From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D1B12283C9D for ; Tue, 11 Aug 2026 14:27:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786458456; cv=none; b=Jcnp0/7IKgo2RJP8Nc2jqDrYokO8tuY4l0En1kvvHQgVCifnaiosaqd3qDpyAmaVvWWjt8swA8qBx8Ts0EtsTWjDqfvtJNVZVl7j5iSbq0zXdLag22WeIBQF+yQ4TPBUErX75Guvj4StB5WObKDrlrS4Mx0GaJtfzTXP2oKbN48= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786458456; c=relaxed/simple; bh=S1MnOpajZIuRKJeZjsd/WdRxI/oF2ocNH/aJeyBhuMw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lhPJwriWGRZX4EkhUZgnSPLfbia5RBbEKUJphmeWkNt6UCwEkycUx/uK2l8IfUQhT4UnCfxwK5Af+yuiyffD71nNpQ6Z23ArBVMfkZTa5Devi9QjHl0APAI4k0fj1j0Ji/ksdbAwTYK8uXb6pE3MeDe1F+Pn90rli+EpDjiqtNs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=dbB7+sak; arc=none smtp.client-ip=209.85.222.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="dbB7+sak" Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-92e5c9211d2so248884885a.1 for ; Tue, 11 Aug 2026 07:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1786458454; x=1787063254; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=yGh0jdU9hH3pMDac+rBHolUofOnAZc4NvBka4kqdBBE=; b=dbB7+sak40pPnRMPCKfyGL9fk2C4XP85WbbO0XvS7oiplIMQzZ9ZMVREd8gxsmiJDl CGPDOVFKQTqSbqWd/la0FNTF67FkUqJUNp2hzlh483mpKDJnGp5NeJ+3H7Kw29iuZ4ye 6W4I3giodel+k42aIDd+NcA7SHqrzSoT10isnVs0k6HCLZZBsOf9/AfsmoFCDj6cp6mS R1lkEpTJ1+OTl1FnkWwfgVnwq7jFsRslT3VFKuB6Q3pfpS3NB69g1enhQh8pl1zRSCSv MO0+lPHNFiQ3ImmafIWOoyIW6QSRn2HxQ74T+kkDvFB4CDoHAJqapHktVpbiUclOKHBd NHZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786458454; x=1787063254; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=yGh0jdU9hH3pMDac+rBHolUofOnAZc4NvBka4kqdBBE=; b=OmW/wpeT1x8++qQCTjXoS0tC4Y086VaD3jn+GfetEoH1fGuclCBkO+gumjqXu9Vxhj wl/oKrOWKZm8ZNaZ0n7+c+qeq0+5UijtVfPbzAJp3ICFbEJvszeU6AxAgURQdf2GJqrg z0LwF9kkR9nqGwom7/kxTpt5C+9rUHQAROZHJBbkwTmYWh4tS3GKRrJfKDuoesFXNwDN PTMnTSX4M9p/hPQFlXsyPCrngquDcGS3yw20i+9Qg+pw2Lr2TyAdixlh4XDm/GC8DDqy kB3TDvrcgc04qlLtqjQerDg+Rtc39DAx1DMArbXPt5/ioKWuhkCSbPlehys6nVdTWhLd 1svg== X-Forwarded-Encrypted: i=1; AHgh+RpYBgOnreJU/Urys7CMtewB/apCH+fvCyMK0dFzYzPd+QNOgbI4xcv2GVjeLy7iAX636kn66s9rmmY+jSk=@vger.kernel.org X-Gm-Message-State: AOJu0YwkkYZ8j1pGJPfNjgnN5Tw8jqi0pJ4TqqJEcSAhPK+mqEuWOQYg WKms81a+oKuh6MVS0m5kl1F9RbfU95n93Kj4FACZrM9yQGA1gwCIaqsR8n3HPt0o0Ws= X-Gm-Gg: AR+sD11vrIkfhkJgbjrN0bkDKutAqiM0X+kfenmV9nrLbrQVhLzCpIQW/R+PDGvE0zm cK4qu1ZfrmChWApfGefnLldvidRQEmwMqPF/aMov0m02LkUkYOMeUyfGe0ihaEb4CdprLEP28GJ RPmVJbOTPrXz9GYIkebPeiNaSyWaCDy9xKDnGgmoaMOg4eGytYb9fePHj+tyCyaqD2POAiDz+n9 8xSBoAiKjgClqT+UDjUHeHb3Aw04E8ivfOifMLRyaiWZSUsPAInUw+J9GDc655zd3LerClb/sD4 x7RyqK+AeoFs0AMNH2niZI0T+0wvKdxBS7RGnY8py5WL4ERylqLZJoMlAK1OU7IaLlX8PO8h3mJ rvNCuKIRJlY7UuCvn417p5HFgpitYHY6+wztJ68FuPL81HLsJYlIm4HztfqhnNgrdC90FfRd3Y/ ZOa1MW9rixJh2ELLj7vvjfhy8LbGkKZExybH750w== X-Received: by 2002:a05:620a:4549:b0:914:bd27:2d1 with SMTP id af79cd13be357-936a8edb650mr322022485a.11.1786458453669; Tue, 11 Aug 2026 07:27:33 -0700 (PDT) Received: from ziepe.ca ([142.166.156.215]) by smtp.gmail.com with ESMTPSA id af79cd13be357-936a849ed87sm122584685a.15.2026.08.11.07.27.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 07:27:31 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wtnRy-00000002VR0-3Mpe; Tue, 11 Aug 2026 11:27:30 -0300 Date: Tue, 11 Aug 2026 11:27:30 -0300 From: Jason Gunthorpe To: David Woodhouse Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Simona Vetter , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Christian =?utf-8?B?S8O2bmln?= , "Paul E. McKenney" , Sean Christopherson , Paolo Bonzini , 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 Message-ID: <20260811142730.GG544626@ziepe.ca> References: <20260811135537.GC544626@ziepe.ca> <1d669aca4ffee797b9c29215382444a5b23624b3.camel@infradead.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1d669aca4ffee797b9c29215382444a5b23624b3.camel@infradead.org> On Tue, Aug 11, 2026 at 03:21:35PM +0100, David Woodhouse wrote: > > >  - On PREEMPT_RT, spinning locks become sleeping locks, and perfectly > > >    legitimate spinlock/rwlock usage in notifier implementations (e.g. > > >    KVM's mn_invalidate_lock and gfn_to_pfn_cache locks) triggers the > > >    splat despite having no allocator dependency whatsoever. This is > > >    reproducible today on a PREEMPT_RT kernel: KVM takes > > >    kvm->mn_invalidate_lock in kvm_mmu_notifier_invalidate_range_start(), > > >    and if the OOM reaper reaps a KVM process the result is a "BUG: > > >    sleeping function called from invalid context" from > > >    rt_spin_lock(). > > > > I don't know anything about PREEEMPT_RT, but this seems like an issue > > with RT if a traditionally atomic safe functions are now triggering > > might sleep failures? > > I can sympathise with that point of view. In fact I've spent the last > couple of years mostly ignoring this "problem" and just blaming RT for > doing exactly that, but I don't think we can really get away with it > any more. > > cf. https://lore.kernel.org/all/787aa26cf62dfd361eea8ed19f384fc517892501.camel@infradead.org/ If might_sleep doesn't work sanely at all in preempt_rt then just globally turn it off? > > >  - A notifier implementation may legitimately need to wait for an RCU > > >    grace period before allowing the caller to proceed with unmapping > > > > That's not allowed. We really want to forbid that, it is not an > > acceptable way to implement a driver using these APIs due to > > performance. > > Speak for yourself. For the KVM gfn-to-pfn-cache the performance scales > *much* better with RCU than with explicit locking: > https://lore.kernel.org/all/8f41cb82b7c99d5a3d1dda016e4841326b4d8a52.camel@infradead.org/ At the cost of completely destroying the mm shootdown performance with 1s RCU grace period waits every mm operation. No thanks. The unstated secondary purprose of the atomic context is to force the driver implementors to make sane choices that don't degrade the MM spectacularly. > Perhaps we could find a way to push down an *accurate* sanity check > into the code paths where what you say is *true*? I guess it could be > done with a flag on each notifier? Or *into* the notifier callback > function(s)? I think it is right and correct the way it is. Jason