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 D789C404898 for ; Mon, 18 May 2026 12:33:59 +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=1779107639; cv=none; b=krVCQpk6brd7fVY35b2NujrTHj1Kfz18RZQtemcBnzn/7GCtS5G4kquxOaIyCnxTJxBf+GDjuOM7sywymcVtRMVG/+idtbjjGLISj/oUK++PDX2Uw5/WwGH4coeCa7+P6aeNTy1zFyRvaoxknYHoYvJ+oYDqg8vH6LONwanJghg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779107639; c=relaxed/simple; bh=Z2KjGLrAvcxjwZ42Qu5KBbhocNO31ciqZgzU5RIhitE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=V4bm5+7k6kUaojFR7zUyDaB6F0aJwXWR1lhiDmALgsClpX/KSWlT4FBQqCTQlagDWGPROZSsolWjX2iDTe62mniFpTbRiOGOJnK8KXP/mDVhIUKcL4trraJltw9tsp7WgBEpSFAfV2QdDbynGYWwgdQEg36NwAskjfC+S68xHZ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PNWQrve3; 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="PNWQrve3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98599C2BCB7; Mon, 18 May 2026 12:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779107639; bh=Z2KjGLrAvcxjwZ42Qu5KBbhocNO31ciqZgzU5RIhitE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PNWQrve3K49AXfEAdnKTFOMyKSwKpQfZ82CP6pKq61cA5x6A1THjTjga0ABb4EcF4 jPtgojh1aFk9UZIVNI/NLvGwqOdx4s9CGTgFp907P60wmSNUmudb0iRhgL0doGq62n 2sFBYM/7br250+TsyG8k7oR+piUkNg7qg+RGSoX4HhndxSQEltV3rsi3wqFH0ZWbJ8 +STmqBv55Be36ZGr6EfX6WnJqeEwMxBV4f8zSdhBfZqxJQpyfeumqyzxnBoxmVaN3k nFJUIy7RNLqKHgBzOlWsIDB1aOD+AQzw5ysy7lAefgQTrKMhs1hfjFeWef6ZkEhH/t 49UyolwJlnCVg== Date: Mon, 18 May 2026 13:33:54 +0100 From: Lorenzo Stoakes To: Thorsten Blum Cc: Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Yury Norov , Rasmus Villemoes , Andy Shevchenko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h Message-ID: References: <20260517123428.1181981-4-thorsten.blum@linux.dev> 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-Disposition: inline In-Reply-To: On Mon, May 18, 2026 at 02:13:54PM +0200, Thorsten Blum wrote: > Hi Lorenzo, > > On Mon, May 18, 2026 at 11:02:10AM +0100, Lorenzo Stoakes wrote: > > Seriously, please resend this. > > > > This is 3 patches with 2 in-reply-to 1/3, that's not how we do series in mm, > > take a look around :) > > > > Write a cover letter, and have all the patches in-reply-to that. > > A cover letter seemed unnecessary for such a seemingly trivial 3-patch > series, but this thread [1] might have been helpful for context. OK, but this is how we do multi-patch series in mm, as I said. It's always a good idea to look around a subsystem to get a sense of how things are done as a courtesy. So politely request you do this :) though as I said I question this being broken out into as many patches as it is. > > [1] https://lore.kernel.org/lkml/CAHp75VfQNkqEYsO4Uup0c-uiYuVyAWit=tmCz2BsYLp-sjXsZw@mail.gmail.com/ > > > Was there not previous versions of this? I _seem_ to remember that, but might be > > misremembering :) > > I only know about the one Yury mentioned. This is v1 of my series. > > > Also I'm really questioning the value of this, you've not sold why we should > > take this whatsoever. > > > > 'Add a random new header file we have to maintain because it's smaller' is not > > really hugely compelling. > > > > Also a _lot_ of stuff in the kernel ultimately pulls in mm.h. So what exactly > > has the specific requirement of both needing this define and (somehow) doesn't > > use mm? > > Patch 3/3 is one of many examples that pulls in all of mm.h just for > offset_in_page(). lib/string.c from the same thread [1] is another > example that would need to include mm.h just for offset_in_page(). And that's a problem why? Compile time? Somehow binary bloat? Conflicts? Confusion? > > Many other files (hundreds) don't use offset_in_page(), but open-code it > in many different ways instead: > > (unsigned long)p & ~PAGE_MASK > (unsigned long)p & (PAGE_SIZE - 1) > (long)p & (PAGE_SIZE - 1) > ... > > I can't tell whether they didn't know about offset_in_page(), or > deliberately chose not to include mm.h. OK but this series doesn't address any of that? It just adds a new header, a questionable macro and uses it in one place? So those justifications are rather moot here. > > Thanks, > Thorsten Cheers, Lorenzo