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: <DB9PR08MB7511C861A96B1206ED685AD8F4BBA@DB9PR08MB7511.eurprd08.prod.outlook.com>
Date:   Tue, 21 Nov 2023 01:44:20 +0000
From:   Jianyong Wu <Jianyong.Wu@....com>
To:     Russell King <linux@...linux.org.uk>
CC:     "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
        "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
        Salil Mehta <salil.mehta@...wei.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Justin He <Justin.He@....com>,
        James Morse <James.Morse@....com>,
        Catalin Marinas <Catalin.Marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <Mark.Rutland@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>
Subject: RE: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs



> -----Original Message-----
> From: Russell King <linux@...linux.org.uk>
> Sent: 2023年11月20日 17:58
> To: Jianyong Wu <Jianyong.Wu@....com>
> Cc: linux-pm@...r.kernel.org; loongarch@...ts.linux.dev;
> linux-acpi@...r.kernel.org; linux-arch@...r.kernel.org;
> linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> linux-riscv@...ts.infradead.org; kvmarm@...ts.linux.dev; x86@...nel.org;
> linux-csky@...r.kernel.org; linux-doc@...r.kernel.org;
> linux-ia64@...r.kernel.org; linux-parisc@...r.kernel.org; Salil Mehta
> <salil.mehta@...wei.com>; Jean-Philippe Brucker <jean-philippe@...aro.org>;
> Justin He <Justin.He@....com>; James Morse <James.Morse@....com>;
> Catalin Marinas <Catalin.Marinas@....com>; Will Deacon <will@...nel.org>;
> Mark Rutland <Mark.Rutland@....com>; Lorenzo Pieralisi
> <lpieralisi@...nel.org>
> Subject: Re: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs
> 
> On Mon, Nov 20, 2023 at 09:36:05AM +0000, Jianyong Wu wrote:
> >
> >
> > > -----Original Message-----
> > > From: Russell King <linux@...linux.org.uk>
> > > Sent: 2023年11月20日 17:25
> > > To: Jianyong Wu <Jianyong.Wu@....com>
> > > Cc: linux-pm@...r.kernel.org; loongarch@...ts.linux.dev;
> > > linux-acpi@...r.kernel.org; linux-arch@...r.kernel.org;
> > > linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> > > linux-riscv@...ts.infradead.org; kvmarm@...ts.linux.dev;
> > > x86@...nel.org; linux-csky@...r.kernel.org;
> > > linux-doc@...r.kernel.org; linux-ia64@...r.kernel.org;
> > > linux-parisc@...r.kernel.org; Salil Mehta <salil.mehta@...wei.com>;
> > > Jean-Philippe Brucker <jean-philippe@...aro.org>; Justin He
> > > <Justin.He@....com>; James Morse <James.Morse@....com>; Catalin
> > > Marinas <Catalin.Marinas@....com>; Will Deacon <will@...nel.org>;
> > > Mark Rutland <Mark.Rutland@....com>; Lorenzo Pieralisi
> > > <lpieralisi@...nel.org>
> > > Subject: Re: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs
> > >
> > > On Thu, Nov 16, 2023 at 07:45:51AM +0000, Jianyong Wu wrote:
> > > > Hi Russell,
> > > >
> > > > One inline comment.
> > > ...
> > > > > Changes since RFC v2
> > > > >  * Add specification reference
> > > > >  * Use EPERM rather than EPROBE_DEFER
> > > ...
> > > > > @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu)  {
> > > > >  	phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry);
> > > > >  	int err = psci_ops.cpu_on(cpu_logical_map(cpu),
> pa_secondary_entry);
> > > > > -	if (err)
> > > > > +	if (err && err != -EPROBE_DEFER)
> > > >
> > > > Should this be EPERM? As the following psci cpu_on op will return it.
> > > > I think you miss to change this when apply Jean-Philippe's patch.
> > >
> > > It looks like James didn't properly update all places. Also,
> > >
> > > > > diff --git a/drivers/firmware/psci/psci.c
> > > > > b/drivers/firmware/psci/psci.c index d9629ff87861..ee82e7880d8c
> > > > > 100644
> > > > > --- a/drivers/firmware/psci/psci.c
> > > > > +++ b/drivers/firmware/psci/psci.c
> > > > > @@ -218,6 +218,8 @@ static int __psci_cpu_on(u32 fn, unsigned
> > > > > long cpuid, unsigned long entry_point)
> > > > >  	int err;
> > > > >
> > > > >  	err = invoke_psci_fn(fn, cpuid, entry_point, 0);
> > > > > +	if (err == PSCI_RET_DENIED)
> > > > > +		return -EPERM;
> > > > >  	return psci_to_linux_errno(err);
> > >
> > > This change is unnecessary - probably comes from when -EPROBE_DEFER
> > > was being used. psci_to_linux_errno() already does:
> >
> > But may print lots of noise like:
> >
> > [    0.008955] smp: Bringing up secondary CPUs ...
> > [    0.009661] psci: failed to boot CPU1 (-1)
> > [    0.010360] psci: failed to boot CPU2 (-1)
> > [    0.011164] psci: failed to boot CPU3 (-1)
> > [    0.011946] psci: failed to boot CPU4 (-1)
> > [    0.012764] psci: failed to boot CPU5 (-1)
> > [    0.013534] psci: failed to boot CPU6 (-1)
> > [    0.014349] psci: failed to boot CPU7 (-1)
> > [    0.014820] smp: Brought up 1 node, 1 CPU
> >
> > Is this expected?
> 
> Please read my email again, and take note of the _context_ above the places
> that I've commented. Context matters.
> 
> What I'm saying is that this change:
> 
>  	err = invoke_psci_fn(fn, cpuid, entry_point, 0);
> +	if (err == PSCI_RET_DENIED)
> +		return -EPERM;
>  	return psci_to_linux_errno(err);
> 
> Is unnecessary when psci_to_linux_errno() already does:
> 
> static __always_inline int psci_to_linux_errno(int errno) {
> 	switch (errno) {
> 	...
> 	case PSCI_RET_DENIED:
> 		return -EPERM;
> 
> So, a return of PSCI_RET_DENIED from invoke_psci_fn() above will _already_ be
> translated to -EPERM (which is -1) by psci_to_linux_errno(). There is no need to
> add that extra if() statement in __psci_cpu_on().
> 
> I was _not_ saying that the entire patch was unnecessary.
> 
> Context matters. That's why we include context in replies.
> 
> Standard email etiquette (before Microsoft messed it up) is to quote the email
> that is being replied to, trimming hard irrelevant content, and to place the reply
> comments immediately below the original content to which the comments
> relate, to give the reply comments the context necessary for correct
> interpretation.
> 

Oh, sorry, my mistake. Ignore my last comment.

Thanks
Jianyong

> Thanks.
> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ