The bug is obvious and fatal. No comments. It should be delivered as kpatch.
But the situation is quite interesting. There are two puzzles here. First, how the hell nobody have seen this? I was even sure it was introduced by me, because in my latest tests it kills vstorage instantly. Nope, it was always there, just neither our tests nor customer's load is enough to trigger it. vstorage uses for io only mlocked memory, so that no page faults are even possible. Here is the second puzzle. Why is it triggered at all? Here is the discovery: intel triggers lots of suprious useless page faults! No idea whether it is a hardware bug or it is a feature. But it looks like when one cpu accesses memory and internally sets accessed/dirty bits on pte, any access on other cpu triggers useless fault. Not exactly sure, but my investigation confirms this conjecture. Signed-off-by: Alexey Kuznetsov <[email protected]> --- fs/fuse/dev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index 168b0e5..c110206 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -2306,13 +2306,13 @@ static int copy_out_krpczc(struct fuse_copy_state *cs, struct fuse_args *args, /* copy data from userspace buff, otherwise data had been zero-copied */ if (src) { - dst = kmap_atomic(ap->pages[didx]); + dst = kmap_local_page(ap->pages[didx]); if (copy_from_user(dst + doff, src, copy)) { - kunmap_atomic(dst); + kunmap_local(dst); err = -EFAULT; goto out; } - kunmap_atomic(dst); + kunmap_local(dst); src += copy; } -- 1.8.3.1 _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
