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 A43ACC54E58 for ; Tue, 26 Mar 2024 02:17:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF2E76B0092; Mon, 25 Mar 2024 22:17:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D78826B0093; Mon, 25 Mar 2024 22:17:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCB036B0095; Mon, 25 Mar 2024 22:17:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A74636B0092 for ; Mon, 25 Mar 2024 22:17:24 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 848DE1C0A18 for ; Tue, 26 Mar 2024 02:17:24 +0000 (UTC) X-FDA: 81937578408.05.175FA9A Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by imf02.hostedemail.com (Postfix) with ESMTP id A42EF8000A for ; Tue, 26 Mar 2024 02:17:21 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="n2fEt/wz"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 198.175.65.16 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711419443; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KA2yrbdUGYuU2RNX6bqHhmZw2pr2BnHeu/QgVIFDK/s=; b=DWcAP8XsBoBhu0XzfYbSrsT1EJLULntYN0U9R7QWDVeU/7q2xlJp0K44btaGK3ADCS5d/6 b0C/iL/H56nTtB9IxwUC4iVPMsqOn/FqDPz1+1DCzfGDJaycCnzm3NGO5YEdylcbnfTSPu Xk2KQtC5dmFSr5bjNzE0CcLrv0PIehI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="n2fEt/wz"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 198.175.65.16 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711419443; a=rsa-sha256; cv=none; b=q38+cxUnsRhpz4/zw27jdUvq5RWjkBGds/93b34BjPV+740ISl1moAiZHFCmI6D1LeXIuB ovqjB6A4UP/Q2Da/LuLRJ2nLZYWFPOlZeANqESQ5bIKXkXErDRSwOEbYnLuOseR+AFh+Pk kuTrS+nJ/1tcX3l+1gS8WJ7i3rgvgyE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711419443; x=1742955443; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=1Q2Y9vtgXw1JXW1FsaqsQyB2Shfhn7MnIwpk2ZhDn1g=; b=n2fEt/wzxx8/Tsb3M4/J3VYrfVYF0JNfxNM+NztaxCO4wP5OdQjq1TrW j4crDcXGMkWNvIQzKxfIFbyBOu1lXJvttDtrb/GFcUkRIMuMkgjfIKF4j 0FlmvEEJJen+NnN2GotfRxXesaIzRXC0ApgcD8Nmbms3LafwQyqQfGqgi JeykckMGfRj6jCyWuHo4q2eRsFTWbUnW5tOq5EWJ8lZ/tv7xx8RN8k0s7 l23wqI6J3PtTWx3/mQ+dsHJFqnIqPnjHg08QGAouoXoEqiiLo0xOE6pPz mlTFFf6z/yDwJ/tMdlqoaekKp1As0j7e3OKMZWecnwccpEQAFldP1t6XH g==; X-IronPort-AV: E=McAfee;i="6600,9927,11024"; a="6564303" X-IronPort-AV: E=Sophos;i="6.07,154,1708416000"; d="scan'208";a="6564303" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 19:17:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,154,1708416000"; d="scan'208";a="20489897" Received: from rpwilson-mobl.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.251.11.187]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 19:17:16 -0700 From: Rick Edgecombe To: Liam.Howlett@oracle.com, akpm@linux-foundation.org, bp@alien8.de, broonie@kernel.org, christophe.leroy@csgroup.eu, dave.hansen@linux.intel.com, debug@rivosinc.com, hpa@zytor.com, keescook@chromium.org, kirill.shutemov@linux.intel.com, luto@kernel.org, mingo@redhat.com, peterz@infradead.org, tglx@linutronix.de, x86@kernel.org Cc: rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Helge Deller , "James E.J. Bottomley" , linux-parisc@vger.kernel.org Subject: [PATCH v4 08/14] parisc: Use initializer for struct vm_unmapped_area_info Date: Mon, 25 Mar 2024 19:16:50 -0700 Message-Id: <20240326021656.202649-9-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240326021656.202649-1-rick.p.edgecombe@intel.com> References: <20240326021656.202649-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: A42EF8000A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: m59bf4gfxm8e83kxu4yqddgpqz44uwan X-HE-Tag: 1711419441-607802 X-HE-Meta: U2FsdGVkX1/VjhimRdToZKVzogW60lC6Wj7QS0+EbTVP4uLSFrzF/JV4T3M+MTtw16bBvNtPYe4qsOXdp3BUXseYDWf3SEbUcQRrRasljTeIUELIKFaqNXFa2oWwGO3GZfXQGsKcIBsiySpk38emYLmRkY7VOgL3FWhRb2LNMayGhOmjwNEORvgK12hOYU+dQVsP4HmgZop+GOAKnsROXn1cA6m+Dn2G/o+VLTmWYmO85/v6CmXyz+lhcVXVECoj/4rOhBtYFBMuZVrxIKXqlSGyF7z1CO8RwBx55XXfEZMjHBd2wZCkelBugxkEPaTnovH62gzhffx4gMoYB43q+b75VJd0fvHhwOyPa76McfF+bFTQRqeC93XkhXXfwR5FPePvx+ejqV+Pd/q98CIczaTkChcIvj8Ja7se7suMpiF+/+r/2JFfSoDQMdeBf9w+yJ86s5cGU8pumZDbNdvFJzRNMbLDsMzS2ecuRjWRGcufCaeumeT/q/PSqnvDiT0M5tw3+yptFGDWkW2ULELcelEVIjadOyhRXkjF8SLZ9FL9gd7Yw+gMmaEYXJMbRt2zH2sDc0/I5hee2wHyyeKxbZSNYgA4KUg4n7jEhhPrWJVc7toFjR0NtC/XGa2RLc0XPxk3w8f57zlnxGinYYlIykm6Ez6IKBN3PpeMEP259WkFCnKSSEyeg+d52e6NT6CUN4DfTrlexQ50byIgYSEzfziV7gUASMwZgGtFNPhfYn7DnqPxDBJldV6hfb1A7Vv2iWnbz9x2WynoidSOGODEZOBUlkeAGH2l4tsTfonj6BI+RBgxrbVpsGPViv2s5R7QN8OI32fmULqU3K/WsGiXUIDaJwhTx6VqNQAQ4EToiAzkRUVhAdES+ZuseIsSMJ/3HiMC+SAwMIBndxQ+fN0emH6id8L02Is6UKD9Jfeb1O8IXDj6Uz0A0Q== 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: Future changes will need to add a new member to struct vm_unmapped_area_info. This would cause trouble for any call site that doesn't initialize the struct. Currently every caller sets each member manually, so if new members are added they will be uninitialized and the core code parsing the struct will see garbage in the new member. It could be possible to initialize the new member manually to 0 at each call site. This and a couple other options were discussed, and a working consensus (see links) was that in general the best way to accomplish this would be via static initialization with designated member initiators. Having some struct vm_unmapped_area_info instances not zero initialized will put those sites at risk of feeding garbage into vm_unmapped_area() if the convention is to zero initialize the struct and any new member addition misses a call site that initializes each member manually. It could be possible to leave the code mostly untouched, and just change the line: struct vm_unmapped_area_info info to: struct vm_unmapped_area_info info = {}; However, that would leave cleanup for the members that are manually set to zero, as it would no longer be required. So to be reduce the chance of bugs via uninitialized members, instead simply continue the process to initialize the struct this way tree wide. This will zero any unspecified members. Move the member initializers to the struct declaration when they are known at that time. Leave the members out that were manually initialized to zero, as this would be redundant for designated initializers. Signed-off-by: Rick Edgecombe Reviewed-by: Christophe Leroy Acked-by: Helge Deller Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: linux-parisc@vger.kernel.org Link: https://lore.kernel.org/lkml/202402280912.33AEE7A9CF@keescook/#t Link: https://lore.kernel.org/lkml/j7bfvig3gew3qruouxrh7z7ehjjafrgkbcmg6tcghhfh3rhmzi@wzlcoecgy5rs/ --- v3: - Fixed spelling errors in log - Be consistent about field vs member in log Hi, This patch was split and refactored out of a tree-wide change [0] to just zero-init each struct vm_unmapped_area_info. The overall goal of the series is to help shadow stack guard gaps. Currently, there is only one arch with shadow stacks, but two more are in progress. It is compile tested only. There was further discussion that this method of initializing the structs while nice in some ways has a greater risk of introducing bugs in some of the more complicated callers. Since this version was reviewed my arch maintainers already, leave it as was already acknowledged. Thanks, Rick [0] https://lore.kernel.org/lkml/20240226190951.3240433-6-rick.p.edgecombe@intel.com/ --- arch/parisc/kernel/sys_parisc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c index 98af719d5f85..f7722451276e 100644 --- a/arch/parisc/kernel/sys_parisc.c +++ b/arch/parisc/kernel/sys_parisc.c @@ -104,7 +104,9 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp, struct vm_area_struct *vma, *prev; unsigned long filp_pgoff; int do_color_align; - struct vm_unmapped_area_info info; + struct vm_unmapped_area_info info = { + .length = len + }; if (unlikely(len > TASK_SIZE)) return -ENOMEM; @@ -139,7 +141,6 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp, return addr; } - info.length = len; info.align_mask = do_color_align ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0; info.align_offset = shared_align_offset(filp_pgoff, pgoff); @@ -160,7 +161,6 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp, */ } - info.flags = 0; info.low_limit = mm->mmap_base; info.high_limit = mmap_upper_limit(NULL); return vm_unmapped_area(&info); -- 2.34.1