From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1371AC4360C for ; Tue, 8 Oct 2019 09:12:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D56B206C2 for ; Tue, 8 Oct 2019 09:12:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D56B206C2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 12CB18E0005; Tue, 8 Oct 2019 05:12:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B6DE8E0003; Tue, 8 Oct 2019 05:12:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E72ED8E0005; Tue, 8 Oct 2019 05:12:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id BF7BA8E0003 for ; Tue, 8 Oct 2019 05:12:57 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 6138B52A3 for ; Tue, 8 Oct 2019 09:12:57 +0000 (UTC) X-FDA: 76020052794.11.point33_8e2062095d40d X-HE-Tag: point33_8e2062095d40d X-Filterd-Recvd-Size: 12045 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 09:12:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 34D7CAF25; Tue, 8 Oct 2019 09:12:55 +0000 (UTC) Subject: Re: [Question] pfn_valid_within(page_to_pfn(buddy)) vs pfn_valid_within(buddy_pfn) in __free_one_page() To: Kefeng Wang , linux-mm@kvack.org Cc: Michal Hocko , Andrew Morton , Mel Gorman , qiuguorui1@huawei.com References: From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; prefer-encrypt=mutual; keydata= mQINBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABtCBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PokCVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJcbbyGBQkH8VTqAAoJECJPp+fMgqZkpGoP /1jhVihakxw1d67kFhPgjWrbzaeAYOJu7Oi79D8BL8Vr5dmNPygbpGpJaCHACWp+10KXj9yz fWABs01KMHnZsAIUytVsQv35DMMDzgwVmnoEIRBhisMYOQlH2bBn/dqBjtnhs7zTL4xtqEcF 1hoUFEByMOey7gm79utTk09hQE/Zo2x0Ikk98sSIKBETDCl4mkRVRlxPFl4O/w8dSaE4eczH LrKezaFiZOv6S1MUKVKzHInonrCqCNbXAHIeZa3JcXCYj1wWAjOt9R3NqcWsBGjFbkgoKMGD usiGabetmQjXNlVzyOYdAdrbpVRNVnaL91sB2j8LRD74snKsV0Wzwt90YHxDQ5z3M75YoIdl byTKu3BUuqZxkQ/emEuxZ7aRJ1Zw7cKo/IVqjWaQ1SSBDbZ8FAUPpHJxLdGxPRN8Pfw8blKY 8mvLJKoF6i9T6+EmlyzxqzOFhcc4X5ig5uQoOjTIq6zhLO+nqVZvUDd2Kz9LMOCYb516cwS/ Enpi0TcZ5ZobtLqEaL4rupjcJG418HFQ1qxC95u5FfNki+YTmu6ZLXy+1/9BDsPuZBOKYpUm 3HWSnCS8J5Ny4SSwfYPH/JrtberWTcCP/8BHmoSpS/3oL3RxrZRRVnPHFzQC6L1oKvIuyXYF rkybPXYbmNHN+jTD3X8nRqo+4Qhmu6SHi3VquQENBFsZNQwBCACuowprHNSHhPBKxaBX7qOv KAGCmAVhK0eleElKy0sCkFghTenu1sA9AV4okL84qZ9gzaEoVkgbIbDgRbKY2MGvgKxXm+kY n8tmCejKoeyVcn9Xs0K5aUZiDz4Ll9VPTiXdf8YcjDgeP6/l4kHb4uSW4Aa9ds0xgt0gP1Xb AMwBlK19YvTDZV5u3YVoGkZhspfQqLLtBKSt3FuxTCU7hxCInQd3FHGJT/IIrvm07oDO2Y8J DXWHGJ9cK49bBGmK9B4ajsbe5GxtSKFccu8BciNluF+BqbrIiM0upJq5Xqj4y+Xjrpwqm4/M ScBsV0Po7qdeqv0pEFIXKj7IgO/d4W2bABEBAAGJA3IEGAEKACYWIQSpQNQ0mSwujpkQPVAi T6fnzIKmZAUCWxk1DAIbAgUJA8JnAAFACRAiT6fnzIKmZMB0IAQZAQoAHRYhBKZ2GgCcqNxn k0Sx9r6Fd25170XjBQJbGTUMAAoJEL6Fd25170XjDBUH/2jQ7a8g+FC2qBYxU/aCAVAVY0NE YuABL4LJ5+iWwmqUh0V9+lU88Cv4/G8fWwU+hBykSXhZXNQ5QJxyR7KWGy7LiPi7Cvovu+1c 9Z9HIDNd4u7bxGKMpn19U12ATUBHAlvphzluVvXsJ23ES/F1c59d7IrgOnxqIcXxr9dcaJ2K k9VP3TfrjP3g98OKtSsyH0xMu0MCeyewf1piXyukFRRMKIErfThhmNnLiDbaVy6biCLx408L Mo4cCvEvqGKgRwyckVyo3JuhqreFeIKBOE1iHvf3x4LU8cIHdjhDP9Wf6ws1XNqIvve7oV+w B56YWoalm1rq00yUbs2RoGcXmtX1JQ//aR/paSuLGLIb3ecPB88rvEXPsizrhYUzbe1TTkKc 4a4XwW4wdc6pRPVFMdd5idQOKdeBk7NdCZXNzoieFntyPpAq+DveK01xcBoXQ2UktIFIsXey uSNdLd5m5lf7/3f0BtaY//f9grm363NUb9KBsTSnv6Vx7Co0DWaxgC3MFSUhxzBzkJNty+2d 10jvtwOWzUN+74uXGRYSq5WefQWqqQNnx+IDb4h81NmpIY/X0PqZrapNockj3WHvpbeVFAJ0 9MRzYP3x8e5OuEuJfkNnAbwRGkDy98nXW6fKeemREjr8DWfXLKFWroJzkbAVmeIL0pjXATxr +tj5JC0uvMrrXefUhXTo0SNoTsuO/OsAKOcVsV/RHHTwCDR2e3W8mOlA3QbYXsscgjghbuLh J3oTRrOQa8tUXWqcd5A0+QPo5aaMHIK0UAthZsry5EmCY3BrbXUJlt+23E93hXQvfcsmfi0N rNh81eknLLWRYvMOsrbIqEHdZBT4FHHiGjnck6EYx/8F5BAZSodRVEAgXyC8IQJ+UVa02QM5 D2VL8zRXZ6+wARKjgSrW+duohn535rG/ypd0ctLoXS6dDrFokwTQ2xrJiLbHp9G+noNTHSan ExaRzyLbvmblh3AAznb68cWmM3WVkceWACUalsoTLKF1sGrrIBj5updkKkzbKOq5gcC5AQ0E Wxk1NQEIAJ9B+lKxYlnKL5IehF1XJfknqsjuiRzj5vnvVrtFcPlSFL12VVFVUC2tT0A1Iuo9 NAoZXEeuoPf1dLDyHErrWnDyn3SmDgb83eK5YS/K363RLEMOQKWcawPJGGVTIRZgUSgGusKL NuZqE5TCqQls0x/OPljufs4gk7E1GQEgE6M90Xbp0w/r0HB49BqjUzwByut7H2wAdiNAbJWZ F5GNUS2/2IbgOhOychHdqYpWTqyLgRpf+atqkmpIJwFRVhQUfwztuybgJLGJ6vmh/LyNMRr8 J++SqkpOFMwJA81kpjuGR7moSrUIGTbDGFfjxmskQV/W/c25Xc6KaCwXah3OJ40AEQEAAYkC PAQYAQoAJhYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJbGTU1AhsMBQkDwmcAAAoJECJPp+fM gqZkPN4P/Ra4NbETHRj5/fM1fjtngt4dKeX/6McUPDIRuc58B6FuCQxtk7sX3ELs+1+w3eSV rHI5cOFRSdgw/iKwwBix8D4Qq0cnympZ622KJL2wpTPRLlNaFLoe5PkoORAjVxLGplvQIlhg miljQ3R63ty3+MZfkSVsYITlVkYlHaSwP2t8g7yTVa+q8ZAx0NT9uGWc/1Sg8j/uoPGrctml hFNGBTYyPq6mGW9jqaQ8en3ZmmJyw3CHwxZ5FZQ5qc55xgshKiy8jEtxh+dgB9d8zE/S/UGI E99N/q+kEKSgSMQMJ/CYPHQJVTi4YHh1yq/qTkHRX+ortrF5VEeDJDv+SljNStIxUdroPD29 2ijoaMFTAU+uBtE14UP5F+LWdmRdEGS1Ah1NwooL27uAFllTDQxDhg/+LJ/TqB8ZuidOIy1B xVKRSg3I2m+DUTVqBy7Lixo73hnW69kSjtqCeamY/NSu6LNP+b0wAOKhwz9hBEwEHLp05+mj 5ZFJyfGsOiNUcMoO/17FO4EBxSDP3FDLllpuzlFD7SXkfJaMWYmXIlO0jLzdfwfcnDzBbPwO hBM8hvtsyq8lq8vJOxv6XD6xcTtj5Az8t2JjdUX6SF9hxJpwhBU0wrCoGDkWp4Bbv6jnF7zP Nzftr4l8RuJoywDIiJpdaNpSlXKpj/K6KrnyAI/joYc7 Message-ID: <67e418a0-d56b-8b2b-13da-c777e67f7013@suse.cz> Date: Tue, 8 Oct 2019 11:12:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/8/19 10:35 AM, Kefeng Wang wrote: > Hi Vlastimil and all, >=20 > We met a Null pointer when do page_to_pfn() in __free_one_page() in ol= der kernel, __nr_to_section(__sec) return NULL, >=20 > #define __page_to_pfn(pg) \ > ({ const struct page *__pg =3D (pg); \ > int __sec =3D page_to_section(__pg); \ > (unsigned long)(__pg - __section_mem_map_addr(__nr_to_section(__sec))= ); \ > }) >=20 > Before v4.11, __free_one_page() use pfn_valid_within(page_to_pfn(buddy= )) to check pfn, after the Hmm, looks like the code before v4.11 was wrong. pfn_valid_(within) should be checked first, before obtaining and working with the struct page. Here we already have a struct page obtained by pointer arithmetics, and are calling page_to_pfn() on it, which means accessing its flags. The pfn_valid_within() then comes too late. > following patches, it use buddy_pfn directly. >=20 > b4fb8f66f1ae mm, page_alloc: Add missing check for memory holes > 13ad59df67f1 mm, page_alloc: avoid page_to_pfn() when merging buddies = // NOTE: directly use buddy_pfn > 76741e776a37 mm, page_alloc: don't convert pfn to idx when merging Looks like my patches fixed that code without realizing there was the bug. Commit b4fb8f66f1ae shows I've also introduced it elsewhere. > If use page_to_pfn(buddy) back in mainline 5.4-rc2, the same issue will= occur, No surprise, we must validate pfn first before touching the page. > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index c0b2e0306720..fbbfe8e8b4ca 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -934,7 +934,7 @@ static inline void __free_one_page(struct page *pag= e, > buddy_pfn =3D __find_buddy_pfn(pfn, order); > buddy =3D page + (buddy_pfn - pfn); >=20 > - if (!pfn_valid_within(buddy_pfn)) > + if (!pfn_valid_within(page_to_pfn(buddy))) > goto done_merging; > if (!page_is_buddy(page, buddy, order)) > goto done_merging; >=20 > It shows the buddy->flags is wrong, that is, buddy is bad, we find the = buddy by page + (buddy_pfn - pfn), > so there is some issue in __find_buddy_pfn(pfn, order)? No, result of __find_buddy_pfn has to be validated first. > The following is the debug print and CallTrace, any comment? >=20 > Thanks, > Kefeng >=20 > 1) MEMBLOCK configuration: > memory size =3D 0x0000000036800000 reserved size =3D 0x0000000004ca7fb= c > memory.cnt =3D 0x4 > memory[0x0] [0x0000000000000000-0x0000000013ffffff], 0x000000001400000= 0 bytes flags: 0x0 > memory[0x1] [0x000000002d600000-0x0000000033ffffff], 0x0000000006a0000= 0 bytes flags: 0x0 > memory[0x2] [0x0000000034800000-0x00000000445fffff], 0x000000000fe0000= 0 bytes flags: 0x0 > memory[0x3] [0x0000000044a00000-0x00000000509fffff], 0x000000000c00000= 0 bytes flags: 0x0 > reserved.cnt =3D 0x6 > reserved[0x0] [0x000000002d680000-0x000000002e7c8fff], 0x0000000001149= 000 bytes flags: 0x0 > reserved[0x1] [0x0000000030b00000-0x000000003239cfff], 0x000000000189d= 000 bytes flags: 0x0 > reserved[0x2] [0x0000000032400000-0x00000000324fffff], 0x0000000000100= 000 bytes flags: 0x0 > reserved[0x3] [0x000000004e000000-0x000000004fffffff], 0x0000000002000= 000 bytes flags: 0x0 > reserved[0x4] [0x000000005083e040-0x0000000050849ffb], 0x000000000000b= fbc bytes flags: 0x0 > reserved[0x5] [0x000000005084a000-0x00000000509fffff], 0x00000000001b6= 000 bytes flags: 0x0 These might be holes in the zones, right. > 2) CONFIG > CONFIG_SPARSEMEM_MANUAL=3Dy > CONFIG_SPARSEMEM=3Dy > CONFIG_HAVE_MEMORY_PRESENT=3Dy > CONFIG_SPARSEMEM_EXTREME=3Dy > CONFIG_SPARSEMEM_VMEMMAP_ENABLE=3Dy > # CONFIG_SPARSEMEM_VMEMMAP is not set Is CONFIG_HOLES_IN_ZONE enabled? Probably yes as that's arm64. > 3) debug print and CallTrace > __free_one_page , order =3D 9, max_order =3D 11, page =3D ffffff804e128= 000, buddy =3D ffffff804e120000, sec =3D 42623, mem_section =3D 000000000= 0000000 I would assume buddy is in one of the holes, but you'd have to print the = pfn's to be sure. > buddy =3D ffffff804e120000, __sec =3D 42623, buddy->flags =3D 299fcc27a= ebc552f, SECTIONS_PGSHIFT =3D 46, SECTIONS_MASK =3D 3ffff > __section_mem_map_addr, section =3D 0000000000000000 > ------------[ cut here ]------------ > Ignoring spurious kernel translation fault at virtual address 000000000= 0000000 > WARNING: CPU: 1 PID: 29 at ../arch/arm64/mm/fault.c:302 __do_kernel_fau= lt+0xb8/0x130 > Modules linked in: > CPU: 1 PID: 29 Comm: kworker/1:1 Not tainted 5.4.0-rc2+ #16 > Hardware name: linux,dummy-virt (DT) > Workqueue: events delayed_fput > pstate: 60000085 (nZCv daIf -PAN -UAO) > pc : __do_kernel_fault+0xb8/0x130 > lr : __do_kernel_fault+0xb8/0x130 > sp : ffffffc011273560 > x29: ffffffc011273560 x28: ffffff805020ce00 > x27: ffffff804e128000 x26: ffffff804e120000 > x25: 0000000000000000 x24: 0000000000000025 > x23: 0000000096000005 x22: 0000000000000025 > x21: 0000000096000005 x20: ffffffc011273650 > x19: 0000000000000000 x18: 0000000000000000 > x17: 00000000f06e9c14 x16: 0000000000000014 > x15: 0000000000000000 x14: 7320303030303030 > x13: 6c20616464726573 x12: 7420766972747561 > x11: 206661756c742061 x10: 6e736c6174696f6e > x9 : 726e656c20747261 x8 : 72696f7573206b65 > x7 : 72696e6720737075 x6 : 0000000000000000 > x5 : 0000000000000001 x4 : 0000000000000000 > x3 : 0000000000000000 x2 : 0000000000000000 > x1 : 0095a39d527dc9a0 x0 : 0000000000000000 > Call trace: > __do_kernel_fault+0xb8/0x130 > do_page_fault+0x60/0x3ec > do_translation_fault+0x40/0x78 > do_mem_abort+0x50/0xa8 > el1_da+0x20/0x94 > __free_one_page+0x1d8/0x31c > free_pcppages_bulk+0x1dc/0x258 > free_unref_page_commit.isra.114+0xb0/0xc0 > free_unref_page_list+0x144/0x198 > release_pages+0x8c/0x2bc > __pagevec_release+0x38/0x48 > pagevec_release+0x14/0x20 > shmem_undo_range+0x23c/0x49c > shmem_truncate_range+0x38/0x58 > shmem_evict_inode+0xd4/0x1e8 > evict+0xb8/0x174 > iput+0x178/0x1c0 > dentry_unlink_inode+0x120/0x124 > __dentry_kill+0x98/0x170 > dput+0x88/0x140 > __fput+0x184/0x1e8 > delayed_fput+0x40/0x54 > process_one_work+0x1a4/0x294 > worker_thread+0x1ec/0x284 > kthread+0xf0/0x100 > ret_from_fork+0x10/0x18 > ---[ end trace ebdfde5c0fdc7511 ]--- > ------------[ cut here ]------------ >=20