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

[Xin Zhao]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/