Re: [PATCH v2] linux/types.h: Restore the ability to disable sparse endianness checks

[Bart Van Assche]

On Mon, 2017-10-16 at 22:57 +0300, Michael S. Tsirkin wrote:
> On Mon, Oct 16, 2017 at 10:26:33AM -0700, Bart Van Assche wrote:
> > I think that this shows that the followed approach does not work,
> > probably because several driver authors do not use sparse. For
> > developers who are not the authors of these drivers it would take
> > a very significant effort to make these drivers endianness clean.
> 
> I'm afraid I still don't see it.  For developers endian-ness is really
> easy.  Look at hardware spec make sure code matches.  You can often do
> without looking at the spec too, if a given field is always used with
> cpu_to_le, mark it __le.  If you don't want to change driver code, you
> don't really need to run sparse on it.

You seem to assume that all drivers that are not yet endianness clean do
not contain any endianness conversion bugs. I severely doubt that that
assumption is correct. It is likely that it is not possible to make several
kernel drivers endianness clean due to endianness conversion bugs in such
drivers.

> > Examples are drivers/scsi/qla2xxx and drivers/infiniband/hw/nes.
> 
> These seem to be actively maintained. So post a patch, maintainers
> can look at the spec to help make sure annotations are right.

I don't have the time to delve deep in these two and the many other kernel
drivers that are not endianness clean. So please stop telling *me* that *I*
have to fix the endianness annotations in these drivers.

BTW, I think it should be mentioned here that you have tried to fix the
endianness annotations in the qla2xxx driver but once you noticed how 
complicated that task was that you gave up half-way. See also Michael
Tsirkin, [PATCH] scsi/qla2xxx: label endian-ness for many fields, 9 Dec
2016 (https://www.spinics.net/lists/linux-scsi/msg102739.html).

> > Hence restore the ability to disable sparse endianness checks such
> > that it becomes again easy to review other sparse diagnostics for
> > people who want to analyze drivers they are not the author of.
> 
> What are these diagnostics that are important to analyze?

E.g. a spin_unlock() that is missing from an error path. Sparse can detect
such errors.

> White-listing these as opposed to black-listing endian-ness might be a
> better idea.

As explained in a previous e-mail, any approach that suppresses endianness
error messages automatically makes it easier for driver authors to ignore
endianness error messages. This is why I prefer that if endianness error
messages are suppressed that this happens manually. Hence the patch at the
start of this e-mail thread that restores __CHECK_ENDIAN__.

Bart.