Messages in this thread | | | Date | Fri, 2 Jun 2006 16:24:36 -0400 | From | Joe Korty <> | Subject | Re: lock_kernel called under spinlock in NFS |
| |
On Thu, Jun 01, 2006 at 04:13:39PM -0400, Trond Myklebust wrote: > On Thu, 2006-06-01 at 15:55 -0400, Joe Korty wrote: >> Tree 5fdccf2354269702f71beb8e0a2942e4167fd992 >> >> [PATCH] vfs: *at functions: core >> >> introduced a bug where lock_kernel() can be called from >> under a spinlock. To trigger the bug one must have >> CONFIG_PREEMPT_BKL=y and be using NFS heavily. It is >> somewhat rare and, so far, haven't traced down the userland >> sequence that causes the fatal path to be taken. >> >> The bug was caused by the insertion into do_path_lookup() >> of a call to file_permission(). do_path_lookup() >> read-locks current->fs->lock for most of its operation. >> file_permission() calls permission() which calls >> nfs_permission(), which has one path through it >> that uses lock_kernel().
> Nowhere should anyone be calling file_permission() under a spinlock. > > Why would you need to read-protect current->fs in the case where you are > starting from a file? The correct thing to do there would appear to be > to read_protect only the cases where (*name=='/') and (dfd == AT_FDCWD). > > Something like the attached patch...
Hi Trond, I've been running with the patch for the last few hours, on an nfs-rooted system, and it has been working fine. Any plans to submit this for 2.6.17?
Thanks!!! Joe - 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/
| |