search for: sleepable

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 triggering a > notification. > > The following is an invalid context bug triggerd by md invoking > sysfs_notif...

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

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. The following is an invalid context bug triggerd by md invoking sysfs_notify() from IO completion path....

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. The following is an invalid context bug triggerd by md invoking sysfs_notify() from IO completion path....

Working on the Dell R420 today, got most of it working, even the broadcom ethernet cards! However, I get the following when I reboot the system: Syncing disks, vnodes remaining...4 Sleeping thread (tid 100107, pid 9) owns a non-sleepable lock KDB: stack backtrace of thread 100107: sched_switch() at sched_switch+0x19f mi_switch() at mi_switch+0x208 sleepq_switch() at sleepq_switch+0xfc sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x3f6 ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97 ipmi_set_watchdog() at ipm...

On 06/29/2014 02:47 PM, Michael S. Tsirkin wrote: > On Sun, Jun 29, 2014 at 09:32:22PM +0200, Christoph Hellwig wrote: >> 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

On 06/29/2014 02:47 PM, Michael S. Tsirkin wrote: > On Sun, Jun 29, 2014 at 09:32:22PM +0200, Christoph Hellwig wrote: >> 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

...- and this function calls some other functions again that might sleep (e.g. kzalloc or wait_event in ccw_io_helper) ... and this causes the new kernel warning message with kernel 3.19. I think it would be quite difficult or at least ugly to rewrite virtio_ccw_get_config() so that it does not call sleepable functions anymore. So would it be feasible to rewrite the balloon() function that it does not call the towards_target() in its wait_event condition anymore? I am unfortunately not that familiar with the balloon code semantics, so any help is very appreciated here! Thanks, Thomas

...- and this function calls some other functions again that might sleep (e.g. kzalloc or wait_event in ccw_io_helper) ... and this causes the new kernel warning message with kernel 3.19. I think it would be quite difficult or at least ugly to rewrite virtio_ccw_get_config() so that it does not call sleepable functions anymore. So would it be feasible to rewrite the balloon() function that it does not call the towards_target() in its wait_event condition anymore? I am unfortunately not that familiar with the balloon code semantics, so any help is very appreciated here! Thanks, Thomas

...o a bit ugly. Answering on behalf of Simon, and hoping he will agree. You are missing a big opportunity to make the kernel avoid doing useless work. The dsa_slave_fdb_event() function runs in atomic switchdev notifier context, and schedules a deferred workqueue item - dsa_schedule_work() - to get sleepable context to program hardware. Only that scheduling a deferred work item is not exactly cheap, so we try to avoid doing that unless we know that we'll end up doing something with that FDB entry once the deferred work does get scheduled: /* Check early that we're not doing work in vain. *...

...rameter to iommu_map_sg() iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous() iommufd: Use GFP_KERNEL_ACCOUNT for iommu_map() iommu/intel: Add a gfp parameter to alloc_pgtable_page() iommu/intel: Support the gfp argument to the map_pages op iommu/intel: Use GFP_KERNEL in sleepable contexts iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s iommu/s390: Use GFP_KERNEL in sleepable contexts arch/arm/mm/dma-mapping.c | 11 ++-- arch/s390/include/asm/pci_dma.h | 5 +- arch/s390/pci/pci_dma.c | 31 +++++...

...rameter to iommu_map_sg() iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous() iommufd: Use GFP_KERNEL_ACCOUNT for iommu_map() iommu/intel: Add a gfp parameter to alloc_pgtable_page() iommu/intel: Support the gfp argument to the map_pages op iommu/intel: Use GFP_KERNEL in sleepable contexts iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s iommu/s390: Use GFP_KERNEL in sleepable contexts arch/arm/mm/dma-mapping.c | 11 ++-- arch/s390/include/asm/pci_dma.h | 5 +- arch/s390/pci/pci_dma.c | 31 +++++...

..., 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't realize we had users triggering sysfs notifications from an atomic context. fsnotify support requires sleepable context. Guess I'll have to punt it to a work item. :( Thanks. -- tejun

...ls some other functions again that might sleep (e.g. kzalloc or > wait_event in ccw_io_helper) ... and this causes the new kernel warning > message with kernel 3.19. > > I think it would be quite difficult or at least ugly to rewrite > virtio_ccw_get_config() so that it does not call sleepable functions > anymore. So would it be feasible to rewrite the balloon() function that > it does not call the towards_target() in its wait_event condition > anymore? I am unfortunately not that familiar with the balloon code > semantics, so any help is very appreciated here! > > Tha...

...ls some other functions again that might sleep (e.g. kzalloc or > wait_event in ccw_io_helper) ... and this causes the new kernel warning > message with kernel 3.19. > > I think it would be quite difficult or at least ugly to rewrite > virtio_ccw_get_config() so that it does not call sleepable functions > anymore. So would it be feasible to rewrite the balloon() function that > it does not call the towards_target() in its wait_event condition > anymore? I am unfortunately not that familiar with the balloon code > semantics, so any help is very appreciated here! > > Tha...

Hi, my FreeBSD-9/stable machine (FreeBSD freebsd-tower.goebo.site 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2 r241044M: Sat Sep 29 12:52:01 CEST 2012 lbo@freebsd-tower.goebo.site:/usr/obj/usr/src/sys/GENERIC i386) crashes reproducibly when rsync-ing files to an NFSv4 share on the FreeBSD machine. The crash makes the system reboot. The crash creates files in /var/crash which may be obtained

...rameter to iommu_map_sg() iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous() iommufd: Use GFP_KERNEL_ACCOUNT for iommu_map() iommu/intel: Add a gfp parameter to alloc_pgtable_page() iommu/intel: Support the gfp argument to the map_pages op iommu/intel: Use GFP_KERNEL in sleepable contexts iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s iommu/s390: Use GFP_KERNEL in sleepable contexts arch/arm/mm/dma-mapping.c | 11 ++-- arch/s390/include/asm/pci_dma.h | 5 +- arch/s390/pci/pci_dma.c | 31 +++++...

On Tue 27-03-18 14:23:51, Wei Wang wrote: > On 03/27/2018 05:22 AM, Andrew Morton wrote: > > On Mon, 26 Mar 2018 10:39:51 +0800 Wei Wang <wei.w.wang at intel.com> wrote: > > > > > This patch adds support to walk through the free page blocks in the > > > system and report them via a callback function. Some page blocks may > > > leave the free list

On Tue 27-03-18 14:23:51, Wei Wang wrote: > On 03/27/2018 05:22 AM, Andrew Morton wrote: > > On Mon, 26 Mar 2018 10:39:51 +0800 Wei Wang <wei.w.wang at intel.com> wrote: > > > > > This patch adds support to walk through the free page blocks in the > > > system and report them via a callback function. Some page blocks may > > > leave the free list