[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86ms3yl6bb.fsf@kernel.org>
Date: Thu, 04 Dec 2025 14:34:00 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Mike Rapoport <rppt@...nel.org>, Arnd Bergmann <arnd@...nel.org>, Hugh
Dickins <hughd@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>,
Pratyush Yadav <pratyush@...nel.org>, Pasha Tatashin
<pasha.tatashin@...een.com>, Arnd Bergmann <arnd@...db.de>, Baolin Wang
<baolin.wang@...ux.alibaba.com>, Kairui Song <kasong@...cent.com>,
Christian Brauner <brauner@...nel.org>, Lorenzo Stoakes
<lorenzo.stoakes@...cle.com>, Kemeng Shi <shikemeng@...weicloud.com>,
Guo Weikang <guoweikang.kernel@...il.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [v2] mm: shmem: avoid build warning for CONFIG_SHMEM=n
On Thu, Dec 04 2025, David Hildenbrand (Red Hat) wrote:
> On 12/4/25 11:55, Mike Rapoport wrote:
>> On Thu, Dec 04, 2025 at 11:34:24AM +0100, David Hildenbrand (Red Hat) wrote:
>>> On 12/4/25 11:28, Arnd Bergmann wrote:
>>>> From: Arnd Bergmann <arnd@...db.de>
>>>>
>>>> The newly added 'flags' variable is unused and causes a warning if
>>>> CONFIG_SHMEM is disabled, since the shmem_acct_size() macro it is passed
>>>> into does nothing:
>>>>
>>>> mm/shmem.c: In function '__shmem_file_setup':
>>>> mm/shmem.c:5816:23: error: unused variable 'flags' [-Werror=unused-variable]
>>>> 5816 | unsigned long flags = (vm_flags & VM_NORESERVE) ? SHMEM_F_NORESERVE : 0;
>>>> | ^~~~~
>>>>
>>>> Replace the two macros with equivalent inline functions tto get the
>>>> argument checking.
>>>>
>>>> Fixes: 6ff1610ced56 ("mm: shmem: use SHMEM_F_* flags instead of VM_* flags")
>>>
>>> That's still not upstream, right?
>>>
>>> $ git tag --contains 6ff1610ced56
>>> mm-everything-2025-11-29-19-43
>>> mm-everything-2025-12-03-23-49
>>> next-20251201
>>> next-20251203
>>> next-20251204
>>>
>>> So we can likely just squash it into the problematic commit before
>>> proceeding with it?
>> It's mm-nonmm-stable, I don't think fixups can go there.
>
> Ah, I only looked at mm-stable and mm-unstable.
>
> Confused why this is in nomm-stable and not mm-stable.
The patch came in with the liveupdate series [0], most of which counts
as nonmm I suppose.
[0] https://lore.kernel.org/all/20251125165850.3389713-1-pasha.tatashin@soleen.com/
[...]
--
Regards,
Pratyush Yadav
Powered by blists - more mailing lists