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 8DCDC39DBF8 for ; Thu, 19 Mar 2026 19:58:40 +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=1773950320; cv=none; b=kzRHGPegNOE0iOim8idZ65naZwPTGz1PWIdM4q5fTus/TCeRfNXgx1zq2YAcwhdVduzMUVXQmngrBSJF0VEwBu8WhUzqu/I4viKHn9Ekbn3HNF26f/dUlOP2ouRVZEmqbsTSc1kTviAT1EWBC5XbJp2EGYwaroC/ugm5Nc4Rp+s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773950320; c=relaxed/simple; bh=T6BKD1tqEyuEpYK55Snf7V7YPTv2oSGQpGwo9UT6bpA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XnGb5thA1lZY+L6JAh+JDIcyK+3E2Ekp/a/fxeH/yYb7kHNKzIdZTqFEkTPH4xACqvc5mKSJ4aBLfWprurNKVc7MUrHhjoCKUoBvA5bOXNvdi3L2Uiv4TQzFK3ON/F6x5eERdZo3vv0bzjueKLebHQKk9lNKmNa7blCDHwsDlF0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m8IjRoXA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m8IjRoXA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00986C19424; Thu, 19 Mar 2026 19:58:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773950320; bh=T6BKD1tqEyuEpYK55Snf7V7YPTv2oSGQpGwo9UT6bpA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=m8IjRoXAb3Zn/Q67ROj1HfcvutqDAL5M5RN5U9jIQ+MDQtwlLUhEPBHAM0gg0+vj9 bRhMmk2R0w2Ss7XmKPV75OZiSRABwamNdgK+i03w9BnRUcRL3LCL1GmYUC8HUaPbBx 714XFx4wuYbiYxYvymJiZ/pvn7ebpp77eClZHB4OTicuQh5dnxYWf7MM3aw4ABy+8+ 4jqy5YMbhMooeiEtIzOtsjS5NFA0qeEHUfuYJSBl2KV54Nqc64SzKPBwRx/PWyIYQr 0PgZMICX0rP0hpEsD3wqrCOGaxgXneNtmubvl0+jiBUZUGTnmhTPT7ULd+qB9BhQMw UlXfQKFEJVS9w== Message-ID: <6ff14b27-a494-4faa-94ed-ebbf63116125@kernel.org> Date: Thu, 19 Mar 2026 20:58:34 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long Content-Language: en-US To: Brendan Jackman Cc: Andrew Morton , Michal Hocko , David Rientjes , Shakeel Butt , Suren Baghdasaryan , Johannes Weiner , Zi Yan , Harry Yoo , Hao Li , Christoph Lameter , Roman Gushchin , Uladzislau Rezki , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds References: <20260319-gfp64-v1-0-2c73b8d42b7f@google.com> <215517e5-a49b-4eb7-824c-8c42e4db046e@kernel.org> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/19/26 18:38, Brendan Jackman wrote: > On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) wrote: >> >> On 3/19/26 17:03, Brendan Jackman wrote: >> > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is >> > probably not needed for 32-bit. This offers a way out of the GFP flag >> > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit >> > machines, while leaving it 32-bit on 32-bit machines. >> >> Thanks for tackling this! But now I'm wondering, if we decide to change it, >> would it be worth trying to add some type safety too? To help with cases >> like the recent kmalloc_objs() footgun discussed in this comment thread >> https://lwn.net/Articles/1063356/ > > Do you mean something similar to pgprot_t? Yeah, at least I don't know a better way. > I did that in [0] but I'm rather sheepish about it, I only went for it Right. > because I think it's especially needed for the specific "type" due to > the migration path creating a high type-unsafety risk. And that was > totally local to a few files in mm/. > > Are there common issues with gfp_t in particular besides the > kmalloc_objs() thing? If so then maybe it could make sense. It's not a > problem I've ever run into myself though. I think it's a hazard in any case where there are multiple arguments to a function where one is gfp flags and other some integer, and somebody gets the order wrong. But I just verified that at least in the kmalloc_objs() mistake, sparse will flag it, thanks to the __bitwise annotation. Would be better if compiler did, but it makes the case for changing gfp_t smaller if it was too disruptive (it likely would be). > [0] https://lore.kernel.org/all/20260225-page_alloc-unmapped-v1-8-e8808a03cd66@google.com/