* [PATCH] MIPS: Remove custom MIPS32 __kernel_fsid_t type
@ 2019-03-14 17:40 Paul Burton
2019-03-15 22:39 ` Paul Burton
0 siblings, 1 reply; 2+ messages in thread
From: Paul Burton @ 2019-03-14 17:40 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, Paul Burton, Amir Goldstein, Arnd Bergmann,
Jan Kara, linux-arch
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@mips.com>
Cc: Amir Goldstein <amir73il@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jan Kara <jack@suse.cz>
Cc: linux-arch@vger.kernel.org
Cc: linux-mips@vger.kernel.org
---
arch/mips/include/uapi/asm/posix_types.h | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/mips/include/uapi/asm/posix_types.h b/arch/mips/include/uapi/asm/posix_types.h
index 6aa49c10f88f..f0ccb5b90ce9 100644
--- a/arch/mips/include/uapi/asm/posix_types.h
+++ b/arch/mips/include/uapi/asm/posix_types.h
@@ -21,13 +21,6 @@
typedef long __kernel_daddr_t;
#define __kernel_daddr_t __kernel_daddr_t
-#if (_MIPS_SZLONG == 32)
-typedef struct {
- long val[2];
-} __kernel_fsid_t;
-#define __kernel_fsid_t __kernel_fsid_t
-#endif
-
#include <asm-generic/posix_types.h>
#endif /* _ASM_POSIX_TYPES_H */
--
2.21.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] MIPS: Remove custom MIPS32 __kernel_fsid_t type
2019-03-14 17:40 [PATCH] MIPS: Remove custom MIPS32 __kernel_fsid_t type Paul Burton
@ 2019-03-15 22:39 ` Paul Burton
0 siblings, 0 replies; 2+ messages in thread
From: Paul Burton @ 2019-03-15 22:39 UTC (permalink / raw)
To: Paul Burton
Cc: linux-mips, linux-kernel, Paul Burton, Amir Goldstein,
Arnd Bergmann, Jan Kara, linux-arch, linux-mips
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@mips.com>
> Cc: Amir Goldstein <amir73il@gmail.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Jan Kara <jack@suse.cz>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-mips@vger.kernel.org
Applied to mips-fixes.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-03-15 22:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-14 17:40 [PATCH] MIPS: Remove custom MIPS32 __kernel_fsid_t type Paul Burton
2019-03-15 22:39 ` Paul Burton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).