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 EAB2CE7717F for ; Fri, 13 Dec 2024 18:44:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B0A16B0085; Fri, 13 Dec 2024 13:44:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55FB06B0088; Fri, 13 Dec 2024 13:44:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 427B16B0089; Fri, 13 Dec 2024 13:44:45 -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 246526B0085 for ; Fri, 13 Dec 2024 13:44:45 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3395E161061 for ; Fri, 13 Dec 2024 18:44:41 +0000 (UTC) X-FDA: 82890811710.29.3552DA8 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf16.hostedemail.com (Postfix) with ESMTP id CBA3318000F for ; Fri, 13 Dec 2024 18:44:12 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="DoyoGM7/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734115467; a=rsa-sha256; cv=none; b=fxdcF1YWUnSgL1ysEHyr1H6OxzSMT9bZLL4K0rNfZ6aoulJhDXA4EAtrZbyRzyt4lDl69a E0VPopQ9M4fMf3pbsdX95EyCYGtRdbjyNz3xu0voDJtdotfeYpId3oy/m1MLeiPN3oMQe6 ST6S/tk7L54ulBpzZbeDRW3h0xb6EmQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="DoyoGM7/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734115467; 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:dkim-signature; bh=BrSCJE+EGfJUskmDWEJ6FaLoRajg4WYRBr19oClqqVA=; b=Tgjd0detCjB2YAOVRkdLGgVQHQoLSQ9eH6qhYexO4M+Mi1JrhT0NVl1uKrY05ZLEUxhziF nZ51IOfCqJhFlnHym+xSB1Hq1UN70pywNfzJPO//KvaeFHO2etA3Xsid43ff7FE8qGoAYF vkyAi06Y1M6v3kitPLwCqxJIviJax8c= Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-3862df95f92so1109248f8f.2 for ; Fri, 13 Dec 2024 10:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734115478; x=1734720278; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BrSCJE+EGfJUskmDWEJ6FaLoRajg4WYRBr19oClqqVA=; b=DoyoGM7/SOUXQP7FEhVgZ/WGsoVF71rDmZ3gRcjln/2clGxmxqUgU7bD3so+jNe4hk vKygXlmclYUQp3UOvkAdqvYJ418lmtvjyHZrgGk+LKfnm+lwZOfb99v3xrx3PMdWkv7W YoNMckhBrUfpg8NePTmKT88zqnClM9yooJwUBSkISqG0w1RZ5IrWe5BzlBQIiJqgRjKT JXHwHImSMWTMqwJ0Mfin2tnLFSzqrTDzZFW2qY206DFvj/QdA3lpHclIuxxjs2V1a635 chVRleupf6CuI0f0+k45fDyTBpZ0t0AWhiEdbZ+JH8FDWvwFM3HcLHVIF0hKd6wcP9kA S6QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734115478; x=1734720278; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BrSCJE+EGfJUskmDWEJ6FaLoRajg4WYRBr19oClqqVA=; b=YtoNJdCSqY7zTpKC3RBU2awLlH1nPm6z67Bw7bS+8LeK57fvLYfre1vnnf1/IlMxwH HX1BJZ0/t4fdBkA1YEVKWjDcxZrsbJhPyAWYznhnqRBhXNsC5fm7FsZjQ826oGKVZnh3 Bqz1xGtHppzBQHQEt/ERRvXVSoBSXLpypffR6vIVV1aQKXTKObKhI57nrMEE6G7tvxN+ yYippX81ofIQjagy4qsGa54xq8z4bQTFMMQP8DmqP9ggvoA2rzNsm+j304DpPiit4VD4 kYPiiCqCXMgKUZOk2QAiXZg9VcdVIxyDqlaGfOUUEuGGRHZKHuLPPJ/zMFSDRp4ePLOI 9B6Q== X-Forwarded-Encrypted: i=1; AJvYcCW2NfeC/+fel8g6ZpgTfAZay489/6dHylK+8wqaBIe3cjVZSJb++HrqaYaTH6cHySbx5RfnlYLY7Q==@kvack.org X-Gm-Message-State: AOJu0YyMrfTYN+odDOPxcXttiJ5F9sxhZ814XJtW8j44c3ExSPWqKrc8 txNL8fu3ABB6E2wRrawBYqC0PzKK9iQPsOjhmz3JlwNRMjrX6ICyuIzJ6WoeQEUYYUxBztFxJBi iSgjKKeRrRIUi4SsQ03gOhWWubcA= X-Gm-Gg: ASbGncu4ttZtP5O5+oiwBUAy9VzTr8Hj6uAwUb1kwyNiFAx838DkyPInmINEtV+AwS6 bkWB3OdBd7My5LLn9ZdBzot8cBc0jlSF+VdmmT0gcd+37omozUw1jP6yW4uIbeAzRBiDBDA== X-Google-Smtp-Source: AGHT+IFZcpiXKP/ZcONpx5vmGIX9lMq29yMBYpt8oS6CIF6nJKSM0r5W8OGVJ2YUpoiuuO1uWwmS0SPMb+X65HN6SlE= X-Received: by 2002:a05:6000:4709:b0:386:3803:bbd8 with SMTP id ffacd0b85a97d-3888e0c4d35mr2989495f8f.59.1734115477492; Fri, 13 Dec 2024 10:44:37 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <20241213124411.105d0f33@gandalf.local.home> From: Alexei Starovoitov Date: Fri, 13 Dec 2024 10:44:26 -0800 Message-ID: Subject: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation To: Steven Rostedt 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CBA3318000F X-Stat-Signature: gkp4kab88zj3qhjbe65kzzkn65adni9f X-HE-Tag: 1734115452-753195 X-HE-Meta: U2FsdGVkX1+5kslP5B6trwfOQp2sSrykdsWBZdUWddywWSKpF+m+AFej8dFA29mOXjCvbVvTb2KGOgTAAkLRwFSY5fUO/llclxM8yciUU9FjaY3ku65sWJ1WR7yhQ779Qzbcda7kdAaQahP0Uisl/9WVulipFa4pTgbDLX4S+UPVGYQiwMuroLPtCJyRuSVmDJCFkpXhkVC9WNrxLeA2DBwJlsclFGV8b3dCJLe6+ubUbqanGilbovlqJVmunxFitNqoOxR4QTvWcydp/tk8Lr8GjpfTFZmO83zKy4OrvZjgWK5/E8vd7E81BQpjVdTEo0wQl3DA4UqMmXBOD1qbrl5cLh/v2lYx/RARnD7lud7yAHOb0zTUFk5LCqAQ+UNBqn2jz2uwyXK8dFA+IiO/GYW9uTC+BBbfeSfPs0H56d1q6EyRQvJdyDjKRFMDPJcjZyEnbR5PFXbQnrgujSjTY3vTzn8SLFIFPC/bs239QWq37XRgrdRFGWw1ro03CjiqGbVm4j6AwtV2H0ydmC8VuwGeLnkjuGZUIFfNvkShTBZRsUQboxyYrnWEngzn+lC2VMD3HWhIom5A6DkvKON3jgGRo7tgRizFXX+ww9cyf5fu1NpXzWbjkfu9wInbepv9bd5SHVhAnwH6LN981cXof2CoVGrGzC3yOLCFVEfkccTbwPuFb4bqKfwdA+4jnX4OHZ1o9CL1teKhUmWwsiKarKkkYzFe7XGJgW5MPxNKJ5QHrGt1Ez999yOniJdqpmXJyc6gJXnUs478KjmjTAgWYZxXGKeqK0/I3ZHnpe/onz6JddLBL8RT5eBvv6x9RmLqeiSRTB1dKiANqxv/mgjNlG70+LI5kd78pzTA5wdwIna1HIs6Nk/RT/5fvET1L90NmZD6WI125q02EsJ6sD+yiWMtpUNF4GDFZZBdgnQbNQxxUAvmbu2OGtubAp9j8Mh2TUcKippvIXFqw+n15/Q oW4rteSF HHgzRgfSXjPaOxzZ02iZ8iYzsy1j3qjNJkcveFQhNkG778r2gB3DOarJTR0/zlQvIqHclM+phFJghExDLw+ASmISfJA1+U6ZA3UMQ4Xt/r55gn3F72rVX40UfU7cC0Jx6nW+LqPduU88vESJS2zJ5BqP82Nv91YUN+ZlJl9buckXBDDD/3Lnv020yvplwcSLmB03GnxAdVVQ/7jZ0IIPn59mcDvNXTaMbJHQX26V1sZ5b6p0WG2uBa16JzcNWPYSSl2SE//PfnaazPpCKbXrIAmwPf42UMKujEPClkw3WFEKlXBV+NFZ0wMCGurGSU5wAp+h2Br/XlpTAyxGb18Q4SW7Z5v4ONhtRga4khqGRRra1QekiTMNod4PJflaECedeovYNmLT4s3aiEezfgkjgFs9SzrH7siOiiurjo0i6BxdrVPW5brgfgx4zDddm+x8XLcxsIj/89J9QWX8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000268, 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, Dec 13, 2024 at 9:43=E2=80=AFAM Steven Rostedt wrote: > > 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 earl= y > > 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 =3D=3D rt_mutex_top_waiter(lock)) > owner =3D rt_mutex_owner(lock); > else > owner =3D 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 wil= l > 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. 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 tas= k ? 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.