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 2C6B3C83F1A for ; Thu, 17 Jul 2025 16:24:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B09726B00AD; Thu, 17 Jul 2025 12:24:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8E86B00AE; Thu, 17 Jul 2025 12:24:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CF206B00B8; Thu, 17 Jul 2025 12:24:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8CF906B00AD for ; Thu, 17 Jul 2025 12:24:00 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 43EABB6512 for ; Thu, 17 Jul 2025 16:24:00 +0000 (UTC) X-FDA: 83674278240.26.06D05A3 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by imf21.hostedemail.com (Postfix) with ESMTP id 5A8731C000C for ; Thu, 17 Jul 2025 16:23:58 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U8Tngnq2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.51 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=1752769438; 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=Nk8MgKi5lPnsc5ClvbjZVmm59ODJhkuhBra1IO5r/SM=; b=hKaJQrRT7dLyiORBeUoyq2Sc38pHGVuzfGJQbpWmFYoxg7NMMiGJtZE+0ItWdfF9QJ3le9 h5lXyFYz0zaQD16vje2aKWLW6xyKh82Po2S0nlkgTDuyt2v7mxKn1/z6CdqFYAsM2TNNwW s3JZ8Kh1xIaS7UgTY82i6sFZGdEhe+w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752769438; a=rsa-sha256; cv=none; b=usvlw1xMd7qzmcYto92LbLD9DjmWy7LyVCzwNOO4r3r+pqU0FlepNXg1V8GIWi+f15eDW0 2Lxa5+573+N4YCpO1npJgVQXqbrBYPWVQTf3uqaE/X5oh8c/4dzWPGJcnwseP4vXuD/zjE NqS+9+D+3B+TbYr7tvz2aTUu6ULJyP8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U8Tngnq2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-3a6d1369d4eso735085f8f.2 for ; Thu, 17 Jul 2025 09:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752769437; x=1753374237; 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=Nk8MgKi5lPnsc5ClvbjZVmm59ODJhkuhBra1IO5r/SM=; b=U8Tngnq20c0X6JWR6Sb9z3Mndu3PMnELp0m8bYrB+QBYXucnBzzY3rmA7QWpE+hM3F KPyCYUe6ujSOym/SmjsneCEcDUSENaT/KXfksR3mljDhTqwYjfcWfFes2cGbVXs585zU QX891ZJoSP52qTQRuQ1xo4qtRX0pYXkcG0lNr/7P7sxDwpPgPgoSp0BwtZJUHn8//uhO vUR45HMIGd9ihPEozfulIEbCi3z7pdS6JSBoGHdoXhXryugIiDJDIXNx8VZMLk/HoO2o Zkw+SZ41pNRcEEofshRu2OJ1nIliDtuCM347LnyaCH2PucAOa555FWZyFCosyMvKzoqK JUYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752769437; x=1753374237; 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=Nk8MgKi5lPnsc5ClvbjZVmm59ODJhkuhBra1IO5r/SM=; b=bPdO5/ZmOpLVEmiAtmqfpE0cD6fOGF8uUL6xwEUZx+LPWHA7b+6TOb+E6E234K1zo9 vi9F8LIYbgLsi7xJiG7pOGKk3+fSQhuCOA+e/Thb+Xg/52iryV01UY5u6lr93ez2XTJ9 zXVaZX8EuGoLIqyOZ/DWmwGZUBqyx17adAl7VZzCpyM247EsR8JNfGFbG+LmRB80j3Cr f1Ysgq5BFZAKon5inL+jIDqa8vb2dbAeQJEABYGvRfERscP5U/PZq5LedaSPAT3v/V3w UvQiwtQgb4ZZ/ezw41ueiDZQsGCO3j7wUvMOMreStlcJavze05qR45gSV15+Hm/KDTEK Vbkw== X-Forwarded-Encrypted: i=1; AJvYcCWp2Y82pPzoXjpzZm1qzrYxqnH0F5Y/RwAtjqopXx3mXvYwZDl/ikqXgr1HchhrhCrtVtv0RHD5yw==@kvack.org X-Gm-Message-State: AOJu0YzKeiddU6SBREKFPExkhfxuxBsEk8PzYX8Uts/pUG5cZ9m5NSzu SaP7BZwDMdIOiHBBAixDG2QwHo0hW5nRdcvmj1JhguFo3NHcQPPLpgnF7J758yJEPRS/ew/ge0H Ct7hwsUrYZzcGoJ21Qe2xzb+03qMnqfI= X-Gm-Gg: ASbGncuWuhVD+g1ZjV/gZfwbV+yCWdYpOXh8xAriashgDAnEr54QJFhlQ+gOIoDh0wz kmZgGDNRgfctfeTqpbol++qROig5jol+uPiH+nWdbUlPox1XF1I/jA7Jsy9HFhThHbYVcZUr1Dt d4mXVFE+/YSlLKsxZCW0TtmhZJGAeisiEfHgh5CtMoCNfA+Av9SjrB+VFazMEOsFbA+e24UxV1y +YRpOMQTV89gYzF+0lu0s8= X-Google-Smtp-Source: AGHT+IGObr3+mK/nBSSAqr/4D47SeJcDylS1eU4gWKtCeotozAgGPtjm/iwky2NIR12Cx4hqxuLn+zfiCVR+CKHVt0o= X-Received: by 2002:a05:6000:25c3:b0:3a5:8a68:b815 with SMTP id ffacd0b85a97d-3b60dd996d8mr6556382f8f.46.1752769436470; Thu, 17 Jul 2025 09:23:56 -0700 (PDT) MIME-Version: 1.0 References: <20250716022950.69330-1-alexei.starovoitov@gmail.com> <20250716022950.69330-6-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Thu, 17 Jul 2025 09:23:43 -0700 X-Gm-Features: Ac12FXwzl8imCEsBuPqkG9NPDgHmLDQTXaLnFMmXbSPj6skZY9zJYfF0awK8QKc Message-ID: Subject: Re: [PATCH v3 5/6] slab: Introduce kmalloc_nolock() and kfree_nolock(). To: Vlastimil Babka Cc: bpf , linux-mm , Harry Yoo , Shakeel Butt , Michal Hocko , Sebastian Sewior , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Steven Rostedt , Johannes Weiner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: z814mbdsi3kbbmpxgs31b158ixyo7kiq X-Rspamd-Queue-Id: 5A8731C000C X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1752769438-989414 X-HE-Meta: U2FsdGVkX1/D5qeCgouAUUvYCLbnGRT+VStm0ZEwGujHM9zjVNidJRz65zQM4xa1YaOeo/rZ51h0hh4ChQtPffS2KTRUH0yDGcyDdjogpWftrHhlT2ckcyzGea1LLH63fdo19vW9JCFUPBtHaZIMXeKqhnYWBjBCMWpP/nX3+1bZ8cbdPKNHIvkM0dag3jJaVYu/uS0uU4/m2+xEVV3H4gUxmbicbGCvkklmTuGdNlflf0CY187ftzzm2qm97D0kE327dk+vSWnA0ebh3xNFVNZVtqMZc1Tx7y9+l2zbZRQpMJ+g3RsSkEwD2CDWVwu6fFmgqxydN20Z19k+ABV7fVF3l0qTdPpcW4TGXYYe6WVsOZ7R4rNsIBPwNIfbo9y28p3Z97N1A3VTIJR9axZEKwQ7Xsg1NWXCvo2vXytc7BKUi7h5MgTUfI6HdQ+6fWUN4IpehNA9e811DGN+mZpqYmfxOZzNwCPh2+VM44CLXD/P3RimynGk4YSFTwbrh4rOH6AVzzCOisOt9pE9ruLfLyxyZQqdUZUq016Yt9BN0ATZspeDuOKMnpuwwIKldp64cIyIyiP7tRAWZTZ/T3HeDvLvdhK0IaMEKYDkAGd1T66pAzbH99l7rWi2EEapHAra1utqv5VboluE/9C/Q41j3R8YNuGfaa8NRMUNHjNbmklt+ykU5csftjw63NnL24oqv3OEpxfEcSdPXCCcShHtwLS5OBN7EV8tQxUy8JpkCJNvHqdh2WFN0k/BxTdqoqUYbCyaH1Rz8wzxu3c+C8ShTuv6CJDBgagAHRwYTRqB82mpYmnOA/VAceE8wlj0qJFYFoNVouKe8JwX5bMubU9g/BOBMQw01Ie5XKBquJxc+SiQjhHjUJpa/zeWNQ6YTNarzx1TxozCrYKjcWDAyicujWcaaJlBZ3oPBSfTUKI0ZaZIjEYUtcsjqQvtwpOSLACcN9/5cZNODZJK1E3XFOj 6loKrkaj 1ycCvK15tPJ/mzJdDI+Tn7gfSvSs83+kHl4IgdfNvFFPzZEYuHThApT+oQa6Rlf6Pzr5kReiQrTgDYMiuFXFc2gQzvp+pOmUCPLfhsVXMMzJXs0XZQMHk7k2dMaLJzgq3+zrm0NGa+ZLXb2J/kRN65IRvcS/Sgyw9QFA6A/sewB96TbQZk0/uP9wFqECw2SJw4erkhH2FXUzBKEFed+jxPzSixV1lhTa5CN1YXf43lwRBmxecoU57ZYgYPaKtETkM6SLuoG6xemP40OjGHEqjIFh+SwMfiA0ezgcHoDCUC3iM3cNE3sNZi16tt5qQkEypzY+XI77dQwiH/Qzjq6DjgoS9/gR8Mz1NmrsW/gP/fWgP1najIcE4tam1hrOtR8OEA6C8tZ37bMd866ytYbPEBO8zgSNB/NnDADiHyZHunVOc9LFFku0EBw1czw== 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, Jul 17, 2025 at 2:18=E2=80=AFAM Vlastimil Babka wr= ote: > > > > > When "bool allow_spin" was there in Sebastian's version it definitely > > looked cleaner as a proper function, > > but now, if (!IS_ENABLED(CONFIG_PREEMPT_RT)) can be > > #ifdef CONFIG_PREEMPT_RT > > and the comment will look normal (without ugly backslashes) > > So yeah. I'll convert it to macro. > > To clarify, the ideal I think would be e.g. > > #if defined(CONFIG_PREEMPT_RT) || !defined(CONFIG_LOCKDEP) > > local_lock_irqsave(); > > #else > > lockdep_assert(local_trylock_irqsave()); > > #endif > > This should mean that without lockdep we just trust the code to be correc= t > (kmalloc_nolock() using local_lock_held() properly before calling here, a= nd > kmalloc() callers not being in an unsupported context, as before this > series) with no checking on both RT and !RT. > > With lockdep, on RT lockdep does its checking in local_lock_irqsave() > normally. On !RT we need to use trylock to avoid false positives in nmi, = but > lockdep_assert() will catch a bug still in case of a true positive. > > At least I hope I got it right... Yes. Exactly what I had in mind. > > My preference is to add a comment saying that only objects > > allocated by kmalloc_nolock() should be freed by kfree_nolock(). > > We could go with that until someone has a case for changing this, and the= n > handle kmemleak and kfence with defer_free()... Good. Will go with warning/comment for now. At least from bpf infra pov the context where free-ing is done is better controlled than allocation. Free is often in call_rcu() or call_rcu_tasks_trace() callback. Whereas the context of kmalloc_nolock() is impossible to predict when it comes to tracing bpf progs. So the issues from kmalloc_nolock() -> kfree() transition are more likely to occur, but bpf progs won't be using these primitives directly, of course. The existing layers of protection like bpf_obj_new()/bpf_obj_drop() will continue to be the interface. Fun fact... initially I was planning to implement kmalloc_nolock() only :) since bpf use case of freeing is after rcu and rcu_tasks_trace GP, but once I realized that slab is already recursive and kmalloc_nolock() has to be able to free deep inside, I figured I had to implement kfree_nolock() in the same patch. I'm talking about alloc_slab_obj_exts() -> vec =3D kmalloc_nolock() -> kfree_nolock(vec) path= .