- 19 Oct, 2017 35 commits
-
-
Matt Redfearn authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit db8466c5 ] When the separate IRQ stack was introduced, stack unwinding only proceeded as far as the top of the IRQ stack, leading to kernel backtraces being less useful, lacking the trace of what was interrupted. Fix this by providing a means for the kernel to unwind the IRQ stack onto the interrupted task stack. The processor state is saved to the kernel task stack on interrupt. The IRQ_STACK_START macro reserves an unsigned long at the top of the IRQ stack where the interrupted task stack pointer can be saved. After the active stack is switched to the IRQ stack, save the interrupted tasks stack pointer to the reserved location. Fix the stack unwinding code to look for the frame being the top of the IRQ stack and if so get the next frame from the saved location. The existing test does not work with the separate stack since the ra is no longer pointed at ret_from_{irq,exception}. The test to stop unwinding the stack 32 bytes from the top of a stack must be modified to allow unwinding to continue up to the location of the saved task stack pointer when on the IRQ stack. The low / high marks of the stack are set depending on whether the sp is on an irq stack or not. Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com> Cc: Masanari Iida <standby24x7@gmail.com> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jason A. Donenfeld <jason@zx2c4.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15788/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Liping Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 3b7dabf0 ] Otherwise, another CPU may access the invalid pointer. For example: CPU0 CPU1 - rcu_read_lock(); - pfunc = _hook_; _hook_ = NULL; - mod unload - - pfunc(); // invalid, panic - rcu_read_unlock(); So we must call synchronize_rcu() to wait the rcu reader to finish. Also note, in nf_nat_snmp_basic_fini, synchronize_rcu() will be invoked by later nf_conntrack_helper_unregister, but I'm inclined to add a explicit synchronize_rcu after set the nf_nat_snmp_hook to NULL. Depend on such obscure assumptions is not a good idea. Last, in nfnetlink_cttimeout, we use kfree_rcu to free the time object, so in cttimeout_exit, invoking rcu_barrier() is not necessary at all, remove it too. Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Ido Schimmel authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 5b8d5429 ] Peter reported a kernel oops when executing the following command: $ ip link add name test type bridge vlan_default_pvid 1 [13634.939408] BUG: unable to handle kernel NULL pointer dereference at 0000000000000190 [13634.939436] IP: __vlan_add+0x73/0x5f0 [...] [13634.939783] Call Trace: [13634.939791] ? pcpu_next_unpop+0x3b/0x50 [13634.939801] ? pcpu_alloc+0x3d2/0x680 [13634.939810] ? br_vlan_add+0x135/0x1b0 [13634.939820] ? __br_vlan_set_default_pvid.part.28+0x204/0x2b0 [13634.939834] ? br_changelink+0x120/0x4e0 [13634.939844] ? br_dev_newlink+0x50/0x70 [13634.939854] ? rtnl_newlink+0x5f5/0x8a0 [13634.939864] ? rtnl_newlink+0x176/0x8a0 [13634.939874] ? mem_cgroup_commit_charge+0x7c/0x4e0 [13634.939886] ? rtnetlink_rcv_msg+0xe1/0x220 [13634.939896] ? lookup_fast+0x52/0x370 [13634.939905] ? rtnl_newlink+0x8a0/0x8a0 [13634.939915] ? netlink_rcv_skb+0xa1/0xc0 [13634.939925] ? rtnetlink_rcv+0x24/0x30 [13634.939934] ? netlink_unicast+0x177/0x220 [13634.939944] ? netlink_sendmsg+0x2fe/0x3b0 [13634.939954] ? _copy_from_user+0x39/0x40 [13634.939964] ? sock_sendmsg+0x30/0x40 [13634.940159] ? ___sys_sendmsg+0x29d/0x2b0 [13634.940326] ? __alloc_pages_nodemask+0xdf/0x230 [13634.940478] ? mem_cgroup_commit_charge+0x7c/0x4e0 [13634.940592] ? mem_cgroup_try_charge+0x76/0x1a0 [13634.940701] ? __handle_mm_fault+0xdb9/0x10b0 [13634.940809] ? __sys_sendmsg+0x51/0x90 [13634.940917] ? entry_SYSCALL_64_fastpath+0x1e/0xad The problem is that the bridge's VLAN group is created after setting the default PVID, when registering the netdevice and executing its ndo_init(). Fix this by changing the order of both operations, so that br_changelink() is only processed after the netdevice is registered, when the VLAN group is already initialized. Fixes: b6677449 ("bridge: netlink: call br_changelink() during br_dev_newlink()") Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reported-by:
Peter V. Saveliev <peter@svinota.eu> Tested-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Heiner Kallweit authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 5ef1ecf0 ] Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be used for DMA to be 8-byte-aligned. struct sdio_func has an embedded small DMA buffer not meeting this requirement. When testing switching to descriptor chain mode in meson-gx driver SDIO is broken therefore. Fix this by allocating the small DMA buffer separately as kmalloc ensures that the returned memory area is properly aligned for every basic data type. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Tested-by:
Helmut Klein <hgkr.klein@gmail.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Roman Spychała authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 6f2aee0c ] This patch adds support for the PL-27A1 by adding the appropriate USB ID's. This chip is used in the goobay Active USB 3.0 Data Link and Unitek Y-3501 cables. Signed-off-by:
Roman Spychała <roed@onet.eu> Signed-off-by:
-
Pan Bian authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 72ec0bc6 ] In functions team_nl_send_port_list_get() and team_nl_send_options_get(), pointer skb keeps the return value of nlmsg_new(). When the call to genlmsg_put() fails, the memory is not freed(). This will result in memory leak bugs. Fixes: 9b00cf2d ("team: implement multipart netlink messages for options transfers") Signed-off-by:
Pan Bian <bianpan2016@163.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Alexander Potapenko authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit fd2c83b3 ] In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 |val| remains uninitialized and the syscall may behave differently depending on its value, and even copy garbage to userspace on certain architectures. To fix this we now return -EINVAL if optlen is too small. This bug has been detected with KMSAN. Signed-off-by:
Alexander Potapenko <glider@google.com> Signed-off-by:
-
Myungho Jung authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 9899886d ] Added NULL check to make __dev_kfree_skb_irq consistent with kfree family of functions. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289Signed-off-by:
Myungho Jung <mhjungk@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 98ea51cb ] Hauke already fixed a couple of them, but one instance remains that checks for a negative integer when it should check for a NULL pointer: arch/mips/lantiq/xway/sysctrl.c: In function 'ltq_soc_init': arch/mips/lantiq/xway/sysctrl.c:473:19: error: ordered comparison of pointer with integer zero [-Werror=extra] Fixes: 6e807852 ("MIPS: Lantiq: Fix check for return value of request_mem_region()") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: John Crispin <john@phrozen.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15043/Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 639467c8 ] commit 66feeec9322132689d42723df2537d60f96f8e44 "RFC: ASoC: dapm: handle probe deferrals" forgot a to update some two sites where the call was used. The static codechecks quickly found them. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 66feeec93221 ("RFC: ASoC: dapm: handle probe deferrals") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Peter Chen authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit c3b674a0 ] At some situations, the vbus may already be there before starting gadget. So we need to check vbus event after switching to gadget in order to handle missing vbus event. The typical use cases are plugging vbus cable before driver load or the vbus has already been there after stopping host but before starting gadget. Signed-off-by:
Peter Chen <peter.chen@nxp.com> Tested-by:
Stephen Boyd <stephen.boyd@linaro.org> Reported-by:
-
Richard Guy Briggs authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 62bc306e ] 32-bit socketcalls were not being logged by audit on x86_64 systems. Log them. This is basically a duplicate of the call from net/socket.c:sys_socketcall(), but it addresses the impedance mismatch between 32-bit userspace process and 64-bit kernel audit. See: https://github.com/linux-audit/audit-kernel/issues/14Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 37e1df8c ] This starts to handle probe deferrals on regulators and clocks on the ASoC DAPM. I came to this patch after audio stopped working on Ux500 ages ago and I finally looked into it to see what is wrong. I had messages like this in the console since a while back: ab8500-codec.0: ASoC: Failed to request audioclk: -517 ab8500-codec.0: ASoC: Failed to create DAPM control audioclk ab8500-codec.0: Failed to create new controls -12 snd-soc-mop500.0: ASoC: failed to instantiate card -12 snd-soc-mop500.0: Error: snd_soc_register_card failed (-12)! snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -12 Apparently because the widget table for the codec looks like this (sound/soc/codecs/ab8500-codec.c): static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = { /* Clocks */ SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"), /* Regulators */ SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0), So when we call snd_soc_register_codec() and any of these widgets get a deferred probe we do not get an -EPROBE_DEFER (-517) back as we should and instead we just fail. Apparently the code assumes that clocks and regulators must be available at this point and not defer. After this patch it rather looks like this: ab8500-codec.0: Failed to create new controls -517 snd-soc-mop500.0: ASoC: failed to instantiate card -517 snd-soc-mop500.0: Error: snd_soc_register_card failed (-517)! (...) abx500-clk.0: registered clocks for ab850x snd-soc-mop500.0: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok snd-soc-mop500.0: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok I'm pretty happy about the patch as it it, but I'm a bit uncertain on how to proceed: there are a lot of users of the external functions snd_soc_dapm_new_control() (111 sites) and that will now return an occassional error pointer, which is not handled in the calling sites. I want an indication from the maintainers whether I should just go in and augment all these call sites, or if deferred probe is frowned upon when it leads to this much overhead. Signed-off-by:
-
Alden Tondettar authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit c5082b70 ] If a GUID Partition Table claims to have more than 2**25 entries, the calculation of the partition table size in alloc_read_gpt_entries() will overflow a 32-bit integer and not enough space will be allocated for the table. Nothing seems to get written out of bounds, but later efi_partition() will read up to 32768 bytes from a 128 byte buffer, possibly OOPSing or exposing information to /proc/partitions and uevents. The problem exists on both 64-bit and 32-bit platforms. Fix the overflow and also print a meaningful debug message if the table size is too large. Signed-off-by:
Alden Tondettar <alden.tondettar@gmail.com> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit cd8db057 ] Make sure to detect short transfers when reading a device register. The modem-status handling had sufficient error checks in place, but move handling of short transfers into the register accessor function itself for consistency. Reviewed-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 0d130367 ] Make sure to log an error on short transfers when reading a device register. Also clear the provided buffer (which if often an uninitialised automatic variable) on errors as the driver currently does not bother to check for errors. Reviewed-by:
-
Pan Bian authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 8bf79388 ] In function kfd_wait_on_events(), when the call to copy_from_user() fails, the value of return variable ret is 0. 0 indicates success, which is inconsistent with the execution status. This patch fixes the bug by assigning "-EFAULT" to ret when copy_from_user() returns an unexpected value. Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Feras Daoud authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit c586071d ] In order to resolve a situation where a few process delete the same list element in sequence and cause panic, list_del is replaced with list_del_init. In this case if the first process that calls list_del releases the lock before acquiring it again, other processes who can acquire the lock will call list_del_init. Fixes: b63b70d8 ("IPoIB: Use a private hash table for path lookup") Signed-off-by:
Feras Daoud <ferasda@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Reviewed-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Feras Daoud authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 89a3987a ] The ipoib_vlan_add function calls rtnl_unlock after free_netdev, rtnl_unlock not only releases the lock, but also calls netdev_run_todo. The latter function browses the net_todo_list array and completes the unregistration of all its net_device instances. If we call free_netdev before rtnl_unlock, then netdev_run_todo call over the freed device causes panic. To fix, move rtnl_unlock call before free_netdev call. Fixes: 9baa0b03 ("IB/ipoib: Add rtnl_link_ops support") Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Feras Daoud authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 1c3098cd ] This patch fixes Deadlock while executing ipoib_vlan_delete. The function takes the vlan_rwsem semaphore and calls unregister_netdevice. The later function calls ipoib_mcast_stop_thread that cause workqueue flush. When the queue has one of the ipoib_ib_dev_flush_xxx events, a deadlock occur because these events also tries to catch the same vlan_rwsem semaphore. To fix, unregister_netdevice should be called after releasing the semaphore. Fixes: cbbe1efa ("IPoIB: Fix deadlock between ipoib_open() and child interface create") Signed-off-by:
-
Christophe JAILLET authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 1a5c2d1d ] 'request_irq()' and 'free_irq()' should be called with the same dev_id. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Afzal Mohammed authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 8a792e9a ] REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself available to Kconfig, DRAM_BASE also is available as the Kconfig gets sourced on !MMU. Signed-off-by:
Afzal Mohammed <afzal.mohd.ma@gmail.com> Reviewed-by:
Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Andreas Klinger authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit ff1293f6 ] Add DT bindings for avia,hx711 Add vendor avia to vendor list Signed-off-by:
Andreas Klinger <ak@it-klinger.de> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit fa2849e9 ] For some reason the axp288_adc driver was modifying the AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on whether the GP_ADC channel or another channel was written. These bits control when a bias current is send to the TS_PIN, the GP_ADC has its own pin and a separate bit in another register to control the bias current. Not only does changing when to enable the TS_PIN bias current (always or only when sampling) when reading the GP_ADC make no sense at all, the code is modifying these bits is writing the entire register, assuming that all the other bits have their default value. So if the firmware has configured a different bias-current for either pin, then that change gets clobbered by the write, likewise if the firmware has set bit 2 to indicate that the battery has no thermal sensor, this will get clobbered by the write. This commit fixes all this, by simply removing all writes to the AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the GP_ADC pin, and can actually be harmful. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Guenter Roeck authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 87cdfa9d ] Writes into limit attributes can overflow due to multplications and additions with unbound input values. Writing into fan limit attributes can result in a crash with a division by zero if very large values are written and the fan divider is larger than 1. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Niklas Söderlund authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 6dcf45e5 ] This bit was wrongly named due to a typo, Sergei checked the SH7734/63 manuals and this bit should be named MPDE. Suggested-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 5757aca1 ] The vbus-present bit in the power status register also gets set to 1 when a usb-host cable (id-pin shorted to ground) is plugged in and a 5v boost converter is supplying 5v to the otg usb bus. This causes a "disconnect or unknown or ID event" warning in dmesg as well as the extcon device to report the last detected charger cable type as being connected even though none is connected. This commit switches to checking the vbus-valid bit instead, which is only 1 when both vbus is present and the vbus-path is enabled in the vbus-path control register (the vbus-path gets disabled when a usb-host cable is detected, to avoid the pmic drawing power from the 5v boost converter). Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Guilherme G Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 69b97cf6 ] Whenever the igb driver detects the result of a read operation returns a value composed only by F's (like 0xFFFFFFFF), it will detach the net_device, clear the hw_addr pointer and warn to the user that adapter's link is lost - those steps happen on igb_rd32(). In case a PCI error happens on Power architecture, there's a recovery mechanism called EEH, that will reset the PCI slot and call driver's handlers to reset the adapter and network functionality as well. We observed that once hw_addr is NULL after the error is detected on igb_rd32(), it's never assigned back, so in the process of resetting the network functionality we got a NULL pointer dereference in both igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid such bug, this patch re-assigns the hw_addr value in the slot_reset handler. Reported-by:
Anthony H Thai <ahthai@us.ibm.com> Reported-by:
Harsha Thyagaraja <hathyaga@in.ibm.com> Signed-off-by:
Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 08d90c81 ] ralink_soc sould be assigned to RT3883_SOC, replace incorrect comparision with assignment. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Fixes: 418d29c8 ("MIPS: ralink: Unify SoC id handling") Cc: John Crispin <john@phrozen.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14903/Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 3f00f4d8 ] When clearing the .bss section in kernel_entry we do so using LONG_S instructions, and branch whilst the current write address doesn't equal the end of the .bss section minus the size of a long integer. The .bss section always begins at a long-aligned address and we always increment the write pointer by the size of a long integer - we therefore rely upon the .bss section ending at a long-aligned address. If this is not the case then the long-aligned write address can never be equal to the non-long-aligned end address & we will continue to increment past the end of the .bss section, attempting to zero the rest of memory. Despite this requirement that .bss end at a long-aligned address we pass 0 as the end alignment requirement to the BSS_SECTION macro and thus don't guarantee any particular alignment, allowing us to hit the error condition described above. Fix this by instead passing 8 bytes as the end alignment argument to the BSS_SECTION macro, ensuring that the end of the .bss section is always at least long-aligned. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14526/Signed-off-by:
-
Simon Horman authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 654450ba ] Use recently added R-Car Gen 2 fallback binding for msiof nodes in DT for r8a7790 SoC. This has no run-time effect for the current driver as the initialisation sequence is the same for the SoC-specific binding for r8a7790 and the fallback binding for R-Car Gen 2. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Santosh Shilimkar authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 941f8d55 ] When application sends an RDS RDMA composite message consist of RDMA transfer to be followed up by non RDMA payload, it expect to be notified *only* when the full message gets delivered. RDS RDMA notification doesn't behave this way though. Thanks to Venkat for debug and root casuing the issue where only first part of the message(RDMA) was successfully delivered but remainder payload delivery failed. In that case, application should not be notified with a false positive of message delivery success. Fix this case by making sure the user gets notified only after the full message delivery. Reviewed-by:
Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com> Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 14d37564 ] This patch fixes a place where function gfs2_glock_iter_next can reference an invalid error pointer. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Bartosz Golaszewski authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 2e644be3 ] THS8135 is a configurable video DAC. Add DT bindings for this chip. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszewski@baylibre.comSigned-off-by:
-
Kristian H. Kristensen authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit af913418 ] We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code() macro to work correctly. Signed-off-by:
Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsberg@google.comSigned-off-by:
-
- 17 Oct, 2017 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:
-
- 10 Oct, 2017 4 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Marcelo Henrique Cerri authored
Ignore: yes Make insert-ubuntu-changes to consider full version numbers when looping through debian.master/changelog entries and comparing the version number of each entry with the arguments passed to the script to decide which entries should be included in the output changelog file. Previously, only the last number in the version was used in this comparison. For example, when comparing 4.4.0-50.51 and 4.4.0-83.84 only the numbers 51 and 84 were actually used in the comparison. That however might not work properly when the major version is bumped. For instance, using "end" as 4.4.0-50.51 and "start" as 4.4.0-83.84 used to work fine because 84 is greater than 51. However when using "end" as 4.11.0-10.11 and "start" as 4.13.0-2.3, no entry was being selected since 3 is not greater than 11. Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Yadan Fan authored
BugLink: https://bugs.launchpad.net/bugs/1720359 The hpsa firmware will bypass the cache for any request larger than 1MB, so we should cap the request size to avoid any performance degradation in kernels later than v4.3 This degradation is caused from d2be537c, which changed max_sectors_kb to 1280k, but the hardware is able to work fine with it, so the true fix should be from hpsa driver. Signed-off-by:
Yadan Fan <ydfan@suse.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit e2c7b433) Signed-off-by:
Eric Desrochers <eric.desrochers@canonical.com> Acked-by:
-
hayeswang authored
BugLink: http://bugs.launchpad.net/bugs/1720977 The list rx_done would be initialized when the linking on occurs. Therefore, if a napi is scheduled without any linking on before, the following kernel panic would happen. BUG: unable to handle kernel NULL pointer dereference at 000000000000008 IP: [<ffffffffc085efde>] r8152_poll+0xe1e/0x1210 [r8152] PGD 0 Oops: 0002 [#1] SMP Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
