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 B39A7E7717F for ; Fri, 13 Dec 2024 17:43:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13A696B0095; Fri, 13 Dec 2024 12:43:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C2E36B0096; Fri, 13 Dec 2024 12:43:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7CBD6B0098; Fri, 13 Dec 2024 12:43:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BFE326B0095 for ; Fri, 13 Dec 2024 12:43:50 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 676831410A4 for ; Fri, 13 Dec 2024 17:43:50 +0000 (UTC) X-FDA: 82890657402.03.4B0E3F5 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf11.hostedemail.com (Postfix) with ESMTP id 32C0940008 for ; Fri, 13 Dec 2024 17:43:25 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of "SRS0=hwFb=TG=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 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=1734111811; 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=0x2xskoY3ffYepj6aPRtYydS6zlcvWytId/k5CqC3MI=; b=QC6ajE2La0ST4qx2X2AtjJ7NkyODjyirAM6eBFpPQOjFpbeM1FeQTqwl+NTSny2y+D94dP mI+1Rrh9ZtaIZZbyVRgEeje4TdIUrAVo7PxjiWRICj2JE6YC0g3DkPeibqkTw77PtZ0djP tMtuIPTYoGk9NeNnMT9dIsbzlx/pikU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of "SRS0=hwFb=TG=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 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=1734111811; a=rsa-sha256; cv=none; b=IbbZ8qT2/X8zsyOIQjeeUurht5r01mOddrzYBqb6alyMxny5qSsx6cLowF+4lltNHs6IQG o5WRlAjr7Kujty9XdF1YYH1/UIiuGiLCk/fUdVblHpZBM9UGUYL5h+SklI/w1JaaAAOp4a MpGfpSLSigJkvV8eFjDXLRyUgStxLCY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id DEB6BA42C29; Fri, 13 Dec 2024 17:41:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4752C4CED0; Fri, 13 Dec 2024 17:43:45 +0000 (UTC) Date: Fri, 13 Dec 2024 12:44:11 -0500 From: Steven Rostedt To: Sebastian Sewior Cc: Michal Hocko , Alexei Starovoitov , 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: <20241213124411.105d0f33@gandalf.local.home> In-Reply-To: <20241212160009.O3lGzN95@linutronix.de> 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> 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: wiqhf5ztfxmmyofgbnkd5xz7j618jezj X-Rspamd-Queue-Id: 32C0940008 X-Rspam-User: X-HE-Tag: 1734111805-553181 X-HE-Meta: U2FsdGVkX19m7/TKdJ+DpahncZHnA3tz55nddjEYxGi8Cb6Gro3+euT9WKbF83SVjOGS8odt6rh2V7zy2EoujPi7yCxu/O0Dr+XF1AbCvnGjz51FaesbnwftyL9cB5VdNpDjzxX+0xF1AesSnN2ZY6uT/vmpa+Vr6Bgd+tTU7tGDfaLzdN1MncjbadkR7bBmSJ4BlI9RyNGfGXl+oFpx/JHJjmk0zORTUox881wA1fW2P34suRUkn8+kofKZmHOJavhgc7BFh60eyeL6IaQBSxv+t5CaQzMNAnVyNlqjkigK88LWpmO/D129KEm4WTR7cZruqUB7tNzwotEmuB69Rv7vMHSbRZl11uHRe6t1cWh6EdPqw3iTMYUTh+h8dKZWPZLKiCQeBgme957oecMjRIGIHO4sJgVibW9zeFiqvARm2zceSOLJXUuHzohXvuvnSTi2v/I35FLcnax2Z4lPeMHg7zduYXG57lHH5vTq549KxMtYPMTziRY2XDf7j+oTckqM1HrQptlorkINSJ3SzmUy3LisCoWQemYEF5Nw7zGSXQwrSjbnCd/9J4Uj5iYFffKfppKWi/V7AQ2rJezsmmXzT3TWfzaeVoShcPSqwD25PtvwySE8KJpK5vqPxE1HU+P0dCko+ZGBfwGTm2RoxDPYgVLJR8Ip29ipVDPn0He1jVQc3BlsItA9Tw9d+em6qkMyvgAngtOp/qh1u72XpHFMd6w/CE6ezIPwKb0DTMf8Sy/wZvDY44p7EK2yLPjwZro6YBRkk6SBhDC579oL96NGo5Mp1qxurtphJyrl59ruK+Nja3IvJ93F7YRM1I2UyESy1dMlSWPwK79saHqcqrfHag6vohoEPm7kJ8qJHTdhiu13W45+X+QzZfhm0U0rnJqHZX6MrDtYRCdWjnjK67oVvsChegiywkaWZygEr8f1mEaHPBoBrWyAvy+qkSPbHeRFB9WfNPEIAEbeHyb JNRDKLDT c0aEvuBhGCMy4jIMd4f68Vrw797iNBCrg5OG7VYoSQyz7rQXZawQbt/V5cyth1j/tgBDJrJOjnwV7WQ+j7BUoB67AglFaQW2HUw/zJPrpfss4rjon6Rpp0bpgHKx8NQWibIZzX/l3cGFKYvqLknIP8OMsd8+xcpwh3XuSbnsRmz7G6NETbNfO1l15bGQYjwb1GJHMxP2aqgtfp3Yeh166mIp4a4xXOA43PceEPeQYbA+NsbJp4LHN3Kj2VA7TMfhDw6av1Rmo1mj0gjEVdsx0ZKxKrd8gBzj9obF7EsVGSU/3J/d2WG+oKGkOqoYJLUGOhVEgNftxryac/6A= 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 Thu, 12 Dec 2024 17:00:09 +0100 Sebastian Sewior wrote: > > The lockig of the raw_spinlock_t has irqsave. Correct. But not because > it expects to be called in interrupt disabled context or an actual > interrupt. It was _irq() but got changed because it is used in the early > init code and would unconditionally enable interrupts which should > remain disabled. > Yep, I understand that. My point was that because it does it this way, it should also work in hard interrupt context. But it doesn't! Looking deeper, I do not think this is safe from interrupt context! I'm looking at the rt_mutex_slowlock_block(): if (waiter == rt_mutex_top_waiter(lock)) owner = rt_mutex_owner(lock); else owner = NULL; raw_spin_unlock_irq(&lock->wait_lock); if (!owner || !rtmutex_spin_on_owner(lock, waiter, owner)) rt_mutex_schedule(); If we take an interrupt right after the raw_spin_unlock_irq() and then do a trylock on an rt_mutex in the interrupt and it gets the lock. The task is now both blocked on a lock and also holding a lock that's later in the chain. I'm not sure the PI logic can handle such a case. That is, we have in the chain of the task: lock A (blocked-waiting-for-lock) -> lock B (taken in interrupt) If another task blocks on B, it will reverse order the lock logic. It will see the owner is the task, but the task is blocked on A, the PI logic assumes that for such a case, the lock order would be: B -> A 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. -- Steve