- 03 Dec, 2019 40 commits
-
-
Ding Xiang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit c6e1241a ] if device_register return error, iounmap should be called, also iounmap need to call before put_device. Signed-off-by:
Ding Xiang <dingxiang@cmss.chinamobile.com> Reviewed-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/20476/ Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Erik Stromdahl authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 37f62c0d ] This is done in order not to trig the below warning in ieee80211_rx_napi: WARN_ON_ONCE(softirq_count() == 0); ieee80211_rx_napi requires that softirq's are disabled during execution. The High latency bus drivers (SDIO and USB) sometimes call the wmi ep_rx_complete callback from non softirq context, resulting in a trigger of the above warning. Calling ieee80211_rx_ni with softirq's already disabled (e.g., from softirq context) should be safe as the local_bh_disable and local_bh_enable functions (called from ieee80211_rx_ni) are fully reentrant. Signed-off-by:
Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 9ab708ae ] In the case where lo_vag <= SGTL5000_LINE_OUT_GND_BASE, lo_vag is set to zero and later vol_quot is computed by dividing by lo_vag causing a division by zero error. Fix this by avoiding a zero division and set vol_quot to zero in this specific case so that the lowest setting for i is correctly set. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Stefan Wahren authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit fa8cd98c ] We need to bail out if lan78xx_get_endpoints() fails, otherwise the result is overwritten. Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet") Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Raghuram Chary Jallipalli <raghuramchary.jallipalli@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Larry Finger authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 199ba9fa ] In gcc8, when the 3rd argument (size) of a call to strncpy() matches the length of the first argument, the compiler warns of the possibility of an unterminated string. Using strlcpy() forces a null at the end. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Marcel Ziswiler authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 8a1ecc01 ] There is one too many zeroes in the Power I2C base address. Fix this. Signed-off-by:
Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Patryk Małek authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 5907cf6c ] To prevent VF from deleting MAC address that was assigned by the PF we need to check for that scenario when we try to delete a MAC address from a VF. Signed-off-by:
Patryk Małek <patryk.malek@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Patryk Małek authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 5cba17b1 ] Hold the rtnl lock when we're clearing interrupt scheme in i40e_shutdown and in i40e_remove. Signed-off-by:
-
Mitch Williams authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 7eb74ff8 ] Caught by GCC 8. When we provide a length for strncpy, we should not include the terminating null. So we must tell it one less than the size of the destination buffer. Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Marek Szyprowski authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 64858773 ] This patch adds missing properties to the CODEC and sound nodes, so the audio will work also on Snow rev5 Chromebook. This patch is an extension to the commit e9eefc3f ("ARM: dts: exynos: Add missing clock and DAI properties to the max98095 node in Snow Chromebook") and commit 6ab56993 ("ARM: dts: exynos: Enable HDMI audio on Snow Chromebook"). It has been reported that such changes work fine on the rev5 board too. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> [krzk: Fixed typo in phandle to &max98090] Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Tuomas Tynkkynen authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit feef7918 ] Setting GPIO 21 high seems to be required to enable power to USB ports on the WNDR3400v3. As there is already similar code for WNR3500L, make the existing USB power GPIO code generic and use that. Signed-off-by:
Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Charles Keepax authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit e33ffbd9 ] If the CPU DAI does not initialise rate_max, say if using using KNOT or CONTINUOUS, then the rate_max field will be initialised to 0. A value of zero in the rate_max field of the hardware runtime will cause the sound card to support no sample rates at all. Obviously this is not desired, just a different mechanism is being used to apply the constraints. As such update the setting of rate_max in dpcm_init_runtime_hw to be consistent with the non-DPCM cases and set rate_max to UINT_MAX if nothing is defined on the CPU DAI. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Bob Peterson authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 4f36cb36 ] The GFS2_RDF_UPTODATE flag in the rgrp is used to determine when a rgrp buffer is valid. It's cleared when the glock is invalidated, signifying that the buffer data is now invalid. But before this patch, function update_rgrp_lvb was setting the flag when it determined it had a valid lvb. But that's an invalid assumption: just because you have a valid lvb doesn't mean you have valid buffers. After all, another node may have made the lvb valid, and this node just fetched it from the glock via dlm. Consider this scenario: 1. The file system is mounted with RGRPLVB option. 2. In gfs2_inplace_reserve it locks the rgrp glock EX, but thanks to GL_SKIP, it skips the gfs2_rgrp_bh_get. 3. Since loops == 0 and the allocation target (ap->target) is bigger than the largest known chunk of blocks in the rgrp (rs->rs_rbm.rgd->rd_extfail_pt) it skips that rgrp and bypasses the call to gfs2_rgrp_bh_get there as well. 4. update_rgrp_lvb sees the lvb MAGIC number is valid, so bypasses gfs2_rgrp_bh_get, but it still sets sets GFS2_RDF_UPTODATE due to this invalid assumption. 5. The next time update_rgrp_lvb is called, it sees the bit is set and just returns 0, assuming both the lvb and rgrp are both uptodate. But since this is a smaller allocation, or space has been freed by another node, thus adjusting the lvb values, it decides to use the rgrp for allocations, with invalid rd_free due to the fact it was never updated. This patch changes update_rgrp_lvb so it doesn't set the UPTODATE flag anymore. That way, it has no choice but to fetch the latest values. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit b8e13154 ] snd_seq_system_client_init() doesn't check the errors returned from its port creations. Let's do it properly and handle the error paths. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jay Foster authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 10af10db ] Fix a typo. No functional change made by this patch. Signed-off-by:
Jay Foster <jayfoster@ieee.org> Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 6f128fa4 ] The "frames" variable is unsigned so the error handling doesn't work properly. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Marcus Folkesson authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 0833627f ] Do not try to write negative values and make sure that the write goes well. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Eugen Hristev authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit fed23c58 upstream. The quirks2 are parsed and set (e.g. from DT) before the quirk for broken HS200 is set in the driver. The driver needs to enable just this flag, not rewrite the whole quirk set. Fixes: 7871aa60 ("mmc: sdhci-of-at91: add quirk for broken HS200") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Roman Gushchin authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 0362f326 upstream. An exiting task might belong to an offline cgroup. In this case an attempt to grab a cgroup reference from the task can end up with an infinite loop in hugetlb_cgroup_charge_cgroup(), because neither the cgroup will become online, neither the task will be migrated to a live cgroup. Fix this by switching over to css_tryget(). As css_tryget_online() can't guarantee that the cgroup won't go offline, in most cases the check doesn't make sense. In this particular case users of hugetlb_cgroup_charge_cgroup() are not affected by this change. A similar problem is described by commit 18fa84a2 ("cgroup: Use css_tryget() instead of css_tryget_online() in task_get_css()"). Link: http://lkml.kernel.org/r/20191106225131.3543616-2-guro@fb.comSigned-off-by:
Roman Gushchin <guro@fb.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Tejun Heo <tj@kernel.org> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Roman Gushchin authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 00d484f3 upstream. We've encountered a rcu stall in get_mem_cgroup_from_mm(): rcu: INFO: rcu_sched self-detected stall on CPU rcu: 33-....: (21000 ticks this GP) idle=6c6/1/0x4000000000000002 softirq=35441/35441 fqs=5017 (t=21031 jiffies g=324821 q=95837) NMI backtrace for cpu 33 <...> RIP: 0010:get_mem_cgroup_from_mm+0x2f/0x90 <...> __memcg_kmem_charge+0x55/0x140 __alloc_pages_nodemask+0x267/0x320 pipe_write+0x1ad/0x400 new_sync_write+0x127/0x1c0 __kernel_write+0x4f/0xf0 dump_emit+0x91/0xc0 writenote+0xa0/0xc0 elf_core_dump+0x11af/0x1430 do_coredump+0xc65/0xee0 get_signal+0x132/0x7c0 do_signal+0x36/0x640 exit_to_usermode_loop+0x61/0xd0 do_syscall_64+0xd4/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The problem is caused by an exiting task which is associated with an offline memcg. We're iterating over and over in the do {} while (!css_tryget_online()) loop, but obviously the memcg won't become online and the exiting task won't be migrated to a live memcg. Let's fix it by switching from css_tryget_online() to css_tryget(). As css_tryget_online() cannot guarantee that the memcg won't go offline, the check is usually useless, except some rare cases when for example it determines if something should be presented to a user. A similar problem is described by commit 18fa84a2 ("cgroup: Use css_tryget() instead of css_tryget_online() in task_get_css()"). Johannes: : The bug aside, it doesn't matter whether the cgroup is online for the : callers. It used to matter when offlining needed to evacuate all charges : from the memcg, and so needed to prevent new ones from showing up, but we : don't care now. Link: http://lkml.kernel.org/r/20191106225131.3543616-1-guro@fb.comSigned-off-by:
Shakeel Butt <shakeeb@google.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Michal Koutn <mkoutny@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Eric Auger authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 4e7120d7 upstream. For both PASID-based-Device-TLB Invalidate Descriptor and Device-TLB Invalidate Descriptor, the Physical Function Source-ID value is split according to this layout: PFSID[3:0] is set at offset 12 and PFSID[15:4] is put at offset 52. Fix the part laid out at offset 52. Fixes: 0f725561 ("iommu/vt-d: Add definitions for PFSID") Signed-off-by:
Eric Auger <eric.auger@redhat.com> Acked-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: stable@vger.kernel.org # v4.19+ Acked-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Al Viro authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 762c6968 upstream. We need to get the underlying dentry of parent; sure, absent the races it is the parent of underlying dentry, but there's nothing to prevent losing a timeslice to preemtion in the middle of evaluation of lower_dentry->d_parent->d_inode, having another process move lower_dentry around and have its (ex)parent not pinned anymore and freed on memory pressure. Then we regain CPU and try to fetch ->d_inode from memory that is freed by that point. dentry->d_parent *is* stable here - it's an argument of ->lookup() and we are guaranteed that it won't be moved anywhere until we feed it to d_add/d_splice_alias. So we safely go that way to get to its underlying dentry. Cc: stable@vger.kernel.org # since 2009 or so Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit e72b9dd6 upstream. lower_dentry can't go from positive to negative (we have it pinned), but it *can* go from negative to positive. So fetching ->d_inode into a local variable, doing a blocking allocation, checking that now ->d_inode is non-NULL and feeding the value we'd fetched earlier to a function that won't accept NULL is not a good idea. Cc: stable@vger.kernel.org Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit fa3a5a18 upstream. No timer must be left running when the device goes away. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-and-tested-by: syzbot+b6c55daa701fc389e286@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1573726121.17351.3.camel@suse.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Henry Lin authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 52869931 upstream. While output urb's snd_complete_urb() is executing, calling prepare_outbound_urb() may cause endpoint stopped before prepare_outbound_urb() returns and result in next urb submitted to stopped endpoint. usb-audio driver cannot re-use it afterwards as the urb is still hold by usb stack. This change checks EP_FLAG_RUNNING flag after prepare_outbound_urb() again to let snd_complete_urb() know the endpoint already stopped and does not submit next urb. Below kind of error will be fixed: [ 213.153103] usb 1-2: timeout: still 1 active urbs on EP #1 [ 213.164121] usb 1-2: cannot submit urb 0, error -16: unknown error Signed-off-by:
Henry Lin <henryl@nvidia.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191113021420.13377-1-henryl@nvidia.comSigned-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 167beb17 upstream. A check of the return value from get_cur_mix_raw() is missing at the resolution test code in get_min_max_with_quirks(), which may leave the variable untouched, leading to a random uninitialized value, as detected by syzkaller fuzzer. Add the missing return error check for fixing that. Reported-and-tested-by: syzbot+abe1ab7afc62c6bb6377@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191109181658.30368-1-tiwai@suse.deSigned-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit a9a51bd7 ] If a malicious device gives a short MAC it can elicit up to 5 bytes of leaked memory out of the driver. We need to check for ETH_ALEN instead. Reported-by: syzbot+a8d4acdad35e6bbca308@syzkaller.appspotmail.com Signed-off-by:
-
Jouni Hogander authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 3b5a3997 ] Driver/net/can/slcan.c is derived from slip.c. Memory leak was detected by Syzkaller in slcan. Same issue exists in slip.c and this patch is addressing the leak in slip.c. Here is the slcan memory leak trace reported by Syzkaller: BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096): comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s) hex dump (first 32 bytes): 73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0 [<0000000083306e66>] kvmalloc_node+0x3a/0xc0 [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080 [<0000000061a996c9>] slcan_open+0x3ae/0x9a0 [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0 [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0 [<000000004de5a617>] tty_ioctl+0x48d/0x1590 [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510 [<0000000059068dbc>] ksys_ioctl+0x99/0xb0 [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0 [<0000000053d0332e>] do_syscall_64+0x16f/0x580 [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<000000008ea75434>] 0xfffffffffffffff Cc: "David S. Miller" <davem@davemloft.net> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
Jouni Hogander <jouni.hogander@unikie.com> Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1853177 Ignore: yes Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1853177Signed-off-by:
-
Josh Poimboeuf authored
BugLink: https://bugs.launchpad.net/bugs/1853177 commit 012206a8 upstream. For new IBRS_ALL CPUs, the Enhanced IBRS check at the beginning of cpu_bugs_smt_update() causes the function to return early, unintentionally skipping the MDS and TAA logic. This is not a problem for MDS, because there appears to be no overlap between IBRS_ALL and MDS-affected CPUs. So the MDS mitigation would be disabled and nothing would need to be done in this function anyway. But for TAA, the TAA_MSG_SMT string will never get printed on Cascade Lake and newer. The check is superfluous anyway: when 'spectre_v2_enabled' is SPECTRE_V2_IBRS_ENHANCED, 'spectre_v2_user' is always SPECTRE_V2_USER_NONE, and so the 'spectre_v2_user' switch statement handles it appropriately by doing nothing. So just remove the check. Fixes: 1b42f017 ("x86/speculation/taa: Add mitigation for TSX Async Abort") Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Tyler Hicks <tyhicks@canonical.com> Reviewed-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Nicholas Piggin authored
BugLink: https://bugs.launchpad.net/bugs/1853177 commit ff45000f upstream. The boot wrapper performs its own relocations and does not require PT_INTERP segment. However currently we don't tell the linker that. Prior to binutils 2.28 that works OK. But since binutils commit 1a9ccd70f9a7 ("Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix readelf to report such invalid binaries.") binutils tries to create a program header segment due to PT_INTERP, and the link fails because there is no space for it: ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, try linking with -N ld: final link failed: Bad value So tell the linker not to do that, by passing --no-dynamic-linker. Cc: stable@vger.kernel.org Reported-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> [mpe: Drop dependency on ld-version.sh and massage change log] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [ajd: backport to v4.4 (resolve conflict with a comment line)] Signed-off-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
-
Nicholas Piggin authored
BugLink: https://bugs.launchpad.net/bugs/1853177 commit 4dc831aa upstream. GCC can compile with either endian, but the default ABI version is set based on the default endianness of the toolchain. Alan Modra says: you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc generate powerpc64 code The opposite is true for powerpc64 when generating -mlittle it requires -mabi=elfv2 to generate v2 ABI, which we were already doing. This change adds ABI annotations together with endianness for all cases, LE and BE. This fixes the case of building a BE kernel with a toolchain that is LE by default. Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
Michael Ellerman authored
BugLink: https://bugs.launchpad.net/bugs/1853177 commit 164af597 upstream. When we introduced the little endian support, we added the endian flags to CC directly using override. I don't know the history of why we did that, I suspect no one does. Although this mostly works, it has one bug, which is that CROSS32CC doesn't get -mbig-endian. That means when the compiler is little endian by default and the user is building big endian, vdso32 is incorrectly compiled as little endian and the kernel fails to build. Instead we can add the endian flags to cflags-y/aflags-y, and then append those to KBUILD_CFLAGS/KBUILD_AFLAGS. This has the advantage of being 1) less ugly, 2) the documented way of adding flags in the arch Makefile and 3) it fixes building vdso32 with a LE toolchain. Signed-off-by:
-
Jonas Gorski authored
BugLink: https://bugs.launchpad.net/bugs/1853177 commit 8a38dacf upstream. The Ethernet Switch core mask was set to 0, causing the switch core to be not reset on BCM6368 on boot. Provide the proper mask so the switch core gets reset to a known good state. Fixes: 799faa62 ("MIPS: BCM63XX: add core reset helper") Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Junaid Shahid authored
BugLink: https://bugs.launchpad.net/bugs/1853177 [ Upstream commit d35b34a9 ] kvm should not attempt to read guest PDPTEs when CR0.PG = 0 and CR4.PAE = 1. Signed-off-by:
Junaid Shahid <junaids@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1852335 Ignore: yes Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1852335Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1852335 [ Upstream commit f75359f3 ] Add a couple of READ_ONCE() and WRITE_ONCE() to prevent load-tearing and store-tearing in sock_read_timestamp() and sock_write_timestamp() This might prevent another KCSAN report. Fixes: 3a0ed3e9 ("sock: Make sock->sk_stamp thread-safe") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by:
Deepa Dinamani <deepa.kernel@gmail.com> Signed-off-by:
-
Tejun Heo authored
BugLink: https://bugs.launchpad.net/bugs/1852335 commit 65de03e2 upstream. cgroup writeback tries to refresh the associated wb immediately if the current wb is dead. This is to avoid keeping issuing IOs on the stale wb after memcg - blkcg association has changed (ie. when blkcg got disabled / enabled higher up in the hierarchy). Unfortunately, the logic gets triggered spuriously on inodes which are associated with dead cgroups. When the logic is triggered on dead cgroups, the attempt fails only after doing quite a bit of work allocating and initializing a new wb. While c3aab9a0 ("mm/filemap.c: don't initiate writeback if mapping has no dirty pages") alleviated the issue significantly as it now only triggers when the inode has dirty pages. However, the condition can still be triggered before the inode is switched to a different cgroup and the logic simply doesn't make sense. Skip the immediate switching if the associated memcg is dying. This is a simplified version of the following two patches: * https://lore.kernel.org/linux-mm/20190513183053.GA73423@dennisz-mbp/ * http://lkml.kernel.org/r/156355839560.2063.5265687291430814589.stgit@buzz Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Fixes: e8a7abf5 ("writeback: disassociate inodes from dying bdi_writebacks") Acked-by:
Dennis Zhou <dennis@kernel.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
