linux-kernel - Re: [01/38] PCI: Set PCI-E Max Payload Size on fabric

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]

Date:	Tue, 11 Oct 2011 15:32:04 -0600
From:	Greg KH <gregkh@...e.de>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Greg KH <greg@...ah.com>, Benjamin LaHaise <bcrl@...ck.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	stable-review@...nel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Jon Mason <mason@...i.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [01/38] PCI: Set PCI-E Max Payload Size on fabric

On Tue, Oct 11, 2011 at 02:22:11PM -0600, Bjorn Helgaas wrote:
> On Tue, Oct 11, 2011 at 1:56 PM, Greg KH <greg@...ah.com> wrote:
> > On Tue, Oct 11, 2011 at 01:47:47PM -0600, Bjorn Helgaas wrote:
> >> On Tue, Oct 11, 2011 at 1:24 PM, Greg KH <greg@...ah.com> wrote:
> >> > On Tue, Oct 11, 2011 at 12:14:05PM -0600, Bjorn Helgaas wrote:
> >>
> >> >> It's not obvious that this fits the criteria for -stable
> >> >> (Documentation/stable_kernel_rules.txt).
> >> >>
> >> >> For example, I can't tell what real problem this fixes.
> >> >
> >> > Yeah, it's not obvious, but I have had a lot of reports that 3.0 does
> >> > not work on some systems without this set of patches.  Now figuring out
> >> > of those same systems ever worked at all is getting to be quite
> >> > difficult as I don't have access to the hardware, and the people that do
> >> > aren't responding to test requests.  But from what I gather, 2.6.32 did
> >> > work on these boxes, so it is a regression somehow, but I am not
> >> > positive of this.
> >>
> >> I'd like to know more about this regression.
> >
> > It shows up as an oops that prevents the machine from booting.
> >
> >> > Now I'm very open to pushback, and if people really don't want these in
> >> > (i.e. the PCI maintainer(s) say no), then I'll drop them and work with
> >> > the distros to get them into their trees so that their customers's
> >> > systems will work properly.
> >>
> >> If distros want these patches, does that mean they have bug reports?
> >> URLs to them would be helpful.
> >
> > All of the ones I have are "private" at the moment due to the hardware
> > and product being tested by the users, sorry.
> >
> > I really wish that some of the people who had this problem would post
> > publically, and I guess we could just say, because they aren't being
> > public about it, it shouldn't go into a stable tree.  And I don't have a
> > problem with that.
> 
> I think accepting patches without our having a chance to see the
> problem sets a bad precedent.  It's quite common to see patches that
> "solve" the problem, but do it in the wrong way.
> 
> If the hardware is secret, maybe they could open a new, sanitized bug
> report?  It should be easy to remove the valuable details from the
> dmesg log and oops.

I'll go ask again for them to do this, and I'll drop these patches from
the release.

thanks,

greg k-h
--
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/