Messages in this thread | | | Date | Thu, 29 Apr 2004 01:53:35 +0100 | From | viro@parcelfa ... | Subject | Re: BUG: might_sleep in /proc/swaps code |
| |
On Wed, Apr 28, 2004 at 04:24:58PM -0700, Tim Hockin wrote: > * /proc/swaps uses seq_file code, calling seq_path() with swaplock held > * seq_path() calls d_path() > * d_path() calls mntput() which might_sleep() > > Is this worth trying to solve?
Hrm... Yes, it is - we could have chroot(2) called from another thread while traversing the path to current root and have e.g. umount -l trigger final umount when d_path() is finished.
Note that we have another blocking function called there anyway - dput() will happily block under similar conditions (s/umount -l/rm/).
Lovely... So we need yet another semaphore in swapfile.c (we can't turn swaplock into semaphore *and* can't reuse swaps_bdev_sem, since dput() et.al. are not just blocking but can cause any IO and memory allocations).
I'll try to put together something not too revolting; will post the patch in a followup... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |