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
prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox