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, hu1.chen@intel.com, miklos@szeredi.hu,
	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 overlayfs-next v3 0/4] overlayfs: Optimize override/revert creds
Date: Tue, 05 Nov 2024 14:27:13 -0800	[thread overview]
Message-ID: <871pzpqptq.fsf@intel.com> (raw)
In-Reply-To: <CAOQ4uxiaRE_cQ9m9LZMEiDCeSQKkZDfsJbpt85ds6hgvjnwHUQ@mail.gmail.com>

Hi,

Amir Goldstein <amir73il@gmail.com> writes:

> On Tue, Nov 5, 2024 at 8:35 PM Vinicius Costa Gomes
> <vinicius.gomes@intel.com> wrote:
>>
>> Hi,
>>
>> This series is rebased on top of Amir's overlayfs-next branch.
>>
>> Changes from v2:
>>  - Removed the "convert to guard()/scoped_guard()" patches (Miklos Szeredi);
>>  - In the overlayfs code, convert all users of override_creds()/revert_creds() to the _light() versions by:
>>       1. making ovl_override_creds() use override_creds_light();
>>       2. introduce ovl_revert_creds() which calls revert_creds_light();
>>       3. convert revert_creds() to ovl_revert_creds()
>>    (Amir Goldstein);
>>  - Fix an potential reference counting issue, as the lifetime
>>    expectations of the mounter credentials are different (Christian
>>    Brauner);
>>
>
> Hi Vicius,
>
> The end result looks good to me, but we still need to do the series a
> bit differently.
>
>> The series is now much simpler:
>>
>> Patch 1: Introduce the _light() version of the override/revert cred operations;
>> Patch 2: Convert backing-file.c to use those;
>> Patch 3: Do the conversion to use the _light() version internally;
>
> This patch mixes a small logic change and a large mechanical change
> that is not a good mix.
>
> I took the liberty to split out the large mechanical change to
> ovl: use wrapper ovl_revert_creds()
> and pushed it to branch
> https://github.com/amir73il/linux/commits/ovl_creds
>
> I then rebased overlayfs-next over this commit and resolved the
> conflicts with the pure mechanical change.
>
> Now you can rebase your patches over ovl_creds and they should
> not be conflicting with overlayfs-next changes.
>
> The reason I wanted to do this is that Christian could take your changes
> as well as my ovl_creds branch through the vfs tree if he chooses to do so.
>

Makes sense.

>> Patch 4: Fix a potential refcounting issue
>
> This patch cannot be separated from patch #3 because it would introduce the
> refcount leak mid series.
>
> But after I took out all the mechanical changes out of patch #3,
> there should be no problem for you to squash patches #3 and #4 together.
>

Done. 

> One more nit: please use "ovl: ..." for commit titles instead of
> "fs/overlayfs: ...".
>

Also done. Will give the series a round of testing, just to be sure, and
will send the next version tomorrow.

> Thanks,
> Amir.


Cheers,
-- 
Vinicius

      reply	other threads:[~2024-11-05 22:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-05 19:35 [PATCH overlayfs-next v3 0/4] overlayfs: Optimize override/revert creds Vinicius Costa Gomes
2024-11-05 19:35 ` [PATCH overlayfs-next v3 1/4] cred: Add a light version of override/revert_creds() Vinicius Costa Gomes
2024-11-06 18:56   ` kernel test robot
2024-11-05 19:35 ` [PATCH overlayfs-next v3 2/4] fs/backing-file: Convert to revert/override_creds_light() Vinicius Costa Gomes
2024-11-05 19:35 ` [PATCH overlayfs-next v3 3/4] fs/overlayfs: Optimize override/revert creds Vinicius Costa Gomes
2024-11-05 19:35 ` [PATCH overlayfs-next v3 4/4] fs/overlayfs: Drop creds usage decrement for ovl_setup_for_create() Vinicius Costa Gomes
2024-11-05 20:47 ` [PATCH overlayfs-next v3 0/4] overlayfs: Optimize override/revert creds Amir Goldstein
2024-11-05 22:27   ` Vinicius Costa Gomes [this message]

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=871pzpqptq.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.