On Wed, 23 Jul 2014 20:53:59 -0700
Joe Perches <joe@xxxxxxxxxxx> wrote:
> On Wed, 2014-07-23 at 14:11 -0400, Jeff Layton wrote:
> > On Sun, 20 Jul 2014 11:23:43 -0700 Joe Perches <joe@xxxxxxxxxxx> wrote:
> > > op->info.rv is an s32, but it's only used as a u8.
> > I don't understand this patch. info.rv is s32 (and I assume that "rv"
> > stands for "return value").
>
> In this case it's not a return value but an input.
>
Well, it's an input into the lm_grant callback, but it originally comes
in the downcall from userland (AFAICT). In this case, I'm referring to
the field in the downcall.
> > What I don't get is why you think it's just
> > used as a u8.
>
> Because it's tested only in nlmsvc_grant_deferred
> and nlmsvc_update_deferred_block against 0.
>
> As far as I can tell, it's not possible to set it
> to a negative value.
>
It's been a while since I've looked over the lockd code, but I believe
it's just a flag that indicates whether there is still a conflict
between the block and the lock on the file.
> > It seems to be used more like a bool than anything else,
> > and I'm not sure that "type" is really a good description for it. Maybe
> > it should be a "bool" and named "conflict",
>
> Maybe. But it seemed likely and possible to expand
> it from a single bool to a value.
>
> > given the comments in dlm_posix_get ?
>
> Maybe, though I don't see how the comments relate to
> this change. The rv value returned from that call
> is either -ENOMEM or 0 and is unchanged by this patch.
>
I don't think that patch will break anything. I just don't see it as an
improvement on what's already there.
The rationale for this is lost in antiquity, but I think the basic idea
was that you're either granting or updating the block based on the
_result_ from some check for a lock conflict. While "result" as a name
is a little confusing, "type" is even more so, IMO.
If you're hell-bent on changing this, then my suggestion would be
to turn it into a bool and call it "conflict" or something similar. If
you do decide to do that, adding some helpful kerneldoc comments would
be a nice improvement too.
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> []
> > > @@ -842,7 +842,7 @@ struct lock_manager_operations {
> > > int (*lm_compare_owner)(struct file_lock *fl1, struct file_lock *fl2);
> > > unsigned long (*lm_owner_key)(struct file_lock *fl);
> > > void (*lm_notify)(struct file_lock *fl); /* unblock callback */
> > > - int (*lm_grant)(struct file_lock *fl, int result);
> > > + int (*lm_grant)(struct file_lock *fl, unsigned char type);
> > > void (*lm_break)(struct file_lock *fl);
> > > int (*lm_change)(struct file_lock **fl, int type);
> > > };
>
> I used variable name "type" because that's what
> lm_change uses. No worries if you think a name
> like conflict is better.
>
> The only in-kernel setter of lm_grant is:
>
> fs/lockd/svclock.c: .lm_grant = nlmsvc_grant_deferred,
>
> and for that, I think using a variable name of
> "result" is misleading at best.
>
--
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
