linux-kernel - Re: [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment in hv_crash_setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <193768a-6914-5217-8815-ab1c75f1c8d@inria.fr>
Date: Fri, 31 Oct 2025 10:37:00 +0100 (CET)
From: Julia Lawall <julia.lawall@...ia.fr>
To: Naman Jain <namjain@...ux.microsoft.com>
cc: Markus Elfring <Markus.Elfring@....de>, linux-hyperv@...r.kernel.org, 
    x86@...nel.org, Borislav Petkov <bp@...en8.de>, 
    Dave Hansen <dave.hansen@...ux.intel.com>, 
    Dexuan Cui <decui@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, 
    "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, 
    "K. Y. Srinivasan" <kys@...rosoft.com>, Long Li <longli@...rosoft.com>, 
    Mukesh Rathor <mrathor@...ux.microsoft.com>, 
    Thomas Gleixner <tglx@...utronix.de>, Wei Liu <wei.liu@...nel.org>, 
    LKML <linux-kernel@...r.kernel.org>, kernel-janitors@...r.kernel.org, 
    Miaoqian Lin <linmq006@...il.com>
Subject: Re: [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment
 in hv_crash_setup_trampdata()



On Fri, 31 Oct 2025, Naman Jain wrote:

>
>
> On 10/31/2025 2:03 PM, Markus Elfring wrote:
> > From: Markus Elfring <elfring@...rs.sourceforge.net>
> > Date: Fri, 31 Oct 2025 09:24:31 +0100
> >
> > A pointer was assigned to a variable. The same pointer was used for
> > the destination parameter of a memcpy() call.
> > This function is documented in the way that the same value is returned.
> > Thus convert two separate statements into a direct variable assignment for
> > the return value from a memory copy action.
> >
> > The source code was transformed by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring <elfring@...rs.sourceforge.net>
> > ---
> >   arch/x86/hyperv/hv_crash.c | 4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
> > index c0e22921ace1..745d02066308 100644
> > --- a/arch/x86/hyperv/hv_crash.c
> > +++ b/arch/x86/hyperv/hv_crash.c
> > @@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
> >   		return -1;
> >   	}
> >   -	dest = (void *)trampoline_va;
> > -	memcpy(dest, &hv_crash_asm32, size);
> > -
> > +	dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
> >   	dest += size;
> >   	dest = (void *)round_up((ulong)dest, 16);
> >   	tramp = (struct hv_crash_tramp_data *)dest;
>
>
> I tried running spatch Coccinelle checks on this file, but could not get it to
> flag this improvement. Do you mind sharing more details on the issue
> reproduction please.
>
> I am OK with this change, though it may cost code readability a little bit.
> But if this is a result of some known standard rule, added as part of these
> Coccinelle rules, we should be good.

Multiple people have suggested that due to the loos of readability the
change is not a good idea.

It's not done by a standard rule.

julia