Re: A review of dm-writeboost
Mikulas, > Next, you need to design some locking - which variables are protected by > which locks. If you use shared variables without locks, you need to use > memory barriers (it is harder to design code using memory barriers than > locks). First I will explain the locking and the shared variables. writeboost doesn't have many variables shared among asynchronous threads. 1. We have HashTable for cache lookup and RAM buffer for write data transiently. These data structures are locked by a mutex io_lock. barrier_ios is a queue to push bio flagged with REQ_FUA or REQ_FLUSH. This queue is also locked by io_lock. These bios are chained to flush job inside io_lock. queue_flushing is a routine that makes a flush job and queues it in flush_queue which is protected by a spinlock flush_queue_lock. This foreground (.map) is a producer of flush jobs to flush daemon. 2. flush daemon loops flush_proc in single thread. It pops and consumes one flush job from flush_queue (writing to the cache device). Therefore, foreground should keep that the flush job is completely initialized before queues it. After completing the writing, it sets(actually increments) the last_flush_segment_id. This daemon is the only to update this shared variable. 3. migrate daemon loops migrate_proc also running in the single thread. It first calculates how many (nr_mig) segments from last_migrated_segment_id + 1 to + nr_mig by referring last_flushed_segment_id and last_migrate_segment_id. The former is the head of the dirty log and the latter is the tail. Note that the head doesn't have to be synchronized since the last_flush_segment_id linearly increases. last_flush_segment_id not synced only results in less number of migration than actual. It doesn't collapse anything at all. After migrate all the nr_mig dirty segments, it increments last_migrated_segment_id by nr_mig. This daemon is the only to update this last_migrate_segment_id. Other daemons don't share such variables. > Think of this piece of code: > nr_mig_candidates = cache->last_flushed_segment_id - > cache->last_migrated_segment_id; > ... > nr_mig = min(nr_mig_candidates, > cache->nr_cur_batched_migration); > ... > for (i = 1; i <= nr_mig; i++) { > seg = get_segment_header_by_id( > cache, > cache->last_migrated_segment_id + i); > list_add_tail(&seg->migrate_list, &cache->migrate_list); > } > > The processor may reorder all memory accesses - for example it may read > the data accessed in the "for" cycle before reading the variables > "cache->last_flushed_segment_id" and "cache->last_migrated_segment_id". If > this happens, the code may work with invalid data. True? My understanding is that reordering does not happen for these three blocks of code because there are sequential data dependencies. That the last block is while loop is the point? But, I sorted our other two points we need to insert memory barriers. First is in queue_flushing. We can't deny that incomplete flush job is queued and flush_proc goes bad. I am thinking of inserting smp_wmb before queuing and smp_rmb after popping a job in flush_proc. Second is in migrate_proc. We can't deny that migrate_proc goes into migrate_linked_segments before cache->migrate_list is properly initialized. I am thinking of inserting smp_wmb before migrate_linked_segments. I don't understand memory barrier well. So, please fix if I am going the wrong way. > Nonatomic 64-bit variables > -- > > Note that 64-bit variables are not atomic on 32-bit architectures. > > Linux assumes that 32-bit variables are atomic on 32-bit architectures and > 64-bit or 32-bit variables are atomic on 64-bit architectures. That is, > variables having the "long" or "int" type are atomic. Atomicity means that > if you read and modify the variable at the same time, you read either the > old value or the new values. > > 64-bit variables on 32-bit architectures are usually read and written in > two steps, and thus the atomicity requirement isn't true. > > For example, suppose that you change cache->last_flushed_segment_id from > 0x to 0x0001. Now, the function migrate_proc > that asynchronously reads cache->last_flushed_segment_id can read > 0x or 0x0001 (if it reads one of these values, > it behaves correctly), but it can also read 0x or > 0x0001 - if migrate_proc reads one of these two values, it > goes wild, migrating segments that weren't ever supposed to be migrated, > and likely causes a crash or data corruption. > > I found this bug in migrate_proc and update_superblock_record (but it may > be also in other parts of the code). > > You can use atomic64_t type for atomic 64-bit variables (plus memory > barriers as explained in the previous section). Or
Re: [PATCH 1/2] hyperv-fb: add pci stub
On 02/10/13 14:55, Gerd Hoffmann wrote: > This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer > driver will bind to the pci device then, so linux kernel and userspace > know there is a proper kernel driver for the device active. lspci shows > this for example: > > [root@dhcp231 ~]# lspci -vs8 > 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual > VGA (prog-if 00 [VGA controller]) > Flags: bus master, fast devsel, latency 0, IRQ 11 > Memory at f800 (32-bit, non-prefetchable) [size=64M] > Expansion ROM at [disabled] > Kernel driver in use: hyperv_fb > > Another effect is that the xorg vesa driver will not attach to the > device and thus the Xorg server will automatically use the fbdev > driver instead. > > Signed-off-by: Gerd Hoffmann > --- > drivers/video/hyperv_fb.c | 40 +++- > 1 file changed, 39 insertions(+), 1 deletion(-) > Thanks, queuing the series for 3.13. Tomi signature.asc Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 06/10] staging: lustre: Do not use 0 for NULL pointer in console.c
Do not use 0 for NULL pointer. Signed-off-by: Sachin Kamat --- drivers/staging/lustre/lnet/selftest/console.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/selftest/console.c b/drivers/staging/lustre/lnet/selftest/console.c index 09e4700..f1152e4 100644 --- a/drivers/staging/lustre/lnet/selftest/console.c +++ b/drivers/staging/lustre/lnet/selftest/console.c @@ -797,7 +797,7 @@ lstcon_group_info(char *name, lstcon_ndlist_ent_t *gents_p, return rc; } - if (dents_up != 0) { + if (dents_up) { /* verbose query */ rc = lstcon_nodes_getent(&grp->grp_ndl_list, index_p, count_p, dents_up); -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 02/10] staging: dgap: dgap_fep5: Remove braces around return
Braces are not needed around return values. Signed-off-by: Sachin Kamat Cc: Lidza Louina --- drivers/staging/dgap/dgap_fep5.c | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/staging/dgap/dgap_fep5.c b/drivers/staging/dgap/dgap_fep5.c index 5ebfcac..86e9aa6 100644 --- a/drivers/staging/dgap/dgap_fep5.c +++ b/drivers/staging/dgap/dgap_fep5.c @@ -134,7 +134,7 @@ int dgap_after_config_loaded(void) dgap_Board[i]->flipflagbuf = dgap_driver_kzmalloc(MYFLIPLEN, GFP_ATOMIC); } - return (rc); + return rc; } @@ -150,14 +150,14 @@ static int dgap_usertoboard(struct board_t *brd, char *to_addr, char __user *fro int n = U2BSIZE; if (!brd || brd->magic != DGAP_BOARD_MAGIC) - return(-EFAULT); + return -EFAULT; while (len) { if (n > len) n = len; if (copy_from_user((char *) &buf, from_addr, n) == -1 ) { - return(-EFAULT); + return -EFAULT; } /* Copy data from buffer to card memory */ @@ -169,7 +169,7 @@ static int dgap_usertoboard(struct board_t *brd, char *to_addr, char __user *fro from_addr += n; n = U2BSIZE; } - return(0); + return 0; } @@ -1155,20 +1155,20 @@ uint dgap_get_custom_baud(struct channel_t *ch) uint value = 0; if (!ch || ch->magic != DGAP_CHANNEL_MAGIC) { - return (0); + return 0; } if (!ch->ch_bd || ch->ch_bd->magic != DGAP_BOARD_MAGIC) { - return (0); + return 0; } if (!(ch->ch_bd->bd_flags & BD_FEP5PLUS)) - return (0); + return 0; vaddr = ch->ch_bd->re_map_membase; if (!vaddr) - return (0); + return 0; /* * Go get from fep mem, what the fep @@ -1178,7 +1178,7 @@ uint dgap_get_custom_baud(struct channel_t *ch) (ch->ch_portnum * 0x28) + LINE_SPEED)); value = readw(vaddr + offset); - return (value); + return value; } @@ -1230,23 +1230,23 @@ int dgap_param(struct tty_struct *tty) uchar hflow; if (!tty || tty->magic != TTY_MAGIC) - return (-ENXIO); + return -ENXIO; un = (struct un_t *) tty->driver_data; if (!un || un->magic != DGAP_UNIT_MAGIC) - return (-ENXIO); + return -ENXIO; ch = un->un_ch; if (!ch || ch->magic != DGAP_CHANNEL_MAGIC) - return (-ENXIO); + return -ENXIO; bd = ch->ch_bd; if (!bd || bd->magic != DGAP_BOARD_MAGIC) - return (-ENXIO); + return -ENXIO; bs = ch->ch_bs; if (bs == 0) - return (-ENXIO); + return -ENXIO; DPR_PARAM(("param start: tdev: %x cflags: %x oflags: %x iflags: %x\n", ch->ch_tun.un_dev, ch->ch_c_cflag, ch->ch_c_oflag, ch->ch_c_iflag)); @@ -1553,7 +1553,7 @@ int dgap_param(struct tty_struct *tty) DPR_PARAM(("param finish\n")); - return (0); + return 0; } @@ -1670,7 +1670,7 @@ static int dgap_event(struct board_t *bd) int b1; if (!bd || bd->magic != DGAP_BOARD_MAGIC) - return (-ENXIO); + return -ENXIO; DGAP_LOCK(bd->bd_lock, lock_flags); @@ -1678,7 +1678,7 @@ static int dgap_event(struct board_t *bd) if (!vaddr) { DGAP_UNLOCK(bd->bd_lock, lock_flags); - return (-ENXIO); + return -ENXIO; } eaddr = (struct ev_t *) (vaddr + EVBUF); @@ -1696,7 +1696,7 @@ static int dgap_event(struct board_t *bd) DPR_EVENT(("should be calling xxfail %d\n", __LINE__)); /* Let go of board lock */ DGAP_UNLOCK(bd->bd_lock, lock_flags); - return (-ENXIO); + return -ENXIO; } /* @@ -1944,5 +1944,5 @@ next: writew(tail, &(eaddr->ev_tail)); DGAP_UNLOCK(bd->bd_lock, lock_flags); - return (0); + return 0; } -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 05/10] staging: line6: midi: Use NULL instead of 0 for pointers
Use NULL instead of 0 for pointers. Signed-off-by: Sachin Kamat --- drivers/staging/line6/midi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/line6/midi.c b/drivers/staging/line6/midi.c index e3f9a53..52da4d9 100644 --- a/drivers/staging/line6/midi.c +++ b/drivers/staging/line6/midi.c @@ -205,7 +205,7 @@ static void line6_midi_input_trigger(struct snd_rawmidi_substream *substream, if (up) line6->line6midi->substream_receive = substream; else - line6->line6midi->substream_receive = 0; + line6->line6midi->substream_receive = NULL; } static struct snd_rawmidi_ops line6_midi_output_ops = { -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/10] staging: dgap: dgap_fep5: Do not use 0 for NULL pointer
Do not compare NULL pointer with 0. Signed-off-by: Sachin Kamat Cc: Lidza Louina --- drivers/staging/dgap/dgap_fep5.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/dgap/dgap_fep5.c b/drivers/staging/dgap/dgap_fep5.c index 86e9aa6..794cf9d 100644 --- a/drivers/staging/dgap/dgap_fep5.c +++ b/drivers/staging/dgap/dgap_fep5.c @@ -1245,7 +1245,7 @@ int dgap_param(struct tty_struct *tty) return -ENXIO; bs = ch->ch_bs; - if (bs == 0) + if (!bs) return -ENXIO; DPR_PARAM(("param start: tdev: %x cflags: %x oflags: %x iflags: %x\n", -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 07/10] staging: dgnc: dgnc_tty: Do not use 0 for NULL pointer
Do not use 0 for NULL pointer. Signed-off-by: Sachin Kamat Cc: Lidza Louina --- drivers/staging/dgnc/dgnc_tty.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c index c6fee11..a6c6aba 100644 --- a/drivers/staging/dgnc/dgnc_tty.c +++ b/drivers/staging/dgnc/dgnc_tty.c @@ -520,7 +520,7 @@ void dgnc_sniff_nowait_nolock(struct channel_t *ch, uchar *text, uchar *buf, int /* * Loop while data remains. */ - while (nbuf > 0 && ch->ch_sniff_buf != 0) { + while (nbuf > 0 && ch->ch_sniff_buf) { /* * Determine the amount of available space left in the * buffer. If there's none, wait until some appears. -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/10] staging: dgap: dgap_tty: Do not use 0 for pointers
0 should not be used instead of NULL for pointers. Signed-off-by: Sachin Kamat Cc: Lidza Louina --- drivers/staging/dgap/dgap_tty.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/staging/dgap/dgap_tty.c b/drivers/staging/dgap/dgap_tty.c index 924e2bf..2a7a372 100644 --- a/drivers/staging/dgap/dgap_tty.c +++ b/drivers/staging/dgap/dgap_tty.c @@ -595,7 +595,7 @@ static void dgap_sniff_nowait_nolock(struct channel_t *ch, uchar *text, uchar *b /* * Loop while data remains. */ - while (nbuf > 0 && ch->ch_sniff_buf != 0) { + while (nbuf > 0 && ch->ch_sniff_buf) { /* * Determine the amount of available space left in the * buffer. If there's none, wait until some appears. @@ -1107,9 +1107,10 @@ static int dgap_tty_open(struct tty_struct *tty, struct file *file) MAJOR(tty_devnum(tty)), MINOR(tty_devnum(tty)), un, brd->name)); /* -* Error if channel info pointer is 0. +* Error if channel info pointer is NULL. */ - if ((bs = ch->ch_bs) == 0) { + bs = ch->ch_bs; + if (!bs) { DGAP_UNLOCK(ch->ch_lock, lock_flags2); DGAP_UNLOCK(brd->bd_lock, lock_flags); DPR_OPEN(("%d BS is 0!\n", __LINE__)); -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/10] staging: rtl8192u: Use NULL instead of 0
Use NULL instead of 0 for pointer. Signed-off-by: Sachin Kamat --- drivers/staging/rtl8192u/r8192U_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c index cd0946d..c383e64 100644 --- a/drivers/staging/rtl8192u/r8192U_core.c +++ b/drivers/staging/rtl8192u/r8192U_core.c @@ -2009,7 +2009,7 @@ void rtl8192_usb_deleteendpoints(struct net_device *dev) priv->oldaddr = NULL; if (priv->pp_rxskb) { kfree(priv->pp_rxskb); - priv->pp_rxskb = 0; + priv->pp_rxskb = NULL; } } #else -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 01/10] staging: dgap: dgap_fep5: Remove braces around single line statements
Single line statements do not require braces. Signed-off-by: Sachin Kamat Cc: Lidza Louina --- drivers/staging/dgap/dgap_fep5.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/staging/dgap/dgap_fep5.c b/drivers/staging/dgap/dgap_fep5.c index 4464f02..5ebfcac 100644 --- a/drivers/staging/dgap/dgap_fep5.c +++ b/drivers/staging/dgap/dgap_fep5.c @@ -1229,29 +1229,24 @@ int dgap_param(struct tty_struct *tty) uchar mval; uchar hflow; - if (!tty || tty->magic != TTY_MAGIC) { + if (!tty || tty->magic != TTY_MAGIC) return (-ENXIO); - } un = (struct un_t *) tty->driver_data; - if (!un || un->magic != DGAP_UNIT_MAGIC) { + if (!un || un->magic != DGAP_UNIT_MAGIC) return (-ENXIO); - } ch = un->un_ch; - if (!ch || ch->magic != DGAP_CHANNEL_MAGIC) { + if (!ch || ch->magic != DGAP_CHANNEL_MAGIC) return (-ENXIO); - } bd = ch->ch_bd; - if (!bd || bd->magic != DGAP_BOARD_MAGIC) { + if (!bd || bd->magic != DGAP_BOARD_MAGIC) return (-ENXIO); - } bs = ch->ch_bs; - if (bs == 0) { + if (bs == 0) return (-ENXIO); - } DPR_PARAM(("param start: tdev: %x cflags: %x oflags: %x iflags: %x\n", ch->ch_tun.un_dev, ch->ch_c_cflag, ch->ch_c_oflag, ch->ch_c_iflag)); -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 10/10] staging: vt6655: Use NULL instead of 0
Use NULL instead of 0 for pointer. Signed-off-by: Sachin Kamat Cc: Forest Bond --- drivers/staging/vt6655/wroute.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/wroute.c b/drivers/staging/vt6655/wroute.c index b61328f..85302c5 100644 --- a/drivers/staging/vt6655/wroute.c +++ b/drivers/staging/vt6655/wroute.c @@ -179,7 +179,7 @@ bool ROUTEbRelay(PSDevice pDevice, unsigned char *pbySkbData, unsigned int uData pHeadTD = pHeadTD->next; } - pLastTD->pTDInfo->skb = 0; + pLastTD->pTDInfo->skb = NULL; pLastTD->pTDInfo->byFlags = 0; pDevice->apCurrTD[TYPE_AC0DMA] = pHeadTD; -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 08/10] staging: lirc: Do not use 0 for NULL pointer
Do not use 0 for NULL pointer. Signed-off-by: Sachin Kamat Cc: Jarod Wilson --- drivers/staging/media/lirc/lirc_bt829.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_bt829.c b/drivers/staging/media/lirc/lirc_bt829.c index fa31ee7..fbbdce4 100644 --- a/drivers/staging/media/lirc/lirc_bt829.c +++ b/drivers/staging/media/lirc/lirc_bt829.c @@ -132,7 +132,7 @@ int init_module(void) atir_driver.minor = -1; atir_driver.code_length = 8; atir_driver.sample_rate = 10; - atir_driver.data= 0; + atir_driver.data= NULL; atir_driver.add_to_buf = atir_add_to_buf; atir_driver.set_use_inc = atir_set_use_inc; atir_driver.set_use_dec = atir_set_use_dec; @@ -159,7 +159,7 @@ void cleanup_module(void) static int atir_init_start(void) { pci_addr_lin = ioremap(pci_addr_phys + DATA_PCI_OFF, 0x400); - if (pci_addr_lin == 0) { + if (!pci_addr_lin) { pr_info("pci mem must be mapped\n"); return 0; } -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: mt29f_spinand: Use module_spi_driver
module_spi_driver removes the boilerplate code and simplifies it. Signed-off-by: Sachin Kamat Cc: Henry Pan --- drivers/staging/mt29f_spinand/mt29f_spinand.c | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c index 8e95a57..5647079 100644 --- a/drivers/staging/mt29f_spinand/mt29f_spinand.c +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c @@ -939,23 +939,7 @@ static struct spi_driver spinand_driver = { .remove = spinand_remove, }; -/* - * Device driver registration - */ -static int __init spinand_init(void) -{ - return spi_register_driver(&spinand_driver); -} - -/* - * unregister Device driver. - */ -static void __exit spinand_exit(void) -{ - spi_unregister_driver(&spinand_driver); -} -module_init(spinand_init); -module_exit(spinand_exit); +module_spi_driver(spinand_driver); MODULE_DESCRIPTION("SPI NAND driver for Micron"); MODULE_AUTHOR("Henry Pan , Kamlakant Patel "); -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[BUG] imx-drm: lockdep circular locking dependency
A suggestion to IMX developers: please run your test kernels with PROVE_LOCKING enabled (and preferably other debugging options too.) Thanks. == [ INFO: possible circular locking dependency detected ] 3.12.0-rc3+ #43 Not tainted --- swapper/0/1 is trying to acquire lock: (&imx_drm_device->mutex){+.+.+.}, at: [] imx_drm_encoder_get_mux_id+0x28/0x98 but task is already holding lock: (&crtc->mutex){+.+...}, at: [] drm_modeset_lock_all+0x44/0x58 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&crtc->mutex){+.+...}: [] __lock_acquire+0x15a8/0x1e1c [] lock_acquire+0x68/0x7c [] _mutex_lock_nest_lock+0x58/0x388 [] drm_crtc_init+0x48/0xb0 [] imx_drm_add_crtc+0xe4/0x148 [] ipu_drm_probe+0x138/0x20c [] platform_drv_probe+0x20/0x24 [] driver_probe_device+0x9c/0x234 [] __driver_attach+0x9c/0xa0 [] bus_for_each_dev+0x70/0x94 [] driver_attach+0x24/0x28 [] bus_add_driver+0x1d8/0x26c [] driver_register+0x80/0xfc [] __platform_driver_register+0x50/0x64 [] ipu_drm_driver_init+0x18/0x20 [] do_one_initcall+0x38/0x168 [] kernel_init_freeable+0x104/0x1cc [] kernel_init+0x10/0xec [] ret_from_fork+0x14/0x2c -> #1 (&dev->mode_config.mutex){+.+.+.}: [] __lock_acquire+0x15a8/0x1e1c [] lock_acquire+0x68/0x7c [] mutex_lock_nested+0x5c/0x38c [] drm_modeset_lock_all+0x20/0x58 [] drm_encoder_init+0x20/0x84 [] imx_drm_add_encoder+0x8c/0xe0 [] imx_ldb_probe+0x2bc/0x50c [] platform_drv_probe+0x20/0x24 [] driver_probe_device+0x9c/0x234 [] __driver_attach+0x9c/0xa0 [] bus_for_each_dev+0x70/0x94 [] driver_attach+0x24/0x28 [] bus_add_driver+0x1d8/0x26c [] driver_register+0x80/0xfc [] __platform_driver_register+0x50/0x64 [] imx_ldb_driver_init+0x18/0x20 [] do_one_initcall+0x38/0x168 [] kernel_init_freeable+0x104/0x1cc [] kernel_init+0x10/0xec [] ret_from_fork+0x14/0x2c -> #0 (&imx_drm_device->mutex){+.+.+.}: [] print_circular_bug+0x74/0x2fc [] __lock_acquire+0x1770/0x1e1c [] lock_acquire+0x68/0x7c [] mutex_lock_nested+0x5c/0x38c [] imx_drm_encoder_get_mux_id+0x28/0x98 [] imx_ldb_encoder_prepare+0x3c/0x12c [] drm_crtc_helper_set_mode+0x1f8/0x4b0 [] drm_crtc_helper_set_config+0x7b4/0x9dc [] drm_mode_set_config_internal+0x68/0xf0 [] drm_fb_helper_set_par+0x54/0xb0 [] fbcon_init+0x4c8/0x520 [] visual_init+0xac/0xf8 [] do_bind_con_driver+0x16c/0x388 [] do_take_over_console+0xa4/0x1b4 [] do_fbcon_takeover+0x70/0xd4 [] fbcon_event_notify+0x7e0/0x830 [] notifier_call_chain+0x4c/0x8c [] __blocking_notifier_call_chain+0x50/0x68 [] blocking_notifier_call_chain+0x20/0x28 [] fb_notifier_call_chain+0x20/0x24 [] register_framebuffer+0x1ac/0x268 [] drm_fb_helper_initial_config+0x408/0x574 [] drm_fbdev_cma_init+0x7c/0xe8 [] imx_fb_helper_init+0x58/0x90 [] do_one_initcall+0x38/0x168 [] kernel_init_freeable+0x104/0x1cc [] kernel_init+0x10/0xec [] ret_from_fork+0x14/0x2c other info that might help us debug this: Chain exists of: &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex Possible unsafe locking scenario: CPU0CPU1 lock(&crtc->mutex); lock(&dev->mode_config.mutex); lock(&crtc->mutex); lock(&imx_drm_device->mutex); *** DEADLOCK *** 6 locks held by swapper/0/1: #0: (registration_lock){+.+.+.}, at: [] register_framebuffer+0x20/0x268 #1: (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x20/0x44 #2: (console_lock){+.+.+.}, at: [] register_framebuffer+0x19c/0x268 #3: ((fb_notifier_list).rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x34/0x68 #4: (&dev->mode_config.mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x20/0x58 #5: (&crtc->mutex){+.+...}, at: [] drm_modeset_lock_all+0x44/0x58 stack backtrace: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-rc3+ #43 Backtrace: [] (dump_backtrace+0x0/0x10c) from [] (show_stack+0x18/0x1c) r6:c097dba8 r5:c097e318 r4: r3: [] (show_stack+0x0/0x1c) from [] (dump_stack+0x70/0x90) [] (dump_stack+0x0/0x90) from [] (print_circular_bug+0x1d0/0x2fc) r4:c097ddc8 r3:df87 [] (print_circular_bug+0x0/0x2fc) from [] (__lock_acquire+0x1770/0x1e1c) [] (__lock_acquire+0x0/0x1e1c) from [] (lock_acquire+0x68/0x7c) [] (lock_acquire+0x0/0x7c) from [] (mutex_lock_nested+0x5c/0x38c) r7:df86c000 r6:c088904c r5:c046eaa8 r4:dfb6c4a0 [] (mutex_lock_nested+0x0/0x38c) from [] (imx_drm_encoder_get_mux_id+0x28/0x98) [] (imx_drm_e
RE: [PATCH 01/28] staging: comedi: s626: tidy the header file a bit
On Tuesday, October 08, 2013 11:06 AM, Ian Abbott wrote: > Tidy up the "s626.h" header file a bit, cleaning up the whitespace and > fixing overlength lines. Add multiple inclusion protection (even though > it's only included once and only by "s626.c"). Remove unnecessary > driver comment near the start of the file as it is more or less the same > as the one in "s626.c". Remove obviously unused/useless stuff. > > I'm not sure what to do about the INTEL/MOTOROLA platform selection in > the file. I've left it alone (set to INTEL) for now. > > Signed-off-by: Ian Abbott > --- > drivers/staging/comedi/drivers/s626.h | 925 > -- > 1 file changed, 436 insertions(+), 489 deletions(-) Ian, I'm still reviewing this series but I had a comment on the s626.h file. Since the s626 driver is the only user of this header it would be nicer if this head just went away. Any objections to just merging its contents directly info to s626.c file? This could be done as a single patch after this series is applied. Regards, Hartley ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
On 09/27/2013 08:35 AM, KY Srinivasan wrote: > > Thanks Olaf. Could you submit the patch. > Haven't heard anything from Olaf... could you fold in the fix and resumbit? -hpa ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] imx-drm: imx-drm-core: Fix circular locking dependency
From: Fabio Estevam Booting a mx6 with CONFIG_PROVE_LOCKING we get: == [ INFO: possible circular locking dependency detected ] 3.12.0-rc4-next-20131009+ #34 Not tainted --- swapper/0/1 is trying to acquire lock: (&imx_drm_device->mutex){+.+.+.}, at: [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98 but task is already holding lock: (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&crtc->mutex){+.+...}: [<800777d0>] __lock_acquire+0x18d4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805ead5c>] _mutex_lock_nest_lock+0x58/0x3a8 [<802fec50>] drm_crtc_init+0x48/0xa8 [<80457c88>] imx_drm_add_crtc+0xd4/0x144 [<8045e2e8>] ipu_drm_probe+0x114/0x1fc [<80312278>] platform_drv_probe+0x20/0x50 [<80310c68>] driver_probe_device+0x110/0x22c [<80310e20>] __driver_attach+0x9c/0xa0 [<8030f218>] bus_for_each_dev+0x5c/0x90 [<80310750>] driver_attach+0x20/0x28 [<8031034c>] bus_add_driver+0xdc/0x1dc [<803114d8>] driver_register+0x80/0xfc [<80312198>] __platform_driver_register+0x50/0x64 [<808172fc>] ipu_drm_driver_init+0x18/0x20 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c -> #1 (&dev->mode_config.mutex){+.+.+.}: [<800777d0>] __lock_acquire+0x18d4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805eb100>] mutex_lock_nested+0x54/0x3a4 [<802fe758>] drm_modeset_lock_all+0x20/0x54 [<802fead4>] drm_encoder_init+0x20/0x7c [<80457ae4>] imx_drm_add_encoder+0x88/0xec [<80459838>] imx_ldb_probe+0x344/0x4fc [<80312278>] platform_drv_probe+0x20/0x50 [<80310c68>] driver_probe_device+0x110/0x22c [<80310e20>] __driver_attach+0x9c/0xa0 [<8030f218>] bus_for_each_dev+0x5c/0x90 [<80310750>] driver_attach+0x20/0x28 [<8031034c>] bus_add_driver+0xdc/0x1dc [<803114d8>] driver_register+0x80/0xfc [<80312198>] __platform_driver_register+0x50/0x64 [<8081722c>] imx_ldb_driver_init+0x18/0x20 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c -> #0 (&imx_drm_device->mutex){+.+.+.}: [<805e510c>] print_circular_bug+0x74/0x2e0 [<80077ad0>] __lock_acquire+0x1bd4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805eb100>] mutex_lock_nested+0x54/0x3a4 [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98 [<80459a98>] imx_ldb_encoder_prepare+0x34/0x114 [<802ef724>] drm_crtc_helper_set_mode+0x1f0/0x4c0 [<802f0344>] drm_crtc_helper_set_config+0x828/0x99c [<802ff270>] drm_mode_set_config_internal+0x5c/0xdc [<802eebe0>] drm_fb_helper_set_par+0x50/0xb4 [<802af580>] fbcon_init+0x490/0x500 [<802dd104>] visual_init+0xa8/0xf8 [<802df414>] do_bind_con_driver+0x140/0x37c [<802df764>] do_take_over_console+0x114/0x1c4 [<802af65c>] do_fbcon_takeover+0x6c/0xd4 [<802b2b30>] fbcon_event_notify+0x7c8/0x818 [<80049954>] notifier_call_chain+0x4c/0x8c [<80049cd8>] __blocking_notifier_call_chain+0x50/0x68 [<80049d10>] blocking_notifier_call_chain+0x20/0x28 [<802a75f0>] fb_notifier_call_chain+0x1c/0x24 [<802a9224>] register_framebuffer+0x188/0x268 [<802ee994>] drm_fb_helper_initial_config+0x2bc/0x4b8 [<802f118c>] drm_fbdev_cma_init+0x7c/0xec [<80817288>] imx_fb_helper_init+0x54/0x90 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c other info that might help us debug this: Chain exists of: &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex Possible unsafe locking scenario: CPU0CPU1 lock(&crtc->mutex); lock(&dev->mode_config.mutex); lock(&crtc->mutex); lock(&imx_drm_device->mutex); *** DEADLOCK *** 6 locks held by swapp
Re: [PATCH] imx-drm: imx-drm-core: Fix circular locking dependency
On Wed, Oct 09, 2013 at 08:07:12PM -0300, Fabio Estevam wrote: > In order to avoid this lockdep warning, remove the locking from > imx_drm_encoder_get_mux_id() and imx_drm_crtc_panel_format_pins(). > > Tested on a mx6sabrelite and mx53qsb. > > Reported-by: Russell King > Signed-off-by: Fabio Estevam Confirmed that it avoids the warning. Tested-by: Russell King (Please change the reported-to to this address as well please, thanks.) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] imx-drm: imx-drm-core: Fix circular locking dependency
From: Fabio Estevam Booting a mx6 with CONFIG_PROVE_LOCKING we get: == [ INFO: possible circular locking dependency detected ] 3.12.0-rc4-next-20131009+ #34 Not tainted --- swapper/0/1 is trying to acquire lock: (&imx_drm_device->mutex){+.+.+.}, at: [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98 but task is already holding lock: (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&crtc->mutex){+.+...}: [<800777d0>] __lock_acquire+0x18d4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805ead5c>] _mutex_lock_nest_lock+0x58/0x3a8 [<802fec50>] drm_crtc_init+0x48/0xa8 [<80457c88>] imx_drm_add_crtc+0xd4/0x144 [<8045e2e8>] ipu_drm_probe+0x114/0x1fc [<80312278>] platform_drv_probe+0x20/0x50 [<80310c68>] driver_probe_device+0x110/0x22c [<80310e20>] __driver_attach+0x9c/0xa0 [<8030f218>] bus_for_each_dev+0x5c/0x90 [<80310750>] driver_attach+0x20/0x28 [<8031034c>] bus_add_driver+0xdc/0x1dc [<803114d8>] driver_register+0x80/0xfc [<80312198>] __platform_driver_register+0x50/0x64 [<808172fc>] ipu_drm_driver_init+0x18/0x20 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c -> #1 (&dev->mode_config.mutex){+.+.+.}: [<800777d0>] __lock_acquire+0x18d4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805eb100>] mutex_lock_nested+0x54/0x3a4 [<802fe758>] drm_modeset_lock_all+0x20/0x54 [<802fead4>] drm_encoder_init+0x20/0x7c [<80457ae4>] imx_drm_add_encoder+0x88/0xec [<80459838>] imx_ldb_probe+0x344/0x4fc [<80312278>] platform_drv_probe+0x20/0x50 [<80310c68>] driver_probe_device+0x110/0x22c [<80310e20>] __driver_attach+0x9c/0xa0 [<8030f218>] bus_for_each_dev+0x5c/0x90 [<80310750>] driver_attach+0x20/0x28 [<8031034c>] bus_add_driver+0xdc/0x1dc [<803114d8>] driver_register+0x80/0xfc [<80312198>] __platform_driver_register+0x50/0x64 [<8081722c>] imx_ldb_driver_init+0x18/0x20 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c -> #0 (&imx_drm_device->mutex){+.+.+.}: [<805e510c>] print_circular_bug+0x74/0x2e0 [<80077ad0>] __lock_acquire+0x1bd4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805eb100>] mutex_lock_nested+0x54/0x3a4 [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98 [<80459a98>] imx_ldb_encoder_prepare+0x34/0x114 [<802ef724>] drm_crtc_helper_set_mode+0x1f0/0x4c0 [<802f0344>] drm_crtc_helper_set_config+0x828/0x99c [<802ff270>] drm_mode_set_config_internal+0x5c/0xdc [<802eebe0>] drm_fb_helper_set_par+0x50/0xb4 [<802af580>] fbcon_init+0x490/0x500 [<802dd104>] visual_init+0xa8/0xf8 [<802df414>] do_bind_con_driver+0x140/0x37c [<802df764>] do_take_over_console+0x114/0x1c4 [<802af65c>] do_fbcon_takeover+0x6c/0xd4 [<802b2b30>] fbcon_event_notify+0x7c8/0x818 [<80049954>] notifier_call_chain+0x4c/0x8c [<80049cd8>] __blocking_notifier_call_chain+0x50/0x68 [<80049d10>] blocking_notifier_call_chain+0x20/0x28 [<802a75f0>] fb_notifier_call_chain+0x1c/0x24 [<802a9224>] register_framebuffer+0x188/0x268 [<802ee994>] drm_fb_helper_initial_config+0x2bc/0x4b8 [<802f118c>] drm_fbdev_cma_init+0x7c/0xec [<80817288>] imx_fb_helper_init+0x54/0x90 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c other info that might help us debug this: Chain exists of: &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex Possible unsafe locking scenario: CPU0CPU1 lock(&crtc->mutex); lock(&dev->mode_config.mutex); lock(&crtc->mutex); lock(&imx_drm_device->mutex); *** DEADLOCK *** 6 locks held by swapp
RE: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > Sent: Wednesday, October 09, 2013 3:50 PM > To: KY Srinivasan > Cc: Olaf Hering; x...@kernel.org; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; a...@canonical.com; > jasow...@redhat.com; t...@linutronix.de; jbeul...@suse.com; b...@alien8.de > Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency > from the hypervisor > > On 09/27/2013 08:35 AM, KY Srinivasan wrote: > > > > Thanks Olaf. Could you submit the patch. > > > > Haven't heard anything from Olaf... could you fold in the fix and resumbit? I think Olaf sent the updated patch out; I will dig up the email and resend it. Regards, K. Y > > -hpa > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 00/28] staging: comedi: s626: tidy up
On Tuesday, October 08, 2013 11:06 AM, Ian Abbott wrote: > > Tidy up the s626 comedi driver a bit. This driver is mind numbingly hard to follow... All the subtracted bit shifting and masking is still a mess. Probably why the code is so comment happy. But, your cleanup does help so... Reviewed-by: H Hartley Sweeten ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
My friendly greetings
My Boss has instructed me to contact you with regards to a transaction worth 22.4million pounds to discuss with you. Reply to his private email mark- jcar...@hotmail.co.uk for more information. Anetta ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: xillybus: Use module_platform_driver
module_platform_driver simplifies the code by removing the boilerplate. Signed-off-by: Sachin Kamat --- drivers/staging/xillybus/xillybus_of.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/staging/xillybus/xillybus_of.c b/drivers/staging/xillybus/xillybus_of.c index 92c2931..2ae045e 100644 --- a/drivers/staging/xillybus/xillybus_of.c +++ b/drivers/staging/xillybus/xillybus_of.c @@ -198,15 +198,4 @@ static struct platform_driver xillybus_platform_driver = { }, }; -static int __init xillybus_of_init(void) -{ - return platform_driver_register(&xillybus_platform_driver); -} - -static void __exit xillybus_of_exit(void) -{ - platform_driver_unregister(&xillybus_platform_driver); -} - -module_init(xillybus_of_init); -module_exit(xillybus_of_exit); +module_platform_driver(xillybus_platform_driver); -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel