From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: brauner@kernel.org, amir73il@gmail.com, 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 v2 10/16] overlayfs/file: Convert to cred_guard()
Date: Mon, 26 Aug 2024 16:12:52 -0700 [thread overview]
Message-ID: <87v7zmkhe3.fsf@intel.com> (raw)
In-Reply-To: <CAJfpegsq5NruDeL6HRgkpj=QvdOKdnqOwZiRS0VY092=h0RSkg@mail.gmail.com>
Miklos Szeredi <miklos@szeredi.hu> writes:
> On Thu, 22 Aug 2024 at 03:25, Vinicius Costa Gomes
> <vinicius.gomes@intel.com> wrote:
>>
>> Replace the override_creds_light()/revert_creds_light() pairs of
>> operations with cred_guard()/cred_scoped_guard().
>>
>> Only ovl_copyfile() and ovl_fallocate() use cred_scoped_guard(),
>> because of 'goto', which can cause the cleanup flow to run on garbage
>> memory.
>
> This doesn't sound good. Is this a compiler bug or a limitation of guards?
>
This is a gcc bug, that it accepts invalid code: i.e. with a goto you
can skip the declaration of a variable and as the cleanup is inserted by
the compiler unconditionally, the cleanup will run with garbage value.
clang refuses to compile and emits an error.
Link to a simpler version of the bug I am seeing:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
>> @@ -211,9 +208,8 @@ static loff_t ovl_llseek(struct file *file, loff_t offset, int whence)
>> ovl_inode_lock(inode);
>> real.file->f_pos = file->f_pos;
>>
>> - old_cred = ovl_override_creds_light(inode->i_sb);
>> + cred_guard(ovl_creds(inode->i_sb));
>> ret = vfs_llseek(real.file, offset, whence);
>> - revert_creds_light(old_cred);
>
> Why not use scoped guard, like in fallocate?
No reason. I was only under the impression that cred_guard() was
preferred over cred_scoped_guard().
>
>> @@ -398,9 +393,8 @@ static int ovl_fsync(struct file *file, loff_t start, loff_t end, int datasync)
>>
>> /* Don't sync lower file for fear of receiving EROFS error */
>> if (file_inode(real.file) == ovl_inode_upper(file_inode(file))) {
>> - old_cred = ovl_override_creds_light(file_inode(file)->i_sb);
>> + cred_guard(ovl_creds(file_inode(file)->i_sb));
>> ret = vfs_fsync_range(real.file, start, end, datasync);
>> - revert_creds_light(old_cred);
>
> Same here.
>
Will keep it consistent whatever version is chosen.
>> @@ -584,9 +571,8 @@ static int ovl_flush(struct file *file, fl_owner_t id)
>> return err;
>>
>> if (real.file->f_op->flush) {
>> - old_cred = ovl_override_creds_light(file_inode(file)->i_sb);
>> + cred_guard(ovl_creds(file_inode(file)->i_sb));
>
> What's the scope of this? The function or the inner block?
>
As far as I understand, the inner block.
> Thanks,
> Miklos
Cheers,
--
Vinicius
next prev parent reply other threads:[~2024-08-26 23:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 1:25 [PATCH v2 00/16] overlayfs: Optimize override/revert creds Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 01/16] cred: Add a light version of override/revert_creds() Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 02/16] fs/backing-file: Convert to revert/override_creds_light() Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 03/16] fs/overlayfs: Introduce ovl_override_creds_light() Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 04/16] overlayfs: Document critical override_creds() operations Vinicius Costa Gomes
2024-08-22 8:14 ` Miklos Szeredi
2024-08-26 22:48 ` Vinicius Costa Gomes
2024-09-24 21:13 ` Vinicius Costa Gomes
2024-09-25 9:57 ` Christian Brauner
2024-09-25 14:17 ` Vinicius Costa Gomes
2024-10-07 11:12 ` Amir Goldstein
2024-10-07 16:13 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 05/16] overlayfs: Use ovl_override_creds_light()/revert_creds_light() Vinicius Costa Gomes
2024-08-22 8:26 ` Miklos Szeredi
2024-08-26 22:57 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 06/16] cred: Introduce cred_guard() and cred_scoped_guard() helpers Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 07/16] fs/backing-file: Convert to cred_guard() Vinicius Costa Gomes
2024-08-22 8:31 ` Miklos Szeredi
2024-08-26 22:58 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 08/16] overlayfs/copy_up: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 09/16] overlayfs/dir: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 10/16] overlayfs/file: " Vinicius Costa Gomes
2024-08-22 8:41 ` Miklos Szeredi
2024-08-26 23:12 ` Vinicius Costa Gomes [this message]
2024-08-22 11:06 ` Amir Goldstein
2024-08-26 23:18 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 11/16] overlayfs/inode: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 12/16] overlayfs/namei: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 13/16] overlayfs/readdir: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 14/16] overlayfs/xattrs: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 15/16] overlayfs/util: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 16/16] overlayfs: Remove ovl_override_creds_light() Vinicius Costa Gomes
2024-08-22 8:59 ` Miklos Szeredi
2024-08-26 23:21 ` Vinicius Costa Gomes
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=87v7zmkhe3.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;
as well as URLs for NNTP newsgroup(s).