From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (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 C80C63C872C for ; Tue, 11 Aug 2026 16:24:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786465467; cv=none; b=EZzhVjMxSf59ViZCxMOaWz8ogY4TcfbtkdYi/A+OT4hKti16Ftz0YBf81nDHVyo6BsZeJ5cvCgBZluQzTIBhVw+zFoh6egGFTD5ofht9/CAAAJ/BCvGVaL8tciQmd8BVKp0mUbzCdEpSiEWxnXrdS4/f6XWg7acDOlWxH48Ta70= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786465467; c=relaxed/simple; bh=HwC3T/puzehhf8bSut7phAm1yYtmjq0Oh6XDbBl2A68=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RlpBf2Xsx8Qi62dyuhpTc8zK6eE6gSr41TsrCPxJsPE8yuxBxArWlgO50Nbs6XDSTnW+z23IKpwRHUZEMsEcGFS/t/Y/m/b8gkCZX0SsJT5b/zE+OKY1wMi9c8xZM8WMx9+ZMOUWiB0RCP9aOhiB4ebpI4K7P1xMKVpxol66uKA= 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=XMRiV+3z; arc=none smtp.client-ip=209.85.219.43 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="XMRiV+3z" Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-9030f8ea3b3so58906d6.1 for ; Tue, 11 Aug 2026 09:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1786465465; x=1787070265; 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=Ge2DKXL/0cigzsh3KdWGGLhQNvufZEJOXUsvNTDWwxU=; b=XMRiV+3zHn7csMteo7qplcPoE0IJjjaZOqOxsoSP1uyWa1jOVvdePlhXC+eOKo4bw/ 1Ktyf+6oXen/UGN9QtwETFY08PBvRM3mVKYLLySMOIC8viSgDh7qLvmaBvi9aTdNw2d1 bP42Kc/LXzQ9PboxRgm0rsUT0kasw85YTZ6/Yub2Ues3dzsPL+kKi/bVbdI55T+I2dM2 c4ghxew3iGVPvg9JBKpBUMVrHLIAu1h4lTg8FDeMvrdudUTm2geMLFkhi4KttJ1AC2Tt aPO7z6KCEhJxSoJqLyqKqeKfi/nLJIoJBgiBQ/jMSGN09lhDW03WNm5hv8ijAZV5YAtD BUOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786465465; x=1787070265; 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=Ge2DKXL/0cigzsh3KdWGGLhQNvufZEJOXUsvNTDWwxU=; b=d8SpoVDwMthEnSR+LZ7jui4Kok7sCpZWgEdViB/F5ZRsDyF/Q6LI/LfUUCfzR/W/Mf bx5IsvP0uAucbBGk1JG98ZugIsJaFuaog/2uZOsYI/JdldADzAVef7VyDvjCSek8vKn+ IsiP7vJiBuPOp9Hz37BeYE3T7C4auBlaHLafec7Ay6T3a+W+Wqb6Br29XUCfOGdPUD0X Nrllo3W9HES3nRGCeIS0HdoeuWznnunv1UtVKPMFRfAtqCBMjK0SXGyyXh8X/m2+2WYn Sb4whgs++s9+LWMtCL5jp60JFkDvZTQT+hsxB8pD2wjlwn5rfyouJ6TqpwsHbo70TNcD eq1g== X-Forwarded-Encrypted: i=1; AHgh+RrGMvHu6vBWMHg0VZ34yj4yVF0l1VscbWojMIC/KgM4k9XU7SkTEmagLrKrL04QQjrXwGn3OVPRib3Pxmc=@vger.kernel.org X-Gm-Message-State: AOJu0YzUq4Ol3ftOqTSlTxlRD2mYoZbhpUoBvdEjSUEA7so64DCoDA9K OyUszTlf/9QXY9WAKQdiOn/h/zhnEjByoWKxV+YoEMnakRxvZ7mrrZkg2VBgbXBpeFs= X-Gm-Gg: AR+sD11wxPhTtJLmEROtPeTl2JDnQOnl5o4zRoABgnxXExiqGCQoiQdiPlzYekn3Cqx DxUm25FpAiLFWUMe38Ib1IZP7tcphfJHtFsktXqIPK8en8unLGpuiAyakDKCd7zB6jGLAMvDqPo 0OoUYGJxmLVx8ChJOW7NNf7eC9vPmnzJzULvjSkfPcgKJUlDiOCNfIaeqIXkqgqssBO8eAU1Q/K hJlh0zf4103q0LKvkd6GOaRfwBvORdDefGM9hDYPeahmkLo3d7+GvfQQd90DDbY2bjnuSs6fidC nC0/UQZiDB8EU9en3ZR8kRM/4W7JDTIEznoyTtsqXjreMxeZdk5t+E9Y242G466G22S2XosqcTI 9WQXjftDDjIPzutR1eCUbxc+LEeUhGDTj4/BWgsZIbUme3lIsPi9KZsXaDmQ9JzFt8DCrjfnvgq Mq4uc4inGUeJkLBOKjJyOUHBPVjYrK+rAeHgyGrqdm1sM2MKDB X-Received: by 2002:a05:6214:5d81:b0:8ef:ea2a:2728 with SMTP id 6a1803df08f44-90a66df2c02mr43379816d6.19.1786465464725; Tue, 11 Aug 2026 09:24:24 -0700 (PDT) Received: from ziepe.ca ([142.166.156.215]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-90a6c3c38c4sm2442696d6.36.2026.08.11.09.24.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 09:24:23 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wtpH5-00000002YAS-0rLs; Tue, 11 Aug 2026 13:24:23 -0300 Date: Tue, 11 Aug 2026 13:24:23 -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: <20260811162423.GL544626@ziepe.ca> References: <20260811135537.GC544626@ziepe.ca> <1d669aca4ffee797b9c29215382444a5b23624b3.camel@infradead.org> <20260811142730.GG544626@ziepe.ca> <15a7bd252a9aaeefe393f5609ec383ce2c61694a.camel@infradead.org> <20260811152435.GH544626@ziepe.ca> 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: On Tue, Aug 11, 2026 at 04:29:55PM +0100, David Woodhouse wrote: > On Tue, 2026-08-11 at 12:24 -0300, Jason Gunthorpe wrote: > > It is documented to be like this, even if it is hard to test.. > > So don't change your documentation :) > > > Even for normal blocking notifiers you should not be using > > synchronize_rcu(). > > This is SRCU not RCU, and the read-side sections are converted from > rwlocks and never had any allocations inside them anyway. To be clear you should not be using any synchronize_[s]rcu() primitive inside the invalidation callbacks. These are well known to have multi-second delays on loaded systems which are a completely inappropriate performance characteristic for these mm callbacks. This statement has nothing to do with deadlock. RCU is always a trade off, you can make the read side run really fast and the write side is ghastly slow. If you can't handle the slow write you shouldn't use RCU techniques. Jason