From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759533AbcAUMcg (ORCPT ); Thu, 21 Jan 2016 07:32:36 -0500 Received: from mail.skyhub.de ([78.46.96.112]:35208 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759214AbcAUMcd (ORCPT ); Thu, 21 Jan 2016 07:32:33 -0500 Date: Thu, 21 Jan 2016 13:32:05 +0100 From: Borislav Petkov To: Dan Carpenter , Aravind Gopalakrishnan Cc: Doug Thompson , Mauro Carvalho Chehab , linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct_addr() Message-ID: <20160121123205.GE21930@pd.tnic> References: <20160120095451.GB19898@mwanda> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160120095451.GB19898@mwanda> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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.