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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 153DBC6FA9E for ; Sat, 4 Mar 2023 20:19:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229717AbjCDUTM (ORCPT ); Sat, 4 Mar 2023 15:19:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229609AbjCDUTK (ORCPT ); Sat, 4 Mar 2023 15:19:10 -0500 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 119F990; Sat, 4 Mar 2023 12:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=m12OYazIp/kPA8ILuZmCQtNsNjkVovAMQd9c8AOvVGE=; b=nTRr3QDJ4g4SArWl29WAZzR0/w GGS1f4cbEphwNWxWEMKddY2phQGDmhhtYPVrFIfOCsg1ZaJu+ErW7uTQ1oy0eeYX3HBh8ubZCdC4e ZkLp6tKgn+ZExqvM1dvHtgGpVlDzx4xvDQgRbz5LWYD3lJWicu13DJn1l4Z174aWQeHdHms6b5QpA hxWev6Cl/xxVUjjW3GPkLAnR2WbzFwTNROrgp6vOD8N5EGLZmCy38CHbq4hFzIUHohVWxvFcCJVkW LXw2SMc/qJcUbDIHNvxVQM8kr8G4jBDzNT2nLvSOzxIyEaQNcEdI8/OGbPGkAvclb6oO7O2w1Irdx wM9yHWbw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1pYYLI-00DyIh-1D; Sat, 04 Mar 2023 20:18:56 +0000 Date: Sat, 4 Mar 2023 20:18:56 +0000 From: Al Viro To: Mateusz Guzik Cc: Linus Torvalds , Alexander Potapenko , Kees Cook , Eric Biggers , Christian Brauner , serge@hallyn.com, paul@paul-moore.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible Message-ID: References: <6400fedb.170a0220.ece29.04b8@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 03, 2023 at 09:39:11PM +0100, Mateusz Guzik wrote: > the allocation routine does not have any information about the size > available at compilation time, so has to resort to a memset call at > runtime. Instead, should this be: > > f = kmem_cache_alloc(...); > memset(f, 0, sizeof(*f)); > > ... the compiler could in principle inititalize stuff as indicated by > code and emit zerofill for the rest. Interestingly, last I checked > neither clang nor gcc knew how to do it, they instead resort to a full > sized memset anyway, which is quite a bummer. For struct file I wouldn't expect a win from that, TBH.