Re: [PATCH 9/9] fs: dlm: lockd: Convert int result to unsigned char type

[Jeff Layton]

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-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/