summaryrefslogtreecommitdiff
path: root/block/blk-mq-debugfs.h
diff options
context:
space:
mode:
authorPaul Burton <paul.burton@mips.com>2019-03-14 20:40:16 +0300
committerPaul Burton <paul.burton@mips.com>2019-03-14 21:31:20 +0300
commitf6cab793d4a70808e4946baa8f5df4ea9adacc82 (patch)
treec29409570b2224ca0fb3075e581123697de3d98d /block/blk-mq-debugfs.h
parentcdb8faa00e3fcdd0ad10add743516d616dc7d38e (diff)
downloadlinux-f6cab793d4a70808e4946baa8f5df4ea9adacc82.tar.xz
MIPS: Remove custom MIPS32 __kernel_fsid_t type
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 Cc: linux-kernel@vger.kernel.org
Diffstat (limited to 'block/blk-mq-debugfs.h')
0 files changed, 0 insertions, 0 deletions