From: Christian Brauner <brauner@kernel.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
Linux Memory Management List <linux-mm@kvack.org>,
linux-kernel@vger.kernel.org, ying.huang@intel.com,
feng.tang@intel.com, fengwei.yin@intel.com
Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression
Date: Wed, 3 Jul 2024 16:08:56 +0200 [thread overview]
Message-ID: <20240703-haftstrafe-anbringen-88ed445e77a4@brauner> (raw)
In-Reply-To: <du5vnvwygzbtal6qogmxckawwwxgbppuq5qi5aeqcs5unrlpz3@3k5degdvflzq>
> As a side note this is where I should also note the *current* LSM hooks
> are racy as is. Suppose you can stat a particular file now, but a chown
> to 1234 means you can't. Then your stat call can race against chown +
> other ops. You can end up in a state where LSMs gave a green light and
> only then the state changed to one you are not allowed to look at. This
Fwiw, we've discussed this before. And my opinion is that we should
absolute not care about this. I have no interest in complicating path
lookup or any codepath to make these hooks less racy. This raciness they
have to deal with. This is not a comment on your patch but just that the
raciness of security hooks is not a problem we should care to solve
imho. If we go down that road we'll all slowly go insane trying to give
state change guarantees to layers that hook into the VFS in really odd
locations.
next prev parent reply other threads:[~2024-07-03 14:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-27 2:41 kernel test robot
2024-06-27 6:25 ` Mateusz Guzik
2024-06-27 7:00 ` Mateusz Guzik
2024-06-27 16:32 ` Linus Torvalds
2024-06-27 16:55 ` Mateusz Guzik
2024-06-27 16:57 ` Linus Torvalds
2024-06-27 17:20 ` Mateusz Guzik
2024-06-27 17:23 ` Linus Torvalds
2024-07-02 7:19 ` Mateusz Guzik
2024-07-02 12:10 ` Mateusz Guzik
2024-07-02 16:47 ` Linus Torvalds
2024-07-02 17:02 ` Mateusz Guzik
2024-07-02 17:28 ` Linus Torvalds
2024-07-02 17:46 ` Mateusz Guzik
2024-07-02 17:58 ` Mateusz Guzik
2024-07-02 18:41 ` Linus Torvalds
2024-07-02 20:33 ` Mateusz Guzik
2024-07-02 20:42 ` Linus Torvalds
2024-07-02 21:15 ` Mateusz Guzik
2024-07-02 22:14 ` Linus Torvalds
2024-07-03 13:53 ` Mateusz Guzik
2024-07-03 14:08 ` Christian Brauner [this message]
2024-07-03 14:11 ` Mateusz Guzik
2024-07-03 16:47 ` Linus Torvalds
2024-07-03 8:34 ` Christian Brauner
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=20240703-haftstrafe-anbringen-88ed445e77a4@brauner \
--to=brauner@kernel.org \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=mjguzik@gmail.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=ying.huang@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