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 E8595C0218C for ; Sun, 26 Jan 2025 02:06:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20F382800E3; Sat, 25 Jan 2025 21:06:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BE4C2800DA; Sat, 25 Jan 2025 21:06:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 086422800E3; Sat, 25 Jan 2025 21:06:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DEBD92800DA for ; Sat, 25 Jan 2025 21:06:22 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6060AB1E99 for ; Sun, 26 Jan 2025 02:06:22 +0000 (UTC) X-FDA: 83047963404.19.BC8EDE7 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf02.hostedemail.com (Postfix) with ESMTP id D1B7680007 for ; Sun, 26 Jan 2025 02:06:19 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf02.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737857180; a=rsa-sha256; cv=none; b=AeFuCxjpkI49Sqk5MuqXsP19M6dbXvaLOmkcOk53RBEMsWwGyFew24BmJTZqVTDnJ0IgZl d6RC93hSfJSUbHQR4t9pxEsWLG6fs9E+++j6NM5kftvP6Wj3d7VDB9PdHrda3DR6atB6Q+ x36RLnEJ/Xih1lpd9q9Loh+/2tdGvSY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf02.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737857180; 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; bh=aB9K3TbwnGjgB4SeNsHmgIAiYNQxH5vHQbaMsmxAJCY=; b=KQTS7RRbGZKwWjmJYlqy1kKSm+W5KHCeJ4z1EKNEr26ux4wg66FByDX07BtS/6/U226tBz HbidtRHcrdkOEVw1MxZ/A/Z6yumnTEyekudFycl/kwNmc6LOyWMAH4r4W29RZErsLJWlin L8vxK9tBjnXjDJoIwYC80fVd5gEL/v0= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4YgZb15gwzzRlyS; Sun, 26 Jan 2025 10:03:25 +0800 (CST) Received: from kwepemg200013.china.huawei.com (unknown [7.202.181.64]) by mail.maildlp.com (Postfix) with ESMTPS id 1CF7A180087; Sun, 26 Jan 2025 10:06:00 +0800 (CST) Received: from [10.174.179.24] (10.174.179.24) by kwepemg200013.china.huawei.com (7.202.181.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sun, 26 Jan 2025 10:05:59 +0800 Subject: Re: [PATCH] mm/compaction: fix UBSAN shift-out-of-bounds warning To: Andrew Morton , David Hildenbrand References: <20250123021029.2826736-1-liushixin2@huawei.com> <20250123222002.8897374343971b0b8e877307@linux-foundation.org> CC: Kefeng Wang , Kemeng Shi , Baolin Wang , Mel Gorman , Matthew Wilcox , Nanyong Sun , , From: Liu Shixin Message-ID: <8f2238e4-5c2a-8185-9d36-8722bf638b87@huawei.com> Date: Sun, 26 Jan 2025 10:05:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20250123222002.8897374343971b0b8e877307@linux-foundation.org> Content-Type: multipart/alternative; boundary="------------F9C2BAB4A87949D04B3774FA" X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemg200013.china.huawei.com (7.202.181.64) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D1B7680007 X-Stat-Signature: xm85pz8yuoe4mosfgw11z6o7deiwz9id X-Rspam-User: X-HE-Tag: 1737857179-623958 X-HE-Meta: U2FsdGVkX18rfrBUIFJOgZBeIyHudvyAfLNblmvTw1T5pX8foAEc5ht3v05X+DYiuDpgL/THn2UyTzgx4zLKkB5UsvngUb/Yquj27wOzoZfqsJLhsIbrr2vN2alEDz+sSD+zLOE6YmkSsvMVlvnHEI4bHCebeJ6Mc68wOn2mroEBamg4Trr2xnbAiR/+vVzxO2RPJNV7qe0E8a4N42jIW7RAi5Iq9egCAZeT7zPqadFS5mZc9VgB1bTneHtg1QaFcVrCb2RJu1h47WfCi7+VjCext+0SRq25gEw/WUTSwXsqD9oea62wVgLpwf3G7AnaIJIHZ1z17Jwv46VqgMCAg1dtUji//AJZAJ4Evz2rmE5Fky6pRl9/dT5WZ8mnpVkbwf+itPCFTFRfLoae+mftpLRKoKGcyfZ0kHSQUhOCrJUN0rJ2RJd3Yd87gQ4Z/6WuAcRz40vuW5A8b6+PqFp/UsAoq8a18ILhYt/hvjOBUc0hckASdU0GXgNiwWNgA9Q/zO9BG0ZSGAZ4IPXdnauzE38vw+boIRwazzWF3yIdDoUqyCbfY4geRoh4Yn5yYQKaRQpcTB+QNxjU5ET8lBZefa49j+K6SK4lfkSbfQ+jnLr16VN2XaqzDb0IJ/bUMYZ112oU2wVzLri8I2QXGjZ+WF66KybzFCMTSGFD5dBIvuOkJEVHmLbPPTmQNrF5BvH6e0D3qoeF18gsbWS5ig2TruPrcdhbqLl8l2IY9HerCDjZi1Lp/FlBnsGFzbqE4YvuxX4r/Bsn0vRyjiIakttkYAybfQaOmqpsCuXGyuN1D7VVv1f1hKGMX32Mvyiq3ef7O1PKyK86TqR6n7RPZu1DQpT6Q5l8X/y1UMFhXYlbN+59Q/9I4PXjmyQOaKXOuXpiw7kWBaBC0oO8SjG0kc21Y8I8gB30CjjaYvyDTL5rikWfgpwSkgdEHN4hNTdhJClqY5vu//DLCiFhheXbwJZ 7yKv5b1H sYMB4+cXXVllO3wUy/IHK8hmNgu+w/jU/xpAGPGZ81WiWuFwg7FfBajQfE4i8WysoDuxn7lLG2FzKjp7poaPzrAy0P7w7fJ9v1t4ftvloCxK4j4ql2Q4cSM3pyQBZ5+NuNhAGbyM8Cy022RyxCh3XIq8AO8+7bmGvylWimTEjOPiZEvul8cEAf/LmnVg/FYQjpwVQpHJo0n5UUOgI39yVtHbTP7K2VbSfNrVW27+uD9uHiuy26Ggh0zJ6XNU53RHcM7GtbvLKBscpX9dCo7ffSrPBj6DY/ISlw/2hzkonUn6eNCLjuelUdx9j1y39qczy2uCn2y/UOIs0ENlsaaoiqhXcRShwdgHT30ar X-Bogosity: Ham, tests=bogofilter, spamicity=0.000026, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --------------F9C2BAB4A87949D04B3774FA Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit On 2025/1/24 14:20, Andrew Morton wrote: > On Thu, 23 Jan 2025 10:10:29 +0800 Liu Shixin wrote: > >> syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order) > A Link: to the syzcaller report would be great, please. The warning arises only once in another version instead of mainline, and the syzkaller log not reproduce. In that version, compound_orderis still union with lru instead of flags, so I didn't put it in the log. See enum pageflags, we can know that the warning need folio setting PG_waiters flags, which is low probability. > >> in isolate_freepages_block(). The bogus compound_order can be any value >> because it is union with flags. Add back the MAX_PAGE_ORDER check to fix >> the warning. > OK, I'd never noticed compound_order()'s restrictions before. It looks > like a crazy thing - what use is it if it can return "wild return > values"? > > Can someone please explain what's going on here and suggest what we can > do about it? > > For example, should we have a compound_order_not_wild() which is called > with refcounted pages and which cannot return "wild" numbers? Or > something else. > >> --- a/mm/compaction.c >> +++ b/mm/compaction.c >> @@ -630,7 +630,8 @@ static unsigned long isolate_freepages_block(struct compact_control *cc, >> if (PageCompound(page)) { >> const unsigned int order = compound_order(page); >> >> - if (blockpfn + (1UL << order) <= end_pfn) { >> + if ((order <= MAX_PAGE_ORDER) && >> + (blockpfn + (1UL << order) <= end_pfn)) { >> blockpfn += (1UL << order) - 1; >> page += (1UL << order) - 1; >> nr_scanned += (1UL << order) - 1; > isolate_migratepages_block()'s > > if (skip_isolation_on_order(order, cc->order)) { > > doesn't check for "wild" values, but it seems that > skip_isolation_on_order() will handle it. > . > --------------F9C2BAB4A87949D04B3774FA Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit



On 2025/1/24 14:20, Andrew Morton wrote:
On Thu, 23 Jan 2025 10:10:29 +0800 Liu Shixin <liushixin2@huawei.com> wrote:


syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order)

A Link: to the syzcaller report would be great, please.
The warning arises only once in another version instead of mainline, and the syzkaller log
not reproduce. In that version, compound_order is still union with lru instead of flags,
so I didn't put it in the log.
See enum pageflags, we can know that the warning need folio setting PG_waiters flags,
which is low probability. 


in isolate_freepages_block(). The bogus compound_order can be any value
because it is union with flags. Add back the MAX_PAGE_ORDER check to fix
the warning.

OK, I'd never noticed compound_order()'s restrictions before.  It looks
like a crazy thing - what use is it if it can return "wild return
values"?

Can someone please explain what's going on here and suggest what we can
do about it?

For example, should we have a compound_order_not_wild() which is called
with refcounted pages and which cannot return "wild" numbers?  Or
something else.


--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -630,7 +630,8 @@ static unsigned long isolate_freepages_block(struct compact_control *cc,
 		if (PageCompound(page)) {
 			const unsigned int order = compound_order(page);
 
-			if (blockpfn + (1UL << order) <= end_pfn) {
+			if ((order <= MAX_PAGE_ORDER) &&
+			    (blockpfn + (1UL << order) <= end_pfn)) {
 				blockpfn += (1UL << order) - 1;
 				page += (1UL << order) - 1;
 				nr_scanned += (1UL << order) - 1;

isolate_migratepages_block()'s

		if (skip_isolation_on_order(order, cc->order)) {

doesn't check for "wild" values, but it seems that
skip_isolation_on_order() will handle it.
.

--------------F9C2BAB4A87949D04B3774FA--