- 28 7月, 2017 12 次提交
-
-
由 Arnd Bergmann 提交于
We get a link error trying to access the w100fb_gpio_read/write functions from the platform when the driver is a loadable module or not built-in, so the platform already uses 'select' to hard-enable the driver. However, that fails if the framebuffer subsystem is disabled altogether. I've considered various ways to fix this properly, but they all seem like too much work or too risky, so this simply adds another 'select' to force the subsystem on as well. Fixes: 82427de2 ("ARM: pxa: PXA_ESERIES depends on FB_W100.") Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
An empty macro definition can cause unexpected behavior, in case of the ixp4xx ioport_unmap, we get two warnings: drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release': drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] ioport_unmap(card->iobase); drivers/vfio/pci/vfio_pci_rdwr.c: In function 'vfio_pci_vga_rw': drivers/vfio/pci/vfio_pci_rdwr.c:230:15: error: the omitted middle operand in ?: will always be 'true', suggest explicit middle operand [-Werror=parentheses] is_ioport ? ioport_unmap(iomem) : iounmap(iomem); This uses an inline function to define the macro in a safer way. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NKrzysztof Halasa <khalasa@piap.pl>
-
由 Arnd Bergmann 提交于
Just like ARCH_MULTIPLATFORM, we want to use ARM_PATCH_PHYS_VIRT when possible, but that fails for NOMMU or XIP_KERNEL configurations. Using 'imply' instead of 'select' gets this right and only uses the symbol when we don't have to hardcode the address anyway. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com>
-
由 Arnd Bergmann 提交于
This variable may be used by some devices that each have their on Kconfig symbol, or by none of them, and that causes a build warning: arch/arm/mach-mmp/devices.c:241:12: error: 'usb_dma_mask' defined but not used [-Werror=unused-variable] Marking it __maybe_unused avoids the warning. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
The omap_generic_init() and omap_hwmod_init_postsetup() functions are used in the initialization for all OMAP2+ SoC types, but in the extreme case that those are all disabled, we get a warning about unused code: arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function] arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function] This annotates both as __maybe_unused to shut up that warning. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NTony Lindgren <tony@atomide.com> Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
-
由 Arnd Bergmann 提交于
The osk_mistral_init() contains code that is only compiled when CONFIG_PM is set, but it uses a variable that is declared outside of the #ifdef: arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init': arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable] This removes the #ifdef around the user of the variable, make it always used. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Suggested-by: NTony Lindgren <tony@atomide.com> Acked-by: NAaro Koskinen <aaro.koskinen@iki.fi>
-
由 Arnd Bergmann 提交于
sirfsoc_init_late is called by each of the three individual SoC definitions, but in a randconfig build, we can encounter a situation where they are all disabled: arch/arm/mach-prima2/common.c:18:123: warning: 'sirfsoc_init_late' defined but not used [-Wunused-function] While that is not a useful configuration, the warning also doesn't help, so this patch marks the function as __maybe_unused to let the compiler know it is there intentionally. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
ixp4xx defines the arguments to its __indirect_writesb() and other functions as pointers to fixed-size data. This is not necessarily wrong, and it works most of the time, but it causes warnings in at least one driver: drivers/net/ethernet/smsc/smc91x.c: In function 'smc_rcv': drivers/net/ethernet/smsc/smc91x.c:495:21: error: passing argument 2 of '__indirect_readsw' from incompatible pointer type [-Werror=incompatible-pointer-types] SMC_PULL_DATA(lp, data, packet_len - 4); All other definitions of the same functions pass void pointers, so doing the same here avoids the warnings. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NKrzysztof Halasa <khalasa@piap.pl>
-
由 Arnd Bergmann 提交于
The modem pm handler in the ams-delta board uses regulator_enable() but does not check for a successful return code: board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result] It is not easy to propagate that return code to the callers in uart_configure_port/uart_suspend_port/uart_resume_port, unless we change all UART drivers, and it is unclear what those would do with the return code. Instead, this patch uses a runtime warning to replace the compiletime warning. I have checked that the regulator in question is hardcoded to a fixed-voltage GPIO regulator, and that should never fail to get enabled if I understand the code right. Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NAaro Koskinen <aaro.koskinen@iki.fi> Link: https://patchwork.kernel.org/patch/8391981/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
The RAM_SIZE macro in mach/hardware.h conflicts with macros of the same name in multiple drivers, leading to annoying build warnings: In file included from drivers/net/ethernet/cirrus/cs89x0.c:79:0: drivers/net/ethernet/cirrus/cs89x0.h:324:0: error: "RAM_SIZE" redefined [-Werror] #define RAM_SIZE 0x1000 /* The card has 4k bytes or RAM */ ^ In file included from /git/arm-soc/arch/arm/mach-rpc/include/mach/io.h:16:0, from /git/arm-soc/arch/arm/include/asm/io.h:194, from /git/arm-soc/include/linux/scatterlist.h:8, from /git/arm-soc/include/linux/dmaengine.h:24, from /git/arm-soc/include/linux/netdevice.h:38, from /git/arm-soc/drivers/net/ethernet/cirrus/cs89x0.c:54: arch/arm/mach-rpc/include/mach/hardware.h:28:0: note: this is the location of the previous definition #define RAM_SIZE 0x10000000 We don't use RAM_SIZE/RAM_START at all, so we could just remove them, but it might be nice to leave them for documentation purposes, so this renames them to RPC_RAM_SIZE/RPC_RAM_START in order to avoid the build warnings Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
w90x900 still provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent or clk_round_rate functions when a platform lacks those interfaces. This adds empty stub implementations for each of them, and I don't even try to do something useful here but instead just print a WARN() message to make it obvious what is going on if they ever end up being called. The drivers that call these won't be used on these platforms (otherwise we'd get a link error today), so the added code is harmless bloat and will warn about accidental use. A while ago there was a proposal to change w90x900 to use the common-clk implementation, which would be the way it should be handled properly. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Alexander Sverdlin 提交于
It's a combination of the patch from Arnd Bergmann, which added empty stubs for clk_round_rate() and clk_set_parent() and a working trivial implementation of clk_get_parent(). The later is required for ADC driver. Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 27 7月, 2017 5 次提交
-
-
由 Arnd Bergmann 提交于
sa1100 provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent or clk_round_rate functions when a platform lacks those interfaces. This adds trivial stub implementations for each of them, based on the behavior of the COMMON_CLK implementation: - set_rate() and set_parent() report success without doing anything - round_rate() returns the clk rate - get_parent() returns NULL. This adds the minimal bloat and should do the right thing for the simple clock hardware in this SoC. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
davinci still has its own clk implementation, but lacks a clk_get_parent() helper, which can lead to link errors in randconfig builds. This adds the usual implementation. Acked-by: NSekhar Nori <nsekhar@ti.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
In commit 3169663a "ARM: sa11x0/pxa: convert OS timer registers to IOMEM", the definition of the OSCR macro was changed to be an __iomem pointer, but the same register is also used by the XIP code. This patch does the corresponding change here as well. On PXA, the IRQ register definitions were removed even earlier, in commit 5d284e35 ("ARM: pxa: avoid accessing interrupt registers directly"). This patch unfortunately brings some of that back. An earlier version of my patch moved the code into an external function, which could not work for CONFIG_XIP_KERNEL+CONFIG_MTD_XIP, so this restores something close to the original code. Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241716.htmlAcked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
A change to the platform data definitions caused a warning in the board code: arch/arm/mach-davinci/board-da850-evm.c:1221:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] arch/arm/mach-davinci/board-da850-evm.c:1231:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] This is a bit unfortunate, since we generally like structure definitions to be const, but as this is legacy code, the easiest way out is still to remove the 'const' annotation here. Fixes: 4a5f8ae5 ("[media] davinci: vpif_capture: get subdevs from DT when available") Fixes: 231ce279 ("ARM: davinci: fix const warnings") Acked-by: NSekhar Nori <nsekhar@ti.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Krzysztof Kozlowski 提交于
Add necessary parent clocks for audss (Audio SubSystem, MAUDIO) clock controller block. This allows driver to keep EPLL enabled before accessing any MAUDIO registers thus fixing silent hang. This silent hang appeared with commit 6edfa11c ("clk: samsung: Add enable/disable operation for PLL36XX clocks"), e.g. on Odroid U3 usually with last (but unrelated) messages: [ 2.382741] input: gpio_keys as /devices/platform/gpio_keys/input/input0 [ 2.405686] usb 1-3: new high-speed USB device number 3 using exynos-ehci [ 2.419843] max77686-rtc max77686-rtc: setting system clock to 2017-06-21 17:04:13 UTC (1498064653) Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 23 7月, 2017 2 次提交
-
-
由 Juergen Gross 提交于
Commit dc6416f1 ("xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()") introduced an error leading to a stack overflow of the idle task when a cpu was brought offline/online many times: by calling cpu_startup_entry() instead of returning at the end of xen_play_dead() do_idle() would be entered again and again. Don't use cpu_startup_entry(), but cpuhp_online_idle() instead allowing to return from xen_play_dead(). Cc: <stable@vger.kernel.org> # 4.12 Signed-off-by: NJuergen Gross <jgross@suse.com> Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: NJuergen Gross <jgross@suse.com>
-
由 Vitaly Kuznetsov 提交于
CONFIG_BOOTPARAM_HOTPLUG_CPU0 allows to offline CPU0 but Xen HVM guests BUG() in xen_teardown_timer(). Remove the BUG_ON(), this is probably a leftover from ancient times when CPU0 hotplug was impossible, it works just fine for HVM. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Acked-by: NJuergen Gross <jgross@suse.com> Signed-off-by: NJuergen Gross <jgross@suse.com>
-
- 21 7月, 2017 4 次提交
-
-
由 Rob Herring 提交于
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each device node. Signed-off-by: NRob Herring <robh@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: devicetree@vger.kernel.org Link: http://lkml.kernel.org/r/20170718214339.7774-7-robh@kernel.org [ Clarify the error message while at it, as 'node' is ambiguous. ] Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Jiri Olsa 提交于
We have 2 functions using the same sched_task callback: - PEBS drain for free running counters - LBR save/store Both of them are called from intel_pmu_sched_task() and either of them can be unwillingly triggered when the other one is configured to run. Let's say there's PEBS drain configured in sched_task callback for the event, but in the callback itself (intel_pmu_sched_task()) we will also run the code for LBR save/restore, which we did not ask for, but the code in intel_pmu_sched_task() does not check for that. This can lead to extra cycles in some perf monitoring, like when we monitor PEBS event without LBR data. # perf record --no-timestamp -c 10000 -e cycles:p ./perf bench sched pipe -l 1000000 (We need PEBS, non freq/non timestamp event to enable the sched_task callback) The perf stat of cycles and msr:write_msr for above command before the change: ... Performance counter stats for './perf record --no-timestamp -c 10000 -e cycles:p \ ./perf bench sched pipe -l 1000000' (5 runs): 18,519,557,441 cycles:k 91,195,527 msr:write_msr 29.334476406 seconds time elapsed And after the change: ... Performance counter stats for './perf record --no-timestamp -c 10000 -e cycles:p \ ./perf bench sched pipe -l 1000000' (5 runs): 18,704,973,540 cycles:k 27,184,720 msr:write_msr 16.977875900 seconds time elapsed There's no affect on cycles:k because the sched_task happens with events switched off, however the msr:write_msr tracepoint counter together with almost 50% of time speedup show the improvement. Monitoring LBR event and having extra PEBS drain processing in sched_task callback showed just a little speedup, because the drain function does not do much extra work in case there is no PEBS data. Adding conditions to recognize the configured work that needs to be done in the x86_pmu's sched_task callback. Suggested-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NJiri Olsa <jolsa@kernel.org> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Kan Liang <kan.liang@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Link: http://lkml.kernel.org/r/20170719075247.GA27506@kravaSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andrew Banman 提交于
The BAU confers no benefit to a UV system running with only one hub/socket. Permanently disable the BAU driver if there are less than two hubs online to avoid BAU overhead. We have observed failed boots on single-socket UV4 systems caused by BAU that are avoided with this patch. Also, while at it, consolidate initialization error blocks and fix a memory leak. Signed-off-by: NAndrew Banman <abanman@hpe.com> Acked-by: NRuss Anderson <rja@hpe.com> Acked-by: NMike Travis <mike.travis@hpe.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: tony.ernst@hpe.com Link: http://lkml.kernel.org/r/1500588351-78016-1-git-send-email-abanman@hpe.com [ Minor cleanups. ] Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Linus Torvalds 提交于
They really are, and the "take the address of a single character" makes the string fortification code unhappy (it believes that you can now only acccess one byte, rather than a byte range, and then raises errors for the memory copies going on in there). We could now remove a few 'addressof' operators (since arrays naturally degrade to pointers), but this is the minimal patch that just changes the C prototypes of those template arrays (the templates themselves are defined in inline asm). Reported-by: Nkernel test robot <xiaolong.ye@intel.com> Acked-and-tested-by: NMasami Hiramatsu <mhiramat@kernel.org> Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 7月, 2017 13 次提交
-
-
由 Roman Kagan 提交于
If the SynIC timer message delivery fails due to SINT message slot being busy, there's no point to attempt starting the timer again until we're notified of the slot being released by the guest (via EOM or EOI). Even worse, when a oneshot timer fails to deliver its message, its re-arming with an expiration time in the past leads to immediate retry of the delivery, and so on, without ever letting the guest vcpu to run and release the slot, which results in a livelock. To avoid that, only start the timer when there's no timer message pending delivery. When there is, meaning the slot is busy, the processing will be restarted upon notification from the guest that the slot is released. Signed-off-by: NRoman Kagan <rkagan@virtuozzo.com> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
-
由 Wanpeng Li 提交于
This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries to emulate invalid guest state task-switch: kvm_exit: reason TASK_SWITCH rip 0x0 info 40000058 0 kvm_emulate_insn: 42000:0:0f 0b (0x2) kvm_emulate_insn: 42000:0:0f 0b (0x2) failed kvm_inj_exception: #UD (0x0) kvm_entry: vcpu 0 kvm_exit: reason TASK_SWITCH rip 0x0 info 40000058 0 kvm_emulate_insn: 42000:0:0f 0b (0x2) kvm_emulate_insn: 42000:0:0f 0b (0x2) failed kvm_inj_exception: #UD (0x0) ...................... It appears that the task-switch emulation updates rflags (and vm86 flag) only after the segments are loaded, causing vmx->emulation_required to be set, when in fact invalid guest state emulation is not needed. This patch fixes it by updating vmx->emulation_required after the rflags (and vm86 flag) is updated in task-switch emulation. Thanks Radim for moving the update to vmx__set_flags and adding Paolo's suggestion for the check. Suggested-by: NNadav Amit <nadav.amit@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Nadav Amit <nadav.amit@gmail.com> Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
-
由 Josh Poimboeuf 提交于
Mike Galbraith reported a situation where a WARN_ON_ONCE() call in DRM code turned into an oops. As it turns out, WARN_ON_ONCE() seems to be completely broken when called from a module. The bug was introduced with the following commit: 19d43626 ("debug: Add _ONCE() logic to report_bug()") That commit changed WARN_ON_ONCE() to move its 'once' logic into the bug trap handler. It requires a writable bug table so that the BUGFLAG_DONE bit can be written to the flags to indicate the first warning has occurred. The bug table was made writable for vmlinux, which relies on vmlinux.lds.S and vmlinux.lds.h for laying out the sections. However, it wasn't made writable for modules, which rely on the ELF section header flags. Reported-by: NMike Galbraith <efault@gmx.de> Tested-by: NMasami Hiramatsu <mhiramat@kernel.org> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 19d43626 ("debug: Add _ONCE() logic to report_bug()") Link: http://lkml.kernel.org/r/a53b04235a65478dd9afc51f5b329fdc65c84364.1500095401.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Arnd Bergmann 提交于
We have space for exactly three characters for the index in "max7315_%d_base", but as GCC points out having more would cause an string overflow: arch/x86/platform/intel-mid/device_libs/platform_max7315.c: In function 'max7315_platform_data': arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:26: error: '%d' directive writing between 1 and 11 bytes into a region of size 9 [-Werror=format-overflow=] sprintf(base_pin_name, "max7315_%d_base", nr); ^~~~~~~~~~~~~~~~~ arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:26: note: directive argument in the range [-2147483647, 2147483647] arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:3: note: 'sprintf' output between 15 and 25 bytes into a destination of size 17 sprintf(base_pin_name, "max7315_%d_base", nr); This makes it use an snprintf() to truncate the string if that happened rather than overflowing the stack. In practice, this is safe, because there won't be a large number of max7315 devices in the systems, and both the format and the length are defined by the firmware interface. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170719125310.2487451-9-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Arnd Bergmann 提交于
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: NArnd Bergmann <arnd@arndb.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170719125310.2487451-8-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Arnd Bergmann 提交于
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: NArnd Bergmann <arnd@arndb.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170719125310.2487451-6-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Arnd Bergmann 提交于
The x86 version of insb/insw/insl uses an inline assembly that does not have the target buffer listed as an output. This can confuse the compiler, leading it to think that a subsequent access of the buffer is uninitialized: drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’: drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized] drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/net/sb1000.c: In function 'sb1000_rx': drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized] drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized] I tried to mark the exact input buffer as an output here, but couldn't figure it out. As suggested by Linus, marking all memory as clobbered however is good enough too. For the outs operations, I also add the memory clobber, to force the input to be written to local variables. This is probably already guaranteed by the "asm volatile", but it can't hurt to do this for symmetry. Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Cc: Borislav Petkov <bp@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de Link: https://lkml.org/lkml/2017/7/12/605Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Arnd Bergmann 提交于
gcc-7.1.1 produces this warning: arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add': arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: using integer constants in boolean context [-Werror=int-in-bool-context] This appears to be a bug in gcc-7.1.1, and I have reported it as PR81484. The compiler suggests that code written as if (a & b ? c : d) is usually incorrect and should have been if (a & (b ? c : d)) However, in this case, we correctly write if ((a & b) ? c : d) and should not get a warning for it. This adds a dirty workaround for the problem, adding a comparison with zero inside of the macro. The warning is currently disabled in the kernel, so we may decide not to apply the patch, and instead wait for future gcc releases to fix the problem. On the other hand, it seems to be the only instance of this particular problem. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Bill Metzenthen <billm@melbpc.org.au> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170719125310.2487451-4-arnd@arndb.de Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Arnd Bergmann 提交于
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: NArnd Bergmann <arnd@arndb.de> Cc: Bill Metzenthen <billm@melbpc.org.au> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170719125310.2487451-3-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Arnd Bergmann 提交于
The intialization function checks for various failure scenarios, but unfortunately the compiler gets a little confused about the possible combinations, leading to a false-positive build warning when -Wmaybe-uninitialized is set: arch/x86/events/core.c: In function ‘init_hw_perf_events’: arch/x86/events/core.c:264:3: warning: ‘reg_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized] arch/x86/events/core.c:264:3: warning: ‘val_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized] pr_err(FW_BUG "the BIOS has corrupted hw-PMU resources (MSR %x is %Lx)\n", We can't actually run into this case, so this shuts up the warning by initializing the variables to a known-invalid state. Suggested-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170719125310.2487451-2-arnd@arndb.de Link: https://patchwork.kernel.org/patch/9392595/Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Krzysztof Kozlowski 提交于
Remove old, dead Kconfig options (in order appearing in this commit): - EXPERIMENTAL is gone since v3.9; - IP_NF_TARGET_ULOG: commit d4da843e ("netfilter: kill remnants of ulog targets"); - USB_LIBUSUAL: commit f61870ee ("usb: remove libusual"); Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1500526885-4341-1-git-send-email-krzk@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Seunghun Han 提交于
One of the rarely executed code pathes in check_timer() calls unmask_ioapic_irq() passing irq_get_chip_data(0) as argument. That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of interrupt 0. irq_get_chip_data(0) returns NULL, so the following dereference in unmask_ioapic_irq() causes a kernel panic. The issue went unnoticed in the first place because irq_get_chip_data() returns a void pointer so the compiler cannot do a type check on the argument. The code path was added for machines with broken configuration, but it seems that those machines are either not running current kernels or simply do not longer exist. Hand in irq_get_irq_data(0) as argument which provides the correct data. [ tglx: Rewrote changelog ] Fixes: 4467715a ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c") Signed-off-by: NSeunghun Han <kkamagui@gmail.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkamagui@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Seunghun Han 提交于
The bus_irq argument of mp_override_legacy_irq() is used as the index into the isa_irq_to_gsi[] array. The bus_irq argument originates from ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI tables, but is nowhere sanity checked. That allows broken or malicious ACPI tables to overwrite memory, which might cause malfunction, panic or arbitrary code execution. Add a sanity check and emit a warning when that triggers. [ tglx: Added warning and rewrote changelog ] Signed-off-by: NSeunghun Han <kkamagui@gmail.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: security@kernel.org Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: stable@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 19 7月, 2017 4 次提交
-
-
由 Arnd Bergmann 提交于
KVM tries to select 'TASKSTATS', which had additional dependencies: warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER) Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
-
由 Jim Mattson 提交于
Immediately following MOV-to-SS/POP-to-SS, VM-entry is disallowed. This check comes after the check for a valid VMCS. When this check fails, the instruction pointer should fall through to the next instruction, the ALU flags should be set to indicate VMfailValid, and the VM-instruction error should be set to 26 ("VM entry with events blocked by MOV SS"). Signed-off-by: NJim Mattson <jmattson@google.com> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
-
由 Paolo Bonzini 提交于
vmx_recover_nmi_blocking is using a cached value of the guest interruptibility info, which is stored in vmx->nmi_known_unmasked. vmx_recover_nmi_blocking is run for both normal and nested guests, so the cached value must be per-VMCS. This fixes eventinj.flat in a nested non-EPT environment. With EPT it works, because the EPT violation handler doesn't have the vmx->nmi_known_unmasked optimization (it is unnecessary because, unlike vmx_recover_nmi_blocking, it can just look at the exit qualification). Thanks to Wanpeng Li for debugging the testcase and providing an initial patch. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
-
由 Dan Carpenter 提交于
kvm_read_cr3() returns an unsigned long and gfn is a u64. We intended to mask out the bottom 5 bits but because of the type issue we mask the top 32 bits as well. I don't know if this is a real problem, but it causes static checker warnings. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
-