On 07.11.2019 16:26, Martin Husemann wrote: > On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote: >> On 07.11.2019 14:25, Valery Ushakov wrote: >>> If the sanitizer does complain about other uses, there is little point >>> in fixing one instance and not the others. >> >> We already agreed with Christos that this is appeasing of GCC. If you >> want to scan the whole kernel (or whole C) file for more occurrences of >> violations - please go for it. > > No. The commit needs to be reverted, and then > > a) either the root cause for the unaligned address be fixed or > b) some other means be found to make the sanitizer shut up > > As uwe said: papering over a tiny detail that *never* hits in the real > world but potentialy hiding a real issue is not the way to go. > I don't have a readily available reproducer locally but it was breaking syzbot from booting after the switch to gcc8. I will fix it differently aligning the whole struct (so the same approach as we use in userland) and backout this change. > Martin > > P.S.: Independend of this I would still like an official C standard > clarification; in my reading a simple address calculation is not > accessing an object through a pointer (which would be the undefined > behaviour). If the C standard is not clear on this, it needs to be > improved. > Unfortunately the C committee went into the opposite direction here and specified a potential dereference. All I can do now is to add another exception, &p[x] is allowed and it is not far from &p->x. It is also a tricky part as some things are unequally documented for p->x and for (*p).x... so not sure if it is worth trying out really... especially that offsetof() as defined for this purpose.
Attachment:
signature.asc
Description: OpenPGP digital signature