- 25 Feb, 2018 40 commits
-
-
Arnd Bergmann authored
commit fddbeb80 upstream. The mvumi scsi hides the references to its suspend/resume functions in an #ifdef but does not hide the implementation the same way: drivers/scsi/mvumi.c:2632:12: error: 'mvumi_suspend' defined but not used [-Werror=unused-function] drivers/scsi/mvumi.c:2651:12: error: 'mvumi_resume' defined but not used [-Werror=unused-function] This adds __maybe_unused annotations so the compiler knows it can silently drop them instead of warning, while avoiding the addition of another #ifdef. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Wagner authored
commit 206fc205 upstream. As the function name already indicates that get_opt_bool() parses for a bool. It is not a surprise that compiler is complaining about it when -Werror=incompatible-pointer-types is used: drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’: drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types] if (get_opt_bool(this_opt, "accel", &accel)) Signed-off-by:
Daniel Wagner <daniel.wagner@bmw-carit.de> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Arnd Bergmann authored
commit 5b833fea upstream. The sis framebuffer driver complains with a compile-time warning if neither the FB_SIS_300 nor FB_SIS_315 symbols are selected: drivers/video/fbdev/sis/sis_main.c:61:2: warning: #warning Neither CONFIG_FB_SIS_300 nor CONFIG_FB_SIS_315 is se This is reasonable because it doesn't work in that case, but it's also annoying for randconfig builds and is one of the most common warnings I'm seeing on ARM now. This changes the Kconfig logic to prevent the silly configuration, by always selecting the FB_SIS_300 variant if the other one is not set. Signed-off-by:
-
Arnd Bergmann authored
commit 9045a4a7 upstream. The rmi4 touchscreen driver encloses the power-management functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume functions are only really used when CONFIG_PM_SLEEP is also set, as a frequent gcc warning shows: ste_rmi4/synaptics_i2c_rmi4.c:1050:12: warning: 'synaptics_rmi4_suspend' defined but not used ste_rmi4/synaptics_i2c_rmi4.c:1084:12: warning: 'synaptics_rmi4_resume' defined but not used This changes the driver to remove the #ifdef and instead mark the functions as __maybe_unused, which is a nicer anyway, as it provides build testing for all the code in all configurations and is harder to get wrong. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Sudip Mukherjee authored
commit 32ad6195 upstream. The variables modeflag and resinfo were only assigned some value but were never used. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Arnd Bergmann authored
commit 120f83f8 upstream. The fdomain SCSI host driver is one of the last remaining drivers that manually search the PCI bus using pci_get_device rather than registering a pci_driver instance. This means the module device table is unused when the driver is built-in, and we get a warning about it: drivers/scsi/fdomain.c:1773:29: warning: 'fdomain_pci_tbl' defined but not used [-Wunused-variable] To avoid the warning, this adds another #ifdef around the table definition. Signed-off-by:
-
Arnd Bergmann authored
commit 28558f5a upstream. The seq_mpt_print_ioc_summary function is used for the /proc/mpt/iocN/summary implementation and never gets called when CONFIG_PROC_FS is disabled: drivers/message/fusion/mptbase.c:6851:13: warning: 'seq_mpt_print_ioc_summary' defined but not used [-Wunused-function] static void seq_mpt_print_ioc_summary(MPT_ADAPTER *ioc, struct seq_file *m, int showlan) This adds an #ifdef to hide the function definition in that case and avoid the warning. Signed-off-by:
-
Julia Lawall authored
commit e4106a7c upstream. Add __init attribute on functions that are only called from other __init functions and that are not inlined, at least with gcc version 4.8.4 on an x86 machine with allyesconfig. Currently, the functions are put in the .text.unlikely segment. Declaring them as __init will cause them to be put in the .init.text and to disappear after initialization. The result of objdump -x on the functions before the change is as follows: 00000000000001bc l F .text.unlikely 00000000000006a2 ck804xrom_init_one.isra.1 00000000000001aa l F .text.unlikely 0000000000000764 esb2rom_init_one.isra.1 00000000000001db l F .text.unlikely 0000000000000716 ichxrom_init_one.isra.1 And after the change it is as follows: 0000000000000000 l F .init.text 000000000000069d ck804xrom_init_one.isra.1 0000000000000000 l F .init.text 000000000000075f esb2rom_init_one.isra.1 0000000000000000 l F .init.text 0000000000000711 ichxrom_init_one.isra.1 Done with the help of Coccinelle. The semantic patch checks for local static non-init functions that are called from an __init function and are not called from any other function. Note that in each case, the function is stored in the probe field of a pci_driver structure, but this code is under an #if 0. The #if 0s have been unchanged since 2009 at the latest. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit e70dda08 upstream. pci_read_config_word() might fail and not initialize its output, as pointed out by older versions of gcc when using the -Wmaybe-unintialized flag: drivers/mtd/maps/ichxrom.c: In function ‘ichxrom_cleanup’: drivers/mtd/maps/ichxrom.c:63:2: error: ‘word’ is used uninitialized in this function [-Werror=uninitialized] This is apparently a correct warning, though it does not show up with newer compilers. Changing the code to not attempt to write back uninitialized data into PCI config space is a correct fix for the problem and avoids the warning. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Arnd Bergmann authored
commit 3312c951 upstream. When CONFIG_LBDAF is not set, sector_t is only 32-bits wide, which means we cannot have devices with more than 2TB, and the code that is trying to handle compatibility support for large devices in md version 0.90 is meaningless but also causes a compile-time warning: drivers/md/md.c: In function 'super_90_load': drivers/md/md.c:1029:19: warning: large integer implicitly truncated to unsigned type [-Woverflow] drivers/md/md.c: In function 'super_90_rdev_size_change': drivers/md/md.c:1323:17: warning: large integer implicitly truncated to unsigned type [-Woverflow] This adds a check for CONFIG_LBDAF to avoid even getting into this code path, and also adds an explicit cast to let the compiler know it doesn't have to warn about the truncation. Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
-
Arnd Bergmann authored
commit ade356b9 upstream. A couple of functions and variables in the profile implementation are used only on SMP systems by the procfs code, but are unused if either procfs is disabled or in uniprocessor kernels. gcc prints a harmless warning about the unused symbols: kernel/profile.c:243:13: error: 'profile_flip_buffers' defined but not used [-Werror=unused-function] static void profile_flip_buffers(void) ^ kernel/profile.c:266:13: error: 'profile_discard_flip_buffers' defined but not used [-Werror=unused-function] static void profile_discard_flip_buffers(void) ^ kernel/profile.c:330:12: error: 'profile_cpu_callback' defined but not used [-Werror=unused-function] static int profile_cpu_callback(struct notifier_block *info, ^ This adds further #ifdef to the file, to annotate exactly in which cases they are used. I have done several thousand ARM randconfig kernels with this patch applied and no longer get any warnings in this file. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Sudip Mukherjee authored
commit f50abb9b upstream. We were getting build warning about: drivers/scsi/dpt_i2o.c:183:29: warning: 'dptids' defined but not used dptids[] is only used in the MODULE_DEVICE_TABLE so when MODULE is not defined then dptids[] becomes unused. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Reviewed-by:
-
Fabian Frederick authored
commit cb4396ed upstream. Some eisa_driver structures used __init probe functions which generates a warning and could crash if function is called after being deleted. Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sudip Mukherjee authored
commit 648a0a7d upstream. We are getting build warning about: "Section mismatch in reference from the variable sim710_eisa_driver to the function .init.text:sim710_eisa_probe() The variable sim710_eisa_driver references the function __init sim710_eisa_probe()" sim710_eisa_probe() was having __init but that was being referenced from sim710_eisa_driver. Signed-off-by:
-
Arnd Bergmann authored
commit 553bbc11 upstream. The latest binutils are warning about a .fill directive with an explicit value in a .bss section: arch/x86/kernel/head_32.S: Assembler messages: arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned' arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned' This comes from the 'ENTRY()' macro padding the space between the symbols with 'nop' via: .align 4,0x90 Open-coding the .globl directive without the padding avoids that warning, as all the symbols are already page aligned. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
commit d612c64d upstream. The spear thermal driver hides its suspend/resume function conditionally based on CONFIG_PM, but references them based on CONFIG_PM_SLEEP, so we get a warning if the former is set but the latter is not: thermal/spear_thermal.c:58:12: warning: 'spear_thermal_suspend' defined but not used [-Wunused-function] thermal/spear_thermal.c:75:12: warning: 'spear_thermal_resume' defined but not used [-Wunused-function] This removes the #ifdef and instead uses a __maybe_uninitialized annotation to avoid the warning and improve compile-time coverage. Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit b7e2d195 upstream. The SoC variant of the ssb code is now optional like the other ones, which means we can build the framwork without any front-end, but that results in a warning: drivers/ssb/main.c:616:12: warning: 'ssb_bus_register' defined but not used [-Wunused-function] This annotates the ssb_bus_register function as __maybe_unused to shut up the warning. A configuration like this will not work on any hardware of course, but we still want this to silently build without warnings if the configuration is allowed in the first place. Signed-off-by:
Michael Buesch <m@bues.ch> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
commit ab494964 upstream. The latest gcc-7.0.1 snapshot warns about an unintialized variable use: In file included from fs/reiserfs/lbalance.c:8:0: fs/reiserfs/lbalance.c: In function 'leaf_item_bottle.isra.3': fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); ~~^~~ fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); This happens because the offset/type pair that is stored in ih.key.u.k_offset_v2 is actually uninitialized when we call set_le_ih_k_offset() and set_le_ih_k_type(). After we have called both, all data is correct, but the first of the two reads uninitialized data for the type field and writes it back before it gets overwritten. This works around the warning by initializing the k_offset_v2 through the slightly larger memcpy(). [JK: Remove now unused define and make it obvious we initialize the key] Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Arnd Bergmann authored
commit 46a049da upstream. gcc-7 caught what it considers a NULL pointer dereference: sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop': sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null expected [-Werror=nonnull] This is plausible from looking at the function, as we compare 'reply' to NULL earlier in it. I have not tried to analyze if there are constraints that make it impossible to hit the bug, but adding another NULL check in the end kills the warning and makes the function more robust. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kefeng Wang authored
commit 2e449048 upstream. Fix warning: "(COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)" Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Arnd Bergmann authored
commit 44a5b977 upstream. gcc-7.0.1 now warns about a previously unnoticed access of uninitialized struct members: drivers/scsi/advansys.c: In function 'AscMsgOutSDTR': drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]); ^ drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code has existed in this exact form at least since v2.6.12, and the warning seems correct. This uses named initializers to ensure we initialize all members of the structure. Signed-off-by:
-
Arnd Bergmann authored
commit d689c64d upstream. The IOSF_MBI option requires PCI support, without it we get a harmless Kconfig warning when it gets selected by PUNIT_ATOM_DEBUG: warning: (X86_INTEL_LPSS && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects IOSF_MBI which has unmet direct dependencies (PCI) This adds another dependency to avoid the warning. Signed-off-by:
-
Arnd Bergmann authored
commit c2ce3f5d upstream. KVM tries to select 'TASKSTATS', which had additional dependencies: warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER) Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
commit 68fd77cf upstream. We get a Kconfig warning when selecting this without also enabling CONFIG_PCI: warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects IOSF_MBI which has unmet direct dependencies (PCI) This adds a new depedency. Fixes: 3a2419f8 ("Thermal: Intel SoC: DTS thermal use common APIs") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit d460131d upstream. Every kernel build on x86 will result in some output: Setup is 13084 bytes (padded to 13312 bytes). System is 4833 kB CRC 6d35fa35 Kernel: arch/x86/boot/bzImage is ready (#2) This shuts it up, so that 'make -s' is truely silent as long as everything works. Building without '-s' should produce unchanged output. Signed-off-by:
-
Josh Poimboeuf authored
commit e572d088 upstream. When doing a kernel build with 'make -s', everything is silenced except the objtool build. That's because the tools tree support for silent builds is some combination of missing and broken. Three changes are needed to fix it: - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the tools Makefiles can see it. - tools/scripts/Makefile.include: fix the tools Makefiles' ability to recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences the "DESCEND objtool" message. - tools/build/Makefile.build: add support to the tools Build files for recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences all the object compile/link messages. Reported-and-Tested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Michal Marek <mmarek@suse.com> Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
commit 75e2f0a6 upstream. When building the kernel with "make EXTRA_CFLAGS=...", this overrides the "PARANOID" preprocessor macro defined in arch/x86/math-emu/Makefile, and we run into a build warning: arch/x86/math-emu/reg_compare.c: In function ‘compare_i_st_st’: arch/x86/math-emu/reg_compare.c:254:6: error: ‘f’ may be used uninitialized in this function [-Werror=maybe-uninitialized] This fixes the implementation to work correctly even without the PARANOID flag, and also fixes the Makefile to not use the EXTRA_CFLAGS variable but instead use the ccflags-y variable in the Makefile that is meant for this purpose. Signed-off-by:
-
Arnd Bergmann authored
commit f13d52cb upstream. This mirrors commit e9c38ceb ("ARM: 8455/1: define __BUG as asm(BUG_INSTR) without CONFIG_BUG") to make the behavior of arm64 consistent with arm and x86, and avoids lots of warnings in randconfig builds, such as: kernel/seccomp.c: In function '__seccomp_filter': kernel/seccomp.c:666:1: error: no return statement in function returning non-void [-Werror=return-type] Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Borislav Petkov authored
commit d4b2ac63 upstream. ... and get rid of the annoying: arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function] when doing randconfig builds. Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Yazen Ghannam <Yazen.Ghannam@amd.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170123183514.13356-2-bp@alien8.deSigned-off-by:
-
Arnd Bergmann authored
commit f46e7cd3 upstream. The advansys probe function tries to handle both ISA and PCI cases, each hidden in an #ifdef when unused. This leads to a warning indicating that when PCI is disabled we could be using uninitialized data: drivers/scsi/advansys.c: In function advansys_board_found : drivers/scsi/advansys.c:11036:5: error: ret may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:28: note: ret was declared here drivers/scsi/advansys.c:11309:8: error: share_irq may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:6: note: share_irq was declared here This cannot happen in practice because the hardware in question only exists for PCI, but changing the code to just error out here is better for consistency and avoids the warning. Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Arnd Bergmann authored
commit 484c7bbf upstream. When CONFIG_PROC_FS is disabled, we get warnings about unused variables as remove_proc_entry() evaluates to an empty macro. drivers/video/fbdev/via/viafbdev.c: In function 'viafb_remove_proc': drivers/video/fbdev/via/viafbdev.c:1635:4: error: unused variable 'iga2_entry' [-Werror=unused-variable] drivers/video/fbdev/via/viafbdev.c:1634:4: error: unused variable 'iga1_entry' [-Werror=unused-variable] These are easy to avoid by using the pointer from the structure. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Borislav Petkov authored
commit b4aca383 upstream. Fix: drivers/platform/x86/intel_mid_thermal.c:424:12: warning: ‘mid_thermal_resume’ defined but not used [-Wunused-function] static int mid_thermal_resume(struct device *dev) ^ drivers/platform/x86/intel_mid_thermal.c:436:12: warning: ‘mid_thermal_suspend’ defined but not used [-Wunused-function] static int mid_thermal_suspend(struct device *dev) ^ which I see during randbuilds here. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Augusto Mecking Caringi authored
commit fbc2a294 upstream. The only usage of function intel_gpio_runtime_idle() is here (in the same file): static const struct dev_pm_ops intel_gpio_pm_ops = { SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle) }; And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to nothing, causing the following compiler warning: drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’ defined but not used [-Wunused-function] static int intel_gpio_runtime_idle(struct device *dev) Fix it by annotating the function with __maybe_unused. Signed-off-by:
Augusto Mecking Caringi <augustocaringi@gmail.com> Acked-by:
-
Arnd Bergmann authored
commit fbdf0e28 upstream. I got a warning about broken code on ARM64 with 64K pages: drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_rq_init': drivers/net/vmxnet3/vmxnet3_drv.c:1679:29: error: large integer implicitly truncated to unsigned type [-Werror=overflow] rq->buf_info[0][i].len = PAGE_SIZE; 'len' here is a 16-bit integer, so this clearly won't work. I don't think this driver is used much on anything other than x86, so there is no need to fix this properly and we can work around it with a Kconfig dependency to forbid known-broken configurations. qemu in theory supports it on other architectures too, but presumably only for compatibility with x86 guests that also run on vmware. CONFIG_PAGE_SIZE_64KB is used on hexagon, mips, sh and tile, the other symbols are architecture-specific names for the same thing. Signed-off-by:
-
Arnd Bergmann authored
commit 01ed1e15 upstream. The icn driver currently produces an unconditional #warning whenever we build it, introduced by Karsten Keil back in 2003: #warning TODO test headroom or use skb->nb to flag ACK Karsten's original commit (from BitKeeper) contains this description: - here are lot of bugs left, so ISDN is not stable yet but I think it's really time to fix it, even if it need some cycles to get it right (normally I'm only send patches if it works 100% for me). - I add some additional #warnings to address places which need fixing (I hope that some of the other ISDN developer jump in) Apparently this has not happened, and it is unlikely that it ever will, given that the driver doesn't seem to work. No substantial bug fixes other than janitorial cleanups have happened in the driver since then, and I see no indication that anyone who patched it had the hardware. We should probably either remove the driver, or remove all of i4l, but for now, this shuts up the distracting #warning by turning it into a comment. Signed-off-by:
-
Arnd Bergmann authored
commit f0bb2d50 upstream. The latest gcc-7.0.1 snapshot reports a new warning: virtio/virtio_balloon.c: In function 'update_balloon_stats': virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:260:26: error: 'events[3]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:261:56: error: 'events[18]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:262:56: error: 'events[17]' is used uninitialized in this function [-Werror=uninitialized] This seems absolutely right, so we should add an extra check to prevent copying uninitialized stack data into the statistics. >From all I can tell, this has been broken since the statistics code was originally added in 2.6.34. Fixes: 9564e138 ("virtio: Add memory statistics reporting to the balloon driver (V4)") Signed-off-by:
Ladi Prosek <lprosek@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit 6e266610 ] The driver may sleep under a spinlock. The function call path is: rr_close (acquire the spinlock) free_irq --> may sleep To fix it, free_irq is moved to the place without holding the spinlock. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by:
Jia-Ju Bai <baijiaju1990@163.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Jan Beulich authored
[ Upstream commit c4f9d9cb ] Add a respective dependency. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Karol Herbst authored
[ Upstream commit 6d60ce38 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap() the address passed to unregister_kmmio_probe() was PAGE_SIZE aligned by the caller leading to a complete freeze of the machine. We should always page align addresses while (un)registerung mappings, because the mmiotracer works on top of pages, not mappings. We still keep track of the probes based on their real addresses and lengths though, because the mmiotrace still needs to know what are mapped memory regions. Also move the call to mmiotrace_iounmap() prior page aligning the address, so that all probes are unregistered properly, otherwise the kernel ends up failing memory allocations randomly after disabling the mmiotracer. Tested-by:
Lyude <lyude@redhat.com> Signed-off-by:
Karol Herbst <kherbst@redhat.com> Acked-by:
Pekka Paalanen <ppaalanen@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: nouveau@lists.freedesktop.org Link: http://lkml.kernel.org/r/20171127075139.4928-1-kherbst@redhat.comSigned-off-by:
-
Dave Young authored
[ Upstream commit 7f6f60a1 ] earlyprintk=efi,keep does not work any more with a warning in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING): Boot just hangs because of the earlyprintk within the earlyprintk implementation code itself. This is caused by a new introduced middle state in: 69a78ff2 ("init: Introduce SYSTEM_SCHEDULING state") early_ioremap() is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING states, original condition should be updated accordingly. Signed-off-by:
Dave Young <dyoung@redhat.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: bp@suse.de Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20171209041610.GA3249@dhcp-128-65.nay.redhat.comSigned-off-by:
-
