Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 25 Apr 2006 11:31:57 -0400 | From | "Xin Zhao" <> | Subject | Re: question about nfs_execute_read: why do we need to do lock_kernel? |
| |
Thanks for your guys' reply!
Peter, can you point me somewhere I can check the semantics of BKL? In the past, I remembered BKL does block the kernel. So I am quite confused now.
Also, I still don't understand why we use lock_kernel instead of some finer granularity lock. Trond's answer gave me a feeling that this is simply because the code is not carefully optimized. :)
-x
On 4/25/06, Peter Staubach <staubach@redhat.com> wrote: > Xin Zhao wrote: > > >Thanks for your reply. So the only reason is for rpc auditing? If so, > >why not just lock the code that updating the audit information? Now > >the code is: > > > >lock_kernel() > >rpc_execute() > >unlock_kernel(). > > > >That means the kernel will be blocked when rpc is executed, which > >could take long time. Even if rpc_execute() won't take very long, this > >implementation still looks inefficient. That's why I am a little > >confused on this point. > > > >Any further thought? > > > > I would suggest looking at the semantics of the BKL. They don't end up > implying what you are suggesting. The kernel isn't really locked for > the duration of the over the wire RPC. > > Thanx... > > ps > - 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/
| ![\](/images/icornerr.gif) |