All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: brauner@kernel.org, miklos@szeredi.hu, hu1.chen@intel.com,
	malini.bhandaru@intel.com, tim.c.chen@intel.com,
	mikko.ylinen@intel.com, linux-unionfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/4] ovl: Optimize override/revert creds
Date: Thu, 14 Nov 2024 13:01:18 -0800	[thread overview]
Message-ID: <87h689sf6p.fsf@intel.com> (raw)
In-Reply-To: <CAOQ4uxiXt4Y=fP+nUfbKkf46of4em633Dmd+iUCFyB=5ijvHdw@mail.gmail.com>

Amir Goldstein <amir73il@gmail.com> writes:

> On Thu, Nov 14, 2024 at 9:56 AM Amir Goldstein <amir73il@gmail.com> wrote:
>>
>> On Wed, Nov 13, 2024 at 8:30 PM Vinicius Costa Gomes
>> <vinicius.gomes@intel.com> wrote:
>> >
>> > Amir Goldstein <amir73il@gmail.com> writes:
>> >
>> > > On Thu, Nov 7, 2024 at 1:57 AM Vinicius Costa Gomes
>> > > <vinicius.gomes@intel.com> wrote:
>> >
>> > [...]
>> >
>> > >
>> > > Vinicius,
>> > >
>> > > While testing fanotify with LTP tests (some are using overlayfs),
>> > > kmemleak consistently reports the problems below.
>> > >
>> > > Can you see the bug, because I don't see it.
>> > > Maybe it is a false positive...
>> >
>> > Hm, if the leak wasn't there before and we didn't touch anything related to
>> > prepare_creds(), I think that points to the leak being real.
>> >
>> > But I see your point, still not seeing it.
>> >
>> > This code should be equivalent to the code we have now (just boot
>> > tested):
>> >
>> > ----
>> > diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
>> > index 136a2c7fb9e5..7ebc2fd3097a 100644
>> > --- a/fs/overlayfs/dir.c
>> > +++ b/fs/overlayfs/dir.c
>> > @@ -576,8 +576,7 @@ static int ovl_setup_cred_for_create(struct dentry *dentry, struct inode *inode,
>> >          * We must be called with creator creds already, otherwise we risk
>> >          * leaking creds.
>> >          */
>> > -       WARN_ON_ONCE(override_creds(override_cred) != ovl_creds(dentry->d_sb));
>> > -       put_cred(override_cred);
>> > +       WARN_ON_ONCE(override_creds_light(override_cred) != ovl_creds(dentry->d_sb));
>> >
>> >         return 0;
>> >  }
>> > ----
>> >
>> > Does it change anything? (I wouldn't think so, just to try something)
>>
>> No, but I think this does:
>>
>
> Vinicius,
>
> Sorry, your fix is correct. I did not apply it properly when I tested.
>
> I edited the comment as follows and applied on top of the patch
> that I just sent [1]:
>

I just noticed there's a typo in the first sentence of the commit
message, the function name that we are using revert_creds_light() is
ovl_revert_creds(). Could you fix that while you are at it?

Glad that the fix works:

Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>

>
> -       put_cred(override_creds(override_cred));
> +
> +       /*
> +        * Caller is going to match this with revert_creds_light() and drop
> +        * reference on the returned creds.
> +        * We must be called with creator creds already, otherwise we risk
> +        * leaking creds.
> +        */
> +       old_cred = override_creds_light(override_cred);
> +       WARN_ON_ONCE(old_cred != ovl_creds(dentry->d_sb));
>
>         return override_cred;
>
> Thanks,
> Amir.
>
> [1] https://lore.kernel.org/linux-unionfs/20241114100536.628162-1-amir73il@gmail.com/

-- 
Vinicius

  reply	other threads:[~2024-11-14 21:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07  0:57 [PATCH v4 0/4] overlayfs: Optimize override/revert creds Vinicius Costa Gomes
2024-11-07  0:57 ` [PATCH v4 1/4] cred: Add a light version of override/revert_creds() Vinicius Costa Gomes
2024-11-07  0:57 ` [PATCH v4 2/4] fs/backing-file: Convert to revert/override_creds_light() Vinicius Costa Gomes
2024-11-07  0:57 ` [PATCH v4 3/4] ovl: use wrapper ovl_revert_creds() Vinicius Costa Gomes
2024-11-07  0:57 ` [PATCH v4 4/4] ovl: Optimize override/revert creds Vinicius Costa Gomes
2024-11-13 14:26   ` Amir Goldstein
2024-11-13 19:30     ` Vinicius Costa Gomes
2024-11-14  8:56       ` Amir Goldstein
2024-11-14  9:17         ` Amir Goldstein
2024-11-14 11:01         ` Amir Goldstein
2024-11-14 21:01           ` Vinicius Costa Gomes [this message]
2024-11-15  8:16             ` Amir Goldstein
2024-11-07 10:19 ` [PATCH v4 0/4] overlayfs: " Amir Goldstein
2024-11-08 16:57   ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h689sf6p.fsf@intel.com \
    --to=vinicius.gomes@intel.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=hu1.chen@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=malini.bhandaru@intel.com \
    --cc=mikko.ylinen@intel.com \
    --cc=miklos@szeredi.hu \
    --cc=tim.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.