linux-kernel - Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325

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:	Mon, 30 Jun 2008 02:39:47 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Ingo Molnar <mingo@...e.hu>, Matthew Garrett <mjg59@...f.ucam.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	Andi Kleen <andi-suse@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325

On Mon, 30 Jun 2008, Rafael J. Wysocki wrote:

> > > well as long as we eliminate the bad effects around via DMI exceptions 
> > > nobody will feel the need to argue whether it's a regression ;-) [this 
> > > problem could be argued to be a regression, even if it's caused by prior 
> > > luck/stupidity of Linux. We have to live with the effects of our 
> > > mistakes.]
> > 
> >  Of course -- this is the only reason I can be bothered with the issue in
> > the first place.  Otherwise, I would have said: 'Get the manufacturer to
> > fix it, use "noapic" or live with a local patch.'
> 
> In that case your patch would surely make it to the regression list.

 Please be careful -- you seem to contradict yourself.  I wrote to the
effect of: "If this wasn't a regression, I would have said [...]" and your
reply is: "In that case your [non-regressing] patch would surely make it
to the regression list."

> >  This is actually how I have kept one of my old MPS SMP systems up for
> > years now -- it has a broken MP table which prevents interrupts from
> > working when too many PCI option cards are present, so I have prepared a
> > patch for patching the table manually.  I proposed it once, which you may
> > recall, but it was rejected on the grounds of the syntax being too tough
> > to comprehend to a poor average user being.  I am sure more systems would
> > benefit as MP table breakages used to be quite common.
> > 
> >  Here the simple workaround was "noapic" too, so everyone else could be
> > happy and I have been happy to keep the patch and use the capabilities of
> > the piece of hardware properly despite its broken firmware.
> 
> Again.  If there's a configuration that didn't need any manual workarounds
> before, it's expected to continue to work without any manual workarounds and
> as a patch submitter, it's _your_ burden to make that happen.

 That is certainly true for standard hardware.  We have to take
responsibility for own bugs, sure.  I cannot readily understand why you
apparently try to imply hardware vendors do not.

> Otherwise you throw this burden onto users who
> (1) don't expect things to stop working,
> (2) may not be able to figure out themselves what the right workaround is,
> (3) may not be able to make hardware manufacturers do anything.
> 
> If there's a configuration that worked before your patch and doesn't work
> after it, you're hurting the users of that configuration.

 Honestly?  These poor users who have no clue or time to follow the
development lists and/or fix bugs themselves should report the problem to
the supplier of their Linux distribution, who would sort it out by, first,
providing a temporary workaround till the problem is sorted out correctly,
second, contacting the hardware vendor through a recognised channel to
request the problem to be investigated and fixed properly.  I am fairly
sure all the reputable (responsible?) distribution vendors have service
agreements already in place with all the major hardware vendors and all
the minor hardware vendors will be happy to cooperate anyway so as not to
be minor vendors anymore.  This is why I have asked for points of contact 
repeatedly in this thread.

 Of course it leaves hobbyist distributions at a slight disadvantage, but
their users are sort of expected to be "power users" (otherwise they
wouldn't have been hobbyists, would they?) and adding an option or a patch
even should not be a problem for them.  We may try to do our best to help
them, but not at the price of penalising good hardware.

  Maciej
--
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/