On Wed, Oct 25, 2017 at 12:13:55PM +0200, greg@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. > > Oh, and the maintainers summit is already half over, and the schedule is > full from what I can tell... There is one open TBD slot. > > thanks, > > greg k-h > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss