All of lore.kernel.org
 help / color / mirror / Atom feed
* [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr()
@ 2016-01-20  9:54 ` Dan Carpenter
  0 siblings, 0 replies; 6+ messages in thread
From: Dan Carpenter @ 2016-01-20  9:54 UTC (permalink / raw)
  To: Doug Thompson, Borislav Petkov
  Cc: Mauro Carvalho Chehab, linux-edac, linux-kernel, kernel-janitors

dct_sel_base_off is declared as a u64 but we're only using the lower 32
bits because of a shift wrapping bug.

Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Static checker stuff.  Not tested.

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 9eee13e..d87a475 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1452,7 +1452,7 @@ static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt, u8 range,
 	u64 chan_off;
 	u64 dram_base		= get_dram_base(pvt, range);
 	u64 hole_off		= f10_dhar_offset(pvt);
-	u64 dct_sel_base_off	= (pvt->dct_sel_hi & 0xFFFFFC00) << 16;
+	u64 dct_sel_base_off	= (u64)(pvt->dct_sel_hi & 0xFFFFFC00) << 16;
 
 	if (hi_rng) {
 		/*

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr()
@ 2016-01-20  9:54 ` Dan Carpenter
  0 siblings, 0 replies; 6+ messages in thread
From: Dan Carpenter @ 2016-01-20  9:54 UTC (permalink / raw)
  To: Doug Thompson, Borislav Petkov
  Cc: Mauro Carvalho Chehab, linux-edac, linux-kernel, kernel-janitors

dct_sel_base_off is declared as a u64 but we're only using the lower 32
bits because of a shift wrapping bug.

Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Static checker stuff.  Not tested.

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 9eee13e..d87a475 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1452,7 +1452,7 @@ static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt, u8 range,
 	u64 chan_off;
 	u64 dram_base		= get_dram_base(pvt, range);
 	u64 hole_off		= f10_dhar_offset(pvt);
-	u64 dct_sel_base_off	= (pvt->dct_sel_hi & 0xFFFFFC00) << 16;
+	u64 dct_sel_base_off	= (u64)(pvt->dct_sel_hi & 0xFFFFFC00) << 16;
 
 	if (hi_rng) {
 		/*

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr()
  2016-01-20  9:54 ` Dan Carpenter
@ 2016-01-21 12:32   ` Borislav Petkov
  -1 siblings, 0 replies; 6+ messages in thread
From: Borislav Petkov @ 2016-01-21 12:32 UTC (permalink / raw)
  To: Dan Carpenter, Aravind Gopalakrishnan
  Cc: Doug Thompson, Mauro Carvalho Chehab, linux-edac, linux-kernel,
	kernel-janitors

On Wed, Jan 20, 2016 at 12:54:51PM +0300, Dan Carpenter wrote:
> dct_sel_base_off is declared as a u64 but we're only using the lower 32
> bits because of a shift wrapping bug.
> 
> Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Static checker stuff.  Not tested.
> 
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 9eee13e..d87a475 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -1452,7 +1452,7 @@ static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt, u8 range,
>  	u64 chan_off;
>  	u64 dram_base		= get_dram_base(pvt, range);
>  	u64 hole_off		= f10_dhar_offset(pvt);
> -	u64 dct_sel_base_off	= (pvt->dct_sel_hi & 0xFFFFFC00) << 16;
> +	u64 dct_sel_base_off	= (u64)(pvt->dct_sel_hi & 0xFFFFFC00) << 16;

Good catch.

So this could possibly give us the wrong channel address and thus not
find the CS row. Hmm, so on my boxes, DctSelBaseOffset[47:26] is not big
enough so that its high 16-bits are 0 and truncation doesn't hurt there.

@Aravind: do you have a box with

setpci -s 18.2 0x114.l

bits [31:16] not 0?

If so, you might want to run with and without this fix above as it
should fix system address to CS row mapping.

Anyway, applied and tagged for stable.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr()
@ 2016-01-21 12:32   ` Borislav Petkov
  0 siblings, 0 replies; 6+ messages in thread
From: Borislav Petkov @ 2016-01-21 12:32 UTC (permalink / raw)
  To: Dan Carpenter, Aravind Gopalakrishnan
  Cc: Doug Thompson, Mauro Carvalho Chehab, linux-edac, linux-kernel,
	kernel-janitors

On Wed, Jan 20, 2016 at 12:54:51PM +0300, Dan Carpenter wrote:
> dct_sel_base_off is declared as a u64 but we're only using the lower 32
> bits because of a shift wrapping bug.
> 
> Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Static checker stuff.  Not tested.
> 
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 9eee13e..d87a475 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -1452,7 +1452,7 @@ static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt, u8 range,
>  	u64 chan_off;
>  	u64 dram_base		= get_dram_base(pvt, range);
>  	u64 hole_off		= f10_dhar_offset(pvt);
> -	u64 dct_sel_base_off	= (pvt->dct_sel_hi & 0xFFFFFC00) << 16;
> +	u64 dct_sel_base_off	= (u64)(pvt->dct_sel_hi & 0xFFFFFC00) << 16;

Good catch.

So this could possibly give us the wrong channel address and thus not
find the CS row. Hmm, so on my boxes, DctSelBaseOffset[47:26] is not big
enough so that its high 16-bits are 0 and truncation doesn't hurt there.

@Aravind: do you have a box with

setpci -s 18.2 0x114.l

bits [31:16] not 0?

If so, you might want to run with and without this fix above as it
should fix system address to CS row mapping.

Anyway, applied and tagged for stable.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr()
  2016-01-21 12:32   ` Borislav Petkov
@ 2016-01-21 15:29     ` Aravind Gopalakrishnan
  -1 siblings, 0 replies; 6+ messages in thread
From: Aravind Gopalakrishnan @ 2016-01-21 15:29 UTC (permalink / raw)
  To: Borislav Petkov, Dan Carpenter
  Cc: Doug Thompson, Mauro Carvalho Chehab, linux-edac, linux-kernel,
	kernel-janitors

On 1/21/2016 6:32 AM, Borislav Petkov wrote:
> On Wed, Jan 20, 2016 at 12:54:51PM +0300, Dan Carpenter wrote:
>> +	u64 dct_sel_base_off	= (u64)(pvt->dct_sel_hi & 0xFFFFFC00) << 16;
>
>
> @Aravind: do you have a box with
>
> setpci -s 18.2 0x114.l
>
> bits [31:16] not 0?
>
>
>

Nope. I don't see it set on my Fam10h and Fam15h Model 00-0fh systems.

But yes, nice catch!

-Aravind.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr()
@ 2016-01-21 15:29     ` Aravind Gopalakrishnan
  0 siblings, 0 replies; 6+ messages in thread
From: Aravind Gopalakrishnan @ 2016-01-21 15:29 UTC (permalink / raw)
  To: Borislav Petkov, Dan Carpenter
  Cc: Doug Thompson, Mauro Carvalho Chehab, linux-edac, linux-kernel,
	kernel-janitors

On 1/21/2016 6:32 AM, Borislav Petkov wrote:
> On Wed, Jan 20, 2016 at 12:54:51PM +0300, Dan Carpenter wrote:
>> +	u64 dct_sel_base_off	= (u64)(pvt->dct_sel_hi & 0xFFFFFC00) << 16;
>
>
> @Aravind: do you have a box with
>
> setpci -s 18.2 0x114.l
>
> bits [31:16] not 0?
>
>
>

Nope. I don't see it set on my Fam10h and Fam15h Model 00-0fh systems.

But yes, nice catch!

-Aravind.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-01-21 15:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-20  9:54 [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr() Dan Carpenter
2016-01-20  9:54 ` Dan Carpenter
2016-01-21 12:32 ` Borislav Petkov
2016-01-21 12:32   ` Borislav Petkov
2016-01-21 15:29   ` Aravind Gopalakrishnan
2016-01-21 15:29     ` Aravind Gopalakrishnan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.