在 2024/3/2 10:59, Linus Torvalds 写道:
On Thu, 29 Feb 2024 at 09:32, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
One option might be to make a failed memcpy_from_iter_mc() set another
flag in the iter, and then make fault_in_iov_iter_readable() test that
flag and return 'len' if that flag is set.
Something like that (wild handwaving) should get the right error handling.
The simpler alternative is maybe something like the attached.
COMPLETELY UNTESTED. Maybe I've confused myself with all the different
indiraction mazes in the iov_iter code.
Actually, I think the right model is to get rid of that horrendous
.copy_mc field entirely.
We only have one single place that uses it - that nasty core dumping
code. And that code is *not* performance critical.
And not only isn't it performance-critical, it already does all the
core dumping one page at a time because it doesn't want to write pages
that were never mapped into user space.
So what we can do is
(a) make the core dumping code *copy* the page to a good location
with copy_mc_to_kernel() first
(b) remove this horrendous .copy_mc crap entirely from iov_iter
I think this solution has two impacts:
1. Although it is not a performance-critical path, the CPU usage may be
affected by one more memory copy in some large-memory applications.
2. If a hardware memory error occurs in "good location" and the
".copy_mc" is removed, the kernel will panic.
I would prefer to use the previous solution(modify the implementation of
memcpy_from_iter_mc()).
Thanks,
Tong.
This is slightly complicated by the fact that copy_mc_to_kernel() may
not even exist, and architectures that don't have it don't want the
silly extra copy. So we need to abstract the "copy to temporary page"
code a bit. But that's probably a good thing anyway in that it forces
us to have nice interfaces.
End result: something like the attached.
AGAIN: THIS IS ENTIRELY UNTESTED.
But hey, so was clearly all the .copy_mc code too that this removes, so...
Linus
