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, lizhen.you@intel.com,
	linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC v2 4/4] fs: Optimize credentials reference count for backing file ops
Date: Fri, 26 Jan 2024 16:25:08 -0800	[thread overview]
Message-ID: <87mssr4o7v.fsf@intel.com> (raw)
In-Reply-To: <CAOQ4uxi7MtVZECGXo-30YWjSU5ZFZP0AQzgBXLyowdOmNUc5DA@mail.gmail.com>

Amir Goldstein <amir73il@gmail.com> writes:

> On Fri, Jan 26, 2024 at 1:57 AM Vinicius Costa Gomes
> <vinicius.gomes@intel.com> wrote:
>>
>> For backing file operations, users are expected to pass credentials
>> that will outlive the backing file common operations.
>>
>> Use the specialized guard statements to override/revert the
>> credentials.
>>
>
> As I wrote before, I prefer to see this patch gets reviewed and merged
> before the overlayfs large patch, so please reorder the series.
>

Sure. Will do.

>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> ---
>>  fs/backing-file.c | 124 ++++++++++++++++++++++------------------------
>>  1 file changed, 60 insertions(+), 64 deletions(-)
>>
>> diff --git a/fs/backing-file.c b/fs/backing-file.c
>> index a681f38d84d8..9874f09f860f 100644
>> --- a/fs/backing-file.c
>> +++ b/fs/backing-file.c
>> @@ -140,7 +140,7 @@ ssize_t backing_file_read_iter(struct file *file, struct iov_iter *iter,
>>                                struct backing_file_ctx *ctx)
>>  {
>>         struct backing_aio *aio = NULL;
>> -       const struct cred *old_cred;
>> +       const struct cred *old_cred = ctx->cred;
>>         ssize_t ret;
>>
>>         if (WARN_ON_ONCE(!(file->f_mode & FMODE_BACKING)))
>> @@ -153,29 +153,28 @@ ssize_t backing_file_read_iter(struct file *file, struct iov_iter *iter,
>>             !(file->f_mode & FMODE_CAN_ODIRECT))
>>                 return -EINVAL;
>>
>> -       old_cred = override_creds(ctx->cred);
>> -       if (is_sync_kiocb(iocb)) {
>> -               rwf_t rwf = iocb_to_rw_flags(flags);
>> +       scoped_guard(cred, old_cred) {
>
> This reads very strage.
>
> Also, I see that e.g. scoped_guard(spinlock_irqsave, ... hides the local var
> used for save/restore of flags inside the macro.
>
> Perhaps you use the same technique for scoped_guard(cred, ..
> loose the local old_cred variable in all those functions and then the
> code will read:
>
> scoped_guard(cred, ctx->cred) {
>
> which is nicer IMO.

Most likely using DEFINE_LOCK_GUARD_1() would allow us to use the nicer version.

>
>> +               if (is_sync_kiocb(iocb)) {
>> +                       rwf_t rwf = iocb_to_rw_flags(flags);
>>
>> -               ret = vfs_iter_read(file, iter, &iocb->ki_pos, rwf);
>> -       } else {
>> -               ret = -ENOMEM;
>> -               aio = kmem_cache_zalloc(backing_aio_cachep, GFP_KERNEL);
>> -               if (!aio)
>> -                       goto out;
>> +                       ret = vfs_iter_read(file, iter, &iocb->ki_pos, rwf);
>> +               } else {
>> +                       ret = -ENOMEM;
>> +                       aio = kmem_cache_zalloc(backing_aio_cachep, GFP_KERNEL);
>> +                       if (!aio)
>> +                               goto out;
>>
>> -               aio->orig_iocb = iocb;
>> -               kiocb_clone(&aio->iocb, iocb, get_file(file));
>> -               aio->iocb.ki_complete = backing_aio_rw_complete;
>> -               refcount_set(&aio->ref, 2);
>> -               ret = vfs_iocb_iter_read(file, &aio->iocb, iter);
>> -               backing_aio_put(aio);
>> -               if (ret != -EIOCBQUEUED)
>> -                       backing_aio_cleanup(aio, ret);
>> +                       aio->orig_iocb = iocb;
>> +                       kiocb_clone(&aio->iocb, iocb, get_file(file));
>> +                       aio->iocb.ki_complete = backing_aio_rw_complete;
>> +                       refcount_set(&aio->ref, 2);
>> +                       ret = vfs_iocb_iter_read(file, &aio->iocb, iter);
>> +                       backing_aio_put(aio);
>> +                       if (ret != -EIOCBQUEUED)
>> +                               backing_aio_cleanup(aio, ret);
>> +               }
>
> if possible, I would rather avoid all this churn in functions that mostly
> do work with the new cred, so either use guard(cred, ) directly or split a
> helper that uses guard(cred, ) form the rest.
>

Yeah, I think what happened is that I tried to keep the scope of the
guard to be as close as possible to override/revert (as you said), and
that caused the churn.

Probably using guard() more will reduce these confusing code changes. I
am going to try that.

> Thanks,
> Amir.


Cheers,
-- 
Vinicius

  reply	other threads:[~2024-01-27  0:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25 23:57 [RFC v2 0/4] overlayfs: Optimize override/revert creds Vinicius Costa Gomes
2024-01-25 23:57 ` [RFC v2 1/4] cleanup: Fix discarded const warning when defining guards Vinicius Costa Gomes
2024-01-26 14:46   ` Amir Goldstein
2024-01-25 23:57 ` [RFC v2 2/4] cred: Add a light version of override/revert_creds() Vinicius Costa Gomes
2024-01-26 14:34   ` Amir Goldstein
2024-01-27  0:16     ` Vinicius Costa Gomes
2024-01-25 23:57 ` [RFC v2 3/4] overlayfs: Optimize credentials usage Vinicius Costa Gomes
2024-01-26 17:22   ` Amir Goldstein
2024-01-27  0:34     ` Vinicius Costa Gomes
2024-01-25 23:57 ` [RFC v2 4/4] fs: Optimize credentials reference count for backing file ops Vinicius Costa Gomes
2024-01-26 14:50   ` Amir Goldstein
2024-01-27  0:25     ` Vinicius Costa Gomes [this message]
2024-01-26 11:40 ` [RFC v2 0/4] overlayfs: Optimize override/revert creds Amir Goldstein
2024-01-27  0:02   ` Vinicius Costa Gomes
  -- strict thread matches above, loose matches on Subject: below --
2024-01-28 12:27 [RFC v2 4/4] fs: Optimize credentials reference count for backing file ops kernel test robot

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=87mssr4o7v.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=lizhen.you@intel.com \
    --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.