Re: question about nfs_execute_read: why do we need to do lock_kernel?
- From: Peter Staubach <staubach@xxxxxxxxxx>
- Date: Tue, 25 Apr 2006 10:37:39 -0400
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/
- Follow-Ups:
- References:
- question about nfs_execute_read: why do we need to do lock_kernel?
- From: Xin Zhao
- Re: question about nfs_execute_read: why do we need to do lock_kernel?
- From: Trond Myklebust
- Re: question about nfs_execute_read: why do we need to do lock_kernel?
- From: Xin Zhao
- question about nfs_execute_read: why do we need to do lock_kernel?
- Prev by Date: RE: C++ pushback
- Next by Date: sd cards : OCR busy?
- Previous by thread: Re: question about nfs_execute_read: why do we need to do lock_kernel?
- Next by thread: Re: question about nfs_execute_read: why do we need to do lock_kernel?
- Index(es):
Relevant Pages
|
|
