[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20231026051313.GA15694@google.com>
Date: Thu, 26 Oct 2023 14:13:13 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: John Johansen <john.johansen@...onical.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Anil Altinay <aaltinay@...gle.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
LKLM <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Tomasz Figa <tfiga@...omium.org>,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH v5 0/4] apparmor: cache buffers on percpu list if there
is lock, contention
On (23/10/17 02:21), John Johansen wrote:
> > > yeah, testing help is always much appreciated. I have a v4, and I am
> > > working on 3 alternate version to compare against, to help give a better
> > > sense if we can get away with simplifying or tweak the scaling.
> > >
> > > I should be able to post them out some time tonight.
> >
> > Hi John,
> >
> > Did you get a chance to post v4? I may be able to give it some testing
> > on our real-life case.
>
> sorry yes, how about a v5. That is simplified with 3 follow on patches
> that aren't strictly necessary, but some combination of them might be
> better than just the base patch, but splitting them out makes the
> individual changes easier to review.
Sorry for late reply. So I gave it a try but, apparently, our build
environment has changed quite significantly since the last time I
looked into it.
I don't see that many aa_get/put_buffer() anymore. apparmor buffer
functions are mostly called form the exec path:
security_bprm_creds_for_exec()
apparmor_bprm_creds_for_exec()
make_vfsuid()
aa_get_buffer()
As for vfs_statx()->...->apparmor_inode_getattr()->aa_path_perm(),
that path is bpf_lsm_inode_getsecid() now.
Powered by blists - more mailing lists