search for: kernf

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 trig...

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 trig...

kernfs seems to have disappeared between 4.7-REL and 4.8-REL, but I couldn't find any mention of this in any of 4.8-REL docs, where/why did it go? -Paul-

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 linuxfoundation.org> The other kernfs changes...

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 linuxfoundation.org> The other kernfs changes...

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 sleepa...

...drivers/block/mtip32xx/mtip32xx.c >> >> Just like __blk_end_request_all blk_mq_end_io is supposed to be called >> from irq context. The problem is that 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 d911...

...drivers/block/mtip32xx/mtip32xx.c >> >> Just like __blk_end_request_all blk_mq_end_io is supposed to be called >> from irq context. The problem is that 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 d911...

...cache_type_store() and > cache_type_show() because IIUC they aren't in blk-mq and virtqueue code > paths, but they use vdev. > > Do we have to take the mutex there too? No, because del_gendisk() in virtblk_remove() deletes the sysfs attributes before vblk->vdev is set to NULL. kernfs deactivates the kernfs nodes so that further read()/write() operations fail with ENODEV (see fs/kernfs/dir.c and fs/kernfs/file.c). I have tested that a userspace process with a sysfs attr file open cannot access the attribute after virtblk_remove(). Stefan -------------- next part -------------...

...cache_type_store() and > cache_type_show() because IIUC they aren't in blk-mq and virtqueue code > paths, but they use vdev. > > Do we have to take the mutex there too? No, because del_gendisk() in virtblk_remove() deletes the sysfs attributes before vblk->vdev is set to NULL. kernfs deactivates the kernfs nodes so that further read()/write() operations fail with ENODEV (see fs/kernfs/dir.c and fs/kernfs/file.c). I have tested that a userspace process with a sysfs attr file open cannot access the attribute after virtblk_remove(). Stefan -------------- next part -------------...

...least one other driver is doing this: > drivers/block/mtip32xx/mtip32xx.c Just like __blk_end_request_all blk_mq_end_io is supposed to be called from irq context. The problem is that 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.

...least one other driver is doing this: > drivers/block/mtip32xx/mtip32xx.c Just like __blk_end_request_all blk_mq_end_io is supposed to be called from irq context. The problem is that 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.

...che_type_show() because IIUC they aren't in blk-mq and virtqueue code > > paths, but they use vdev. > > > > Do we have to take the mutex there too? > > No, because del_gendisk() in virtblk_remove() deletes the sysfs > attributes before vblk->vdev is set to NULL. kernfs deactivates the > kernfs nodes so that further read()/write() operations fail with ENODEV > (see fs/kernfs/dir.c and fs/kernfs/file.c). > > I have tested that a userspace process with a sysfs attr file open > cannot access the attribute after virtblk_remove(). > > Stefan So...

Hi! On BSD, mmap()ing files works on on-disk files but not on pseudo filesystems like kernfs or procfs. Therefore, attached patch mmap()s anonymous memory. Linux equivalents are sysfs and procfs to above BSD''s pseudo-filesystems. On Linux, mmap is implemented for sysfs but it is questionable to me how write operations work since (most) files in sysfs have static content. So this...

...ng this: > > drivers/block/mtip32xx/mtip32xx.c > > Just like __blk_end_request_all blk_mq_end_io is supposed to be called > from irq context. The problem is that 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:...

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90

...ported-by: kbuild test robot <lkp at intel.com> All errors (new ones prefixed by >>): In file included from include/linux/spinlock.h:89:0, from include/linux/radix-tree.h:16, from include/linux/idr.h:15, from include/linux/kernfs.h:13, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/of.h:17, from include/linux/irqdomain.h:35, from include/linux/acpi.h:13, from include/ac...

...I recently did a 'make world' to update my base system due to the realpath bug. After that finished, I noticed that I still had the following statically compiled binaries laying around that did not get updated during a 'make world'. I track 4-STABLE. /usr/bin/miniperl /sbin/mount_kernfs /sbin/mount_devfs /sbin/modunload /sbin/modload /sbin/ft /stand/boot_crunch /stand/find /stand/sed /stand/test /stand/pwd /stand/ppp /stand/newfs /stand/minigzip /stand/cpio /stand/bad144 /stand/fsck /stand/ifconfig /stand/route /stand/slattach /stand/mount_nfs /stand/dhclient /stand/arp /stand/gz...

We forget to put the inode and unmount the kernfs used for compaction. Fixes: 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com> Cc: Wei Wang <wei.w.wang at intel.com> Cc: Liang Li <liang.z.li at intel.co...