From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8DFAE7717F for ; Fri, 13 Dec 2024 20:09:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1379B6B0088; Fri, 13 Dec 2024 15:09:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BFE96B0089; Fri, 13 Dec 2024 15:09:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA2826B008C; Fri, 13 Dec 2024 15:09:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CD80E6B0088 for ; Fri, 13 Dec 2024 15:09:31 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 960291C6119 for ; Fri, 13 Dec 2024 20:09:31 +0000 (UTC) X-FDA: 82891025154.05.94FFF5D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 772374001B for ; Fri, 13 Dec 2024 20:09:00 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of "SRS0=hwFb=TG=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=hwFb=TG=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734120552; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IF3dn5NFj9gztu28UFKM/pNGZXvFhOb3o3/nzzXBLQw=; b=peZxyhwqmrF4rETPYZn+RIh9SAJ2or9TBG6YXw1NEhw3B0MVzBLsYxhQp7z0ER+Gd360Ca egg0EqoO52y56BGJaWVJM1yJZJh17dEr8KZlrl6R5uq7Ob8AJNoqMzO24TxqiaA6LZmRYX uOQgQGfyrHPYx9enYv95y7Nxu0OaNcg= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of "SRS0=hwFb=TG=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=hwFb=TG=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734120552; a=rsa-sha256; cv=none; b=lLaVY6TMjl6NIweOyBC4W5vGv6+Rjlz/wHMKD4+l2ttZuVuwFFxfUkFWRvOik3eiSdlU6R 1Nkv5nMdDR8d2SXKXlXTbyLxHWHWGF1V+AKiq+W+L6fVOKhQbg6used88DooDMt8iMTN+f St68YyaT7dS0fmH9l0pcN2xukZn+Ujs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 002475C64D1; Fri, 13 Dec 2024 20:08:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D670C4CED0; Fri, 13 Dec 2024 20:09:25 +0000 (UTC) Date: Fri, 13 Dec 2024 15:09:50 -0500 From: Steven Rostedt To: Alexei Starovoitov Cc: Sebastian Sewior , Michal Hocko , Matthew Wilcox , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Vlastimil Babka , Hou Tao , Johannes Weiner , shakeel.butt@linux.dev, Thomas Gleixner , Tejun Heo , linux-mm , Kernel Team Subject: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation Message-ID: <20241213150950.2879b7db@gandalf.local.home> In-Reply-To: References: <20241210023936.46871-1-alexei.starovoitov@gmail.com> <20241210023936.46871-2-alexei.starovoitov@gmail.com> <20241212150744.dVyycFUJ@linutronix.de> <20241212153506.dT1MvukO@linutronix.de> <20241212104809.1c6cb0a1@batman.local.home> <20241212160009.O3lGzN95@linutronix.de> <20241213124411.105d0f33@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Stat-Signature: sb3aai7mb9hhprpfc6kfop8dhrqz13tx X-Rspamd-Queue-Id: 772374001B X-Rspam-User: X-HE-Tag: 1734120540-600146 X-HE-Meta: U2FsdGVkX1808fwnCU5Bk+NWyz8jksm78pTW0U+hqqcVwid86c4aPiar22baX+qdR0WJ+v8jCDwEsxh8ax2DlnhCSnJS4yldjYZyXQy88mh/wxxS34UUTPfWpU1wDoOXd6KQxehbiLtwTsV/3We80XYEvFtBdFbjXC4UqArIlxIJX0jPtD9Yu+15mhya+U/A6Jr3LUIQ4Vt2soXQ9UdTZT2Q0btGU9PkVsFJH3g+uBuQh29BKE+e58WNA0L7wjQvos8w9awis33DS9axWXdPKVlz9lCWoZ3YWX0ro8tQY9u7f7UwAy+9V2BkmXJAyoWQ1TcwrsaPOdzAnWFjYIJI4kMz07TCRfaxsUY8DDQNog7JuUOksTTk315NybpyMcOssX5CredddwOWAEsNaFMP6DEHA5g81ajsnP7HMENXwqhobuDksb5qpLV+9hKlA4spYvGUY+ZSwoxqNBNv8jW2vJun4y3UvnVypE4oJ0GUjwZJifllK/Lsx7TxAF7tunGmDFjFqWCBtB3MrquLihF2s0AVmWU77CUChEnTLL9uIQJBUqYH5fNJgd5D/cCGdA5X+WQvCMvaCed+s8AnrnzkKHqG2kx5jHA3HZ1OuV+7BR4ZnQfuvKFpNy2d2/L9nZWBxjIEYcPvaQhMJZ2GSW5U/PSWe22YeAUvQbhOEfIwl3RHA15gIcOq/d2sApEcFMitLxupv4NJibXSGcTHJjktHG9JA/MkeC+/oLbax4cekePFpnfzOPs5talfrD0qknslPxOOkZcLKyAjj1NA7/HhoCL7F6T2yK8y0AU8ZcHux0EI/gbCWVLxImzlAGXQzGFJPdFY/0Omu+IZ6IUeVjwfU5wAwC0aRX+0WwerL3j0Oc8BotTChca/3cDKi3WnRwyow+fjHY8CVpoSdZMiKyBxJU4+/uCCsTHxfTVs+D86mfbXx71obqALNn+HmBW753HVBfHJRqmpXcDQKw+JG9F mif5sXys C2iDWtD6zEF4ETQN9+qdtUP7yuXuuZgon+HEPcmayXDB3BFQg+kllPj0HVphnisckBfeYeObpMFel3lIQcaufyRHmBz+h7ay9gm98hB/fmCxE+iNjuXwO5uQ8tbvyZj44cYcv9AS5vqX6KHMvP6oc2vRdqMyti/3MO4htZKb2WGtLb1H85MCSLJd0Hbjb/M4e7z7HVf2ehvSBOq29RQG76RC012WxrPB2F3x0ZaN+O9CJ2ZeP+f0B5WYxkG/tIuyUeNNmftSLFhmCxpngK8B53U2ZgqpQczE4Sdjhp2wCW7iGScsQoy499JPuMTKoiUqgW8uRqyhUV5//fR6H3096Uzjlt6TgnsFOWAeSINSsKQC4nC8mQDRcn62Xs4Scl36TRKuySoiQmEvYQg8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 13 Dec 2024 10:44:26 -0800 Alexei Starovoitov wrote: > > But this is not the case. I'm not sure what would happen here, but it is > > definitely out of scope of the requirements of the PI logic and thus, > > trylock must also not be used in hard interrupt context. > > If hard-irq acquired rt_mutex B (spin_lock or spin_trylock doesn't > change the above analysis), the task won't schedule > and it has to release this rt_mutex B before reenabling irq. > The irqrestore without releasing the lock is a bug regardless. > > What's the concern then? That PI may see an odd order of locks for this task ? > but it cannot do anything about it anyway, since the task won't schedule. > And before irq handler is over the B will be released and everything > will look normal again. The problem is the chain walk. It could also cause unwanted side effects in RT. If low priority task 1 has lock A and is running on another CPU and low priority task 2 blocks on lock A and then is interrupted right before going to sleep as being "blocked on", and takes lock B in the interrupt context. We then have high priority task 3 on another CPU block on B which will then see that the owner of B is blocked (even though it is not blocked for B), it will boost its priority as well as the owner of the lock (A). The A owner will get boosted where it is not the task that is blocking the high priority task. My point is that RT is all about deterministic behavior. It would require a pretty substantial audit to the PI logic to make sure that this doesn't cause any unexpected results. My point is, the PI logic was not designed for taking a lock after being blocked on another lock. It may work, but we had better prove and show all side effects that can happen in these cases. -- Steve