From: "Paul E. McKenney" <paulmck@kernel.org> To: Nicolas Saenz Julienne <nsaenzju@redhat.com> Cc: tglx@linutronix.de, mark.rutland@arm.com, rostedt@goodmis.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, rcu@vger.kernel.org, peterz@infradead.org, mtosatti@redhat.com, frederic@kernel.org, corbet@lwn.net Subject: Re: [PATCH v4 2/2] Documentation: core-api: entry: Add comments about nesting Date: Mon, 10 Jan 2022 10:01:26 -0800 [thread overview] Message-ID: <20220110180126.GF947480@paulmck-ThinkPad-P17-Gen-1> (raw) In-Reply-To: <20220110105044.94423-2-nsaenzju@redhat.com> On Mon, Jan 10, 2022 at 11:50:44AM +0100, Nicolas Saenz Julienne wrote: > The topic of nesting and reentrancy in the context of early entry code > hasn't been addressed so far. So do it. > > Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> > --- > > Changes since v3: > - Introduce Paul's rewording suggestions > > Documentation/core-api/entry.rst | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/Documentation/core-api/entry.rst b/Documentation/core-api/entry.rst > index c6f8e22c88fe..e12f22ab33c7 100644 > --- a/Documentation/core-api/entry.rst > +++ b/Documentation/core-api/entry.rst > @@ -105,6 +105,8 @@ has to do extra work between the various steps. In such cases it has to > ensure that enter_from_user_mode() is called first on entry and > exit_to_user_mode() is called last on exit. > > +Do not nest syscalls. Nested systcalls will cause RCU and/or context tracking > +to print a warning. > > KVM > --- > @@ -121,6 +123,8 @@ Task work handling is done separately for guest at the boundary of the > vcpu_run() loop via xfer_to_guest_mode_handle_work() which is a subset of > the work handled on return to user space. > > +Do not nest KVM entry/exit transitions because doing so is nonsensical. > + > Interrupts and regular exceptions > --------------------------------- > > @@ -180,6 +184,16 @@ before it handles soft interrupts, whose handlers must run in BH context rather > than irq-disabled context. In addition, irqentry_exit() might schedule, which > also requires that HARDIRQ_OFFSET has been removed from the preemption count. > > +Even though interrupt handlers are expected to run with local interrupts > +disabled, interrupt nesting is common from an entry/exit perspective. For > +example, softirq handling happens within an irqentry_{enter,exit}() block with > +local interrupts enabled. Also, although uncommon, nothing prevents an > +interrupt handler from re-enabling interrupts. > + > +Interrupt entry/exit code doesn't strictly need to handle reentrancy, since it > +runs with local interrupts disabled. But NMIs can happen anytime, and a lot of > +the entry code is shared between the two. > + > NMI and NMI-like exceptions > --------------------------- > > @@ -259,3 +273,7 @@ and for e.g. a debug exception it can look like this: > > There is no combined irqentry_nmi_if_kernel() function available as the > above cannot be handled in an exception-agnostic way. > + > +NMIs can happen in any context. For example, an NMI-like exception triggered > +while handling an NMI. So NMI entry code has to be reentrant and state updates > +need to handle nesting. > -- > 2.34.1 >
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@kernel.org> To: Nicolas Saenz Julienne <nsaenzju@redhat.com> Cc: tglx@linutronix.de, mark.rutland@arm.com, rostedt@goodmis.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, rcu@vger.kernel.org, peterz@infradead.org, mtosatti@redhat.com, frederic@kernel.org, corbet@lwn.net Subject: Re: [PATCH v4 2/2] Documentation: core-api: entry: Add comments about nesting Date: Mon, 10 Jan 2022 10:01:26 -0800 [thread overview] Message-ID: <20220110180126.GF947480@paulmck-ThinkPad-P17-Gen-1> (raw) In-Reply-To: <20220110105044.94423-2-nsaenzju@redhat.com> On Mon, Jan 10, 2022 at 11:50:44AM +0100, Nicolas Saenz Julienne wrote: > The topic of nesting and reentrancy in the context of early entry code > hasn't been addressed so far. So do it. > > Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> > --- > > Changes since v3: > - Introduce Paul's rewording suggestions > > Documentation/core-api/entry.rst | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/Documentation/core-api/entry.rst b/Documentation/core-api/entry.rst > index c6f8e22c88fe..e12f22ab33c7 100644 > --- a/Documentation/core-api/entry.rst > +++ b/Documentation/core-api/entry.rst > @@ -105,6 +105,8 @@ has to do extra work between the various steps. In such cases it has to > ensure that enter_from_user_mode() is called first on entry and > exit_to_user_mode() is called last on exit. > > +Do not nest syscalls. Nested systcalls will cause RCU and/or context tracking > +to print a warning. > > KVM > --- > @@ -121,6 +123,8 @@ Task work handling is done separately for guest at the boundary of the > vcpu_run() loop via xfer_to_guest_mode_handle_work() which is a subset of > the work handled on return to user space. > > +Do not nest KVM entry/exit transitions because doing so is nonsensical. > + > Interrupts and regular exceptions > --------------------------------- > > @@ -180,6 +184,16 @@ before it handles soft interrupts, whose handlers must run in BH context rather > than irq-disabled context. In addition, irqentry_exit() might schedule, which > also requires that HARDIRQ_OFFSET has been removed from the preemption count. > > +Even though interrupt handlers are expected to run with local interrupts > +disabled, interrupt nesting is common from an entry/exit perspective. For > +example, softirq handling happens within an irqentry_{enter,exit}() block with > +local interrupts enabled. Also, although uncommon, nothing prevents an > +interrupt handler from re-enabling interrupts. > + > +Interrupt entry/exit code doesn't strictly need to handle reentrancy, since it > +runs with local interrupts disabled. But NMIs can happen anytime, and a lot of > +the entry code is shared between the two. > + > NMI and NMI-like exceptions > --------------------------- > > @@ -259,3 +273,7 @@ and for e.g. a debug exception it can look like this: > > There is no combined irqentry_nmi_if_kernel() function available as the > above cannot be handled in an exception-agnostic way. > + > +NMIs can happen in any context. For example, an NMI-like exception triggered > +while handling an NMI. So NMI entry code has to be reentrant and state updates > +need to handle nesting. > -- > 2.34.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-10 18:01 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-10 10:50 [PATCH v4 1/2] Documentation: Fill the gaps about entry/noinstr constraints Nicolas Saenz Julienne 2022-01-10 10:50 ` Nicolas Saenz Julienne 2022-01-10 10:50 ` [PATCH v4 2/2] Documentation: core-api: entry: Add comments about nesting Nicolas Saenz Julienne 2022-01-10 10:50 ` Nicolas Saenz Julienne 2022-01-10 18:01 ` Paul E. McKenney [this message] 2022-01-10 18:01 ` Paul E. McKenney 2022-01-21 14:55 ` Frederic Weisbecker 2022-01-21 14:55 ` Frederic Weisbecker 2022-01-21 14:47 ` [PATCH v4 1/2] Documentation: Fill the gaps about entry/noinstr constraints Frederic Weisbecker 2022-01-21 14:47 ` Frederic Weisbecker 2022-01-27 18:33 ` Jonathan Corbet 2022-01-27 18:33 ` Jonathan Corbet
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=20220110180126.GF947480@paulmck-ThinkPad-P17-Gen-1 \ --to=paulmck@kernel.org \ --cc=corbet@lwn.net \ --cc=frederic@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mtosatti@redhat.com \ --cc=nsaenzju@redhat.com \ --cc=peterz@infradead.org \ --cc=rcu@vger.kernel.org \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ /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: linkBe 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.