- 19 May, 2016 11 commits
-
-
Ben Hutchings authored
[ Upstream commit f43bfaed ] atl2 includes NETIF_F_SG in hw_features even though it has no support for non-linear skbs. This bug was originally harmless since the driver does not claim to implement checksum offload and that used to be a requirement for SG. Now that SG and checksum offload are independent features, if you explicitly enable SG *and* use one of the rare protocols that can use SG without checkusm offload, this potentially leaks sensitive information (before you notice that it just isn't working). Therefore this obscure bug has been designated CVE-2016-2117. Reported-by:
Justin Yackoski <jyackoski@crypto-nite.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Fixes: ec5f0615 ("net: Kill link between CSUM and SG features.") Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mathias Krause authored
[ Upstream commit 309cf37f ] Because we miss to wipe the remainder of i->addr[] in packet_mc_add(), pdiag_put_mclist() leaks uninitialized heap bytes via the PACKET_DIAG_MCLIST netlink attribute. Fix this by explicitly memset(0)ing the remaining bytes in i->addr[]. Fixes: eea68e2f ("packet: Report socket mclist info via diag module") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@parallels.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
-
Chris Friesen authored
[ Upstream commit d6d5e999 ] For local routes that require a particular output interface we do not want to cache the result. Caching the result causes incorrect behaviour when there are multiple source addresses on the interface. The end result being that if the intended recipient is waiting on that interface for the packet he won't receive it because it will be delivered on the loopback interface and the IP_PKTINFO ipi_ifindex will be set to the loopback interface as well. This can be tested by running a program such as "dhcp_release" which attempts to inject a packet on a particular interface so that it is received by another program on the same board. The receiving process should see an IP_PKTINFO ipi_ifndex value of the source interface (e.g., eth1) instead of the loopback interface (e.g., lo). The packet will still appear on the loopback interface in tcpdump but the important aspect is that the CMSG info is correct. Sample dhcp_release command line: dhcp_release eth1 192.168.204.222 02:11:33:22:44:66 Signed-off-by:
Allain Legacy <allain.legacy@windriver.com> Signed off-by: Chris Friesen <chris.friesen@windriver.com> Reviewed-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
-
David S. Miller authored
[ Upstream commit a36a0d40 ] In particular, make sure we check for decnet private presence for loopback devices. Signed-off-by:
-
Tony Lindgren authored
commit d8a50941 upstream. We get a NULL pointer dereference on omap3 for thumb2 compiled kernels: Internal error: Oops: 80000005 [#1] SMP THUMB2 ... [<c046497b>] (_raw_spin_unlock_irqrestore) from [<c0024375>] (omap3_enter_idle_bm+0xc5/0x178) [<c0024375>] (omap3_enter_idle_bm) from [<c0374e63>] (cpuidle_enter_state+0x77/0x27c) [<c0374e63>] (cpuidle_enter_state) from [<c00627f1>] (cpu_startup_entry+0x155/0x23c) [<c00627f1>] (cpu_startup_entry) from [<c06b9a47>] (start_kernel+0x32f/0x338) [<c06b9a47>] (start_kernel) from [<8000807f>] (0x8000807f) The power management related assembly on omaps needs to interact with ARM mode bootrom code, so we need to keep most of the related assembly in ARM mode. Turns out this error is because of missing ENDPROC for assembly code as suggested by Stephen Boyd <sboyd@codeaurora.org>. Let's fix the problem by adding ENDPROC in two places to sleep34xx.S. Let's also remove the now duplicate custom code for mode switching. This has been unnecessary since commit 6ebbf2ce ("ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+"). And let's also remove the comments about local variables, they are now just confusing after the ENDPROC. The reason why ENDPROC makes a difference is it sets .type and then the compiler knows what to do with the thumb bit as explained at: https://wiki.ubuntu.com/ARM/Thumb2PortingHowtoReported-by:
Kevin Hilman <khilman@kernel.org> Tested-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Daniel Vetter authored
commit 2700818a upstream. LPT is pch, so might run into the fdi bandwidth constraint (especially since it has only 2 lanes). But right now we just force pipe_bpp back to 24, resulting in a nice loop (which we bail out with a loud WARN_ON). Fix this. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=93477Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch (cherry picked from commit f58a1acc) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Lucas Stach authored
commit e3c00d87 upstream. On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not be taken into consideration when looking for an already enabled PLL to be shared with other outputs. This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland based laptop, where the internal display is connected to UNIPHYA through a TRAVIS DP->LVDS bridge. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78987 v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop extra parameter. Signed-off-by:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Andi Kleen authored
commit a99aa42d upstream. Mark variables referenced from assembler files visible. This fixes compile problems with LTO. Cc: Jaroslav Kysela <perex@perex.cz> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/1391845930-28580-4-git-send-email-ak@linux.intel.comSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by:
-
Marek Szyprowski authored
commit 6ae645d5 upstream. NULL pointer derefence happens when booting with DTB because the platform data for haptic device is not set in supplied data from parent MFD device. The MFD device creates only platform data (from Device Tree) for itself, not for haptic child. Unable to handle kernel NULL pointer dereference at virtual address 0000009c pgd = c0004000 [0000009c] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM (max8997_haptic_probe) from [<c03f9cec>] (platform_drv_probe+0x4c/0xb0) (platform_drv_probe) from [<c03f8440>] (driver_probe_device+0x214/0x2c0) (driver_probe_device) from [<c03f8598>] (__driver_attach+0xac/0xb0) (__driver_attach) from [<c03f67ac>] (bus_for_each_dev+0x68/0x9c) (bus_for_each_dev) from [<c03f7a38>] (bus_add_driver+0x1a0/0x218) (bus_add_driver) from [<c03f8db0>] (driver_register+0x78/0xf8) (driver_register) from [<c0101774>] (do_one_initcall+0x90/0x1d8) (do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc) (kernel_init_freeable) from [<c06bb5b4>] (kernel_init+0x8/0x114) (kernel_init) from [<c0107938>] (ret_from_fork+0x14/0x3c) Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 104594b0 ("Input: add driver support for MAX8997-haptic") [k.kozlowski: Write commit message, add CC-stable] Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Al Viro authored
commit 99d82582 upstream. Payloads of NM entries are not supposed to contain NUL. When we run into such, only the part prior to the first NUL goes into the concatenation (i.e. the directory entry name being encoded by a bunch of NM entries). We do stop when the amount collected so far + the claimed amount in the current NM entry exceed 254. So far, so good, but what we return as the total length is the sum of *claimed* sizes, not the actual amount collected. And that can grow pretty large - not unlimited, since you'd need to put CE entries in between to be able to get more than the maximum that could be contained in one isofs directory entry / continuation chunk and we are stop once we'd encountered 32 CEs, but you can get about 8Kb easily. And that's what will be passed to readdir callback as the name length. 8Kb __copy_to_user() from a buffer allocated by __get_free_page() Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Herbert Xu authored
commit 13f4bb78 upstream. The crypto hash walk code is broken when supplied with an offset greater than or equal to PAGE_SIZE. This patch fixes it by adjusting walk->pg and walk->offset when this happens. Reported-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
- 11 May, 2016 24 commits
-
-
Greg Kroah-Hartman authored
-
Anton Blanchard authored
commit 6997e57d upstream. The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU feature value, meaning all the remaining elements initialise the wrong values. This means instead of checking for byte 5, bit 0, we check for byte 0, bit 0, and then we incorrectly set the CPU feature bit as well as MMU feature bit 1 and CPU user feature bits 0 and 2 (5). Checking byte 0 bit 0 (IBM numbering), means we're looking at the "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU. In practice that bit is set on all platforms which have the property. This means we set CPU_FTR_REAL_LE always. In practice that seems not to matter because all the modern cpus which have this property also implement REAL_LE, and we've never needed to disable it. We're also incorrectly setting MMU feature bit 1, which is: #define MMU_FTR_TYPE_8xx 0x00000002 Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E code, which can't run on the same cpus as scan_features(). So this also doesn't matter in practice. Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2 is not currently used, and bit 0 is: #define PPC_FEATURE_PPC_LE 0x00000001 Which says the CPU supports the old style "PPC Little Endian" mode. Again this should be harmless in practice as no 64-bit CPUs implement that mode. Fix the code by adding the missing initialisation of the MMU feature. Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It would be unsafe to start using it as old kernels incorrectly set it. Fixes: 44ae3ab3 ("powerpc: Free up some CPU feature bits by moving out MMU-related features") Signed-off-by:
Anton Blanchard <anton@samba.org> [mpe: Flesh out changelog, add comment reserving 0x4] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Andrey Gelman authored
commit 879f2fea upstream. According to the touch controller spec, SPI return a 16 bit value, only 12 bits are valid, they are bit[14-3]. The value of MISO and MOSI can be configured when SPI is in idle mode. Currently this touch driver assumes the SPI bus sets the MOSI and MISO in low level when SPI bus is in idle mode. So the bit[15] of the value got from SPI bus is always 0. But when SPI bus congfigures the MOSI and MISO in high level during the SPI idle mode, the bit[15] of the value get from SPI is always 1. If bit[15] is not masked, we may get the wrong value. Mask the invalid bit to make sure the correct value gets returned. Regardless of the SPI bus idle configuration. Signed-off-by:
Andrey Gelman <andrey.gelman@compulab.co.il> Signed-off-by:
Haibo Chen <haibo.chen@freescale.com> Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 07d2390e upstream. In certain probe conditions the interrupt came right after registering the handler causing a NULL pointer exception because of uninitialized waitqueue: $ udevadm trigger i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL) i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL) Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = e8b38000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (...) (__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c) (__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30) (ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c) (handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68) (exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194) (handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4) (__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94) (gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80) The bug was reproduced on exynos4412-trats2 (with a max77693 device also using i2c-gpio) after building max77693 as a module. Fixes: 94a6d5cf ("iio:ak8975 Implement data ready interrupt handling") Signed-off-by:
Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Jasem Mutlaq authored
commit 613ac23a upstream. Adding VID:PID for Straizona Focusers to cp210x driver. Signed-off-by:
Jasem Mutlaq <mutlaqja@ikarustech.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Mike Manning authored
commit 1d377f4d upstream. The Link ECU is an aftermarket ECU computer for vehicles that provides full tuning abilities as well as datalogging and displaying capabilities via the USB to Serial adapter built into the device. Signed-off-by:
Mike Manning <michael@bsch.com.au> Signed-off-by:
-
Prarit Bhargava authored
commit 93d68841 upstream. ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25 Set the mutex owner thread ID. Original patch from: Prarit Bhargava <prarit@redhat.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121 Link: https://github.com/acpica/acpica/commit/7a3bd2d9Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Tested-by: Andy Lutomirski <luto@kernel.org> # On a Dell XPS 13 9350 Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Wang YanQing authored
commit c10fcb14 upstream. The code for checking whether a BAR address range is valid will break out of the loop when a start address of 0x0 is encountered. This behaviour is wrong since by breaking out of the loop we may miss the BAR that describes the EFI frame buffer in a later iteration. Because of this bug I can't use video=efifb: boot parameter to get efifb on my new ThinkPad E550 for my old linux system hard disk with 3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not supporting the GPU. This patch also add a trivial optimization to break out after we find the frame buffer address range without testing later BARs. Signed-off-by:
Wang YanQing <udknight@gmail.com> [ Rewrote changelog. ] Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by:
Peter Jones <pjones@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.ukSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Chen Yu authored
commit 886123fb upstream. Currently we read the tsc radio: ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f; Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the SDM (35.5), the ratio bits are bit 8-15. Ignoring the upper bits can result in an incorrect tsc ratio, which causes the TSC calibration and the Local APIC timer frequency to be incorrect. Fix this problem by masking 0xff instead. [ tglx: Massaged changelog ] Fixes: 7da7c156 "x86, tsc: Add static (MSR) TSC calibration on Intel Atom SoCs" Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Bin Gao <bin.gao@intel.com> Cc: Len Brown <lenb@kernel.org> Link: http://lkml.kernel.org/r/1462505619-5516-1-git-send-email-yu.c.chen@intel.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Matt Fleming authored
commit e8dfe6d8 upstream. Mark reported that having asterisks on the end of directory names confuses get_maintainer.pl when it encounters subdirectories, and that my name does not appear when run on drivers/firmware/efi/libstub. Reported-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Sven Eckelmann authored
commit d1a65f17 upstream. _batadv_update_route rcu_derefences orig_ifinfo->router outside of a spinlock protected region to print some information messages to the debug log. But this pointer is not checked again when the new pointer is assigned in the spinlock protected region. Thus is can happen that the value of orig_ifinfo->router changed in the meantime and thus the reference counter of the wrong router gets reduced after the spinlock protected region. Just rcu_dereferencing the value of orig_ifinfo->router inside the spinlock protected region (which also set the new pointer) is enough to get the correct old router object. Fixes: e1a5382f ("batman-adv: Make orig_node->router an rcu protected pointer") Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
Antonio Quartulli <a@unstable.cc> Signed-off-by:
-
Linus Lüssing authored
commit c4fdb6cf upstream. When removing a single interface while a broadcast or ogm packet is still pending then we will free the forward packet without releasing the queue slots again. This patch is supposed to fix this issue. Fixes: 6d5808d4 ("batman-adv: Add missing hardif_free_ref in forw_packet_free") Signed-off-by:
Linus Lüssing <linus.luessing@c0d3.blue> [sven@narfation.org: fix conflicts with current version] Signed-off-by:
-
Sven Eckelmann authored
commit c7829666 upstream. The encapsulated ethernet and VLAN header may be outside the received ethernet frame. Thus the skb buffer size has to be checked before it can be parsed to find out if it encapsulates another batman-adv packet. Fixes: 42019357 ("batman-adv: softif bridge loop avoidance") Signed-off-by:
-
Mathias Krause authored
commit 8148a73c upstream. If /proc/<PID>/environ gets read before the envp[] array is fully set up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to read more bytes than are actually written, as env_start will already be set but env_end will still be zero, making the range calculation underflow, allowing to read beyond the end of what has been written. Fix this as it is done for /proc/<PID>/cmdline by testing env_end for zero. It is, apparently, intentionally set last in create_*_tables(). This bug was found by the PaX size_overflow plugin that detected the arithmetic underflow of 'this_len = env_end - (env_start + src)' when env_end is still zero. The expected consequence is that userland trying to access /proc/<PID>/environ of a not yet fully set up process may get inconsistent data as we're in the middle of copying in the environment variables. Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363 Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Knut Wohlrab authored
commit 6984ab1a upstream. A wrong decoding of the touch coordinate message causes a wrong touch ID. Touch ID for dual touch must be 0 or 1. According to the actual Neonode nine byte touch coordinate coding, the state is transported in the lower nibble and the touch ID in the higher nibble of payload byte five. Signed-off-by:
Knut Wohlrab <Knut.Wohlrab@de.bosch.com> Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by:
-
Sascha Hauer authored
commit 5616f367 upstream. The secondary CPU starts up in ARM mode. When the kernel is compiled in thumb2 mode we have to explicitly compile the secondary startup trampoline in ARM mode, otherwise the CPU will go to Nirvana. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Reported-by:
Steffen Trumtrar <s.trumtrar@pengutronix.de> Suggested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Chunyu Hu authored
commit 854145e0 upstream. Currently register functions for events will be called through the 'reg' field of event class directly without any check when seting up triggers. Triggers for events that don't support register through debug fs (events under events/ftrace are for trace-cmd to read event format, and most of them don't have a register function except events/ftrace/functionx) can't be enabled at all, and an oops will be hit when setting up trigger for those events, so just not creating them is an easy way to avoid the oops. Link: http://lkml.kernel.org/r/1462275274-3911-1-git-send-email-chuhu@redhat.com Fixes: 85f2b082 ("tracing: Add basic event trigger framework") Signed-off-by:
Chunyu Hu <chuhu@redhat.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Arnd Bergmann authored
commit aeb6641f upstream. gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array() call in lpfc_online(), which clearly doesn't look right: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online': drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] lpfc_destroy_vport_work_array(phba, vports); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not if (vports != NULL) ^~ Looking at the patch that introduced this code, it's clear that the behavior is correct and the indentation is wrong. This fixes the indentation and adds curly braces around the previous if() block for clarity, as that is most likely what caused the code to be misindented in the first place. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 549e55cd ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list") Reviewed-by:
Sebastian Herbszt <herbszt@gmx.de> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Linus Walleij authored
commit ec7957a6 upstream. Despite care take to allocate clocks state containers the SP810 driver actually just supports creating one instance: all clocks registered for every instance will end up with the exact same name and __clk_init() will fail. Rename the timclken<0> .. timclken<n> to sp810_<instance>_<n> so every clock on every instance gets a unique name. This is necessary for the RealView PBA8 which has two SP810 blocks: the second block will not register its clocks unless every clock on every instance is unique and results in boot logs like this: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at ../drivers/clk/versatile/clk-sp810.c:137 clk_sp810_of_setup+0x110/0x154() Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc2-00030-g352718fc39f6-dirty #225 Hardware name: ARM RealView Machine (Device Tree Support) [<c00167f8>] (unwind_backtrace) from [<c0013204>] (show_stack+0x10/0x14) [<c0013204>] (show_stack) from [<c01a049c>] (dump_stack+0x84/0x9c) [<c01a049c>] (dump_stack) from [<c0024990>] (warn_slowpath_common+0x74/0xb0) [<c0024990>] (warn_slowpath_common) from [<c0024a68>] (warn_slowpath_null+0x1c/0x24) [<c0024a68>] (warn_slowpath_null) from [<c051eb44>] (clk_sp810_of_setup+0x110/0x154) [<c051eb44>] (clk_sp810_of_setup) from [<c051e3a4>] (of_clk_init+0x12c/0x1c8) [<c051e3a4>] (of_clk_init) from [<c0504714>] (time_init+0x20/0x2c) [<c0504714>] (time_init) from [<c0501b18>] (start_kernel+0x244/0x3c4) [<c0501b18>] (start_kernel) from [<7000807c>] (0x7000807c) ---[ end trace cb88537fdc8fa200 ]--- Cc: Michael Turquette <mturquette@baylibre.com> Cc: Pawel Moll <pawel.moll@arm.com> Fixes: 6e973d2c "clk: vexpress: Add separate SP810 driver" Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Dan Streetman authored
commit da6ccaaa upstream. Make the "Attempted send on closed socket" error messages generated in nbd_request_handler() ratelimited. When the nbd socket is shutdown, the nbd_request_handler() function emits an error message for every request remaining in its queue. If the queue is large, this will spam a large amount of messages to the log. There's no need for a separate error message for each request, so this patch ratelimits it. In the specific case this was found, the system was virtual and the error messages were logged to the serial port, which overwhelmed it. Fixes: 4d48a542 ("nbd: fix I/O hang on disconnected nbds") Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
-
Marco Angaroni authored
commit 7617a24f upstream. The IPVS SIP persistence engine is not able to parse the SIP header "Call-ID" when such header is inserted in the first positions of the SIP message. When IPVS is configured with "--pe sip" option, like for example: ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o some particular messages (see below for details) do not create entries in the connection template table, which can be listed with: ipvsadm -Lcn --persistent-conn Problematic SIP messages are SIP responses having "Call-ID" header positioned just after message first line: SIP/2.0 200 OK [Call-ID header here] [rest of the headers] When "Call-ID" header is positioned down (after a few other headers) it is correctly recognized. This is due to the data offset used in get_callid function call inside ip_vs_pe_sip.c file: since dptr already points to the start of the SIP message, the value of dataoff should be initially 0. Otherwise the header is searched starting from some bytes after the first character of the SIP message. Fixes: 758ff033 ("IPVS: sip persistence engine") Signed-off-by:
Marco Angaroni <marcoangaroni@gmail.com> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Behan Webster authored
commit c4586256 upstream. Similar to the fix in 40413dcb MODULE_DEVICE_TABLE(x86cpu, ...) expects the struct to be called struct x86cpu_device_id, and not struct x86_cpu_id which is what is used in the rest of the kernel code. Although gcc seems to ignore this error, clang fails without this define to fix the name. Code from drivers/thermal/x86_pkg_temp_thermal.c static const struct x86_cpu_id __initconst pkg_temp_thermal_ids[] = { ... }; MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids); Error from clang: drivers/thermal/x86_pkg_temp_thermal.c:577:1: error: variable has incomplete type 'const struct x86cpu_device_id' MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids); ^ include/linux/module.h:145:3: note: expanded from macro 'MODULE_DEVICE_TABLE' MODULE_GENERIC_TABLE(type##_device, name) ^ include/linux/module.h:87:32: note: expanded from macro 'MODULE_GENERIC_TABLE' extern const struct gtype##_id __mod_##gtype##_table \ ^ <scratch space>:143:1: note: expanded from here __mod_x86cpu_device_table ^ drivers/thermal/x86_pkg_temp_thermal.c:577:1: note: forward declaration of 'struct x86cpu_device_id' include/linux/module.h:145:3: note: expanded from macro 'MODULE_DEVICE_TABLE' MODULE_GENERIC_TABLE(type##_device, name) ^ include/linux/module.h:87:21: note: expanded from macro 'MODULE_GENERIC_TABLE' extern const struct gtype##_id __mod_##gtype##_table \ ^ <scratch space>:141:1: note: expanded from here x86cpu_device_id ^ 1 error generated. Signed-off-by:
Behan Webster <behanw@converseincode.com> Signed-off-by:
Jan-Simon Möller <dl9pf@gmx.de> Acked-by:
-
Paolo Bonzini authored
commit 95272c29 upstream. -ftracer can duplicate asm blocks causing compilation to fail in noclone functions. For example, KVM declares a global variable in an asm like asm("2: ... \n .pushsection data \n .global vmx_return \n vmx_return: .long 2b"); and -ftracer causes a double declaration. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable@vger.kernel.org Cc: kvm@vger.kernel.org Reported-by:
Linda Walsh <lkml@tlinx.org> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Joe Perches authored
commit f320793e upstream. [ Upstream commit cb984d10 ] As gcc major version numbers are going to advance rather rapidly in the future, there's no real value in separate files for each compiler version. Deduplicate some of the macros #defined in each file too. Neaten comments using normal kernel commenting style. Signed-off-by:
Joe Perches <joe@perches.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Segher Boessenkool <segher@kernel.crashing.org> Cc: Sasha Levin <levinsasha928@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: Alan Modra <amodra@gmail.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
- 04 May, 2016 5 commits
-
-
Greg Kroah-Hartman authored
-
NeilBrown authored
commit a6ab1e81 upstream. sunrpc_cache_pipe_upcall() can detect a race if CACHE_PENDING is no longer set. In this case it aborts the queuing of the upcall. However it has already taken a new counted reference on "h" and doesn't "put" it, even though it frees the data structure holding the reference. So let's delay the "cache_get" until we know we need it. Fixes: f9e1aedc ("sunrpc/cache: remove races with queuing an upcall.") Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Guo-Fu Tseng authored
commit 81422e67 upstream. According to Documentation/power/devices.txt The driver should not use device_set_wakeup_enable() which is the policy for user to decide. Using device_init_wakeup() to initialize dev->power.should_wakeup and dev->power.can_wakeup on driver initialization. And use device_may_wakeup() on suspend to decide if WoL function should be enabled on NIC. Reported-by:
Diego Viola <diego.viola@gmail.com> Signed-off-by:
Guo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by:
-
Guo-Fu Tseng authored
commit 0772a99b upstream. Otherwise it might be back on resume right after going to suspend in some hardware. Reported-by:
-
Fabio Estevam authored
commit 33b96d2c upstream. Currently we have an incorrect behaviour when multiple devices are present under the weim node. For example: &weim { ... status = "okay"; sram@0,0 { ... status = "okay"; }; mram@0,0 { ... status = "disabled"; }; }; In this case only the 'sram' device should be probed and not 'mram'. However what happens currently is that the status variable is ignored, causing the 'sram' device to be disabled and 'mram' to be enabled. Change the weim_parse_dt() function to use for_each_available_child_of_node()so that the devices marked with 'status = disabled' are not probed. Suggested-by:
Wolfgang Netbal <wolfgang.netbal@sigmatek.at> Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
