Re: [PATCH 0/2] proc: protect ptrace_may_access() with exec_update_lock

[Christian Brauner]

On Wed, May 27, 2026 at 03:44:17PM +0200, Jann Horn wrote:
> On Wed, May 27, 2026 at 2:01 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> > On Tue, May 26, 2026 at 08:22:38PM +0200, Jann Horn wrote:
> > > On Mon, May 25, 2026 at 9:56 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
> > > > Question 4.
> > > > Is it possible to use a seq_lock instead of reader writer semaphore?
> > > > Or is that only for non-sleeping readers?
> > >
> > > Linux seqcounts are 32-bit, which means they are always kind of dodgy,
> > > but they are particularly dodgy if a reader can be forced to sleep for
> > > an extended amount of time. I don't see a reason why we couldn't, in
> > > general, use a 64-bit sequence count for readers that may need to
> > > sleep while reading.
> >
> > I have a patch series for this that I started working after merging your
> > series for precisely this reason: performance. It's a few days old now.
> > I've tried various approaches and I started with a simple 32-bit counter
> > as the POC. See appended (untested) patches.
> 
> It looks like there is a missing patch at the start of the series,
> patch 1 uses exec_update_seq_begin without defining it.

Yes. I was mainly worried about changing performance characteristics if
we start using the lock in more cases.