linux-kernel - Re: 2.6.21-mm2: ACPI exception on resume

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]

Message-ID: <2c0942db0705231837k2941b9a0l9bb7d7cdc7d35195@mail.gmail.com>
Date:	Wed, 23 May 2007 18:37:38 -0700
From:	"Ray Lee" <ray-lk@...rabbit.org>
To:	"Henrique de Moraes Holschuh" <hmh@....eng.br>
Cc:	"Matt Mackall" <mpm@...enic.com>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: 2.6.21-mm2: ACPI exception on resume

On 5/23/07, Henrique de Moraes Holschuh <hmh@....eng.br> wrote:
> On Wed, 23 May 2007, Ray Lee wrote:
> > Which is the crux of my problem with your statement. I feel we
> > shouldn't give the wrong idea to those authors. They need to know that
> > the expectation is that 2.6.x is a stable series, and 2.6.x.y is for
> > dealing with unavoidable mistakes.
>
> Well, the only case where I feel a regression is justified is one where it
> is caused by a bug in the firmware or the hardware.

Here's the problem. Each of the people testing the kernel is a 'canary
in the coalmine.' If one person is having trouble, then it's likely
that there are ten more that will have the same issue. The real
problem here is that those other ten people aren't going to know how
to fix it, other than "it used to work, so obviously the kernel is now
doing something wrong."

This is particularly bad for firmware, where upgrading it may
introduce new regressions. I understand that there are broken
firmwares out there -- I have a laptop with one.  But there needs to
be a way to support broken systems and the sane ones simultaneously.
This is a requirement for the ACPI tree, for example, and it seems to
work.

All of this is assuming that the firmware really was at fault. It's
also possible that it's just doing something different than before,
and both behaviors are valid and should be dealt with gracefully.

> At which point my personal opinion is that users of firmware/hardware *that
> have a fix available* are to be told to apply the fix, unless the problem is
> so serious that it could potentially cause extreme damage (loss of human
> life, permanent hardware damage, major data loss).

Those are extreme. My point is that if you know who all those people
are, and are willing to contact them, then sure, that's viable.
Otherwise, the bottom line is that the kernel used to deal with a
problem gracefully, and now it doesn't. There's no telling how many
other people will get bit by the same problem, and most of those
people aren't going to know what to do about it, other than to
downgrade the kernel, and wait for it to magically get fixed by
someone else.

> If there is no fix the user can apply, then it really depends on how
> damaging it is to work around the issue for others: you don't punish those
> who have non-broken stuff to avoid problems for those that have broken
> stuff.

I understand your point of view, but another way to look at it is that
we always want to make forward progress on the code. If we don't, then
we're never going to have a good metric (measure) of how we're doing.

> Fortunately, most of the time one can come up with a fix that causes little
> to no loss to those with non-broken hardware/firmware.

And I'm sure those with the Big Brains(tm) can do so again.

Thanks,

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