All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrei Vagin <avagin@google.com>
Cc: Kees Cook <keescook@chromium.org>,
	Tycho Andersen <tandersen@netflix.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Will Drewry <wad@chromium.org>, Jens Axboe <axboe@kernel.dk>,
	Christian Brauner <brauner@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] seccomp: release task filters when the task exits
Date: Wed, 22 May 2024 12:35:51 +0200	[thread overview]
Message-ID: <20240522103531.GA28435@redhat.com> (raw)
In-Reply-To: <CAEWA0a6Z+jGKtz1Bdc2tP4YwR6u1zeEhoYY1hYZqdxCZMcgjcg@mail.gmail.com>

On 05/22, Andrei Vagin wrote:
>
> > On Thu, May 16, 2024 at 6:10 AM Oleg Nesterov <oleg@redhat.com> wrote:
> > >
> > > On 05/16, Oleg Nesterov wrote:
> > > >
> > > > On 05/15, Andrei Vagin wrote:
> > > > >
> > > > > seccomp_sync_threads and seccomp_can_sync_threads should be considered too.
> > > >
> > > > Yes. But we only need to consider them in the multi-thread case, right?
> > > > In this case exit_signals() sets PF_EXITING under ->siglock, so they can't
> > > > miss this flag, seccomp_filter_release() doesn't need to take siglock.
> > >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> PF_EXITING is set without holding ->siglock if tsk->signal has the
> SIGNAL_GROUP_EXIT flag. I think it can be a case when one thread is in
> seccomp_sync_threads and others are exiting.

Yes, I forgot this.

> > > Hmm. I thought we have something smp_mb__after_unlock(), but it seems we
> > > don't. So we can't add a fast-path
>
> We have smp_mb__after_unlock_lock in include/linux/rcupdate.h.

This is another thing.

But sorry for confusion, this doesn't really matter, we could you a plain mb().
I mean, I was thinking about something like

	seccomp_filter_release:

		smp_mb();
		if (!READ_ONCE(tsk->seccomp.filter))
			return;

		spin_lock_irq(siglock);
		orig = tsk->seccomp.filter;
		...

but then seccomp_sync_threads() should do something like


		orig = READ_ONCE(thread->seccomp.filter);

		smp_store_release(&thread->seccomp.filter,
				  caller->seccomp.filter);

		smp_mb(); // pairs with mb() in seccomp_filter_release()

		if (READ_ONCE(thread->flags) & PF_EXITING) {
			WRITE_ONCE(thread->seccomp.filter, orig);
			continue;
		}
		__seccomp_filter_release(orig);

		...

too subtle even _if_ correct, and I am not sure at all this would be correct.

> > > Cough... Now that I look at seccomp_can_sync_threads() I think it too
> > > doesn't need the PF_EXITING check.
> > >
> > > If it is called before seccomp_filter_release(), this doesn't really
> > > differ from the case when it is called before do_exit/exit_signals.
> > >
> > > If it is called after seccomp_filter_release(), then is_ancestor()
> > > must be true.
> > >
> > > But perhaps I missed something, I won't insist, up to you.
> > >
>
> You are right, this check isn't required in seccomp_can_sync_threads, but
> I decided that it is better to be consistent with seccomp_sync_threads.

OK, agreed.

Oleg.


  reply	other threads:[~2024-05-22 10:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240514175551.297237-1-avagin@google.com>
     [not found] ` <20240514175551.297237-3-avagin@google.com>
     [not found]   ` <20240515125113.GC6821@redhat.com>
     [not found]     ` <CAEWA0a5dBvRwGAnztL56i=JV-WGGiaTd-GdJYdOxZmq1c+bdpg@mail.gmail.com>
2024-05-16  9:34       ` [PATCH 2/3] seccomp: release task filters when the task exits Oleg Nesterov
2024-05-16 13:09         ` Oleg Nesterov
2024-05-22  6:49           ` Andrei Vagin
2024-05-22  7:06             ` Andrei Vagin
2024-05-22 10:35               ` Oleg Nesterov [this message]
2024-05-23  1:45 [PATCH 0/3 v2] seccomp: improve handling of SECCOMP_IOCTL_NOTIF_RECV Andrei Vagin
2024-05-23  1:45 ` [PATCH 2/3] seccomp: release task filters when the task exits Andrei Vagin
2024-05-23  9:00   ` Oleg Nesterov
2024-06-26 18:57   ` Kees Cook

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=20240522103531.GA28435@redhat.com \
    --to=oleg@redhat.com \
    --cc=avagin@google.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=tandersen@netflix.com \
    --cc=wad@chromium.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.