Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751919AbeAPTa6 (ORCPT + 1 other); Tue, 16 Jan 2018 14:30:58 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:43202 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbeAPTa4 (ORCPT ); Tue, 16 Jan 2018 14:30:56 -0500 X-Google-Smtp-Source: ACJfBouGI4ZhIYCEuZv9yiJMvg5sKHrwfzSCQ16in+mZSxDPl5p5uZJdgBr73Lv+PahM2qKDua/s2lDDvNbR0MblKTE= MIME-Version: 1.0 In-Reply-To: <7f100b0f-3588-be25-41f6-a0e4dde27916@linux.intel.com> References: <201801142054.FAD95378.LVOOFQJOFtMFSH@I-love.SAKURA.ne.jp> <201801160115.w0G1FOIG057203@www262.sakura.ne.jp> <7f100b0f-3588-be25-41f6-a0e4dde27916@linux.intel.com> From: Linus Torvalds Date: Tue, 16 Jan 2018 11:30:54 -0800 X-Google-Sender-Auth: 0I5osyKp1_Pyz-SrT7ExK9lzmdk Message-ID: Subject: Re: [mm 4.15-rc8] Random oopses under memory pressure. To: Dave Hansen Cc: Tetsuo Handa , Linux Kernel Mailing List , linux-mm , "the arch/x86 maintainers" , linux-fsdevel , Michal Hocko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 16, 2018 at 12:06 AM, Dave Hansen wrote: > On 01/15/2018 06:14 PM, Linus Torvalds wrote: >> But I'm adding Dave Hansen explicitly to the cc, in case he has any >> ideas. Not because I blame him, but he's touched the sparsemem code >> fairly recently, so maybe he'd have some idea on adding sanity >> checking to the sparsemem version of pfn_to_page(). > > I swear I haven't touched it lately! Heh. I did git blame -C mm/sparse.c | grep 2017 and your name shows up at the beginning a lot because of commit c4e1be9ec113 ("mm, sparsemem: break out of loops early"). And Michal Hocko (who shows up even more) was already on the cc. > I'm not sure I'd go after pfn_to_page(). *Maybe* if we were close to > the places where we've done a pfn_to_page(), but I'm not seeing those. Fair enough. I just wanted to add debugging, looked at Tetsuo's config, and went "no way am I adding debugging to the sparsemem case because it's so confusing". That said, I also started looking at "kmap_to_page()". That's something that is *really* different with HIGHMEM, and while most of the users are in random drivers that do crazy things, I do note that one of the users is in mm/swap.c. That thing goes back to commit 5a178119b0fb ("mm: add support for direct_IO to highmem pages") and was only used for swap_writepage(), if I read this right. That swap_writepage() use of kmap()'ed patches was removed some time later in commit 62a8067a7f35 ("bio_vec-backed iov_iter"), but the crazy kmap_to_page() thing remained. I see nothing actively wrong in there, but it really feels like a "that is all bogus" thing to me. > Did anyone else notice the > > [ 31.068198] ? vmalloc_sync_all+0x150/0x150 > > present in a bunch of the stack traces? That should be pretty uncommon. No, didn't notice that. And yes, vmalloc_sync_all() might be interesting. > Is it just part of the normal do_page_fault() stack and the stack > dumper picks up on it? I don't think so. It should *not* happen normally. The fact that it shows up in the trace means it happened that time. It doesn't seem HIGHMEM-related, though. Or maybe the highmem signal is bogus too, and it's just that Tetsuo's reproducer needs magical timing. Linus