search for: kernfs_notify

d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events too") added fsnotify triggering to kernfs_notify() which requires a sleepable context. There are already existing users of kernfs_notify() which invoke it from an atomic context and in general it's silly to require a sleepable context for triggering a notification...

d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events too") added fsnotify triggering to kernfs_notify() which requires a sleepable context. There are already existing users of kernfs_notify() which invoke it from an atomic context and in general it's silly to require a sleepable context for triggering a notification...

...alling >> a sleeping function. Not sure if that's a bug in MD though given the >> kernfs symbols in the all trace and the recent churn in that area. > > My understanding is this: > > bitmap_endwrite -> calls sysfs_notify_dirent_safe under spinlock > -> calls kernfs_notify which takes a mutex. > > So I am guessing it is this commit: > > commit d911d98748018f7c8facc035ba39c30f5cce6f9c > Author: Tejun Heo <tj at kernel.org> > Date: Wed Apr 9 11:07:31 2014 -0400 > > kernfs: make kernfs_notify() trigger inotify events too > >...

...alling >> a sleeping function. Not sure if that's a bug in MD though given the >> kernfs symbols in the all trace and the recent churn in that area. > > My understanding is this: > > bitmap_endwrite -> calls sysfs_notify_dirent_safe under spinlock > -> calls kernfs_notify which takes a mutex. > > So I am guessing it is this commit: > > commit d911d98748018f7c8facc035ba39c30f5cce6f9c > Author: Tejun Heo <tj at kernel.org> > Date: Wed Apr 9 11:07:31 2014 -0400 > > kernfs: make kernfs_notify() trigger inotify events too > >...

On Tue, Jul 01, 2014 at 04:41:03PM -0400, Tejun Heo wrote: > d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events > too") added fsnotify triggering to kernfs_notify() which requires a > sleepable context. There are already existing users of > kernfs_notify() which invoke it from an atomic context and in general > it's silly to require a sleepable context for trigg...

...1807b4c>] dump_stack+0x4d/0x66 [<ffffffff810d4f14>] __might_sleep+0x184/0x240 [<ffffffff8180caf2>] mutex_lock_nested+0x42/0x440 [<ffffffff810e1de6>] ? local_clock+0x16/0x30 [<ffffffff810fc23f>] ? lock_release_holdtime.part.28+0xf/0x200 [<ffffffff812d76a0>] kernfs_notify+0x90/0x150 [<ffffffff8163377c>] bitmap_endwrite+0xcc/0x240 [<ffffffffa00de863>] close_write+0x93/0xb0 [raid1] [<ffffffffa00df029>] r1_bio_write_done+0x29/0x50 [raid1] [<ffffffffa00e0474>] raid1_end_write_request+0xe4/0x260 [raid1] [<ffffffff813acb8b>] bio_end...

...1807b4c>] dump_stack+0x4d/0x66 [<ffffffff810d4f14>] __might_sleep+0x184/0x240 [<ffffffff8180caf2>] mutex_lock_nested+0x42/0x440 [<ffffffff810e1de6>] ? local_clock+0x16/0x30 [<ffffffff810fc23f>] ? lock_release_holdtime.part.28+0xf/0x200 [<ffffffff812d76a0>] kernfs_notify+0x90/0x150 [<ffffffff8163377c>] bitmap_endwrite+0xcc/0x240 [<ffffffffa00de863>] close_write+0x93/0xb0 [raid1] [<ffffffffa00df029>] r1_bio_write_done+0x29/0x50 [raid1] [<ffffffffa00e0474>] raid1_end_write_request+0xe4/0x260 [raid1] [<ffffffff813acb8b>] bio_end...

Hello, On Tue, Jul 01, 2014 at 01:51:48PM -0700, Greg Kroah-Hartman wrote: > Looks good to me, do you want to take this with your other kernfs > patches for 3.16-final? Or if you don't have that, I can take it > through my tree, it's your choice, either is fine for me. > > If you want it in your tree, feel free to add: > Acked-by: Greg Kroah-Hartman <gregkh at

Hello, On Tue, Jul 01, 2014 at 01:51:48PM -0700, Greg Kroah-Hartman wrote: > Looks good to me, do you want to take this with your other kernfs > patches for 3.16-final? Or if you don't have that, I can take it > through my tree, it's your choice, either is fine for me. > > If you want it in your tree, feel free to add: > Acked-by: Greg Kroah-Hartman <gregkh at

...x4d/0x66 > [<ffffffff810d4f14>] __might_sleep+0x184/0x240 > [<ffffffff8180caf2>] mutex_lock_nested+0x42/0x440 > [<ffffffff810e1de6>] ? local_clock+0x16/0x30 > [<ffffffff810fc23f>] ? lock_release_holdtime.part.28+0xf/0x200 > [<ffffffff812d76a0>] kernfs_notify+0x90/0x150 > [<ffffffff8163377c>] bitmap_endwrite+0xcc/0x240 > [<ffffffffa00de863>] close_write+0x93/0xb0 [raid1] > [<ffffffffa00df029>] r1_bio_write_done+0x29/0x50 [raid1] > [<ffffffffa00e0474>] raid1_end_write_request+0xe4/0x260 [raid1] > [<ffff...

On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote: > On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: > > Hi All, > > > > We've had a report[1] of the virt_blk driver causing a lot of spew > > because it's calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel

On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote: > On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: > > Hi All, > > > > We've had a report[1] of the virt_blk driver causing a lot of spew > > because it's calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel

...at the MD bio end_io handler is calling > a sleeping function. Not sure if that's a bug in MD though given the > kernfs symbols in the all trace and the recent churn in that area. My understanding is this: bitmap_endwrite -> calls sysfs_notify_dirent_safe under spinlock -> calls kernfs_notify which takes a mutex. So I am guessing it is this commit: commit d911d98748018f7c8facc035ba39c30f5cce6f9c Author: Tejun Heo <tj at kernel.org> Date: Wed Apr 9 11:07:31 2014 -0400 kernfs: make kernfs_notify() trigger inotify events too Tejun, what do you think? Josh, Brian, could you...

On Sun, Jun 29, 2014 at 02:55:36PM -0600, Jens Axboe wrote: > > commit d911d98748018f7c8facc035ba39c30f5cce6f9c > > Author: Tejun Heo <tj at kernel.org> > > Date: Wed Apr 9 11:07:31 2014 -0400 > > > > kernfs: make kernfs_notify() trigger inotify events too > > > > Tejun, what do you think? > > > > Josh, Brian, could you try reverting that commit to see if it helps? > > That definitely be a bug. If you need to block off ->bi_end_io(), just > must punt to a worker thread. Ugh... didn&...