Re: question about nfs_execute_read: why do we need to do lock_kernel?

["Xin Zhao" <uszhaoxin@gmail.com>]

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
>