[email@example.com: Re: [PATCH]: Windows BRL Try 2]
jra at samba.org
Wed Feb 18 17:40:53 MST 2009
----- Forwarded message from Jeremy Allison <jra at samba.org> -----
From: Jeremy Allison <jra at samba.org>
To: Zack Kirsch <zack.kirsch at isilon.com>
Cc: Jeremy Allison <jra at samba.org>
Subject: Re: [PATCH]: Windows BRL Try 2
Reply-To: Jeremy Allison <jra at samba.org>
On Fri, Feb 13, 2009 at 11:42:12AM -0800, Zack Kirsch wrote:
> Thanks Jeremy!
> While I've got you thinking about the BRL path, how would you feel about
> * A new BRL_LOCK_WINDOWS_ASYNC call, which would be called with the
> PENDING lock type. In the lockingX case, the logic used to decide
> whether or not to call push_blocking_lock_request() is very complicated.
> Ideally, I'd like to call BRL_LOCK_WINDOWS_ASYNC if we're going okay
> with performing an asynchronous request, but call BRL_LOCK_WINDOWS if
> we're not. Do you have any ideas of how we could rectify the complicated
> lockingX logic in with this?
> Let me know if I need to explain this more - I'm in the middle of
> tracing down a kernel panic. :)
What exactly do you mean by complicated lockingX logic ?
Currently we're calling do_lock and if that fails with
LOCK_DENIED or LOCK_CONFLICT and timeout > 0 we do
the queuing thing. I like your idea of separating
out the two cases into VFS calls, but can't we just
move the spin logic into the BRL_LOCK_WINDOWS_ASYNC case ?
----- End forwarded message -----
More information about the samba-technical