From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: zohar@linux.ibm.com, roberto.sassu@huawei.com,
paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] evm: stop avoidably reading i_writecount in evm_file_release
Date: Tue, 24 Sep 2024 13:56:23 +0200 [thread overview]
Message-ID: <d31e3e0e9e35523bb40b5dbbb29790c874e7627d.camel@huaweicloud.com> (raw)
In-Reply-To: <CAGudoHGBTRJqKAE6Db3PyVne6rrJR4vsF2MNH2qKMy-44XReZw@mail.gmail.com>
On Mon, 2024-09-23 at 07:26 +0200, Mateusz Guzik wrote:
> On Fri, Aug 16, 2024 at 1:53 PM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> >
> > On Tue, 2024-08-06 at 15:36 +0200, Mateusz Guzik wrote:
> > > The EVM_NEW_FILE flag is unset if the file already existed at the time
> > > of open and this can be checked without looking at i_writecount.
> >
> > Agreed. EVM_NEW_FILE is not going to be set during the open(), only
> > before, in evm_post_path_mknod().
> >
> > Looks good to me.
> >
> > Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
> >
> > Thanks
>
> thanks for the review
>
> are there plans to pick this up for this merge window?
Welcome! Sorry, Mimi wants to do few more checks. It is more likely
that we will pick this for the next version.
Roberto
> >
> > Roberto
> >
> > > Not accessing it reduces traffic on the cacheline during parallel open
> > > of the same file and drop the evm_file_release routine from second place
> > > to bottom of the profile.
> > >
> > > Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
> > > ---
> > >
> > > The context is that I'm writing a patch which removes one lockref
> > > get/put cycle on parallel open. An operational WIP reduces ping-pong in
> > > that area and made do_dentry_open skyrocket along with evm_file_release,
> > > due to i_writecount access. With the patch they go down again and
> > > apparmor takes the rightful first place.
> > >
> > > The patch accounts for about 5% speed up at 20 cores running open3 from
> > > will-it-scale on top of the above wip. (the apparmor + lockref thing
> > > really don't scale, that's next)
> > >
> > > I would provide better measurements, but the wip is not ready (as the
> > > description suggests) and I need evm out of the way for the actual
> > > patch.
> > >
> > > security/integrity/evm/evm_main.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
> > > index 62fe66dd53ce..309630f319e2 100644
> > > --- a/security/integrity/evm/evm_main.c
> > > +++ b/security/integrity/evm/evm_main.c
> > > @@ -1084,7 +1084,8 @@ static void evm_file_release(struct file *file)
> > > if (!S_ISREG(inode->i_mode) || !(mode & FMODE_WRITE))
> > > return;
> > >
> > > - if (iint && atomic_read(&inode->i_writecount) == 1)
> > > + if (iint && iint->flags & EVM_NEW_FILE &&
> > > + atomic_read(&inode->i_writecount) == 1)
> > > iint->flags &= ~EVM_NEW_FILE;
> > > }
> > >
> >
>
>
next prev parent reply other threads:[~2024-09-24 11:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 13:36 [PATCH] evm: stop avoidably reading i_writecount in evm_file_release Mateusz Guzik
2024-08-16 11:53 ` Roberto Sassu
2024-09-23 5:26 ` Mateusz Guzik
2024-09-24 11:56 ` Roberto Sassu [this message]
2024-10-10 3:00 ` Mimi Zohar
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=d31e3e0e9e35523bb40b5dbbb29790c874e7627d.camel@huaweicloud.com \
--to=roberto.sassu@huaweicloud.com \
--cc=jmorris@namei.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.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).