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 DA6D0C6FA82 for ; Thu, 22 Sep 2022 17:41:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4682940007; Thu, 22 Sep 2022 13:41:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA8386B0072; Thu, 22 Sep 2022 13:41:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C21A6940007; Thu, 22 Sep 2022 13:41:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ADB6D6B0071 for ; Thu, 22 Sep 2022 13:41:19 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 85FCB1A092C for ; Thu, 22 Sep 2022 17:41:19 +0000 (UTC) X-FDA: 79940437878.04.2D9BFE1 Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by imf10.hostedemail.com (Postfix) with ESMTP id 3F25AC005C for ; Thu, 22 Sep 2022 17:41:19 +0000 (UTC) Received: by mail-il1-f177.google.com with SMTP id y9so5261026ily.11 for ; Thu, 22 Sep 2022 10:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=AsxpWsr5dzcIncNfx/+Sw1HyEwfMiBKVAKBEW7wNeQA=; b=HG1BCa9aD7EruuXSP8vfBpl2xSAcB9NgvDE4n3t4WegezK8iPhrhfTbs3Xxfdxp/aP 0j4XfOQ90rYJJLxvR5Fxutq+CKSR+3NwG5g3gHNWC0rGeSJkCPwM1qeiyt5MoX9kie1E Ogc+09wvN660uSYqTrtW/DY7BHEKikOuBqjuMNkdFuICid58Qmi9sfyROy/V1LgkIpE7 e2Nv1gEo4Vp0GQpWl3bRqM1059jceqcIcZbW6os/ZnPJ8J1PnWKNgSi8e2+WYP/WJpYk +8abyMsCFGIX1fgDuD8Pv5kCGUDjVFxUFNtnD5auEWqa0LNmLWv9bnrrUipYT443cCtB +LNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=AsxpWsr5dzcIncNfx/+Sw1HyEwfMiBKVAKBEW7wNeQA=; b=wjuwI2odrWMoHqiAqRBhdpzqhmBpKnNDOkXymLrrG/VXxZ30izVQf1yEnOeR7ZdGRx NwyTyTOKlhi1iDH8A6zDBAYGKLbt3JqID6Dxxx5YxUa/uJUHVTP7neXj8jKK9Mm4h5mS rvDfjLHag23tqkR1cf0L4Q7EuD7BpHPeUjZpxrzRqRvQiFQd/X8WLmJvbaXlpeDLc9kq vkk99Kjx4QpuO8sIYYdy/1l/icmM4JhLyQPX5DIFoom+CU14mXxQfwpheM6xdnCSFQMH cFSEMcosXvsiPmrfp+yElPFmCARQGf01Ivf57SbyJu2lQh7dfL6uhCAar/AKqjdTrGkO vdBg== X-Gm-Message-State: ACrzQf2rOeqeQcgQog9TH6P2chA25SLZwN40EE0ozDBsFtcBc1exSsNH 8cLmqAzfgJ9rjsMgsxhZDOPTudTT0QIfYiY4W9U= X-Google-Smtp-Source: AMsMyM5Iawxjt3SoOGTNllk8NVk3tyvcsl1U/lS7sz1j/GB7JoPgBuMEGvT0T6zJ1tbupUccXP7nLvzrv1dgRwQijjQ= X-Received: by 2002:a05:6e02:152a:b0:2f6:58ae:ff0c with SMTP id i10-20020a056e02152a00b002f658aeff0cmr2429401ilu.237.1663868478589; Thu, 22 Sep 2022 10:41:18 -0700 (PDT) MIME-Version: 1.0 References: <20220922031013.2150682-1-keescook@chromium.org> <20220922031013.2150682-12-keescook@chromium.org> <202209220855.B8DA16E@keescook> In-Reply-To: <202209220855.B8DA16E@keescook> From: Miguel Ojeda Date: Thu, 22 Sep 2022 19:41:07 +0200 Message-ID: Subject: Re: [PATCH 11/12] slab: Remove __malloc attribute from realloc functions To: Kees Cook Cc: Vlastimil Babka , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Nick Desaulniers , Hao Luo , Marco Elver , linux-mm@kvack.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Greg Kroah-Hartman , Alex Elder , Josef Bacik , David Sterba , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Jesse Brandeburg , Daniel Micay , Yonghong Song , Miguel Ojeda , Feng Tang , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, dev@openvswitch.org, x86@kernel.org, linux-wireless@vger.kernel.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663868479; 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=AsxpWsr5dzcIncNfx/+Sw1HyEwfMiBKVAKBEW7wNeQA=; b=ezgodurhNnotWYJ4QHBl0osFnBtOApeLz+J9DjCbN7lA4bFjsZnDMPzztgPyOCUbZYAnmT L8qghuM78hXLqoNIG6VFfu4Z1KbZarFnpg9cNy38sZKtXfovU67dj54euAjH3hM65sknwk nRpVfGM2KH/lk+XOeqoBeJ8GKMSGoGI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HG1BCa9a; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.166.177 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663868479; a=rsa-sha256; cv=none; b=q1X8IEWOafDmbkwybKTCuBSNYyFdMnbVSDUuKcKz7a6bNHj4ZvSH/G6j1glQ1cVuzUGmz9 RQ6/fDBcvcNhZpBqh9oSwfurMBLyvRkIgX4vTCSMPOdCVaI/IxbrUmxQg3xgzFQSSuFIg7 Bo9cTC8Nxdgei9qANFsp5YBWsv4Y/pw= Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HG1BCa9a; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.166.177 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com X-Rspam-User: X-Stat-Signature: uwanh1mjckpkyqyiq7gh5rw7bkrz65jb X-Rspamd-Queue-Id: 3F25AC005C X-Rspamd-Server: rspam06 X-HE-Tag: 1663868479-950193 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: On Thu, Sep 22, 2022 at 5:56 PM Kees Cook wrote: > > I wasn't sure if this "composite macro" was sane there, especially since > it would be using __malloc before it was defined, etc. Would you prefer > I move it? Hmm... On one hand, they end up being attributes, so it could make sense to have them there (after all, the big advantage of that header is that there is no `#ifdef` nest like in others, and that it is only for attributes). On the other hand, you are right that the file so far is intended to be as simple as possible (`__always_inline` having an extra `inline` and `fallthrough` would be closest outliers), so if we do it, I would prefer to do so in an independent series that carries its own rationale. So I would leave the patch as it is here. Cheers, Miguel