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 B9E152F0673; Tue, 12 Aug 2025 20:13:29 +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=1755029609; cv=none; b=f+t5OakJvHg2tdZdYK1Cb5Q33bj15u3NXbgdA2soajct3WCtpMlDYwMxX8Mz31g3gEYEMXpla4dPU14/wPPGHxIp7Bq+Da7SN6yalTKc4SSFG3DtfmYw3wnQqximghMPGlaQft2lPFBR3zT/XpboyPwLhw1+G98b851rs15WciY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755029609; c=relaxed/simple; bh=67thnts7t0DLgkZq/Ii6wBw0jrSFJtM5mUMWCYrbVS8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=gpmu5EpKg06/gjEnOBvYRUSECSS0AJpSo/Jg3E7SPM8lTzATPALntaAnVPGdHWcgOzWNPc20gGgrlIszCa4t6mbqeg6AKSECBHM8/1zTkWeQfXOyivUjt+GsgkdQAZFYi9G019HsjrBqFBLJOhvpehSAn9VhdAx9tf/AMsODE3M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gZk5s4qd; 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="gZk5s4qd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AD26C4CEF0; Tue, 12 Aug 2025 20:13:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755029609; bh=67thnts7t0DLgkZq/Ii6wBw0jrSFJtM5mUMWCYrbVS8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gZk5s4qdbM6pcT8YroWmQOKRLwIIFGieYYi0v9aoNi2ICJDuc3wg8bhKf+s6pvQNd c+i3MR/y/FAagcjMfROfPVLTOsoG3YlP79F/PpCEZGyFDsyuBtQtypuh96jit6toX0 v+aQUOZ71f1sVS4LLJKLKq+8hdeGPjE2mpVgs/FuY2KZSzhX/6T7dzeh6CvpLmMDoF weuTiAVwv1mVOxNZA1KKoDpEA1hk0wwazemaioBJiDYkvkx74pTiTr9+YupNxQLK8F rz5RHVzbW4bBYKxh5nyMODvXXmIYvJS3DB65gwqyMSJvM3wUZw/6uqpQTB/gIvOiXG Gs3FPiwr7oo7A== From: SeongJae Park To: Lorenzo Stoakes Cc: SeongJae Park , Andrew Morton , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , "David S . Miller" , Andreas Larsson , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Alexander Viro , Christian Brauner , Jan Kara , Kees Cook , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Xu Xin , Chengming Zhou , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , David Rientjes , Shakeel Butt , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Kan Liang , Masami Hiramatsu , Oleg Nesterov , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Jason Gunthorpe , John Hubbard , Peter Xu , Jann Horn , Pedro Falcato , Matthew Wilcox , Mateusz Guzik , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: Re: [PATCH 00/10] mm: make mm->flags a bitmap and 64-bit on all arches Date: Tue, 12 Aug 2025 13:13:26 -0700 Message-Id: <20250812201326.60843-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 12 Aug 2025 16:44:09 +0100 Lorenzo Stoakes wrote: > We are currently in the bizarre situation where we are constrained on the > number of flags we can set in an mm_struct based on whether this is a > 32-bit or 64-bit kernel. > > This is because mm->flags is an unsigned long field, which is 32-bits on a > 32-bit system and 64-bits on a 64-bit system. > > In order to keep things functional across both architectures, we do not > permit mm flag bits to be set above flag 31 (i.e. the 32nd bit). > > This is a silly situation, especially given how profligate we are in > storing metadata in mm_struct, so let's convert mm->flags into a bitmap and > allow ourselves as many bits as we like. I like this conversion. [...] > > In order to execute this change, we introduce a new opaque type - > mm_flags_t - which wraps a bitmap. I have no strong opinion here, but I think coding-style.rst[1] has one? To quote, Please don't use things like ``vps_t``. It's a **mistake** to use typedef for structures and pointers. checkpatch.pl also complains similarly. Again, I have no strong opinion, but I think adding a clarification about why we use typedef despite of the documented recommendation here might be nice? [...] > For mm->flags initialisation on fork, we adjust the logic to ensure all > bits are cleared correctly, and then adjust the existing intialisation Nit. s/intialisation/initialisation/ ? [...] [1] https://docs.kernel.org/process/coding-style.html#typedefs Thanks, SJ