[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <MWHPR2201MB1277D4B4E3CE45B3AC1870F3C1440@MWHPR2201MB1277.namprd22.prod.outlook.com>
Date: Fri, 15 Mar 2019 22:39:12 +0000
From: Paul Burton <paul.burton@...s.com>
To: Paul Burton <pburton@...ecomp.com>
CC: "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paul Burton <pburton@...ecomp.com>,
Amir Goldstein <amir73il@...il.com>,
Arnd Bergmann <arnd@...db.de>, Jan Kara <jack@...e.cz>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>
Subject: Re: [PATCH] MIPS: Remove custom MIPS32 __kernel_fsid_t type
Hello,
Paul Burton wrote:
> For MIPS32 kernels we have a custom definition of __kernel_fsid_t. This
> differs from the asm-generic version used by all other architectures &
> MIPS64 in one way - it declares the val field as an array of long,
> rather than an array of int. Since int & long have identical size &
> alignment when targeting MIPS32 anyway, this makes little sense.
>
> Beyond the pointlessness this causes problems for code which prints
> entries from the val array, for example the fanotify_encode_fid()
> function [1]. If such code uses a format specified suited to an int then
> it encounters compiler warnings when building for MIPS32, such as:
>
> In file included from include/linux/kernel.h:14:0,
> from include/linux/list.h:9,
> from include/linux/preempt.h:11,
> from include/linux/spinlock.h:51,
> from include/linux/fdtable.h:11,
> from fs/notify/fanotify/fanotify.c:3:
> fs/notify/fanotify/fanotify.c: In function 'fanotify_encode_fid':
> include/linux/kern_levels.h:5:18: warning: format '%x' expects argument
> of type 'unsigned int', but argument 2 has type 'long int' [-Wformat=]
>
> Remove the custom __kernel_fsid_t definition & make use of the
> asm-generic version which will have an identical layout in memory
> anyway, in order to remove the inconsistency with other architectures.
>
> One possible regression this could cause if is any code is attempting to
> print entries from the val array with a long-sized format specifier, in
> which case it would begin seeing compiler warnings when built against
> kernel headers including this change. Since such code is exceedingly
> rare, and would have to be MIPS32-specific to expect a long, this seems
> to be a problem that it's extremely unlikely anyone will encounter.
>
> [1] https://lore.kernel.org/linux-mips/CAOQ4uxiEkczB7PNCXegFC-eYb9zAGaio_o=OgHAJHFd7eavBxA@mail.gmail.com/T/#mb43103277c79ef06b884359209e817db1c136140
>
> Signed-off-by: Paul Burton <paul.burton@...s.com>
> Cc: Amir Goldstein <amir73il@...il.com>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Jan Kara <jack@...e.cz>
> Cc: linux-arch@...r.kernel.org
> Cc: linux-mips@...r.kernel.org
Applied to mips-fixes.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@...s.com to report it. ]
Powered by blists - more mailing lists