Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753346AbbDFUm2 (ORCPT ); Mon, 6 Apr 2015 16:42:28 -0400 Received: from mail-ig0-f174.google.com ([209.85.213.174]:34657 "EHLO mail-ig0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753062AbbDFUm1 (ORCPT ); Mon, 6 Apr 2015 16:42:27 -0400 MIME-Version: 1.0 In-Reply-To: <5522D9A8.5080104@oracle.com> References: <552204B8.40605@oracle.com> <5522D9A8.5080104@oracle.com> Date: Mon, 6 Apr 2015 13:42:26 -0700 X-Google-Sender-Auth: wFSpjEi_J8OZN45NXwV-xGWtIbk 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: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1726 Lines: 36 On Mon, Apr 6, 2015 at 12:08 PM, Sasha Levin wrote: > > Your patch just makes it hang in memset instead: So it's certainly a big memset (2GB or so: original count in RDX: 0x7e777000, and "%rcx << 6" is bytes left, so it has done about 85% of it), which is certainly going to be slow, but it shouldn't *hang*. The kernel memory should be all there and allocated, so it should be just limited by memory speeds, which shouldn't be enough to take 22s. The previous "one byte at a time" case I could easily have seen being slow enough to , but 2GB of pre-allocated memory? Weird. Any half-way normal memory subsystem should write memory at tens of GB/s. So it's a bit odd that the watchdog triggers. That said, maybe there is some virtualization thing that slows down these things by an order of magniture or two (for example, paging in the host). At that point I can easily see the 2GB memset() taking a long time. The main (only, really) reason we zero the target kernel buffer is for security reasons, but that's really mainly for copying structures from user space or for the data copy for write() system calls etc. So we could easily say that we limit the clearing to a single hugepage or something, since anything bigger than that is going to be into vmalloc space and the copyer had *better* check the return value anyway. Alternatively, we could just limit module loading size to some (fairly arbitrary) big number. Linus -- 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/