From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (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 6683A432E80 for ; Wed, 12 Aug 2026 12:28:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786537684; cv=none; b=XZcuTHHJJwqokREYINr5+oQ0Cq9yo7tBHyuzzpLIVHHt3PX5f4WNmwbQgbtVDrUPNm2sLxiS4Ciz6h/6abzszNCHLsvAUTyq4dRHcX7j8C0yunwSyEKGml9VrPZpOQtxQxgnhsKOGgf/eKinX60gZLE0v+Dx5iZPW042tgUHyJo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786537684; c=relaxed/simple; bh=OLsQWQAZ8OxYrzOAjJrunSXzJbHmrpka58K+pH4v6TM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=S77VrMY5hlEi6biOdvkvl6Y0Y7zcpsSfm60v6Sq5cHKY/pJ8onHtNWh2hQyD28ps3DoCD6Ipm0mQD0C1UrVhk9Jj0WsWhLbAZyEUpNoziApJfQq2EzpLG9znGqfmjbOSp5iuofxuIrZ/gD+iJv99Y4rJ/BlTUalXNfEtx0sAChQ= 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=Q1QXGocS; arc=none smtp.client-ip=209.85.160.175 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="Q1QXGocS" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-5218927884fso9093031cf.3 for ; Wed, 12 Aug 2026 05:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1786537681; x=1787142481; 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=nO3QhHY842VdcusB6Ch/Vqg2F2nPYU3R/4exE5xwEVo=; b=Q1QXGocS/eg7eON61a3tdhQhABvMJ2bAwGHjg3lg5yeqp1aXMz5qcxVGSNaJK+uAc8 PJqSUlRiRauhhKs/9U0qZnBG/nryXnqPYSWE9K6UuVQ7TrT22yZ67orHFysFufz+GFQe f0EQXxPnoyqE+lTl7eaVDbM0XpLVbMvqS5hJRZ7G5++52n1Tg88x7Xv5OljS/B+CTCX/ 3AFZ4E9UKosoZ1+AT6l7EPbIwWOFiH/tY0wQz8eRvBN1MTmcoG5yrDeOWjGI8uBPpS/F g/zjx50e51FGkEDMEANi15VG1hrU7aqJmJkVMqvsZvzeF+dfIso82wXq2C1jFMofajvq iQ2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786537681; x=1787142481; 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=nO3QhHY842VdcusB6Ch/Vqg2F2nPYU3R/4exE5xwEVo=; b=MDg/BU04BWW98Clg6wm8+glBStUtbH+dwTvA4J3Ao5kcXGJsoGKsgTadXGBijrl0vl u4ZdOsnmLa4eTnaDj6KEwi9ac5+0qrfwTKj9HhsvDlch2jJLrOL8EZy/gllwFAGmq1G7 PURKJlXV/Apbz45fGIrU9FKe6ali2dfBtA08UK2cZ7OkYExWbmbL9glJQvDqlxQ/Zbd+ bIbI7cQJnbf9EUI53rcVM4LpmIFYe00zrqr8pWtW1kdecPWt+Lb8XoVafq5kXgFQog+q 3JKw1gEKHbF0rSE9yDJB1tVpPDUSIzQLX7n1LF7vYjp6vOJcH2vCkLTqtSGhYhTIE8LP jP6w== X-Forwarded-Encrypted: i=1; AHgh+RpmBF/kfeldRsN7K2AM8LLDBk8oI2eZIEkHfVqhV4uuNWJ5wu0Z/kAtIMcYNSeMrvuiGhzQBeKhaOjx1N8=@vger.kernel.org X-Gm-Message-State: AOJu0YxBHZpmnq47ymRRO1RW0PX6pEFJuXQrF2BphtB60isXGW2nwOyd OtWratYpi9vzeg2GueTYPtN4kNCLFBNJqvKfQbPjlIC0rDjf9/BqkFYTHe/k+CNeZDI= X-Gm-Gg: AR+sD11A8Y7yIdnZD1WJzWzvGYqWa85K7iZIBrST7v7xXfyQ9INhoxWtYKM90P4H/Wf +mVRSj7YdX03cqqnK6ahtqa2Hs3DSk1DhJznxnsavw4sfvrpH/sd1wT0ShAnUgbVf1rgIjjw2sk 9Ok+Y8bwVtbdwEk8KybAJMkqkVn2dR3jXePad3+sX2ve9IBleuYeW3AfAYOK0Ptyspll4hfM1DN yuQwgYcyuclUCrUpR8LZ/yBSh7KHCHDsM90BbPf0AH2K/GVvlgqtgCrV7+XVEpZfouxtApaM+Wt NVH69sTNdpTv1pspbfx3DujAbQd6Xb84uLzaMgq6gSqGI/vWaV0gwxuzAP4DJJ9UGOKms8UxlNF sUpR7R3IZIvopd792mrdsWITwsARwWngM/5YmMcAVdlrQKezS5blt2Q9wW1BS+LLHylLf7xCbpD /RrYCOHemH6+Kfd+Z1WYHmzNXlm/S5+OTd0ciuuFKfJmPmRa5x X-Received: by 2002:a05:622a:2596:b0:517:7188:c47a with SMTP id d75a77b69052e-52d646b8da0mr38269131cf.2.1786537681291; Wed, 12 Aug 2026 05:28:01 -0700 (PDT) Received: from ziepe.ca ([142.166.156.215]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-90a6c29e942sm20435386d6.12.2026.08.12.05.28.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 05:28:00 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wu83r-000000030Kg-2xlk; Wed, 12 Aug 2026 09:27:59 -0300 Date: Wed, 12 Aug 2026 09:27:59 -0300 From: Jason Gunthorpe To: David Woodhouse Cc: Michal Hocko , Steven Rostedt , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Sebastian Andrzej Siewior , Clark Williams , 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: <20260812122759.GA662699@ziepe.ca> References: <20260811135537.GC544626@ziepe.ca> <1d669aca4ffee797b9c29215382444a5b23624b3.camel@infradead.org> <20260811142730.GG544626@ziepe.ca> <20260811104229.72fdd928@gandalf.local.home> <37b83b429b9f14ea6ad4ca1c13cc8e565ec09033.camel@infradead.org> <44c51ace9b0dc44b795f6f48c91cda440eed910b.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=us-ascii Content-Disposition: inline In-Reply-To: <44c51ace9b0dc44b795f6f48c91cda440eed910b.camel@infradead.org> On Wed, Aug 12, 2026 at 09:21:31AM +0100, David Woodhouse wrote: > On Wed, 2026-08-12 at 10:14 +0200, Michal Hocko wrote: > > On Tue 11-08-26 16:24:48, David Woodhouse wrote: > > [...] > > > I had a second reason for disabling the overzealous check too: to allow > > > SRCU grace periods within the notifier callbacks. > > > > Is there a way that srcu barrier could cause an indirect dependency on > > memory allocation? In other words what might block the scru to complete? > > Not after https://lore.kernel.org/all/6eed3fe3461e9690b486ca98fa7563f60d3940ff.camel@infradead.org/ The user of the SRCU might have a read side that wraps an allocate. In general it is not safe. I'm skeptical that without special API and documentation the KVM special use of SRCU you've outlined will not remain working long term too.. Jason