From patchwork Tue Mar 12 22:28:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Edgecombe, Rick P" X-Patchwork-Id: 13590676 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 CADB3C54E58 for ; Tue, 12 Mar 2024 22:29:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2CB18E0028; Tue, 12 Mar 2024 18:29:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B6B88E0011; Tue, 12 Mar 2024 18:29:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82FE28E0028; Tue, 12 Mar 2024 18:29:13 -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 6C1AB8E0011 for ; Tue, 12 Mar 2024 18:29:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4786C160463 for ; Tue, 12 Mar 2024 22:29:13 +0000 (UTC) X-FDA: 81889828986.26.A2D6479 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf15.hostedemail.com (Postfix) with ESMTP id 4B63DA0005 for ; Tue, 12 Mar 2024 22:29:10 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IAS66i75; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf15.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.198.163.15 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=1710282550; 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=9n/FakS/5V2QrPHm0TUWzRHiHuBIkVldaGqGRm3C17I=; b=U1uf/vz86GOVaYdiwZjZgf5n5xj8knZiV8GrV5z1YVwopQIOOQ9CcX9kLxU8UUr7u8h+p8 gUgjNT5F5kVtH7rQwdr0EeRObmDyudOhws0CBw4vZOm23NIhhDiKi+iCGRE6iDbldXpEdr iEf7wHLNfERYLwHCoo2aBFj3NZP2h68= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IAS66i75; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf15.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710282550; a=rsa-sha256; cv=none; b=3TM0AJuMLESfJ86hr0pesLHZD2JVvrZMhX9jrnFh5y49/0l62x4MkZVl/XCxTQEefbzmM1 eTFanpH4phQ8AtFDrMkXZkOQ78UXPjl9ZyGbZhtnu4hWXC28pM4bdCS1pyOxCDZIOtJ6ml 8Pt3d7J76fu0R6MW/OdJPidt/sJ1xWA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710282551; x=1741818551; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SOxmdONZG+ooJ46ryKwSr/UQJN1BRbIVpZR9p2Kx8ZQ=; b=IAS66i753CdMQtAqghirYqfidmYoVsJpc9SVN56noraScVLoXaqxhbqs M7jStfFYxSd7ECLQuP5IGHOSNVEe0EorvHOAnRdEBQZ2CISiTw9xo1tyF EnQwgT8KWsJBEQ6bE/mQ+Qhh1DkvpyceNOli+JWOASE/7kd9zGIO4bjn8 ygEr3QcmCC+HmTGYHYyIBodYhwWyE4QnSAMUvZO9FGatcLn/JPKBigf8c fXa2hjkp0d7xABogBTIKdGgBibl7RLTcp5VNg8wzcEjb44T5JB09SCtKw SF8oQbm4uciaXRXVT9E5CVLrsp8XelyYetljgHllXWJrv4t9BgFr6lwPW Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11011"; a="5191998" X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="5191998" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 15:29:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="16356860" Received: from gargayus-mobl1.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.255.231.196]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 15:29:03 -0700 From: Rick Edgecombe To: Liam.Howlett@oracle.com, akpm@linux-foundation.org, bp@alien8.de, broonie@kernel.org, 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, christophe.leroy@csgroup.eu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, rick.p.edgecombe@intel.com, Michael Ellerman , Nicholas Piggin , "Aneesh Kumar K . V" , "Naveen N . Rao" , linuxppc-dev@lists.ozlabs.org Subject: [PATCH v3 07/12] powerpc: Use initializer for struct vm_unmapped_area_info Date: Tue, 12 Mar 2024 15:28:38 -0700 Message-Id: <20240312222843.2505560-8-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312222843.2505560-1-rick.p.edgecombe@intel.com> References: <20240312222843.2505560-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4B63DA0005 X-Stat-Signature: ixsry9o4hi98dhcy7e5zy3jyo48x8uaf X-HE-Tag: 1710282550-966718 X-HE-Meta: U2FsdGVkX19X9aeRTc8l/7SyLDMuMuDn7dPzl+Li8Gxbi2RdYgyKD30Lz+1cggt5dqhKEW5FYSWXeqh3OHceXTFuNevs4xh0zziyx8Uy+yVRBqa6jkDQ83sJ+OJNAwyPQ/8uoivgzvlQ+HV/H45aDEX1kk50Xz2fpRBO+eeerbnVng5Rwbl17IactpjJf3kO6am7EN3nk4Jn3V+nytGzVNMSOhJ+/3nQS+btHzFWXA5vQtpefgUAq0aa6caw3llBAniSoK/whghVKcd7e8CJ5kpx5RfYV8O1DiziuXEZbIMCd5yIE1GX5CZfatUp29rR9OFkm6sSCSSC8B01ckSo5CzCpg/jHr4Uyohm+JgwhoY+jvorBzuDoSACvcP1vcKLsQ5DDFA0HrKw8ONWbGC4u5ibYXu5IWGykcOkGmN61s4pMzbqQoymrGtGkdHUzlhQDNPgjEpb0EQ/yiAIpmeg+bGzWvwd0j9WGZA58iqj+RKVNgtj1URHah34sIiQlV/At6dQNJRZdzX7ct/41IJAG9WZNsWV0wMmgKO7B+NTfSOj3ybzrAhfcDw41PoqLQESLfkzTXQS36vGLciX67gp+ZP2+NBhJtGbkG8UiRRFOxSjmVsGPSWPcxuff5BZ5oDhbgP7OAO0VoHOZVQ/a5HqcQJUXv2Dh2afUy7iS8NPKdC8FnCrWY0M9/1WMbeBz53UaqvEBS8RGe1u4uPjiIviOnC/6xPr0iFcbEzPcbOQbDWvUFM5buFNQ4J6SO2UlquRbCfVHNsrFF/7iLjUzxb1PmsiQ0BoMnZjtf49ESQPO/21h86JK0XWoSD7+mpdQRIVAtRBYhj472bsdYfr76ciFzPi+7+g0glMQnLFnXwv0FnaJphrHhKCWbtEnyMnxs/lXedhrg88toBB2UYvHhRVMxBjJewjzwwvX4Xkg5suBecUFP9SEGcQiy+59FSrzDdylJDfiEi6fw8Wr202Hn8 5rgP5y26 rYDLugqdaA7a8nV0bvDIjb0Qt0Y8lza2H/NQqYMV41g8iTFRW3jF9LH7IaXFsxYtO/KJn4aDOs9gDaA55gkKopmwU2rdq1O0/dKNu1P9bAu53oAWxIZ9CixrnJh8wUWwvecRTl60kWp5+KP5BfgU9azdNEF0ynSKGjWVfKx0G2vQxTkpWBf7Tp9K90AzjCfO2AkcZALYV6wmqep5B5a2txayWlZZ8fqCGjIiHoP312CmJs4JPRISffq+KO7KMvwFlo8pk1WqjEpv21lQPYkC8VYYB5zMDOH3a/zGBopEa8KCcmowicKM+Mqmp0i9EL64JdlWk3gK2mkNbm1nN5nTM2bTDH1i8UbGujM4GJygDhGIi6VKPtC0YvvFf07O+my3FYb9cRk2wAhWwLnOrpl0kFs2R/jz97vifxZcJsbsF1RS8K9f4SvSJKxyNaw== 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 Acked-by: Michael Ellerman Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Aneesh Kumar K.V Cc: Naveen N. Rao Cc: linuxppc-dev@lists.ozlabs.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/powerpc/mm/book3s64/slice.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/mm/book3s64/slice.c b/arch/powerpc/mm/book3s64/slice.c index c0b58afb9a47..6c7ac8c73a6c 100644 --- a/arch/powerpc/mm/book3s64/slice.c +++ b/arch/powerpc/mm/book3s64/slice.c @@ -282,12 +282,12 @@ static unsigned long slice_find_area_bottomup(struct mm_struct *mm, { int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT); unsigned long found, next_end; - struct vm_unmapped_area_info info; - - info.flags = 0; - info.length = len; - info.align_mask = PAGE_MASK & ((1ul << pshift) - 1); - info.align_offset = 0; + struct vm_unmapped_area_info info = { + .flags = 0, + .length = len, + .align_mask = PAGE_MASK & ((1ul << pshift) - 1), + .align_offset = 0 + }; /* * Check till the allow max value for this mmap request */ @@ -326,13 +326,14 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm, { int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT); unsigned long found, prev; - struct vm_unmapped_area_info info; + struct vm_unmapped_area_info info = { + .flags = VM_UNMAPPED_AREA_TOPDOWN, + .length = len, + .align_mask = PAGE_MASK & ((1ul << pshift) - 1), + .align_offset = 0 + }; unsigned long min_addr = max(PAGE_SIZE, mmap_min_addr); - info.flags = VM_UNMAPPED_AREA_TOPDOWN; - info.length = len; - info.align_mask = PAGE_MASK & ((1ul << pshift) - 1); - info.align_offset = 0; /* * If we are trying to allocate above DEFAULT_MAP_WINDOW * Add the different to the mmap_base.