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] [day] [month] [year] [list]
Date:   Mon, 12 Nov 2018 05:32:43 -0800
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Rafael David Tinoco <rafael.tinoco@...aro.org>
Cc:     Sasha Levin <sashal@...nel.org>, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org, Prarit Bhargava <prarit@...hat.com>,
        Shuah Khan <shuah@...nel.org>,
        Stafford Horne <shorne@...il.com>
Subject: Re: [PATCH AUTOSEL 4.4 07/32] cpupower: Fix coredump on VMWare

On Mon, Nov 12, 2018 at 08:29:27AM -0200, Rafael David Tinoco wrote:
> On 10/31/18 9:11 PM, Sasha Levin wrote:
> > From: Prarit Bhargava <prarit@...hat.com>
> > 
> > [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
> > 
> > cpupower crashes on VMWare guests.  The guests have the AMD PStateDef MSR
> > (0xC0010064 + state number) set to zero.  As a result fid and did are zero
> > and the crash occurs because of a divide by zero (cof = fid/did).  This
> > can be prevented by checking the enable bit in the PStateDef MSR before
> > calculating cof.  By doing this the value of pstate[i] remains zero and
> > the value can be tested before displaying the active Pstates.
> > 
> > Check the enable bit in the PstateDef register for all supported families
> > and only print out enabled Pstates.
> > 
> > Signed-off-by: Prarit Bhargava <prarit@...hat.com>
> > Cc: Shuah Khan <shuah@...nel.org>
> > Cc: Stafford Horne <shorne@...il.com>
> > Signed-off-by: Shuah Khan (Samsung OSG) <shuah@...nel.org>
> > Signed-off-by: Sasha Levin <sashal@...nel.org>
> > ---
> >   tools/power/cpupower/utils/cpufreq-info.c | 2 ++
> >   tools/power/cpupower/utils/helpers/amd.c  | 5 +++++
> >   2 files changed, 7 insertions(+)
> > 
> > diff --git a/tools/power/cpupower/utils/cpufreq-info.c b/tools/power/cpupower/utils/cpufreq-info.c
> > index 0e6764330241..f9b064ac8d94 100644
> > --- a/tools/power/cpupower/utils/cpufreq-info.c
> > +++ b/tools/power/cpupower/utils/cpufreq-info.c
> > @@ -200,6 +200,8 @@ static int get_boost_mode(unsigned int cpu)
> >   		printf(_("    Boost States: %d\n"), b_states);
> >   		printf(_("    Total States: %d\n"), pstate_no);
> >   		for (i = 0; i < pstate_no; i++) {
> > +			if (!pstates[i])
> > +				continue;
> >   			if (i < b_states)
> >   				printf(_("    Pstate-Pb%d: %luMHz (boost state)"
> >   					 "\n"), i, pstates[i]);
> > diff --git a/tools/power/cpupower/utils/helpers/amd.c b/tools/power/cpupower/utils/helpers/amd.c
> > index 6437ef39aeea..82adfb33d7a5 100644
> > --- a/tools/power/cpupower/utils/helpers/amd.c
> > +++ b/tools/power/cpupower/utils/helpers/amd.c
> > @@ -103,6 +103,11 @@ int decode_pstates(unsigned int cpu, unsigned int cpu_family,
> >   		}
> >   		if (read_msr(cpu, MSR_AMD_PSTATE + i, &pstate.val))
> >   			return -1;
> > +		if ((cpu_family == 0x17) && (!pstate.fam17h_bits.en))
> > +			continue;
> > +		else if (!pstate.bits.en)
> > +			continue;
> > +
> >   		pstates[i] = get_cof(cpu_family, pstate);
> >   	}
> >   	*no = i;
> > 
> 
> Sasha,
> 
> This commit is causing:
> 
> $ make V=1 -C tools/power/cpupower all
> 
> gcc -fPIC -DVERSION=\"4.4.163.99.g0d9e7b\" -DPACKAGE=\"cpupower\"
> -DPACKAGE_BUGREPORT=\"linux-pm@...r.kernel.org\" -D_GNU_SOURCE -pipe -DNLS
> -Wall -Wchar-subscripts -Wpointer-arith -Wsign-compare -Wno-pointer-sign
> -Wdeclaration-after-statement -Wshadow -O1 -g -DDEBUG -I./lib -I ./utils -o
> utils/helpers/amd.o -c utils/helpers/amd.c
> utils/helpers/amd.c: In function ‘decode_pstates’:
> utils/helpers/amd.c:106:39: error: ‘union msr_pstate’ has no member named
> ‘fam17h_bits’
>    if ((cpu_family == 0x17) && (!pstate.fam17h_bits.en))
> 
> I think it should be dropped from v4.4 and v4.9 RCs, since this is a fix for
> a CPU that isn't supported for those 2.

Now dropped from both queues now.  Thanks for testing and finding these.

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ