From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 179EF1D6DB8 for ; Fri, 24 Jan 2025 06:20:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737699604; cv=none; b=pLRkD6YucQ/gowykC1AeiiT9KcC2TWxhzjc/017EBL9pq8/L+EbvOedIYgWLfji435srvSSA+Hnq0l+J8bQA4d6nGVJr5f5BgHJ2TJlGdaqNvWpnHCs/LT0BvOVDOuGXuG/bjMDngSyaqddcCCCaS09nwSmN8Quv1PkORb1Ygf0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737699604; c=relaxed/simple; bh=kX5nzk24H8vhTxZtLP2fc/Z5oTaG7kCuiTNecNt9uXw=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=Jm7xHYAeQEqSzTtq7shIk3mbnZzNaM0uYcylHSgucaXquIWG+6uKoOhbqMizanLih+acirlCNNlvTzHa3OyKXN1aILY2sLk6zrFqQg7IbQwc6mgjNbLXJH4wNxEqacdjzlz/064PycxhSKOi6i+jFC9KoMynjsiBGyU7e0HYOVk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=sKClBrQE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="sKClBrQE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F496C4CEE0; Fri, 24 Jan 2025 06:20:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1737699603; bh=kX5nzk24H8vhTxZtLP2fc/Z5oTaG7kCuiTNecNt9uXw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sKClBrQEzJ/OA2xTdjynW/UjFSDNA7lsFEc5l93mAxXVoGNGmh+Njdz0DGtlh8/aF 028kJ9lMh4Q5QiyeypwewkBAbCUSpMkVK/ZI+ybIc0UBHEHAUscN7okMR+5agJ8Dkj uxkVRQauwirEGfgJSnXQw2S7LJ9veawWm02t9o1M= Date: Thu, 23 Jan 2025 22:20:02 -0800 From: Andrew Morton To: Liu Shixin Cc: Kefeng Wang , Kemeng Shi , Baolin Wang , Mel Gorman , David Hildenbrand , Matthew Wilcox , Nanyong Sun , , Subject: Re: [PATCH] mm/compaction: fix UBSAN shift-out-of-bounds warning Message-Id: <20250123222002.8897374343971b0b8e877307@linux-foundation.org> In-Reply-To: <20250123021029.2826736-1-liushixin2@huawei.com> References: <20250123021029.2826736-1-liushixin2@huawei.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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. > 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.