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

greg at kroah.com greg at kroah.com
Wed Oct 25 10:13:55 UTC 2017


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 :)

Oh, and the maintainers summit is already half over, and the schedule is
full from what I can tell...

thanks,

greg k-h


More information about the Ksummit-discuss mailing list