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 70244C02181 for ; Fri, 24 Jan 2025 16:28:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 01E0E28007B; Fri, 24 Jan 2025 11:28:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F1064280079; Fri, 24 Jan 2025 11:28:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDD0528007B; Fri, 24 Jan 2025 11:28:35 -0500 (EST) 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 C13FF280079 for ; Fri, 24 Jan 2025 11:28:35 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 724931A15FB for ; Fri, 24 Jan 2025 16:28:35 +0000 (UTC) X-FDA: 83042878590.18.A923B10 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 9B3A618000B for ; Fri, 24 Jan 2025 16:28:31 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oNEtmoRu; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737736113; 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=Irbw1bGTK9gYgpshyOyAQdC0GwwG9zFKQ+fCPPFgO+Y=; b=uoFgI47E4deXrzBo1/d+3q3onlqj6ART4GBumGm+MT/v1JTktoJvoe/X2Ai4BPss+I9GC8 BJTH/FPB6abGL5xuMC68SwD+9VMod8x6SpIzLkN5a/PDAeDxwva3c91oATprIBBR+Zj5cJ PgMVWj/dr8eGCs/LvpOBqEQSsXix/4E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737736114; a=rsa-sha256; cv=none; b=XiUlGLuiESMCrRx1hyzV9C9BLyTNtLxBssO131IQUxVmwK+f2gp3R74mWE9QRa5Rves+b/ UN24IsCPzU7IdZDeIkagIAl0J2UWBG/6llw0AUx70mobcMQ3Jqe5j5NKp/5r+L8Qi351Ga MjEcmVHikIYO/YWwC+VPApn/its8WRY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oNEtmoRu; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Irbw1bGTK9gYgpshyOyAQdC0GwwG9zFKQ+fCPPFgO+Y=; b=oNEtmoRulpKzxP9axT7jkgDXDe Pte02DiB3LLnzFujy4qy8z0ivQEFNO8djkZCl/m6s5qUmTlapagKLHqX5Ohl6/vlrAIkwYSEeOHHp umyTJxuFDMyJvslktxkwxlXNx1XH/Ea8l6nX/I6ZB0FFlbUEowjlYU3lbzAipot6fJz9geX+y7glZ BX5x8B07FS7vYh0iqqCmjFTlIcCoq/zA4LoC7ARBjy0+Kd2KVjZJorKlaL+Bb32Oh9GzPhbtKQuL0 1rvajr2yYK5QIjLh8eGtmLPqAUS3eQMR3h1C82M6J0pG1SeQ6V9C3jWw6fOtfEUMxFkHZwveeaBx0 q5drOqRw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tbMXd-0000000Gqrz-1XhV; Fri, 24 Jan 2025 16:28:21 +0000 Date: Fri, 24 Jan 2025 16:28:21 +0000 From: Matthew Wilcox To: Alexei Starovoitov Cc: Vlastimil Babka , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , Shakeel Butt , Michal Hocko , Thomas Gleixner , Jann Horn , Tejun Heo , linux-mm , Kernel Team , Marco Elver , Andrey Konovalov , Oscar Salvador Subject: Re: [PATCH bpf-next v6 0/6] bpf, mm: Introduce try_alloc_pages() Message-ID: References: <20250124035655.78899-1-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: f7phce976f7g9bn9wdg1bxzrprwjedmu X-Rspam-User: X-Rspamd-Queue-Id: 9B3A618000B X-Rspamd-Server: rspam03 X-HE-Tag: 1737736111-215996 X-HE-Meta: U2FsdGVkX196dAlaQEbP4r50jEVuBtFHeZTdVZ+v99sfon1NhwAivTR+wAdDjmu2Am5nswqjj/tdW/Yuu1odMcIMxiMes4OjGw7rdcExtGCBtISmeR9zmXzcmyRLdzFtmR/21jYBxMqioiEulACqyIxuP8ppFTPkyP6qkp6NYfNJCLNqIIXX0LcRoScF8ptaNElmpb/YpA+he6HaGa1etOfOYgsWAM8sWDIjoYwcD90JucT+yxypBFJBrr+3i/d4x0fgefMx+4lIpRAehuCf40tQtfokgrv05DQodGYciaCnnqpwMingEEP0/XQQyjF0Ab0j8L8ep4VRYhOWqGYPi0QLlIn35Tk0gmtCvUzx4jmJvGQvW744KFMyu5iOxhPGZFUsdN7RCoL4e/+V45WL9GbNKsn+20Uf3KJU4VpG5w5xj0n7mlpALOPsB2KHYSEZ3Vd4IcxZJKyqUdKKHIIX+d68PF1xWVnVyS5XbWmcnI1pI1dMOLvgatjo6XGV5rj4Uih7Wehdx4EUrQkUQgvCKg4v7qrgN+9wa4jl+rLDVexA0yY85FDB3A6m502GvatOo3di57nhWpyZW/T64RMe/H+wGpt/vI22CASGI1torx9PdPsfJ24orSse0MyoPdY6lnDrN/vMExsFtWhAClEB83wZ/hi9cuW/bbxJy5yBHbsnm41bZs1uxgNcNbder83zr5LFTnMthjqkVF1/octWxZnMetERCVhaPgzsvwI0T2w8E9InRd0Iuh2DSBS+eULtDwosxSzD5Yw4KmUzHF/FpxGqzIFPFw3N1rl7F0XxhQ6SbP5ng1bC8qwl+to0OLkUdOeoQZ9VRmBc3HWBvTbjYuc/C6MzH1uG7n4wmgzzVZeCFJXTD54aV2x6F9RxzKD9KSphQWEemGJ0CASbM+PoFsqHx2P/Iv7RnRrhhlQOkkpkH1Nl3isdwlPwlBZc3xqF8s2c5gJgKIKJtg789pl mZB9jiJS wsoAgezToNTxI21g73S1+US6uOWeOHSkw74HwZYY+PPxuHbYaWScOHFxXjZIDwoEdXo0B6oBXdpJZo4/akgNY5sc8JmJg5yaFFwM765KPTrSa8oAdOSqOaaLR3rvEogClz2JWx3tVuAqQ3usfdAksj0TW8GzmUWviS+g3rIgB+hTGSzgFMT0zp6tk6haXzrT6BgDZTTYYjM9tnr9tok/ES/WWS9dZ2dIO/DBpONNYGXCMU250paz126W6axougf33f0viOWHWx5NYRXBjNBDp/swjg49oDpQGjrPhqPWAFpgOMXt3Li9mubY02pumK8Uk7jMmtk9H5A5Q1QATRj8+Mn9KKZhY6Vui8u5f 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 Fri, Jan 24, 2025 at 08:19:19AM -0800, Alexei Starovoitov wrote: > I spotted this line: > VM_BUG_ON_PAGE(compound && compound_order(page) != order, page); > that line alone was a good enough reason to use __GFP_COMP, > but since it's debug only I could only guess where the future lies. > > Should it be something like: > > if (WARN_ON(compound && compound_order(page) != order)) > order = compound_order(page); > > since proceeding with the wrong order is certain to crash. > ? It's hard to say. We've got a discrepancy between "order at free call site" and "order recorded in page". We might, for example, have a memory corruption which has overwritten the compound_order() stored in the struct page, in which case the 'order' passed in is the correct one, and "correcting" it to the corrupt one stored in struct page would be the thing which caused the crash. I'd leave it as VM_BUG_ON().