Skip to main content

Browse the archive

https://github.com/torvalds/linux
16 September 2024, 20:19:31 UTC
sort by:
Revision Author Date Message Commit Date
abeccc4 yash2710 21 September 2019, 00:53:41 UTC Reapply first commit 22 September 2019, 02:51:55 UTC
caa1939 Khalid Elmously 20 August 2019, 19:25:30 UTC UBUNTU: Ubuntu-5.0.0-27.28 Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 20 August 2019, 19:25:30 UTC
b7eda3e Khalid Elmously 20 August 2019, 19:24:29 UTC UBUNTU: link-to-tracker: update tracking bug BugLink: https://bugs.launchpad.net/bugs/1840816 Properties: no-test-build Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 20 August 2019, 19:24:29 UTC
76b3daf Khalid Elmously 20 August 2019, 19:23:48 UTC UBUNTU: Start new release Ignore: yes Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 20 August 2019, 19:23:48 UTC
5c4d42c Nadav Amit 20 August 2019, 14:42:27 UTC x86/kprobes: Set instruction page as executable BugLink: https://bugs.launchpad.net/bugs/1840750 Set the page as executable after allocation. This patch is a preparatory patch for a following patch that makes module allocated pages non-executable. While at it, do some small cleanup of what appears to be unnecessary masking. Signed-off-by: Nadav Amit <namit@vmware.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: <akpm@linux-foundation.org> Cc: <ard.biesheuvel@linaro.org> Cc: <deneen.t.dock@intel.com> Cc: <kernel-hardening@lists.openwall.com> Cc: <kristen@linux.intel.com> Cc: <linux_dti@icloud.com> Cc: <will.deacon@arm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rik van Riel <riel@surriel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20190426001143.4983-11-namit@vmware.com Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 7298e24f904224fa79eb8fd7e0fbd78950ccf2db) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 20 August 2019, 19:14:00 UTC
2284166 Stefan Bader 13 August 2019, 12:19:24 UTC UBUNTU: Ubuntu-5.0.0-26.27 Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:19:24 UTC
f27f686 Stefan Bader 13 August 2019, 12:01:37 UTC UBUNTU: link-to-tracker: update tracking bug BugLink: https://bugs.launchpad.net/bugs/1839972 Properties: no-test-build Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:18:20 UTC
28e5ad6 Stefan Bader 13 August 2019, 12:00:08 UTC UBUNTU: Start new release Ignore: yes Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:18:20 UTC
16744c9 Stefan Bader 13 August 2019, 11:59:17 UTC UBUNTU: [Packaging] update helper scripts BugLink: http://bugs.launchpad.net/bugs/1786013 Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:18:20 UTC
dc2115d Takashi Iwai 17 July 2019, 14:42:00 UTC ALSA: hda/hdmi - Fix i915 reverse port/pin mapping BugLink: https://bugs.launchpad.net/bugs/1836916 The recent fix for Icelake HDMI codec introduced the mapping from pin NID to the i915 gfx port number. However, it forgot the reverse mapping from the port number to the pin NID that is used in the ELD notifier callback. As a result, it's processed to a wrong widget and gives a warning like snd_hda_codec_hdmi hdaudioC0D2: HDMI: pin nid 5 not registered This patch corrects it with a proper reverse mapping function. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204133 Fixes: b0d8bc50b9f2 ("ALSA: hda: hdmi - add Icelake support") Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 3140aafb22edeab0cc41f15f53b12a118c0ac215) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> 13 August 2019, 12:18:20 UTC
34e3ec1 Takashi Iwai 17 July 2019, 14:42:00 UTC ALSA: hda/hdmi - Remove duplicated define BugLink: https://bugs.launchpad.net/bugs/1836916 INTEL_GET_VENDOR_VERB is defined twice identically. Let's remove a superfluous line. Fixes: b0d8bc50b9f2 ("ALSA: hda: hdmi - add Icelake support") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit eb4177116bf568a413c544eca3f4446cb4064be9) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> 13 August 2019, 12:18:20 UTC
19977fe Jaroslav Kysela 17 July 2019, 14:42:00 UTC ALSA: hda: hdmi - add Icelake support BugLink: https://bugs.launchpad.net/bugs/1836916 This is just a port of the ASoC Icelake HDMI codec code to the legacy HDA driver with some cleanups. ASoC commit 019033c854a20e10f691f6cc0e897df8817d9521: "ASoC: Intel: hdac_hdmi: add Icelake support" Signed-off-by: Jaroslav Kysela <perex@perex.cz> Cc: Bard liao <bard.liao@intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit b0d8bc50b9f221e3af76afe0473f7c171cebbb40) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> 13 August 2019, 12:18:20 UTC
144dc98 Hui Wang 19 July 2019, 14:39:17 UTC Input: alps - fix a mismatch between a condition check and its comment BugLink: https://bugs.launchpad.net/bugs/1836752 In the function alps_is_cs19_trackpoint(), we check if the param[1] is in the 0x20~0x2f range, but the code we wrote for this checking is not correct: (param[1] & 0x20) does not mean param[1] is in the range of 0x20~0x2f, it also means the param[1] is in the range of 0x30~0x3f, 0x60~0x6f... Now fix it with a new condition checking ((param[1] & 0xf0) == 0x20). Fixes: 7e4935ccc323 ("Input: alps - don't handle ALPS cs19 trackpoint-only device") Cc: stable@vger.kernel.org Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit 771a081e44a9baa1991ef011cc453ef425591740) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
529d6b3 Hui Wang 19 July 2019, 14:39:16 UTC Input: alps - don't handle ALPS cs19 trackpoint-only device BugLink: https://bugs.launchpad.net/bugs/1836752 On a latest Lenovo laptop, the trackpoint and 3 buttons below it don't work at all, when we move the trackpoint or press those 3 buttons, the kernel will print out: "Rejected trackstick packet from non DualPoint device" This device is identified as an alps touchpad but the packet has trackpoint format, so the alps.c drops the packet and prints out the message above. According to XiaoXiao's explanation, this device is named cs19 and is trackpoint-only device, its firmware is only for trackpoint, it is independent of touchpad and is a device completely different from DualPoint ones. To drive this device with mininal changes to the existing driver, we just let the alps driver not handle this device, then the trackpoint.c will be the driver of this device if the trackpoint driver is enabled. (if not, this device will fallback to a bare PS/2 device) With the trackpoint.c, this trackpoint and 3 buttons all work well, they have all features that the trackpoint should have, like scrolling-screen, drag-and-drop and frame-selection. Signed-off-by: XiaoXiao Liu <sliuuxiaonxiao@gmail.com> Signed-off-by: Hui Wang <hui.wang@canonical.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit 7e4935ccc3236751e5fe4bd6846f86e46bb2e427) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
64bdfad Martin Schwidefsky 22 July 2019, 18:24:34 UTC s390: add alignment hints to vector load and store BugLink: https://bugs.launchpad.net/bugs/1836857 The z14 introduced alignment hints to increase the performance of vector loads and stores. The kernel uses an implicit alignmenet of 8 bytes for the vector registers, set the alignment hint to 3. Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 142c52d7bce45d335f48d53fdbf428bb15cf3924) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
0829d0e Martin Schwidefsky 22 July 2019, 18:24:33 UTC s390: report new CPU capabilities BugLink: https://bugs.launchpad.net/bugs/1836857 Add hardware capability bits and features tags to /proc/cpuinfo for 4 new CPU features: "Vector-Enhancements Facility 2" (tag "vxe2", hwcap 2^15) "Vector-Packed-Decimal-Enhancement Facility" (tag "vxp", hwcap 2^16) "Enhanced-Sort Facility" (tag "sort", hwcap 2^17) "Deflate-Conversion Facility" (tag "dflt", hwcap 2^18) Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit a8fd61688dfad6fdce95fa64cacd8a66595697b8) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
8dff416 José Roberto de Souza 23 July 2019, 07:39:28 UTC drm/i915: Enable hotplug retry BugLink: http://bugs.launchpad.net/bugs/1835001 Right now we are aware of two cases that needs another hotplug retry: - Unpowered type-c dongles - HDMI slow unplug Both have a complete explanation in the code to schedule another run of the hotplug handler. It could have more checks to just trigger the retry in those two specific cases but why would sink signal a long pulse if there is no change? Also the drawback of running the hotplug handler again is really low and that could fix another cases that we are not aware. Also retrying for old DP ports(non-DDI) to make it consistent and not cause CI failures if those systems are connected to chamelium boards that will be used to simulate the issues reported in here. v2: Also retrying for old DP ports(non-DDI)(Imre) v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep it consistent(Rodrigo) Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com (backported from commit bb80c9255770fa1ed54e889a6bee628bdd0f6762 git://anongit.freedesktop.org/drm-intel) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
4211bdb Imre Deak 23 July 2019, 07:39:27 UTC drm/i915: Add support for retrying hotplug BugLink: http://bugs.launchpad.net/bugs/1835001 There is some scenarios that we are aware that sink probe can fail, so lets add the infrastructure to let hotplug() hook to request another probe after some time. v2: Handle shared HPD pins (Imre) v3: Rebased v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep it consistent(Rodrigo) v5: Making the working queue used explicit through all the callers to hotplug_work (Ville) Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-1-jose.souza@intel.com (backported from commit 3944709df8e9298225fc2b29e53ee8e6f4b26618 git://anongit.freedesktop.org/drm-intel) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
95c51be Thomas Richter 24 July 2019, 16:30:35 UTC s390/cpumf: Add extended counter set definitions for model 8561 and 8562 BugLink: https://bugs.launchpad.net/bugs/1836860 Add the extended counter set definitions for s390 machine types 8561 and 8262. They are identical with machine types 3906 and 3907. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> (cherry picked from commit 820bace734722715c643dcb5f74b502cb912d4eb) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
73d4d8d Thomas Richter 24 July 2019, 16:30:34 UTC s390/cpum_cf: Add support for CPU-MF SVN 6 BugLink: https://bugs.launchpad.net/bugs/1836860 Add support for the CPU-Measurement Facility counter second version number 6. This number is used to detect some more counters in the crypto counter set and the extended counter set. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 46a984ffb86c8542fa510656fa8cb33befe8ee8f) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
5f91785 Hans de Goede 25 July 2019, 07:19:10 UTC platform/x86: asus-wmi: Only Tell EC the OS will handle display hotkeys from asus_nb_wmi BugLink: https://bugs.launchpad.net/bugs/1837117 Commit 78f3ac76d9e5 ("platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey") causes the backlight to be permanently off on various EeePC laptop models using the eeepc-wmi driver (Asus EeePC 1015BX, Asus EeePC 1025C). The asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL) call added by that commit is made conditional in this commit and only enabled in the quirk_entry structs in the asus-nb-wmi driver fixing the broken display / backlight on various EeePC laptop models. Cc: João Paulo Rechi Vita <jprvita@endlessm.com> Fixes: 78f3ac76d9e5 ("platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (cherry picked from commit 1dd93f873d8ed8e5b228d1ae324b1f3c1e94bfa8) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
f5bfd0f Christian Brauner 26 July 2019, 00:20:54 UTC netfilter: bridge: prevent UAF in brnf_exit_net() BugLink: https://bugs.launchpad.net/bugs/1836910 Prevent a UAF in brnf_exit_net(). When unregister_net_sysctl_table() is called the ctl_hdr pointer will obviously be freed and so accessing it righter after is invalid. Fix this by stashing a pointer to the table we want to free before we unregister the sysctl header. Note that syzkaller falsely chased this down to the drm tree so the Fixes tag that syzkaller requested would be wrong. This commit uses a different but the correct Fixes tag. /* Splat */ BUG: KASAN: use-after-free in br_netfilter_sysctl_exit_net net/bridge/br_netfilter_hooks.c:1121 [inline] BUG: KASAN: use-after-free in brnf_exit_net+0x38c/0x3a0 net/bridge/br_netfilter_hooks.c:1141 Read of size 8 at addr ffff8880a4078d60 by task kworker/u4:4/8749 CPU: 0 PID: 8749 Comm: kworker/u4:4 Not tainted 5.2.0-rc5-next-20190618 #17 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351 __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482 kasan_report+0x12/0x20 mm/kasan/common.c:614 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 br_netfilter_sysctl_exit_net net/bridge/br_netfilter_hooks.c:1121 [inline] brnf_exit_net+0x38c/0x3a0 net/bridge/br_netfilter_hooks.c:1141 ops_exit_list.isra.0+0xaa/0x150 net/core/net_namespace.c:154 cleanup_net+0x3fb/0x960 net/core/net_namespace.c:553 process_one_work+0x989/0x1790 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x354/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 11374: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_kmalloc mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503 __do_kmalloc mm/slab.c:3645 [inline] __kmalloc+0x15c/0x740 mm/slab.c:3654 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:743 [inline] __register_sysctl_table+0xc7/0xef0 fs/proc/proc_sysctl.c:1327 register_net_sysctl+0x29/0x30 net/sysctl_net.c:121 br_netfilter_sysctl_init_net net/bridge/br_netfilter_hooks.c:1105 [inline] brnf_init_net+0x379/0x6a0 net/bridge/br_netfilter_hooks.c:1126 ops_init+0xb3/0x410 net/core/net_namespace.c:130 setup_net+0x2d3/0x740 net/core/net_namespace.c:316 copy_net_ns+0x1df/0x340 net/core/net_namespace.c:439 create_new_namespaces+0x400/0x7b0 kernel/nsproxy.c:103 unshare_nsproxy_namespaces+0xc2/0x200 kernel/nsproxy.c:202 ksys_unshare+0x444/0x980 kernel/fork.c:2822 __do_sys_unshare kernel/fork.c:2890 [inline] __se_sys_unshare kernel/fork.c:2888 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:2888 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 9: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451 kasan_slab_free+0xe/0x10 mm/kasan/common.c:459 __cache_free mm/slab.c:3417 [inline] kfree+0x10a/0x2c0 mm/slab.c:3746 __rcu_reclaim kernel/rcu/rcu.h:215 [inline] rcu_do_batch kernel/rcu/tree.c:2092 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2310 [inline] rcu_core+0xcc7/0x1500 kernel/rcu/tree.c:2291 __do_softirq+0x25c/0x94c kernel/softirq.c:292 The buggy address belongs to the object at ffff8880a4078d40 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 32 bytes inside of 512-byte region [ffff8880a4078d40, ffff8880a4078f40) The buggy address belongs to the page: page:ffffea0002901e00 refcount:1 mapcount:0 mapping:ffff8880aa400a80 index:0xffff8880a40785c0 flags: 0x1fffc0000000200(slab) raw: 01fffc0000000200 ffffea0001d636c8 ffffea0001b07308 ffff8880aa400a80 raw: ffff8880a40785c0 ffff8880a40780c0 0000000100000004 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a4078c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4078c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc > ffff8880a4078d00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8880a4078d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4078e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Reported-by: syzbot+43a3fa52c0d9c5c94f41@syzkaller.appspotmail.com Fixes: 22567590b2e6 ("netfilter: bridge: namespace bridge netfilter sysctls") Signed-off-by: Christian Brauner <christian@brauner.io> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db) Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
ac8eb19 Christian Brauner 26 July 2019, 00:20:53 UTC netfilter: bridge: namespace bridge netfilter sysctls BugLink: https://bugs.launchpad.net/bugs/1836910 Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This patch ensures that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. This unblocks some use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Cc: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 22567590b2e634247931b3d2351384ba45720ebe) Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
6e664cb Christian Brauner 26 July 2019, 00:20:52 UTC netfilter: bridge: port sysctls to use brnf_net BugLink: https://bugs.launchpad.net/bugs/1836910 This ports the sysctls to use struct brnf_net. With this patch we make it possible to namespace the br_netfilter module in the following patch. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit ff6d090d0db41425aef0cfe5dc58bb3cc12514a2) Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
27d51a9 Hans de Goede 29 July 2019, 16:06:55 UTC platform/x86: ideapad-laptop: Remove no_hw_rfkill_list BugLink: https://bugs.launchpad.net/bugs/1837136 When the ideapad-laptop driver was first written it was written for laptops which had a hardware rfkill switch. So when the first ideapad laptops showed up without a hw rfkill switch and it turned out that in this case the ideapad firmware interface would always report the wifi being hardware- blocked, a DMI id list of models which lack a hw rfkill switch was started (by yours truly). Things were done this way to avoid regressing existing models with a hw rfkill switch. In hindsight this was a mistake. Lenovo releases a lot of ideapad models every year and even the latest models still use the "VPC2004" ACPI interface the ideapad-laptop driver binds to. Having a hw rfkill switch is quite rare on modern hardware, so all these new models need to be added to the no_hw_rfkill_list, leading to a never ending game of whack a mole. Worse the failure mode when not present on the list, is very bad. In this case the ideapad-laptop driver will report the wifi as being hw-blocked, at which points NetworkManager does not even try to use it and the user ends up with non working wifi. This leads to various Linux fora on the internet being filled with wifi not working on ideapad laptops stories, which does not make Linux look good. The failure mode when we flip the default to assuming that a hw rfkill switch is not present OTOH is quite benign. When we properly report the wifi as being hw-blocked on ideapads which do have the hw-switch; and it is in the wifi-off position, then at least when using NetworkManager + GNOME3 the user will get a "wifi disabled in hardware" message when trying to connect to the wifi from the UI. If OTOH we assume there is no hardware rfkill switch, then the user will get an empty list for the list of available networks. Although the empty list vs the "wifi disabled in hardware" message is a regression, it is a very minor regression and it can easily be fixed on a model by model basis by filling the new hw_rfkill_list this commit introduces. Therefor this commit removes the ever growing no_hw_rfkill_list, flipping the default to assuming there is no hw rfkill switch and adding a new hw_rfkill_list. Thereby fixing the wifi not working on all the current ideapad and yoga models which are not on the list yet and also fixing it for all future ideapad and yoga models using the "VPC2004" ACPI interface. Note once this patch has been accepted upstream. I plan to write a blog post asking for users of ideapads and yoga's with a hw rfkill switch to step forward, so that we can populate the new hw_rfkill_list with the few older yoga and ideapad models which actually have a hw rfkill switch. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1703338 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (backported from commit 5105e78e5b2414ec39efaadca1802e37e7105bb1) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
37430e4 Christian Brauner 01 August 2019, 18:08:29 UTC UBUNTU: SAUCE: shiftfs: enable overlayfs on shiftfs BugLink: https://bugs.launchpad.net/bugs/1838677 This patch enables overlayfs to use shiftfs as an underlay. Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Co-Developed-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Christian Brauner <christian.brauner@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:20 UTC
6a8b7d8 Andrea Righi 07 August 2019, 12:46:17 UTC UBUNTU: SAUCE: bcache: fix deadlock in bcache_allocator bcache_allocator() can call the following: bch_allocator_thread() -> bch_prio_write() -> bch_bucket_alloc() -> wait on &ca->set->bucket_wait But the wake up event on bucket_wait is supposed to come from bch_allocator_thread() itself => deadlock: [ 1158.490744] INFO: task bcache_allocato:15861 blocked for more than 10 seconds. [ 1158.495929] Not tainted 5.3.0-050300rc3-generic #201908042232 [ 1158.500653] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1158.504413] bcache_allocato D 0 15861 2 0x80004000 [ 1158.504419] Call Trace: [ 1158.504429] __schedule+0x2a8/0x670 [ 1158.504432] schedule+0x2d/0x90 [ 1158.504448] bch_bucket_alloc+0xe5/0x370 [bcache] [ 1158.504453] ? wait_woken+0x80/0x80 [ 1158.504466] bch_prio_write+0x1dc/0x390 [bcache] [ 1158.504476] bch_allocator_thread+0x233/0x490 [bcache] [ 1158.504491] kthread+0x121/0x140 [ 1158.504503] ? invalidate_buckets+0x890/0x890 [bcache] [ 1158.504506] ? kthread_park+0xb0/0xb0 [ 1158.504510] ret_from_fork+0x35/0x40 Fix by making the call to bch_prio_write() non-blocking, so that bch_allocator_thread() never waits on itself. Moreover, make sure to wake up the garbage collector thread when bch_prio_write() is failing to allocate buckets. BugLink: https://bugs.launchpad.net/bugs/1784665 Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:18:21 UTC
47408e0 Coly Li 07 August 2019, 12:46:16 UTC bcache: improve bcache_reboot() BugLink: https://bugs.launchpad.net/bugs/1784665 This patch tries to release mutex bch_register_lock early, to give chance to stop cache set and bcache device early. This patch also expends time out of stopping all bcache device from 2 seconds to 10 seconds, because stopping writeback rate update worker may delay for 5 seconds, 2 seconds is not enough. After this patch applied, stopping bcache devices during system reboot or shutdown is very hard to be observed any more. Signed-off-by: Coly Li <colyli@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit eb8cbb6df38f6e5124a3d5f1f8a3dbf519537c60) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
98df239 Daniel Axtens 07 August 2019, 12:46:15 UTC bcache: never writeback a discard operation BugLink: https://bugs.launchpad.net/bugs/1784665 Some users see panics like the following when performing fstrim on a bcached volume: [ 529.803060] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 530.183928] #PF error: [normal kernel read fault] [ 530.412392] PGD 8000001f42163067 P4D 8000001f42163067 PUD 1f42168067 PMD 0 [ 530.750887] Oops: 0000 [#1] SMP PTI [ 530.920869] CPU: 10 PID: 4167 Comm: fstrim Kdump: loaded Not tainted 5.0.0-rc1+ #3 [ 531.290204] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 12/27/2015 [ 531.693137] RIP: 0010:blk_queue_split+0x148/0x620 [ 531.922205] Code: 60 38 89 55 a0 45 31 db 45 31 f6 45 31 c9 31 ff 89 4d 98 85 db 0f 84 7f 04 00 00 44 8b 6d 98 4c 89 ee 48 c1 e6 04 49 03 70 78 <8b> 46 08 44 8b 56 0c 48 8b 16 44 29 e0 39 d8 48 89 55 a8 0f 47 c3 [ 532.838634] RSP: 0018:ffffb9b708df39b0 EFLAGS: 00010246 [ 533.093571] RAX: 00000000ffffffff RBX: 0000000000046000 RCX: 0000000000000000 [ 533.441865] RDX: 0000000000000200 RSI: 0000000000000000 RDI: 0000000000000000 [ 533.789922] RBP: ffffb9b708df3a48 R08: ffff940d3b3fdd20 R09: 0000000000000000 [ 534.137512] R10: ffffb9b708df3958 R11: 0000000000000000 R12: 0000000000000000 [ 534.485329] R13: 0000000000000000 R14: 0000000000000000 R15: ffff940d39212020 [ 534.833319] FS: 00007efec26e3840(0000) GS:ffff940d1f480000(0000) knlGS:0000000000000000 [ 535.224098] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 535.504318] CR2: 0000000000000008 CR3: 0000001f4e256004 CR4: 00000000001606e0 [ 535.851759] Call Trace: [ 535.970308] ? mempool_alloc_slab+0x15/0x20 [ 536.174152] ? bch_data_insert+0x42/0xd0 [bcache] [ 536.403399] blk_mq_make_request+0x97/0x4f0 [ 536.607036] generic_make_request+0x1e2/0x410 [ 536.819164] submit_bio+0x73/0x150 [ 536.980168] ? submit_bio+0x73/0x150 [ 537.149731] ? bio_associate_blkg_from_css+0x3b/0x60 [ 537.391595] ? _cond_resched+0x1a/0x50 [ 537.573774] submit_bio_wait+0x59/0x90 [ 537.756105] blkdev_issue_discard+0x80/0xd0 [ 537.959590] ext4_trim_fs+0x4a9/0x9e0 [ 538.137636] ? ext4_trim_fs+0x4a9/0x9e0 [ 538.324087] ext4_ioctl+0xea4/0x1530 [ 538.497712] ? _copy_to_user+0x2a/0x40 [ 538.679632] do_vfs_ioctl+0xa6/0x600 [ 538.853127] ? __do_sys_newfstat+0x44/0x70 [ 539.051951] ksys_ioctl+0x6d/0x80 [ 539.212785] __x64_sys_ioctl+0x1a/0x20 [ 539.394918] do_syscall_64+0x5a/0x110 [ 539.568674] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We have observed it where both: 1) LVM/devmapper is involved (bcache backing device is LVM volume) and 2) writeback cache is involved (bcache cache_mode is writeback) On one machine, we can reliably reproduce it with: # echo writeback > /sys/block/bcache0/bcache/cache_mode (not sure whether above line is required) # mount /dev/bcache0 /test # for i in {0..10}; do file="$(mktemp /test/zero.XXX)" dd if=/dev/zero of="$file" bs=1M count=256 sync rm $file done # fstrim -v /test Observing this with tracepoints on, we see the following writes: fstrim-18019 [022] .... 91107.302026: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4260112 + 196352 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302050: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4456464 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302075: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4718608 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302094: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5324816 + 180224 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302121: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5505040 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302145: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5767184 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.308777: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 6373392 + 180224 hit 1 bypass 0 <crash> Note the final one has different hit/bypass flags. This is because in should_writeback(), we were hitting a case where the partial stripe condition was returning true and so should_writeback() was returning true early. If that hadn't been the case, it would have hit the would_skip test, and as would_skip == s->iop.bypass == true, should_writeback() would have returned false. Looking at the git history from 'commit 72c270612bd3 ("bcache: Write out full stripes")', it looks like the idea was to optimise for raid5/6: * If a stripe is already dirty, force writes to that stripe to writeback mode - to help build up full stripes of dirty data To fix this issue, make sure that should_writeback() on a discard op never returns true. More details of debugging: https://www.spinics.net/lists/linux-bcache/msg06996.html Previous reports: - https://bugzilla.kernel.org/show_bug.cgi?id=201051 - https://bugzilla.kernel.org/show_bug.cgi?id=196103 - https://www.spinics.net/lists/linux-bcache/msg06885.html (Coly Li: minor modification to follow maximum 75 chars per line rule) Cc: Kent Overstreet <koverstreet@google.com> Cc: stable@vger.kernel.org Fixes: 72c270612bd3 ("bcache: Write out full stripes") Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit 9951379b0ca88c95876ad9778b9099e19a95d566) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
94d6eb9 Nicolin Chen 08 August 2019, 00:43:14 UTC dma-contiguous: page-align the size in dma_free_contiguous() BugLink: https://bugs.launchpad.net/bugs/1839395 According to the original dma_direct_alloc_pages() code: { unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT; if (!dma_release_from_contiguous(dev, page, count)) __free_pages(page, get_order(size)); } The count parameter for dma_release_from_contiguous() was page aligned before the right-shifting operation, while the new API dma_free_contiguous() forgets to have PAGE_ALIGN() at the size. So this patch simply adds it to prevent any corner case. Fixes: fdaeec198ada ("dma-contiguous: add dma_{alloc,free}_contiguous() helpers") Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christoph Hellwig <hch@lst.de> (cherry picked from commit f46cc0152501e46d1b3aa5e7eade61145070eab0) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
e422ace Nicolin Chen 08 August 2019, 00:43:13 UTC dma-contiguous: do not overwrite align in dma_alloc_contiguous() BugLink: https://bugs.launchpad.net/bugs/1839395 The dma_alloc_contiguous() limits align at CONFIG_CMA_ALIGNMENT for cma_alloc() however it does not restore it for the fallback routine. This will result in a size mismatch between the allocation and free when running into the fallback routines after cma_alloc() fails, if the align is larger than CONFIG_CMA_ALIGNMENT. This patch adds a cma_align to take care of cma_alloc() and prevent the align from being overwritten. Fixes: fdaeec198ada ("dma-contiguous: add dma_{alloc,free}_contiguous() helpers") Reported-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> (cherry picked from commit c6622a425acd1d2f3a443cd39b490a8777b622d7) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
2810960 Jason Wang 08 August 2019, 04:43:35 UTC vhost: scsi: add weight support This patch will check the weight and exit the loop if we exceeds the weight. This is useful for preventing scsi kthread from hogging cpu which is guest triggerable. This addresses CVE-2019-3900. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Fixes: 057cbf49a1f0 ("tcm_vhost: Initial merge for vhost level target fabric driver") Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> CVE-2019-3900 (cherry picked from commit c1ea02f15ab5efb3e93fc3144d895410bf79fcf2) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
5be4521 Jason Wang 08 August 2019, 04:43:34 UTC vhost: vsock: add weight support This patch will check the weight and exit the loop if we exceeds the weight. This is useful for preventing vsock kthread from hogging cpu which is guest triggerable. The weight can help to avoid starving the request from on direction while another direction is being processed. The value of weight is picked from vhost-net. This addresses CVE-2019-3900. Cc: Stefan Hajnoczi <stefanha@redhat.com> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko") Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> CVE-2019-3900 (cherry picked from commit e79b431fb901ba1106670bcc80b9b617b25def7d) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
16b15d2 Jason Wang 08 August 2019, 04:43:33 UTC vhost_net: fix possible infinite loop When the rx buffer is too small for a packet, we will discard the vq descriptor and retry it for the next packet: while ((sock_len = vhost_net_rx_peek_head_len(net, sock->sk, &busyloop_intr))) { ... /* On overrun, truncate and discard */ if (unlikely(headcount > UIO_MAXIOV)) { iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1); err = sock->ops->recvmsg(sock, &msg, 1, MSG_DONTWAIT | MSG_TRUNC); pr_debug("Discarded rx packet: len %zd\n", sock_len); continue; } ... } This makes it possible to trigger a infinite while..continue loop through the co-opreation of two VMs like: 1) Malicious VM1 allocate 1 byte rx buffer and try to slow down the vhost process as much as possible e.g using indirect descriptors or other. 2) Malicious VM2 generate packets to VM1 as fast as possible Fixing this by checking against weight at the end of RX and TX loop. This also eliminate other similar cases when: - userspace is consuming the packets in the meanwhile - theoretical TOCTOU attack if guest moving avail index back and forth to hit the continue after vhost find guest just add new buffers This addresses CVE-2019-3900. Fixes: d8316f3991d20 ("vhost: fix total length when packets are too short") Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server") Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> CVE-2019-3900 (cherry picked from commit e2412c07f8f3040593dfb88207865a3cd58680c0) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
99a79c6 Jason Wang 08 August 2019, 04:43:32 UTC vhost: introduce vhost_exceeds_weight() We used to have vhost_exceeds_weight() for vhost-net to: - prevent vhost kthread from hogging the cpu - balance the time spent between TX and RX This function could be useful for vsock and scsi as well. So move it to vhost.c. Device must specify a weight which counts the number of requests, or it can also specific a byte_weight which counts the number of bytes that has been processed. Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> CVE-2019-3900 (cherry picked from commit e82b9b0727ff6d665fff2d326162b460dded554d) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> 13 August 2019, 12:11:36 UTC
9d89912 Greg Kroah-Hartman 04 June 2019, 06:01:31 UTC Linux 5.0.21 BugLink: https://bugs.launchpad.net/bugs/1837518 Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
deb3a5e Junwei Hu 20 May 2019, 06:43:59 UTC tipc: fix modprobe tipc failed after switch order of device registration BugLink: https://bugs.launchpad.net/bugs/1837518 commit 526f5b851a96566803ee4bee60d0a34df56c77f8 upstream. Error message printed: modprobe: ERROR: could not insert 'tipc': Address family not supported by protocol. when modprobe tipc after the following patch: switch order of device registration, commit 7e27e8d6130c ("tipc: switch order of device registration to fix a crash") Because sock_create_kern(net, AF_TIPC, ...) called by tipc_topsrv_create_listener() in the initialization process of tipc_init_net(), so tipc_socket_init() must be execute before that. Meanwhile, tipc_net_id need to be initialized when sock_create() called, and tipc_socket_init() is no need to be called for each namespace. I add a variable tipc_topsrv_net_ops, and split the register_pernet_subsys() of tipc into two parts, and split tipc_socket_init() with initialization of pernet params. By the way, I fixed resources rollback error when tipc_bcast_init() failed in tipc_init_net(). Fixes: 7e27e8d6130c ("tipc: switch order of device registration to fix a crash") Signed-off-by: Junwei Hu <hujunwei4@huawei.com> Reported-by: Wang Wang <wangwang2@huawei.com> Reported-by: syzbot+1e8114b61079bfe9cbc5@syzkaller.appspotmail.com Reviewed-by: Kang Zhou <zhoukang7@huawei.com> Reviewed-by: Suanming Mou <mousuanming@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
6d6b53c David S. Miller 17 May 2019, 19:15:05 UTC Revert "tipc: fix modprobe tipc failed after switch order of device registration" BugLink: https://bugs.launchpad.net/bugs/1837518 commit 5593530e56943182ebb6d81eca8a3be6db6dbba4 upstream. This reverts commit 532b0f7ece4cb2ffd24dc723ddf55242d1188e5e. More revisions coming up. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
59042d9 Konrad Rzeszutek Wilk 13 February 2019, 23:21:31 UTC xen/pciback: Don't disable PCI_COMMAND on PCI device reset. BugLink: https://bugs.launchpad.net/bugs/1837518 commit 7681f31ec9cdacab4fd10570be924f2cef6669ba upstream. There is no need for this at all. Worst it means that if the guest tries to write to BARs it could lead (on certain platforms) to PCI SERR errors. Please note that with af6fc858a35b90e89ea7a7ee58e66628c55c776b "xen-pciback: limit guest control of command register" a guest is still allowed to enable those control bits (safely), but is not allowed to disable them and that therefore a well behaved frontend which enables things before using them will still function correctly. This is done via an write to the configuration register 0x4 which triggers on the backend side: command_write \- pci_enable_device \- pci_enable_device_flags \- do_pci_enable_device \- pcibios_enable_device \-pci_enable_resourcess [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO] However guests (and drivers) which don't do this could cause problems, including the security issues which XSA-120 sought to address. Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Juergen Gross <jgross@suse.com> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
ccfd9be Daniel Axtens 16 May 2019, 15:40:02 UTC crypto: vmx - ghash: do nosimd fallback manually BugLink: https://bugs.launchpad.net/bugs/1837518 commit 357d065a44cdd77ed5ff35155a989f2a763e96ef upstream. VMX ghash was using a fallback that did not support interleaving simd and nosimd operations, leading to failures in the extended test suite. If I understood correctly, Eric's suggestion was to use the same data format that the generic code uses, allowing us to call into it with the same contexts. I wasn't able to get that to work - I think there's a very different key structure and data layout being used. So instead steal the arm64 approach and perform the fallback operations directly if required. Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module") Cc: stable@vger.kernel.org # v4.1+ Reported-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
e73c227 Willem de Bruijn 30 May 2019, 22:01:21 UTC net: correct zerocopy refcnt with udp MSG_MORE BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 100f6d8e09905c59be45b6316f8f369c0be1b2d8 ] TCP zerocopy takes a uarg reference for every skb, plus one for the tcp_sendmsg_locked datapath temporarily, to avoid reaching refcnt zero as it builds, sends and frees skbs inside its inner loop. UDP and RAW zerocopy do not send inside the inner loop so do not need the extra sock_zerocopy_get + sock_zerocopy_put pair. Commit 52900d22288ed ("udp: elide zerocopy operation in hot path") introduced extra_uref to pass the initial reference taken in sock_zerocopy_alloc to the first generated skb. But, sock_zerocopy_realloc takes this extra reference at the start of every call. With MSG_MORE, no new skb may be generated to attach the extra_uref to, so refcnt is incorrectly 2 with only one skb. Do not take the extra ref if uarg && !tcp, which implies MSG_MORE. Update extra_uref accordingly. This conditional assignment triggers a false positive may be used uninitialized warning, so have to initialize extra_uref at define. Changes v1->v2: fix typo in Fixes SHA1 Fixes: 52900d22288e7 ("udp: elide zerocopy operation in hot path") Reported-by: syzbot <syzkaller@googlegroups.com> Diagnosed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
ddf79a0 Vishal Kulkarni 23 May 2019, 02:37:21 UTC cxgb4: Revert "cxgb4: Remove SGE_HOST_PAGE_SIZE dependency on page size" BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit ab0610efabb4c4f419a531455708caf1dd29357e ] This reverts commit 2391b0030e241386d710df10e53e2cfc3c5d4fc1 which has introduced regression. Now SGE's BAR2 Doorbell/GTS Page Size is interpreted correctly in the firmware itself by using actual host page size. Hence previous commit needs to be reverted. Signed-off-by: Vishal Kulkarni <vishal@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
5246c43 Jakub Kicinski 22 May 2019, 02:02:02 UTC net/tls: don't ignore netdev notifications if no TLS features BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit c3f4a6c39cf269a40d45f813c05fa830318ad875 ] On device surprise removal path (the notifier) we can't bail just because the features are disabled. They may have been enabled during the lifetime of the device. This bug leads to leaking netdev references and use-after-frees if there are active connections while device features are cleared. Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
b668d06 Jakub Kicinski 22 May 2019, 02:02:01 UTC net/tls: fix state removal with feature flags off BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 3686637e507b48525fcea6fb91e1988bdbc14530 ] TLS offload drivers shouldn't (and currently don't) block the TLS offload feature changes based on whether there are active offloaded connections or not. This seems to be a good idea, because we want the admin to be able to disable the TLS offload at any time, and there is no clean way of disabling it for active connections (TX side is quite problematic). So if features are cleared existing connections will stay offloaded until they close, and new connections will not attempt offload to a given device. However, the offload state removal handling is currently broken if feature flags get cleared while there are active TLS offloads. RX side will completely bail from cleanup, even on normal remove path, leaving device state dangling, potentially causing issues when the 5-tuple is reused. It will also fail to release the netdev reference. Remove the RX-side warning message, in next release cycle it should be printed when features are disabled, rather than when connection dies, but for that we need a more efficient method of finding connection of a given netdev (a'la BPF offload code). Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
f63983e Michael Chan 22 May 2019, 23:12:56 UTC bnxt_en: Reduce memory usage when running in kdump kernel. BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit d629522e1d66561f38e5c8d4f52bb6d254ec0707 ] Skip RDMA context memory allocations, reduce to 1 ring, and disable TPA when running in the kdump kernel. Without this patch, the driver fails to initialize with memory allocation errors when running in a typical kdump kernel. Fixes: cf6daed098d1 ("bnxt_en: Increase context memory allocations on 57500 chips for RDMA.") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
46d06c7 Michael Chan 22 May 2019, 23:12:55 UTC bnxt_en: Fix possible BUG() condition when calling pci_disable_msix(). BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 1b3f0b75c39f534278a895c117282014e9d0ae1f ] When making configuration changes, the driver calls bnxt_close_nic() and then bnxt_open_nic() for the changes to take effect. A parameter irq_re_init is passed to the call sequence to indicate if IRQ should be re-initialized. This irq_re_init parameter needs to be included in the bnxt_reserve_rings() call. bnxt_reserve_rings() can only call pci_disable_msix() if the irq_re_init parameter is true, otherwise it may hit BUG() because some IRQs may not have been freed yet. Fixes: 41e8d7983752 ("bnxt_en: Modify the ring reservation functions for 57500 series chips.") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
b050f80 Michael Chan 22 May 2019, 23:12:54 UTC bnxt_en: Fix aggregation buffer leak under OOM condition. BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 296d5b54163964b7ae536b8b57dfbd21d4e868e1 ] For every RX packet, the driver replenishes all buffers used for that packet and puts them back into the RX ring and RX aggregation ring. In one code path where the RX packet has one RX buffer and one or more aggregation buffers, we missed recycling the aggregation buffer(s) if we are unable to allocate a new SKB buffer. This leads to the aggregation ring slowly running out of buffers over time. Fix it by properly recycling the aggregation buffers. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reported-by: Rakesh Hemnani <rhemnani@fb.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
6d51a37 Weifeng Voon 21 May 2019, 05:38:38 UTC net: stmmac: dma channel control register need to be init first BugLink: https://bugs.launchpad.net/bugs/1837518 stmmac_init_chan() needs to be called before stmmac_init_rx_chan() and stmmac_init_tx_chan(). This is because if PBLx8 is to be used, "DMA_CH(#i)_Control.PBLx8" needs to be set before programming "DMA_CH(#i)_TX_Control.TxPBL" and "DMA_CH(#i)_RX_Control.RxPBL". Fixes: 47f2a9ce527a ("net: stmmac: dma channel init prepared for multiple queues") Reviewed-by: Zhang, Baoli <baoli.zhang@intel.com> Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Weifeng Voon <weifeng.voon@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
2450edb Tan, Tee Min 21 May 2019, 04:55:42 UTC net: stmmac: fix ethtool flow control not able to get/set BugLink: https://bugs.launchpad.net/bugs/1837518 Currently ethtool was not able to get/set the flow control due to a missing "!". It will always return -EOPNOTSUPP even the device is flow control supported. This patch fixes the condition check for ethtool flow control get/set function for ETHTOOL_LINK_MODE_Asym_Pause_BIT. Fixes: 3c1bcc8614db (“net: ethernet: Convert phydev advertize and supported from u32 to link mode”) Signed-off-by: Tan, Tee Min <tee.min.tan@intel.com> Reviewed-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Voon, Weifeng <weifeng.voon@intel.com@intel.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
ee0b874 Saeed Mahameed 23 May 2019, 19:55:10 UTC net/mlx5e: Disable rxhash when CQE compress is enabled BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit c0194e2d0ef0e5ce5e21a35640d23a706827ae28 ] When CQE compression is enabled (Multi-host systems), compressed CQEs might arrive to the driver rx, compressed CQEs don't have a valid hash offload and the driver already reports a hash value of 0 and invalid hash type on the skb for compressed CQEs, but this is not good enough. On a congested PCIe, where CQE compression will kick in aggressively, gro will deliver lots of out of order packets due to the invalid hash and this might cause a serious performance drop. The only valid solution, is to disable rxhash offload at all when CQE compression is favorable (Multi-host systems). Fixes: 7219ab34f184 ("net/mlx5e: CQE compression") Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
10b4b76 Parav Pandit 10 May 2019, 15:40:08 UTC net/mlx5: Allocate root ns memory using kzalloc to match kfree BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 25fa506b70cadb580c1e9cbd836d6417276d4bcd ] root ns is yet another fs core node which is freed using kfree() by tree_put_node(). Rest of the other fs core objects are also allocated using kmalloc variants. However, root ns memory is allocated using kvzalloc(). Hence allocate root ns memory using kzalloc(). Fixes: 2530236303d9e ("net/mlx5_core: Flow steering tree initialization") Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Daniel Jurgens <danielj@mellanox.com> Reviewed-by: Mark Bloch <markb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
714712c Chris Packham 20 May 2019, 03:45:36 UTC tipc: Avoid copying bytes beyond the supplied data BugLink: https://bugs.launchpad.net/bugs/1837518 TLV_SET is called with a data pointer and a len parameter that tells us how many bytes are pointed to by data. When invoking memcpy() we need to careful to only copy len bytes. Previously we would copy TLV_LENGTH(len) bytes which would copy an extra 4 bytes past the end of the data pointer which newer GCC versions complain about. In file included from test.c:17: In function 'TLV_SET', inlined from 'test' at test.c:186:5: /usr/include/linux/tipc_config.h:317:3: warning: 'memcpy' forming offset [33, 36] is out of the bounds [0, 32] of object 'bearer_name' with type 'char[32]' [-Warray-bounds] memcpy(TLV_DATA(tlv_ptr), data, tlv_len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ test.c: In function 'test': test.c::161:10: note: 'bearer_name' declared here char bearer_name[TIPC_MAX_BEARER_NAME]; ^~~~~~~~~~~ We still want to ensure any padding bytes at the end are initialised, do this with a explicit memset() rather than copy bytes past the end of data. Apply the same logic to TCM_SET. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
01a76ee Parav Pandit 10 May 2019, 15:26:23 UTC net/mlx5: Avoid double free in fs init error unwinding path BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 9414277a5df3669c67e818708c0f881597e0118e ] In below code flow, for ingress acl table root ns memory leads to double free. mlx5_init_fs init_ingress_acls_root_ns() init_ingress_acl_root_ns kfree(steering->esw_ingress_root_ns); /* steering->esw_ingress_root_ns is not marked NULL */ mlx5_cleanup_fs cleanup_ingress_acls_root_ns steering->esw_ingress_root_ns non NULL check passes. kfree(steering->esw_ingress_root_ns); /* double free */ Similar issue exist for other tables. Hence zero out the pointers to not process the table again. Fixes: 9b93ab981e3bf ("net/mlx5: Separate ingress/egress namespaces for each vport") Fixes: 40c3eebb49e51 ("net/mlx5: Add support in RDMA RX steering") Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Mark Bloch <markb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
c51ca62 Kloetzke Jan 21 May 2019, 13:18:40 UTC usbnet: fix kernel crash after disconnect BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ] When disconnecting cdc_ncm the kernel sporadically crashes shortly after the disconnect: [ 57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... [ 58.006653] PC is at 0x0 [ 58.009202] LR is at call_timer_fn+0xec/0x1b4 [ 58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145 [ 58.020976] sp : ffffff8008003da0 [ 58.024295] x29: ffffff8008003da0 x28: 0000000000000001 [ 58.029618] x27: 000000000000000a x26: 0000000000000100 [ 58.034941] x25: 0000000000000000 x24: ffffff8008003e68 [ 58.040263] x23: 0000000000000000 x22: 0000000000000000 [ 58.045587] x21: 0000000000000000 x20: ffffffc68fac1808 [ 58.050910] x19: 0000000000000100 x18: 0000000000000000 [ 58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10 [ 58.061556] x15: 0000000000000001 x14: 000000000000006e [ 58.066878] x13: 0000000000000000 x12: 00000000000000ba [ 58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020 [ 58.077524] x9 : 8000100008001000 x8 : 0000000000000001 [ 58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70 [ 58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b [ 58.093492] x3 : 0000000000000000 x2 : 0000000000000000 [ 58.098814] x1 : 0000000000000000 x0 : 0000000000000000 ... [ 58.205800] [< (null)>] (null) [ 58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c [ 58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128 [ 58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348 [ 58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc [ 58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac [ 58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac ... The crash happens roughly 125..130ms after the disconnect. This correlates with the 'delay' timer that is started on certain USB tx/rx errors in the URB completion handler. The problem is a race of usbnet_stop() with usbnet_start_xmit(). In usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in flight. This only makes sense if no new URBs are submitted concurrently, though. But the usbnet_start_xmit() can run at the same time on another CPU which almost unconditionally submits an URB. The error callback of the new URB will then schedule the timer after it was already stopped. The fix adds a check if the tx queue is stopped after the tx list lock has been taken. This should reliably prevent the submission of new URBs while usbnet_terminate_urbs() does its job. The same thing is done on the rx side even though it might be safe due to other flags that are checked there. Signed-off-by: Jan Klötzke <Jan.Kloetzke@preh.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
f82aa78 Heiner Kallweit 29 May 2019, 05:44:01 UTC r8169: fix MAC address being lost in PCI D3 BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 59715171fbd0172a579576f46821031800a63bc5 ] (At least) RTL8168e forgets its MAC address in PCI D3. To fix this set the MAC address when resuming. For resuming from runtime-suspend we had this in place already, for resuming from S3/S5 it was missing. The commit referenced as being fixed isn't wrong, it's just the first one where the patch applies cleanly. Fixes: 0f07bd850d36 ("r8169: use dev_get_drvdata where possible") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reported-by: Albert Astals Cid <aacid@kde.org> Tested-by: Albert Astals Cid <aacid@kde.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
97a6456 Jisheng Zhang 22 May 2019, 10:05:09 UTC net: stmmac: fix reset gpio free missing BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 49ce881c0d4c4a7a35358d9dccd5f26d0e56fc61 ] Commit 984203ceff27 ("net: stmmac: mdio: remove reset gpio free") removed the reset gpio free, when the driver is unbinded or rmmod, we miss the gpio free. This patch uses managed API to request the reset gpio, so that the gpio could be freed properly. Fixes: 984203ceff27 ("net: stmmac: mdio: remove reset gpio free") Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
b298d4e Vlad Buslov 23 May 2019, 06:32:31 UTC net: sched: don't use tc_action->order during action dump BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 4097e9d250fb17958c1d9b94538386edd3f20144 ] Function tcf_action_dump() relies on tc_action->order field when starting nested nla to send action data to userspace. This approach breaks in several cases: - When multiple filters point to same shared action, tc_action->order field is overwritten each time it is attached to filter. This causes filter dump to output action with incorrect attribute for all filters that have the action in different position (different order) from the last set tc_action->order value. - When action data is displayed using tc action API (RTM_GETACTION), action order is overwritten by tca_action_gd() according to its position in resulting array of nl attributes, which will break filter dump for all filters attached to that shared action that expect it to have different order value. Don't rely on tc_action->order when dumping actions. Set nla according to action position in resulting array of actions instead. Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
a5de42c Russell King 28 May 2019, 09:34:42 UTC net: phy: marvell10g: report if the PHY fails to boot firmware BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 3d3ced2ec5d71b99d72ae6910fbdf890bc2eccf0 ] Some boards do not have the PHY firmware programmed in the 3310's flash, which leads to the PHY not working as expected. Warn the user when the PHY fails to boot the firmware and refuse to initialise. Fixes: 20b2af32ff3f ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
73a3214 Antoine Tenart 29 May 2019, 13:59:48 UTC net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 21808437214637952b61beaba6034d97880fbeb3 ] MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but the current code is passing the global tx queue offset, so it ends up writing to unknown registers (between 0x8280 and 0x82fc, which seemed to be unused by the hardware). This fixes the issue by using the logical queue id instead. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
78a1c47 Jisheng Zhang 27 May 2019, 11:04:17 UTC net: mvneta: Fix err code path of probe BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit d484e06e25ebb937d841dac02ac1fe76ec7d4ddd ] Fix below issues in err code path of probe: 1. we don't need to unregister_netdev() because the netdev isn't registered. 2. when register_netdev() fails, we also need to destroy bm pool for HWBM case. Fixes: dc35a10f68d3 ("net: mvneta: bm: add support for hardware buffer management") Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
510040a Eric Dumazet 29 May 2019, 22:36:10 UTC net-gro: fix use-after-free read in napi_gro_frags() BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit a4270d6795b0580287453ea55974d948393e66ef ] If a network driver provides to napi_gro_frags() an skb with a page fragment of exactly 14 bytes, the call to gro_pull_from_frag0() will 'consume' the fragment by calling skb_frag_unref(skb, 0), and the page might be freed and reused. Reading eth->h_proto at the end of napi_frags_skb() might read mangled data, or crash under specific debugging features. BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline] BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841 Read of size 2 at addr ffff88809366840c by task syz-executor599/8957 CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188 __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 kasan_report+0x12/0x20 mm/kasan/common.c:614 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142 napi_frags_skb net/core/dev.c:5833 [inline] napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841 tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991 tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037 call_write_iter include/linux/fs.h:1872 [inline] do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693 do_iter_write fs/read_write.c:970 [inline] do_iter_write+0x184/0x610 fs/read_write.c:951 vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015 do_writev+0x15b/0x330 fs/read_write.c:1058 Fixes: a50e233c50db ("net-gro: restore frag0 optimization") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
62473e2 Andy Duan 23 May 2019, 01:55:28 UTC net: fec: fix the clk mismatch in failed_reset path BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit ce8d24f9a5965a58c588f9342689702a1024433c ] Fix the clk mismatch in the error path "failed_reset" because below error path will disable clk_ahb and clk_ipg directly, it should use pm_runtime_put_noidle() instead of pm_runtime_put() to avoid to call runtime resume callback. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Tested-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
a9873df Rasmus Villemoes 29 May 2019, 07:02:11 UTC net: dsa: mv88e6xxx: fix handling of upper half of STATS_TYPE_PORT BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 84b3fd1fc9592d431e23b077e692fa4e3fd0f086 ] Currently, the upper half of a 4-byte STATS_TYPE_PORT statistic ends up in bits 47:32 of the return value, instead of bits 31:16 as they should. Fixes: 6e46e2d821bb ("net: dsa: mv88e6xxx: Fix u64 statistics") Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
1e2be5c Jiri Pirko 29 May 2019, 07:59:44 UTC mlxsw: spectrum_acl: Avoid warning after identical rules insertion BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit ef74422020aa8c224b00a927e3e47faac4d8fae3 ] When identical rules are inserted, the latter one goes to C-TCAM. For that, a second eRP with the same mask is created. These 2 eRPs by the nature cannot be merged and also one cannot be parent of another. Teach mlxsw_sp_acl_erp_delta_fill() about this possibility and handle it gracefully. Reported-by: Alex Kushnarov <alexanderk@mellanox.com> Fixes: c22291f7cf45 ("mlxsw: spectrum: acl: Implement delta for ERP") Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
8d0b539 Eric Dumazet 28 May 2019, 00:35:52 UTC llc: fix skb leak in llc_build_and_send_ui_pkt() BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 8fb44d60d4142cd2a440620cd291d346e23c131e ] If llc_mac_hdr_init() returns an error, we must drop the skb since no llc_build_and_send_ui_pkt() caller will take care of this. BUG: memory leak unreferenced object 0xffff8881202b6800 (size 2048): comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.590s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline] [<00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline] [<00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline] [<00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669 [<00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline] [<00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608 [<00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662 [<000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950 [<00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173 [<0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430 [<000000008bdec225>] sock_create net/socket.c:1481 [inline] [<000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523 [<00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline] [<00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline] [<00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530 [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0xffff88811d750d00 (size 224): comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.600s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff ...$.....h+ .... backtrace: [<0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline] [<0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline] [<0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579 [<00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198 [<00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline] [<00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327 [<000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225 [<00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242 [<00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933 [<00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline] [<00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671 [<000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964 [<00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline] [<00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline] [<00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972 [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
5c7a4af David Ahern 22 May 2019, 22:12:18 UTC ipv6: Fix redirect with VRF BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 31680ac265802397937d75461a2809a067b9fb93 ] IPv6 redirect is broken for VRF. __ip6_route_redirect walks the FIB entries looking for an exact match on ifindex. With VRF the flowi6_oif is updated by l3mdev_update_flow to the l3mdev index and the FLOWI_FLAG_SKIP_NH_OIF set in the flags to tell the lookup to skip the device match. For redirects the device match is requires so use that flag to know when the oif needs to be reset to the skb device index. Fixes: ca254490c8df ("net: Add VRF support to IPv6 stack") Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
0ad92f6 Mike Manning 20 May 2019, 18:57:17 UTC ipv6: Consider sk_bound_dev_if when binding a raw socket to an address BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 72f7cfab6f93a8ea825fab8ccfb016d064269f7f ] IPv6 does not consider if the socket is bound to a device when binding to an address. The result is that a socket can be bound to eth0 and then bound to the address of eth1. If the device is a VRF, the result is that a socket can only be bound to an address in the default VRF. Resolve by considering the device if sk_bound_dev_if is set. Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com> Reviewed-by: David Ahern <dsahern@gmail.com> Tested-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
3558528 Eric Dumazet 23 May 2019, 01:35:16 UTC ipv4/igmp: fix build error if !CONFIG_IP_MULTICAST BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 903869bd10e6719b9df6718e785be7ec725df59f ] ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST Fixes: 3580d04aa674 ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
c261006 Eric Dumazet 22 May 2019, 23:51:22 UTC ipv4/igmp: fix another memory leak in igmpv3_del_delrec() BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 3580d04aa674383c42de7b635d28e52a1e5bc72c ] syzbot reported memory leaks [1] that I have back tracked to a missing cleanup from igmpv3_del_delrec() when (im->sfmode != MCAST_INCLUDE) Add ip_sf_list_clear_all() and kfree_pmc() helpers to explicitely handle the cleanups before freeing. [1] BUG: memory leak unreferenced object 0xffff888123e32b00 (size 64): comm "softirq", pid 0, jiffies 4294942968 (age 8.010s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 e0 00 00 01 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000006105011b>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<000000006105011b>] slab_post_alloc_hook mm/slab.h:439 [inline] [<000000006105011b>] slab_alloc mm/slab.c:3326 [inline] [<000000006105011b>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<000000004bba8073>] kmalloc include/linux/slab.h:547 [inline] [<000000004bba8073>] kzalloc include/linux/slab.h:742 [inline] [<000000004bba8073>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline] [<000000004bba8073>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085 [<00000000a46a65a0>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475 [<000000005956ca89>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:957 [<00000000848e2d2f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246 [<00000000b9db185c>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616 [<000000003028e438>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130 [<0000000015b65589>] __sys_setsockopt+0x98/0x120 net/socket.c:2078 [<00000000ac198ef0>] __do_sys_setsockopt net/socket.c:2089 [inline] [<00000000ac198ef0>] __se_sys_setsockopt net/socket.c:2086 [inline] [<00000000ac198ef0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 [<000000000a770437>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<00000000d3adb93b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 9c8bb163ae78 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hangbin Liu <liuhangbin@gmail.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
344a790 Eric Dumazet 27 March 2019, 19:40:33 UTC inet: switch IP ID generator to siphash BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit df453700e8d81b1bdafdf684365ee2b9431fb702 ] According to Amit Klein and Benny Pinkas, IP ID generation is too weak and might be used by attackers. Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix()) having 64bit key and Jenkins hash is risky. It is time to switch to siphash and its 128bit keys. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Amit Klein <aksecurity@gmail.com> Reported-by: Benny Pinkas <benny@pinkas.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
61adca8 Raju Rangoju 23 May 2019, 15:11:44 UTC cxgb4: offload VLAN flows regardless of VLAN ethtype BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit b5730061d1056abf317caea823b94d6e12b5b4f6 ] VLAN flows never get offloaded unless ivlan_vld is set in filter spec. It's not compulsory for vlan_ethtype to be set. So, always enable ivlan_vld bit for offloading VLAN flows regardless of vlan_ethtype is set or not. Fixes: ad9af3e09c (cxgb4: add tc flower match support for vlan) Signed-off-by: Raju Rangoju <rajur@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
2ee84ec Jarod Wilson 24 May 2019, 13:49:28 UTC bonding/802.3ad: fix slave link initialization transition states BugLink: https://bugs.launchpad.net/bugs/1837518 [ Upstream commit 334031219a84b9994594015aab85ed7754c80176 ] Once in a while, with just the right timing, 802.3ad slaves will fail to properly initialize, winding up in a weird state, with a partner system mac address of 00:00:00:00:00:00. This started happening after a fix to properly track link_failure_count tracking, where an 802.3ad slave that reported itself as link up in the miimon code, but wasn't able to get a valid speed/duplex, started getting set to BOND_LINK_FAIL instead of BOND_LINK_DOWN. That was the proper thing to do for the general "my link went down" case, but has created a link initialization race that can put the interface in this odd state. The simple fix is to instead set the slave link to BOND_LINK_DOWN again, if the link has never been up (last_link_up == 0), so the link state doesn't bounce from BOND_LINK_DOWN to BOND_LINK_FAIL -- it hasn't failed in this case, it simply hasn't been up yet, and this prevents the unnecessary state change from DOWN to FAIL and getting stuck in an init failure w/o a partner mac. Fixes: ea53abfab960 ("bonding/802.3ad: fix link_failure_count tracking") CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: netdev@vger.kernel.org Tested-by: Heesoon Kim <Heesoon.Kim@stratus.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
221f400 Greg Kroah-Hartman 31 May 2019, 13:45:24 UTC Linux 5.0.20 BugLink: https://bugs.launchpad.net/bugs/1837517 Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
167a607 Benjamin Coddington 09 May 2019, 11:25:21 UTC NFS: Fix a double unlock from nfs_match,get_client BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit c260121a97a3e4df6536edbc2f26e166eff370ce ] Now that nfs_match_client drops the nfs_client_lock, we should be careful to always return it in the same condition: locked. Fixes: 950a578c6128 ("NFS: make nfs_match_client killable") Reported-by: syzbot+228a82b263b5da91883d@syzkaller.appspotmail.com Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
1a03832 Maxime Ripard 11 February 2019, 14:41:24 UTC drm/sun4i: dsi: Enforce boundaries on the start delay BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit efa31801203ac2f5c6a82a28cb991c7163ee0f1d ] The Allwinner BSP makes sure that we don't end up with a null start delay or with a delay larger than vtotal. The former condition is likely to happen now with the reworked start delay, so make sure we enforce the same boundaries. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/c9889cf5f7a3d101ef380905900b45a182596f56.1549896081.git-series.maxime.ripard@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
a032dcb Brett Creeley 13 February 2019, 18:51:14 UTC ice: Put __ICE_PREPARED_FOR_RESET check in ice_prepare_for_reset BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 5abac9d7e1bb9a373673811154774d4c89a7f85e ] Currently we check if the __ICE_PREPARED_FOR_RESET bit is set prior to calling ice_prepare_for_reset in ice_reset_subtask(), but we aren't checking that bit in ice_do_reset() before calling ice_prepare_for_reset(). This is not consistent and can cause issues if ice_prepare_for_reset() is called prior to ice_do_reset(). Fix this by checking if the __ICE_PREPARED_FOR_RESET bit is set internal to ice_prepare_for_reset(). Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
c7aac8e Farhan Ali 16 April 2019, 21:23:14 UTC vfio-ccw: Prevent quiesce function going into an infinite loop BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit d1ffa760d22aa1d8190478e5ef555c59a771db27 ] The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we: - wait for any interrupts - flush all I/O in the workqueue - retry cio_cancel_halt_clear During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever. Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device. Suggested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
51a9f47 Maxime Ripard 11 February 2019, 14:41:23 UTC drm/sun4i: dsi: Change the start delay calculation BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit da676c6aa6413d59ab0a80c97bbc273025e640b2 ] The current calculation for the video start delay in the current DSI driver is that it is the total vertical size, minus the front porch and sync length, plus 1. This equals to the active vertical size plus the back porch plus 1. That 1 is coming in the Allwinner BSP from an variable that is set to 1. However, if we look at the Allwinner BSP more closely, and especially in the "legacy" code for the display (in drivers/video/sunxi/legacy/), we can see that this variable is actually computed from the porches and the sync minus 10, clamped between 8 and 100. This fixes the start delay symptom we've seen on some panels (vblank timeouts with vertical white stripes at the bottom of the panel). Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e5f72e68f47ca0223877464bf12f0c3f3978de8.1549896081.git-series.maxime.ripard@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
9c48640 Chris Wilson 04 August 2017, 08:23:28 UTC drm: Wake up next in drm_read() chain if we are forced to putback the event BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 60b801999c48b6c1dd04e653a38e2e613664264e ] After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Testcase: igt/drm_read/short-buffer-wakeup Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170804082328.17173-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
ddcf490 Noralf Trønnes 25 February 2019, 14:42:26 UTC drm/drv: Hold ref on parent device during drm_device lifetime BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 56be6503aab2bc3a30beae408071b9be5e1bae51 ] This makes it safe to access drm_device->dev after the parent device has been removed/unplugged. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-2-noralf@tronnes.org Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
fbfea80 Eric Anholt 08 March 2019, 17:43:35 UTC drm/v3d: Handle errors from IRQ setup. BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit fc22771547e7e8a63679f0218e943d72b107de65 ] Noted in review by Dave Emett for V3D 4.2 support. Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-1-eric@anholt.net Reviewed-by: Dave Emett <david.emett@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
8ec704e Arnd Bergmann 04 March 2019, 20:30:50 UTC ASoC: ti: fix davinci_mcasp_probe dependencies BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 7d7b25d05ef1c5a1a9320190e1eeb55534847558 ] The SND_SOC_DAVINCI_MCASP driver can use either edma or sdma as a back-end, and it takes the presence of the respective dma engine drivers in the configuration as an indication to which ones should be built. However, this is flawed in multiple ways: - With CONFIG_TI_EDMA=m and CONFIG_SND_SOC_DAVINCI_MCASP=y, is enabled as =m, and we get a link error: sound/soc/ti/davinci-mcasp.o: In function `davinci_mcasp_probe': davinci-mcasp.c:(.text+0x930): undefined reference to `edma_pcm_platform_register' - When CONFIG_SND_SOC_DAVINCI_MCASP=m has already been selected by another driver, the same link error appears even if CONFIG_TI_EDMA is disabled There are possibly other issues here, but it seems that the only reasonable solution is to always build both SND_SOC_TI_EDMA_PCM and SND_SOC_TI_SDMA_PCM as a dependency here. Both are fairly small and do not have any other compile-time dependencies, so the cost is very small, and makes the configuration stage much more consistent. Fixes: f2055e145f29 ("ASoC: ti: Merge davinci and omap directories") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
c99b0d6 Arnd Bergmann 07 March 2019, 10:11:30 UTC ASoC: davinci-mcasp: Fix clang warning without CONFIG_PM BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 8ca5104715cfd14254ea5aecc390ae583b707607 ] Building with clang shows a variable that is only used by the suspend/resume functions but defined outside of their #ifdef block: sound/soc/ti/davinci-mcasp.c:48:12: error: variable 'context_regs' is not needed and will not be emitted We commonly fix these by marking the PM functions as __maybe_unused, but here that would grow the davinci_mcasp structure, so instead add another #ifdef here. Fixes: 1cc0c054f380 ("ASoC: davinci-mcasp: Convert the context save/restore to use array") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
0cb1262 Chris Lesiak 07 March 2019, 20:39:00 UTC spi: Fix zero length xfer bug BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 5442dcaa0d90fc376bdfc179a018931a8f43dea4 ] This fixes a bug for messages containing both zero length and unidirectional xfers. The function spi_map_msg will allocate dummy tx and/or rx buffers for use with unidirectional transfers when the hardware can only do a bidirectional transfer. That dummy buffer will be used in place of a NULL buffer even when the xfer length is 0. Then in the function __spi_map_msg, if he hardware can dma, the zero length xfer will have spi_map_buf called on the dummy buffer. Eventually, __sg_alloc_table is called and returns -EINVAL because nents == 0. This fix prevents the error by not using the dummy buffer when the xfer length is zero. Signed-off-by: Chris Lesiak <chris.lesiak@licor.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
46b3a76 Steve Twiss 26 February 2019, 14:59:59 UTC regulator: da9055: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 5e6afb3832bedf420dd8e4c5b32ed85117c5087d ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f6130be652d0 ("regulator: DA9055 regulator driver") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
8f64777 Steve Twiss 26 February 2019, 15:19:34 UTC regulator: da9062: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 978995def0f6030aa6b3b494682f673aca13881b ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 4068e5182ada ("regulator: da9062: DA9062 regulator driver") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
784dc21 Steve Twiss 26 February 2019, 15:46:55 UTC regulator: pv88090: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 275513b7695a61b75b2546406ecd0f8e3d9fc8be ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: c90456e36d9c ("regulator: pv88090: new regulator driver") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
a0ab0e2 Steve Twiss 26 February 2019, 15:48:46 UTC regulator: wm831x: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 119c4f5085c45b60cb23c5595e45d06135b89518 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: e4ee831f949a ("regulator: Add WM831x DC-DC buck convertor support") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
b921783 Steve Twiss 26 February 2019, 15:44:54 UTC regulator: pv88080: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 1867af94cfdf37fc70fe67b3d522e78352800196 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 99cf3af5e2d5 ("regulator: pv88080: new regulator driver") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
4eb9034 Steve Twiss 26 February 2019, 15:23:02 UTC regulator: da9063: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 29d40b4a5776ec4727c9f0e00a884423dd5e3366 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 69ca3e58d178 ("regulator: da9063: Add Dialog DA9063 voltage regulators support.") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
543653a Steve Twiss 26 February 2019, 15:27:57 UTC regulator: da9211: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 65378de3359d30ebce44762d8b8027f372b5b1c4 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 1028a37daa14 ("regulator: da9211: new regulator driver") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
c0f4877 Steve Twiss 26 February 2019, 15:32:18 UTC regulator: lp8755: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 89b2758c192c35068b07766a6830433bfbdc1f44 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: b59320cc5a5e ("regulator: lp8755: new driver for LP8755") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
ddf428f Trent Piepho 04 March 2019, 20:18:49 UTC spi: imx: stop buffer overflow in RX FIFO flush BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit c842749ea1d32513f9e603c074d60d7aa07cb2ef ] Commit 71abd29057cb ("spi: imx: Add support for SPI Slave mode") added an RX FIFO flush before start of a transfer. In slave mode, the master may have sent more data than expected and this data will still be in the RX FIFO at the start of the next transfer, and so needs to be flushed. However, the code to do the flush was accidentally saving this data into the previous transfer's RX buffer, clobbering the contents of whatever followed that buffer. Change it to empty the FIFO and throw away the data. Every one of the RX functions for the different eCSPI versions and modes reads the RX FIFO data using the same readl() call, so just use that, rather than using the spi_imx->rx function pointer and making sure all the different rx functions have a working "throw away" mode. There is another issue, which affects master mode when switching from DMA to PIO. There can be extra data in the RX FIFO which triggers this flush code, causing memory corruption in the same manner. I don't know why this data is unexpectedly in the FIFO. It's likely there is a different bug or erratum responsible for that. But regardless of that, I think this is proper fix the for bug at hand here. Fixes: 71abd29057cb ("spi: imx: Add support for SPI Slave mode") Cc: Jiada Wang <jiada_wang@mentor.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: Stefan Agner <stefan@agner.ch> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
2c340a5 Steve Twiss 26 February 2019, 15:42:50 UTC regulator: pv88060: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit f58213637206e190453e3bd91f98f535566290a3 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f307a7e9b7af ("regulator: pv88060: new regulator driver") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
a54dc4a Steve Twiss 26 February 2019, 15:35:35 UTC regulator: ltc3589: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit f132da2534ec6599c78c4adcef15340cff2e9dd9 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 3eb2c7ecb7ea ("regulator: Add LTC3589 support") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
c578804 Steve Twiss 26 February 2019, 15:38:56 UTC regulator: ltc3676: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 769fc8d4182c1d1875db7859852afeb436714c5c ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 37b918a034fe ("regulator: Add LTC3676 support") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
34a9442 Steve Twiss 26 February 2019, 15:51:28 UTC regulator: wm831x isink: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit f7a621728a6a23bfd2c6ac4d3e42e1303aefde0f ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d4d6b722e780 ("regulator: Add WM831x ISINK support") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
7b38162 Steve Twiss 26 February 2019, 15:54:01 UTC regulator: wm831x ldo: Fix notifier mutex lock warning BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 8be64b6d87bd47d81753b60ddafe70102ebfd76b ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d1c6b4fe668b ("regulator: Add WM831x LDO support") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
9a91f21 Geert Uytterhoeven 12 March 2019, 18:45:13 UTC spi: rspi: Fix sequencer reset during initialization BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 26843bb128590edd7eba1ad7ce22e4b9f1066ce3 ] While the sequencer is reset after each SPI message since commit 880c6d114fd79a69 ("spi: rspi: Add support for Quad and Dual SPI Transfers on QSPI"), it was never reset for the first message, thus relying on reset state or bootloader settings. Fix this by initializing it explicitly during configuration. Fixes: 0b2182ddac4b8837 ("spi: add support for Renesas RSPI") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
cd799b1 Laurent Pinchart 13 September 2018, 00:45:06 UTC drm/omap: Notify all devices in the pipeline of output disconnection BugLink: https://bugs.launchpad.net/bugs/1837517 [ Upstream commit 27a7e3e18419869cdcc414a404f3fe66f1b4e644 ] For HDMI pipelines, when the output gets disconnected the device handling CEC needs to be notified. Instead of guessing which device that would be (and sometimes getting it wrong), notify all devices in the pipeline. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 13 August 2019, 12:11:36 UTC
back to top