On Sun, Apr 24, 2022 at 12:54 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > And last time we discussed this, Al was looking at making it > byte-exact, and I'm pretty sure he noted that other architectures > already didn't do always do it. > > Let me go try to find it. Hmnm. I may have mis-remembered the details. The thread I was thinking of was this: https://lore.kernel.org/all/20200719031733.GI2786714@xxxxxxxxxxxxxxxxxx/ and while Al was arguing for not enforcing the exact byte count, he still suggested that it must make *some* progress. But note the whole "There are two problems with that. First of all, the promise was bogus - there are architectures where it is simply not true. E.g. ppc (or alpha, or sparc, or...) can have copy_from_user() called with source one word prior to an unmapped page, fetch that word, fail to fetch the next one and bugger off without doing any stores" ie it's simply never been the case in general, and Al mentions ppc, alpha and sparc as examples of architectures where it has not been true. (arm and arm64, btw, does seem to have the "try harder" byte copy loop at the end, like x86 does). And that's when I argued that we should just accept that the byte exact behavior simply has never been reality, and we shouldn't even try to make it be reality. NOTE! We almost certainly do want to have some limit of how much off we can be, though. I do *not* think we can just unroll the loop a ton, and say "hey, we're doing copies in chunks of 16 words, so now we're off by up to 128 bytes". I'd suggest making it clear that being "off" by a word is fine, because that's the natural thing for any architecture that needs to do a "load low/high word" followed by "store aligned word" due to not handling unaligned faults well (eg the whole traditional RISC thing). And yes, I think it's actually somewhat detrimental to our test coverage that x86 does the byte-exact thing, because it means that *if* we have any code that depends on it, it will just happen to work on x86, but then fail on architectures that don't get nearly the same test coverage. Linus
