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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D43A8C2BD09 for ; Wed, 10 Jul 2024 00:14:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65FBC6B0088; Tue, 9 Jul 2024 20:14:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6101B6B008A; Tue, 9 Jul 2024 20:14:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D7C66B0092; Tue, 9 Jul 2024 20:14:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 30C626B0088 for ; Tue, 9 Jul 2024 20:14:54 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D5506C16F3 for ; Wed, 10 Jul 2024 00:14:53 +0000 (UTC) X-FDA: 82321922466.10.1257AB5 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf27.hostedemail.com (Postfix) with ESMTP id 18C5C40009 for ; Wed, 10 Jul 2024 00:14:51 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pYU7uDlG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of hughd@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720570468; a=rsa-sha256; cv=none; b=u8KESgQYj5+q2je754cO5l43NNJaINn83wvzmGn3tjJlcQUuYe+ZFwVAeD8SJQU+Ma55az xg1JK9yu3bO9mgaptps6axJaF1ljwtdK4O1X1g2SFir8mB/RxEsrPHhHL7TV362fQsWf7t NFmSbUYeMVCHaI2GoOGZO1GzQqdsA88= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pYU7uDlG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of hughd@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720570468; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cYzCTDwEK2pMUJCfcFRfctFHDDdLzr2h8y801pHs+Og=; b=OBOP8JpYP1kjdAgIGOWAwCrlNrbHLOISx5Nj70bZEkxXyasgLHhv2VMQJRe+e3xY97HSKb HGuLNfOzHYglbZcZVJl2xs1ZLiEu2scbnXpG2J+GMKvqFdd7CKbkqAIoCQY/b1OPW+jAs1 9zzd7MRnYM96vnHNow6BpVbaLiZdZDU= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-64b0d45a7aaso54823457b3.0 for ; Tue, 09 Jul 2024 17:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1720570491; x=1721175291; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=cYzCTDwEK2pMUJCfcFRfctFHDDdLzr2h8y801pHs+Og=; b=pYU7uDlGF42kmqmxePLJ7KcYZrWocrKQBpKkvKE5yMsp/xnRMMQpqH1NoZstTCCuHp aerABze6EXUy61xgv7KQYq950pvm8/BPdO9WrUOqmDgvBMby3uYBR1t+s992yxvfvZDy TR92qg/FHC6x+6fjP+BR/vm+TsViwi9/eohaNH/oWUy28KZcBXI5KfwNgkm1nH1uXgDF 53G0vtqZYBLOfYzzhj8IkAJKYAGSq8BWtETWQfrR9Gyu4UlHekOJtSH+M/0MpxKnJOr7 pmYNDyhDFTWQ/haogPyYAGYhRzZvGgadRytQGaU938pIjw3b+oZgawTtmeQ18JCQSH01 Yb7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720570491; x=1721175291; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cYzCTDwEK2pMUJCfcFRfctFHDDdLzr2h8y801pHs+Og=; b=Fb027yoElYm8OXzdFnZPWlJzQLCdIVwgFHwLyrxyzL/C0a32F4Vza+wtPASQnIapHd eI3AI5XqLYrIa/KWdrrpy9UsEVZZMakPq3u8+tOJ6WMUn6MZ8nYMybcjl0T4UdQUL6DF k7dQYbhkTE27j5/qpp17SQTNUPaN+neIyiQh8kH2GtfcCzo03cxHm2n6fIgWODHnzKBT k4O2jNS8O6j6YkgRu3FU98kY6CRiK1ZGFoHhPlL4L4vXzll0x7D7C4mU6HSDjXvlfvJP 9vMCaChnzWoD2NBdJVZF1eayfJtk8nCrxBS25233keBsA0r1R8eeCTcg21l5ZeufsZEC PwIw== X-Forwarded-Encrypted: i=1; AJvYcCUlAglWuVveuTeOErTshx6ysKqCwFohZRt97UdeUxWnvhtvC8VcnlJsl1VXPZf7+sjbYdFvqu4qgAmAEOd9G/BctLM= X-Gm-Message-State: AOJu0YyqdODknZEAi9BPpIibj9MxEoep++PUDiS+vv16F1ODTj82yzod tLcWI1F4Zo7YVmVzjnH46obgY+HTKRIDSGcqJDf2Zu9JFRD2rBUUA8AeyFz4UA== X-Google-Smtp-Source: AGHT+IEJDg6S4NBLs9dJMYf+hcqE1vXc4OPxZz7GmEdH8VNMxw4eh6jmPRHrPp2NqBak+KIDmEPJ2g== X-Received: by 2002:a05:690c:ed4:b0:64a:7040:2d8e with SMTP id 00721157ae682-658f02f56c2mr51883617b3.33.1720570490925; Tue, 09 Jul 2024 17:14:50 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 00721157ae682-658e69da2a7sm5413497b3.115.2024.07.09.17.14.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jul 2024 17:14:49 -0700 (PDT) Date: Tue, 9 Jul 2024 17:14:01 -0700 (PDT) From: Hugh Dickins To: Miaohe Lin cc: akpm@linux-foundation.org, muchun.song@linux.dev, hughd@google.com, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] mm/hugetlb: fix kernel NULL pointer dereference when migrating hugetlb folio In-Reply-To: <20240709120433.4136700-1-linmiaohe@huawei.com> Message-ID: References: <20240709120433.4136700-1-linmiaohe@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 18C5C40009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wq54c48bjaerzmng36yf3xuiqwwq1h1u X-HE-Tag: 1720570491-157066 X-HE-Meta: U2FsdGVkX1+IraOC31LeHVGYl69SPktOByi0MtMYSdxc9I1DgR6+D5f1uhOJt52nx8tSuVKHH5SO1FOr2m1sO8XKvcl8WAw21MBrcTcEqCXZCrNwH06YZ1tcCS1CmXXtohVTOE1PW6gIXVUX6yy4Ko2CvhZumSal6INKIsF5f73dTCm7/flr1b+rBEZfXkNYKTCwhjwRFcOr6cooH5pd7enBgm8tEtbolQGCt3U33eqj2RJoD6B2dB+C5OElbX4MdwyFb6NBya7ZLZpUi18zLoVT6wbJdyyybuapOlvUvNYP9t4d55u6ek9XCNKanW90PxXF+ybHhxhcG0riwGZbAKfmTBySJSBrVvRlPaehaYCoH5ol/jypB1FsyRdndLlV/Jr32QLYt4bfG4aEZ7K7xbiNrynTQoa5InHzKJb3VtfJViA0xkJt1qiLpHwPEGyi3l0e8OIVpSw3G4gOZUE02MrTj6Jxd1ATvbmvRt6Ml3iolDb4S845qxTOhDEPGzdP+8W4RdaANKiGcdDexJfRo2WnQvhpJ0W/m3dj/1wM/YCeil+YHeKypoWsYrSwhRkhELJDZIyodmnkEsL6kZdMTVnuX5BiMRRML//qdKH+3FfB/wF8FkDgS36moMz1LCNdXmwjCFSluGQxs0QY7Gfr73TAv0JShYBgrtN9x88WZURYML/iMbN6gkGjWJN0+AS8SKUImtMalF5nK42yR6HIua76fQdPs+9livab+v3u37GeX72aND2oaYc2f+I3dgFnzehHgirATa4Xrv5i0RUPD9fQeE8mLziucFisu6F54mgEhtD5H6yT+2gy++gq0DGTAn8FVHFNGXgRqoeNQRmh+k2SEBHQdhJDN8tsMBZ1X8qCReQerB/8Z1re6ok0BJMGgUQu0xhm4SZ+rp/3sZCQdMH3rnbpFFaRx+FQ1F/dlBzRilqJGlfg4JGEP2oKCuRyqJHNqVCeqwDF5jSI8dI r59I5A9y +TVk4WwJ8qNv26mL6eMYdoL6XIn/LrBWjNDM3M2VeKprDPVS17sz7fQaWhR5Sp5gmOv/hV1t3FKYzAqPtX/MSusrkrH3BNFSC5MhN4TVzOKfcw2/HZMuHWjgTZQf5fYySAAUBAqNV0/rdp5hKEVV25k8b3/PWblC/UQpBMX0Pct+dR6iSxlrC13WkO/HXjDRKVL5ZY7QIJNtukhux+Ey3Td+Fg3lfkmFXw9kr3+DVjB4w1nvPTGpR6YEDzK1qZ12813H1TkQ/ArcyTIEIKNzDrrk1DB0nyxUjZYXYaLg/6IwFILrQQ2J8kOQWglWTz/+pIVO43tP6xUITI8UAUyQOvijqtoyDRluVVCXfeEi3UaipUZBzvf81QAVEGpn6FYNmbCtbMN9pfcQxHb7v05yBQ67X7ZSmfmOel/QT 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: List-Subscribe: List-Unsubscribe: On Tue, 9 Jul 2024, Miaohe Lin wrote: > A kernel crash was observed when migrating hugetlb folio: > > BUG: kernel NULL pointer dereference, address: 0000000000000008 > PGD 0 P4D 0 > Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI > CPU: 0 PID: 3435 Comm: bash Not tainted 6.10.0-rc6-00450-g8578ca01f21f #66 > RIP: 0010:__folio_undo_large_rmappable+0x70/0xb0 > RSP: 0018:ffffb165c98a7b38 EFLAGS: 00000097 > RAX: fffffbbc44528090 RBX: 0000000000000000 RCX: 0000000000000000 > RDX: ffffa30e000a2800 RSI: 0000000000000246 RDI: ffffa3153ffffcc0 > RBP: fffffbbc44528000 R08: 0000000000002371 R09: ffffffffbe4e5868 > R10: 0000000000000001 R11: 0000000000000001 R12: ffffa3153ffffcc0 > R13: fffffbbc44468000 R14: 0000000000000001 R15: 0000000000000001 > FS: 00007f5b3a716740(0000) GS:ffffa3151fc00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000008 CR3: 000000010959a000 CR4: 00000000000006f0 > Call Trace: > > __folio_migrate_mapping+0x59e/0x950 > __migrate_folio.constprop.0+0x5f/0x120 > move_to_new_folio+0xfd/0x250 > migrate_pages+0x383/0xd70 > soft_offline_page+0x2ab/0x7f0 > soft_offline_page_store+0x52/0x90 > kernfs_fop_write_iter+0x12c/0x1d0 > vfs_write+0x380/0x540 > ksys_write+0x64/0xe0 > do_syscall_64+0xb9/0x1d0 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f5b3a514887 > RSP: 002b:00007ffe138fce68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 > RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f5b3a514887 > RDX: 000000000000000c RSI: 0000556ab809ee10 RDI: 0000000000000001 > RBP: 0000556ab809ee10 R08: 00007f5b3a5d1460 R09: 000000007fffffff > R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c > R13: 00007f5b3a61b780 R14: 00007f5b3a617600 R15: 00007f5b3a616a00 > > It's because hugetlb folio is passed to __folio_undo_large_rmappable() > unexpectedly. large_rmappable flag is imperceptibly set to hugetlb folio > since commit f6a8dd98a2ce ("hugetlb: convert alloc_buddy_hugetlb_folio to > use a folio"). Then commit be9581ea8c05 ("mm: fix crashes from deferred > split racing folio migration") makes folio_migrate_mapping() call > folio_undo_large_rmappable() triggering the bug. Fix this issue by > clearing large_rmappable flag for hugetlb folios. They don't need that > flag set anyway. Gosh, thanks a lot for catching this: it had not crossed my mind that a folio which passes (folio_test_large and) folio_test_large_rmappable might not be suitable for folio_undo_large_rmappable. > > Fixes: f6a8dd98a2ce ("hugetlb: convert alloc_buddy_hugetlb_folio to use a folio") That's in 6.10-rc, isn't it? > Fixes: be9581ea8c05 ("mm: fix crashes from deferred split racing folio migration") And that's in mm-hotfixes-stable intended for 6.10 final. > Signed-off-by: Miaohe Lin > Cc: So if all goes to plan, this shouldn't need the Cc stable. I certainly deserve blame for not thinking of this possibility: but how was it working before my commit, when the folio_undo_large_rmappable() was being called from mem_cgroup_migrate()? I think that was just as liable to crash too. I would like to hear definitively from Matthew, whether a hugetlb page should or should not be reported as large_rmappable - is your patch here just fixing a surprise, or in danger of adding another surprise somewhere? Hugh > --- > mm/hugetlb.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 6282dd9e37e3..45fd3bc75332 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2173,6 +2173,9 @@ static struct folio *alloc_buddy_hugetlb_folio(struct hstate *h, > nid = numa_mem_id(); > retry: > folio = __folio_alloc(gfp_mask, order, nid, nmask); > + /* Ensure hugetlb folio won't have large_rmappable flag set. */ > + if (folio) > + folio_clear_large_rmappable(folio); > > if (folio && !folio_ref_freeze(folio, 1)) { > folio_put(folio); > -- > 2.33.0