Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for
block reads") broke I2C block reads. It aimed to fix normal SMBus block
read, but changed the correct behavior of I2C block read in the process.
According to Documentation/i2c/smbus-protocol, one vital difference
between normal SMBus block read and I2C block read is that there is no
byte count prefixed in the data sent on the wire:
SMBus Block Read: i2c_smbus_read_block_data()
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
I2C Block Read: i2c_smbus_read_i2c_block_data()
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
Therefore the two transaction types need to be processed differently in
the driver by copying of the dma_buffer as done previously for the
I2C_SMBUS_I2C_BLOCK_DATA case.
Fixes: b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads") Signed-off-by: Pontus Andersson <epontan@gmail.com> Tested-by: Stephen Douthit <stephend@adiengineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Tue, 9 May 2017 10:05:01 +0000 (12:05 +0200)]
net/xen-netback: disable on 64KB page granularity
Building the linux-3.16 stable branch, I ran into this warning that
shows a serious problem in the xen-netback driver:
drivers/net/xen-netback/netback.c: In function 'xenvif_dealloc_kthread':
drivers/net/xen-netback/netback.c:2002:1: error: the frame size of 16384 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
The bug was fixed in linux-4.4, but for any older stable kernel we
either need to backport that fix, or not use the driver when the page
size is set to 64KB. As the proper fix is way bigger than the usual limit
for stable backport patches, this adds a Kconfig dependency.
Fixes: d0089e8a0e4c ("net/xen-netback: Make it running on 64KB page granularity") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
We were using s64 for lat_ns (latency nano-second value) since in
our calculations a negative value could be a resultant. For negative
values, we then assign lat_ns to be zero, so the value passed to
do_div() was never negative, but do_div() expects the argument type
to be u64, so do a cast to resolve a compile warning seen on
PowerPC.
CC: Yanjiang Jin <yanjiang.jin@windriver.com> CC: Yanir Lubetkin <yanirx.lubetkin@intel.com> Reported-by: Yanjiang Jin <yanjiang.jin@windriver.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
cpmac_start_xmit() used the max() macro on skb->len (an unsigned int)
and ETH_ZLEN (a signed int literal). This led to the following compiler
warning:
In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from drivers/net/ethernet/ti/cpmac.c:19:
drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer
types lacks a cast
(void) (&_max1 == &_max2); \
^
drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max'
len = max(skb->len, ETH_ZLEN);
^
On top of this, it assigned the result of the max() macro to a signed
integer whilst all further uses of it result in it being cast to varying
widths of unsigned integer.
Fix this up by using max_t to ensure the comparison is performed as
unsigned integers, and for consistency change the type of the len
variable to unsigned int.
Signed-off-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Tue, 9 May 2017 10:04:54 +0000 (12:04 +0200)]
MIPS: jz4740: fix build error in irq.h
kernelci found build error on the 3.16 and 3.18 stable trees that don't
show up in later versions:
arch/mips/jz4740/irq.h:21:38: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
arch/mips/jz4740/irq.h:20:39: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
include/linux/irqdesc.h:92:33: error: 'NR_IRQS' undeclared here (not in a function)
arch/mips/jz4740/irq.c:91:41: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function)
arch/mips/jz4740/irq.c:68:6: error: conflicting types for 'jz4740_irq_resume'
arch/mips/jz4740/irq.c:62:6: error: conflicting types for 'jz4740_irq_suspend'
arch/mips/jz4740/irq.c:49:39: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function)
arch/mips/jz4740/gpio.c:47:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:46:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:45:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:44:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:447:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
arch/mips/jz4740/gpio.c:446:23: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
arch/mips/jz4740/gpio.c:427:14: error: implicit declaration of function 'JZ4740_IRQ_INTC_GPIO' [-Werror=implicit-function-declaration]
arch/mips/jz4740/gpio.c:269:9: error: implicit declaration of function 'JZ4740_IRQ_GPIO' [-Werror=implicit-function-declaration]
The problem seems to be caused by commit 83bc76920080 ("MIPS: JZ4740: Use
generic irq chip") from linux-3.2, but only showed up in a defconfig
build when qi_lb60_defconfig was added in linux-3.13 and that configuration
never successfully built.
The code has changed in a number of ways before 4.4, which builds fine.
While I did not bisect the problem to a specific change, I found a simple
fix by including the obviously missing header.
Both Linus (most recent) and Steve (a while ago) reported that perf
related callbacks have massive stack bloat.
The problem is that software events need a pt_regs in order to
properly report the event location and unwind stack. And because we
could not assume one was present we allocated one on stack and filled
it with minimal bits required for operation.
Now, pt_regs is quite large, so this is undesirable. Furthermore it
turns out that most sites actually have a pt_regs pointer available,
making this even more onerous, as the stack space is pointless waste.
This patch addresses the problem by observing that software events
have well defined nesting semantics, therefore we can use static
per-cpu storage instead of on-stack.
Linus made the further observation that all but the scheduler callers
of perf_sw_event() have a pt_regs available, so we change the regular
perf_sw_event() to require a valid pt_regs (where it used to be
optional) and add perf_sw_event_sched() for the scheduler.
We have a scheduler specific call instead of a more generic _noregs()
like construct because we can assume non-recursion from the scheduler
and thereby simplify the code further (_noregs would have to put the
recursion context call inline in order to assertain which __perf_regs
element to use).
One last note on the implementation of perf_trace_buf_prepare(); we
allow .regs = NULL for those cases where we already have a pt_regs
pointer available and do not need another.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Javi Merino <javi.merino@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Petr Mladek <pmladek@suse.cz> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tom Zanussi <tom.zanussi@linux.intel.com> Cc: Vaibhav Nagarnaik <vnagarnaik@google.com> Link: http://lkml.kernel.org/r/20141216115041.GW3337@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The cfi_staa_write_buffers function uses a large amount of kernel stack
whenever CONFIG_MTD_MAP_BANK_WIDTH_32 is set, and that results in a
warning on ARM allmodconfig builds:
drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=]
It turns out that this is largely a result of a suboptimal implementation
of map_word_andequal(). Replacing this function with a straightforward
one reduces the stack size in this function by exactly 200 bytes,
shrinks the .text segment for this file from 27648 bytes to 26608 bytes,
and makes the warning go away.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Tue, 9 May 2017 10:04:49 +0000 (12:04 +0200)]
staging: r8192ee: prorperly format warning message
In stable/linux-3.16.y, we get a warning for 64-bit architectures:
drivers/staging/rtl8192ee/pci.c: In function '_rtl_pci_rx_interrupt':
include/linux/kern_levels.h:4:18: warning: format '%d' expects argument of type 'int', but argument 2 has type 'sk_buff_data_t {aka unsigned char *}' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%d' expects argument of type 'int', but argument 3 has type 'sk_buff_data_t {aka unsigned char *}' [-Wformat=]
The driver was removed in 3.18 before this was fixed, so there is no
workaround to backport, but it's easy enough to avoid the problem
by changing the printk message to something similar that uses
proper accessors for the skb fields.
Fixes: 78de2c063710 ("staging: r8192ee: Add source files for core driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
HOSTCC arch/mips/boot/elf2ecoff
arch/mips/boot/elf2ecoff.c: In function ‘main’:
arch/mips/boot/elf2ecoff.c:271:8: warning: variable ‘shstrtab’ set but not used [-Wunused-but-set-variable]
char *shstrtab;
Somehow the wrong version of the patch to remove the use of custom
gpio.h on mips has been merged. This patch add the missing fixes for a
build error on jz4740 because linux/gpio.h doesn't provide any machine
specfics definitions anymore.
Signed-off-by: Alban Bedel <albeu@free.fr> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/11089/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
kernelci reports a failure of the ip28_defconfig build after upgrading its
gcc version:
arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option -mr10k-cache-barrier=store. Stop.
The problem apparently is that the -mr10k-cache-barrier=store option is now
rejected for CPUs other than r10k. Explicitly including the CPU in the
check fixes this and is safe because both options were introduced in
gcc-4.4.
Fix a commit 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in
delay slots") regression and remove assembly errors:
arch/mips/dec/int-handler.S: Assembler messages:
arch/mips/dec/int-handler.S:162: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:163: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:229: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:230: Error: Macro used $at after ".set noat"
triggering with with the CPU_DADDI_WORKAROUNDS option set and the DADDIU
instruction. This is because with that option in place the instruction
becomes a macro, which expands to an LI/DADDU (or actually ADDIU/DADDU)
sequence that uses $at as a temporary register.
With CPU_DADDI_WORKAROUNDS we only support `-msym32' compilation though,
and this is already enforced in arch/mips/Makefile, so choose the 32-bit
expansion variant for the supported configurations and then replace the
64-bit variant with #error just in case.
Fixes: 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in delay slots") Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16893/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
When expanding the la or dla pseudo-instruction in a delay slot the GNU
assembler will complain should the pseudo-instruction expand to multiple
actual instructions, since only the first of them will be in the delay
slot leading to the pseudo-instruction being only partially executed if
the branch is taken. Use of PTR_LA in the dec int-handler.S leads to
such warnings:
arch/mips/dec/int-handler.S: Assembler messages:
arch/mips/dec/int-handler.S:149: Warning: macro instruction expanded into multiple instructions in a branch delay slot
arch/mips/dec/int-handler.S:198: Warning: macro instruction expanded into multiple instructions in a branch delay slot
Commit 078a55fc824c1 ("Delete __cpuinit/__CPUINIT usage from MIPS code")
removed our __CPUINIT directives, so now the ".previous" directives
are superfluous. Remove them.
The aurora cache controller is the only remaining user of a couple
of functions in this file and are completely unused when that is
disabled, leading to build warnings:
arch/arm/mm/cache-l2x0.c:167:13: warning: 'l2x0_cache_sync' defined but not used [-Wunused-function]
arch/arm/mm/cache-l2x0.c:184:13: warning: 'l2x0_flush_all' defined but not used [-Wunused-function]
arch/arm/mm/cache-l2x0.c:194:13: warning: 'l2x0_disable' defined but not used [-Wunused-function]
With the knowledge that the code is now aurora-specific, we can
simplify it noticeably:
- The pl310 errata workarounds are not needed on aurora and can be removed
- As confirmed by Thomas Petazzoni from the data sheet, the cache_wait()
macro is never needed.
- No need to hold the lock across atomic cache sync
- We can load the l2x0_base into a local variable across operations
There should be no functional change in this patch, but readability
and the generated object code improves, along with avoiding the
warnings.
(on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
DMA traffic by reading data from a SD card)
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The warning was introduced in 2009 (commit 4bf1fa5a34aa ([ARM] 5613/1:
implement CALLER_ADDRESSx)). The only "problem" here is that
CALLER_ADDRESSx for x > 1 returns NULL which doesn't do much harm.
The drawback of implementing a fix (i.e. use unwind tables to implement CALLER_ADDRESSx) is that much of the unwinder code would need to be marked as not
traceable.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Commit 21278aeafbfa ("ARM: use menuconfig for sub-arch menus") improved
the sub-arch menus, but accidentally caused new warnings for omap1.
This was because the commit added a menu entry around config ARCH_OMAP
bool entry where the menu had depends on ARCH_MULTI_V6 || ARCH_MULTI_V7.
As ARCH_OMAP is shared between omap1 and omap2plus, let's fix the
issue by defining ARCH_OMAP in the shared plat-omap/Kconfig.
Fixes: 21278aeafbfa ("ARM: use menuconfig for sub-arch menus") Reported-by: Andreas Ruprecht <rupran@einserver.de> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The PJ4 inline asm sequence to write to cp15 cannot be built in Thumb-2
mode, due to the way it performs arithmetic on the program counter, so it
is built in ARM mode instead. However, building C files in ARM mode under
CONFIG_THUMB2_KERNEL is problematic, since the instrumentation performed
by subsystems like ftrace does not expect having to deal with interworking
branches.
Since the sequence in question is simply a poor man's ISB instruction,
let's use a straight 'isb' instead when building in Thumb2 mode. Thumb2
implies V7, so 'isb' should always be supported in that case.
Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Two files that get included when building the multi_v7_defconfig target
fail to build when selecting THUMB2_KERNEL for this configuration.
In both cases, we can just build the file as ARM code, as none of its
symbols are exported to modules, so there are no interworking concerns.
In the iwmmxt.S case, add ENDPROC() declarations so the symbols are
annotated as functions, resulting in the linker to emit the appropriate
mode switches.
Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Olof Johansson <olof@lixom.net> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Fri, 5 May 2017 19:47:31 +0000 (21:47 +0200)]
ARM: cns3xxx: shut up frame size warning
This shuts up a warning in the 3.18-stable series that has been fixed
in newer kernels with commit 498a92d42596 ("ARM: cns3xxx: pci: avoid
potential stack overflow"):
arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init':
arch/arm/mach-cns3xxx/pcie.c:313:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
The fix that went into v4.4 is known to be buggy and was later
fixed again with commit 88e9da9a2a70 ("CNS3xxx: Fix PCI
cns3xxx_write_config()"). While we could backport both to 3.18,
they are fairly invasive and the warning is definitely harmless
here as the call chain is known to not overflow the stack of the
init task.
This simply adds a Makefile flag to extend the limit for this one
file.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Linus reported the following new warning on x86 allmodconfig with GCC 5.1:
> ./arch/x86/include/asm/spinlock.h: In function ‘arch_spin_lock’:
> ./arch/x86/include/asm/spinlock.h:119:3: warning: implicit declaration
> of function ‘__ticket_lock_spinning’ [-Wimplicit-function-declaration]
> __ticket_lock_spinning(lock, inc.tail);
> ^
This warning triggers because of these hacks in misc.h:
/*
* we have to be careful, because no indirections are allowed here, and
* paravirt_ops is a kind of one. As it will only run in baremetal anyway,
* we just keep it from happening
*/
#undef CONFIG_PARAVIRT
#undef CONFIG_KASAN
But these hacks were not updated when CONFIG_PARAVIRT_SPINLOCKS was added,
and eventually (with the introduction of queued paravirt spinlocks in
recent kernels) this created an invalid Kconfig combination and broke
the build.
So add a CONFIG_PARAVIRT_SPINLOCKS #undef line as well.
Also remove the _ASM_X86_DESC_H quirk: that undocumented quirk
was originally added ages ago, in:
099e1377269a ("x86: use ELF format in compressed images.")
and I went back to that kernel (and fixed up the main Makefile
which didn't build anymore) and checked what failure it
avoided: it avoided an include file dependencies related
build failure related to our old x86-platforms code.
That old code is long gone, the header dependencies got cleaned
up, and the build does not fail anymore with the totality of
asm/desc.h included - so remove the quirk.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper
bound of the loop setting non-kernel-image entries to zero should not
exceed the size of level2_kernel_pgt.
In file included from drivers/staging/wlan-ng/prism2usb.c:5:0:
drivers/staging/wlan-ng/prism2fw.c: In function
‘read_cardpda.constprop.43’:
drivers/staging/wlan-ng/prism2fw.c:792:1: warning: the frame size of
1068 bytes is larger than 1024 bytes [-Wframe-larger-than=]
The variable to 'struct p80211msg_p2req_readpda' was previously being created
on the stack, which inturn exeeded the frame size limit, resulting in a
sparse warning. This patch alloctes the memory to the structure dynamically
and the operations are left unchanged.
Signed-off-by: A Raghavendra Rao <arrao@cdac.in> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fix indent warning when building with gcc 6:
drivers/staging/iio/adc/ad7192.c:239:4: warning: statement is indented
as if it were guarded by... [-Wmisleading-indentation]
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Fri, 5 May 2017 19:47:23 +0000 (21:47 +0200)]
staging: vt6655: fix overly large stack usage
We get a warning for the large stack usage in some configurations:
drivers/staging/vt6655/device_main.c: In function 'device_ioctl':
drivers/staging/vt6655/device_main.c:2974:1: warning: the frame size of 1304 bytes is larger than 1024 bytes [-Wframe-larger-than=]
This is addressed in linux-3.19 with commit 67013f2c0e58 ("staging: vt6655:
mac80211 conversion add main mac80211 functions"), which obsoletes the
device_ioctl() function, but as that does not apply to stable kernels,
this picks an easier way out by using dynamic allocation.
The driver was merged in 2.6.31, and the fix applies to all versions
before 3.19.
Arnd Bergmann [Fri, 5 May 2017 19:47:22 +0000 (21:47 +0200)]
staging: imx-drm: fix indentation warning
gcc-6 produces a harmless warning:
drivers/staging/imx-drm/imx-hdmi.c: In function 'hdmi_config_AVI':
drivers/staging/imx-drm/imx-hdmi.c:967:2: error: this 'else' clause does not guard... [-Werror=misleading-indentation]
Commit d083c312cba2 ("drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little")
in linux-4.3 fixes this with a larger rewrite that is not applicable here.
After that rewrite, the variable that gets assigned here no longer exists.
The assignment is rather pointless here, as we just set a variable to zero
that is later added into another variable using a bitwise or operator, and
that has no effect, so I'm just changing the indentation here to shut up
the warning.
The driver was originally merged in linux-3.13, and the fix applies
to all versions between that and 4.2.
Arnd Bergmann [Fri, 5 May 2017 19:47:21 +0000 (21:47 +0200)]
staging: bcm: add 32-bit host dependency
The driver uses a 32-bit variable to store a pointer, causing a couple of
warnings:
../drivers/staging/bcm/CmHost.c: In function 'StoreCmControlResponseMessage':
../drivers/staging/bcm/CmHost.c:1503:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
(struct bcm_connect_mgr_params *) ntohl(
^
../drivers/staging/bcm/CmHost.c:1546:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
(struct bcm_connect_mgr_params *) ntohl(
^
../drivers/staging/bcm/CmHost.c:1564:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
(struct bcm_connect_mgr_params *) ntohl(
I fixed other warnings in an earlier commit 9f1c75ac2dba ("staging/bcm: fix most
build warnings"), but couldn't figure out what was the intended behavior on
64-bit machines here.
The driver was removed in linux-3.19, commit d09e9b160fc1 ("staging: bcm: remove
driver") which explains that it never worked on 64-bit machines. This adds
a Kconfig dependency instead to prevent it from being built in the known
broken configuration. This workaround applies to v2.6.37 or higher.
Fixes: f8942e07a3db ("staging: Beeceem USB Wimax driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Commit 7edaa761ee81b ("video: mx3fb: Add backlight control support")
changed the mx3fb driver so it always selects the BACKLIGHT_CLASS_DEVICE
symbol, but that is hidden behind BACKLIGHT_LCD_SUPPORT in Kconfig, so
we get a Kconfig warning for multi_v5_defconfig, which doesn't have that:
This makes sure we always enable both symbols together for mx3fb, like
we do for the other drivers that can't be built without backlight
support. Note that a better solution would be to ensure the driver can
work with or without backlight support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Alexander Stein <alexander.stein@systec-electronic.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Static checkers complain that we should probably add curly braces
because, from the indenting, it looks like seq_printf() should be inside
the list_for_each_entry() loop. But the code is actually correct, it's
just the indenting which is off.
Besides fixing the indenting on seq_printf(), I did add curly braces,
because generally mult-line indents should have curly braces to make
them more readable.
The unintended indent was left behind and not unindented in
drm/i915: Make pin count per VMA Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
====================
net/netfilter/nft_reject.c: In function ‘nft_reject_dump’:
net/netfilter/nft_reject.c:61:2: warning: enumeration value ‘NFT_REJECT_TCP_RST’ not handled in switch [-Wswitch]
switch (priv->type) {
^
net/netfilter/nft_reject.c:61:2: warning: enumeration value ‘NFT_REJECT_ICMPX_UNREACH’ not handled in switch [-Wswi\
tch]
net/netfilter/nft_reject_inet.c: In function ‘nft_reject_inet_dump’:
net/netfilter/nft_reject_inet.c:105:2: warning: enumeration value ‘NFT_REJECT_TCP_RST’ not handled in switch [-Wswi\
tch]
switch (priv->type) {
^
====================
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
More recent GCC warns about two kinds of switch statement uses:
1) Switching on an enumeration, but not having an explicit case
statement for all members of the enumeration. To show the
compiler this is intentional, we simply add a default case
with nothing more than a break statement.
2) Switching on a boolean value. I think this warning is dumb
but nevertheless you get it wholesale with -Wswitch.
This patch cures all such warnings in netfilter.
Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
gcc-5.0 gained a new warning in the fwsignal portion of the brcmfmac
driver:
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c: In function 'brcmf_fws_txs_process':
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
This is a false positive, and marking the brcmf_fws_hanger_poppkt function
as 'static inline' makes the warning go away. I have checked the object
file output and while a little code gets moved around, the size of
the binary remains identical.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The driver reads a value from hfa384x_from_bap(), which may fail,
and then assigns the value to a local variable. gcc detects that
in in the failure case, the 'rlen' variable now contains
uninitialized data:
In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (le16_to_cpu(rec.len) == 0) {
This restructures the function as suggested by Russell King, to
make it more readable and get more reliable error handling, by
handling each failure mode using a goto.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
is misleadingly indented: the
db->init=0
is indented as if part of the else clause at line 1086, but it is
independent of it (no braces before the "if" at line 1087).
This patch fixes the indentation to reflect the actual meaning of the code,
though is it actually meant to be part of the "else" clause? (I'm a
compiler developer, not a kernel person). It also adds spaces around
the assignment, to placate checkpatch.pl.
Seen via an experimental new gcc warning I'm working on for gcc 6,
-Wmisleading-indentation, using gcc r223098 adding
-Werror=misleading-indentation to KBUILD_CFLAGS in Makefile.
The experimental GCC emits this warning (as an error), rightly IMHO:
drivers/net/ethernet/dec/tulip/uli526x.c: In function ‘uli526x_timer’:
drivers/net/ethernet/dec/tulip/uli526x.c:1118:3: error: statement is
indented as if it were guarded by... [-Werror=misleading-indentation]
db->init=0;
^
drivers/net/ethernet/dec/tulip/uli526x.c:1086:4: note: ...this ‘else’
clause, but it is not
} else
^
Hope this is helpful
Dave
Signed-off-by: David Malcolm <dmalcolm@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
in the vxge driver:
drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning: 'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning: 'adaptive_coalesce_rx_interrupts' defined but not used [-Wunused-function]
We could add another #ifdef here, but it's nicer to avoid those warnings
for good by converting the existing #ifdef to if(IS_ENABLED()), which has
the same effect but provides better compile-time coverage in general,
and lets the compiler understand better when the function is intentionally
unused.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This is the last remaining warning for arm64, and I'd like to get rid of
it. We don't really know the cache line size, architecturally it would
be at least 16 bytes, but all implementations I found have 64 or 128
bytes. Configuring tulip for 32-byte lines as we do on ARM32 seems to
be the safe but slow default, and nobody who cares about performance these
days would use a tulip chip anyway, so we can just use that.
To save the next person the job of trying to find out what this is for
and picking a default for their architecture just to kill off the warning,
I'm now removing the preprocessor #warning and turning it into a pr_warn
or dev_warn that prints the equivalent information when the driver gets
loaded.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Resolves compile warning about use of a deprecated function call:
drivers/net/ethernet/amd/nmclan_cs.c: In function ‘nmclan_config’:
drivers/net/ethernet/amd/nmclan_cs.c:624:3: warning: ‘pcmcia_request_exclusive_irq’ is deprecated (declared at include/pcmcia/ds.h:213) [-Wdeprecated-declarations]
ret = pcmcia_request_exclusive_irq(link, mace_interrupt);
Updates pcmcia_request_exclusive_irq() to pcmcia_request_irq().
CC: Roger Pao <rpao@paonet.org> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
A recent patch tried to work around a valid warning for the use of a
deprecated interface by blindly changing from the old
pcmcia_request_exclusive_irq() interface to pcmcia_request_irq().
This driver has an interrupt handler that is not currently aware
of shared interrupts, but can be easily converted to be.
At the moment, the driver reads the interrupt status register
repeatedly until it contains only zeroes in the interesting bits,
and handles each bit individually.
This patch adds the missing part of returning IRQ_NONE in case none
of the bits are set to start with, so we can move on to the next
interrupt source.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 5f5316fcd08ef7 ("am2150: Update nmclan_cs.c to use update PCMCIA API") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
gcc points out code that is not indented the way it is
interpreted:
net/caif/cfpkt_skbuff.c: In function 'cfpkt_setlen':
net/caif/cfpkt_skbuff.c:289:4: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
return cfpkt_getlen(pkt);
^~~~~~
net/caif/cfpkt_skbuff.c:286:3: note: ...this 'else' clause, but it is not
else
^~~~
It is clear from the context that not returning here would be
a bug, as we'd end up passing a negative length into a function
that takes a u16 length, so it is not missing curly braces
here, and I'm assuming that the indentation is the only part
that's wrong about it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The #warning was present 10 years ago when the driver first got merged.
As the platform is rather obsolete by now, it seems very unlikely that
the warning will cause anyone to fix the code properly.
kernelci.org reports the warning for every build in the meantime, so
I think it's better to just turn it into a code comment to reduce
noise.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Not all architectures are able to call __builtin_return_address().
On ARM, the mISDN code produces this warning:
hardware/mISDN/w6692.c: In function 'w6692_dctrl':
hardware/mISDN/w6692.c:1181:75: warning: unsupported argument to '__builtin_return_address'
pr_debug("%s: %s dev(%d) open from %p\n", card->name, __func__,
^
hardware/mISDN/mISDNipac.c: In function 'open_dchannel':
hardware/mISDN/mISDNipac.c:759:75: warning: unsupported argument to '__builtin_return_address'
pr_debug("%s: %s dev(%d) open from %p\n", isac->name, __func__,
^
In a lot of cases, this is relatively easy to work around by
passing the value of __builtin_return_address(0) from the
callers into the functions that want it. One exception is
the indirect 'open' function call in struct isac_hw. While it
would be possible to fix this as well, this patch only addresses
the other callers properly and lets this one return the direct
parent function, which should be good enough.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The mlx5 driver passes a string pointer in through a 'u64' variable,
which on 32-bit machines causes a build warning:
drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function 'qp_read_field':
drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:303:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
The code is in fact safe, so we can shut up the warning by adding
extra type casts.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Reduce stack use by using kmemdup and not using a very
large struct on stack.
In function ‘i40e_dbg_dump_desc’:
warning: the frame size of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Signed-off-by: Joe Perches <joe@perches.com> Tested-by: Jim Young <jamesx.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The time comparsion functions require arguments of type unsigned long
instead of (signed) long.
Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
kernelci.org reports a warning for this driver, as it copies a local
variable into a 'const char *' string:
drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of 'strncpy' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
Using kstrndup() simplifies the code and avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
If no user settings are found it's pointless trying to
read them from flash. So skip that step.
This also fixes a compilation warning about uninitialized variables in
aic94xx.
Signed-off-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fix a smatch warning:
drivers/scsi/mvsas/mv_sas.c:740 mvs_task_prep() warn: curly braces intended?
The code is correct, the indention is misleading. When the device is not
ready we want to return SAS_PHY_DOWN. But current indentation makes it
look like we only do so in the else branch of if (mvi_dev).
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
drivers/scsi/be2iscsi/be_main.c: In function 'be_sgl_create_contiguous':
drivers/scsi/be2iscsi/be_main.c:3187:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
WARN_ON(!length > 0);
gcc version 5.2.1
Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Cc: Jayamohan Kallickal <jayamohan.kallickal@avagotech.com> Cc: Minh Tran <minh.tran@avagotech.com> Cc: John Soni Jose <sony.john-n@avagotech.com> Cc: "James E.J. Bottomley" <JBottomley@odin.com> Reported-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Manoj Kumar <manoj@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Fri, 5 May 2017 19:46:53 +0000 (21:46 +0200)]
scsi: advansys: remove #warning message
The advansys driver was converted to the proper DMA API in linux-4.2, but
the 3.18-stable kernel still warns about this:
drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API [-Wcpp]
The warning clearly is not helpful in 3.18 any more, it just clutters up
the build log. This removes the warning instead, and clarifies the
comment above it.
Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[bwh: Changed comment to say 3.16] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
non-x86 builds want the #warning in the IPS code about compiling on the wrong
architecture removed because it keeps triggering on their platforms build
farms. Transform from a compile time warning into a runtime one with taint to
preserve the original intent of the authors.
Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Fri, 5 May 2017 19:46:51 +0000 (21:46 +0200)]
scsi-tgt: fix type conversion warning
In 3.16-stable, we get this warning:
drivers/scsi/scsi_tgt_if.c:289:36: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast [-Wint-conversion]
The driver was removed in 3.17, so the bug was never fixed, but the code
works correctly and is only lacking a cast to build cleanly on all architectures.
Fixes: 97f78759ea1c ("[SCSI] scsi tgt: scsi target user and kernel communication interface") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Fri, 5 May 2017 19:46:50 +0000 (21:46 +0200)]
dm bufio: hide bogus warning
mips-gcc-5.3 warns about correct code on linux-3.18 and earlier:
In file included from ../include/linux/blkdev.h:4:0,
from ../drivers/md/dm-bufio.h:12,
from ../drivers/md/dm-bufio.c:9:
../drivers/md/dm-bufio.c: In function 'alloc_buffer':
../include/linux/sched.h:1975:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
../drivers/md/dm-bufio.c:325:11: note: 'noio_flag' was declared here
The warning disappeared on later kernels with this commit: be0c37c985ed
("MIPS: Rearrange PTE bits into fixed positions.") I assume this only
happened because it changed some inlining decisions.
On 3.18.y, we can shut up the warning by adding an extra initialization.
Arnd Bergmann [Fri, 5 May 2017 19:46:49 +0000 (21:46 +0200)]
i2o: hide unsafe ioctl on 64-bit
We get a warning about a broken pointer conversion on 64-bit architectures:
drivers/message/i2o/i2o_config.c: In function 'i2o_cfg_passthru':
drivers/message/i2o/i2o_config.c:893:19: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
(p->virt, (void __user *)sg[i].addr_bus,
^
drivers/message/i2o/i2o_config.c:953:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
((void __user *)sg[j].addr_bus, sg_list[j].virt,
^
This has clearly never worked right, so we can add an #ifdef around the code.
The driver was moved to staging in linux-4.0 and finally removed in 4.2,
so upstream does not have a fix for it.
The driver originally got this mostly right, though probably by accident.
Fixes: f4c2c15b930b ("[PATCH] Convert i2o to compat_ioctl") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Building an arm allmodconfig kernel triggers a lengthy but harmless
warning in the isicom driver:
drvers/tty/isicom.c: In function 'isicom_send_break':
uapi/linux/swab.h:13:15: warning: integer overflow in expression [-Woverflow]
(((__u16)(x) & (__u16)0x00ffU) << 8) | \
^
uapi/linux/swab.h:107:2: note: in expansion of macro '___constant_swab16'
___constant_swab16(x) : \
^
uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16'
#define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
^
linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16'
#define cpu_to_le16 __cpu_to_le16
^
include/asm/io.h:270:6: note: in expansion of macro 'cpu_to_le16'
cpu_to_le16(v),__io(p)); })
^
drivers/tty/isicom.c:1058:2: note: in expansion of macro 'outw'
outw((length & 0xff00), base);
^
Apparently, the problem is related to the fact that the value 0xff00,
when used as a 16-bit number, is negative and passed into bitwise
operands of the generic byte swapping code.
Marking the input argument as unsigned in both technically correct
and avoids the warning.
The nozomi wireless data driver has its own helper function to
transfer data from a FIFO, doing an extra byte swap on big-endian
architectures, presumably to bring the data back into byte-serial
order after readw() or readl() perform their implicit byteswap.
This helper function is used in the receive_data() function to
first read the length into a 32-bit variable, which causes
a compile-time warning:
drivers/tty/nozomi.c: In function 'receive_data':
drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
The problem is that gcc is unsure whether the data was actually
read or not. We know that it is at this point, so we can replace
it with a single readl() to shut up that warning.
I am leaving the byteswap in there, to preserve the existing
behavior, even though this seems fishy: Reading the length of
the data into a cpu-endian variable should normally not use
a second byteswap on big-endian systems, unless the hardware
is aware of the CPU endianess.
There appears to be a lot more confusion about endianess in this
driver, so it probably has not worked on big-endian systems in
a long time, if ever, and I have no way to test it. It's well
possible that this driver has not been used by anyone in a while,
the last patch that looks like it was tested on the hardware is
from 2008.
When building on 64 bit architectures the use of bitwise negation generates
constants larger than 32 bits which won't fit in u32s used to represent
32 bit register values on the device. Explicitly cast to let the compiler
know that the higher bits are not significant and can be discarded.
Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
On 64 bit systems integers are generally still 32 bit but long values and
pointers are usually 64 bit. GCC warns when casting a 64 bit pointer into
a 32 bit integer so cast to a long instead in order to avoid warnings.
Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Since commit 54196ccbe0ba (of: consolidate linker section OF match table
declarations) which went into 3.16-rc1 the following compiler warning is
generated:
In file included from drivers/clk/clk-efm32gg.c:12:0: include/linux/of.h:772:20:
warning: comparison of distinct pointer types lacks a cast [enabled by default]
.data = (fn == (fn_type)NULL) ? fn : fn }
^
include/linux/of.h:785:3: note: in expansion of macro '_OF_DECLARE'
_OF_DECLARE(table, name, compat, fn, of_init_fn_1)
^
include/linux/clk-provider.h:545:42: note: in expansion of macro 'OF_DECLARE_1'
#define CLK_OF_DECLARE(name, compat, fn) OF_DECLARE_1(clk, name, compat, fn)
^
drivers/clk/clk-efm32gg.c:81:1: note: in expansion of macro 'CLK_OF_DECLARE'
CLK_OF_DECLARE(efm32ggcmu, "efm32gg,cmu", efm32gg_cmu_init);
^
Fix it by making efm32gg_cmu_init return void.
Cc: Rob Herring <robh@kernel.org> Reported-by: Bryan Hundven <bryanhundven@gmail.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
gcc-5.x warns about a preexisting problem in the hpt36x pata driver:
drivers/ata/pata_hpt366.c: In function 'hpt36x_init_one':
drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
Other ata drivers have the same problem, as ata_pci_bmdma_init_one
takes a non-const pointer, and they solve it by using a cast to
turn that pointer into a normal non-const pointer.
I also tried to change the ata core code to make host->private_data
a const pointer, but that quickly got out of hand, as some other
drivers expect it to be writable, so I ended up using the same
hack as the others here.
Negating ADAU1977_BLOCK_POWER_SAI_LDO_EN creates an unsigned long constant
with all bits set which on 64 bit architectures needs to be truncated to
an unsigned int, generating a warning. Add an explicit cast since we know
this is OK.
Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
There is one design rule according to SAI's reference manual:
If the transmitter bit clock and frame sync are to be used by both transmitter
and receiver, the transmitter must be configured for asynchronous operation
and the receiver for synchronous operation.
And SYNC of TCR2 is a 2-width control bit:
00 Asynchronous mode.
01 Synchronous with receiver.
10 Synchronous with another SAI transmitter.
11 Synchronous with another SAI receiver.
So the driver should have set SYNC bit of TCR2 to 0x0, and meanwhile set SYNC
bit of RCR2 to 0x1 (Synchronous with transmitter).
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Since we pass the port number through file private data for debugfs we cast
it to and from a pointer so use uintptr_t in order to ensure that the
types are compatible, avoiding warnings on 64 bit platforms where pointers
are 64 bit and unsigned integers 32 bit.
Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
do_div() requires that the first parameter is a 64-bit integer,
which but clkrate was defined as an unsigned long. This caused
the following warnings:
CC sound/soc/fsl/fsl_ssi.o
sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_set_bclk':
sound/soc/fsl/fsl_ssi.c:593:3: warning: comparison of distinct pointer types lacks a cast
sound/soc/fsl/fsl_ssi.c:593:3: warning: right shift count >= width of type
sound/soc/fsl/fsl_ssi.c:593:3: warning: passing argument 1 of '__div64_32' from incompatible pointer type
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is of type 'long unsigned int *'
Signed-off-by: Timur Tabi <timur@tabi.org> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
As we start to decomission the return value from gpiochip_remove()
the compilers emit warnings due to the function being tagged
__must_check. So drop this until we remove the return value
altogether.
Cc: Abdoulaye Berthe <berthe.ab@gmail.com> Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
When printing size_t values we should use the %zd or %zx format specifier
in order to ensure the value is displayed correctly and avoid warnings from
sparse.
Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
As with ARM the ARMv8 architecture provides a cycle counter which can be
used to provide a high resolution time for the joystick driver and
silence the build warning that results from not having a precise timer
on ARMv8, making allmodconfig and allyesconfig quieter.
Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
../drivers/mfd/arizona-core.c: In function ‘arizona_of_get_type’:
../drivers/mfd/arizona-core.c:505:10:
warning: cast from pointer to integer of different size
Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The xgene-reset driver uses xgene_restart() as arm_pm_restart() but that
function should take an enum reset_type as the first argument rather than
a char. Fix this; the paramter is not referenced in the implementation.
Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The return type of find_first_bit() is architecture specific,
on ARM it is 'unsigned int', while the asm-generic code used
on x86 and a lot of other architectures returns 'unsigned long'.
When building the mlx5 driver on ARM, we get a warning about
this:
infiniband/hw/mlx5/mem.c: In function 'mlx5_ib_cont_pages':
infiniband/hw/mlx5/mem.c:84:143: warning: comparison of distinct pointer types lacks a cast
m = min(m, find_first_bit(&tmp, sizeof(tmp)));
This patch changes the driver to use min_t to make it behave
the same way on all architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Eli Cohen <eli@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Fri, 5 May 2017 19:46:30 +0000 (21:46 +0200)]
iio: adc: fix building on 64-bit
On the 3.16 kernel, we get a harmless warning:
drivers/iio/adc/exynos_adc.c: In function 'exynos_adc_get_version':
drivers/iio/adc/exynos_adc.c:112:9: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
Upstream commit e49d99e0ecc8 ("iio: adc: exynos_adc: Add exynos_adc_data
structure to improve readability") in 3.17 removed the function, so
we can't backport a fix from upstream, but changing the cast to
use uintptr_t is the obvious fix.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The original fix that was backported to 3.18 already addressed the warning
in some configurations, but not in others, leaving us with the same output:
../fs/gfs2/dir.c: In function 'get_first_leaf':
../fs/gfs2/dir.c:768:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
error = get_leaf(dip, leaf_no, bh_out);
^
../fs/gfs2/dir.c: In function 'dir_split_leaf.isra.20':
../fs/gfs2/dir.c:987:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
This takes the approach that we took in later versions in mainline,
but does not backport the entire patch, as that would be too large
for stable and IIRC caused regressions in other drivers.
da91309e0a7e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function. I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)
cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.
It can fail. One of the two callers ignores this, the other aborts and
fails the device open.
It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes. Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.
It contains a nonsensical test "!cpumask_of_node(numa_node)". This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.
It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.
Fixes: da91309e0a7e8966d916a74cce42ed170fde06bf Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased) Tested-by: Amir Vadai <amirv@mellanox.com> Acked-by: Amir Vadai <amirv@mellanox.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
For every pfn aligned to minimum_order, dissolve_free_huge_pages() will
call dissolve_free_huge_page() which takes the hugetlb spinlock, even if
the page is not huge at all or a hugepage that is in-use.
Improve this by doing the PageHuge() and page_count() checks already in
dissolve_free_huge_pages() before calling dissolve_free_huge_page(). In
dissolve_free_huge_page(), when holding the spinlock, those checks need
to be revalidated.
Link: http://lkml.kernel.org/r/20160926172811.94033-4-gerald.schaefer@de.ibm.com Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Rui Teng <rui.teng@linux.vnet.ibm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
MODULE_DEVICE_TABLE() macro used to create aliases to device tables.
Normally alias should have the same type as aliased symbol.
Device tables are arrays, so they have 'struct type##_device_id[x]'
types. Alias created by MODULE_DEVICE_TABLE() will have non-array type -
'struct type##_device_id'.
This inconsistency confuses compiler, it could make a wrong assumption
about variable's size which leads KASan to produce a false positive report
about out of bounds access.
For every global variable compiler calls __asan_register_globals() passing
information about global variable (address, size, size with redzone, name
...) __asan_register_globals() poison symbols redzone to detect possible
out of bounds accesses.
When symbol has an alias __asan_register_globals() will be called as for
symbol so for alias. Compiler determines size of variable by size of
variable's type. Alias and symbol have the same address, so if alias have
the wrong size part of memory that actually belongs to the symbol could be
poisoned as redzone of alias symbol.
By fixing type of alias symbol we will fix size of it, so
__asan_register_globals() will not poison valid memory.
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Konstantin Serebryany <kcc@google.com> Cc: Dmitry Chernenkov <dmitryc@google.com> Signed-off-by: Andrey Konovalov <adech.fo@gmail.com> Cc: Yuri Gribov <tetra2005@gmail.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Christoph Lameter <cl@linux.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Normally any device ids will be above the corresponding device driver
structure. This patch moves the pci device ids and MODULE_DEVICE_TABLE()
above the pci driver structure.
Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Currently an allyesconfig build [gcc-4.9.1] can generate the following:
WARNING: vmlinux.o(.text.unlikely+0x3864): Section mismatch in
reference from the function cpumask_empty.constprop.3() to the
variable .init.data:nmi_ipi_mask
which comes from the cpumask_empty usage in arch/x86/kernel/nmi_selftest.c.
Normally we would not see a symbol entry for cpumask_empty since it is:
Currently the match() function supports a leading * to match any
prefix and a trailing * to match any suffix. However there currently
is not a combination of both that can be used to target matches of
whole families of functions that share a common substring.
Here we expand the *foo and foo* match to also support *foo* with
the goal of targeting compiler generated symbol names that contain
strings like ".constprop." and ".isra."
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Newer versions of gcc warn about the use of __builtin_return_address()
with a non-zero argument when "-Wall" is specified:
kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’:
kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address]
stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
[ .. repeats a few times for other similar cases .. ]
It is true that a non-zero argument is somewhat dangerous, and we do not
actually have very many uses of that in the kernel - but the ftrace code
does use it, and as Stephen Rostedt says:
"We are well aware of the danger of using __builtin_return_address() of
> 0. In fact that's part of the reason for having the "thunk" code in
x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames
when tracking irqs off sections, to prevent __builtin_return_address()
from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to
trace irqs off. (otherwise CALLER_ADDR1 might crash)'."
For now, __builtin_return_address() with a non-zero argument is the best
we can do, and the warning is not helpful and can end up making people
miss other warnings for real problems.
So disable the frame-address warning on compilers that need it.
Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
As a part of memory initialisation the architecture passes an array to
free_area_init_nodes() which specifies the max PFN of each memory zone.
This array is not necessarily monotonic (due to unused zones) so this
array is parsed to build monotonic lists of the min and max PFN for each
zone. ZONE_MOVABLE is special cased here as its limits are managed by
the mm subsystem rather than the architecture. Unfortunately, this
special casing is broken when ZONE_MOVABLE is the not the last zone in
the zone list. The core of the issue is:
if (i == ZONE_MOVABLE)
continue;
arch_zone_lowest_possible_pfn[i] =
arch_zone_highest_possible_pfn[i-1];
As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will
be set to zero. This patch fixes this bug by adding explicitly tracking
where the next zone should start rather than relying on the contents
arch_zone_highest_possible_pfn[].
Thie is low priority. To get bitten by this you need to enable a zone
that appears after ZONE_MOVABLE in the zone_type enum. As far as I can
tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled,
so I can't see this affecting too many people.
I only noticed this because I've been fiddling with ZONE_DEVICE on
powerpc and 4.6 broke my test kernel. This bug, in conjunction with the
changes in Taku Izumi's kernelcore=mirror patch (d91749c1dda71) and
powerpc being the odd architecture which initialises max_zone_pfn[] to
~0ul instead of 0 caused all of system memory to be placed into
ZONE_DEVICE at boot, followed a panic since device memory cannot be used
for kernel allocations. I've already submitted a patch to fix the
powerpc specific bits, but I figured this should be fixed too.
Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.com Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Mel Gorman <mgorman@techsingularity.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Some false positive warnings are reported for powerpc build.
The following warnings are reported in
http://kisskb.ellerman.id.au/kisskb/buildresult/12519703/
CC fs/nilfs2/super.o
fs/nilfs2/super.c: In function 'nilfs_resize_fs':
fs/nilfs2/super.c:376:2: warning: 'blocknr' may be used uninitialized in this function [-Wuninitialized]
fs/nilfs2/super.c:362:11: note: 'blocknr' was declared here
CC fs/nilfs2/recovery.o
fs/nilfs2/recovery.c: In function 'nilfs_salvage_orphan_logs':
fs/nilfs2/recovery.c:631:21: warning: 'sum' may be used uninitialized in this function [-Wuninitialized]
fs/nilfs2/recovery.c:585:32: note: 'sum' was declared here
fs/nilfs2/recovery.c: In function 'nilfs_search_super_root':
fs/nilfs2/recovery.c:873:11: warning: 'sum' may be used uninitialized in this function [-Wuninitialized]
Another similar warning is reported in
http://kisskb.ellerman.id.au/kisskb/buildresult/12520079/
CC fs/nilfs2/btree.o
fs/nilfs2/btree.c: In function 'nilfs_btree_convert_and_insert':
include/asm-generic/bitops/non-atomic.h:105:20: warning: 'bh' may be used uninitialized in this function [-Wuninitialized]
fs/nilfs2/btree.c:1859:22: note: 'bh' was declared here
This cleans out these warnings by forcing the variables to be initialized.
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
enabled. This might once have been OK in non-preemptible
configurations, but even in that case snd_seq_read() may sleep while
relying on a 'use' lock. So always use the proper implementations.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Andrey used the syzkaller fuzzer to find an out-of-bounds memory
access in usb_get_bos_descriptor(). The code wasn't checking that the
next usb_dev_cap_header structure could fit into the remaining buffer
space.
This patch fixes the error and also reduces the bNumDeviceCaps field
in the header to match the actual number of capabilities found, in
cases where there are fewer than expected.
Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The hid descriptor identifies the length and type of subordinate
descriptors for a device. If the received hid descriptor is smaller than
the size of the struct hid_descriptor, it is possible to cause
out-of-bounds.
In addition, if bNumDescriptors of the hid descriptor have an incorrect
value, this can also cause out-of-bounds while approaching hdesc->desc[n].
So check the size of hid descriptor and bNumDescriptors.
BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
Read of size 1 at addr ffff88006c5f8edf by task kworker/1:2/1261
projects / linux-stable / log