Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752964AbbDFR0V (ORCPT ); Mon, 6 Apr 2015 13:26:21 -0400 Received: from mail-ig0-f180.google.com ([209.85.213.180]:36111 "EHLO mail-ig0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751829AbbDFR0R (ORCPT ); Mon, 6 Apr 2015 13:26:17 -0400 MIME-Version: 1.0 In-Reply-To: <552204B8.40605@oracle.com> References: <552204B8.40605@oracle.com> Date: Mon, 6 Apr 2015 10:26:17 -0700 X-Google-Sender-Auth: -1vnaQ4NbniLb6O-Vh95fs28ZlM Message-ID: Subject: Re: Hang on large copy_from_user with PREEMPT_NONE From: Linus Torvalds To: Sasha Levin Cc: LKML , Rusty Russell , Dave Jones , Michal Hocko , Borislav Petkov , "the arch/x86 maintainers" Content-Type: multipart/mixed; boundary=047d7b343c9c7d42e505131198fc Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4235 Lines: 90 --047d7b343c9c7d42e505131198fc Content-Type: text/plain; charset=UTF-8 On Sun, Apr 5, 2015 at 8:59 PM, Sasha Levin wrote: > > This is the result of getting copy_user_handle_tail to zero out a large block of > kernel memory very inefficiently: Ugh. Normally we should be able to just do if (zerorest) memset(to, 0, len); and be done with it. The only reason we don't do that actually looks like a buglet in 'copy_in_user()', which can have a source fault but should *not* necessarily try to clear the rest of the destination buffer. But it uses the shared "copy_user_generic()" logic, so it doesn't even realize that. I call it a "buglet", because there's not necessarily anything horribly wrong with clearing the tail, it's just completely wasted work. And it makes the "oops, source is bad" case unnecessarily horribly slow. In fact, the whole "zerorest" thing is garbage, I think. The copy_user_generic() code seems to always set it to just 'len', and it's because it doesn't even know or care about the actual direction. The *real* test should just be "is the destination a kernel space buffer" (we have done the "access_ok()" things independently). And that test we can do without any 'zerorest' parameter. So the attached (untested) patch should (a) remove the pointless 'zerorest' parameter (b) fix the 'copy_in_user()' buglet (c) make the kernel destination case be much more efficient with just a simple 'memset()' Hmm? Comments? Sasha, do you have the initial random number state to recreate this easily? Linus --047d7b343c9c7d42e505131198fc Content-Type: text/plain; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i865fixe0 IGFyY2gveDg2L2luY2x1ZGUvYXNtL3VhY2Nlc3NfNjQuaCB8ICAyICstCiBhcmNoL3g4Ni9saWIv dXNlcmNvcHlfNjQuYyAgICAgICAgfCAxNSArKysrKysrLS0tLS0tLS0KIDIgZmlsZXMgY2hhbmdl ZCwgOCBpbnNlcnRpb25zKCspLCA5IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2 L2luY2x1ZGUvYXNtL3VhY2Nlc3NfNjQuaCBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3VhY2Nlc3Nf NjQuaAppbmRleCAxMmEyNmI5NzliZjEuLmYyZjliMzliMjc0YSAxMDA2NDQKLS0tIGEvYXJjaC94 ODYvaW5jbHVkZS9hc20vdWFjY2Vzc182NC5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3Vh Y2Nlc3NfNjQuaApAQCAtMjMxLDYgKzIzMSw2IEBAIF9fY29weV9mcm9tX3VzZXJfaW5hdG9taWNf bm9jYWNoZSh2b2lkICpkc3QsIGNvbnN0IHZvaWQgX191c2VyICpzcmMsCiB9CiAKIHVuc2lnbmVk IGxvbmcKLWNvcHlfdXNlcl9oYW5kbGVfdGFpbChjaGFyICp0bywgY2hhciAqZnJvbSwgdW5zaWdu ZWQgbGVuLCB1bnNpZ25lZCB6ZXJvcmVzdCk7Citjb3B5X3VzZXJfaGFuZGxlX3RhaWwoY2hhciAq dG8sIGNoYXIgKmZyb20sIHVuc2lnbmVkIGxlbik7CiAKICNlbmRpZiAvKiBfQVNNX1g4Nl9VQUND RVNTXzY0X0ggKi8KZGlmZiAtLWdpdCBhL2FyY2gveDg2L2xpYi91c2VyY29weV82NC5jIGIvYXJj aC94ODYvbGliL3VzZXJjb3B5XzY0LmMKaW5kZXggYzkwNWU4OWUxOWZlLi4xZjMzYjNkMWZkNjgg MTAwNjQ0Ci0tLSBhL2FyY2gveDg2L2xpYi91c2VyY29weV82NC5jCisrKyBiL2FyY2gveDg2L2xp Yi91c2VyY29weV82NC5jCkBAIC02OSwyMSArNjksMjAgQEAgRVhQT1JUX1NZTUJPTChjb3B5X2lu X3VzZXIpOwogICogaXQgaXMgbm90IG5lY2Vzc2FyeSB0byBvcHRpbWl6ZSB0YWlsIGhhbmRsaW5n LgogICovCiBfX3Zpc2libGUgdW5zaWduZWQgbG9uZwotY29weV91c2VyX2hhbmRsZV90YWlsKGNo YXIgKnRvLCBjaGFyICpmcm9tLCB1bnNpZ25lZCBsZW4sIHVuc2lnbmVkIHplcm9yZXN0KQorY29w eV91c2VyX2hhbmRsZV90YWlsKGNoYXIgKnRvLCBjaGFyICpmcm9tLCB1bnNpZ25lZCBsZW4pCiB7 Ci0JY2hhciBjOwotCXVuc2lnbmVkIHplcm9fbGVuOwotCiAJZm9yICg7IGxlbjsgLS1sZW4sIHRv KyspIHsKKwkJY2hhciBjOworCiAJCWlmIChfX2dldF91c2VyX25vY2hlY2soYywgZnJvbSsrLCBz aXplb2YoY2hhcikpKQogCQkJYnJlYWs7CiAJCWlmIChfX3B1dF91c2VyX25vY2hlY2soYywgdG8s IHNpemVvZihjaGFyKSkpCiAJCQlicmVhazsKIAl9Ci0KLQlmb3IgKGMgPSAwLCB6ZXJvX2xlbiA9 IGxlbjsgemVyb3Jlc3QgJiYgemVyb19sZW47IC0temVyb19sZW4pCi0JCWlmIChfX3B1dF91c2Vy X25vY2hlY2soYywgdG8rKywgc2l6ZW9mKGNoYXIpKSkKLQkJCWJyZWFrOwogCWNsYWMoKTsKKwor CS8qIElmIHRoZSBkZXN0aW5hdGlvbiBpcyBhIGtlcm5lbCBidWZmZXIsIHdlIGFsd2F5cyBjbGVh ciB0aGUgZW5kICovCisJaWYgKCh1bnNpZ25lZCBsb25nKXRvID49IFRBU0tfU0laRV9NQVgpCisJ CW1lbXNldCh0bywgMCwgbGVuKTsKIAlyZXR1cm4gbGVuOwogfQo= --047d7b343c9c7d42e505131198fc-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/