linux-kernel - Re: Major qla2xxx regression on sparc64

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: <20070416.123743.07452378.davem@davemloft.net>
Date:	Mon, 16 Apr 2007 12:37:43 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	andrew.vasquez@...gic.com
Cc:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	James.Bottomley@...elEye.com, ema@...ian.org
Subject: Re: Major qla2xxx regression on sparc64

From: Andrew Vasquez <andrew.vasquez@...gic.com>
Date: Mon, 16 Apr 2007 09:37:12 -0700

> On Mon, 16 Apr 2007, David Miller wrote:
> 
> > But even if that fails, I think the fallback code should be put back,
> > since it obviously was used by at least one system and it's probable
> > that there are some other applications of using this qla2xxx chip that
> > will have an empty NVRAM too.
> 
> Then they should really get their NVRAM corrected, if in fact their
> NVRAMs are cleared.
> 
> > I can understand the apprehension in using a fixed port_name[] value,
> > since it could conflict with other FC controllers on the mesh, but if
> > that is so important just choose some random value that is a valid FC
> > ID or use some characteristic ID that can be used to compose part of
> > the port WWN in order to give it at least some uniqueness.
> 
> Look, there's a fine balance here that we must strike -- the solution
> that you're proposing implies that there's some 'random' bit-space
> within the IEEE NAA with which one can safely encode without stomping
> on any valid OUI.

The fact is that your driver was significantly more robust
previously, and now it's so less robust that it now fails for
people.

That's totally unacceptable.

Just like the sparc64 systsems, others depending upon this fallback
behavior the qla2xxx driver had are going to break and they are not
going to be able to just go and fix their hardware and re-flash the
NVRAM.

Every user on the planet is going to be 1,000 times more happy with a
big fat warning in their kernel log saying that things might not go
right, but the driver is going to try anyways, rather than a complete
non-attempt to make things work.

You replaced a possible failure with a guarenteed one.

%99.9999999 of people are never going to run into a FC ID collision.
They have an onboard FC controller and a disk or two.  They DON'T
CARE, they want their systems to work and if you don't give them that
you're not being a good driver maintainer.

You BROKE things, therefore you must FIX it.

Now I'm happy to code up the sparc OFW property bits but your attitude
and perspective on this absolutely has to change and the old fallback
code still has to go back in there, possible FC ID collisions or not.
-
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/