From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (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 6406F3431FA for ; Tue, 16 Dec 2025 11:26:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765884393; cv=none; b=NfTyAta1Jarbqx4ehjvpjtkoD6ePe3/zglpprFJf3gyNWcm9oY9Qb9ORmXQs2xskNSJ8dTKnUbfl3QKBOwmv8snhua1/3xeq3O9foqCpyPrLfsXgv4PI0hJYRY5D6gba4DEh5nVz64ODS3xRUbVYPL95BZ8HG/ztSemNuhWuDA4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765884393; c=relaxed/simple; bh=q9ZAtoPzV+0i8f8sOYySZ4a5kVA9GV/rbZS2hvoFQJA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=U4aEj9eNDN4qx4SF4B6FQ4m5qM7X/LjuxR7WZTzhlaaqion5NYUXq/6FZGvCRXzjdkhkWu2Y9N8Ii1xvd64ea8+9xPmPV2p9lGGjohdBaPkwa/5uTechMj3aQX5MiC+A3h6RJuMNczL+OwdlBdntxxUsq7+djodngDUnZAJxgLs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=qIeYZnvz; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qIeYZnvz" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-430fcf10287so1992546f8f.0 for ; Tue, 16 Dec 2025 03:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1765884390; x=1766489190; darn=lists.linux.dev; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=krMeQQo0RYkVVveyUInYgEYC1GtxSzSLPYvL0R6jcGk=; b=qIeYZnvzJRf7i7zt90aj1wi+KYqFZLw50sxkvkyKU1Io0QAuCSqta67KWmLgIC/M3s wCfCufKIHQt+rj7oumDgSZy/AERfgZmCUgvdJn2owQqcDCe1CnFACnGAmQDfN1C/L237 Z2FUYpWTwCtEDX4WV+b9bK36tj/bL8z4srvifN0a2QIh3rbEQlUQvdGk9010BzW8fXJK NpK3CkJtgh5/T3woRiWcfwSoRR7VuIgvC7xzzrtrMXc+vaNIX1+O9N/kcmcO57/zRZP9 3Z6G7xAhoy3CE3ODNzYcGtMpNcsnCVNsA8caoNFiR1E+yL4uoaG82XGplHnCQWHi5o6U ZcDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765884390; x=1766489190; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=krMeQQo0RYkVVveyUInYgEYC1GtxSzSLPYvL0R6jcGk=; b=pO8THik2EjbQGL8LKMVV+cgQUJxUn8fUR1pe7c7Vw+ZZsX9zfyHMRcSX5nRKjW1GdI vX1A4ynu7FtQEuczrv58ktJBRlJQNTAXWzMOBZ8PhIVajqli6EOHPEjRnfO5ORGJdvng kxcaf2wyabZ1f8B8RBTBjWqQdfwEScH3T4O0Z6hv8AKKBeImEtkBucPah/h6ofBifaGL tYs4gEb8xKxjxNtLck6avLfcw0z0W6fsPX6/mDcFTCdHKb8y3IsoKUj6LRITYsORHXRU lfv8kyBRxxf+ZnQvOMYoMTPw9aef5BkKFjbVmaWb+qCOjZbD9mKYpB8xG5e4FS062yO7 KMzA== X-Forwarded-Encrypted: i=1; AJvYcCVb2CgBoSXRIp6EXUYVWcBwcuJjA92Ul9XKIdf2IC1ZrP+jfe08t6BlhvLuPWP3sfESf8tfLn7/tLab5kixfg==@lists.linux.dev X-Gm-Message-State: AOJu0YxgDUScIJqiIX6av3XQdaQYU/9CbLp2Sx2jggIXweeVKsvmTdNR 4+337VkFZM/9Osk6Tx6mwVj4/766K6FbcwJQ5jLHEdH40Og5fpXfDENuG9PnQPewA3Ebat97ReV HKo2+OiPWIdHhxQ== X-Google-Smtp-Source: AGHT+IHRBFMdNHijFHNhfpSjk2TQJ9kZwXaGz3RsF4bB/Qt7P2NzdaKmXMouO4czF1ta3V3ssZTXVLAPCUMyQQ== X-Received: from wrrr18.prod.google.com ([2002:adf:a152:0:b0:427:87c:f46]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:310e:b0:430:fcda:4529 with SMTP id ffacd0b85a97d-430fcda47a1mr7553444f8f.61.1765884389671; Tue, 16 Dec 2025 03:26:29 -0800 (PST) Date: Tue, 16 Dec 2025 11:26:29 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-rt-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251212161832.2067134-1-yeoreum.yun@arm.com> <20251212161832.2067134-3-yeoreum.yun@arm.com> X-Mailer: aerc 0.21.0 Message-ID: Subject: Re: [PATCH 2/2] arm64: mmu: use pagetable_alloc_nolock() while stop_machine() From: Brendan Jackman To: Yeoreum Yun , Brendan Jackman Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue Dec 16, 2025 at 11:03 AM UTC, Yeoreum Yun wrote: > Hi Brendan, > >> On Mon Dec 15, 2025 at 10:06 AM UTC, Yeoreum Yun wrote: >> [snip] >> >> Overall I am feeling a bit uncomfortable about this use of _nolock, b= ut >> >> I am also feeling pretty ignorant about PREEMPT_RT and also about thi= s >> >> arm64 code, so I am hesitant to suggest alternatives, I hope someone >> >> else can offer some input here... >> > >> > I understand. However, as I mentioned earlier, >> > my main intention was to hear opinions specifically about memory conte= ntion. >> > >> > That said, if there is no memory contention, >> > I don=E2=80=99t think using the _nolock API is necessarily a bad appro= ach. >> >> >> > In fact, I believe a bigger issue is that, under PREEMPT_RT, >> > code that uses the regular memory allocation APIs may give users the f= alse impression >> > that those APIs are =E2=80=9Csafe to use,=E2=80=9D even though they ar= e not. >> >> Yeah, I share this concern. I would bet I have written code that's >> broken under PREEMPT_RT (luckily only in Google's kernel fork). The >> comment for GFP_ATOMIC says: >> >> * %GFP_ATOMIC users can not sleep and need the allocation to succeed. A= lower >> * watermark is applied to allow access to "atomic reserves". >> * The current implementation doesn't support NMI and few other strict >> * non-preemptive contexts (e.g. raw_spin_lock). The same applies to %GF= P_NOWAIT. >> >> It kinda sounds like it's supposed to be OK to use GFP_ATOMIC in a >> normal preempt_disable() context. So do you know exactly why it's >> invalid to use it in this stop_machine() context here? Maybe we need to >> update this comment. > > In non-PREEMPT_RT configurations, this is fine to use. > However, in PREEMPT_RT, it should not be used because > spin_lock becomes a sleepable lock backed by an rt-mutex. > > From Documentation/locking/locktypes.rst: > > The fact that PREEMPT_RT changes the lock category of spinlock_t and > rwlock_t from spinning to sleeping. > > As you know, all locks related to memory allocation > (e.g., zone_lock, PCP locks, etc.) use spin_lock, > which becomes sleepable under PREEMPT_RT. > > The callback of stop_machine() is executed in a preemption-disabled conte= xt > (see cpu_stopper_thread()). In this context, if it fails to acquire a spi= nlock > during memory allocation, > the task would be able to go to sleep while preemption is disabled, > which is an obviously problematic situation. But this is what I mean, doesn't this sound like the GFP_ATOMIC comment I quoted is wrong (or at least, it implies things which are wrong)? The comment refers specifically to raw_spin_lock() and "strict non-preemptive contexts". Which sounds like it is being written with PREEMPT_RT in mind. But that doesn't really match what you've said.