linux-kernel - Re: [PATCH] [v2] mm: shmem: avoid build warning for CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93782526-c198-4590-b96b-c4f630b8ecbb@kernel.org>
Date: Thu, 4 Dec 2025 11:34:24 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>, Hugh Dickins <hughd@...gle.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Pratyush Yadav <pratyush@...nel.org>,
 "Mike Rapoport (Microsoft)" <rppt@...nel.org>,
 Pasha Tatashin <pasha.tatashin@...een.com>
Cc: 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 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?


Thanks Arnd!

-- 
Cheers

David