From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 96E6E39DBC4 for ; Mon, 16 Mar 2026 15:05:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773673522; cv=none; b=OuxY6YvXJ+5GuOwHO9QG5z3yltrUzL5/2KXDNg6B6Cglc68yhLjFXX1YLX+O16Fpvh8Gjl8HJleKrNRRB/7bMUmBRLBTtmkdAHLBc6e3+49L834StqhYcxFH0nZKA7HTcnwrl3u2Tt+SG+orMEzjmDzBkU4gbzrYly3vMUGC398= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773673522; c=relaxed/simple; bh=RnzelXQEhcmD1T1EIc3JYmO2mAx5i3ChXWZTRK+KT6E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MYcuVkunVpmMJyFr5t3qqYJu48TjvO6a8dMU6crVDvpJVK+IxHqZ4AKkwKemhHiEhEg7jqemL2SoX9bTyA21HlLI6bOLD+L3s3o9RYI9DOLKzb6hp1dPKSokgqDNG7WMAxW+h/N2qf59EJrVNvOrROYAW5zuNbN9EN9XF/xN0o4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hUS7nlHy; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hUS7nlHy" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-48535a0ef86so39280015e9.1 for ; Mon, 16 Mar 2026 08:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773673518; x=1774278318; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Gqco5SPEd6UaXLI10tvcOr9r7x/pSR9Rg9OAhUkP36s=; b=hUS7nlHyle7WeHcHg7sagZtDpm3MfyYPIVSEJToV9Y7WU5ONqqxdP0ET829XxrhXKi fppHrvTyudMI2SIhx+yAxkDsnHX3+YQTk0Uq0HuY03R1cTGXnxXhayTmCi2eXU9AjgW6 C+Ppjaeo0ZL7uh5U7LBowOvMm1NUOVqapaiJOC2Rp2pgQv4iOghEPddJRDY+nb7SPxNe lXOSgiAWeYcjTxA9MN/nkV9lgoJTfO9nKLRi8C5w9VRL8Aseks/J+Uf3MOgLWn8DqCKY V/n2Yu5bPhdTgMfCox0DE7tydzanNvR+OhY+/j/Q4PnjjMGUcsgrDHNxnNVtJ3069yPk EbAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773673518; x=1774278318; h=in-reply-to:content-disposition: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; bh=Gqco5SPEd6UaXLI10tvcOr9r7x/pSR9Rg9OAhUkP36s=; b=BrbZcG9FvVr2KN9I62DsbUh9bf7YHlpKIv9X6P8IN/sPGKoGDNq4QVvnZ8PQRbZfn8 3jaSwcITdVbgMlAb/Gl4WqFLOtBhapQEeegAPFmOEtgA/UOa6NN4lJhYkYfeb1DuZSWC bPms8/HKTZNYJX7aqkXXEyLFMf//gOj5kksfc7qK6L9uhX9/x6SdRUUV7RVXtVriRxve lCH1uRXZJGNkAdr1O+vpBvFgXE+yAo4rVmNGohLTbaGv/D/g5+/71+IMCQIoSEy+GUsu THNmTl0W92YnExkRSIAwq7DfvrfO85vhUxqQrNLLOhCavGSqVWiJSM4MM3MbWJvHlMVo vicA== X-Forwarded-Encrypted: i=1; AJvYcCXAwB2kvSIyqhpBUJeEJ3FePQP+aDGZbioAn2HMolOQthqtbsPiBi7lIZ/ud2SNeHguYloiJXfTIhK7Qqc=@vger.kernel.org X-Gm-Message-State: AOJu0YyNGzTMpgDOqM5r9du3fdtTSwl/P7DEGGI5yVaiEjVJTf5TYnyR SwYujn+2bMwWvJEEWWQ7ebFm7PfaPh4lo3Zeu2MSaA0PIyHZ8RyWX22s X-Gm-Gg: ATEYQzywvuoFboWW+UbxZwqN/hbC59kNWwuQJooDfnoYWHf7kvmqWrmfTQ49qMkalmI vJgT6gdXqeJDprNSoXyktZhAhhI1DXYYD9cEJmlv9OnCM5isp1Psnqj7UChxV29QshmUm9OwB5W tAGJHSCdE5SpOTeA+rtfdkPh5tJGis3ukujAF0lVceHhs+/TqUMetfggLi3h2q8LWkf1LVeRYdj gfOjKprrerO/pY6ueTp5mZ4pXwbdarP9jRbWGdNAF9GkXF4TfL+eRaZKguUhcuZcfas1qrPEVyL PXVnDTF5EPvL1IwSDM2T+hXWpIL0jHFcXK+As9nVzAa6F5oEMvgN42ptpJ/FlqKbqA1NDWGKqmH Xxdl9IIlDLXmMz+gvcasBJ+/3Vr5m97EQ6G2e+tu1ZZpGCmqdFzTmuTT3UVV9ZBuuTUx36Gtdhl O3+YSwfcPMa3LLFoCm7hL4mWjWuPU7rI7AI3dxg6ujMkATELOaRCI3q5mkgJ9U1ne/78Dw9biwb myjQqFPyGlLDvQ3u5XbydaOT9v2iwTIAHsLpOUBp0+Elyy+GulrbNf/Z6ezbXZ8kGsn90VOTqvc 0lYw2mGva+Q= X-Received: by 2002:a05:600c:8b2c:b0:485:4bd1:4c7e with SMTP id 5b1f17b1804b1-485567148e8mr223653815e9.33.1773673517657; Mon, 16 Mar 2026 08:05:17 -0700 (PDT) Received: from mail.gmail.com (2a01cb0889497e0077fb9a9968087a66.ipv6.abo.wanadoo.fr. [2a01:cb08:8949:7e00:77fb:9a99:6808:7a66]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4854b5f6c24sm398807025e9.5.2026.03.16.08.05.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 08:05:16 -0700 (PDT) Date: Mon, 16 Mar 2026 16:05:14 +0100 From: Paul Chaignon To: rsworktech@outlook.com Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Amery Hung , linux-riscv@lists.infradead.org, stable@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH bpf v3] bpf: do not use kmalloc_nolock when !HAVE_CMPXCHG_DOUBLE Message-ID: References: <20260315-bpf-kmalloc-nolock-v3-1-91c72bf91902@outlook.com> 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: <20260315-bpf-kmalloc-nolock-v3-1-91c72bf91902@outlook.com> On Sun, Mar 15, 2026 at 12:02:48AM +0800, Levi Zim via B4 Relay wrote: > From: Levi Zim > > kmalloc_nolock always fails for architectures that lack cmpxchg16b. > For example, this causes bpf_task_storage_get with flag > BPF_LOCAL_STORAGE_GET_F_CREATE to fails on riscv64 6.19 kernel. > > Fix it by enabling use_kmalloc_nolock only when HAVE_CMPXCHG_DOUBLE. > But leave the PREEMPT_RT case as is because it requires kmalloc_nolock > for correctness. Add a comment about this limitation that architecture's > lack of CMPXCHG_DOUBLE combined with PREEMPT_RT could make > bpf_local_storage_alloc always fail. > > Fixes: f484f4a3e058 ("bpf: Replace bpf memory allocator with kmalloc_nolock() in local storage") > Cc: stable@vger.kernel.org > Signed-off-by: Levi Zim > --- Note there may be something broken with your setup as lore is reporting that you sent this v3 email three times. Not sure if it could be an issue. [...] > diff --git a/include/linux/bpf_local_storage.h b/include/linux/bpf_local_storage.h > index 8157e8da61d40..d8f2c5d63a80e 100644 > --- a/include/linux/bpf_local_storage.h > +++ b/include/linux/bpf_local_storage.h > @@ -18,6 +18,7 @@ > #include > > #define BPF_LOCAL_STORAGE_CACHE_SIZE 16 > +#define KMALLOC_NOLOCK_SUPPORTED IS_ENABLED(CONFIG_HAVE_CMPXCHG_DOUBLE) > > struct bpf_local_storage_map_bucket { > struct hlist_head list; > diff --git a/kernel/bpf/bpf_cgrp_storage.c b/kernel/bpf/bpf_cgrp_storage.c > index c2a2ead1f466d..cd18193c44058 100644 > --- a/kernel/bpf/bpf_cgrp_storage.c > +++ b/kernel/bpf/bpf_cgrp_storage.c > @@ -114,7 +114,8 @@ static int notsupp_get_next_key(struct bpf_map *map, void *key, void *next_key) > > static struct bpf_map *cgroup_storage_map_alloc(union bpf_attr *attr) > { > - return bpf_local_storage_map_alloc(attr, &cgroup_cache, true); > + return bpf_local_storage_map_alloc(attr, &cgroup_cache, > + KMALLOC_NOLOCK_SUPPORTED); > } > > static void cgroup_storage_map_free(struct bpf_map *map) > diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c > index 9c96a4477f81a..a6c240da87668 100644 > --- a/kernel/bpf/bpf_local_storage.c > +++ b/kernel/bpf/bpf_local_storage.c > @@ -893,6 +893,10 @@ bpf_local_storage_map_alloc(union bpf_attr *attr, > /* In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non > * preemptible context. Thus, enforce all storages to use > * kmalloc_nolock() when CONFIG_PREEMPT_RT is enabled. > + * > + * However, kmalloc_nolock would fail on architectures that do not > + * have CMPXCHG_DOUBLE. On such architectures with PREEMPT_RT, > + * bpf_local_storage_alloc would always fail. > */ > smap->use_kmalloc_nolock = IS_ENABLED(CONFIG_PREEMPT_RT) ? true : use_kmalloc_nolock; > > diff --git a/kernel/bpf/bpf_task_storage.c b/kernel/bpf/bpf_task_storage.c > index 605506792b5b4..6e8597edea314 100644 > --- a/kernel/bpf/bpf_task_storage.c > +++ b/kernel/bpf/bpf_task_storage.c > @@ -212,7 +212,8 @@ static int notsupp_get_next_key(struct bpf_map *map, void *key, void *next_key) > > static struct bpf_map *task_storage_map_alloc(union bpf_attr *attr) > { > - return bpf_local_storage_map_alloc(attr, &task_cache, true); > + return bpf_local_storage_map_alloc(attr, &task_cache, > + KMALLOC_NOLOCK_SUPPORTED); I can confirm that this does fix one selftest using BPF_LOCAL_STORAGE_GET_F_CREATE on riscv64: test_ls_map_kptr_ref1 in map_kptr. Other tests using BPF_LOCAL_STORAGE_GET_F_CREATE are still failing so I guess they have other issues. Tested-by: Paul Chaignon > } > > static void task_storage_map_free(struct bpf_map *map) > > --- > base-commit: e06e6b8001233241eb5b2e2791162f0585f50f4b > change-id: 20260314-bpf-kmalloc-nolock-60da80e613de > > Best regards, > -- > Levi Zim > > >