[jra@samba.org: Re: [PATCH]: Windows BRL Try 2]

[Jeremy Allison]

----- 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
> this:
> 
> * 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 ?

Jeremy.

----- End forwarded message -----