This is the start of the stable review cycle for the 4.19.124 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 20 May 2020 17:32:42 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.124-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.19.124-rc1
Sergei Trofimovich slyfox@gentoo.org Makefile: disallow data races on gcc-10 as well
Jim Mattson jmattson@google.com KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce
Geert Uytterhoeven geert+renesas@glider.be ARM: dts: r8a7740: Add missing extal2 to CPG node
Yoshihiro Shimoda yoshihiro.shimoda.uh@renesas.com arm64: dts: renesas: r8a77980: Fix IPMMU VIP[01] nodes
Geert Uytterhoeven geert+renesas@glider.be ARM: dts: r8a73a4: Add missing CMT1 interrupts
Chen-Yu Tsai wens@csie.org arm64: dts: rockchip: Rename dwc3 device nodes on rk3399 to make dtc happy
Chen-Yu Tsai wens@csie.org arm64: dts: rockchip: Replace RK805 PMIC node name with "pmic" on rk3328 boards
Marc Zyngier maz@kernel.org clk: Unlink clock if failed to prepare or enable
Kai-Heng Feng kai.heng.feng@canonical.com Revert "ALSA: hda/realtek: Fix pop noise on ALC225"
Wei Yongjun weiyongjun1@huawei.com usb: gadget: legacy: fix error return code in cdc_bind()
Wei Yongjun weiyongjun1@huawei.com usb: gadget: legacy: fix error return code in gncm_bind()
Christophe JAILLET christophe.jaillet@wanadoo.fr usb: gadget: audio: Fix a missing error return value in audio_bind()
Christophe JAILLET christophe.jaillet@wanadoo.fr usb: gadget: net2272: Fix a memory leak in an error handling path in 'net2272_plat_probe()'
John Stultz john.stultz@linaro.org dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()
Justin Swartz justin.swartz@risingedge.co.za clk: rockchip: fix incorrect configuration of rk3228 aclk_gpu* clocks
Eric W. Biederman ebiederm@xmission.com exec: Move would_dump into flush_old_exec
Josh Poimboeuf jpoimboe@redhat.com x86/unwind/orc: Fix error handling in __unwind_start()
Borislav Petkov bp@suse.de x86: Fix early boot crash on gcc-10, third try
Adam McCoy adam@forsedomani.com cifs: fix leaked reference on requeued write
Fabio Estevam festevam@gmail.com ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries
Kishon Vijay Abraham I kishon@ti.com ARM: dts: dra7: Fix bus_dma_limit for PCIe
Sriharsha Allenki sallenki@codeaurora.org usb: xhci: Fix NULL pointer dereference when enqueuing trbs from urb sg list
Kyungtae Kim kt0755@gmail.com USB: gadget: fix illegal array access in binding with UDC
Li Jun jun.li@nxp.com usb: host: xhci-plat: keep runtime active when removing host
Eugeniu Rosca erosca@de.adit-jv.com usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B
Jesus Ramos jesus-ramos@live.com ALSA: usb-audio: Add control message quirk delay for Kingston HyperX headset
Takashi Iwai tiwai@suse.de ALSA: rawmidi: Fix racy buffer resize under concurrent accesses
Takashi Iwai tiwai@suse.de ALSA: hda/realtek - Limit int mic boost for Thinkpad T530
Linus Torvalds torvalds@linux-foundation.org gcc-10: avoid shadowing standard library 'free()' in crypto
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'restrict' warning for now
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'stringop-overflow' warning for now
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'array-bounds' warning for now
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'zero-length-bounds' warning for now
Linus Torvalds torvalds@linux-foundation.org Stop the ad-hoc games with -Wno-maybe-initialized
Masahiro Yamada yamada.masahiro@socionext.com kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
Linus Torvalds torvalds@linux-foundation.org gcc-10 warnings: fix low-hanging fruit
Jason Gunthorpe jgg@ziepe.ca pnp: Use list_for_each_entry() instead of open coding
Samu Nuutamo samu.nuutamo@vincit.fi hwmon: (da9052) Synchronize access with mfd
Jack Morgenstein jackm@dev.mellanox.co.il IB/mlx4: Test return value of calls to ib_get_cached_pkey
Stefano Brivio sbrivio@redhat.com netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()
Christoph Hellwig hch@lst.de arm64: fix the flush_icache_range arguments in machine_kexec
Arnd Bergmann arnd@arndb.de netfilter: conntrack: avoid gcc-10 zero-length-bounds warning
Dave Wysochanski dwysocha@redhat.com NFSv4: Fix fscache cookie aux_data to ensure change_attr is included
Arnd Bergmann arnd@arndb.de nfs: fscache: use timespec64 in inode auxdata
Dave Wysochanski dwysocha@redhat.com NFS: Fix fscache super_cookie index_key from changing after umount
Adrian Hunter adrian.hunter@intel.com mmc: block: Fix request completion in the CQE timeout path
Veerabhadrarao Badiganti vbadigan@codeaurora.org mmc: core: Check request type before completing the request
Dan Carpenter dan.carpenter@oracle.com i40iw: Fix error handling in i40iw_manage_arp_cache()
Grace Kao grace.kao@intel.com pinctrl: cherryview: Add missing spinlock usage in chv_gpio_irq_handler
Andy Shevchenko andriy.shevchenko@linux.intel.com pinctrl: baytrail: Enable pin configuration setting for GPIO chip
Andreas Gruenbacher agruenba@redhat.com gfs2: Another gfs2_walk_metadata fix
Kai-Heng Feng kai.heng.feng@canonical.com ALSA: hda/realtek - Fix S3 pop noise on Dell Wyse
Vasily Averin vvs@virtuozzo.com ipc/util.c: sysvipc_find_ipc() incorrectly updates position index
Vasily Averin vvs@virtuozzo.com drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()
Kai Vehmanen kai.vehmanen@linux.intel.com ALSA: hda/hdmi: fix race in monitor detection during probe
Chris Wilson chris@chris-wilson.co.uk cpufreq: intel_pstate: Only mention the BIOS disabling turbo mode once
Lubomir Rintel lkundrak@v3.sk dmaengine: mmp_tdma: Reset channel error on release
Madhuparna Bhowmik madhuparnabhowmik10@gmail.com dmaengine: pch_dma.c: Avoid data race between probe and irq handler
Ilie Halip ilie.halip@gmail.com riscv: fix vdso build with lld
Eric Dumazet edumazet@google.com tcp: fix SO_RCVLOWAT hangs with fat skbs
Kelly Littlepage kelly@onechronos.com net: tcp: fix rx timestamp behavior for tcp_recvmsg
Zefan Li lizefan@huawei.com netprio_cgroup: Fix unlimited memory leak of v2 cgroups
Paolo Abeni pabeni@redhat.com net: ipv4: really enforce backoff for redirects
Florian Fainelli f.fainelli@gmail.com net: dsa: loop: Add module soft dependency
Luo bin luobin9@huawei.com hinic: fix a bug of ndo_stop
Michael S. Tsirkin mst@redhat.com virtio_net: fix lockdep warning on 32 bit
Eric Dumazet edumazet@google.com tcp: fix error recovery in tcp_zerocopy_receive()
Maciej Żenczykowski maze@google.com Revert "ipv6: add mtu lock check in __ip6_rt_update_pmtu"
Guillaume Nault gnault@redhat.com pppoe: only process PADT targeted at local interfaces
Heiner Kallweit hkallweit1@gmail.com net: phy: fix aneg restart in phy_ethtool_set_eee
Paolo Abeni pabeni@redhat.com netlabel: cope with NULL catmap
Cong Wang xiyou.wangcong@gmail.com net: fix a potential recursive NETDEV_FEAT_CHANGE
Raul E Rangel rrangel@chromium.org mmc: sdhci-acpi: Add SDHCI_QUIRK2_BROKEN_64_BIT_DMA for AMDI0040
Wu Bo wubo40@huawei.com scsi: sg: add sg_remove_request in sg_write
Stefan Hajnoczi stefanha@redhat.com virtio-blk: handle block_device_operations callbacks after hot unplug
Arnd Bergmann arnd@arndb.de drop_monitor: work around gcc-10 stringop-overflow warning
Christophe JAILLET christophe.jaillet@wanadoo.fr net: moxa: Fix a potential double 'free_irq()'
Christophe JAILLET christophe.jaillet@wanadoo.fr net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'
Hugh Dickins hughd@google.com shmem: fix possible deadlocks on shmlock_user_lock
Florian Fainelli f.fainelli@gmail.com net: dsa: Do not make user port errors fatal
-------------
Diffstat:
Makefile | 25 ++++--- arch/arm/boot/dts/dra7.dtsi | 4 +- arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 4 +- arch/arm/boot/dts/r8a73a4.dtsi | 9 ++- arch/arm/boot/dts/r8a7740.dtsi | 2 +- arch/arm64/boot/dts/renesas/r8a77980.dtsi | 2 + arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 +- arch/arm64/kernel/machine_kexec.c | 1 + arch/riscv/kernel/vdso/Makefile | 6 +- arch/x86/include/asm/stackprotector.h | 7 +- arch/x86/kernel/smpboot.c | 8 +++ arch/x86/kernel/unwind_orc.c | 16 +++-- arch/x86/kvm/x86.c | 2 +- arch/x86/xen/smp_pv.c | 1 + crypto/lrw.c | 4 +- crypto/xts.c | 4 +- drivers/block/virtio_blk.c | 86 ++++++++++++++++++++--- drivers/clk/clk.c | 3 + drivers/clk/rockchip/clk-rk3228.c | 17 ++--- drivers/cpufreq/intel_pstate.c | 2 +- drivers/dma/mmp_tdma.c | 2 + drivers/dma/pch_dma.c | 2 +- drivers/gpu/drm/qxl/qxl_image.c | 3 +- drivers/hwmon/da9052-hwmon.c | 4 +- drivers/infiniband/hw/i40iw/i40iw_hw.c | 2 +- drivers/infiniband/hw/mlx4/qp.c | 14 +++- drivers/mmc/core/block.c | 3 +- drivers/mmc/core/queue.c | 3 +- drivers/mmc/host/sdhci-acpi.c | 10 +-- drivers/net/dsa/dsa_loop.c | 1 + drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 16 +++-- drivers/net/ethernet/huawei/hinic/hinic_main.c | 16 +---- drivers/net/ethernet/moxa/moxart_ether.c | 2 +- drivers/net/ethernet/natsemi/jazzsonic.c | 6 +- drivers/net/phy/phy.c | 8 ++- drivers/net/ppp/pppoe.c | 3 + drivers/net/virtio_net.c | 6 +- drivers/pinctrl/intel/pinctrl-baytrail.c | 1 + drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ++ drivers/scsi/sg.c | 4 +- drivers/usb/core/hub.c | 6 +- drivers/usb/dwc3/gadget.c | 3 - drivers/usb/gadget/configfs.c | 3 + drivers/usb/gadget/legacy/audio.c | 4 +- drivers/usb/gadget/legacy/cdc2.c | 4 +- drivers/usb/gadget/legacy/ncm.c | 4 +- drivers/usb/gadget/udc/net2272.c | 2 + drivers/usb/host/xhci-plat.c | 4 +- drivers/usb/host/xhci-ring.c | 4 +- fs/cifs/cifssmb.c | 2 +- fs/exec.c | 4 +- fs/gfs2/bmap.c | 16 +++-- fs/nfs/fscache-index.c | 6 +- fs/nfs/fscache.c | 31 ++++---- fs/nfs/fscache.h | 8 ++- include/linux/compiler.h | 6 ++ include/linux/fs.h | 2 +- include/linux/pnp.h | 29 +++----- include/linux/tty.h | 2 +- include/net/netfilter/nf_conntrack.h | 2 +- include/net/tcp.h | 13 ++++ include/sound/rawmidi.h | 1 + init/main.c | 2 + ipc/util.c | 12 ++-- mm/shmem.c | 7 +- net/core/dev.c | 4 +- net/core/drop_monitor.c | 11 +-- net/core/netprio_cgroup.c | 2 + net/dsa/dsa2.c | 2 +- net/ipv4/cipso_ipv4.c | 6 +- net/ipv4/route.c | 2 +- net/ipv4/tcp.c | 27 ++++--- net/ipv4/tcp_input.c | 3 +- net/ipv6/calipso.c | 3 +- net/ipv6/route.c | 6 +- net/netfilter/nf_conntrack_core.c | 4 +- net/netfilter/nft_set_rbtree.c | 17 +++-- net/netlabel/netlabel_kapi.c | 6 ++ sound/core/rawmidi.c | 31 ++++++-- sound/pci/hda/patch_hdmi.c | 2 + sound/pci/hda/patch_realtek.c | 28 +++++++- sound/usb/quirks.c | 9 +-- 84 files changed, 452 insertions(+), 209 deletions(-)
From: Florian Fainelli f.fainelli@gmail.com
commit 86f8b1c01a0a537a73d2996615133be63cdf75db upstream.
Prior to 1d27732f411d ("net: dsa: setup and teardown ports"), we would not treat failures to set-up an user port as fatal, but after this commit we would, which is a regression for some systems where interfaces may be declared in the Device Tree, but the underlying hardware may not be present (pluggable daughter cards for instance).
Fixes: 1d27732f411d ("net: dsa: setup and teardown ports") Signed-off-by: Florian Fainelli f.fainelli@gmail.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
--- net/dsa/dsa2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/dsa/dsa2.c +++ b/net/dsa/dsa2.c @@ -412,7 +412,7 @@ static int dsa_tree_setup_switches(struc
err = dsa_switch_setup(ds); if (err) - return err; + continue;
for (port = 0; port < ds->num_ports; port++) { dp = &ds->ports[port];
Hi!
From: Florian Fainelli f.fainelli@gmail.com
commit 86f8b1c01a0a537a73d2996615133be63cdf75db upstream.
Prior to 1d27732f411d ("net: dsa: setup and teardown ports"), we would not treat failures to set-up an user port as fatal, but after this commit we would, which is a regression for some systems where interfaces may be declared in the Device Tree, but the underlying hardware may not be present (pluggable daughter cards for instance).
+++ b/net/dsa/dsa2.c @@ -412,7 +412,7 @@ static int dsa_tree_setup_switches(struc err = dsa_switch_setup(ds); if (err)
return err;
continue;
The error code is discarded here, so user can now wonder "why does not my port work" with no indications in the logs... Should we do dev_info() here?
Best regards, Pavel
On 5/19/2020 12:17 AM, Pavel Machek wrote:
Hi!
From: Florian Fainelli f.fainelli@gmail.com
commit 86f8b1c01a0a537a73d2996615133be63cdf75db upstream.
Prior to 1d27732f411d ("net: dsa: setup and teardown ports"), we would not treat failures to set-up an user port as fatal, but after this commit we would, which is a regression for some systems where interfaces may be declared in the Device Tree, but the underlying hardware may not be present (pluggable daughter cards for instance).
+++ b/net/dsa/dsa2.c @@ -412,7 +412,7 @@ static int dsa_tree_setup_switches(struc err = dsa_switch_setup(ds); if (err)
return err;
continue;
The error code is discarded here, so user can now wonder "why does not my port work" with no indications in the logs... Should we do dev_info() here?
There are informational messages provided at various points where a failure can happen and especially in the net/dsa/slave.c file where most of the errors are. I do not think an additional is needed at all.
From: Hugh Dickins hughd@google.com
[ Upstream commit ea0dfeb4209b4eab954d6e00ed136bc6b48b380d ]
Recent commit 71725ed10c40 ("mm: huge tmpfs: try to split_huge_page() when punching hole") has allowed syzkaller to probe deeper, uncovering a long-standing lockdep issue between the irq-unsafe shmlock_user_lock, the irq-safe xa_lock on mapping->i_pages, and shmem inode's info->lock which nests inside xa_lock (or tree_lock) since 4.8's shmem_uncharge().
user_shm_lock(), servicing SysV shmctl(SHM_LOCK), wants shmlock_user_lock while its caller shmem_lock() holds info->lock with interrupts disabled; but hugetlbfs_file_setup() calls user_shm_lock() with interrupts enabled, and might be interrupted by a writeback endio wanting xa_lock on i_pages.
This may not risk an actual deadlock, since shmem inodes do not take part in writeback accounting, but there are several easy ways to avoid it.
Requiring interrupts disabled for shmlock_user_lock would be easy, but it's a high-level global lock for which that seems inappropriate. Instead, recall that the use of info->lock to guard info->flags in shmem_lock() dates from pre-3.1 days, when races with SHMEM_PAGEIN and SHMEM_TRUNCATE could occur: nowadays it serves no purpose, the only flag added or removed is VM_LOCKED itself, and calls to shmem_lock() an inode are already serialized by the caller.
Take info->lock out of the chain and the possibility of deadlock or lockdep warning goes away.
Fixes: 4595ef88d136 ("shmem: make shmem_inode_info::lock irq-safe") Reported-by: syzbot+c8a8197c8852f566b9d9@syzkaller.appspotmail.com Reported-by: syzbot+40b71e145e73f78f81ad@syzkaller.appspotmail.com Signed-off-by: Hugh Dickins hughd@google.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Acked-by: Yang Shi yang.shi@linux.alibaba.com Cc: Yang Shi yang.shi@linux.alibaba.com Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2004161707410.16322@eggly.anvils Link: https://lore.kernel.org/lkml/000000000000e5838c05a3152f53@google.com/ Link: https://lore.kernel.org/lkml/0000000000003712b305a331d3b1@google.com/ Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- mm/shmem.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c index 0a2e1e7801d68..dea5120565d30 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2149,7 +2149,11 @@ int shmem_lock(struct file *file, int lock, struct user_struct *user) struct shmem_inode_info *info = SHMEM_I(inode); int retval = -ENOMEM;
- spin_lock_irq(&info->lock); + /* + * What serializes the accesses to info->flags? + * ipc_lock_object() when called from shmctl_do_lock(), + * no serialization needed when called from shm_destroy(). + */ if (lock && !(info->flags & VM_LOCKED)) { if (!user_shm_lock(inode->i_size, user)) goto out_nomem; @@ -2164,7 +2168,6 @@ int shmem_lock(struct file *file, int lock, struct user_struct *user) retval = 0;
out_nomem: - spin_unlock_irq(&info->lock); return retval; }
Hi!
This may not risk an actual deadlock, since shmem inodes do not take part in writeback accounting, but there are several easy ways to avoid it.
...
Take info->lock out of the chain and the possibility of deadlock or lockdep warning goes away.
It is unclear to me if actual possibility of deadlock exists or not, but anyway:
int retval = -ENOMEM;
- spin_lock_irq(&info->lock);
- /*
* What serializes the accesses to info->flags?
* ipc_lock_object() when called from shmctl_do_lock(),
* no serialization needed when called from shm_destroy().
if (lock && !(info->flags & VM_LOCKED)) { if (!user_shm_lock(inode->i_size, user)) goto out_nomem;*/
Should we have READ_ONCE() here? If it is okay, are concurency sanitizers smart enough to realize that it is okay? Replacing warning with different one would not be exactly a win...
Best regards,
Pavel
Hi Pavel,
On Mon, 18 May 2020, Pavel Machek wrote:
Hi!
This may not risk an actual deadlock, since shmem inodes do not take part in writeback accounting, but there are several easy ways to avoid it.
...
Take info->lock out of the chain and the possibility of deadlock or lockdep warning goes away.
It is unclear to me if actual possibility of deadlock exists or not, but anyway:
int retval = -ENOMEM;
- spin_lock_irq(&info->lock);
- /*
* What serializes the accesses to info->flags?
* ipc_lock_object() when called from shmctl_do_lock(),
* no serialization needed when called from shm_destroy().
if (lock && !(info->flags & VM_LOCKED)) { if (!user_shm_lock(inode->i_size, user)) goto out_nomem;*/
Should we have READ_ONCE() here? If it is okay, are concurency sanitizers smart enough to realize that it is okay? Replacing warning with different one would not be exactly a win...
If a sanitizer comes to question this change, I don't see how a READ_ONCE() anywhere near here (on info->flags?) is likely to be enough to satisfy it - it would be asking for a locking scheme that it understands (being unable to read the comment) - and might then ask for that same locking in the numerous other places that read info->flags (and a few that write it). Add data_race()s all over?
(Or are you concerned about that inode->i_size, which I suppose ought really to be i_size_read(inode) on some 32-bit configurations; though that's of very long standing, and has never caused any concern before.)
I am not at all willing to add annotations speculatively, in case this or that tool turns out to want help later. So far I've not heard of any such complaint on 5.7-rc[3456] or linux-next: but maybe this is too soon to hear a complaint, and you feel this should not be rushed into -stable?
This was an AUTOSEL selection, to which I have no objection, but it isn't something we were desperate to push into -stable: so I've also no objection if Greg shares your concern, and prefers to withdraw it. (That choice may depend on to what extent he expects to be keeping -stable clean against upcoming sanitizers in future.)
Hugh
On Mon, May 18, 2020 at 06:10:58PM -0700, Hugh Dickins wrote:
Hi Pavel,
On Mon, 18 May 2020, Pavel Machek wrote:
Hi!
This may not risk an actual deadlock, since shmem inodes do not take part in writeback accounting, but there are several easy ways to avoid it.
...
Take info->lock out of the chain and the possibility of deadlock or lockdep warning goes away.
It is unclear to me if actual possibility of deadlock exists or not, but anyway:
int retval = -ENOMEM;
- spin_lock_irq(&info->lock);
- /*
* What serializes the accesses to info->flags?
* ipc_lock_object() when called from shmctl_do_lock(),
* no serialization needed when called from shm_destroy().
if (lock && !(info->flags & VM_LOCKED)) { if (!user_shm_lock(inode->i_size, user)) goto out_nomem;*/
Should we have READ_ONCE() here? If it is okay, are concurency sanitizers smart enough to realize that it is okay? Replacing warning with different one would not be exactly a win...
If a sanitizer comes to question this change, I don't see how a READ_ONCE() anywhere near here (on info->flags?) is likely to be enough to satisfy it - it would be asking for a locking scheme that it understands (being unable to read the comment) - and might then ask for that same locking in the numerous other places that read info->flags (and a few that write it). Add data_race()s all over?
(Or are you concerned about that inode->i_size, which I suppose ought really to be i_size_read(inode) on some 32-bit configurations; though that's of very long standing, and has never caused any concern before.)
I am not at all willing to add annotations speculatively, in case this or that tool turns out to want help later. So far I've not heard of any such complaint on 5.7-rc[3456] or linux-next: but maybe this is too soon to hear a complaint, and you feel this should not be rushed into -stable?
This was an AUTOSEL selection, to which I have no objection, but it isn't something we were desperate to push into -stable: so I've also no objection if Greg shares your concern, and prefers to withdraw it. (That choice may depend on to what extent he expects to be keeping -stable clean against upcoming sanitizers in future.)
Sanitizers run on stable trees all the time as that's the releases that ends up on products, where people run them. That's why I like to take those types of fixes, especially when tools report them.
thanks,
greg k-h
From: Christophe JAILLET christophe.jaillet@wanadoo.fr
[ Upstream commit 10e3cc180e64385edc9890c6855acf5ed9ca1339 ]
A call to 'dma_alloc_coherent()' is hidden in 'sonic_alloc_descriptors()', called from 'sonic_probe1()'.
This is correctly freed in the remove function, but not in the error handling path of the probe function. Fix it and add the missing 'dma_free_coherent()' call.
While at it, rename a label in order to be slightly more informative.
Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/net/ethernet/natsemi/jazzsonic.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/natsemi/jazzsonic.c b/drivers/net/ethernet/natsemi/jazzsonic.c index 51fa82b429a3c..40970352d2082 100644 --- a/drivers/net/ethernet/natsemi/jazzsonic.c +++ b/drivers/net/ethernet/natsemi/jazzsonic.c @@ -235,11 +235,13 @@ static int jazz_sonic_probe(struct platform_device *pdev)
err = register_netdev(dev); if (err) - goto out1; + goto undo_probe1;
return 0;
-out1: +undo_probe1: + dma_free_coherent(lp->device, SIZEOF_SONIC_DESC * SONIC_BUS_SCALE(lp->dma_bitmode), + lp->descriptors, lp->descriptors_laddr); release_mem_region(dev->base_addr, SONIC_MEM_SIZE); out: free_netdev(dev);
From: Christophe JAILLET christophe.jaillet@wanadoo.fr
[ Upstream commit ee8d2267f0e39a1bfd95532da3a6405004114b27 ]
Should an irq requested with 'devm_request_irq' be released explicitly, it should be done by 'devm_free_irq()', not 'free_irq()'.
Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/net/ethernet/moxa/moxart_ether.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c index b34055ac476f7..4db3431b79ac1 100644 --- a/drivers/net/ethernet/moxa/moxart_ether.c +++ b/drivers/net/ethernet/moxa/moxart_ether.c @@ -561,7 +561,7 @@ static int moxart_remove(struct platform_device *pdev) struct net_device *ndev = platform_get_drvdata(pdev);
unregister_netdev(ndev); - free_irq(ndev->irq, ndev); + devm_free_irq(&pdev->dev, ndev->irq, ndev); moxart_mac_free_memory(ndev); free_netdev(ndev);
From: Arnd Bergmann arnd@arndb.de
[ Upstream commit dc30b4059f6e2abf3712ab537c8718562b21c45d ]
The current gcc-10 snapshot produces a false-positive warning:
net/core/drop_monitor.c: In function 'trace_drop_common.constprop': cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=] In file included from net/core/drop_monitor.c:23: include/uapi/linux/net_dropmon.h:36:8: note: at offset 0 to object 'entries' with size 4 declared here 36 | __u32 entries; | ^~~~~~~
I reported this in the gcc bugzilla, but in case it does not get fixed in the release, work around it by using a temporary variable.
Fixes: 9a8afc8d3962 ("Network Drop Monitor: Adding drop monitor implementation & Netlink protocol") Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881 Signed-off-by: Arnd Bergmann arnd@arndb.de Acked-by: Neil Horman nhorman@tuxdriver.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- net/core/drop_monitor.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c index c7785efeea577..3978a5e8d261c 100644 --- a/net/core/drop_monitor.c +++ b/net/core/drop_monitor.c @@ -154,6 +154,7 @@ static void sched_send_work(struct timer_list *t) static void trace_drop_common(struct sk_buff *skb, void *location) { struct net_dm_alert_msg *msg; + struct net_dm_drop_point *point; struct nlmsghdr *nlh; struct nlattr *nla; int i; @@ -172,11 +173,13 @@ static void trace_drop_common(struct sk_buff *skb, void *location) nlh = (struct nlmsghdr *)dskb->data; nla = genlmsg_data(nlmsg_data(nlh)); msg = nla_data(nla); + point = msg->points; for (i = 0; i < msg->entries; i++) { - if (!memcmp(&location, msg->points[i].pc, sizeof(void *))) { - msg->points[i].count++; + if (!memcmp(&location, &point->pc, sizeof(void *))) { + point->count++; goto out; } + point++; } if (msg->entries == dm_hit_limit) goto out; @@ -185,8 +188,8 @@ static void trace_drop_common(struct sk_buff *skb, void *location) */ __nla_reserve_nohdr(dskb, sizeof(struct net_dm_drop_point)); nla->nla_len += NLA_ALIGN(sizeof(struct net_dm_drop_point)); - memcpy(msg->points[msg->entries].pc, &location, sizeof(void *)); - msg->points[msg->entries].count = 1; + memcpy(point->pc, &location, sizeof(void *)); + point->count = 1; msg->entries++;
if (!timer_pending(&data->send_timer)) {
From: Stefan Hajnoczi stefanha@redhat.com
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90 [virtio] PGD 800000003a92f067 PUD 3a930067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 1310 Comm: hdio-getgeo Tainted: G OE ------------ 3.10.0-1062.el7.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 task: ffff9be5fbfb8000 ti: ffff9be5fa890000 task.ti: ffff9be5fa890000 RIP: 0010:[<ffffffffc00e5450>] [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90 [virtio] RSP: 0018:ffff9be5fa893dc8 EFLAGS: 00010246 RAX: ffff9be5fc3f3400 RBX: ffff9be5fa893e30 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff9be5fbc10b40 RBP: ffff9be5fa893dc8 R08: 0000000000000301 R09: 0000000000000301 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9be5fdc24680 R13: ffff9be5fbc10b40 R14: ffff9be5fbc10480 R15: 0000000000000000 FS: 00007f1bfb968740(0000) GS:ffff9be5ffc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000090 CR3: 000000003a894000 CR4: 0000000000360ff0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [<ffffffffc016ac37>] virtblk_getgeo+0x47/0x110 [virtio_blk] [<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0
A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc).
Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed in all cases.
Fixes: 48e4043d4529 ("virtio: add virtio disk geometry feature") Reported-by: Lance Digby ldigby@redhat.com Signed-off-by: Stefan Hajnoczi stefanha@redhat.com Link: https://lore.kernel.org/r/20200430140442.171016-1-stefanha@redhat.com Signed-off-by: Michael S. Tsirkin mst@redhat.com Reviewed-by: Stefano Garzarella sgarzare@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/block/virtio_blk.c | 86 ++++++++++++++++++++++++++++++++++---- 1 file changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 9a3c2b14ac378..9be54e5ef96ae 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -31,6 +31,15 @@ struct virtio_blk_vq { } ____cacheline_aligned_in_smp;
struct virtio_blk { + /* + * This mutex must be held by anything that may run after + * virtblk_remove() sets vblk->vdev to NULL. + * + * blk-mq, virtqueue processing, and sysfs attribute code paths are + * shut down before vblk->vdev is set to NULL and therefore do not need + * to hold this mutex. + */ + struct mutex vdev_mutex; struct virtio_device *vdev;
/* The disk structure for the kernel. */ @@ -42,6 +51,13 @@ struct virtio_blk { /* Process context for config space updates */ struct work_struct config_work;
+ /* + * Tracks references from block_device_operations open/release and + * virtio_driver probe/remove so this object can be freed once no + * longer in use. + */ + refcount_t refs; + /* What host tells us, plus 2 for header & tailer. */ unsigned int sg_elems;
@@ -320,10 +336,55 @@ static int virtblk_get_id(struct gendisk *disk, char *id_str) return err; }
+static void virtblk_get(struct virtio_blk *vblk) +{ + refcount_inc(&vblk->refs); +} + +static void virtblk_put(struct virtio_blk *vblk) +{ + if (refcount_dec_and_test(&vblk->refs)) { + ida_simple_remove(&vd_index_ida, vblk->index); + mutex_destroy(&vblk->vdev_mutex); + kfree(vblk); + } +} + +static int virtblk_open(struct block_device *bd, fmode_t mode) +{ + struct virtio_blk *vblk = bd->bd_disk->private_data; + int ret = 0; + + mutex_lock(&vblk->vdev_mutex); + + if (vblk->vdev) + virtblk_get(vblk); + else + ret = -ENXIO; + + mutex_unlock(&vblk->vdev_mutex); + return ret; +} + +static void virtblk_release(struct gendisk *disk, fmode_t mode) +{ + struct virtio_blk *vblk = disk->private_data; + + virtblk_put(vblk); +} + /* We provide getgeo only to please some old bootloader/partitioning tools */ static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo) { struct virtio_blk *vblk = bd->bd_disk->private_data; + int ret = 0; + + mutex_lock(&vblk->vdev_mutex); + + if (!vblk->vdev) { + ret = -ENXIO; + goto out; + }
/* see if the host passed in geometry config */ if (virtio_has_feature(vblk->vdev, VIRTIO_BLK_F_GEOMETRY)) { @@ -339,12 +400,16 @@ static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo) geo->sectors = 1 << 5; geo->cylinders = get_capacity(bd->bd_disk) >> 11; } - return 0; +out: + mutex_unlock(&vblk->vdev_mutex); + return ret; }
static const struct block_device_operations virtblk_fops = { .ioctl = virtblk_ioctl, .owner = THIS_MODULE, + .open = virtblk_open, + .release = virtblk_release, .getgeo = virtblk_getgeo, };
@@ -672,6 +737,10 @@ static int virtblk_probe(struct virtio_device *vdev) goto out_free_index; }
+ /* This reference is dropped in virtblk_remove(). */ + refcount_set(&vblk->refs, 1); + mutex_init(&vblk->vdev_mutex); + vblk->vdev = vdev; vblk->sg_elems = sg_elems;
@@ -824,8 +893,6 @@ static int virtblk_probe(struct virtio_device *vdev) static void virtblk_remove(struct virtio_device *vdev) { struct virtio_blk *vblk = vdev->priv; - int index = vblk->index; - int refc;
/* Make sure no work handler is accessing the device. */ flush_work(&vblk->config_work); @@ -835,18 +902,21 @@ static void virtblk_remove(struct virtio_device *vdev)
blk_mq_free_tag_set(&vblk->tag_set);
+ mutex_lock(&vblk->vdev_mutex); + /* Stop all the virtqueues. */ vdev->config->reset(vdev);
- refc = kref_read(&disk_to_dev(vblk->disk)->kobj.kref); + /* Virtqueues are stopped, nothing can use vblk->vdev anymore. */ + vblk->vdev = NULL; + put_disk(vblk->disk); vdev->config->del_vqs(vdev); kfree(vblk->vqs); - kfree(vblk);
- /* Only free device id if we don't have any users */ - if (refc == 1) - ida_simple_remove(&vd_index_ida, index); + mutex_unlock(&vblk->vdev_mutex); + + virtblk_put(vblk); }
#ifdef CONFIG_PM_SLEEP
From: Wu Bo wubo40@huawei.com
commit 83c6f2390040f188cc25b270b4befeb5628c1aee upstream.
If the __copy_from_user function failed we need to call sg_remove_request in sg_write.
Link: https://lore.kernel.org/r/610618d9-e983-fd56-ed0f-639428343af7@huawei.com Acked-by: Douglas Gilbert dgilbert@interlog.com Signed-off-by: Wu Bo wubo40@huawei.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org [groeck: Backport to v5.4.y and older kernels] Signed-off-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/scsi/sg.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -694,8 +694,10 @@ sg_write(struct file *filp, const char _ hp->flags = input_size; /* structure abuse ... */ hp->pack_id = old_hdr.pack_id; hp->usr_ptr = NULL; - if (__copy_from_user(cmnd, buf, cmd_size)) + if (__copy_from_user(cmnd, buf, cmd_size)) { + sg_remove_request(sfp, srp); return -EFAULT; + } /* * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV, * but is is possible that the app intended SG_DXFER_TO_DEV, because there
From: Raul E Rangel rrangel@chromium.org
[ Upstream commit 45a3fe3bf93b7cfeddc28ef7386555e05dc57f06 ]
The AMD eMMC 5.0 controller does not support 64 bit DMA.
Fixes: 34597a3f60b1 ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400") Signed-off-by: Raul E Rangel rrangel@chromium.org Link: https://marc.info/?l=linux-mmc&m=158879884514552&w=2 Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Acked-by: Adrian Hunter adrian.hunter@intel.com Link: https://lore.kernel.org/r/20200508165344.1.Id5bb8b1ae7ea576f26f9d91c761df7cc... Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/mmc/host/sdhci-acpi.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c index 57c1ec322e421..145143b6a0e6d 100644 --- a/drivers/mmc/host/sdhci-acpi.c +++ b/drivers/mmc/host/sdhci-acpi.c @@ -552,10 +552,12 @@ static int sdhci_acpi_emmc_amd_probe_slot(struct platform_device *pdev, }
static const struct sdhci_acpi_slot sdhci_acpi_slot_amd_emmc = { - .chip = &sdhci_acpi_chip_amd, - .caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE, - .quirks = SDHCI_QUIRK_32BIT_DMA_ADDR | SDHCI_QUIRK_32BIT_DMA_SIZE | - SDHCI_QUIRK_32BIT_ADMA_SIZE, + .chip = &sdhci_acpi_chip_amd, + .caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE, + .quirks = SDHCI_QUIRK_32BIT_DMA_ADDR | + SDHCI_QUIRK_32BIT_DMA_SIZE | + SDHCI_QUIRK_32BIT_ADMA_SIZE, + .quirks2 = SDHCI_QUIRK2_BROKEN_64_BIT_DMA, .probe_slot = sdhci_acpi_emmc_amd_probe_slot, };
From: Cong Wang xiyou.wangcong@gmail.com
[ Upstream commit dd912306ff008891c82cd9f63e8181e47a9cb2fb ]
syzbot managed to trigger a recursive NETDEV_FEAT_CHANGE event between bonding master and slave. I managed to find a reproducer for this:
ip li set bond0 up ifenslave bond0 eth0 brctl addbr br0 ethtool -K eth0 lro off brctl addif br0 bond0 ip li set br0 up
When a NETDEV_FEAT_CHANGE event is triggered on a bonding slave, it captures this and calls bond_compute_features() to fixup its master's and other slaves' features. However, when syncing with its lower devices by netdev_sync_lower_features() this event is triggered again on slaves when the LRO feature fails to change, so it goes back and forth recursively until the kernel stack is exhausted.
Commit 17b85d29e82c intentionally lets __netdev_update_features() return -1 for such a failure case, so we have to just rely on the existing check inside netdev_sync_lower_features() and skip NETDEV_FEAT_CHANGE event only for this specific failure case.
Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack") Reported-by: syzbot+e73ceacfd8560cc8a3ca@syzkaller.appspotmail.com Reported-by: syzbot+c2fb6f9ddcea95ba49b5@syzkaller.appspotmail.com Cc: Jarod Wilson jarod@redhat.com Cc: Nikolay Aleksandrov nikolay@cumulusnetworks.com Cc: Josh Poimboeuf jpoimboe@redhat.com Cc: Jann Horn jannh@google.com Reviewed-by: Jay Vosburgh jay.vosburgh@canonical.com Signed-off-by: Cong Wang xiyou.wangcong@gmail.com Acked-by: Nikolay Aleksandrov nikolay@cumulusnetworks.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/core/dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/core/dev.c +++ b/net/core/dev.c @@ -8259,11 +8259,13 @@ static void netdev_sync_lower_features(s netdev_dbg(upper, "Disabling feature %pNF on lower dev %s.\n", &feature, lower->name); lower->wanted_features &= ~feature; - netdev_update_features(lower); + __netdev_update_features(lower);
if (unlikely(lower->features & feature)) netdev_WARN(upper, "failed to disable %pNF on %s!\n", &feature, lower->name); + else + netdev_features_change(lower); } } }
From: Paolo Abeni pabeni@redhat.com
[ Upstream commit eead1c2ea2509fd754c6da893a94f0e69e83ebe4 ]
The cipso and calipso code can set the MLS_CAT attribute on successful parsing, even if the corresponding catmap has not been allocated, as per current configuration and external input.
Later, selinux code tries to access the catmap if the MLS_CAT flag is present via netlbl_catmap_getlong(). That may cause null ptr dereference while processing incoming network traffic.
Address the issue setting the MLS_CAT flag only if the catmap is really allocated. Additionally let netlbl_catmap_getlong() cope with NULL catmap.
Reported-by: Matthew Sheets matthew.sheets@gd-ms.com Fixes: 4b8feff251da ("netlabel: fix the horribly broken catmap functions") Fixes: ceba1832b1b2 ("calipso: Set the calipso socket label to match the secattr.") Signed-off-by: Paolo Abeni pabeni@redhat.com Acked-by: Paul Moore paul@paul-moore.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/ipv4/cipso_ipv4.c | 6 ++++-- net/ipv6/calipso.c | 3 ++- net/netlabel/netlabel_kapi.c | 6 ++++++ 3 files changed, 12 insertions(+), 3 deletions(-)
--- a/net/ipv4/cipso_ipv4.c +++ b/net/ipv4/cipso_ipv4.c @@ -1272,7 +1272,8 @@ static int cipso_v4_parsetag_rbm(const s return ret_val; }
- secattr->flags |= NETLBL_SECATTR_MLS_CAT; + if (secattr->attr.mls.cat) + secattr->flags |= NETLBL_SECATTR_MLS_CAT; }
return 0; @@ -1453,7 +1454,8 @@ static int cipso_v4_parsetag_rng(const s return ret_val; }
- secattr->flags |= NETLBL_SECATTR_MLS_CAT; + if (secattr->attr.mls.cat) + secattr->flags |= NETLBL_SECATTR_MLS_CAT; }
return 0; --- a/net/ipv6/calipso.c +++ b/net/ipv6/calipso.c @@ -1061,7 +1061,8 @@ static int calipso_opt_getattr(const uns goto getattr_return; }
- secattr->flags |= NETLBL_SECATTR_MLS_CAT; + if (secattr->attr.mls.cat) + secattr->flags |= NETLBL_SECATTR_MLS_CAT; }
secattr->type = NETLBL_NLTYPE_CALIPSO; --- a/net/netlabel/netlabel_kapi.c +++ b/net/netlabel/netlabel_kapi.c @@ -748,6 +748,12 @@ int netlbl_catmap_getlong(struct netlbl_ if ((off & (BITS_PER_LONG - 1)) != 0) return -EINVAL;
+ /* a null catmap is equivalent to an empty one */ + if (!catmap) { + *offset = (u32)-1; + return 0; + } + if (off < catmap->startbit) { off = catmap->startbit; *offset = off;
From: Heiner Kallweit hkallweit1@gmail.com
[ Upstream commit 9de5d235b60a7cdfcdd5461e70c5663e713fde87 ]
phy_restart_aneg() enables aneg in the PHY. That's not what we want if phydev->autoneg is disabled. In this case still update EEE advertisement register, but don't enable aneg and don't trigger an aneg restart.
Fixes: f75abeb8338e ("net: phy: restart phy autonegotiation after EEE advertisment change") Signed-off-by: Heiner Kallweit hkallweit1@gmail.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/phy/phy.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -1302,9 +1302,11 @@ int phy_ethtool_set_eee(struct phy_devic /* Restart autonegotiation so the new modes get sent to the * link partner. */ - ret = phy_restart_aneg(phydev); - if (ret < 0) - return ret; + if (phydev->autoneg == AUTONEG_ENABLE) { + ret = phy_restart_aneg(phydev); + if (ret < 0) + return ret; + } }
return 0;
From: Guillaume Nault gnault@redhat.com
[ Upstream commit b8c158395119be62294da73646a3953c29ac974b ]
We don't want to disconnect a session because of a stray PADT arriving while the interface is in promiscuous mode. Furthermore, multicast and broadcast packets make no sense here, so only PACKET_HOST is accepted.
Reported-by: David Balažic xerces9@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Guillaume Nault gnault@redhat.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ppp/pppoe.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/net/ppp/pppoe.c +++ b/drivers/net/ppp/pppoe.c @@ -497,6 +497,9 @@ static int pppoe_disc_rcv(struct sk_buff if (!skb) goto out;
+ if (skb->pkt_type != PACKET_HOST) + goto abort; + if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr))) goto abort;
Hi!
Is there a good reason this did not land in 4.14 branch?
Openwrt is using that and so it missed this patch.
Any chance it goes in in next round?
Regards, David
On Mon, 18 May 2020 at 19:50, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
From: Guillaume Nault gnault@redhat.com
[ Upstream commit b8c158395119be62294da73646a3953c29ac974b ]
We don't want to disconnect a session because of a stray PADT arriving while the interface is in promiscuous mode. Furthermore, multicast and broadcast packets make no sense here, so only PACKET_HOST is accepted.
Reported-by: David Balažic xerces9@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Guillaume Nault gnault@redhat.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
drivers/net/ppp/pppoe.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/net/ppp/pppoe.c +++ b/drivers/net/ppp/pppoe.c @@ -497,6 +497,9 @@ static int pppoe_disc_rcv(struct sk_buff if (!skb) goto out;
if (skb->pkt_type != PACKET_HOST)
goto abort;
if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr))) goto abort;
On Thu, Jun 04, 2020 at 08:39:00PM +0200, David Balažic wrote:
Hi!
Is there a good reason this did not land in 4.14 branch?
Openwrt is using that and so it missed this patch.
Any chance it goes in in next round?
Does it apply and build cleanly?
I don't know why I didn't backport it further, something must have broke...
greg k-h
On Thu, 4 Jun 2020 at 22:17, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Thu, Jun 04, 2020 at 08:39:00PM +0200, David Balažic wrote:
Hi!
Is there a good reason this did not land in 4.14 branch?
Openwrt is using that and so it missed this patch.
Any chance it goes in in next round?
Does it apply and build cleanly?
I don't know why I didn't backport it further, something must have broke...
The patch from the above applies to linux-4.14.183
If I apply it manually (open pppoe.c in editor and add the two lines from the patch) then it builds. Until LD vmlinux.o when I run out of disk space... I applied it by editor because the first time something went wrong when copying the patch from the email and it did not apply.
So it looks OK, but someone else should try it too. My build system is not exactly great.. (it is a VM I created for openwrt builds and it is after midnight and I don't feel like extending the virtual disk.. sorry, maybe tomorrow).
Regards, David
On Fri, Jun 05, 2020 at 12:31:31AM +0200, David Balažic wrote:
On Thu, 4 Jun 2020 at 22:17, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Thu, Jun 04, 2020 at 08:39:00PM +0200, David Balažic wrote:
Hi!
Is there a good reason this did not land in 4.14 branch?
Openwrt is using that and so it missed this patch.
Any chance it goes in in next round?
Does it apply and build cleanly?
I don't know why I didn't backport it further, something must have broke...
The patch from the above applies to linux-4.14.183
If I apply it manually (open pppoe.c in editor and add the two lines from the patch) then it builds. Until LD vmlinux.o when I run out of disk space... I applied it by editor because the first time something went wrong when copying the patch from the email and it did not apply.
So it looks OK, but someone else should try it too. My build system is not exactly great.. (it is a VM I created for openwrt builds and it is after midnight and I don't feel like extending the virtual disk.. sorry, maybe tomorrow).
Hm, indeed it looks ok for 4.14 (and 4.9, 4.4) so I've queued it up, thank you.
From: "Maciej Żenczykowski" maze@google.com
[ Upstream commit 09454fd0a4ce23cb3d8af65066c91a1bf27120dd ]
This reverts commit 19bda36c4299ce3d7e5bce10bebe01764a655a6d:
| ipv6: add mtu lock check in __ip6_rt_update_pmtu | | Prior to this patch, ipv6 didn't do mtu lock check in ip6_update_pmtu. | It leaded to that mtu lock doesn't really work when receiving the pkt | of ICMPV6_PKT_TOOBIG. | | This patch is to add mtu lock check in __ip6_rt_update_pmtu just as ipv4 | did in __ip_rt_update_pmtu.
The above reasoning is incorrect. IPv6 *requires* icmp based pmtu to work. There's already a comment to this effect elsewhere in the kernel:
$ git grep -p -B1 -A3 'RTAX_MTU lock' net/ipv6/route.c=4813=
static int rt6_mtu_change_route(struct fib6_info *f6i, void *p_arg) ... /* In IPv6 pmtu discovery is not optional, so that RTAX_MTU lock cannot disable it. We still use this lock to block changes caused by addrconf/ndisc. */
This reverts to the pre-4.9 behaviour.
Cc: Eric Dumazet edumazet@google.com Cc: Willem de Bruijn willemb@google.com Cc: Xin Long lucien.xin@gmail.com Cc: Hannes Frederic Sowa hannes@stressinduktion.org Signed-off-by: Maciej Żenczykowski maze@google.com Fixes: 19bda36c4299 ("ipv6: add mtu lock check in __ip6_rt_update_pmtu") Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/ipv6/route.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2360,8 +2360,10 @@ static void __ip6_rt_update_pmtu(struct const struct in6_addr *daddr, *saddr; struct rt6_info *rt6 = (struct rt6_info *)dst;
- if (dst_metric_locked(dst, RTAX_MTU)) - return; + /* Note: do *NOT* check dst_metric_locked(dst, RTAX_MTU) + * IPv6 pmtu discovery isn't optional, so 'mtu lock' cannot disable it. + * [see also comment in rt6_mtu_change_route()] + */
if (iph) { daddr = &iph->daddr;
From: Eric Dumazet edumazet@google.com
[ Upstream commit e776af608f692a7a647455106295fa34469e7475 ]
If user provides wrong virtual address in TCP_ZEROCOPY_RECEIVE operation we want to return -EINVAL error.
But depending on zc->recv_skip_hint content, we might return -EIO error if the socket has SOCK_DONE set.
Make sure to return -EINVAL in this case.
BUG: KMSAN: uninit-value in tcp_zerocopy_receive net/ipv4/tcp.c:1833 [inline] BUG: KMSAN: uninit-value in do_tcp_getsockopt+0x4494/0x6320 net/ipv4/tcp.c:3685 CPU: 1 PID: 625 Comm: syz-executor.0 Not tainted 5.7.0-rc4-syzkaller #0 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+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 tcp_zerocopy_receive net/ipv4/tcp.c:1833 [inline] do_tcp_getsockopt+0x4494/0x6320 net/ipv4/tcp.c:3685 tcp_getsockopt+0xf8/0x1f0 net/ipv4/tcp.c:3728 sock_common_getsockopt+0x13f/0x180 net/core/sock.c:3131 __sys_getsockopt+0x533/0x7b0 net/socket.c:2177 __do_sys_getsockopt net/socket.c:2192 [inline] __se_sys_getsockopt+0xe1/0x100 net/socket.c:2189 __x64_sys_getsockopt+0x62/0x80 net/socket.c:2189 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:297 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45c829 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f1deeb72c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 00000000004e01e0 RCX: 000000000045c829 RDX: 0000000000000023 RSI: 0000000000000006 RDI: 0000000000000009 RBP: 000000000078bf00 R08: 0000000020000200 R09: 0000000000000000 R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000001d8 R14: 00000000004d3038 R15: 00007f1deeb736d4
Local variable ----zc@do_tcp_getsockopt created at: do_tcp_getsockopt+0x1a74/0x6320 net/ipv4/tcp.c:3670 do_tcp_getsockopt+0x1a74/0x6320 net/ipv4/tcp.c:3670
Fixes: 05255b823a61 ("tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive") Signed-off-by: Eric Dumazet edumazet@google.com Reported-by: syzbot syzkaller@googlegroups.com Acked-by: Soheil Hassas Yeganeh soheil@google.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/ipv4/tcp.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
--- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1774,10 +1774,11 @@ static int tcp_zerocopy_receive(struct s
down_read(¤t->mm->mmap_sem);
- ret = -EINVAL; vma = find_vma(current->mm, address); - if (!vma || vma->vm_start > address || vma->vm_ops != &tcp_vm_ops) - goto out; + if (!vma || vma->vm_start > address || vma->vm_ops != &tcp_vm_ops) { + up_read(¤t->mm->mmap_sem); + return -EINVAL; + } zc->length = min_t(unsigned long, zc->length, vma->vm_end - address);
tp = tcp_sk(sk);
From: "Michael S. Tsirkin" mst@redhat.com
[ Upstream commit 01c3259818a11f3cc3cd767adbae6b45849c03c1 ]
When we fill up a receive VQ, try_fill_recv currently tries to count kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that uses a seqcount. sequence counts are "lock" constructs where you need to make sure that writers are serialized.
In turn, this means that we mustn't run two try_fill_recv concurrently. Which of course we don't. We do run try_fill_recv sometimes from a softirq napi context, and sometimes from a fully preemptible context, but the later always runs with napi disabled.
However, when it comes to the seqcount, lockdep is trying to enforce the rule that the same lock isn't accessed from preemptible and softirq context - it doesn't know about napi being enabled/disabled. This causes a false-positive warning:
WARNING: inconsistent lock state ... inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
As a work around, shut down the warning by switching to u64_stats_update_begin_irqsave - that works by disabling interrupts on 32 bit only, is a NOP on 64 bit.
Reported-by: Thomas Gleixner tglx@linutronix.de Suggested-by: Eric Dumazet eric.dumazet@gmail.com Signed-off-by: Michael S. Tsirkin mst@redhat.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/virtio_net.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1242,9 +1242,11 @@ static bool try_fill_recv(struct virtnet break; } while (rq->vq->num_free); if (virtqueue_kick_prepare(rq->vq) && virtqueue_notify(rq->vq)) { - u64_stats_update_begin(&rq->stats.syncp); + unsigned long flags; + + flags = u64_stats_update_begin_irqsave(&rq->stats.syncp); rq->stats.kicks++; - u64_stats_update_end(&rq->stats.syncp); + u64_stats_update_end_irqrestore(&rq->stats.syncp, flags); }
return !oom;
From: Luo bin luobin9@huawei.com
[ Upstream commit e8a1b0efd632d1c9db7d4e93da66377c7b524862 ]
if some function in ndo_stop interface returns failure because of hardware fault, must go on excuting rest steps rather than return failure directly, otherwise will cause memory leak.And bump the timeout for SET_FUNC_STATE to ensure that cmd won't return failure when hw is busy. Otherwise hw may stomp host memory if we free memory regardless of the return value of SET_FUNC_STATE.
Fixes: 51ba902a16e6 ("net-next/hinic: Initialize hw interface") Signed-off-by: Luo bin luobin9@huawei.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 16 ++++++++++++---- drivers/net/ethernet/huawei/hinic/hinic_main.c | 18 +++--------------- 2 files changed, 15 insertions(+), 19 deletions(-)
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c @@ -54,6 +54,8 @@
#define MGMT_MSG_TIMEOUT 5000
+#define SET_FUNC_PORT_MGMT_TIMEOUT 25000 + #define mgmt_to_pfhwdev(pf_mgmt) \ container_of(pf_mgmt, struct hinic_pfhwdev, pf_to_mgmt)
@@ -247,12 +249,13 @@ static int msg_to_mgmt_sync(struct hinic u8 *buf_in, u16 in_size, u8 *buf_out, u16 *out_size, enum mgmt_direction_type direction, - u16 resp_msg_id) + u16 resp_msg_id, u32 timeout) { struct hinic_hwif *hwif = pf_to_mgmt->hwif; struct pci_dev *pdev = hwif->pdev; struct hinic_recv_msg *recv_msg; struct completion *recv_done; + unsigned long timeo; u16 msg_id; int err;
@@ -276,8 +279,9 @@ static int msg_to_mgmt_sync(struct hinic goto unlock_sync_msg; }
- if (!wait_for_completion_timeout(recv_done, - msecs_to_jiffies(MGMT_MSG_TIMEOUT))) { + timeo = msecs_to_jiffies(timeout ? timeout : MGMT_MSG_TIMEOUT); + + if (!wait_for_completion_timeout(recv_done, timeo)) { dev_err(&pdev->dev, "MGMT timeout, MSG id = %d\n", msg_id); err = -ETIMEDOUT; goto unlock_sync_msg; @@ -351,6 +355,7 @@ int hinic_msg_to_mgmt(struct hinic_pf_to { struct hinic_hwif *hwif = pf_to_mgmt->hwif; struct pci_dev *pdev = hwif->pdev; + u32 timeout = 0;
if (sync != HINIC_MGMT_MSG_SYNC) { dev_err(&pdev->dev, "Invalid MGMT msg type\n"); @@ -362,9 +367,12 @@ int hinic_msg_to_mgmt(struct hinic_pf_to return -EINVAL; }
+ if (cmd == HINIC_PORT_CMD_SET_FUNC_STATE) + timeout = SET_FUNC_PORT_MGMT_TIMEOUT; + return msg_to_mgmt_sync(pf_to_mgmt, mod, cmd, buf_in, in_size, buf_out, out_size, MGMT_DIRECT_SEND, - MSG_NOT_RESP); + MSG_NOT_RESP, timeout); }
/** --- a/drivers/net/ethernet/huawei/hinic/hinic_main.c +++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c @@ -475,7 +475,6 @@ static int hinic_close(struct net_device { struct hinic_dev *nic_dev = netdev_priv(netdev); unsigned int flags; - int err;
down(&nic_dev->mgmt_lock);
@@ -489,20 +488,9 @@ static int hinic_close(struct net_device
up(&nic_dev->mgmt_lock);
- err = hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE); - if (err) { - netif_err(nic_dev, drv, netdev, - "Failed to set func port state\n"); - nic_dev->flags |= (flags & HINIC_INTF_UP); - return err; - } - - err = hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE); - if (err) { - netif_err(nic_dev, drv, netdev, "Failed to set port state\n"); - nic_dev->flags |= (flags & HINIC_INTF_UP); - return err; - } + hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE); + + hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE);
free_rxqs(nic_dev); free_txqs(nic_dev);
From: Florian Fainelli f.fainelli@gmail.com
[ Upstream commit 3047211ca11bf77b3ecbce045c0aa544d934b945 ]
There is a soft dependency against dsa_loop_bdinfo.ko which sets up the MDIO device registration, since there are no symbols referenced by dsa_loop.ko, there is no automatic loading of dsa_loop_bdinfo.ko which is needed.
Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver") Signed-off-by: Florian Fainelli f.fainelli@gmail.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/dsa/dsa_loop.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/net/dsa/dsa_loop.c +++ b/drivers/net/dsa/dsa_loop.c @@ -360,6 +360,7 @@ static void __exit dsa_loop_exit(void) } module_exit(dsa_loop_exit);
+MODULE_SOFTDEP("pre: dsa_loop_bdinfo"); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Florian Fainelli"); MODULE_DESCRIPTION("DSA loopback driver");
From: Paolo Abeni pabeni@redhat.com
[ Upstream commit 57644431a6c2faac5d754ebd35780cf43a531b1a ]
In commit b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and rate_tokens usage") I missed the fact that a 0 'rate_tokens' will bypass the backoff algorithm.
Since rate_tokens is cleared after a redirect silence, and never incremented on redirects, if the host keeps receiving packets requiring redirect it will reply ignoring the backoff.
Additionally, the 'rate_last' field will be updated with the cadence of the ingress packet requiring redirect. If that rate is high enough, that will prevent the host from generating any other kind of ICMP messages
The check for a zero 'rate_tokens' value was likely a shortcut to avoid the more complex backoff algorithm after a redirect silence period. Address the issue checking for 'n_redirects' instead, which is incremented on successful redirect, and does not interfere with other ICMP replies.
Fixes: b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and rate_tokens usage") Reported-and-tested-by: Colin Walters walters@redhat.com Signed-off-by: Paolo Abeni pabeni@redhat.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/ipv4/route.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -906,7 +906,7 @@ void ip_rt_send_redirect(struct sk_buff /* Check for load limit; set rate_last to the latest sent * redirect. */ - if (peer->rate_tokens == 0 || + if (peer->n_redirects == 0 || time_after(jiffies, (peer->rate_last + (ip_rt_redirect_load << peer->n_redirects)))) {
From: Zefan Li lizefan@huawei.com
[ Upstream commit 090e28b229af92dc5b40786ca673999d59e73056 ]
If systemd is configured to use hybrid mode which enables the use of both cgroup v1 and v2, systemd will create new cgroup on both the default root (v2) and netprio_cgroup hierarchy (v1) for a new session and attach task to the two cgroups. If the task does some network thing then the v2 cgroup can never be freed after the session exited.
One of our machines ran into OOM due to this memory leak.
In the scenario described above when sk_alloc() is called cgroup_sk_alloc() thought it's in v2 mode, so it stores the cgroup pointer in sk->sk_cgrp_data and increments the cgroup refcnt, but then sock_update_netprioidx() thought it's in v1 mode, so it stores netprioidx value in sk->sk_cgrp_data, so the cgroup refcnt will never be freed.
Currently we do the mode switch when someone writes to the ifpriomap cgroup control file. The easiest fix is to also do the switch when a task is attached to a new cgroup.
Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup") Reported-by: Yang Yingliang yangyingliang@huawei.com Tested-by: Yang Yingliang yangyingliang@huawei.com Signed-off-by: Zefan Li lizefan@huawei.com Acked-by: Tejun Heo tj@kernel.org Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/core/netprio_cgroup.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/net/core/netprio_cgroup.c +++ b/net/core/netprio_cgroup.c @@ -240,6 +240,8 @@ static void net_prio_attach(struct cgrou struct task_struct *p; struct cgroup_subsys_state *css;
+ cgroup_sk_alloc_disable(); + cgroup_taskset_for_each(p, css, tset) { void *v = (void *)(unsigned long)css->cgroup->id;
From: Kelly Littlepage kelly@onechronos.com
[ Upstream commit cc4de047b33be247f9c8150d3e496743a49642b8 ]
The stated intent of the original commit is to is to "return the timestamp corresponding to the highest sequence number data returned." The current implementation returns the timestamp for the last byte of the last fully read skb, which is not necessarily the last byte in the recv buffer. This patch converts behavior to the original definition, and to the behavior of the previous draft versions of commit 98aaa913b4ed ("tcp: Extend SOF_TIMESTAMPING_RX_SOFTWARE to TCP recvmsg") which also match this behavior.
Fixes: 98aaa913b4ed ("tcp: Extend SOF_TIMESTAMPING_RX_SOFTWARE to TCP recvmsg") Co-developed-by: Iris Liu iris@onechronos.com Signed-off-by: Iris Liu iris@onechronos.com Signed-off-by: Kelly Littlepage kelly@onechronos.com Signed-off-by: Eric Dumazet edumazet@google.com Acked-by: Soheil Hassas Yeganeh soheil@google.com Acked-by: Willem de Bruijn willemb@google.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/ipv4/tcp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2135,14 +2135,16 @@ skip_copy: tp->urg_data = 0; tcp_fast_path_check(sk); } - if (used + offset < skb->len) - continue;
if (TCP_SKB_CB(skb)->has_rxtstamp) { tcp_update_recv_tstamps(skb, &tss); has_tss = true; has_cmsg = true; } + + if (used + offset < skb->len) + continue; + if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN) goto found_fin_ok; if (!(flags & MSG_PEEK))
From: Eric Dumazet edumazet@google.com
[ Upstream commit 24adbc1676af4e134e709ddc7f34cf2adc2131e4 ]
We autotune rcvbuf whenever SO_RCVLOWAT is set to account for 100% overhead in tcp_set_rcvlowat()
This works well when skb->len/skb->truesize ratio is bigger than 0.5
But if we receive packets with small MSS, we can end up in a situation where not enough bytes are available in the receive queue to satisfy RCVLOWAT setting. As our sk_rcvbuf limit is hit, we send zero windows in ACK packets, preventing remote peer from sending more data.
Even autotuning does not help, because it only triggers at the time user process drains the queue. If no EPOLLIN is generated, this can not happen.
Note poll() has a similar issue, after commit c7004482e8dc ("tcp: Respect SO_RCVLOWAT in tcp_poll().")
Fixes: 03f45c883c6f ("tcp: avoid extra wakeups for SO_RCVLOWAT users") Signed-off-by: Eric Dumazet edumazet@google.com Acked-by: Soheil Hassas Yeganeh soheil@google.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- include/net/tcp.h | 13 +++++++++++++ net/ipv4/tcp.c | 14 +++++++++++--- net/ipv4/tcp_input.c | 3 ++- 3 files changed, 26 insertions(+), 4 deletions(-)
--- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -1373,6 +1373,19 @@ static inline int tcp_full_space(const s return tcp_win_from_space(sk, sk->sk_rcvbuf); }
+/* We provision sk_rcvbuf around 200% of sk_rcvlowat. + * If 87.5 % (7/8) of the space has been consumed, we want to override + * SO_RCVLOWAT constraint, since we are receiving skbs with too small + * len/truesize ratio. + */ +static inline bool tcp_rmem_pressure(const struct sock *sk) +{ + int rcvbuf = READ_ONCE(sk->sk_rcvbuf); + int threshold = rcvbuf - (rcvbuf >> 3); + + return atomic_read(&sk->sk_rmem_alloc) > threshold; +} + extern void tcp_openreq_init_rwin(struct request_sock *req, const struct sock *sk_listener, const struct dst_entry *dst); --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -488,9 +488,17 @@ static void tcp_tx_timestamp(struct sock static inline bool tcp_stream_is_readable(const struct tcp_sock *tp, int target, struct sock *sk) { - return (READ_ONCE(tp->rcv_nxt) - tp->copied_seq >= target) || - (sk->sk_prot->stream_memory_read ? - sk->sk_prot->stream_memory_read(sk) : false); + int avail = READ_ONCE(tp->rcv_nxt) - READ_ONCE(tp->copied_seq); + + if (avail > 0) { + if (avail >= target) + return true; + if (tcp_rmem_pressure(sk)) + return true; + } + if (sk->sk_prot->stream_memory_read) + return sk->sk_prot->stream_memory_read(sk); + return false; }
/* --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4683,7 +4683,8 @@ void tcp_data_ready(struct sock *sk) const struct tcp_sock *tp = tcp_sk(sk); int avail = tp->rcv_nxt - tp->copied_seq;
- if (avail < sk->sk_rcvlowat && !sock_flag(sk, SOCK_DONE)) + if (avail < sk->sk_rcvlowat && !tcp_rmem_pressure(sk) && + !sock_flag(sk, SOCK_DONE)) return;
sk->sk_data_ready(sk);
From: Ilie Halip ilie.halip@gmail.com
[ Upstream commit 3c1918c8f54166598195d938564072664a8275b1 ]
When building with the LLVM linker this error occurrs: LD arch/riscv/kernel/vdso/vdso-syms.o ld.lld: error: no input files
This happens because the lld treats -R as an alias to -rpath, as opposed to ld where -R means --just-symbols.
Use the long option name for compatibility between the two.
Link: https://github.com/ClangBuiltLinux/linux/issues/805 Reported-by: Dmitry Golovin dima@golovin.in Reviewed-by: Nick Desaulniers ndesaulniers@google.com Signed-off-by: Ilie Halip ilie.halip@gmail.com Reviewed-by: Fangrui Song maskray@google.com Signed-off-by: Palmer Dabbelt palmerdabbelt@google.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/riscv/kernel/vdso/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 87f71a6cd3ef8..1dd134fc0d84a 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -30,15 +30,15 @@ $(obj)/vdso.so.dbg: $(src)/vdso.lds $(obj-vdso) FORCE $(call if_changed,vdsold)
# We also create a special relocatable object that should mirror the symbol -# table and layout of the linked DSO. With ld -R we can then refer to -# these symbols in the kernel code rather than hand-coded addresses. +# table and layout of the linked DSO. With ld --just-symbols we can then +# refer to these symbols in the kernel code rather than hand-coded addresses.
SYSCFLAGS_vdso.so.dbg = -shared -s -Wl,-soname=linux-vdso.so.1 \ $(call cc-ldoption, -Wl$(comma)--hash-style=both) $(obj)/vdso-dummy.o: $(src)/vdso.lds $(obj)/rt_sigreturn.o FORCE $(call if_changed,vdsold)
-LDFLAGS_vdso-syms.o := -r -R +LDFLAGS_vdso-syms.o := -r --just-symbols $(obj)/vdso-syms.o: $(obj)/vdso-dummy.o FORCE $(call if_changed,ld)
From: Madhuparna Bhowmik madhuparnabhowmik10@gmail.com
[ Upstream commit 2e45676a4d33af47259fa186ea039122ce263ba9 ]
pd->dma.dev is read in irq handler pd_irq(). However, it is set to pdev->dev after request_irq(). Therefore, set pd->dma.dev to pdev->dev before request_irq() to avoid data race between pch_dma_probe() and pd_irq().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Madhuparna Bhowmik madhuparnabhowmik10@gmail.com Link: https://lore.kernel.org/r/20200416062335.29223-1-madhuparnabhowmik10@gmail.c... Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/dma/pch_dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c index afd8f27bda969..6e91584c36770 100644 --- a/drivers/dma/pch_dma.c +++ b/drivers/dma/pch_dma.c @@ -873,6 +873,7 @@ static int pch_dma_probe(struct pci_dev *pdev, }
pci_set_master(pdev); + pd->dma.dev = &pdev->dev;
err = request_irq(pdev->irq, pd_irq, IRQF_SHARED, DRV_NAME, pd); if (err) { @@ -888,7 +889,6 @@ static int pch_dma_probe(struct pci_dev *pdev, goto err_free_irq; }
- pd->dma.dev = &pdev->dev;
INIT_LIST_HEAD(&pd->dma.channels);
From: Lubomir Rintel lkundrak@v3.sk
[ Upstream commit 0c89446379218698189a47871336cb30286a7197 ]
When a channel configuration fails, the status of the channel is set to DEV_ERROR so that an attempt to submit it fails. However, this status sticks until the heat end of the universe, making it impossible to recover from the error.
Let's reset it when the channel is released so that further use of the channel with correct configuration is not impacted.
Signed-off-by: Lubomir Rintel lkundrak@v3.sk Link: https://lore.kernel.org/r/20200419164912.670973-5-lkundrak@v3.sk Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/dma/mmp_tdma.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c index 13c68b6434ce2..15b4a44e60069 100644 --- a/drivers/dma/mmp_tdma.c +++ b/drivers/dma/mmp_tdma.c @@ -362,6 +362,8 @@ static void mmp_tdma_free_descriptor(struct mmp_tdma_chan *tdmac) gen_pool_free(gpool, (unsigned long)tdmac->desc_arr, size); tdmac->desc_arr = NULL; + if (tdmac->status == DMA_ERROR) + tdmac->status = DMA_COMPLETE;
return; }
From: Chris Wilson chris@chris-wilson.co.uk
[ Upstream commit 8c539776ac83c0857395e1ccc9c6b516521a2d32 ]
Make a note of the first time we discover the turbo mode has been disabled by the BIOS, as otherwise we complain every time we try to update the mode.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/cpufreq/intel_pstate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 29f25d5d65e00..e7b3d4ed8eff4 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -957,7 +957,7 @@ static ssize_t store_no_turbo(struct kobject *a, struct kobj_attribute *b,
update_turbo_state(); if (global.turbo_disabled) { - pr_warn("Turbo disabled by BIOS or unavailable on processor\n"); + pr_notice_once("Turbo disabled by BIOS or unavailable on processor\n"); mutex_unlock(&intel_pstate_limits_lock); mutex_unlock(&intel_pstate_driver_lock); return -EPERM;
From: Kai Vehmanen kai.vehmanen@linux.intel.com
[ Upstream commit ca76282b6faffc83601c25bd2a95f635c03503ef ]
A race exists between build_pcms() and build_controls() phases of codec setup. Build_pcms() sets up notifier for jack events. If a monitor event is received before build_controls() is run, the initial jack state is lost and never reported via mixer controls.
The problem can be hit at least with SOF as the controller driver. SOF calls snd_hda_codec_build_controls() in its workqueue-based probe and this can be delayed enough to hit the race condition.
Fix the issue by invalidating the per-pin ELD information when build_controls() is called. The existing call to hdmi_present_sense() will update the ELD contents. This ensures initial monitor state is correctly reflected via mixer controls.
BugLink: https://github.com/thesofproject/linux/issues/1687 Signed-off-by: Kai Vehmanen kai.vehmanen@linux.intel.com Link: https://lore.kernel.org/r/20200428123836.24512-1-kai.vehmanen@linux.intel.co... Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org --- sound/pci/hda/patch_hdmi.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 12a064f994b1a..1d83c3c59e1ac 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2211,7 +2211,9 @@ static int generic_hdmi_build_controls(struct hda_codec *codec)
for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) { struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx); + struct hdmi_eld *pin_eld = &per_pin->sink_eld;
+ pin_eld->eld_valid = false; hdmi_present_sense(per_pin, 0); }
From: Vasily Averin vvs@virtuozzo.com
[ Upstream commit 5b5703dbafae74adfbe298a56a81694172caf5e6 ]
v2: removed TODO reminder
Signed-off-by: Vasily Averin vvs@virtuozzo.com Link: http://patchwork.freedesktop.org/patch/msgid/a4e0ae09-a73c-1c62-04ef-3f990d4... Signed-off-by: Gerd Hoffmann kraxel@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/qxl/qxl_image.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_image.c b/drivers/gpu/drm/qxl/qxl_image.c index 7fbcc35e8ad35..c89c10055641e 100644 --- a/drivers/gpu/drm/qxl/qxl_image.c +++ b/drivers/gpu/drm/qxl/qxl_image.c @@ -210,7 +210,8 @@ qxl_image_init_helper(struct qxl_device *qdev, break; default: DRM_ERROR("unsupported image bit depth\n"); - return -EINVAL; /* TODO: cleanup */ + qxl_bo_kunmap_atomic_page(qdev, image_bo, ptr); + return -EINVAL; } image->u.bitmap.flags = QXL_BITMAP_TOP_DOWN; image->u.bitmap.x = width;
From: Vasily Averin vvs@virtuozzo.com
[ Upstream commit 5e698222c70257d13ae0816720dde57c56f81e15 ]
Commit 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position index") is causing this bug (seen on 5.6.8):
# ipcs -q
------ Message Queues -------- key msqid owner perms used-bytes messages
# ipcmk -Q Message queue id: 0 # ipcs -q
------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0
# ipcmk -Q Message queue id: 1 # ipcs -q
------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0 0x76d1fb2a 1 root 644 0 0
# ipcrm -q 0 # ipcs -q
------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0
# ipcmk -Q Message queue id: 2 # ipcrm -q 2 # ipcs -q
------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0
# ipcmk -Q Message queue id: 3 # ipcrm -q 1 # ipcs -q
------ Message Queues -------- key msqid owner perms used-bytes messages 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0
Whenever an IPC item with a low id is deleted, the items with higher ids are duplicated, as if filling a hole.
new_pos should jump through hole of unused ids, pos can be updated inside "for" cycle.
Fixes: 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position index") Reported-by: Andreas Schwab schwab@suse.de Reported-by: Randy Dunlap rdunlap@infradead.org Signed-off-by: Vasily Averin vvs@virtuozzo.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Acked-by: Waiman Long longman@redhat.com Cc: NeilBrown neilb@suse.com Cc: Steven Rostedt rostedt@goodmis.org Cc: Ingo Molnar mingo@redhat.com Cc: Peter Oberparleiter oberpar@linux.ibm.com Cc: Davidlohr Bueso dave@stgolabs.net Cc: Manfred Spraul manfred@colorfullife.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/4921fe9b-9385-a2b4-1dc4-1099be6d2e39@virtuozzo.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- ipc/util.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c index b111e792b3125..af1b572effb14 100644 --- a/ipc/util.c +++ b/ipc/util.c @@ -735,21 +735,21 @@ static struct kern_ipc_perm *sysvipc_find_ipc(struct ipc_ids *ids, loff_t pos, total++; }
- *new_pos = pos + 1; + ipc = NULL; if (total >= ids->in_use) - return NULL; + goto out;
for (; pos < IPCMNI; pos++) { ipc = idr_find(&ids->ipcs_idr, pos); if (ipc != NULL) { rcu_read_lock(); ipc_lock_object(ipc); - return ipc; + break; } } - - /* Out of range - return NULL to terminate iteration */ - return NULL; +out: + *new_pos = pos + 1; + return ipc; }
static void *sysvipc_proc_next(struct seq_file *s, void *it, loff_t *pos)
From: Kai-Heng Feng kai.heng.feng@canonical.com
[ Upstream commit 52e4e36807aeac1cdd07b14e509c8a64101e1a09 ]
Commit 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0") makes the ALC225 have pop noise on S3 resume and cold boot.
The previous fix enable power save node universally for ALC225, however it makes some ALC225 systems unable to produce any sound.
So let's only enable power save node for the affected Dell Wyse platform.
Fixes: 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0") BugLink: https://bugs.launchpad.net/bugs/1866357 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com Link: https://lore.kernel.org/r/20200503152449.22761-2-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org --- sound/pci/hda/patch_realtek.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index fc39550f6c5d5..cf2889f3da41f 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5524,6 +5524,15 @@ static void alc233_alc662_fixup_lenovo_dual_codecs(struct hda_codec *codec, } }
+static void alc225_fixup_s3_pop_noise(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + if (action != HDA_FIXUP_ACT_PRE_PROBE) + return; + + codec->power_save_node = 1; +} + /* Forcibly assign NID 0x03 to HP/LO while NID 0x02 to SPK for EQ */ static void alc274_fixup_bind_dacs(struct hda_codec *codec, const struct hda_fixup *fix, int action) @@ -5690,6 +5699,7 @@ enum { ALC233_FIXUP_ACER_HEADSET_MIC, ALC294_FIXUP_LENOVO_MIC_LOCATION, ALC225_FIXUP_DELL_WYSE_MIC_NO_PRESENCE, + ALC225_FIXUP_S3_POP_NOISE, ALC700_FIXUP_INTEL_REFERENCE, ALC274_FIXUP_DELL_BIND_DACS, ALC274_FIXUP_DELL_AIO_LINEOUT_VERB, @@ -6546,6 +6556,12 @@ static const struct hda_fixup alc269_fixups[] = { { } }, .chained = true, + .chain_id = ALC225_FIXUP_S3_POP_NOISE + }, + [ALC225_FIXUP_S3_POP_NOISE] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc225_fixup_s3_pop_noise, + .chained = true, .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC }, [ALC700_FIXUP_INTEL_REFERENCE] = {
From: Andreas Gruenbacher agruenba@redhat.com
[ Upstream commit 566a2ab3c9005f62e784bd39022d58d34ef4365c ]
Make sure we don't walk past the end of the metadata in gfs2_walk_metadata: the inode holds fewer pointers than indirect blocks.
Slightly clean up gfs2_iomap_get.
Fixes: a27a0c9b6a20 ("gfs2: gfs2_walk_metadata fix") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Andreas Gruenbacher agruenba@redhat.com Signed-off-by: Bob Peterson rpeterso@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/gfs2/bmap.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c index 096b479721395..43f53020553b5 100644 --- a/fs/gfs2/bmap.c +++ b/fs/gfs2/bmap.c @@ -530,10 +530,12 @@ static int gfs2_walk_metadata(struct inode *inode, struct metapath *mp,
/* Advance in metadata tree. */ (mp->mp_list[hgt])++; - if (mp->mp_list[hgt] >= sdp->sd_inptrs) { - if (!hgt) + if (hgt) { + if (mp->mp_list[hgt] >= sdp->sd_inptrs) + goto lower_metapath; + } else { + if (mp->mp_list[hgt] >= sdp->sd_diptrs) break; - goto lower_metapath; }
fill_up_metapath: @@ -879,10 +881,9 @@ static int gfs2_iomap_get(struct inode *inode, loff_t pos, loff_t length, ret = -ENOENT; goto unlock; } else { - /* report a hole */ iomap->offset = pos; iomap->length = length; - goto do_alloc; + goto hole_found; } } iomap->length = size; @@ -936,8 +937,6 @@ static int gfs2_iomap_get(struct inode *inode, loff_t pos, loff_t length, return ret;
do_alloc: - iomap->addr = IOMAP_NULL_ADDR; - iomap->type = IOMAP_HOLE; if (flags & IOMAP_REPORT) { if (pos >= size) ret = -ENOENT; @@ -959,6 +958,9 @@ static int gfs2_iomap_get(struct inode *inode, loff_t pos, loff_t length, if (pos < size && height == ip->i_height) ret = gfs2_hole_size(inode, lblock, len, mp, iomap); } +hole_found: + iomap->addr = IOMAP_NULL_ADDR; + iomap->type = IOMAP_HOLE; goto out; }
From: Andy Shevchenko andriy.shevchenko@linux.intel.com
[ Upstream commit ccd025eaddaeb99e982029446197c544252108e2 ]
It appears that pin configuration for GPIO chip hasn't been enabled yet due to absence of ->set_config() callback.
Enable it here for Intel Baytrail.
Fixes: c501d0b149de ("pinctrl: baytrail: Add pin control operations") Depends-on: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Acked-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/pinctrl/intel/pinctrl-baytrail.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c index a760d8bda0af7..acb02a7aa9496 100644 --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -1495,6 +1495,7 @@ static const struct gpio_chip byt_gpio_chip = { .direction_output = byt_gpio_direction_output, .get = byt_gpio_get, .set = byt_gpio_set, + .set_config = gpiochip_generic_config, .dbg_show = byt_gpio_dbg_show, };
From: Grace Kao grace.kao@intel.com
[ Upstream commit 69388e15f5078c961b9e5319e22baea4c57deff1 ]
According to Braswell NDA Specification Update (#557593), concurrent read accesses may result in returning 0xffffffff and write instructions may be dropped. We have an established format for the commit references, i.e. cdca06e4e859 ("pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler")
Fixes: 0bd50d719b00 ("pinctrl: cherryview: prevent concurrent access to GPIO controllers") Signed-off-by: Grace Kao grace.kao@intel.com Reported-by: Brian Norris briannorris@chromium.org Reviewed-by: Brian Norris briannorris@chromium.org Acked-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c index f16baf9b86962..25932d2a71547 100644 --- a/drivers/pinctrl/intel/pinctrl-cherryview.c +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c @@ -1485,11 +1485,15 @@ static void chv_gpio_irq_handler(struct irq_desc *desc) struct chv_pinctrl *pctrl = gpiochip_get_data(gc); struct irq_chip *chip = irq_desc_get_chip(desc); unsigned long pending; + unsigned long flags; u32 intr_line;
chained_irq_enter(chip, desc);
+ raw_spin_lock_irqsave(&chv_lock, flags); pending = readl(pctrl->regs + CHV_INTSTAT); + raw_spin_unlock_irqrestore(&chv_lock, flags); + for_each_set_bit(intr_line, &pending, pctrl->community->nirqs) { unsigned irq, offset;
From: Dan Carpenter dan.carpenter@oracle.com
[ Upstream commit 37e31d2d26a4124506c24e95434e9baf3405a23a ]
The i40iw_arp_table() function can return -EOVERFLOW if i40iw_alloc_resource() fails so we can't just test for "== -1".
Fixes: 4e9042e647ff ("i40iw: add hw and utils files") Link: https://lore.kernel.org/r/20200422092211.GA195357@mwanda Signed-off-by: Dan Carpenter dan.carpenter@oracle.com Acked-by: Shiraz Saleem shiraz.saleem@intel.com Signed-off-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/infiniband/hw/i40iw/i40iw_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_hw.c b/drivers/infiniband/hw/i40iw/i40iw_hw.c index 55a1fbf0e670c..ae8b97c306657 100644 --- a/drivers/infiniband/hw/i40iw/i40iw_hw.c +++ b/drivers/infiniband/hw/i40iw/i40iw_hw.c @@ -534,7 +534,7 @@ void i40iw_manage_arp_cache(struct i40iw_device *iwdev, int arp_index;
arp_index = i40iw_arp_table(iwdev, ip_addr, ipv4, mac_addr, action); - if (arp_index == -1) + if (arp_index < 0) return; cqp_request = i40iw_get_cqp_request(&iwdev->cqp, false); if (!cqp_request)
From: Veerabhadrarao Badiganti vbadigan@codeaurora.org
[ Upstream commit e6bfb1bf00852b55f4c771f47ae67004c04d3c87 ]
In the request completion path with CQE, request type is being checked after the request is getting completed. This is resulting in returning the wrong request type and leading to the IO hang issue.
ASYNC request type is getting returned for DCMD type requests. Because of this mismatch, mq->cqe_busy flag is never getting cleared and the driver is not invoking blk_mq_hw_run_queue. So requests are not getting dispatched to the LLD from the block layer.
All these eventually leading to IO hang issues. So, get the request type before completing the request.
Cc: stable@vger.kernel.org Fixes: 1e8e55b67030 ("mmc: block: Add CQE support") Signed-off-by: Veerabhadrarao Badiganti vbadigan@codeaurora.org Acked-by: Adrian Hunter adrian.hunter@intel.com Link: https://lore.kernel.org/r/1588775643-18037-2-git-send-email-vbadigan@codeaur... Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/mmc/core/block.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 60eac66dc9f0b..23bcdbba0cab9 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -1424,6 +1424,7 @@ static void mmc_blk_cqe_complete_rq(struct mmc_queue *mq, struct request *req) struct mmc_request *mrq = &mqrq->brq.mrq; struct request_queue *q = req->q; struct mmc_host *host = mq->card->host; + enum mmc_issue_type issue_type = mmc_issue_type(mq, req); unsigned long flags; bool put_card; int err; @@ -1453,7 +1454,7 @@ static void mmc_blk_cqe_complete_rq(struct mmc_queue *mq, struct request *req)
spin_lock_irqsave(q->queue_lock, flags);
- mq->in_flight[mmc_issue_type(mq, req)] -= 1; + mq->in_flight[issue_type] -= 1;
put_card = (mmc_tot_in_flight(mq) == 0);
From: Adrian Hunter adrian.hunter@intel.com
[ Upstream commit c077dc5e0620508a29497dac63a2822324ece52a ]
First, it should be noted that the CQE timeout (60 seconds) is substantial so a CQE request that times out is really stuck, and the race between timeout and completion is extremely unlikely. Nevertheless this patch fixes an issue with it.
Commit ad73d6feadbd7b ("mmc: complete requests from ->timeout") preserved the existing functionality, to complete the request. However that had only been necessary because the block layer timeout handler had been marking the request to prevent it from being completed normally. That restriction was removed at the same time, the result being that a request that has gone will have been completed anyway. That is, the completion was unnecessary.
At the time, the unnecessary completion was harmless because the block layer would ignore it, although that changed in kernel v5.0.
Note for stable, this patch will not apply cleanly without patch "mmc: core: Fix recursive locking issue in CQE recovery path"
Signed-off-by: Adrian Hunter adrian.hunter@intel.com Fixes: ad73d6feadbd7b ("mmc: complete requests from ->timeout") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200508062227.23144-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/mmc/core/queue.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c index becc6594a8a47..03f3d9c80fbac 100644 --- a/drivers/mmc/core/queue.c +++ b/drivers/mmc/core/queue.c @@ -111,8 +111,7 @@ static enum blk_eh_timer_return mmc_cqe_timed_out(struct request *req) __mmc_cqe_recovery_notifier(mq); return BLK_EH_RESET_TIMER; } - /* No timeout (XXX: huh? comment doesn't make much sense) */ - blk_mq_complete_request(req); + /* The request has gone already */ return BLK_EH_DONE; default: /* Timeout is handled by mmc core */
From: Dave Wysochanski dwysocha@redhat.com
[ Upstream commit d9bfced1fbcb35b28d8fbed4e785d2807055ed2b ]
Commit 402cb8dda949 ("fscache: Attach the index key and aux data to the cookie") added the index_key and index_key_len parameters to fscache_acquire_cookie(), and updated the callers in the NFS client. One of the callers was inside nfs_fscache_get_super_cookie() and was changed to use the full struct nfs_fscache_key as the index_key. However, a couple members of this structure contain pointers and thus will change each time the same NFS share is remounted. Since index_key is used for fscache_cookie->key_hash and this subsequently is used to compare cookies, the effectiveness of fscache with NFS is reduced to the point at which a umount occurs. Any subsequent remount of the same share will cause a unique NFS super_block index_key and key_hash to be generated for the same data, rendering any prior fscache data unable to be found. A simple reproducer demonstrates the problem.
1. Mount share with 'fsc', create a file, drop page cache systemctl start cachefilesd mount -o vers=3,fsc 127.0.0.1:/export /mnt dd if=/dev/zero of=/mnt/file1.bin bs=4096 count=1 echo 3 > /proc/sys/vm/drop_caches
2. Read file into page cache and fscache, then unmount dd if=/mnt/file1.bin of=/dev/null bs=4096 count=1 umount /mnt
3. Remount and re-read which should come from fscache mount -o vers=3,fsc 127.0.0.1:/export /mnt echo 3 > /proc/sys/vm/drop_caches dd if=/mnt/file1.bin of=/dev/null bs=4096 count=1
4. Check for READ ops in mountstats - there should be none grep READ: /proc/self/mountstats
Looking at the history and the removed function, nfs_super_get_key(), we should only use nfs_fscache_key.key plus any uniquifier, for the fscache index_key.
Fixes: 402cb8dda949 ("fscache: Attach the index key and aux data to the cookie") Signed-off-by: Dave Wysochanski dwysocha@redhat.com Signed-off-by: David Howells dhowells@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/nfs/fscache.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c index 6f45b1a957397..b931169c2bb24 100644 --- a/fs/nfs/fscache.c +++ b/fs/nfs/fscache.c @@ -192,7 +192,8 @@ void nfs_fscache_get_super_cookie(struct super_block *sb, const char *uniq, int /* create a cache index for looking up filehandles */ nfss->fscache = fscache_acquire_cookie(nfss->nfs_client->fscache, &nfs_fscache_super_index_def, - key, sizeof(*key) + ulen, + &key->key, + sizeof(key->key) + ulen, NULL, 0, nfss, 0, true); dfprintk(FSCACHE, "NFS: get superblock cookie (0x%p/0x%p)\n",
From: Arnd Bergmann arnd@arndb.de
[ Upstream commit 6e31ded6895adfca97211118cc9b72236e8f6d53 ]
nfs currently behaves differently on 32-bit and 64-bit kernels regarding the on-disk format of nfs_fscache_inode_auxdata.
That format should really be the same on any kernel, and we should avoid the 'timespec' type in order to remove that from the kernel later on.
Using plain 'timespec64' would not be good here, since that includes implied padding and would possibly leak kernel stack data to the on-disk format on 32-bit architectures.
struct __kernel_timespec would work as a replacement, but open-coding the two struct members in nfs_fscache_inode_auxdata makes it more obvious what's going on here, and keeps the current format for 64-bit architectures.
Cc: David Howells dhowells@redhat.com Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sasha Levin sashal@kernel.org --- fs/nfs/fscache-index.c | 6 ++++-- fs/nfs/fscache.c | 18 ++++++++++++------ fs/nfs/fscache.h | 8 +++++--- 3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/fs/nfs/fscache-index.c b/fs/nfs/fscache-index.c index 666415d13d521..b7ca0b85b1fe2 100644 --- a/fs/nfs/fscache-index.c +++ b/fs/nfs/fscache-index.c @@ -88,8 +88,10 @@ enum fscache_checkaux nfs_fscache_inode_check_aux(void *cookie_netfs_data, return FSCACHE_CHECKAUX_OBSOLETE;
memset(&auxdata, 0, sizeof(auxdata)); - auxdata.mtime = timespec64_to_timespec(nfsi->vfs_inode.i_mtime); - auxdata.ctime = timespec64_to_timespec(nfsi->vfs_inode.i_ctime); + auxdata.mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; + auxdata.mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; + auxdata.ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; + auxdata.ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec;
if (NFS_SERVER(&nfsi->vfs_inode)->nfs_client->rpc_ops->version == 4) auxdata.change_attr = inode_peek_iversion_raw(&nfsi->vfs_inode); diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c index b931169c2bb24..0a4d6b35545a3 100644 --- a/fs/nfs/fscache.c +++ b/fs/nfs/fscache.c @@ -245,8 +245,10 @@ void nfs_fscache_init_inode(struct inode *inode) return;
memset(&auxdata, 0, sizeof(auxdata)); - auxdata.mtime = timespec64_to_timespec(nfsi->vfs_inode.i_mtime); - auxdata.ctime = timespec64_to_timespec(nfsi->vfs_inode.i_ctime); + auxdata.mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; + auxdata.mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; + auxdata.ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; + auxdata.ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec;
if (NFS_SERVER(&nfsi->vfs_inode)->nfs_client->rpc_ops->version == 4) auxdata.change_attr = inode_peek_iversion_raw(&nfsi->vfs_inode); @@ -270,8 +272,10 @@ void nfs_fscache_clear_inode(struct inode *inode) dfprintk(FSCACHE, "NFS: clear cookie (0x%p/0x%p)\n", nfsi, cookie);
memset(&auxdata, 0, sizeof(auxdata)); - auxdata.mtime = timespec64_to_timespec(nfsi->vfs_inode.i_mtime); - auxdata.ctime = timespec64_to_timespec(nfsi->vfs_inode.i_ctime); + auxdata.mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; + auxdata.mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; + auxdata.ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; + auxdata.ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec; fscache_relinquish_cookie(cookie, &auxdata, false); nfsi->fscache = NULL; } @@ -312,8 +316,10 @@ void nfs_fscache_open_file(struct inode *inode, struct file *filp) return;
memset(&auxdata, 0, sizeof(auxdata)); - auxdata.mtime = timespec64_to_timespec(nfsi->vfs_inode.i_mtime); - auxdata.ctime = timespec64_to_timespec(nfsi->vfs_inode.i_ctime); + auxdata.mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; + auxdata.mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; + auxdata.ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; + auxdata.ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec;
if (inode_is_open_for_write(inode)) { dfprintk(FSCACHE, "NFS: nfsi 0x%p disabling cache\n", nfsi); diff --git a/fs/nfs/fscache.h b/fs/nfs/fscache.h index 6363ea9568581..89d2f956668f2 100644 --- a/fs/nfs/fscache.h +++ b/fs/nfs/fscache.h @@ -66,9 +66,11 @@ struct nfs_fscache_key { * cache object. */ struct nfs_fscache_inode_auxdata { - struct timespec mtime; - struct timespec ctime; - u64 change_attr; + s64 mtime_sec; + s64 mtime_nsec; + s64 ctime_sec; + s64 ctime_nsec; + u64 change_attr; };
/*
From: Dave Wysochanski dwysocha@redhat.com
[ Upstream commit 50eaa652b54df1e2b48dc398d9e6114c9ed080eb ]
Commit 402cb8dda949 ("fscache: Attach the index key and aux data to the cookie") added the aux_data and aux_data_len to parameters to fscache_acquire_cookie(), and updated the callers in the NFS client. In the process it modified the aux_data to include the change_attr, but missed adding change_attr to a couple places where aux_data was used. Specifically, when opening a file and the change_attr is not added, the following attempt to lookup an object will fail inside cachefiles_check_object_xattr() = -116 due to nfs_fscache_inode_check_aux() failing memcmp on auxdata and returning FSCACHE_CHECKAUX_OBSOLETE.
Fix this by adding nfs_fscache_update_auxdata() to set the auxdata from all relevant fields in the inode, including the change_attr.
Fixes: 402cb8dda949 ("fscache: Attach the index key and aux data to the cookie") Signed-off-by: Dave Wysochanski dwysocha@redhat.com Signed-off-by: David Howells dhowells@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/nfs/fscache.c | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c index 0a4d6b35545a3..7dfa45a380882 100644 --- a/fs/nfs/fscache.c +++ b/fs/nfs/fscache.c @@ -231,6 +231,19 @@ void nfs_fscache_release_super_cookie(struct super_block *sb) } }
+static void nfs_fscache_update_auxdata(struct nfs_fscache_inode_auxdata *auxdata, + struct nfs_inode *nfsi) +{ + memset(auxdata, 0, sizeof(*auxdata)); + auxdata->mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; + auxdata->mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; + auxdata->ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; + auxdata->ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec; + + if (NFS_SERVER(&nfsi->vfs_inode)->nfs_client->rpc_ops->version == 4) + auxdata->change_attr = inode_peek_iversion_raw(&nfsi->vfs_inode); +} + /* * Initialise the per-inode cache cookie pointer for an NFS inode. */ @@ -244,14 +257,7 @@ void nfs_fscache_init_inode(struct inode *inode) if (!(nfss->fscache && S_ISREG(inode->i_mode))) return;
- memset(&auxdata, 0, sizeof(auxdata)); - auxdata.mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; - auxdata.mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; - auxdata.ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; - auxdata.ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec; - - if (NFS_SERVER(&nfsi->vfs_inode)->nfs_client->rpc_ops->version == 4) - auxdata.change_attr = inode_peek_iversion_raw(&nfsi->vfs_inode); + nfs_fscache_update_auxdata(&auxdata, nfsi);
nfsi->fscache = fscache_acquire_cookie(NFS_SB(inode->i_sb)->fscache, &nfs_fscache_inode_object_def, @@ -271,11 +277,7 @@ void nfs_fscache_clear_inode(struct inode *inode)
dfprintk(FSCACHE, "NFS: clear cookie (0x%p/0x%p)\n", nfsi, cookie);
- memset(&auxdata, 0, sizeof(auxdata)); - auxdata.mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; - auxdata.mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; - auxdata.ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; - auxdata.ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec; + nfs_fscache_update_auxdata(&auxdata, nfsi); fscache_relinquish_cookie(cookie, &auxdata, false); nfsi->fscache = NULL; } @@ -315,11 +317,7 @@ void nfs_fscache_open_file(struct inode *inode, struct file *filp) if (!fscache_cookie_valid(cookie)) return;
- memset(&auxdata, 0, sizeof(auxdata)); - auxdata.mtime_sec = nfsi->vfs_inode.i_mtime.tv_sec; - auxdata.mtime_nsec = nfsi->vfs_inode.i_mtime.tv_nsec; - auxdata.ctime_sec = nfsi->vfs_inode.i_ctime.tv_sec; - auxdata.ctime_nsec = nfsi->vfs_inode.i_ctime.tv_nsec; + nfs_fscache_update_auxdata(&auxdata, nfsi);
if (inode_is_open_for_write(inode)) { dfprintk(FSCACHE, "NFS: nfsi 0x%p disabling cache\n", nfsi);
From: Arnd Bergmann arnd@arndb.de
[ Upstream commit 2c407aca64977ede9b9f35158e919773cae2082f ]
gcc-10 warns around a suspicious access to an empty struct member:
net/netfilter/nf_conntrack_core.c: In function '__nf_conntrack_alloc': net/netfilter/nf_conntrack_core.c:1522:9: warning: array subscript 0 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds] 1522 | memset(&ct->__nfct_init_offset[0], 0, | ^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from net/netfilter/nf_conntrack_core.c:37: include/net/netfilter/nf_conntrack.h:90:5: note: while referencing '__nfct_init_offset' 90 | u8 __nfct_init_offset[0]; | ^~~~~~~~~~~~~~~~~~
The code is correct but a bit unusual. Rework it slightly in a way that does not trigger the warning, using an empty struct instead of an empty array. There are probably more elegant ways to do this, but this is the smallest change.
Fixes: c41884ce0562 ("netfilter: conntrack: avoid zeroing timer") Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Pablo Neira Ayuso pablo@netfilter.org Signed-off-by: Sasha Levin sashal@kernel.org --- include/net/netfilter/nf_conntrack.h | 2 +- net/netfilter/nf_conntrack_core.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index f45141bdbb837..ac4d70aeee129 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -85,7 +85,7 @@ struct nf_conn { struct hlist_node nat_bysource; #endif /* all members below initialized via memset */ - u8 __nfct_init_offset[0]; + struct { } __nfct_init_offset;
/* If we were expected by an expectation, this will be it */ struct nf_conn *master; diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index c6073d17c3244..ad1da6b2fb607 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -1352,9 +1352,9 @@ __nf_conntrack_alloc(struct net *net, *(unsigned long *)(&ct->tuplehash[IP_CT_DIR_REPLY].hnnode.pprev) = hash; ct->status = 0; write_pnet(&ct->ct_net, net); - memset(&ct->__nfct_init_offset[0], 0, + memset(&ct->__nfct_init_offset, 0, offsetof(struct nf_conn, proto) - - offsetof(struct nf_conn, __nfct_init_offset[0])); + offsetof(struct nf_conn, __nfct_init_offset));
nf_ct_zone_add(ct, zone);
From: Christoph Hellwig hch@lst.de
[ Upstream commit d51c214541c5154dda3037289ee895ea3ded5ebd ]
The second argument is the end "pointer", not the length.
Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support") Cc: stable@vger.kernel.org # 4.8.x- Signed-off-by: Christoph Hellwig hch@lst.de Signed-off-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm64/kernel/machine_kexec.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c index 922add8adb749..5e26ef0078638 100644 --- a/arch/arm64/kernel/machine_kexec.c +++ b/arch/arm64/kernel/machine_kexec.c @@ -192,6 +192,7 @@ void machine_kexec(struct kimage *kimage) * the offline CPUs. Therefore, we must use the __* variant here. */ __flush_icache_range((uintptr_t)reboot_code_buffer, + (uintptr_t)reboot_code_buffer + arm64_relocate_new_kernel_size);
/* Flush the kimage list and its buffers. */
From: Stefano Brivio sbrivio@redhat.com
[ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
Replace negations of nft_rbtree_interval_end() with a new helper, nft_rbtree_interval_start(), wherever this helps to visualise the problem at hand, that is, for all the occurrences except for the comparison against given flags in __nft_rbtree_get().
This gets especially useful in the next patch.
Signed-off-by: Stefano Brivio sbrivio@redhat.com Signed-off-by: Pablo Neira Ayuso pablo@netfilter.org Signed-off-by: Sasha Levin sashal@kernel.org --- net/netfilter/nft_set_rbtree.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c index 0221510328d4f..84d317418d184 100644 --- a/net/netfilter/nft_set_rbtree.c +++ b/net/netfilter/nft_set_rbtree.c @@ -36,6 +36,11 @@ static bool nft_rbtree_interval_end(const struct nft_rbtree_elem *rbe) (*nft_set_ext_flags(&rbe->ext) & NFT_SET_ELEM_INTERVAL_END); }
+static bool nft_rbtree_interval_start(const struct nft_rbtree_elem *rbe) +{ + return !nft_rbtree_interval_end(rbe); +} + static bool nft_rbtree_equal(const struct nft_set *set, const void *this, const struct nft_rbtree_elem *interval) { @@ -67,7 +72,7 @@ static bool __nft_rbtree_lookup(const struct net *net, const struct nft_set *set if (interval && nft_rbtree_equal(set, this, interval) && nft_rbtree_interval_end(rbe) && - !nft_rbtree_interval_end(interval)) + nft_rbtree_interval_start(interval)) continue; interval = rbe; } else if (d > 0) @@ -92,7 +97,7 @@ static bool __nft_rbtree_lookup(const struct net *net, const struct nft_set *set
if (set->flags & NFT_SET_INTERVAL && interval != NULL && nft_set_elem_active(&interval->ext, genmask) && - !nft_rbtree_interval_end(interval)) { + nft_rbtree_interval_start(interval)) { *ext = &interval->ext; return true; } @@ -221,9 +226,9 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set, p = &parent->rb_right; else { if (nft_rbtree_interval_end(rbe) && - !nft_rbtree_interval_end(new)) { + nft_rbtree_interval_start(new)) { p = &parent->rb_left; - } else if (!nft_rbtree_interval_end(rbe) && + } else if (nft_rbtree_interval_start(rbe) && nft_rbtree_interval_end(new)) { p = &parent->rb_right; } else if (nft_set_elem_active(&rbe->ext, genmask)) { @@ -314,10 +319,10 @@ static void *nft_rbtree_deactivate(const struct net *net, parent = parent->rb_right; else { if (nft_rbtree_interval_end(rbe) && - !nft_rbtree_interval_end(this)) { + nft_rbtree_interval_start(this)) { parent = parent->rb_left; continue; - } else if (!nft_rbtree_interval_end(rbe) && + } else if (nft_rbtree_interval_start(rbe) && nft_rbtree_interval_end(this)) { parent = parent->rb_right; continue;
Hi!
[ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
Replace negations of nft_rbtree_interval_end() with a new helper, nft_rbtree_interval_start(), wherever this helps to visualise the problem at hand, that is, for all the occurrences except for the comparison against given flags in __nft_rbtree_get().
This gets especially useful in the next patch.
This looks like cleanup in preparation for the next patch. Next patch is there for some series, but not for 4.19.124. Should this be in 4.19, then?
Best regards, Pavel
On Tue, May 19, 2020 at 02:06:25PM +0200, Pavel Machek wrote:
Hi!
[ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
Replace negations of nft_rbtree_interval_end() with a new helper, nft_rbtree_interval_start(), wherever this helps to visualise the problem at hand, that is, for all the occurrences except for the comparison against given flags in __nft_rbtree_get().
This gets especially useful in the next patch.
This looks like cleanup in preparation for the next patch. Next patch is there for some series, but not for 4.19.124. Should this be in 4.19, then?
What is the "next patch" in this situation?
thanks,
greg k-h
On Tue 2020-05-19 14:13:56, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 02:06:25PM +0200, Pavel Machek wrote:
Hi!
[ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
Replace negations of nft_rbtree_interval_end() with a new helper, nft_rbtree_interval_start(), wherever this helps to visualise the problem at hand, that is, for all the occurrences except for the comparison against given flags in __nft_rbtree_get().
This gets especially useful in the next patch.
This looks like cleanup in preparation for the next patch. Next patch is there for some series, but not for 4.19.124. Should this be in 4.19, then?
What is the "next patch" in this situation?
In 5.4 you have:
9956 O Greg Kroah ├─>[PATCH 5.4 082/147] netfilter: nft_set_rbtree: Introduce and use nft 9957 Greg Kroah ├─>[PATCH 5.4 083/147] netfilter: nft_set_rbtree: Add missing expired c
In 4.19 you have:
10373 r Greg Kroah ├─>[PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft 10376 O Greg Kroah ├─>[PATCH 4.19 42/80] IB/mlx4: Test return value of calls to ib_get_ca
I believe 41/80 can be dropped from 4.19 series, as it is just a preparation for 083/147... which is not queued for 4.19.
Best regards, Pavel
On Tue, May 19, 2020 at 02:19:07PM +0200, Pavel Machek wrote:
On Tue 2020-05-19 14:13:56, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 02:06:25PM +0200, Pavel Machek wrote:
Hi!
[ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
Replace negations of nft_rbtree_interval_end() with a new helper, nft_rbtree_interval_start(), wherever this helps to visualise the problem at hand, that is, for all the occurrences except for the comparison against given flags in __nft_rbtree_get().
This gets especially useful in the next patch.
This looks like cleanup in preparation for the next patch. Next patch is there for some series, but not for 4.19.124. Should this be in 4.19, then?
What is the "next patch" in this situation?
In 5.4 you have:
9956 O Greg Kroah ├─>[PATCH 5.4 082/147] netfilter: nft_set_rbtree: Introduce and use nft 9957 Greg Kroah ├─>[PATCH 5.4 083/147] netfilter: nft_set_rbtree: Add missing expired c
In 4.19 you have:
10373 r Greg Kroah ├─>[PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft 10376 O Greg Kroah ├─>[PATCH 4.19 42/80] IB/mlx4: Test return value of calls to ib_get_ca
I believe 41/80 can be dropped from 4.19 series, as it is just a preparation for 083/147... which is not queued for 4.19.
I've queued it up for 4.19 now, thanks.
greg k-h
On Tue, 19 May 2020 14:51:13 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 19, 2020 at 02:19:07PM +0200, Pavel Machek wrote:
On Tue 2020-05-19 14:13:56, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 02:06:25PM +0200, Pavel Machek wrote:
Hi!
[ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
Replace negations of nft_rbtree_interval_end() with a new helper, nft_rbtree_interval_start(), wherever this helps to visualise the problem at hand, that is, for all the occurrences except for the comparison against given flags in __nft_rbtree_get().
This gets especially useful in the next patch.
This looks like cleanup in preparation for the next patch. Next patch is there for some series, but not for 4.19.124. Should this be in 4.19, then?
What is the "next patch" in this situation?
In 5.4 you have:
9956 O Greg Kroah ├─>[PATCH 5.4 082/147] netfilter: nft_set_rbtree: Introduce and use nft 9957 Greg Kroah ├─>[PATCH 5.4 083/147] netfilter: nft_set_rbtree: Add missing expired c
In 4.19 you have:
10373 r Greg Kroah ├─>[PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft 10376 O Greg Kroah ├─>[PATCH 4.19 42/80] IB/mlx4: Test return value of calls to ib_get_ca
I believe 41/80 can be dropped from 4.19 series, as it is just a preparation for 083/147... which is not queued for 4.19.
I've queued it up for 4.19 now, thanks.
Wait, wait, sorry. I thought you were queuing this up as a missing dependency or something, but I see it's not the case. That patch is *not* the preparation for:
340eaff65116 netfilter: nft_set_rbtree: Add missing expired checks
...but rather preparation for:
7c84d41416d8 netfilter: nft_set_rbtree: Detect partial overlaps on insertion
whose fix-up:
72239f2795fa netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion
was queued for 5.6.x (see 20200421131431.GA793882@kroah.com).
Now, if you want to backport "Add missing expired checks", it *might* be more convenient to also backport:
6f7c9caf017b netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()
and, perhaps (I haven't tried to actually cherry-pick) also:
7c84d41416d8 netfilter: nft_set_rbtree: Detect partial overlaps on insertion 72239f2795fa netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion
and it's safe to either:
- backport only 6f7c9caf017b - backport the three of them
but other than avoiding conflicts, there should be no reason to do that. Sasha had already queued them up for 4.19 and 5.4, then dropped them as they weren't needed, see 20200413163900.GO27528@sasha-vm.
On Tue, May 19, 2020 at 03:53:00PM +0200, Stefano Brivio wrote:
On Tue, 19 May 2020 14:51:13 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 19, 2020 at 02:19:07PM +0200, Pavel Machek wrote:
On Tue 2020-05-19 14:13:56, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 02:06:25PM +0200, Pavel Machek wrote:
Hi!
[ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
Replace negations of nft_rbtree_interval_end() with a new helper, nft_rbtree_interval_start(), wherever this helps to visualise the problem at hand, that is, for all the occurrences except for the comparison against given flags in __nft_rbtree_get().
This gets especially useful in the next patch.
This looks like cleanup in preparation for the next patch. Next patch is there for some series, but not for 4.19.124. Should this be in 4.19, then?
What is the "next patch" in this situation?
In 5.4 you have:
9956 O Greg Kroah ├─>[PATCH 5.4 082/147] netfilter: nft_set_rbtree: Introduce and use nft 9957 Greg Kroah ├─>[PATCH 5.4 083/147] netfilter: nft_set_rbtree: Add missing expired c
In 4.19 you have:
10373 r Greg Kroah ├─>[PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft 10376 O Greg Kroah ├─>[PATCH 4.19 42/80] IB/mlx4: Test return value of calls to ib_get_ca
I believe 41/80 can be dropped from 4.19 series, as it is just a preparation for 083/147... which is not queued for 4.19.
I've queued it up for 4.19 now, thanks.
Wait, wait, sorry. I thought you were queuing this up as a missing dependency or something, but I see it's not the case. That patch is *not* the preparation for:
340eaff65116 netfilter: nft_set_rbtree: Add missing expired checks
...but rather preparation for:
7c84d41416d8 netfilter: nft_set_rbtree: Detect partial overlaps on insertion
whose fix-up:
72239f2795fa netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion
was queued for 5.6.x (see 20200421131431.GA793882@kroah.com).
Now, if you want to backport "Add missing expired checks", it *might* be more convenient to also backport:
6f7c9caf017b netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()
and, perhaps (I haven't tried to actually cherry-pick) also:
7c84d41416d8 netfilter: nft_set_rbtree: Detect partial overlaps on insertion 72239f2795fa netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion
and it's safe to either:
- backport only 6f7c9caf017b
- backport the three of them
but other than avoiding conflicts, there should be no reason to do that. Sasha had already queued them up for 4.19 and 5.4, then dropped them as they weren't needed, see 20200413163900.GO27528@sasha-vm.
Ok, I'll go drop the patch I just added, thanks for clearing this up.
greg k-h
From: Jack Morgenstein jackm@dev.mellanox.co.il
[ Upstream commit 6693ca95bd4330a0ad7326967e1f9bcedd6b0800 ]
In the mlx4_ib_post_send() flow, some functions call ib_get_cached_pkey() without checking its return value. If ib_get_cached_pkey() returns an error code, these functions should return failure.
Fixes: 1ffeb2eb8be9 ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support") Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Fixes: e622f2f4ad21 ("IB: split struct ib_send_wr") Link: https://lore.kernel.org/r/20200426075921.130074-1-leon@kernel.org Signed-off-by: Jack Morgenstein jackm@dev.mellanox.co.il Signed-off-by: Leon Romanovsky leonro@mellanox.com Signed-off-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/infiniband/hw/mlx4/qp.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c index 6dd3cd2c2f80e..73bd35d34a257 100644 --- a/drivers/infiniband/hw/mlx4/qp.c +++ b/drivers/infiniband/hw/mlx4/qp.c @@ -2807,6 +2807,7 @@ static int build_sriov_qp0_header(struct mlx4_ib_sqp *sqp, int send_size; int header_size; int spc; + int err; int i;
if (wr->wr.opcode != IB_WR_SEND) @@ -2841,7 +2842,9 @@ static int build_sriov_qp0_header(struct mlx4_ib_sqp *sqp,
sqp->ud_header.lrh.virtual_lane = 0; sqp->ud_header.bth.solicited_event = !!(wr->wr.send_flags & IB_SEND_SOLICITED); - ib_get_cached_pkey(ib_dev, sqp->qp.port, 0, &pkey); + err = ib_get_cached_pkey(ib_dev, sqp->qp.port, 0, &pkey); + if (err) + return err; sqp->ud_header.bth.pkey = cpu_to_be16(pkey); if (sqp->qp.mlx4_ib_qp_type == MLX4_IB_QPT_TUN_SMI_OWNER) sqp->ud_header.bth.destination_qpn = cpu_to_be32(wr->remote_qpn); @@ -3128,9 +3131,14 @@ static int build_mlx_header(struct mlx4_ib_sqp *sqp, const struct ib_ud_wr *wr, } sqp->ud_header.bth.solicited_event = !!(wr->wr.send_flags & IB_SEND_SOLICITED); if (!sqp->qp.ibqp.qp_num) - ib_get_cached_pkey(ib_dev, sqp->qp.port, sqp->pkey_index, &pkey); + err = ib_get_cached_pkey(ib_dev, sqp->qp.port, sqp->pkey_index, + &pkey); else - ib_get_cached_pkey(ib_dev, sqp->qp.port, wr->pkey_index, &pkey); + err = ib_get_cached_pkey(ib_dev, sqp->qp.port, wr->pkey_index, + &pkey); + if (err) + return err; + sqp->ud_header.bth.pkey = cpu_to_be16(pkey); sqp->ud_header.bth.destination_qpn = cpu_to_be32(wr->remote_qpn); sqp->ud_header.bth.psn = cpu_to_be32((sqp->send_psn++) & ((1 << 24) - 1));
From: Samu Nuutamo samu.nuutamo@vincit.fi
[ Upstream commit 333e22db228f0bd0c839553015a6a8d3db4ba569 ]
When tsi-as-adc is configured it is possible for in7[0123]_input read to return an incorrect value if a concurrent read to in[456]_input is performed. This is caused by a concurrent manipulation of the mux channel without proper locking as hwmon and mfd use different locks for synchronization.
Switch hwmon to use the same lock as mfd when accessing the TSI channel.
Fixes: 4f16cab19a3d5 ("hwmon: da9052: Add support for TSI channel") Signed-off-by: Samu Nuutamo samu.nuutamo@vincit.fi [rebase to current master, reword commit message slightly] Signed-off-by: Sebastian Reichel sebastian.reichel@collabora.com Signed-off-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/hwmon/da9052-hwmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c index a973eb6a28908..9e44d2385e6f9 100644 --- a/drivers/hwmon/da9052-hwmon.c +++ b/drivers/hwmon/da9052-hwmon.c @@ -250,9 +250,9 @@ static ssize_t da9052_read_tsi(struct device *dev, int channel = to_sensor_dev_attr(devattr)->index; int ret;
- mutex_lock(&hwmon->hwmon_lock); + mutex_lock(&hwmon->da9052->auxadc_lock); ret = __da9052_read_tsi(dev, channel); - mutex_unlock(&hwmon->hwmon_lock); + mutex_unlock(&hwmon->da9052->auxadc_lock);
if (ret < 0) return ret;
From: Jason Gunthorpe jgg@mellanox.com
commit 01b2bafe57b19d9119413f138765ef57990921ce upstream.
Aside from good practice, this avoids a warning from gcc 10:
./include/linux/kernel.h:997:3: warning: array subscript -31 is outside array bounds of ‘struct list_head[1]’ [-Warray-bounds] 997 | ((type *)(__mptr - offsetof(type, member))); }) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/list.h:493:2: note: in expansion of macro ‘container_of’ 493 | container_of(ptr, type, member) | ^~~~~~~~~~~~ ./include/linux/pnp.h:275:30: note: in expansion of macro ‘list_entry’ 275 | #define global_to_pnp_dev(n) list_entry(n, struct pnp_dev, global_list) | ^~~~~~~~~~ ./include/linux/pnp.h:281:11: note: in expansion of macro ‘global_to_pnp_dev’ 281 | (dev) != global_to_pnp_dev(&pnp_global); \ | ^~~~~~~~~~~~~~~~~ arch/x86/kernel/rtc.c:189:2: note: in expansion of macro ‘pnp_for_each_dev’ 189 | pnp_for_each_dev(dev) {
Because the common code doesn't cast the starting list_head to the containing struct.
Signed-off-by: Jason Gunthorpe jgg@mellanox.com [ rjw: Whitespace adjustments ] Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- include/linux/pnp.h | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-)
--- a/include/linux/pnp.h +++ b/include/linux/pnp.h @@ -220,10 +220,8 @@ struct pnp_card { #define global_to_pnp_card(n) list_entry(n, struct pnp_card, global_list) #define protocol_to_pnp_card(n) list_entry(n, struct pnp_card, protocol_list) #define to_pnp_card(n) container_of(n, struct pnp_card, dev) -#define pnp_for_each_card(card) \ - for((card) = global_to_pnp_card(pnp_cards.next); \ - (card) != global_to_pnp_card(&pnp_cards); \ - (card) = global_to_pnp_card((card)->global_list.next)) +#define pnp_for_each_card(card) \ + list_for_each_entry(card, &pnp_cards, global_list)
struct pnp_card_link { struct pnp_card *card; @@ -276,14 +274,9 @@ struct pnp_dev { #define card_to_pnp_dev(n) list_entry(n, struct pnp_dev, card_list) #define protocol_to_pnp_dev(n) list_entry(n, struct pnp_dev, protocol_list) #define to_pnp_dev(n) container_of(n, struct pnp_dev, dev) -#define pnp_for_each_dev(dev) \ - for((dev) = global_to_pnp_dev(pnp_global.next); \ - (dev) != global_to_pnp_dev(&pnp_global); \ - (dev) = global_to_pnp_dev((dev)->global_list.next)) -#define card_for_each_dev(card,dev) \ - for((dev) = card_to_pnp_dev((card)->devices.next); \ - (dev) != card_to_pnp_dev(&(card)->devices); \ - (dev) = card_to_pnp_dev((dev)->card_list.next)) +#define pnp_for_each_dev(dev) list_for_each_entry(dev, &pnp_global, global_list) +#define card_for_each_dev(card, dev) \ + list_for_each_entry(dev, &(card)->devices, card_list) #define pnp_dev_name(dev) (dev)->name
static inline void *pnp_get_drvdata(struct pnp_dev *pdev) @@ -437,14 +430,10 @@ struct pnp_protocol { };
#define to_pnp_protocol(n) list_entry(n, struct pnp_protocol, protocol_list) -#define protocol_for_each_card(protocol,card) \ - for((card) = protocol_to_pnp_card((protocol)->cards.next); \ - (card) != protocol_to_pnp_card(&(protocol)->cards); \ - (card) = protocol_to_pnp_card((card)->protocol_list.next)) -#define protocol_for_each_dev(protocol,dev) \ - for((dev) = protocol_to_pnp_dev((protocol)->devices.next); \ - (dev) != protocol_to_pnp_dev(&(protocol)->devices); \ - (dev) = protocol_to_pnp_dev((dev)->protocol_list.next)) +#define protocol_for_each_card(protocol, card) \ + list_for_each_entry(card, &(protocol)->cards, protocol_list) +#define protocol_for_each_dev(protocol, dev) \ + list_for_each_entry(dev, &(protocol)->devices, protocol_list)
extern struct bus_type pnp_bus_type;
From: Linus Torvalds torvalds@linux-foundation.org
commit 9d82973e032e246ff5663c9805fbb5407ae932e3 upstream.
Due to a bug-report that was compiler-dependent, I updated one of my machines to gcc-10. That shows a lot of new warnings. Happily they seem to be mostly the valid kind, but it's going to cause a round of churn for getting rid of them..
This is the really low-hanging fruit of removing a couple of zero-sized arrays in some core code. We have had a round of these patches before, and we'll have many more coming, and there is nothing special about these except that they were particularly trivial, and triggered more warnings than most.
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- include/linux/fs.h | 2 +- include/linux/tty.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -934,7 +934,7 @@ struct file_handle { __u32 handle_bytes; int handle_type; /* file identifier */ - unsigned char f_handle[0]; + unsigned char f_handle[]; };
static inline struct file *get_file(struct file *f) --- a/include/linux/tty.h +++ b/include/linux/tty.h @@ -66,7 +66,7 @@ struct tty_buffer { int read; int flags; /* Data points here */ - unsigned long data[0]; + unsigned long data[]; };
/* Values for .flags field of tty_buffer */
From: Masahiro Yamada yamada.masahiro@socionext.com
commit b303c6df80c9f8f13785aa83a0471fca7e38b24d upstream.
Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched various false positives:
- commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building with -Os") turned off this option for -Os.
- commit 815eb71e7149 ("Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for CONFIG_PROFILE_ALL_BRANCHES
- commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"") turned off this option for GCC < 4.9 Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903
I think this looks better by shifting the logic from Makefile to Kconfig.
Link: https://github.com/ClangBuiltLinux/linux/issues/350 Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Nathan Chancellor natechancellor@gmail.com Tested-by: Nick Desaulniers ndesaulniers@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- Makefile | 11 ++++------- init/Kconfig | 17 +++++++++++++++++ kernel/trace/Kconfig | 1 + 3 files changed, 22 insertions(+), 7 deletions(-)
--- a/Makefile +++ b/Makefile @@ -657,17 +657,14 @@ KBUILD_CFLAGS += $(call cc-disable-warni KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE -KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,) -else -ifdef CONFIG_PROFILE_ALL_BRANCHES -KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,) +KBUILD_CFLAGS += -Os else KBUILD_CFLAGS += -O2 endif -endif
-KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \ - $(call cc-disable-warning,maybe-uninitialized,)) +ifdef CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED +KBUILD_CFLAGS += -Wno-maybe-uninitialized +endif
# Tell gcc to never replace conditional load with a non-conditional one KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0) --- a/init/Kconfig +++ b/init/Kconfig @@ -26,6 +26,22 @@ config CLANG_VERSION config CC_HAS_ASM_GOTO def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
+config CC_HAS_WARN_MAYBE_UNINITIALIZED + def_bool $(cc-option,-Wmaybe-uninitialized) + help + GCC >= 4.7 supports this option. + +config CC_DISABLE_WARN_MAYBE_UNINITIALIZED + bool + depends on CC_HAS_WARN_MAYBE_UNINITIALIZED + default CC_IS_GCC && GCC_VERSION < 40900 # unreliable for GCC < 4.9 + help + GCC's -Wmaybe-uninitialized is not reliable by definition. + Lots of false positive warnings are produced in some cases. + + If this option is enabled, -Wno-maybe-uninitialzed is passed + to the compiler to suppress maybe-uninitialized warnings. + config CONSTRUCTORS bool depends on !UML @@ -1083,6 +1099,7 @@ config CC_OPTIMIZE_FOR_PERFORMANCE
config CC_OPTIMIZE_FOR_SIZE bool "Optimize for size" + imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help Enabling this option will pass "-Os" instead of "-O2" to your compiler resulting in a smaller kernel. --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -370,6 +370,7 @@ config PROFILE_ANNOTATED_BRANCHES config PROFILE_ALL_BRANCHES bool "Profile all if conditionals" if !FORTIFY_SOURCE select TRACE_BRANCH_PROFILING + imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help This tracer profiles all branch conditions. Every if () taken in the kernel is recorded whether it hit or miss.
From: Linus Torvalds torvalds@linux-foundation.org
commit 78a5255ffb6a1af189a83e493d916ba1c54d8c75 upstream.
We have some rather random rules about when we accept the "maybe-initialized" warnings, and when we don't.
For example, we consider it unreliable for gcc versions < 4.9, but also if -O3 is enabled, or if optimizing for size. And then various kernel config options disabled it, because they know that they trigger that warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES).
And now gcc-10 seems to be introducing a lot of those warnings too, so it falls under the same heading as 4.9 did.
At the same time, we have a very straightforward way to _enable_ that warning when wanted: use "W=2" to enable more warnings.
So stop playing these ad-hoc games, and just disable that warning by default, with the known and straight-forward "if you want to work on the extra compiler warnings, use W=123".
Would it be great to have code that is always so obvious that it never confuses the compiler whether a variable is used initialized or not? Yes, it would. In a perfect world, the compilers would be smarter, and our source code would be simpler.
That's currently not the world we live in, though.
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- Makefile | 7 +++---- init/Kconfig | 17 ----------------- kernel/trace/Kconfig | 1 - 3 files changed, 3 insertions(+), 22 deletions(-)
--- a/Makefile +++ b/Makefile @@ -662,10 +662,6 @@ else KBUILD_CFLAGS += -O2 endif
-ifdef CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED -KBUILD_CFLAGS += -Wno-maybe-uninitialized -endif - # Tell gcc to never replace conditional load with a non-conditional one KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
@@ -796,6 +792,9 @@ KBUILD_CFLAGS += $(call cc-disable-warni # disable stringop warnings in gcc 8+ KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
+# Enabled with W=2, disabled by default as noisy +KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized) + # disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
--- a/init/Kconfig +++ b/init/Kconfig @@ -26,22 +26,6 @@ config CLANG_VERSION config CC_HAS_ASM_GOTO def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
-config CC_HAS_WARN_MAYBE_UNINITIALIZED - def_bool $(cc-option,-Wmaybe-uninitialized) - help - GCC >= 4.7 supports this option. - -config CC_DISABLE_WARN_MAYBE_UNINITIALIZED - bool - depends on CC_HAS_WARN_MAYBE_UNINITIALIZED - default CC_IS_GCC && GCC_VERSION < 40900 # unreliable for GCC < 4.9 - help - GCC's -Wmaybe-uninitialized is not reliable by definition. - Lots of false positive warnings are produced in some cases. - - If this option is enabled, -Wno-maybe-uninitialzed is passed - to the compiler to suppress maybe-uninitialized warnings. - config CONSTRUCTORS bool depends on !UML @@ -1099,7 +1083,6 @@ config CC_OPTIMIZE_FOR_PERFORMANCE
config CC_OPTIMIZE_FOR_SIZE bool "Optimize for size" - imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help Enabling this option will pass "-Os" instead of "-O2" to your compiler resulting in a smaller kernel. --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -370,7 +370,6 @@ config PROFILE_ANNOTATED_BRANCHES config PROFILE_ALL_BRANCHES bool "Profile all if conditionals" if !FORTIFY_SOURCE select TRACE_BRANCH_PROFILING - imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help This tracer profiles all branch conditions. Every if () taken in the kernel is recorded whether it hit or miss.
From: Linus Torvalds torvalds@linux-foundation.org
commit 5c45de21a2223fe46cf9488c99a7fbcf01527670 upstream.
This is a fine warning, but we still have a number of zero-length arrays in the kernel that come from the traditional gcc extension. Yes, they are getting converted to flexible arrays, but in the meantime the gcc-10 warning about zero-length bounds is very verbose, and is hiding other issues.
I missed one actual build failure because it was hidden among hundreds of lines of warning. Thankfully I caught it on the second go before pushing things out, but it convinced me that I really need to disable the new warnings for now.
We'll hopefully be all done with our conversion to flexible arrays in the not too distant future, and we can then re-enable this warning.
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- Makefile | 3 +++ 1 file changed, 3 insertions(+)
--- a/Makefile +++ b/Makefile @@ -792,6 +792,9 @@ KBUILD_CFLAGS += $(call cc-disable-warni # disable stringop warnings in gcc 8+ KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
+# We'll want to enable this eventually, but it's not going away for 5.7 at least +KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds) + # Enabled with W=2, disabled by default as noisy KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
From: Linus Torvalds torvalds@linux-foundation.org
commit 44720996e2d79e47d508b0abe99b931a726a3197 upstream.
This is another fine warning, related to the 'zero-length-bounds' one, but hitting the same historical code in the kernel.
Because C didn't historically support flexible array members, we have code that instead uses a one-sized array, the same way we have cases of zero-sized arrays.
The one-sized arrays come from either not wanting to use the gcc zero-sized array extension, or from a slight convenience-feature, where particularly for strings, the size of the structure now includes the allocation for the final NUL character.
So with a "char name[1];" at the end of a structure, you can do things like
v = my_malloc(sizeof(struct vendor) + strlen(name));
and avoid the "+1" for the terminator.
Yes, the modern way to do that is with a flexible array, and using 'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That also technically gets the size "more correct" in that it avoids any alignment (and thus padding) issues, but this is another long-term cleanup thing that will not happen for 5.7.
So disable the warning for now, even though it's potentially quite useful. Having a slew of warnings that then hide more urgent new issues is not an improvement.
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- Makefile | 1 + 1 file changed, 1 insertion(+)
--- a/Makefile +++ b/Makefile @@ -794,6 +794,7 @@ KBUILD_CFLAGS += $(call cc-disable-warni
# We'll want to enable this eventually, but it's not going away for 5.7 at least KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds) +KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds)
# Enabled with W=2, disabled by default as noisy KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
From: Linus Torvalds torvalds@linux-foundation.org
commit 5a76021c2eff7fcf2f0918a08fd8a37ce7922921 upstream.
This is the final array bounds warning removal for gcc-10 for now.
Again, the warning is good, and we should re-enable all these warnings when we have converted all the legacy array declaration cases to flexible arrays. But in the meantime, it's just noise.
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- Makefile | 1 + 1 file changed, 1 insertion(+)
--- a/Makefile +++ b/Makefile @@ -795,6 +795,7 @@ KBUILD_CFLAGS += $(call cc-disable-warni # We'll want to enable this eventually, but it's not going away for 5.7 at least KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds) KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds) +KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow)
# Enabled with W=2, disabled by default as noisy KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
From: Linus Torvalds torvalds@linux-foundation.org
commit adc71920969870dfa54e8f40dac8616284832d02 upstream.
gcc-10 now warns about passing aliasing pointers to functions that take restricted pointers.
That's actually a great warning, and if we ever start using 'restrict' in the kernel, it might be quite useful. But right now we don't, and it turns out that the only thing this warns about is an idiom where we have declared a few functions to be "printf-like" (which seems to make gcc pick up the restricted pointer thing), and then we print to the same buffer that we also use as an input.
And people do that as an odd concatenation pattern, with code like this:
#define sysfs_show_gen_prop(buffer, fmt, ...) \ snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)
where we have 'buffer' as both the destination of the final result, and as the initial argument.
Yes, it's a bit questionable. And outside of the kernel, people do have standard declarations like
int snprintf( char *restrict buffer, size_t bufsz, const char *restrict format, ... );
where that output buffer is marked as a restrict pointer that cannot alias with any other arguments.
But in the context of the kernel, that 'use snprintf() to concatenate to the end result' does work, and the pattern shows up in multiple places. And we have not marked our own version of snprintf() as taking restrict pointers, so the warning is incorrect for now, and gcc picks it up on its own.
If we do start using 'restrict' in the kernel (and it might be a good idea if people find places where it matters), we'll need to figure out how to avoid this issue for snprintf and friends. But in the meantime, this warning is not useful.
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- Makefile | 3 +++ 1 file changed, 3 insertions(+)
--- a/Makefile +++ b/Makefile @@ -797,6 +797,9 @@ KBUILD_CFLAGS += $(call cc-disable-warni KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds) KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow)
+# Another good warning that we'll want to enable eventually +KBUILD_CFLAGS += $(call cc-disable-warning, restrict) + # Enabled with W=2, disabled by default as noisy KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
From: Linus Torvalds torvalds@linux-foundation.org
commit 1a263ae60b04de959d9ce9caea4889385eefcc7b upstream.
gcc-10 has started warning about conflicting types for a few new built-in functions, particularly 'free()'.
This results in warnings like:
crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch]
because the crypto layer had its local freeing functions called 'free()'.
Gcc-10 is in the wrong here, since that function is marked 'static', and thus there is no chance of confusion with any standard library function namespace.
But the simplest thing to do is to just use a different name here, and avoid this gcc mis-feature.
[ Side note: gcc knowing about 'free()' is in itself not the mis-feature: the semantics of 'free()' are special enough that a compiler can validly do special things when seeing it.
So the mis-feature here is that gcc thinks that 'free()' is some restricted name, and you can't shadow it as a local static function.
Making the special 'free()' semantics be a function attribute rather than tied to the name would be the much better model ]
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- crypto/lrw.c | 4 ++-- crypto/xts.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
--- a/crypto/lrw.c +++ b/crypto/lrw.c @@ -453,7 +453,7 @@ static void exit_tfm(struct crypto_skcip crypto_free_skcipher(ctx->child); }
-static void free(struct skcipher_instance *inst) +static void free_inst(struct skcipher_instance *inst) { crypto_drop_skcipher(skcipher_instance_ctx(inst)); kfree(inst); @@ -565,7 +565,7 @@ static int create(struct crypto_template inst->alg.encrypt = encrypt; inst->alg.decrypt = decrypt;
- inst->free = free; + inst->free = free_inst;
err = skcipher_register_instance(tmpl, inst); if (err) --- a/crypto/xts.c +++ b/crypto/xts.c @@ -393,7 +393,7 @@ static void exit_tfm(struct crypto_skcip crypto_free_cipher(ctx->tweak); }
-static void free(struct skcipher_instance *inst) +static void free_inst(struct skcipher_instance *inst) { crypto_drop_skcipher(skcipher_instance_ctx(inst)); kfree(inst); @@ -504,7 +504,7 @@ static int create(struct crypto_template inst->alg.encrypt = encrypt; inst->alg.decrypt = decrypt;
- inst->free = free; + inst->free = free_inst;
err = skcipher_register_instance(tmpl, inst); if (err)
From: Takashi Iwai tiwai@suse.de
commit b590b38ca305d6d7902ec7c4f7e273e0069f3bcc upstream.
Lenovo Thinkpad T530 seems to have a sensitive internal mic capture that needs to limit the mic boost like a few other Thinkpad models. Although we may change the quirk for ALC269_FIXUP_LENOVO_DOCK, this hits way too many other laptop models, so let's add a new fixup model that limits the internal mic boost on top of the existing quirk and apply to only T530.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1171293 Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200514160533.10337-1-tiwai@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/pci/hda/patch_realtek.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5616,6 +5616,7 @@ enum { ALC269_FIXUP_HP_LINE1_MIC1_LED, ALC269_FIXUP_INV_DMIC, ALC269_FIXUP_LENOVO_DOCK, + ALC269_FIXUP_LENOVO_DOCK_LIMIT_BOOST, ALC269_FIXUP_NO_SHUTUP, ALC286_FIXUP_SONY_MIC_NO_PRESENCE, ALC269_FIXUP_PINCFG_NO_HP_TO_LINEOUT, @@ -5928,6 +5929,12 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id = ALC269_FIXUP_PINCFG_NO_HP_TO_LINEOUT }, + [ALC269_FIXUP_LENOVO_DOCK_LIMIT_BOOST] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_limit_int_mic_boost, + .chained = true, + .chain_id = ALC269_FIXUP_LENOVO_DOCK, + }, [ALC269_FIXUP_PINCFG_NO_HP_TO_LINEOUT] = { .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_pincfg_no_hp_to_lineout, @@ -7013,7 +7020,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x21b8, "Thinkpad Edge 14", ALC269_FIXUP_SKU_IGNORE), SND_PCI_QUIRK(0x17aa, 0x21ca, "Thinkpad L412", ALC269_FIXUP_SKU_IGNORE), SND_PCI_QUIRK(0x17aa, 0x21e9, "Thinkpad Edge 15", ALC269_FIXUP_SKU_IGNORE), - SND_PCI_QUIRK(0x17aa, 0x21f6, "Thinkpad T530", ALC269_FIXUP_LENOVO_DOCK), + SND_PCI_QUIRK(0x17aa, 0x21f6, "Thinkpad T530", ALC269_FIXUP_LENOVO_DOCK_LIMIT_BOOST), SND_PCI_QUIRK(0x17aa, 0x21fa, "Thinkpad X230", ALC269_FIXUP_LENOVO_DOCK), SND_PCI_QUIRK(0x17aa, 0x21f3, "Thinkpad T430", ALC269_FIXUP_LENOVO_DOCK), SND_PCI_QUIRK(0x17aa, 0x21fb, "Thinkpad T430s", ALC269_FIXUP_LENOVO_DOCK), @@ -7150,6 +7157,7 @@ static const struct hda_model_fixup alc2 {.id = ALC269_FIXUP_HEADSET_MODE, .name = "headset-mode"}, {.id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC, .name = "headset-mode-no-hp-mic"}, {.id = ALC269_FIXUP_LENOVO_DOCK, .name = "lenovo-dock"}, + {.id = ALC269_FIXUP_LENOVO_DOCK_LIMIT_BOOST, .name = "lenovo-dock-limit-boost"}, {.id = ALC269_FIXUP_HP_GPIO_LED, .name = "hp-gpio-led"}, {.id = ALC269_FIXUP_HP_DOCK_GPIO_MIC1_LED, .name = "hp-dock-gpio-mic1-led"}, {.id = ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, .name = "dell-headset-multi"},
From: Takashi Iwai tiwai@suse.de
commit c1f6e3c818dd734c30f6a7eeebf232ba2cf3181d upstream.
The rawmidi core allows user to resize the runtime buffer via ioctl, and this may lead to UAF when performed during concurrent reads or writes: the read/write functions unlock the runtime lock temporarily during copying form/to user-space, and that's the race window.
This patch fixes the hole by introducing a reference counter for the runtime buffer read/write access and returns -EBUSY error when the resize is performed concurrently against read/write.
Note that the ref count field is a simple integer instead of refcount_t here, since the all contexts accessing the buffer is basically protected with a spinlock, hence we need no expensive atomic ops. Also, note that this busy check is needed only against read / write functions, and not in receive/transmit callbacks; the race can happen only at the spinlock hole mentioned in the above, while the whole function is protected for receive / transmit callbacks.
Reported-by: butt3rflyh4ck butterflyhuangxx@gmail.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/CAFcO6XMWpUVK_yzzCpp8_XP7+=oUpQvuBeCbMffEDkpe8jWrf... Link: https://lore.kernel.org/r/s5heerw3r5z.wl-tiwai@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- include/sound/rawmidi.h | 1 + sound/core/rawmidi.c | 31 +++++++++++++++++++++++++++---- 2 files changed, 28 insertions(+), 4 deletions(-)
--- a/include/sound/rawmidi.h +++ b/include/sound/rawmidi.h @@ -76,6 +76,7 @@ struct snd_rawmidi_runtime { size_t avail_min; /* min avail for wakeup */ size_t avail; /* max used buffer for wakeup */ size_t xruns; /* over/underruns counter */ + int buffer_ref; /* buffer reference count */ /* misc */ spinlock_t lock; wait_queue_head_t sleep; --- a/sound/core/rawmidi.c +++ b/sound/core/rawmidi.c @@ -112,6 +112,17 @@ static void snd_rawmidi_input_event_work runtime->event(runtime->substream); }
+/* buffer refcount management: call with runtime->lock held */ +static inline void snd_rawmidi_buffer_ref(struct snd_rawmidi_runtime *runtime) +{ + runtime->buffer_ref++; +} + +static inline void snd_rawmidi_buffer_unref(struct snd_rawmidi_runtime *runtime) +{ + runtime->buffer_ref--; +} + static int snd_rawmidi_runtime_create(struct snd_rawmidi_substream *substream) { struct snd_rawmidi_runtime *runtime; @@ -661,6 +672,11 @@ static int resize_runtime_buffer(struct if (!newbuf) return -ENOMEM; spin_lock_irq(&runtime->lock); + if (runtime->buffer_ref) { + spin_unlock_irq(&runtime->lock); + kvfree(newbuf); + return -EBUSY; + } oldbuf = runtime->buffer; runtime->buffer = newbuf; runtime->buffer_size = params->buffer_size; @@ -960,8 +976,10 @@ static long snd_rawmidi_kernel_read1(str long result = 0, count1; struct snd_rawmidi_runtime *runtime = substream->runtime; unsigned long appl_ptr; + int err = 0;
spin_lock_irqsave(&runtime->lock, flags); + snd_rawmidi_buffer_ref(runtime); while (count > 0 && runtime->avail) { count1 = runtime->buffer_size - runtime->appl_ptr; if (count1 > count) @@ -980,16 +998,19 @@ static long snd_rawmidi_kernel_read1(str if (userbuf) { spin_unlock_irqrestore(&runtime->lock, flags); if (copy_to_user(userbuf + result, - runtime->buffer + appl_ptr, count1)) { - return result > 0 ? result : -EFAULT; - } + runtime->buffer + appl_ptr, count1)) + err = -EFAULT; spin_lock_irqsave(&runtime->lock, flags); + if (err) + goto out; } result += count1; count -= count1; } + out: + snd_rawmidi_buffer_unref(runtime); spin_unlock_irqrestore(&runtime->lock, flags); - return result; + return result > 0 ? result : err; }
long snd_rawmidi_kernel_read(struct snd_rawmidi_substream *substream, @@ -1261,6 +1282,7 @@ static long snd_rawmidi_kernel_write1(st return -EAGAIN; } } + snd_rawmidi_buffer_ref(runtime); while (count > 0 && runtime->avail > 0) { count1 = runtime->buffer_size - runtime->appl_ptr; if (count1 > count) @@ -1292,6 +1314,7 @@ static long snd_rawmidi_kernel_write1(st } __end: count1 = runtime->avail < runtime->buffer_size; + snd_rawmidi_buffer_unref(runtime); spin_unlock_irqrestore(&runtime->lock, flags); if (count1) snd_rawmidi_output_trigger(substream, 1);
From: Jesus Ramos jesus-ramos@live.com
commit 073919e09ca445d4486968e3f851372ff44cf2b5 upstream.
Kingston HyperX headset with 0951:16ad also needs the same quirk for delaying the frequency controls.
Signed-off-by: Jesus Ramos jesus-ramos@live.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/BY5PR19MB3634BA68C7CCA23D8DF428E796AF0@BY5PR19MB36... Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/usb/quirks.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1334,13 +1334,14 @@ void snd_usb_ctl_msg_quirk(struct usb_de && (requesttype & USB_TYPE_MASK) == USB_TYPE_CLASS) msleep(20);
- /* Zoom R16/24, Logitech H650e, Jabra 550a needs a tiny delay here, - * otherwise requests like get/set frequency return as failed despite - * actually succeeding. + /* Zoom R16/24, Logitech H650e, Jabra 550a, Kingston HyperX needs a tiny + * delay here, otherwise requests like get/set frequency return as + * failed despite actually succeeding. */ if ((chip->usb_id == USB_ID(0x1686, 0x00dd) || chip->usb_id == USB_ID(0x046d, 0x0a46) || - chip->usb_id == USB_ID(0x0b0e, 0x0349)) && + chip->usb_id == USB_ID(0x0b0e, 0x0349) || + chip->usb_id == USB_ID(0x0951, 0x16ad)) && (requesttype & USB_TYPE_MASK) == USB_TYPE_CLASS) usleep_range(1000, 2000); }
From: Eugeniu Rosca erosca@de.adit-jv.com
commit 76e1ef1d81a4129d7e2fb8c48c83b166d1c8e040 upstream.
On Tue, May 12, 2020 at 09:36:07PM +0800, Kai-Heng Feng wrote [1]:
This patch prevents my Raven Ridge xHCI from getting runtime suspend.
The problem described in v5.6 commit 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") applies solely to the USB5534B hub [2] present on the Kingfisher Infotainment Carrier Board, manufactured by Shimafuji Electric Inc [3].
Despite that, the aforementioned commit applied the quirk to _all_ hubs carrying vendor ID 0x424 (i.e. SMSC), of which there are more [4] than initially expected. Consequently, the quirk is now enabled on platforms carrying SMSC/Microchip hub models which potentially don't exhibit the original issue.
To avoid reports like [1], further limit the quirk's scope to USB5534B [2], by employing both Vendor and Product ID checks.
Tested on H3ULCB + Kingfisher rev. M05.
[1] https://lore.kernel.org/linux-renesas-soc/73933975-6F0E-40F5-9584-D2B8F615C0... [2] https://www.microchip.com/wwwproducts/en/USB5534B [3] http://www.shimafuji.co.jp/wp/wp-content/uploads/2018/08/SBEV-RCAR-KF-M06Boa... [4] https://devicehunt.com/search/type/usb/vendor/0424/device/any
Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org # v4.14+ Cc: Alan Stern stern@rowland.harvard.edu Cc: Hardik Gajjar hgajjar@de.adit-jv.com Cc: linux-renesas-soc@vger.kernel.org Cc: linux-usb@vger.kernel.org Reported-by: Kai-Heng Feng kai.heng.feng@canonical.com Signed-off-by: Eugeniu Rosca erosca@de.adit-jv.com Tested-by: Kai-Heng Feng kai.heng.feng@canonical.com Link: https://lore.kernel.org/r/20200514220246.13290-1-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/core/hub.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -37,6 +37,7 @@
#define USB_VENDOR_GENESYS_LOGIC 0x05e3 #define USB_VENDOR_SMSC 0x0424 +#define USB_PRODUCT_USB5534B 0x5534 #define HUB_QUIRK_CHECK_PORT_AUTOSUSPEND 0x01 #define HUB_QUIRK_DISABLE_AUTOSUSPEND 0x02
@@ -5434,8 +5435,11 @@ out_hdev_lock: }
static const struct usb_device_id hub_id_table[] = { - { .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_CLASS, + { .match_flags = USB_DEVICE_ID_MATCH_VENDOR + | USB_DEVICE_ID_MATCH_PRODUCT + | USB_DEVICE_ID_MATCH_INT_CLASS, .idVendor = USB_VENDOR_SMSC, + .idProduct = USB_PRODUCT_USB5534B, .bInterfaceClass = USB_CLASS_HUB, .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND}, { .match_flags = USB_DEVICE_ID_MATCH_VENDOR
From: Li Jun jun.li@nxp.com
commit 1449cb2c2253d37d998c3714aa9b95416d16d379 upstream.
While removing the host (e.g. for USB role switch from host to device), if runtime pm is enabled by user, below oops occurs on dwc3 and cdns3 platforms. Keeping the xhci-plat device active during host removal, and disabling runtime pm before calling pm_runtime_set_suspended() fixes them.
oops1: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000240 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.4.3-00107-g64d454a-dirty Hardware name: FSL i.MX8MP EVK (DT) Workqueue: pm pm_runtime_work pstate: 60000005 (nZCv daif -PAN -UAO) pc : xhci_suspend+0x34/0x698 lr : xhci_plat_runtime_suspend+0x2c/0x38 sp : ffff800011ddbbc0 Call trace: xhci_suspend+0x34/0x698 xhci_plat_runtime_suspend+0x2c/0x38 pm_generic_runtime_suspend+0x28/0x40 __rpm_callback+0xd8/0x138 rpm_callback+0x24/0x98 rpm_suspend+0xe0/0x448 rpm_idle+0x124/0x140 pm_runtime_work+0xa0/0xf8 process_one_work+0x1dc/0x370 worker_thread+0x48/0x468 kthread+0xf0/0x120 ret_from_fork+0x10/0x1c
oops2: usb 2-1: USB disconnect, device number 2 xhci-hcd xhci-hcd.1.auto: remove, state 4 usb usb2: USB disconnect, device number 1 xhci-hcd xhci-hcd.1.auto: USB bus 2 deregistered xhci-hcd xhci-hcd.1.auto: remove, state 4 usb usb1: USB disconnect, device number 1 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000138 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted 5.6.0-rc4-next-20200304-03578 Hardware name: Freescale i.MX8QXP MEK (DT) Workqueue: 1-0050 tcpm_state_machine_work pstate: 20000005 (nzCv daif -PAN -UAO) pc : xhci_free_dev+0x214/0x270 lr : xhci_plat_runtime_resume+0x78/0x88 sp : ffff80001006b5b0 Call trace: xhci_free_dev+0x214/0x270 xhci_plat_runtime_resume+0x78/0x88 pm_generic_runtime_resume+0x30/0x48 __rpm_callback+0x90/0x148 rpm_callback+0x28/0x88 rpm_resume+0x568/0x758 rpm_resume+0x260/0x758 rpm_resume+0x260/0x758 __pm_runtime_resume+0x40/0x88 device_release_driver_internal+0xa0/0x1c8 device_release_driver+0x1c/0x28 bus_remove_device+0xd4/0x158 device_del+0x15c/0x3a0 usb_disable_device+0xb0/0x268 usb_disconnect+0xcc/0x300 usb_remove_hcd+0xf4/0x1dc xhci_plat_remove+0x78/0xe0 platform_drv_remove+0x30/0x50 device_release_driver_internal+0xfc/0x1c8 device_release_driver+0x1c/0x28 bus_remove_device+0xd4/0x158 device_del+0x15c/0x3a0 platform_device_del.part.0+0x20/0x90 platform_device_unregister+0x28/0x40 cdns3_host_exit+0x20/0x40 cdns3_role_stop+0x60/0x90 cdns3_role_set+0x64/0xd8 usb_role_switch_set_role.part.0+0x3c/0x68 usb_role_switch_set_role+0x20/0x30 tcpm_mux_set+0x60/0xf8 tcpm_reset_port+0xa4/0xf0 tcpm_detach.part.0+0x28/0x50 tcpm_state_machine_work+0x12ac/0x2360 process_one_work+0x1c8/0x470 worker_thread+0x50/0x428 kthread+0xfc/0x128 ret_from_fork+0x10/0x18 Code: c8037c02 35ffffa3 17ffe7c3 f9800011 (c85f7c01) ---[ end trace 45b1a173d2679e44 ]---
[minor commit message cleanup -Mathias] Cc: Baolin Wang baolin.wang@linaro.org Cc: stable@vger.kernel.org Fixes: b0c69b4bace3 ("usb: host: plat: Enable xHCI plat runtime PM") Reviewed-by: Peter Chen peter.chen@nxp.com Tested-by: Peter Chen peter.chen@nxp.com Signed-off-by: Li Jun jun.li@nxp.com Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20200514110432.25564-3-mathias.nyman@linux.intel.c... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/host/xhci-plat.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -361,6 +361,7 @@ static int xhci_plat_remove(struct platf struct clk *reg_clk = xhci->reg_clk; struct usb_hcd *shared_hcd = xhci->shared_hcd;
+ pm_runtime_get_sync(&dev->dev); xhci->xhc_state |= XHCI_STATE_REMOVING;
usb_remove_hcd(shared_hcd); @@ -374,8 +375,9 @@ static int xhci_plat_remove(struct platf clk_disable_unprepare(reg_clk); usb_put_hcd(hcd);
- pm_runtime_set_suspended(&dev->dev); pm_runtime_disable(&dev->dev); + pm_runtime_put_noidle(&dev->dev); + pm_runtime_set_suspended(&dev->dev);
return 0; }
From: Kyungtae Kim kt0755@gmail.com
commit 15753588bcd4bbffae1cca33c8ced5722477fe1f upstream.
FuzzUSB (a variant of syzkaller) found an illegal array access using an incorrect index while binding a gadget with UDC.
Reference: https://www.spinics.net/lists/linux-usb/msg194331.html
This bug occurs when a size variable used for a buffer is misused to access its strcpy-ed buffer. Given a buffer along with its size variable (taken from user input), from which, a new buffer is created using kstrdup(). Due to the original buffer containing 0 value in the middle, the size of the kstrdup-ed buffer becomes smaller than that of the original. So accessing the kstrdup-ed buffer with the same size variable triggers memory access violation.
The fix makes sure no zero value in the buffer, by comparing the strlen() of the orignal buffer with the size variable, so that the access to the kstrdup-ed buffer is safe.
BUG: KASAN: slab-out-of-bounds in gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266 Read of size 1 at addr ffff88806a55dd7e by task syz-executor.0/17208
CPU: 2 PID: 17208 Comm: syz-executor.0 Not tainted 5.6.8 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x131/0x1b0 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:641 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132 gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266 flush_write_buffer fs/configfs/file.c:251 [inline] configfs_write_file+0x2f1/0x4c0 fs/configfs/file.c:283 __vfs_write+0x85/0x110 fs/read_write.c:494 vfs_write+0x1cd/0x510 fs/read_write.c:558 ksys_write+0x18a/0x220 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:620 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Kyungtae Kim kt0755@gmail.com Reported-and-tested-by: Kyungtae Kim kt0755@gmail.com Cc: Felipe Balbi balbi@kernel.org Cc: stable stable@vger.kernel.org Link: https://lore.kernel.org/r/20200510054326.GA19198@pizza01 Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/gadget/configfs.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/usb/gadget/configfs.c +++ b/drivers/usb/gadget/configfs.c @@ -260,6 +260,9 @@ static ssize_t gadget_dev_desc_UDC_store char *name; int ret;
+ if (strlen(page) < len) + return -EOVERFLOW; + name = kstrdup(page, GFP_KERNEL); if (!name) return -ENOMEM;
From: Sriharsha Allenki sallenki@codeaurora.org
commit 3c6f8cb92c9178fc0c66b580ea3df1fa3ac1155a upstream.
On platforms with IOMMU enabled, multiple SGs can be coalesced into one by the IOMMU driver. In that case the SG list processing as part of the completion of a urb on a bulk endpoint can result into a NULL pointer dereference with the below stack dump.
<6> Unable to handle kernel NULL pointer dereference at virtual address 0000000c <6> pgd = c0004000 <6> [0000000c] *pgd=00000000 <6> Internal error: Oops: 5 [#1] PREEMPT SMP ARM <2> PC is at xhci_queue_bulk_tx+0x454/0x80c <2> LR is at xhci_queue_bulk_tx+0x44c/0x80c <2> pc : [<c08907c4>] lr : [<c08907bc>] psr: 000000d3 <2> sp : ca337c80 ip : 00000000 fp : ffffffff <2> r10: 00000000 r9 : 50037000 r8 : 00004000 <2> r7 : 00000000 r6 : 00004000 r5 : 00000000 r4 : 00000000 <2> r3 : 00000000 r2 : 00000082 r1 : c2c1a200 r0 : 00000000 <2> Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none <2> Control: 10c0383d Table: b412c06a DAC: 00000051 <6> Process usb-storage (pid: 5961, stack limit = 0xca336210) <snip> <2> [<c08907c4>] (xhci_queue_bulk_tx) <2> [<c0881b3c>] (xhci_urb_enqueue) <2> [<c0831068>] (usb_hcd_submit_urb) <2> [<c08350b4>] (usb_sg_wait) <2> [<c089f384>] (usb_stor_bulk_transfer_sglist) <2> [<c089f2c0>] (usb_stor_bulk_srb) <2> [<c089fe38>] (usb_stor_Bulk_transport) <2> [<c089f468>] (usb_stor_invoke_transport) <2> [<c08a11b4>] (usb_stor_control_thread) <2> [<c014a534>] (kthread)
The above NULL pointer dereference is the result of block_len and the sent_len set to zero after the first SG of the list when IOMMU driver is enabled. Because of this the loop of processing the SGs has run more than num_sgs which resulted in a sg_next on the last SG of the list which has SG_END set.
Fix this by check for the sg before any attributes of the sg are accessed.
[modified reason for null pointer dereference in commit message subject -Mathias] Fixes: f9c589e142d04 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Signed-off-by: Sriharsha Allenki sallenki@codeaurora.org Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20200514110432.25564-2-mathias.nyman@linux.intel.c... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/host/xhci-ring.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3331,8 +3331,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd * /* New sg entry */ --num_sgs; sent_len -= block_len; - if (num_sgs != 0) { - sg = sg_next(sg); + sg = sg_next(sg); + if (num_sgs != 0 && sg) { block_len = sg_dma_len(sg); addr = (u64) sg_dma_address(sg); addr += sent_len;
From: Kishon Vijay Abraham I kishon@ti.com
commit 90d4d3f4ea45370d482fa609dbae4d2281b4074f upstream.
Even though commit cfb5d65f2595 ("ARM: dts: dra7: Add bus_dma_limit for L3 bus") added bus_dma_limit for L3 bus, the PCIe controller gets incorrect value of bus_dma_limit.
Fix it by adding empty dma-ranges property to axi@0 and axi@1 (parent device tree node of PCIe controller).
Cc: stable@kernel.org Signed-off-by: Kishon Vijay Abraham I kishon@ti.com Signed-off-by: Tony Lindgren tony@atomide.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/arm/boot/dts/dra7.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -312,6 +312,7 @@ #address-cells = <1>; ranges = <0x51000000 0x51000000 0x3000 0x0 0x20000000 0x10000000>; + dma-ranges; /** * To enable PCI endpoint mode, disable the pcie1_rc * node and enable pcie1_ep mode. @@ -325,7 +326,6 @@ device_type = "pci"; ranges = <0x81000000 0 0 0x03000 0 0x00010000 0x82000000 0 0x20013000 0x13000 0 0xffed000>; - dma-ranges = <0x02000000 0x0 0x00000000 0x00000000 0x1 0x00000000>; bus-range = <0x00 0xff>; #interrupt-cells = <1>; num-lanes = <1>; @@ -368,6 +368,7 @@ #address-cells = <1>; ranges = <0x51800000 0x51800000 0x3000 0x0 0x30000000 0x10000000>; + dma-ranges; status = "disabled"; pcie2_rc: pcie@51800000 { reg = <0x51800000 0x2000>, <0x51802000 0x14c>, <0x1000 0x2000>; @@ -378,7 +379,6 @@ device_type = "pci"; ranges = <0x81000000 0 0 0x03000 0 0x00010000 0x82000000 0 0x30013000 0x13000 0 0xffed000>; - dma-ranges = <0x02000000 0x0 0x00000000 0x00000000 0x1 0x00000000>; bus-range = <0x00 0xff>; #interrupt-cells = <1>; num-lanes = <1>;
From: Fabio Estevam festevam@gmail.com
commit 0caf34350a25907515d929a9c77b9b206aac6d1e upstream.
The I2C2 pins are already used and the following errors are seen:
imx27-pinctrl 10015000.iomuxc: pin MX27_PAD_I2C2_SDA already requested by 10012000.i2c; cannot claim for 1001d000.i2c imx27-pinctrl 10015000.iomuxc: pin-69 (1001d000.i2c) status -22 imx27-pinctrl 10015000.iomuxc: could not request pin 69 (MX27_PAD_I2C2_SDA) from group i2c2grp on device 10015000.iomuxc imx-i2c 1001d000.i2c: Error applying setting, reverse things back imx-i2c: probe of 1001d000.i2c failed with error -22
Fix it by adding the correct I2C1 IOMUX entries for the pinctrl_i2c1 group.
Cc: stable@vger.kernel.org Fixes: 61664d0b432a ("ARM: dts: imx27 phyCARD-S pinctrl") Signed-off-by: Fabio Estevam festevam@gmail.com Reviewed-by: Stefan Riedmueller s.riedmueller@phytec.de Signed-off-by: Shawn Guo shawnguo@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts +++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts @@ -81,8 +81,8 @@ imx27-phycard-s-rdk { pinctrl_i2c1: i2c1grp { fsl,pins = < - MX27_PAD_I2C2_SDA__I2C2_SDA 0x0 - MX27_PAD_I2C2_SCL__I2C2_SCL 0x0 + MX27_PAD_I2C_DATA__I2C_DATA 0x0 + MX27_PAD_I2C_CLK__I2C_CLK 0x0 >; };
From: Adam McCoy adam@forsedomani.com
commit a48137996063d22ffba77e077425f49873856ca5 upstream.
Failed async writes that are requeued may not clean up a refcount on the file, which can result in a leaked open. This scenario arises very reliably when using persistent handles and a reconnect occurs while writing.
cifs_writev_requeue only releases the reference if the write fails (rc != 0). The server->ops->async_writev operation will take its own reference, so the initial reference can always be released.
Signed-off-by: Adam McCoy adam@forsedomani.com Signed-off-by: Steve French stfrench@microsoft.com CC: Stable stable@vger.kernel.org Reviewed-by: Pavel Shilovsky pshilov@microsoft.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/cifs/cifssmb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -2051,8 +2051,8 @@ cifs_writev_requeue(struct cifs_writedat } }
+ kref_put(&wdata2->refcount, cifs_writedata_release); if (rc) { - kref_put(&wdata2->refcount, cifs_writedata_release); if (is_retryable_error(rc)) continue; i += nr_pages;
From: Borislav Petkov bp@suse.de
commit a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e upstream.
... or the odyssey of trying to disable the stack protector for the function which generates the stack canary value.
The whole story started with Sergei reporting a boot crash with a kernel built with gcc-10:
Kernel panic — not syncing: stack-protector: Kernel stack is corrupted in: start_secondary CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc5—00235—gfffb08b37df9 #139 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M—D3H, BIOS F12 11/14/2013 Call Trace: dump_stack panic ? start_secondary __stack_chk_fail start_secondary secondary_startup_64 -—-[ end Kernel panic — not syncing: stack—protector: Kernel stack is corrupted in: start_secondary
This happens because gcc-10 tail-call optimizes the last function call in start_secondary() - cpu_startup_entry() - and thus emits a stack canary check which fails because the canary value changes after the boot_init_stack_canary() call.
To fix that, the initial attempt was to mark the one function which generates the stack canary with:
__attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused)
however, using the optimize attribute doesn't work cumulatively as the attribute does not add to but rather replaces previously supplied optimization options - roughly all -fxxx options.
The key one among them being -fno-omit-frame-pointer and thus leading to not present frame pointer - frame pointer which the kernel needs.
The next attempt to prevent compilers from tail-call optimizing the last function call cpu_startup_entry(), shy of carving out start_secondary() into a separate compilation unit and building it with -fno-stack-protector, was to add an empty asm("").
This current solution was short and sweet, and reportedly, is supported by both compilers but we didn't get very far this time: future (LTO?) optimization passes could potentially eliminate this, which leads us to the third attempt: having an actual memory barrier there which the compiler cannot ignore or move around etc.
That should hold for a long time, but hey we said that about the other two solutions too so...
Reported-by: Sergei Trofimovich slyfox@gentoo.org Signed-off-by: Borislav Petkov bp@suse.de Tested-by: Kalle Valo kvalo@codeaurora.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200314164451.346497-1-slyfox@gentoo.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/x86/include/asm/stackprotector.h | 7 ++++++- arch/x86/kernel/smpboot.c | 8 ++++++++ arch/x86/xen/smp_pv.c | 1 + include/linux/compiler.h | 6 ++++++ init/main.c | 2 ++ 5 files changed, 23 insertions(+), 1 deletion(-)
--- a/arch/x86/include/asm/stackprotector.h +++ b/arch/x86/include/asm/stackprotector.h @@ -55,8 +55,13 @@ /* * Initialize the stackprotector canary value. * - * NOTE: this must only be called from functions that never return, + * NOTE: this must only be called from functions that never return * and it must always be inlined. + * + * In addition, it should be called from a compilation unit for which + * stack protector is disabled. Alternatively, the caller should not end + * with a function call which gets tail-call optimized as that would + * lead to checking a modified canary value. */ static __always_inline void boot_init_stack_canary(void) { --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -269,6 +269,14 @@ static void notrace start_secondary(void
wmb(); cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); + + /* + * Prevent tail call to cpu_startup_entry() because the stack protector + * guard has been changed a couple of function calls up, in + * boot_init_stack_canary() and must not be checked before tail calling + * another function. + */ + prevent_tail_call_optimization(); }
/** --- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -89,6 +89,7 @@ asmlinkage __visible void cpu_bringup_an { cpu_bringup(); cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); + prevent_tail_call_optimization(); }
void xen_smp_intr_free_pv(unsigned int cpu) --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -351,4 +351,10 @@ static inline void *offset_to_ptr(const compiletime_assert(__native_word(t), \ "Need native word sized stores/loads for atomicity.")
+/* + * This is needed in functions which generate the stack canary, see + * arch/x86/kernel/smpboot.c::start_secondary() for an example. + */ +#define prevent_tail_call_optimization() mb() + #endif /* __LINUX_COMPILER_H */ --- a/init/main.c +++ b/init/main.c @@ -735,6 +735,8 @@ asmlinkage __visible void __init start_k
/* Do the rest non-__init'ed, we're now alive */ rest_init(); + + prevent_tail_call_optimization(); }
/* Call all constructor functions linked into the kernel. */
Hi!
To fix that, the initial attempt was to mark the one function which generates the stack canary with:
__attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused)
however, using the optimize attribute doesn't work cumulatively as the attribute does not add to but rather replaces previously supplied optimization options - roughly all -fxxx options.
The key one among them being -fno-omit-frame-pointer and thus leading to not present frame pointer - frame pointer which the kernel needs.
The next attempt to prevent compilers from tail-call optimizing the last function call cpu_startup_entry(), shy of carving out start_secondary() into a separate compilation unit and building it with -fno-stack-protector, was to add an empty asm("").
This current solution was short and sweet, and reportedly, is supported by both compilers but we didn't get very far this time: future (LTO?) optimization passes could potentially eliminate this, which leads us to the third attempt: having an actual memory barrier there which the compiler cannot ignore or move around etc.
That should hold for a long time, but hey we said that about the other two solutions too so...
You need compiler barrier, but mb() compiles down to
asm volatile(ALTERNATIVE("lock; addl $0,-4(%%esp)", "mfence", \ X86_FEATURE_XMM2) ::: "memory", "cc")
I believe that is a bit of overkill.
I see that empty asm("") is not effective. asm volatile("", ::: "memory") should be effective, AFAICT. You should be able to use existing barrier() macro.
https://elixir.bootlin.com/linux/latest/source/include/linux/compiler-gcc.h#...
Best regards, Pavel
From: Josh Poimboeuf jpoimboe@redhat.com
commit 71c95825289f585014fe9741b051d32a7a916680 upstream.
The unwind_state 'error' field is used to inform the reliable unwinding code that the stack trace can't be trusted. Set this field for all errors in __unwind_start().
Also, move the zeroing out of the unwind_state struct to before the ORC table initialization check, to prevent the caller from reading uninitialized data if the ORC table is corrupted.
Fixes: af085d9084b4 ("stacktrace/x86: add function for detecting reliable stack traces") Fixes: d3a09104018c ("x86/unwinder/orc: Dont bail on stack overflow") Fixes: 98d0c8ebf77e ("x86/unwind/orc: Prevent unwinding before ORC initialization") Reported-by: Pavel Machek pavel@denx.de Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Link: https://lkml.kernel.org/r/d6ac7215a84ca92b895fdd2e1aa546729417e6e6.158948727... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/x86/kernel/unwind_orc.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
--- a/arch/x86/kernel/unwind_orc.c +++ b/arch/x86/kernel/unwind_orc.c @@ -589,23 +589,23 @@ EXPORT_SYMBOL_GPL(unwind_next_frame); void __unwind_start(struct unwind_state *state, struct task_struct *task, struct pt_regs *regs, unsigned long *first_frame) { - if (!orc_init) - goto done; - memset(state, 0, sizeof(*state)); state->task = task;
+ if (!orc_init) + goto err; + /* * Refuse to unwind the stack of a task while it's executing on another * CPU. This check is racy, but that's ok: the unwinder has other * checks to prevent it from going off the rails. */ if (task_on_another_cpu(task)) - goto done; + goto err;
if (regs) { if (user_mode(regs)) - goto done; + goto the_end;
state->ip = regs->ip; state->sp = kernel_stack_pointer(regs); @@ -638,6 +638,7 @@ void __unwind_start(struct unwind_state * generate some kind of backtrace if this happens. */ void *next_page = (void *)PAGE_ALIGN((unsigned long)state->sp); + state->error = true; if (get_stack_info(next_page, state->task, &state->stack_info, &state->stack_mask)) return; @@ -663,8 +664,9 @@ void __unwind_start(struct unwind_state
return;
-done: +err: + state->error = true; +the_end: state->stack_info.type = STACK_TYPE_UNKNOWN; - return; } EXPORT_SYMBOL_GPL(__unwind_start);
From: Eric W. Biederman ebiederm@xmission.com
commit f87d1c9559164294040e58f5e3b74a162bf7c6e8 upstream.
I goofed when I added mm->user_ns support to would_dump. I missed the fact that in the case of binfmt_loader, binfmt_em86, binfmt_misc, and binfmt_script bprm->file is reassigned. Which made the move of would_dump from setup_new_exec to __do_execve_file before exec_binprm incorrect as it can result in would_dump running on the script instead of the interpreter of the script.
The net result is that the code stopped making unreadable interpreters undumpable. Which allows them to be ptraced and written to disk without special permissions. Oops.
The move was necessary because the call in set_new_exec was after bprm->mm was no longer valid.
To correct this mistake move the misplaced would_dump from __do_execve_file into flos_old_exec, before exec_mmap is called.
I tested and confirmed that without this fix I can attach with gdb to a script with an unreadable interpreter, and with this fix I can not.
Cc: stable@vger.kernel.org Fixes: f84df2a6f268 ("exec: Ensure mm->user_ns contains the execed files") Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/exec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/exec.c +++ b/fs/exec.c @@ -1269,6 +1269,8 @@ int flush_old_exec(struct linux_binprm * */ set_mm_exe_file(bprm->mm, bprm->file);
+ would_dump(bprm, bprm->file); + /* * Release all of the old mmap stuff */ @@ -1814,8 +1816,6 @@ static int __do_execve_file(int fd, stru if (retval < 0) goto out;
- would_dump(bprm, bprm->file); - retval = exec_binprm(bprm); if (retval < 0) goto out;
From: Justin Swartz justin.swartz@risingedge.co.za
commit cec9d101d70a3509da9bd2e601e0b242154ce616 upstream.
The following changes prevent the unrecoverable freezes and rcu_sched stall warnings experienced in each of my attempts to take advantage of lima.
Replace the COMPOSITE_NOGATE definition of aclk_gpu_pre with a COMPOSITE that retains the selection of HDMIPHY as the PLL source, but instead makes uses of the aclk_gpu PLL source gate and parent names defined by mux_pll_src_4plls_p rather than mux_aclk_gpu_pre_p.
Remove the now unused mux_aclk_gpu_pre_p and the four named but also unused definitions (cpll_gpu, gpll_gpu, hdmiphy_gpu and usb480m_gpu) of the aclk_gpu PLL source gate.
Use the correct gate offset for aclk_gpu and aclk_gpu_noc.
Fixes: 307a2e9ac524 ("clk: rockchip: add clock controller for rk3228") Cc: stable@vger.kernel.org Signed-off-by: Justin Swartz justin.swartz@risingedge.co.za [double-checked against SoC manual and added fixes tag] Link: https://lore.kernel.org/r/20200114162503.7548-1-justin.swartz@risingedge.co.... Signed-off-by: Heiko Stuebner heiko@sntech.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/clk/rockchip/clk-rk3228.c | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-)
--- a/drivers/clk/rockchip/clk-rk3228.c +++ b/drivers/clk/rockchip/clk-rk3228.c @@ -163,8 +163,6 @@ PNAME(mux_i2s_out_p) = { "i2s1_pre", "x PNAME(mux_i2s2_p) = { "i2s2_src", "i2s2_frac", "xin12m" }; PNAME(mux_sclk_spdif_p) = { "sclk_spdif_src", "spdif_frac", "xin12m" };
-PNAME(mux_aclk_gpu_pre_p) = { "cpll_gpu", "gpll_gpu", "hdmiphy_gpu", "usb480m_gpu" }; - PNAME(mux_uart0_p) = { "uart0_src", "uart0_frac", "xin24m" }; PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac", "xin24m" }; PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" }; @@ -475,16 +473,9 @@ static struct rockchip_clk_branch rk3228 RK2928_CLKSEL_CON(24), 6, 10, DFLAGS, RK2928_CLKGATE_CON(2), 8, GFLAGS),
- GATE(0, "cpll_gpu", "cpll", 0, - RK2928_CLKGATE_CON(3), 13, GFLAGS), - GATE(0, "gpll_gpu", "gpll", 0, - RK2928_CLKGATE_CON(3), 13, GFLAGS), - GATE(0, "hdmiphy_gpu", "hdmiphy", 0, - RK2928_CLKGATE_CON(3), 13, GFLAGS), - GATE(0, "usb480m_gpu", "usb480m", 0, + COMPOSITE(0, "aclk_gpu_pre", mux_pll_src_4plls_p, 0, + RK2928_CLKSEL_CON(34), 5, 2, MFLAGS, 0, 5, DFLAGS, RK2928_CLKGATE_CON(3), 13, GFLAGS), - COMPOSITE_NOGATE(0, "aclk_gpu_pre", mux_aclk_gpu_pre_p, 0, - RK2928_CLKSEL_CON(34), 5, 2, MFLAGS, 0, 5, DFLAGS),
COMPOSITE(SCLK_SPI0, "sclk_spi0", mux_pll_src_2plls_p, 0, RK2928_CLKSEL_CON(25), 8, 1, MFLAGS, 0, 7, DFLAGS, @@ -589,8 +580,8 @@ static struct rockchip_clk_branch rk3228 GATE(0, "pclk_peri_noc", "pclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(12), 2, GFLAGS),
/* PD_GPU */ - GATE(ACLK_GPU, "aclk_gpu", "aclk_gpu_pre", 0, RK2928_CLKGATE_CON(13), 14, GFLAGS), - GATE(0, "aclk_gpu_noc", "aclk_gpu_pre", 0, RK2928_CLKGATE_CON(13), 15, GFLAGS), + GATE(ACLK_GPU, "aclk_gpu", "aclk_gpu_pre", 0, RK2928_CLKGATE_CON(7), 14, GFLAGS), + GATE(0, "aclk_gpu_noc", "aclk_gpu_pre", 0, RK2928_CLKGATE_CON(7), 15, GFLAGS),
/* PD_BUS */ GATE(0, "sclk_initmem_mbist", "aclk_cpu", 0, RK2928_CLKGATE_CON(8), 1, GFLAGS),
From: John Stultz john.stultz@linaro.org
commit 00e21763f2c8cab21b7befa52996d1b18bde5c42 upstream.
The check for the HWO flag in dwc3_gadget_ep_reclaim_trb_sg() causes us to break out of the loop before we call dwc3_gadget_ep_reclaim_completed_trb(), which is what likely should be clearing the HWO flag.
This can cause odd behavior where we never reclaim all the trbs in the sg list, so we never call giveback on a usb req, and that will causes transfer stalls.
This effectively resovles the adb stalls seen on HiKey960 after userland changes started only using AIO in adbd.
Cc: YongQin Liu yongqin.liu@linaro.org Cc: Anurag Kumar Vulisha anurag.kumar.vulisha@xilinx.com Cc: Yang Fei fei.yang@intel.com Cc: Thinh Nguyen thinhn@synopsys.com Cc: Tejas Joglekar tejas.joglekar@synopsys.com Cc: Andrzej Pietrasiewicz andrzej.p@collabora.com Cc: Jack Pham jackp@codeaurora.org Cc: Josh Gao jmgao@google.com Cc: Todd Kjos tkjos@google.com Cc: Felipe Balbi balbi@kernel.org Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org #4.20+ Signed-off-by: John Stultz john.stultz@linaro.org Signed-off-by: Felipe Balbi balbi@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/dwc3/gadget.c | 3 --- 1 file changed, 3 deletions(-)
--- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2279,9 +2279,6 @@ static int dwc3_gadget_ep_reclaim_trb_sg for_each_sg(sg, s, pending, i) { trb = &dep->trb_pool[dep->trb_dequeue];
- if (trb->ctrl & DWC3_TRB_CTRL_HWO) - break; - req->sg = sg_next(s); req->num_pending_sgs--;
From: Christophe JAILLET christophe.jaillet@wanadoo.fr
commit ccaef7e6e354fb65758eaddd3eae8065a8b3e295 upstream.
'dev' is allocated in 'net2272_probe_init()'. It must be freed in the error handling path, as already done in the remove function (i.e. 'net2272_plat_remove()')
Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers") Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Signed-off-by: Felipe Balbi balbi@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/gadget/udc/net2272.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/usb/gadget/udc/net2272.c +++ b/drivers/usb/gadget/udc/net2272.c @@ -2653,6 +2653,8 @@ net2272_plat_probe(struct platform_devic err_req: release_mem_region(base, len); err: + kfree(dev); + return ret; }
From: Christophe JAILLET christophe.jaillet@wanadoo.fr
commit 19b94c1f9c9a16d41a8de3ccbdb8536cf1aecdbf upstream.
If 'usb_otg_descriptor_alloc()' fails, we must return an error code, not 0.
Fixes: 56023ce0fd70 ("usb: gadget: audio: allocate and init otg descriptor by otg capabilities") Reviewed-by: Peter Chen peter.chen@nxp.com Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Signed-off-by: Felipe Balbi balbi@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/gadget/legacy/audio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/legacy/audio.c +++ b/drivers/usb/gadget/legacy/audio.c @@ -300,8 +300,10 @@ static int audio_bind(struct usb_composi struct usb_descriptor_header *usb_desc;
usb_desc = usb_otg_descriptor_alloc(cdev->gadget); - if (!usb_desc) + if (!usb_desc) { + status = -ENOMEM; goto fail; + } usb_otg_descriptor_init(cdev->gadget, usb_desc); otg_desc[0] = usb_desc; otg_desc[1] = NULL;
From: Wei Yongjun weiyongjun1@huawei.com
commit e27d4b30b71c66986196d8a1eb93cba9f602904a upstream.
If 'usb_otg_descriptor_alloc()' fails, we must return a negative error code -ENOMEM, not 0.
Fixes: 1156e91dd7cc ("usb: gadget: ncm: allocate and init otg descriptor by otg capabilities") Reported-by: Hulk Robot hulkci@huawei.com Signed-off-by: Wei Yongjun weiyongjun1@huawei.com Signed-off-by: Felipe Balbi balbi@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/gadget/legacy/ncm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/legacy/ncm.c +++ b/drivers/usb/gadget/legacy/ncm.c @@ -156,8 +156,10 @@ static int gncm_bind(struct usb_composit struct usb_descriptor_header *usb_desc;
usb_desc = usb_otg_descriptor_alloc(gadget); - if (!usb_desc) + if (!usb_desc) { + status = -ENOMEM; goto fail; + } usb_otg_descriptor_init(gadget, usb_desc); otg_desc[0] = usb_desc; otg_desc[1] = NULL;
From: Wei Yongjun weiyongjun1@huawei.com
commit e8f7f9e3499a6d96f7f63a4818dc7d0f45a7783b upstream.
If 'usb_otg_descriptor_alloc()' fails, we must return a negative error code -ENOMEM, not 0.
Fixes: ab6796ae9833 ("usb: gadget: cdc2: allocate and init otg descriptor by otg capabilities") Reported-by: Hulk Robot hulkci@huawei.com Signed-off-by: Wei Yongjun weiyongjun1@huawei.com Signed-off-by: Felipe Balbi balbi@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/gadget/legacy/cdc2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/legacy/cdc2.c +++ b/drivers/usb/gadget/legacy/cdc2.c @@ -179,8 +179,10 @@ static int cdc_bind(struct usb_composite struct usb_descriptor_header *usb_desc;
usb_desc = usb_otg_descriptor_alloc(gadget); - if (!usb_desc) + if (!usb_desc) { + status = -ENOMEM; goto fail1; + } usb_otg_descriptor_init(gadget, usb_desc); otg_desc[0] = usb_desc; otg_desc[1] = NULL;
From: Kai-Heng Feng kai.heng.feng@canonical.com
commit f41224efcf8aafe80ea47ac870c5e32f3209ffc8 upstream.
This reverts commit 3b36b13d5e69d6f51ff1c55d1b404a74646c9757.
Enable power save node breaks some systems with ACL225. Revert the patch and use a platform specific quirk for the original issue isntead.
Fixes: 3b36b13d5e69 ("ALSA: hda/realtek: Fix pop noise on ALC225") BugLink: https://bugs.launchpad.net/bugs/1875916 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com Link: https://lore.kernel.org/r/20200503152449.22761-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/pci/hda/patch_realtek.c | 2 -- 1 file changed, 2 deletions(-)
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7827,8 +7827,6 @@ static int patch_alc269(struct hda_codec spec->gen.mixer_nid = 0; break; case 0x10ec0225: - codec->power_save_node = 1; - /* fall through */ case 0x10ec0295: case 0x10ec0299: spec->codec_variant = ALC269_TYPE_ALC225;
From: Marc Zyngier maz@kernel.org
commit 018d4671b9bbd4a5c55cf6eab3e1dbc70a50b66e upstream.
On failing to prepare or enable a clock, remove the core structure from the list it has been inserted as it is about to be freed.
This otherwise leads to random crashes when subsequent clocks get registered, during which parsing of the clock tree becomes adventurous.
Observed with QEMU's RPi-3 emulation.
Fixes: 12ead77432f2 ("clk: Don't try to enable critical clocks if prepare failed") Signed-off-by: Marc Zyngier maz@kernel.org Cc: Guenter Roeck linux@roeck-us.net Cc: Stephen Boyd sboyd@kernel.org Cc: Michael Turquette mturquette@baylibre.com Link: https://lkml.kernel.org/r/20200505140953.409430-1-maz@kernel.org Signed-off-by: Stephen Boyd sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/clk/clk.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -3105,6 +3105,9 @@ static int __clk_core_init(struct clk_co out: clk_pm_runtime_put(core); unlock: + if (ret) + hlist_del_init(&core->child_node); + clk_prepare_unlock();
if (!ret)
From: Chen-Yu Tsai wens@csie.org
commit 83b994129fb4c18a8460fd395864a28740e5e7fb upstream.
In some board device tree files, "rk805" was used for the RK805 PMIC's node name. However the policy for device trees is that generic names should be used.
Replace the "rk805" node name with the generic "pmic" name.
Fixes: 1e28037ec88e ("arm64: dts: rockchip: add rk805 node for rk3328-evb") Fixes: 955bebde057e ("arm64: dts: rockchip: add rk3328-rock64 board") Signed-off-by: Chen-Yu Tsai wens@csie.org Link: https://lore.kernel.org/r/20200327030414.5903-3-wens@kernel.org Signed-off-by: Heiko Stuebner heiko@sntech.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts @@ -92,7 +92,7 @@ &i2c1 { status = "okay";
- rk805: rk805@18 { + rk805: pmic@18 { compatible = "rockchip,rk805"; reg = <0x18>; interrupt-parent = <&gpio2>; --- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts @@ -112,7 +112,7 @@ &i2c1 { status = "okay";
- rk805: rk805@18 { + rk805: pmic@18 { compatible = "rockchip,rk805"; reg = <0x18>; interrupt-parent = <&gpio2>;
From: Chen-Yu Tsai wens@csie.org
commit 190c7f6fd43a776d4a6da1dac44408104649e9b7 upstream.
The device tree compiler complains that the dwc3 nodes have regs properties but no matching unit addresses.
Add the unit addresses to the device node name. While at it, also rename the nodes from "dwc3" to "usb", as guidelines require device nodes have generic names.
Fixes: 7144224f2c2b ("arm64: dts: rockchip: support dwc3 USB for rk3399") Signed-off-by: Chen-Yu Tsai wens@csie.org Link: https://lore.kernel.org/r/20200327030414.5903-7-wens@kernel.org Signed-off-by: Heiko Stuebner heiko@sntech.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -376,7 +376,7 @@ reset-names = "usb3-otg"; status = "disabled";
- usbdrd_dwc3_0: dwc3 { + usbdrd_dwc3_0: usb@fe800000 { compatible = "snps,dwc3"; reg = <0x0 0xfe800000 0x0 0x100000>; interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>; @@ -409,7 +409,7 @@ reset-names = "usb3-otg"; status = "disabled";
- usbdrd_dwc3_1: dwc3 { + usbdrd_dwc3_1: usb@fe900000 { compatible = "snps,dwc3"; reg = <0x0 0xfe900000 0x0 0x100000>; interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
From: Geert Uytterhoeven geert+renesas@glider.be
commit 0f739fdfe9e5ce668bd6d3210f310df282321837 upstream.
The R-Mobile APE6 Compare Match Timer 1 generates 8 interrupts, one for each channel, but currently only 1 is described. Fix this by adding the missing interrupts.
Fixes: f7b65230019b9dac ("ARM: shmobile: r8a73a4: Add CMT1 node") Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be Link: https://lore.kernel.org/r/20200408090926.25201-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/arm/boot/dts/r8a73a4.dtsi | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r8a73a4.dtsi +++ b/arch/arm/boot/dts/r8a73a4.dtsi @@ -131,7 +131,14 @@ cmt1: timer@e6130000 { compatible = "renesas,r8a73a4-cmt1", "renesas,rcar-gen2-cmt1"; reg = <0 0xe6130000 0 0x1004>; - interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; clocks = <&mstp3_clks R8A73A4_CLK_CMT1>; clock-names = "fck"; power-domains = <&pd_c5>;
From: Yoshihiro Shimoda yoshihiro.shimoda.uh@renesas.com
commit f4d71c6ea9e58c07dd4d02d09c5dd9bb780ec4b1 upstream.
Missing the renesas,ipmmu-main property on ipmmu_vip[01] nodes.
Fixes: 55697cbb44e4 ("arm64: dts: renesas: r8a779{65,80,90}: Add IPMMU devices nodes) Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda.uh@renesas.com Link: https://lore.kernel.org/r/1587108543-23786-1-git-send-email-yoshihiro.shimod... Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/arm64/boot/dts/renesas/r8a77980.dtsi | 2 ++ 1 file changed, 2 insertions(+)
--- a/arch/arm64/boot/dts/renesas/r8a77980.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77980.dtsi @@ -454,6 +454,7 @@ ipmmu_vip0: mmu@e7b00000 { compatible = "renesas,ipmmu-r8a77980"; reg = <0 0xe7b00000 0 0x1000>; + renesas,ipmmu-main = <&ipmmu_mm 4>; power-domains = <&sysc R8A77980_PD_ALWAYS_ON>; #iommu-cells = <1>; }; @@ -461,6 +462,7 @@ ipmmu_vip1: mmu@e7960000 { compatible = "renesas,ipmmu-r8a77980"; reg = <0 0xe7960000 0 0x1000>; + renesas,ipmmu-main = <&ipmmu_mm 11>; power-domains = <&sysc R8A77980_PD_ALWAYS_ON>; #iommu-cells = <1>; };
From: Geert Uytterhoeven geert+renesas@glider.be
commit e47cb97f153193d4b41ca8d48127da14513d54c7 upstream.
The Clock Pulse Generator (CPG) device node lacks the extal2 clock. This may lead to a failure registering the "r" clock, or to a wrong parent for the "usb24s" clock, depending on MD_CK2 pin configuration and boot loader CPG_USBCKCR register configuration.
This went unnoticed, as this does not affect the single upstream board configuration, which relies on the first clock input only.
Fixes: d9ffd583bf345e2e ("ARM: shmobile: r8a7740: add SoC clocks to DTS") Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be Reviewed-by: Ulrich Hecht uli+renesas@fpond.eu Link: https://lore.kernel.org/r/20200508095918.6061-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/arm/boot/dts/r8a7740.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r8a7740.dtsi +++ b/arch/arm/boot/dts/r8a7740.dtsi @@ -479,7 +479,7 @@ cpg_clocks: cpg_clocks@e6150000 { compatible = "renesas,r8a7740-cpg-clocks"; reg = <0xe6150000 0x10000>; - clocks = <&extal1_clk>, <&extalr_clk>; + clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>; #clock-cells = <1>; clock-output-names = "system", "pllc0", "pllc1", "pllc2", "r",
From: Jim Mattson jmattson@google.com
commit c4e0e4ab4cf3ec2b3f0b628ead108d677644ebd9 upstream.
Bank_num is a one-based count of banks, not a zero-based index. It overflows the allocated space only when strictly greater than KVM_MAX_MCE_BANKS.
Fixes: a9e38c3e01ad ("KVM: x86: Catch potential overrun in MCE setup") Signed-off-by: Jue Wang juew@google.com Signed-off-by: Jim Mattson jmattson@google.com Reviewed-by: Peter Shier pshier@google.com Message-Id: 20200511225616.19557-1-jmattson@google.com Reviewed-by: Vitaly Kuznetsov vkuznets@redhat.com Signed-off-by: Paolo Bonzini pbonzini@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3423,7 +3423,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce( unsigned bank_num = mcg_cap & 0xff, bank;
r = -EINVAL; - if (!bank_num || bank_num >= KVM_MAX_MCE_BANKS) + if (!bank_num || bank_num > KVM_MAX_MCE_BANKS) goto out; if (mcg_cap & ~(kvm_mce_cap_supported | 0xff | 0xff0000)) goto out;
From: Sergei Trofimovich slyfox@gentoo.org
commit b1112139a103b4b1101d0d2d72931f2d33d8c978 upstream.
gcc-10 will rename --param=allow-store-data-races=0 to -fno-allow-store-data-races.
The flag change happened at https://gcc.gnu.org/PR92046.
Signed-off-by: Sergei Trofimovich slyfox@gentoo.org Acked-by: Jiri Kosina jkosina@suse.cz Signed-off-by: Masahiro Yamada masahiroy@kernel.org Cc: Thomas Backlund tmb@mageia.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- Makefile | 1 + 1 file changed, 1 insertion(+)
--- a/Makefile +++ b/Makefile @@ -664,6 +664,7 @@ endif
# Tell gcc to never replace conditional load with a non-conditional one KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0) +KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
include scripts/Makefile.kcov include scripts/Makefile.gcc-plugins
On Mon, 18 May 2020 at 23:21, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.19.124 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 20 May 2020 17:32:42 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.124-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Summary ------------------------------------------------------------------------
kernel: 4.19.124-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: ff1170bc0ae95f29422b828165e36382a33b2dd3 git describe: v4.19.123-81-gff1170bc0ae9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.123-8...
No regressions (compared to build v4.19.123)
No fixes (compared to build v4.19.123)
Ran 31223 total tests in the following environments and test suites.
Environments -------------- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 - x86-kasan
Test Suites ----------- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kselftest/networking * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * perf * ltp-cve-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-syscalls-tests * network-basic-tests * v4l2-compliance * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-native/networking * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * kselftest-vsyscall-mode-none/networking
On 18/05/2020 18:36, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.124 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 20 May 2020 17:32:42 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.124-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
All tests are passing for Tegra.
I am having issues pulling the report, but looks good to me.
Cheers Jon
On 5/18/20 11:36 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.124 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 20 May 2020 17:32:42 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.124-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On 5/18/20 10:36 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.124 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 20 May 2020 17:32:42 +0000. Anything received after that time might be too late.
Build results: total: 155 pass: 155 fail: 0 Qemu test results: total: 420 pass: 420 fail: 0
Guenter
Hello Greg,
From: stable-owner@vger.kernel.org stable-owner@vger.kernel.org On Behalf Of Greg Kroah-Hartman Sent: 18 May 2020 18:36
This is the start of the stable review cycle for the 4.19.124 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
No build/boot issues seen for CIP configs for Linux 4.19.124-rc1 (ff1170bc0ae9).
Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/1472... GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master... Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=ff1170#ta...
Kind regards, Chris
Responses should be made by Wed, 20 May 2020 17:32:42 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch- 4.19.124-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.19.124-rc1
Sergei Trofimovich slyfox@gentoo.org Makefile: disallow data races on gcc-10 as well
Jim Mattson jmattson@google.com KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce
Geert Uytterhoeven geert+renesas@glider.be ARM: dts: r8a7740: Add missing extal2 to CPG node
Yoshihiro Shimoda yoshihiro.shimoda.uh@renesas.com arm64: dts: renesas: r8a77980: Fix IPMMU VIP[01] nodes
Geert Uytterhoeven geert+renesas@glider.be ARM: dts: r8a73a4: Add missing CMT1 interrupts
Chen-Yu Tsai wens@csie.org arm64: dts: rockchip: Rename dwc3 device nodes on rk3399 to make dtc happy
Chen-Yu Tsai wens@csie.org arm64: dts: rockchip: Replace RK805 PMIC node name with "pmic" on rk3328 boards
Marc Zyngier maz@kernel.org clk: Unlink clock if failed to prepare or enable
Kai-Heng Feng kai.heng.feng@canonical.com Revert "ALSA: hda/realtek: Fix pop noise on ALC225"
Wei Yongjun weiyongjun1@huawei.com usb: gadget: legacy: fix error return code in cdc_bind()
Wei Yongjun weiyongjun1@huawei.com usb: gadget: legacy: fix error return code in gncm_bind()
Christophe JAILLET christophe.jaillet@wanadoo.fr usb: gadget: audio: Fix a missing error return value in audio_bind()
Christophe JAILLET christophe.jaillet@wanadoo.fr usb: gadget: net2272: Fix a memory leak in an error handling path in 'net2272_plat_probe()'
John Stultz john.stultz@linaro.org dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()
Justin Swartz justin.swartz@risingedge.co.za clk: rockchip: fix incorrect configuration of rk3228 aclk_gpu* clocks
Eric W. Biederman ebiederm@xmission.com exec: Move would_dump into flush_old_exec
Josh Poimboeuf jpoimboe@redhat.com x86/unwind/orc: Fix error handling in __unwind_start()
Borislav Petkov bp@suse.de x86: Fix early boot crash on gcc-10, third try
Adam McCoy adam@forsedomani.com cifs: fix leaked reference on requeued write
Fabio Estevam festevam@gmail.com ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries
Kishon Vijay Abraham I kishon@ti.com ARM: dts: dra7: Fix bus_dma_limit for PCIe
Sriharsha Allenki sallenki@codeaurora.org usb: xhci: Fix NULL pointer dereference when enqueuing trbs from urb sg list
Kyungtae Kim kt0755@gmail.com USB: gadget: fix illegal array access in binding with UDC
Li Jun jun.li@nxp.com usb: host: xhci-plat: keep runtime active when removing host
Eugeniu Rosca erosca@de.adit-jv.com usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B
Jesus Ramos jesus-ramos@live.com ALSA: usb-audio: Add control message quirk delay for Kingston HyperX headset
Takashi Iwai tiwai@suse.de ALSA: rawmidi: Fix racy buffer resize under concurrent accesses
Takashi Iwai tiwai@suse.de ALSA: hda/realtek - Limit int mic boost for Thinkpad T530
Linus Torvalds torvalds@linux-foundation.org gcc-10: avoid shadowing standard library 'free()' in crypto
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'restrict' warning for now
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'stringop-overflow' warning for now
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'array-bounds' warning for now
Linus Torvalds torvalds@linux-foundation.org gcc-10: disable 'zero-length-bounds' warning for now
Linus Torvalds torvalds@linux-foundation.org Stop the ad-hoc games with -Wno-maybe-initialized
Masahiro Yamada yamada.masahiro@socionext.com kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
Linus Torvalds torvalds@linux-foundation.org gcc-10 warnings: fix low-hanging fruit
Jason Gunthorpe jgg@ziepe.ca pnp: Use list_for_each_entry() instead of open coding
Samu Nuutamo samu.nuutamo@vincit.fi hwmon: (da9052) Synchronize access with mfd
Jack Morgenstein jackm@dev.mellanox.co.il IB/mlx4: Test return value of calls to ib_get_cached_pkey
Stefano Brivio sbrivio@redhat.com netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()
Christoph Hellwig hch@lst.de arm64: fix the flush_icache_range arguments in machine_kexec
Arnd Bergmann arnd@arndb.de netfilter: conntrack: avoid gcc-10 zero-length-bounds warning
Dave Wysochanski dwysocha@redhat.com NFSv4: Fix fscache cookie aux_data to ensure change_attr is included
Arnd Bergmann arnd@arndb.de nfs: fscache: use timespec64 in inode auxdata
Dave Wysochanski dwysocha@redhat.com NFS: Fix fscache super_cookie index_key from changing after umount
Adrian Hunter adrian.hunter@intel.com mmc: block: Fix request completion in the CQE timeout path
Veerabhadrarao Badiganti vbadigan@codeaurora.org mmc: core: Check request type before completing the request
Dan Carpenter dan.carpenter@oracle.com i40iw: Fix error handling in i40iw_manage_arp_cache()
Grace Kao grace.kao@intel.com pinctrl: cherryview: Add missing spinlock usage in chv_gpio_irq_handler
Andy Shevchenko andriy.shevchenko@linux.intel.com pinctrl: baytrail: Enable pin configuration setting for GPIO chip
Andreas Gruenbacher agruenba@redhat.com gfs2: Another gfs2_walk_metadata fix
Kai-Heng Feng kai.heng.feng@canonical.com ALSA: hda/realtek - Fix S3 pop noise on Dell Wyse
Vasily Averin vvs@virtuozzo.com ipc/util.c: sysvipc_find_ipc() incorrectly updates position index
Vasily Averin vvs@virtuozzo.com drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()
Kai Vehmanen kai.vehmanen@linux.intel.com ALSA: hda/hdmi: fix race in monitor detection during probe
Chris Wilson chris@chris-wilson.co.uk cpufreq: intel_pstate: Only mention the BIOS disabling turbo mode once
Lubomir Rintel lkundrak@v3.sk dmaengine: mmp_tdma: Reset channel error on release
Madhuparna Bhowmik madhuparnabhowmik10@gmail.com dmaengine: pch_dma.c: Avoid data race between probe and irq handler
Ilie Halip ilie.halip@gmail.com riscv: fix vdso build with lld
Eric Dumazet edumazet@google.com tcp: fix SO_RCVLOWAT hangs with fat skbs
Kelly Littlepage kelly@onechronos.com net: tcp: fix rx timestamp behavior for tcp_recvmsg
Zefan Li lizefan@huawei.com netprio_cgroup: Fix unlimited memory leak of v2 cgroups
Paolo Abeni pabeni@redhat.com net: ipv4: really enforce backoff for redirects
Florian Fainelli f.fainelli@gmail.com net: dsa: loop: Add module soft dependency
Luo bin luobin9@huawei.com hinic: fix a bug of ndo_stop
Michael S. Tsirkin mst@redhat.com virtio_net: fix lockdep warning on 32 bit
Eric Dumazet edumazet@google.com tcp: fix error recovery in tcp_zerocopy_receive()
Maciej Żenczykowski maze@google.com Revert "ipv6: add mtu lock check in __ip6_rt_update_pmtu"
Guillaume Nault gnault@redhat.com pppoe: only process PADT targeted at local interfaces
Heiner Kallweit hkallweit1@gmail.com net: phy: fix aneg restart in phy_ethtool_set_eee
Paolo Abeni pabeni@redhat.com netlabel: cope with NULL catmap
Cong Wang xiyou.wangcong@gmail.com net: fix a potential recursive NETDEV_FEAT_CHANGE
Raul E Rangel rrangel@chromium.org mmc: sdhci-acpi: Add SDHCI_QUIRK2_BROKEN_64_BIT_DMA for AMDI0040
Wu Bo wubo40@huawei.com scsi: sg: add sg_remove_request in sg_write
Stefan Hajnoczi stefanha@redhat.com virtio-blk: handle block_device_operations callbacks after hot unplug
Arnd Bergmann arnd@arndb.de drop_monitor: work around gcc-10 stringop-overflow warning
Christophe JAILLET christophe.jaillet@wanadoo.fr net: moxa: Fix a potential double 'free_irq()'
Christophe JAILLET christophe.jaillet@wanadoo.fr net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'
Hugh Dickins hughd@google.com shmem: fix possible deadlocks on shmlock_user_lock
Florian Fainelli f.fainelli@gmail.com net: dsa: Do not make user port errors fatal
Diffstat:
Makefile | 25 ++++--- arch/arm/boot/dts/dra7.dtsi | 4 +- arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 4 +- arch/arm/boot/dts/r8a73a4.dtsi | 9 ++- arch/arm/boot/dts/r8a7740.dtsi | 2 +- arch/arm64/boot/dts/renesas/r8a77980.dtsi | 2 + arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 +- arch/arm64/kernel/machine_kexec.c | 1 + arch/riscv/kernel/vdso/Makefile | 6 +- arch/x86/include/asm/stackprotector.h | 7 +- arch/x86/kernel/smpboot.c | 8 +++ arch/x86/kernel/unwind_orc.c | 16 +++-- arch/x86/kvm/x86.c | 2 +- arch/x86/xen/smp_pv.c | 1 + crypto/lrw.c | 4 +- crypto/xts.c | 4 +- drivers/block/virtio_blk.c | 86 ++++++++++++++++++++--- drivers/clk/clk.c | 3 + drivers/clk/rockchip/clk-rk3228.c | 17 ++--- drivers/cpufreq/intel_pstate.c | 2 +- drivers/dma/mmp_tdma.c | 2 + drivers/dma/pch_dma.c | 2 +- drivers/gpu/drm/qxl/qxl_image.c | 3 +- drivers/hwmon/da9052-hwmon.c | 4 +- drivers/infiniband/hw/i40iw/i40iw_hw.c | 2 +- drivers/infiniband/hw/mlx4/qp.c | 14 +++- drivers/mmc/core/block.c | 3 +- drivers/mmc/core/queue.c | 3 +- drivers/mmc/host/sdhci-acpi.c | 10 +-- drivers/net/dsa/dsa_loop.c | 1 + drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 16 +++-- drivers/net/ethernet/huawei/hinic/hinic_main.c | 16 +---- drivers/net/ethernet/moxa/moxart_ether.c | 2 +- drivers/net/ethernet/natsemi/jazzsonic.c | 6 +- drivers/net/phy/phy.c | 8 ++- drivers/net/ppp/pppoe.c | 3 + drivers/net/virtio_net.c | 6 +- drivers/pinctrl/intel/pinctrl-baytrail.c | 1 + drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ++ drivers/scsi/sg.c | 4 +- drivers/usb/core/hub.c | 6 +- drivers/usb/dwc3/gadget.c | 3 - drivers/usb/gadget/configfs.c | 3 + drivers/usb/gadget/legacy/audio.c | 4 +- drivers/usb/gadget/legacy/cdc2.c | 4 +- drivers/usb/gadget/legacy/ncm.c | 4 +- drivers/usb/gadget/udc/net2272.c | 2 + drivers/usb/host/xhci-plat.c | 4 +- drivers/usb/host/xhci-ring.c | 4 +- fs/cifs/cifssmb.c | 2 +- fs/exec.c | 4 +- fs/gfs2/bmap.c | 16 +++-- fs/nfs/fscache-index.c | 6 +- fs/nfs/fscache.c | 31 ++++---- fs/nfs/fscache.h | 8 ++- include/linux/compiler.h | 6 ++ include/linux/fs.h | 2 +- include/linux/pnp.h | 29 +++----- include/linux/tty.h | 2 +- include/net/netfilter/nf_conntrack.h | 2 +- include/net/tcp.h | 13 ++++ include/sound/rawmidi.h | 1 + init/main.c | 2 + ipc/util.c | 12 ++-- mm/shmem.c | 7 +- net/core/dev.c | 4 +- net/core/drop_monitor.c | 11 +-- net/core/netprio_cgroup.c | 2 + net/dsa/dsa2.c | 2 +- net/ipv4/cipso_ipv4.c | 6 +- net/ipv4/route.c | 2 +- net/ipv4/tcp.c | 27 ++++--- net/ipv4/tcp_input.c | 3 +- net/ipv6/calipso.c | 3 +- net/ipv6/route.c | 6 +- net/netfilter/nf_conntrack_core.c | 4 +- net/netfilter/nft_set_rbtree.c | 17 +++-- net/netlabel/netlabel_kapi.c | 6 ++ sound/core/rawmidi.c | 31 ++++++-- sound/pci/hda/patch_hdmi.c | 2 + sound/pci/hda/patch_realtek.c | 28 +++++++- sound/usb/quirks.c | 9 +-- 84 files changed, 452 insertions(+), 209 deletions(-)
On Thu, May 21, 2020 at 07:49:42AM +0000, Chris Paterson wrote:
Hello Greg,
From: stable-owner@vger.kernel.org stable-owner@vger.kernel.org On Behalf Of Greg Kroah-Hartman Sent: 18 May 2020 18:36
This is the start of the stable review cycle for the 4.19.124 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
No build/boot issues seen for CIP configs for Linux 4.19.124-rc1 (ff1170bc0ae9).
Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/1472... GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master... Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=ff1170#ta...
Thanks for testing all of these and letting me know.
greg k-h
linux-stable-mirror@lists.linaro.org