> For now, changing the semantics of the function seems like a sure way to > fail in the future though.
I doubt it. Nearly nobody uses the exact return value semantics. (iirc it's mostly write() and some bizarre code in mount) In fact it's a regular mistake to assume it returns -errno. > > In theory we could also duplicate the whole copy_*_ path for cases > > where the caller doesn't care about the exact bytes. But that > > seems overkill for just this issue, and I'm not sure anyone > > else cares about how fast this is. The simpler check works > > as well for now. > > So I don't get that code, but why not fix it in general? Taking two > faults seems silly. It's really complicated to reconstruct the exact bytes, as an optimized memcpy is very complicated and has a lot of corner cases. I tried it originally when writing the original copy function, but failed. That is why people came up later with this two-fault scheme. I think two fault is fine for most cases, just not for NMIs. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
