On Wed, Dec 06, 2006 at 02:57:22PM -0500, J. Bruce Fields wrote:
> On Wed, Dec 06, 2006 at 09:49:51AM -0600, David Teigland wrote:
> > The gfs side looks fine to me.  Did you forget to call fl_notify from
> > gdlm_plock_callback() or am I missing something?
> 
> Yes, looks like we missed something, thanks.  This code's an rfc (not
> even tested), so don't apply it yet!  What we should have there is
> something like:
> 
>       rv = op->info.rv;
> 
>       if (fl_notify(fl, NULL, rv)) {
>               /* XXX: We need to cancel the lock here: */
>               printk("gfs2 lock granted after lock request failed; dangling 
> lock!\n");
>       }
> 
>       if (!rv) {
>               /* check if the following are still valid or make a copy */
>               file = op->info.file;
>               fl = op->info.fl;
>               
>               if (posix_lock_file_wait(file, fl) < 0)
>                       log_error("gdlm_plock: vfs lock error file %p fl %p",
>                                 file, fl);
>       }
> 
> Note there's a race condition--that calls fl_notify before actually
> getting the lock locally.  I don't *think* that's a problem, as long as
> it's the filesystem and not the local lock list that's authoritative
> when it comes to who gets a posix lock.

agree

> The more annoying problem is the need to cancel the GFS lock when
> fl_notify fails; is that something that it's possible for GFS to do?
> 
> It can fail because lockd has a timeout--it waits a few seconds for the
> callback, then gives up and returns a failure to the user.  If that
> happens after your userspace posix lock manager acquires the lock (but
> before fl_notify is called) then you've got to cancel it somehow.

I'd think we could just send an unlock for it at that point.  Set up an op
with GDLM_PLOCK_OP_UNLOCK and the same fields as the lock you're removing
and call send_op().  We probably need to flag this internal-unlock op so
that when the result arrives, device_write() delists and frees it itself.

(I wouldn't call this "canceling", I think of cancel as trying to force a
blocked request to return/fail prematurely.)

Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to