[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YTc4ClL0EwuHsPXP@google.com>
Date: Tue, 7 Sep 2021 18:59:38 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Dan Carpenter <dan.carpenter@...cle.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Namjae Jeon <linkinjeon@...nel.org>,
Steve French <sfrench@...ba.org>,
Hyunchul Lee <hyc.lee@...il.com>, linux-cifs@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] ksmbd: remove unnecessary conditions
On (21/09/07 12:14), Dan Carpenter wrote:
[..]
> > > >
> > > > Can make_kuid() return INVALID_UID? IOW, uid_valid(uid) here as well?
> > >
> > > No need to check twice. We're going to check at the end.
> > >
> > > >
> > > > > +
> > > > > + /* If this is an idmapped mount, apply the idmapping. */
> > > > > + uid = kuid_from_mnt(user_ns, uid);
> > > > > + if (uid_valid(uid)) {
> > > ^^^^^^^^^^^^^^
> > > The check here is sufficient.
> >
> > My point was more that a potentially invalid UID is passed to kuid_from_mnt()
> > and kgid_from_mnt(). I don't see map_id_up(), for example, checking that
> > passed UID is valid. So decided to double check.
>
> But you've seen it now, right?
A linear search in array of 5 elements or a binary search in array of 340
elements? Yea, I saw it. I'd prefer one extra uid_valid(), if you'd ask
me - why call the function if we already know that it'll fail.
Powered by blists - more mailing lists