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 93013C28B2F for ; Sat, 15 Mar 2025 18:31:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27BA9280003; Sat, 15 Mar 2025 14:31:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 22B70280002; Sat, 15 Mar 2025 14:31:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F420280003; Sat, 15 Mar 2025 14:31:45 -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 E636E280002 for ; Sat, 15 Mar 2025 14:31:44 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4F7978149C for ; Sat, 15 Mar 2025 18:31:45 +0000 (UTC) X-FDA: 83224628970.25.3896127 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf16.hostedemail.com (Postfix) with ESMTP id 1532C180008 for ; Sat, 15 Mar 2025 18:31:42 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=LnPVyX8c; spf=pass (imf16.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742063503; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fUg4fCMuPkYhbF/nCEDejVAU0bc8GhrExOsFutZjexE=; b=vtNDT2YG1S8K66Nq4kwVaqtWoUqzCFAcfC5JlwTlVwm/2loARf/ZWVi1244ZHp0IjES3du BMUMXLMgFCrqObngaW3ZyRJZyMKRl8NPsTwZpy4SjcXkeunrETP0f/h7k8O26kPXBPB2OQ PWFKm8+BYx+OsRoL8KiEahgTbg+5kHc= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=LnPVyX8c; spf=pass (imf16.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742063503; a=rsa-sha256; cv=none; b=g7yy70QpfB0DRGdVhTaHxJLZRIuUcZcNMSInWWCha5Vx2vdBvaoTc27DanGrb2zgORrfKQ djJzrRT5uBLhmTehB0TO3MKjrMCUzTIAjzndndvgqZQwHAZgKrB/jiMwdqTW5a9kFBpxji F5dv84vPITGBZ4pcK1/5W8dlqGZvH5w= Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5e5b572e45cso5799333a12.0 for ; Sat, 15 Mar 2025 11:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1742063501; x=1742668301; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fUg4fCMuPkYhbF/nCEDejVAU0bc8GhrExOsFutZjexE=; b=LnPVyX8ctQhW6f/G8GUp2yzW8xeC8XaFhqrdVToBPXY4D1kRAinLdD6v4G0fDGB1/s z6iJgSynr4lCIfTt4QvwOJ3ZZuoujZgq/WRfI5vF0gPZjoTt3ALreKsuSJQvKA3UxvCK VVs4oXvJS67qK2M7yQU0vVv4Ux+x6Vv0/jo3o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742063501; x=1742668301; h=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=fUg4fCMuPkYhbF/nCEDejVAU0bc8GhrExOsFutZjexE=; b=CsFwMZAJskxR+CkG64zT4OWAAu6Ardu1ULJwcPO/OLhqeWpFTdSckI/n2U2SsyEkgH b0/zHbbuIXvoLuhZEm2CQDdlxooo7QRrBDpdVvQdVx4g9WWK2lXJlPu9AstbQxRavgRx xlPgR/gn8ctvPDMJjSx18QK9HpXFgjMxeAHFilhvCkW6gvaLBbm2M95i8e103oK5dCdP Nwv4Mapb2l51xEd7aN0T8wTj48VFCEYtzVvevXAH6mrTARqeJcWhwCFhzGg4N0idyHX0 7Hv8xwZSWp1gWcrE9DrwgHS7HEv03YbW2aOMHWpwGYd6EF5Rsrx53t9RKQq+6gucEikM sfCw== X-Forwarded-Encrypted: i=1; AJvYcCXOcWAH20f3euxr8oOXdzM7oZXMBqlij92v3mCstIPP3XQb4hSwR5h7uKhZZxO0/52EsQZk7ciE+Q==@kvack.org X-Gm-Message-State: AOJu0YzPVb0ETJTpjwvY/kMoNuIvjoW69V/hjqCHb5Ih7BnYsBny/o48 /g+qaqdgs+XPCa144i9nUls71uYdR+bXWywY1fCAVoDKSCtErFRsQ7kIThkowFuRMNRPC5H+L3q B8iM= X-Gm-Gg: ASbGncupWA0e+Yi4p72X0iSTl3UoSeLShh3DHW4Q2m8P6gSYpTC8+lHvAv5fWkwdJrD 0/hi5DolZkykZgx1rbC6fPUbB0Gj2yG3IBEMjbgwasA0ESOgncY3Riw6e/U6QUIA/ylhyOEYIsX rs8B+U0C2ohM5jxG0jgDEXkTY92KRKYZDoQloDgiClrIhNtC6tbePwqdmz8iYP6F4+hcBDl86Uj wpjCiwc8AFYcE+SSiDRqOTBiRM0IdT6nwfTp49x8DZbtgA9iGbrp5PRCfLf02gDq6GhTMh9SKl2 B5BLgjkRocESKm7fhixEN2sH5iStzZGW9b2hj3xkf46JOqinFtC13l6tbWUC2Hjy1nkqiQQNCpK J37/W8Q1/CSMWMYMPBhE= X-Google-Smtp-Source: AGHT+IH40010Ph5TCoLp99sgNVHogzV5on6GRtD4XUELisW8TH8A/C1iuFbiqOUXzAYMzAZiWBD3Zg== X-Received: by 2002:a05:6402:518a:b0:5de:de2c:ea90 with SMTP id 4fb4d7f45d1cf-5e89f741299mr7970595a12.11.1742063501056; Sat, 15 Mar 2025 11:31:41 -0700 (PDT) Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com. [209.85.218.46]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e816974740sm3529369a12.26.2025.03.15.11.31.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Mar 2025 11:31:39 -0700 (PDT) Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-ac2dfdf3c38so582318966b.3 for ; Sat, 15 Mar 2025 11:31:38 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUtOFzIvDR9khJ9urgLPylJ90lxhsaBrmzd+QDyDx6Ou92yEbHV5LO03igoARhFBUwHqmExybaDyw==@kvack.org X-Received: by 2002:a17:907:6e8d:b0:ac3:47ad:41e8 with SMTP id a640c23a62f3a-ac347ad42e1mr292577866b.1.1742063497897; Sat, 15 Mar 2025 11:31:37 -0700 (PDT) MIME-Version: 1.0 References: <20250315025852.it.568-kees@kernel.org> <20250315031550.473587-2-kees@kernel.org> In-Reply-To: <20250315031550.473587-2-kees@kernel.org> From: Linus Torvalds Date: Sat, 15 Mar 2025 08:31:21 -1000 X-Gmail-Original-Message-ID: X-Gm-Features: AQ5f1JqnUqw5FSbsGnxD4hWFlYlctW64jtsJobEgwKJ2Lw8II8J0HunpM362-9I Message-ID: Subject: Re: [PATCH v4 2/2] slab: Introduce kmalloc_obj() and family To: Kees Cook Cc: Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Gustavo A . R . Silva" , Bill Wendling , Justin Stitt , Jann Horn , Przemek Kitszel , Marco Elver , Greg Kroah-Hartman , Sasha Levin , linux-mm@kvack.org, Miguel Ojeda , Nathan Chancellor , Peter Zijlstra , Nick Desaulniers , Jonathan Corbet , Jakub Kicinski , Yafang Shao , Tony Ambardar , Alexander Lobakin , Jan Hendrik Farr , Alexander Potapenko , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 1532C180008 X-Rspamd-Server: rspam03 X-Stat-Signature: getkifsmmohomhc8ijjr98hupa7xzk9p X-HE-Tag: 1742063502-194495 X-HE-Meta: U2FsdGVkX18/MkSQOU/I3Lsk0lXZP2LhHJRrlpzIvcmAvq42/ioF3+rG5g3lWFDuBKkOPaGzaqIzqS82QTy2QRY2IwRZonx5scHebLuuT40+yP/rLXLbt9mSAh/r1A6jrW5iof+Wn+3CzqOEKE5h3t2FQtGqcD8j4dE4dOBgebELbENrIoFI19m6KhT8y1eeeEkAcw/NPcZTQUpgUj+Oq3/KR2D4/OOWxyfnBiS3I6Cmua+jGd7TWkRncS2Lq1l8AHBEcS+gKeT+0TnMTyr35JE5buhcCCXC6CSl9HMguoMWK6BvKfggTco6r+d177XzTBfZ/uE9M97wXadegy6FIWg/plzDMFRJRdXhFNSTY7AQTR2ZMopJMJXjJbBB139WW5U+VggnYYGYmmTWdrbep+pL0yRoCOG13OC/zPRW7wj4X+qhdxhchKvLWUDthAtatt0Wu0dtnoYIBBnf6dwDaZhrxrgWQxzy6326HVFeMepWbeqeWSb6ZePv8s2hAzmYZBpX6ehZGOQHrRohofwHzUblh5+PPZhaA7YZUHg1oOTE78aeoZgbvXSvQmLstbDq74fcZd/eESzZZhoCaICqZxBDnFUPhLvArDzOsOaE5H/kjNLzaZcU8uUw4PBdDbmh6b5psB2F/8HbErHsMBrrDZhA31VY5HV+oGX0+0/N2K1WUTxw2DCi63FrsSMa51dtah3MNaAg/qVD+o5H4hmuSSklefmHhLQRqtW8hkHTHOK7yIhciZBnoYeFYu4UeOj1Zuf1xJHMd7UxliX/fRO+EN/ruUYVBnBzpu5avDF3kXSiBcYwvyn3Hri2fM21M3HaGTVSV1gi/BELy/WeCMKZl3dADNFD5xkN/5PLVUGw4uCtBrjhYP7v52N1RgqURHSHVcuwZrvR4eBJ0AS0J7CYUe/H86v8ayy3mpfcnQS29VewJYII6vqlYkICPpRp+hUpxzIRSbkR1rcyDlBvjoE xny2J9mF 8nG3TLgUyMTBins8iylXqpiS/hkuocoIfK/FtL2HsW5ypAsuaPN0g3hShSMbvVgah0aHpIrwzxL+3eFi8RAeTiySVUTDZxQe61R28hoxNAPiJ/9piw8wgeq6H8NajNY1nxBriCWpQdq+JJTs22yJZwhaomybhqGkMmYJmX+fzA/RylewYQvj/ynuNgQDyI1bvRfBFYUWre0yaYUzZLCdK0brH2lSkhowE1fo9PIi4tmp+t3o9KaUOhA85H9M/6D4TSWs0er1mhcjV4xuv64LJPUL4AEUvB+FU5a6t5QUnXI03CRF+npbbfN5L1sg1RH47mMJcvCin4nikq6pKJWBYE29ogCX0Hmuvjx8XLqtj/y+XZ1l304c6ubp6s6JxAKsEoX3VwQPgeP5/bo4PQc7D8Sw/1uFa9NxkBT0mTW3oCAduvYYYKgZgXBl8alFgOxYnQCPbjqyY/ZCv0thueD+r6svnkmpV4hXTnIuXIHAc/dG3v+lUMUZmyaGUV7MIJPxhAJqmjvsVUXCaPHKK3egpqAdcZ7NerEMMkozgriuWG4AdZkdrwaMRzNi9eHToo1YJoblnyW7LSqf6ivPkirxm7qTn2GYXXTUiT6idL7kYh6/Woc231P/4a99Flp0UKe5crbUwPIokR0cl9xySRWVnkra0Vw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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, 14 Mar 2025 at 17:15, Kees Cook wrote: > > Introduce type-aware kmalloc-family helpers to replace the common > idioms for single, array, and flexible object allocations: > > kmalloc_obj(ptr, gfp); > [ ... ] Honestly, I absolutely hate this. Don't do this. It's a huge mistake. Yes, it's a really easy and convenient interface to use. And it's a ABSOLUTELY HORRENDOUSLY BAD interface to actually then *maintain*. Why? Because it's simply visually and syntactically entirely wrong. It's much much too easy to miss that there's an assignment there, because the assignment is hidden inside that macro that visually looks like a function call. So when you scan the code, the data flow becomes very hard to see. So no. A hard NAK on this. It's wrong, it's bad, and it's crap. Maintaining code is AT LEAST as important as writing it, and arguably much more so. And making code and data flow visually clear is important, and this is actively detrimental to that. So I understand why you want to do this, but no, this is absolutely not the way to do it. It needs at a minimum some way to make it very very visually clear that this is an assignment to 'ptr', and honestly, I do not see how to do that cleanly. Alternatively, this might be acceptable if the syntax makes mistakes much harder to do. So for example, if it wasn't just an assignment, but also declared the 'ptr' variable, maybe it would become much safer simply because it would make the compiler warn about mis-uses. Using visual cues (something that makes it look like it's not a regular function call) might also help. The traditional C way is obviously to use ALL_CAPS() names, which is how we visually show "this is a macro that doesn't necessarily work like the normal stuff". Some variation of that might help the fundamental issue with your horrendous thing. But something very serious needs to be done before this is acceptable. Because no, the advantage of writing kmalloc_obj(ptr, gfp); instead of ptr = kmalloc(sizeof(*ptr), gfp); is absolutely NOT worth the horrendous disadvantages of that disgusting and wrong syntax. You saved a handful of characters, and made the code faster to write, at the cost of making the result be much worse. My suggestion would be to look at some bigger pattern, maybe including that declaration. To take a real example matching that kind of pattern, we have struct mod_unload_taint *mod_taint; ... mod_taint = kmalloc(sizeof(*mod_taint), GFP_KERNEL); and maybe those *two* lines could be combined into something saner like ALLOC(mod_taint, struct mod_unload_taint, GFP_KERNEL); which would stand out visually (which is admittedly very different from being "pretty" ;), and would also save you some typing because it also gets rid of the declaration. We allow declarations in the middle of code these days because we needed it for the guarding macros, so this would be a new kind of interface that dos that. And no, I'm not married to that disgusting "ALLOC()" thing. I'm throwing it out not as TheSOlution(tm), but as a "this interface absolutely needs clarity and must stand out syntactically both to humans and the compiler". Linus