[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <72ddde27-e2e2-4a46-a2ab-4d20a7a9424f@app.fastmail.com>
Date: Wed, 03 Jul 2024 20:34:38 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Naresh Kamboju" <naresh.kamboju@...aro.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc: stable@...r.kernel.org, patches@...ts.linux.dev,
linux-kernel@...r.kernel.org,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Guenter Roeck" <linux@...ck-us.net>, shuah <shuah@...nel.org>,
patches@...nelci.org, lkft-triage@...ts.linaro.org,
"Pavel Machek" <pavel@...x.de>, "Jon Hunter" <jonathanh@...dia.com>,
"Florian Fainelli" <f.fainelli@...il.com>,
"Sudip Mukherjee" <sudipm.mukherjee@...il.com>, srw@...dewatkins.net,
rwarsow@....de, "Conor Dooley" <conor@...nel.org>,
Allen <allen.lkml@...il.com>, "Mark Brown" <broonie@...nel.org>,
"Dan Carpenter" <dan.carpenter@...aro.org>,
"Anders Roxell" <anders.roxell@...aro.org>,
"Linux-sh list" <linux-sh@...r.kernel.org>, "Rich Felker" <dalias@...c.org>,
"John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>
Subject: Re: [PATCH 5.4 000/189] 5.4.279-rc1 review
On Wed, Jul 3, 2024, at 19:45, Naresh Kamboju wrote:
> On Wed, 3 Jul 2024 at 16:20, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> arch/sh/kernel/sys_sh32.c:68:1: error: macro "__MAP3" requires 4
> arguments, but only 2 given
> 68 | SC_ARG64(nbytes), unsigned int, flags)
> | ^
> In file included from arch/sh/kernel/sys_sh32.c:11:
> include/linux/syscalls.h:110: note: macro "__MAP3" defined here
> 110 | #define __MAP3(m,t,a,...) m(t,a), __MAP2(m,__VA_ARGS__)
> |
This is caused by the backport of my patch 30766f1105d6
("sh: rework sync_file_range ABI"), which uses the
SC_ARG64() that in turn was introduced in linux-5.12 commit
2ca408d9c749 ("fanotify: Fix sys_fanotify_mark() on native
x86-32").
We can't backport the entire fanotify patch to stable
kernels, but it would be fairly easy to just extract
the two macros from it, or to open-code them in the
backport of my patch.
For the moment, I'd suggest dropping my 30766f1105d6
patch from 5.10 and earlier LTS kernels to avoid the
build regression.
Rich and Adrian, let me know if you would submit a
tested backport stable@...r.kernel.org yourself, if you
want help backporting my patch, or if we should just
leave the existing state in the LTS kernels.
Arnd
Powered by blists - more mailing lists