All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "David Woodhouse" <dwmw2@infradead.org>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"David Hildenbrand" <david@kernel.org>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	"Clark Williams" <clrkwllms@kernel.org>,
	"Simona Vetter" <simona.vetter@ffwll.ch>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Sean Christopherson" <seanjc@google.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	linux-mm@kvack.org, kvm@vger.kernel.org,
	linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation
Date: Wed, 12 Aug 2026 10:13:09 +0200	[thread overview]
Message-ID: <anwrFZEKcW8bPJTY@tiehlicka> (raw)
In-Reply-To: <20260811104229.72fdd928@gandalf.local.home>

On Tue 11-08-26 10:42:29, Steven Rostedt wrote:
> On Tue, 11 Aug 2026 15:33:18 +0100
> David Woodhouse <dwmw2@infradead.org> wrote:
> 
> > > If might_sleep doesn't work sanely at all in preempt_rt then just
> > > globally turn it off?  
> > 
> > Turn might_sleep off? Or PREEMPT_RT? :)
> > 
> > The RT maintainers are on this thread if you want to pick either of
> > those fights... that was not the course of action I chose to take.
> 
> I guess the question is, what exactly is the reason for sleeping to be
> prohibited? In RT, sleeping is allowed in most context because most context
> are threads (like interrupt handlers and such). Now, you still can't sleep
> in NMIs and hard interrupt handlers that were not converted to threads, but
> I'm not sure that's the case here anyway.
> 
> If the non_block_start() is just a big hammer to make sure things are fine
> in non-RT, it will likely still be fine in RT even though it may block and
> sleep. But what it blocks on are sleeping spin locks that likely would not
> cause an issue here if they didn't cause an issue in non-RT.

Yes, this makes a lot of sense to me. While it is not really great that
the oom_repaer gets blocked by a RT sleeping lock because it delays the
whole operation this shouldn't break the "do not make any direct or
indirect dependency to MM" assumption as those locks are normally
spinlocks so there is no way to depend on blockable allocations.

So the warning is mostly a false positive on RT configs and what you
propose below makes sense.

> 
> Thus, perhaps something like this:
> 
>  		if (ops->invalidate_range_start) {
>  			int _ret;
>  
> 			if (!IS_ENABLED(CONFIG_PREEMPT_RT) && !mmu_notifier_range_blockable(range))
> 				non_block_start();
>  			_ret = ops->invalidate_range_start(subscription, range);
> 			if (!IS_ENABLED(CONFIG_PREEMPT_RT) && !mmu_notifier_range_blockable(range))
> 				non_block_end();
> 
> ?

-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2026-08-12  8:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11  8:58 [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation David Woodhouse
2026-08-11 13:55 ` Jason Gunthorpe
2026-08-11 14:21   ` David Woodhouse
2026-08-11 14:27     ` Jason Gunthorpe
2026-08-11 14:33       ` David Woodhouse
2026-08-11 14:42         ` Steven Rostedt
2026-08-11 15:24           ` David Woodhouse
2026-08-11 15:30             ` Jason Gunthorpe
2026-08-12  8:14             ` Michal Hocko
2026-08-12  8:21               ` David Woodhouse
2026-08-12  8:13           ` Michal Hocko [this message]
2026-08-11 15:29         ` Jason Gunthorpe
2026-08-11 15:15       ` David Woodhouse
2026-08-11 15:24         ` Jason Gunthorpe
2026-08-11 15:29           ` David Woodhouse
2026-08-11 16:24             ` Jason Gunthorpe
2026-08-11 17:22               ` David Woodhouse
2026-08-11 17:26                 ` Jason Gunthorpe
2026-08-11 17:59                   ` David Woodhouse
2026-08-11 18:19                     ` Jason Gunthorpe
2026-08-11 20:06                       ` Sean Christopherson
2026-08-11 20:21                         ` Paolo Bonzini
2026-08-11 21:14                           ` David Woodhouse
2026-08-11 22:58                             ` Sean Christopherson
2026-08-11 23:50                               ` David Woodhouse
2026-08-12 10:25                                 ` David Woodhouse
2026-08-11 20:29                         ` David Woodhouse
2026-08-11 15:12 ` David Hildenbrand (Arm)

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=anwrFZEKcW8bPJTY@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=christian.koenig@amd.com \
    --cc=clrkwllms@kernel.org \
    --cc=david@kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=ljs@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=seanjc@google.com \
    --cc=simona.vetter@ffwll.ch \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.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.