From: Sargun Dhillon <sargun@sargun.me>
To: Linux Containers <containers@lists.linux.dev>,
LKML <linux-kernel@vger.kernel.org>
Cc: "Kees Cook" <keescook@chromium.org>,
"Christian Brauner" <christian.brauner@ubuntu.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Tycho Andersen" <tycho@tycho.pizza>,
"Giuseppe Scrivano" <gscrivan@redhat.com>,
"Rodrigo Campos" <rodrigo@kinvolk.io>,
"Mauricio Vásquez Bernal" <mauricio@kinvolk.io>
Subject: Preemption Signal Management
Date: Fri, 21 May 2021 09:23:52 -0700 [thread overview]
Message-ID: <CAMp4zn93WRF5u=et=detunN7exhQNoFctr-7Qb8-a9=As8vaQw@mail.gmail.com> (raw)
Andy pointed out that we need a mechanism to determine whether or
notifications are preempted. He suggested we use EPOLLPRI to indicate
whether or not notifications are preempted. My outstanding question is
whether or not we need to be able to get insight of what caused the
preemption, and to which notification.
In the past, Christian has suggested just background polling
notification IDs for validity, which is a fine mechanism to determine
that preemption has occurred. We could raise EPOLLPRI whenever a
notification has changed into the preempted state, but that would
require an O(n) operations across all outstanding notifications to
determine which one was preempted, and in addition, it doesn't give a
lot of information as to why the preemption occurred (fatal signal,
preemption?).
In order to try to break this into small parts, I suggest:
1. We make it so EPOLLPRI is raised (always) on preempted notifications
2. We allow the user to set a flag to "track" notifications. If they
specify this flag, they can then run a "stronger" ioctl -- let's say
SECCOMP_IOCTL_NOTIF_STATUS, which, if the flag was specified upon
receiving the notification will return the current state of the
notification and if a signal preempted it, it will always do that.
---
Alternatively (and this is my preference), we add another filter flag,
like SECCOMP_FILTER_FLAG_NOTIF_PREEMPT, which changes the behaviour
to:
1. Raise EPOLLPRI on preempted notifications
2. All preemption notifications must be cleared via
SECCOMP_IOCTL_NOTIF_RECV_STATUS.
Opinions?
next reply other threads:[~2021-05-21 16:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 16:23 Sargun Dhillon [this message]
2021-05-21 16:39 ` Preemption Signal Management Eric W. Biederman
2021-05-26 0:39 ` Andy Lutomirski
2021-05-26 17:52 ` 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='CAMp4zn93WRF5u=et=detunN7exhQNoFctr-7Qb8-a9=As8vaQw@mail.gmail.com' \
--to=sargun@sargun.me \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux.dev \
--cc=gscrivan@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mauricio@kinvolk.io \
--cc=rodrigo@kinvolk.io \
--cc=tycho@tycho.pizza \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).