On 09.07.2018 16:58, Thor Lancelot Simon wrote: > On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: >> >> The C11 standard could indeed use consistent wording. In one place >> "correctly aligned" in other alignment "restrictions" and >> "requirements". None of these terms is marked as a keyword or term and I >> read them in the context of the document as the same phenomenon (I >> haven't found a different interpretation of this in the wild). > > Right, but, architecturally, x86 doesn't have these "restrictions" or > "requirements". Not for correctness, not with the overwhelming majority > of integer instructions. Only (sometimes) for performance. > I have an experience of boosting an application processing packets, that moving members of a struct boosted the performance of an application by 20%. In my case it was not misalignment, but introduction of gaps into structs and not fitting them into CPU cache. > Which makes relying on the standard's language about unaligned access > incorrect. There's no undefined behavior here because there can't be; > strict alignment is not a feature of the target architecture. > I think that is interpretation of undefined behavior in C to what will happen on x86. Kernel UBSan checks the former and treats it as a bug. With some assumptions we can predict what will happen in the latter case... without the assumptions we aren't safe on x86 either (like the EFLAGS bit state) > I understand we have some code that's on the borderline between being MI > and MD, or that's "MD but for several different architectures". ACPICA > is an obvious example. And that such code may legitimately be compiled for > targets where unaligned access is not architecturally valid, and compilers > are free to do odd things with code that tries to do it. But the right > thing to do, I think, is to acknowledge that such code is MI; not to, by > misguided policy, insist that _all_ "MD" code should be written as if it > were MI. > put_misaligned()/get_misaligned() will handle these special cases, without changing algorithms in the code (already used in DRMKMS). In my test-case there are 7 subsystems or kernel features that trigger KUBSan. Access will be marked with proper compiler decoration and the problem will be gone. If we will detect that in some scenario during fuzzing we can trigger misaligned read in e.g. msdos fs, we will know why reading the same the code breaks on RPi. > Because if you head down that road, we're going to be forced to > write a bunch more stuff in assembler that we'd figured out over the decades > how to write in a performant and readable way in C; and I don't think anyone > benefits from having more asm in our kernel. > There is no danger of any major rewrite of anything, mostly small patches here and there. Also we already down to misaligned access reports. > Thor >
Attachment:
signature.asc
Description: OpenPGP digital signature