From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 815BA3749EE for ; Wed, 12 Aug 2026 08:13:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786522394; cv=none; b=bCLczmHs0ldYh6nuvYFjxp7RjOxOCmxeffr2AkDDlyUl0yzB3IjtUi5p13MJ6q2hijxx8FWX0yxnNyDrrrGzRrZHg5qlqI7a+lhrJTmmyPlKjtd2uGSG24fVymsrS6tOv7wNgVtmoiB8RQczpUXxaaJDCfOROQCkdRZ6LLeDpNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786522394; c=relaxed/simple; bh=LZfvAz1OdH+4vvnegdGNwqfqI7AlK1EZetVAI3vqD3U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rC8FuUt+P1sK0/EB10KiZ55F/hbVVwZNsRIf8iyWQAgXNpK9vn+G49Uvtnq4Js9LG2JjViVNnZyWWc2vcpP0uaQSWNV25YSP90IFsuuT/gdx1H4TbKPiA+ZaIsZ5wKjigTv/8jJvFiXIlqr33pohyJeEsoLgjl5sBZh9hqlez5Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=aOTUngGv; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="aOTUngGv" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4957eefd361so4676005e9.1 for ; Wed, 12 Aug 2026 01:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1786522391; x=1787127191; darn=vger.kernel.org; h=in-reply-to: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=Ul3j3WGcIwdB94lLOJYR7d/dt/sRRRqyC+QOYhiAFkk=; b=aOTUngGv+Wh+SXlRAqgcU7heS9OD7v2M7lnPaQ81bTTCy0U06tcqB5PT6vID9BqaX7 eGTxgoAfRxWhowfegqVgcl6pR45Gmt/I/IoETOxLZHlFGiApkI36n6sUCn3d3VWPqlaP kAJcu+KLgmMHwpBXNJmtBUecQHwyAX6BQ+EE8ijkPcL/5qM182lYveSt2LDBPpdxiyo2 CPXuDGHg2jHtCLRIci0GQYKOeTyZgRbm/juRPslLnx6Hl2W94GUFau1GZa6oW+pY07/x cJSkdk4aGBrlDI38CgTMlSHw71LFi02BEoK5RStLq4ExaYzkwZT89ZPQC5dvoXnQEcgh 6KZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786522391; x=1787127191; h=in-reply-to: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=Ul3j3WGcIwdB94lLOJYR7d/dt/sRRRqyC+QOYhiAFkk=; b=ZMOF2QzkOfrB2Y8xDNyjIz2rSHcviGZGjxX6oZbgHrR3RPa4QjyDAwEjlFkkXYEi1z +1j/0DDnOx8zgM8+MJRrKYM1Ecq5KUNw+ZCKLPUa2yIMN7FxxX/CMYXeaDspcbwBWmI7 nqm52fNJqe4Gok4yg2GlgQM/6uUVbp6kvUHzCDd+ZNuNblobZ9/eC1Jj8n1kiSW6yACz i8gYWLMe18mBloPxoS4yyqtY4K43JyG3FvKe8j1Cst1+Q0QOtR358HIekr6SiXMygTHJ rThZleo18agMr/hkGyHrJrQEVM1v+ouxe8uTtaRjJq7w3uZtTapMPISFV8eyRYFrP3zW qzuA== X-Forwarded-Encrypted: i=1; AHgh+RoDGP9XJ+jlbsdLiwlKxTHw7C0nLCGZjS+nWsLDfhHzIGcy0wQrvNa/hOMmiPgq11WrJ6BRPCb9TnjCizc=@vger.kernel.org X-Gm-Message-State: AOJu0YzlylPBgNy43ct0OTqv3CjzAlsdxowpvZb457QjjGcyVPk0vbFa R6HXskxQrKibAfe3YoKeyAzpg6O8i8bXJsybRU1utw2fJkEjeKpEBTke5ltuUglBQV0= X-Gm-Gg: AR+sD12AqmR6qHRAwIyEGLqR9nlX9B+av6OxWyP35izoHC8cT7VORoeFDpU2nKIKeZu nrHqdKjGf9YfBs7cDJnq+ZdtLBTTBMJixsQEEAc9AUp10HMRBRtPIW0CCF96PP/EO4XjZjlxNjR T85ug7Uv8WM9Fhy2h5iUicOnx9BH+/+10QIpnwmFhQ2m1q75kmrjrSmMy0Dxa6fWnH9X14uewyz BVJ1UCZkQzgeYkurJKfNssMgtKzbV6x/zKOsUoTaXyAcPcUUu5K7fZUuVy7Ck0AIb9fvR8NOoyC 6BRylV+AaJJg7e1dIinNCkOANP188Xz6Csg9FV7tt0RDSMxY0qeBuIaYPnkS6CEYwHWzFj7zpRR GpjU/gJQAa+PxzE7kXkIk+skVDRxHrK3TTV+9WcpEuH0rtcZfIq4PMmojxvknrunJGkZWMgZd/g FZOm7NfWK8QGYpL3fJhZJkgtpGPDYpXDxepgccm0ifUp6CQlIk39Y8UrIy1rZdo6FiTbD2cUo= X-Received: by 2002:a05:600c:524c:b0:499:7410:545 with SMTP id 5b1f17b1804b1-4997c145066mr36029645e9.12.1786522390781; Wed, 12 Aug 2026 01:13:10 -0700 (PDT) Received: from localhost (109-81-23-83.rct.o2.cz. [109.81.23.83]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4997b237ab6sm26020375e9.0.2026.08.12.01.13.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 01:13:10 -0700 (PDT) Date: Wed, 12 Aug 2026 10:13:09 +0200 From: Michal Hocko To: Steven Rostedt Cc: David Woodhouse , Jason Gunthorpe , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Sebastian Andrzej Siewior , Clark Williams , Simona Vetter , =?iso-8859-1?B?Suly9G1l?= Glisse , Christian =?iso-8859-1?Q?K=F6nig?= , "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: References: <20260811135537.GC544626@ziepe.ca> <1d669aca4ffee797b9c29215382444a5b23624b3.camel@infradead.org> <20260811142730.GG544626@ziepe.ca> <20260811104229.72fdd928@gandalf.local.home> 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=us-ascii Content-Disposition: inline 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 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