search for: kernf

Displaying 20 results from an estimated 30 matches for "kernf".

Did you mean: kern
2014 Jul 01
3
[PATCH driver-core-linus] kernfs: kernfs_notify() must be useable from non-sleepable contexts
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...
2014 Jul 01
3
[PATCH driver-core-linus] kernfs: kernfs_notify() must be useable from non-sleepable contexts
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...
2003 Jul 11
3
Where did kernfs go?
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-
2014 Jul 02
1
[PATCH driver-core-linus] kernfs: kernfs_notify() must be useable from non-sleepable contexts
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...
2014 Jul 02
1
[PATCH driver-core-linus] kernfs: kernfs_notify() must be useable from non-sleepable contexts
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...
2014 Jul 01
0
[PATCH driver-core-linus] kernfs: kernfs_notify() must be useable from non-sleepable contexts
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...
2014 Jun 29
2
virt_blk BUG: sleeping function called from invalid context
...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...
2014 Jun 29
2
virt_blk BUG: sleeping function called from invalid context
...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...
2020 Apr 30
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...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 -------------...
2020 Apr 30
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...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 -------------...
2014 Jun 29
2
virt_blk BUG: sleeping function called from invalid context
...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.
2014 Jun 29
2
virt_blk BUG: sleeping function called from invalid context
...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.
2020 Apr 30
0
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...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...
2008 Jun 10
3
[PATCH][TOOLS] libxc: mmap fixes for BSD
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...
2014 Jun 29
0
virt_blk BUG: sleeping function called from invalid context
...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:...
2020 Apr 29
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
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
2020 Apr 29
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
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
2019 Dec 26
1
[PATCH v2 5/6] KVM: arm64: Add interface to support VCPU preempted check
...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...
2003 Aug 06
2
statically compiled files left over after a 'make world'
...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...
2020 Feb 05
0
[PATCH v1 2/3] virtio_balloon: Fix memory leaks on errors in virtballoon_probe()
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...