linux-kernel - Re: [PATCH] x86: PCI config space accessor functions should not ignore the segment argument

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:	Thu, 21 Jul 2011 12:59:49 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jan Beulich <JBeulich@...ell.com>, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [PATCH] x86: PCI config space accessor functions should not
 ignore the segment argument

On Thu, 21 Jul 2011 11:05:40 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> > > also, the analysis/explanation is a bit incomplete:
> > >   
> > >> The access method 1 accessor, as it can be used for extended 
> > >> accesses (on AMD systems) instead gets added checks for the 
> > >> passed in segment to be zero (returning an error just like out 
> > >> of range values of the other arguments would cause).  
> > > 
> > > Under what circumstances can this trigger in practice, with the 
> > > current code?  
> > 
> > I really don't know whether multi-segment PCI systems with AMD CPUs 
> > are existing in practice. If they do, and if MMCFG cannot be used 
> > there for whatever reason, accesses to segments other than zero 
> > would get issued to the wrong device(s). I would have thought that 
> > this is what the paragraph above says, but I certainly can add this 
> > more explicit description...  
> 
> Do we have to re-discuss the upstream changelog policy every single 
> time again?
> 
> Yes, overly verbose, reader-friendly changelogs are preferred over 
> 'anyone who is an expert in this field should know all the 
> expectations, status quo and consequences' kind of minimalistic 
> changelogs.
> 
> The former is consciously information-rich and robust, the latter is 
> information-poor and prone to be fragile, prone to be ambiguous, 
> making both the merge flow, any bug and commit triage and eventual 
> later fixes more difficult.

I did a double take on the original, so yeah more verbose would be
good.  But generally you're right we should flag this kind of incorrect
usage, so from that perspective the patch looks good.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/