Received: by 10.223.164.202 with SMTP id h10csp456451wrb; Wed, 8 Nov 2017 20:32:58 -0800 (PST) X-Google-Smtp-Source: ABhQp+T0QaGZDs8AzmhQW1dw43Q1+rCDQ7HRQx78Ng8NUeyWP787mMYoHnl8Qh5jYPnE4p6m3/qF X-Received: by 10.99.109.79 with SMTP id i76mr2729551pgc.134.1510201978639; Wed, 08 Nov 2017 20:32:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510201978; cv=none; d=google.com; s=arc-20160816; b=rxkEr/JLzZAyBh95kmH7RDouXx6XjTSr0C8XqJ31ZQFmOOXQOSkQ+nuER1Qiao9u2k OaNbDQtjMMRHbxHEQjbkXE/SdM0cBJNpTyyihikVlB/YTsBdNfFQKeYtaa+wG0a0VqiI 01EW44l9aaKRiwf9H/Ogo7xPvWgROyVjW3mnqyg4MC/zNCVp2WwfG68lAiNaQuC6ew1O I8xjKF3bBhGFDNQ3iOux+GxGTDAJCWNqsF5+0uUXib6B9+yGOVrwWF9NliQJoMKpukWw XMRWSmrLQBQrD6w3tra1Eksys4CS9/PAz2v7UiV7Yi6UmCJzMozFwCuxerdvZRpsedaL fH1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=qbr9lhR4c8VtVer7Osnn2Py+AAbEYPMAWL2Oq7OOd3c=; b=W3JvRXm49txwhTu5UqxFAQZ5N2pX6ElejdgOD7LFk3TSkwhxKCJxuQFGwZZFuWf1GR WUY39ZMgq53E0KVwCeeZ+QjQlqehauMflJhnwP8W5jtLPEics5UlRvinxIqc8uElQ3F8 2kQl6wwZPELTkGs3pmua4bqFKljqEEp5T30Oaeg0857USSUUKOrnqE+E3Ph2NeQh0fuY nW+ZFFxuNDQacj06HNY7ioregsm4pAL0by23kjwwZvDCHr9vuAmp1T8fHSblIXJ5SqvS l8GKRFI1nCvyduatu3eizO/ZlsU+rX5Qe0vyP84e1UWupLd0D9jz1SLaf6FKi7kQJi26 PW2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c11si5287924pll.792.2017.11.08.20.32.47; Wed, 08 Nov 2017 20:32:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752324AbdKIEbD (ORCPT + 82 others); Wed, 8 Nov 2017 23:31:03 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:60173 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716AbdKIEbC (ORCPT ); Wed, 8 Nov 2017 23:31:02 -0500 Received: from unknown (HELO lgeamrelo01.lge.com) (156.147.1.125) by 156.147.23.53 with ESMTP; 9 Nov 2017 13:31:00 +0900 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Received: from unknown (HELO localhost) (10.177.222.138) by 156.147.1.125 with ESMTP; 9 Nov 2017 13:31:00 +0900 X-Original-SENDERIP: 10.177.222.138 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Thu, 9 Nov 2017 13:35:53 +0900 From: Joonsoo Kim To: Michal Hocko Cc: Jaewon Kim , akpm@linux-foundation.org, vbabka@suse.cz, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jaewon31.kim@gmail.com Subject: Re: [PATCH] mm: page_ext: check if page_ext is not prepared Message-ID: <20171109043552.GC24383@js1304-P5Q-DELUXE> References: <20171107094131.14621-1-jaewon31.kim@samsung.com> <20171107094730.5732nqqltx2miszq@dhcp22.suse.cz> <20171108075956.GC18747@js1304-P5Q-DELUXE> <20171108142106.v76ictdykeqjzhhh@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171108142106.v76ictdykeqjzhhh@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 08, 2017 at 03:21:06PM +0100, Michal Hocko wrote: > On Wed 08-11-17 16:59:56, Joonsoo Kim wrote: > > On Tue, Nov 07, 2017 at 10:47:30AM +0100, Michal Hocko wrote: > > > [CC Joonsoo] > > > > > > On Tue 07-11-17 18:41:31, Jaewon Kim wrote: > > > > online_page_ext and page_ext_init allocate page_ext for each section, but > > > > they do not allocate if the first PFN is !pfn_present(pfn) or > > > > !pfn_valid(pfn). Then section->page_ext remains as NULL. lookup_page_ext > > > > checks NULL only if CONFIG_DEBUG_VM is enabled. For a valid PFN, > > > > __set_page_owner will try to get page_ext through lookup_page_ext. > > > > Without CONFIG_DEBUG_VM lookup_page_ext will misuse NULL pointer as value > > > > 0. This incurrs invalid address access. > > > > > > > > This is the panic example when PFN 0x100000 is not valid but PFN 0x13FC00 > > > > is being used for page_ext. section->page_ext is NULL, get_entry returned > > > > invalid page_ext address as 0x1DFA000 for a PFN 0x13FC00. > > > > > > > > To avoid this panic, CONFIG_DEBUG_VM should be removed so that page_ext > > > > will be checked at all times. > > > > > > > > <1>[ 11.618085] Unable to handle kernel paging request at virtual address 01dfa014 > > > > <1>[ 11.618140] pgd = ffffffc0c6dc9000 > > > > <1>[ 11.618174] [01dfa014] *pgd=0000000000000000, *pud=0000000000000000 > > > > <4>[ 11.618240] ------------[ cut here ]------------ > > > > <2>[ 11.618278] Kernel BUG at ffffff80082371e0 [verbose debug info unavailable] > > > > <0>[ 11.618338] Internal error: Oops: 96000045 [#1] PREEMPT SMP > > > > <4>[ 11.618381] Modules linked in: > > > > <4>[ 11.618524] task: ffffffc0c6ec9180 task.stack: ffffffc0c6f40000 > > > > <4>[ 11.618569] PC is at __set_page_owner+0x48/0x78 > > > > <4>[ 11.618607] LR is at __set_page_owner+0x44/0x78 > > > > <4>[ 11.626025] [] __set_page_owner+0x48/0x78 > > > > <4>[ 11.626071] [] get_page_from_freelist+0x880/0x8e8 > > > > <4>[ 11.626118] [] __alloc_pages_nodemask+0x14c/0xc48 > > > > <4>[ 11.626165] [] __do_page_cache_readahead+0xdc/0x264 > > > > <4>[ 11.626214] [] filemap_fault+0x2ac/0x550 > > > > <4>[ 11.626259] [] ext4_filemap_fault+0x3c/0x58 > > > > <4>[ 11.626305] [] __do_fault+0x80/0x120 > > > > <4>[ 11.626347] [] handle_mm_fault+0x704/0xbb0 > > > > <4>[ 11.626393] [] do_page_fault+0x2e8/0x394 > > > > <4>[ 11.626437] [] do_mem_abort+0x88/0x124 > > > > > > > > > > I suspec this goes all the way down to when page_ext has been > > > resurrected. It is quite interesting that nobody has noticed this in 3 > > > years but maybe the feature is not used all that much and the HW has to > > > be quite special to trigger. Anyway the following should be added > > > > > > Fixes: eefa864b701d ("mm/page_ext: resurrect struct page extending code for debugging") > > > Cc: stable > > > > IIRC, caller of lookup_page_ext() doesn't check 'NULL' until > > f86e427197 ("mm: check the return value of lookup_page_ext for all > > call sites"). So, this problem would happen old kernel even if this > > patch is applied to old kernel. > > OK, then the changelog should mention dependency on that check so that > anybody who backports this patch to pre 4.7 kernels knows to pull that > one as well. > > > IMO, proper fix is to check all the pfn in the section. It is sent > > from Jaewon in other mail. > > I believe that this patch is valuable on its own and the other one > should build on top of it. Okay, agreed. Thanks. From 1583508108930522658@xxx Wed Nov 08 14:23:33 +0000 2017 X-GM-THRID: 1583408356035992696 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread