[Ksummit-discuss] [TECH TOPIC] How to encourage driver authors to annotate integer endianness properly

[greg at kroah.com]

On Wed, Oct 25, 2017 at 01:24:23PM +0300, Leon Romanovsky wrote:
> On Wed, Oct 25, 2017 at 12:13:55PM +0200, greg at kroah.com wrote:
> > On Wed, Oct 25, 2017 at 10:06:59AM +0000, Bart Van Assche wrote:
> > > On Wed, 2017-10-25 at 11:54 +0200, Greg KH wrote:
> > > > On Wed, Oct 25, 2017 at 09:47:25AM +0000, Bart Van Assche wrote:
> > > > > Hello Ted,
> > > > >
> > > > > As you most likely know endianness annotations like __be32 can be verified
> > > > > by the static source code analyzer called sparse. These annotations are a
> > > > > big help to verify whether endianness conversions in drivers are correct
> > > > > (e.g. be32_to_cpu()). However, many driver authors either are not familiar
> > > > > with sparse or do not use it to verify their work. I think we need a way
> > > > > to encourage driver authors to pay attention to endianness annotations,
> > > > > e.g. by letting the zero-day kernel test infrastructure verify endianness
> > > > > annotations. Please consider to add this topic to the kernel summit agenda.
> > > >
> > > > Driver subsystem maintainers should know this, and sparse reports should
> > > > be simple to run and notice these issues.  If you know of a subsystem
> > > > that is not paying attention to this, please let those maintainers know
> > > > and send patches to resolve the issues :)
> > >
> > > Hi Greg,
> > >
> > > A significant challenge is that for several drivers (e.g. drivers/scsi/qla2xxx
> > > and drivers/infiniband/hw/nes) fixing the endianness annotations is so hard
> > > that only the driver authors can make these drivers endianness clean.
> >
> > Then ask them to do so, and if they will not, then mark the drivers in
> > Kconfig so they do not get built for big endian platforms.
> >
> > > Three challenges that have been encountered while trying to make
> > > drivers endianness clean are:
> > > - Some driver authors use a single variable to store both cpu-endian and big
> > >   endian data.
> > > - Endianness bugs - using a big endian integer where a cpu endian number
> > >   should have been used or vice versa.
> > > - The definitive resource for the endianness format is the firmware
> > >   documentation. For many kernel drivers the firmware documentation is either
> > >   not available or only available under NDA.
> >
> > These problems are not "new" at all, it's been this way for 20+ years now :)
> 
> The major difference between past and current is in the tools, they evolved.

endian support in sparse has been there for over a decade now, right?
This isn't a new issue, and if a driver author/team does not want to
do the work for a specific endian, then disable the drivers from that
build...

greg k-h