From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0773B4611CE for ; Fri, 14 Aug 2026 12:30:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786710626; cv=none; b=BjguHzMoBue1tGWWgGG3h86NCiEKh+YvvPYfC0IIxef5ZyeG16wp2OszkJ+Mb5qj8fF2gMfB/qEijLKXfx5RH9diMhMMQzbj4a3p7gWPKBOn4A0XxU9g7QrGNltcMfGE88U99R2G4v4npRx8v/UVuYTpWsXz5Ml0MNpIRikWfbU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786710626; c=relaxed/simple; bh=lpFfOWSGr3C+CPkW0TnSSRqD2KxZ8Vi66mGkFS9sWxQ=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=m4Mf8By9M4UAcsJpQW7RgP0UYz4wl2Xv6gixF9+q9MTNDppedS1OZK8pnvqZP2wtH+6VhC/fw8JyfcSuwc7PD8ADEeJxq+gBEuzqUPjZrlopyjRJ59O/k9Nlk3Ds4P2FxaS41CRsKIf7rDyELkUREl3Oac3tCrOmwwCCKnyDro0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oegK3E0l; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oegK3E0l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB0311F000E9; Fri, 14 Aug 2026 12:30:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786710624; bh=HKKsiOkispBHtadww+iXjd9Ra2guD/uOnDke3p6E2gA=; h=Date:Subject:To:References:From:In-Reply-To; b=oegK3E0lTTkmx97gOV+4Y8Cbm4yAgDCYay9YB7MZlfoKvCp5UAx/+GXfVPD24Txo/ O4aaKBdgYHOQBV/8nWZNAKgZ5shM2Bn5gEhiROTzUM10AbMMr9Ur8Oy13e7pazs+5B RJk2WLWn9NO31SO8fYlhQ2dRJN4/qZrwTlgQ8BTr4e+hMw4zE1R2u23u/Brf0IS9RF WosA+H0u1dIN4MJXjvfUPdeFnKUVriQ3A4P39a/3Enc19JHMNABzip+Vkn3XsDy+nu V7jbR22jhwRUg+4xrvnuHguQFB+CyscjH9HqQ9KasTDqcEAy7JxEgtBLjRZL+miTuN AUX7vTxbgJdDA== Message-ID: <1e28e2fb-36ac-4187-90c4-fc7dfea03f28@kernel.org> Date: Fri, 14 Aug 2026 14:30:19 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] powerpc/ptrace: Add offsetof check for exit_flags in pt_regs_check() To: "Mukesh Kumar Chaurasiya (IBM)" , maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com, mkchauras@linux.ibm.com, sshegde@linux.ibm.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20260703074948.1668744-1-mkchauras@gmail.com> <20260703134456.2d291388-8b-amachhiw@linux.ibm.com> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: <20260703134456.2d291388-8b-amachhiw@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 03/07/2026 à 10:55, Amit Machhiwal a écrit : > On 2026/07/03 01:19 PM, Mukesh Kumar Chaurasiya (IBM) wrote: >> pt_regs_check() verifies that fields shared between struct pt_regs and >> struct user_pt_regs sit at the same offset, to catch any accidental >> layout divergence between the kernel and uapi structures. >> >> Add the missing check for exit_flags, following the same pattern as the >> existing checks for result, dsisr, dar and the other shared fields. >> >> Fixes: d7a6797e0bc1 ("powerpc: add exit_flags field in pt_regs") This commit was almost reverted by commit 263e5159e00a ("powerpc: Fix exit_flags field placement in pt_regs for ptrace") Dropping this patch. Christophe > > You may want to add below in order to get this patch backported: > > Cc: stable@vger.kernel.org > >> Signed-off-by: Mukesh Kumar Chaurasiya (IBM) >> --- >> arch/powerpc/kernel/ptrace/ptrace.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/powerpc/kernel/ptrace/ptrace.c b/arch/powerpc/kernel/ptrace/ptrace.c >> index 316d4f5ead8e..fb3fec73f66a 100644 >> --- a/arch/powerpc/kernel/ptrace/ptrace.c >> +++ b/arch/powerpc/kernel/ptrace/ptrace.c >> @@ -235,6 +235,8 @@ void __init pt_regs_check(void) >> offsetof(struct user_pt_regs, dsisr)); >> BUILD_BUG_ON(offsetof(struct pt_regs, result) != >> offsetof(struct user_pt_regs, result)); >> + BUILD_BUG_ON(offsetof(struct pt_regs, exit_flags) != >> + offsetof(struct user_pt_regs, exit_flags)); > > At first, it appeared to be redundant as we already check > > CHECK_REG(PT_EXIT_FLAGS, exit_flags); > > which expands to: > > #define CHECK_REG(_pt, _reg) \ > BUILD_BUG_ON(_pt != (offsetof(struct user_pt_regs, _reg) / \ > sizeof(unsigned long))); > > But looking closely, it turns out to be non-redundant. CHECK_REG only > touches struct user_pt_regs — it validates the PT_EXIT_FLAGS constant > against the uapi layout. It says nothing about struct pt_regs. > > struct pt_regs (asm/ptrace.h) embeds struct user_pt_regs in a union > alongside an anonymous struct that re-declares all the same fields with > kernel-internal aliases (dear/dar, esr/dsisr). exit_flags lives in that > anonymous struct. A field accidentally inserted there between result and > exit_flags would silently break the union aliasing without CHECK_REG > catching it. The new BUILD_BUG_ON closes that gap, consistent with how > result, dar and dsisr are already protected in the same block. > > Looks good to me. > > Reviewed-by: Amit Machhiwal > > Thanks, > Amit > >> >> BUILD_BUG_ON(sizeof(struct user_pt_regs) > sizeof(struct pt_regs)); >> >> -- >> 2.55.0 >> >>