2020-05-18 18:24:13

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 00/80] 4.19.124-rc1 review

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-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 <[email protected]>
Linux 4.19.124-rc1

Sergei Trofimovich <[email protected]>
Makefile: disallow data races on gcc-10 as well

Jim Mattson <[email protected]>
KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce

Geert Uytterhoeven <[email protected]>
ARM: dts: r8a7740: Add missing extal2 to CPG node

Yoshihiro Shimoda <[email protected]>
arm64: dts: renesas: r8a77980: Fix IPMMU VIP[01] nodes

Geert Uytterhoeven <[email protected]>
ARM: dts: r8a73a4: Add missing CMT1 interrupts

Chen-Yu Tsai <[email protected]>
arm64: dts: rockchip: Rename dwc3 device nodes on rk3399 to make dtc happy

Chen-Yu Tsai <[email protected]>
arm64: dts: rockchip: Replace RK805 PMIC node name with "pmic" on rk3328 boards

Marc Zyngier <[email protected]>
clk: Unlink clock if failed to prepare or enable

Kai-Heng Feng <[email protected]>
Revert "ALSA: hda/realtek: Fix pop noise on ALC225"

Wei Yongjun <[email protected]>
usb: gadget: legacy: fix error return code in cdc_bind()

Wei Yongjun <[email protected]>
usb: gadget: legacy: fix error return code in gncm_bind()

Christophe JAILLET <[email protected]>
usb: gadget: audio: Fix a missing error return value in audio_bind()

Christophe JAILLET <[email protected]>
usb: gadget: net2272: Fix a memory leak in an error handling path in 'net2272_plat_probe()'

John Stultz <[email protected]>
dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()

Justin Swartz <[email protected]>
clk: rockchip: fix incorrect configuration of rk3228 aclk_gpu* clocks

Eric W. Biederman <[email protected]>
exec: Move would_dump into flush_old_exec

Josh Poimboeuf <[email protected]>
x86/unwind/orc: Fix error handling in __unwind_start()

Borislav Petkov <[email protected]>
x86: Fix early boot crash on gcc-10, third try

Adam McCoy <[email protected]>
cifs: fix leaked reference on requeued write

Fabio Estevam <[email protected]>
ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries

Kishon Vijay Abraham I <[email protected]>
ARM: dts: dra7: Fix bus_dma_limit for PCIe

Sriharsha Allenki <[email protected]>
usb: xhci: Fix NULL pointer dereference when enqueuing trbs from urb sg list

Kyungtae Kim <[email protected]>
USB: gadget: fix illegal array access in binding with UDC

Li Jun <[email protected]>
usb: host: xhci-plat: keep runtime active when removing host

Eugeniu Rosca <[email protected]>
usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B

Jesus Ramos <[email protected]>
ALSA: usb-audio: Add control message quirk delay for Kingston HyperX headset

Takashi Iwai <[email protected]>
ALSA: rawmidi: Fix racy buffer resize under concurrent accesses

Takashi Iwai <[email protected]>
ALSA: hda/realtek - Limit int mic boost for Thinkpad T530

Linus Torvalds <[email protected]>
gcc-10: avoid shadowing standard library 'free()' in crypto

Linus Torvalds <[email protected]>
gcc-10: disable 'restrict' warning for now

Linus Torvalds <[email protected]>
gcc-10: disable 'stringop-overflow' warning for now

Linus Torvalds <[email protected]>
gcc-10: disable 'array-bounds' warning for now

Linus Torvalds <[email protected]>
gcc-10: disable 'zero-length-bounds' warning for now

Linus Torvalds <[email protected]>
Stop the ad-hoc games with -Wno-maybe-initialized

Masahiro Yamada <[email protected]>
kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig

Linus Torvalds <[email protected]>
gcc-10 warnings: fix low-hanging fruit

Jason Gunthorpe <[email protected]>
pnp: Use list_for_each_entry() instead of open coding

Samu Nuutamo <[email protected]>
hwmon: (da9052) Synchronize access with mfd

Jack Morgenstein <[email protected]>
IB/mlx4: Test return value of calls to ib_get_cached_pkey

Stefano Brivio <[email protected]>
netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

Christoph Hellwig <[email protected]>
arm64: fix the flush_icache_range arguments in machine_kexec

Arnd Bergmann <[email protected]>
netfilter: conntrack: avoid gcc-10 zero-length-bounds warning

Dave Wysochanski <[email protected]>
NFSv4: Fix fscache cookie aux_data to ensure change_attr is included

Arnd Bergmann <[email protected]>
nfs: fscache: use timespec64 in inode auxdata

Dave Wysochanski <[email protected]>
NFS: Fix fscache super_cookie index_key from changing after umount

Adrian Hunter <[email protected]>
mmc: block: Fix request completion in the CQE timeout path

Veerabhadrarao Badiganti <[email protected]>
mmc: core: Check request type before completing the request

Dan Carpenter <[email protected]>
i40iw: Fix error handling in i40iw_manage_arp_cache()

Grace Kao <[email protected]>
pinctrl: cherryview: Add missing spinlock usage in chv_gpio_irq_handler

Andy Shevchenko <[email protected]>
pinctrl: baytrail: Enable pin configuration setting for GPIO chip

Andreas Gruenbacher <[email protected]>
gfs2: Another gfs2_walk_metadata fix

Kai-Heng Feng <[email protected]>
ALSA: hda/realtek - Fix S3 pop noise on Dell Wyse

Vasily Averin <[email protected]>
ipc/util.c: sysvipc_find_ipc() incorrectly updates position index

Vasily Averin <[email protected]>
drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()

Kai Vehmanen <[email protected]>
ALSA: hda/hdmi: fix race in monitor detection during probe

Chris Wilson <[email protected]>
cpufreq: intel_pstate: Only mention the BIOS disabling turbo mode once

Lubomir Rintel <[email protected]>
dmaengine: mmp_tdma: Reset channel error on release

Madhuparna Bhowmik <[email protected]>
dmaengine: pch_dma.c: Avoid data race between probe and irq handler

Ilie Halip <[email protected]>
riscv: fix vdso build with lld

Eric Dumazet <[email protected]>
tcp: fix SO_RCVLOWAT hangs with fat skbs

Kelly Littlepage <[email protected]>
net: tcp: fix rx timestamp behavior for tcp_recvmsg

Zefan Li <[email protected]>
netprio_cgroup: Fix unlimited memory leak of v2 cgroups

Paolo Abeni <[email protected]>
net: ipv4: really enforce backoff for redirects

Florian Fainelli <[email protected]>
net: dsa: loop: Add module soft dependency

Luo bin <[email protected]>
hinic: fix a bug of ndo_stop

Michael S. Tsirkin <[email protected]>
virtio_net: fix lockdep warning on 32 bit

Eric Dumazet <[email protected]>
tcp: fix error recovery in tcp_zerocopy_receive()

Maciej Żenczykowski <[email protected]>
Revert "ipv6: add mtu lock check in __ip6_rt_update_pmtu"

Guillaume Nault <[email protected]>
pppoe: only process PADT targeted at local interfaces

Heiner Kallweit <[email protected]>
net: phy: fix aneg restart in phy_ethtool_set_eee

Paolo Abeni <[email protected]>
netlabel: cope with NULL catmap

Cong Wang <[email protected]>
net: fix a potential recursive NETDEV_FEAT_CHANGE

Raul E Rangel <[email protected]>
mmc: sdhci-acpi: Add SDHCI_QUIRK2_BROKEN_64_BIT_DMA for AMDI0040

Wu Bo <[email protected]>
scsi: sg: add sg_remove_request in sg_write

Stefan Hajnoczi <[email protected]>
virtio-blk: handle block_device_operations callbacks after hot unplug

Arnd Bergmann <[email protected]>
drop_monitor: work around gcc-10 stringop-overflow warning

Christophe JAILLET <[email protected]>
net: moxa: Fix a potential double 'free_irq()'

Christophe JAILLET <[email protected]>
net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'

Hugh Dickins <[email protected]>
shmem: fix possible deadlocks on shmlock_user_lock

Florian Fainelli <[email protected]>
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(-)



2020-05-18 18:24:20

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 02/80] shmem: fix possible deadlocks on shmlock_user_lock

From: Hugh Dickins <[email protected]>

[ 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: [email protected]
Reported-by: [email protected]
Signed-off-by: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Acked-by: Yang Shi <[email protected]>
Cc: Yang Shi <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Link: https://lore.kernel.org/lkml/[email protected]/
Link: https://lore.kernel.org/lkml/[email protected]/
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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;
}

--
2.20.1



2020-05-18 18:24:30

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 21/80] tcp: fix SO_RCVLOWAT hangs with fat skbs

From: Eric Dumazet <[email protected]>

[ 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 <[email protected]>
Acked-by: Soheil Hassas Yeganeh <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);


2020-05-18 18:24:36

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 18/80] net: ipv4: really enforce backoff for redirects

From: Paolo Abeni <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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)))) {


2020-05-18 18:24:38

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 67/80] dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()

From: John Stultz <[email protected]>

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 <[email protected]>
Cc: Anurag Kumar Vulisha <[email protected]>
Cc: Yang Fei <[email protected]>
Cc: Thinh Nguyen <[email protected]>
Cc: Tejas Joglekar <[email protected]>
Cc: Andrzej Pietrasiewicz <[email protected]>
Cc: Jack Pham <[email protected]>
Cc: Josh Gao <[email protected]>
Cc: Todd Kjos <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
Cc: [email protected] #4.20+
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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--;



2020-05-18 18:24:39

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 09/80] net: fix a potential recursive NETDEV_FEAT_CHANGE

From: Cong Wang <[email protected]>

[ 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: [email protected]
Reported-by: [email protected]
Cc: Jarod Wilson <[email protected]>
Cc: Nikolay Aleksandrov <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Jann Horn <[email protected]>
Reviewed-by: Jay Vosburgh <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Acked-by: Nikolay Aleksandrov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
}
}
}


2020-05-18 18:24:40

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 04/80] net: moxa: Fix a potential double free_irq()

From: Christophe JAILLET <[email protected]>

[ 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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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);

--
2.20.1



2020-05-18 18:24:44

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 14/80] tcp: fix error recovery in tcp_zerocopy_receive()

From: Eric Dumazet <[email protected]>

[ 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 <[email protected]>
Reported-by: syzbot <[email protected]>
Acked-by: Soheil Hassas Yeganeh <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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(&current->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(&current->mm->mmap_sem);
+ return -EINVAL;
+ }
zc->length = min_t(unsigned long, zc->length, vma->vm_end - address);

tp = tcp_sk(sk);


2020-05-18 18:25:35

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 48/80] gcc-10: disable zero-length-bounds warning for now

From: Linus Torvalds <[email protected]>

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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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)



2020-05-18 18:25:35

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 26/80] ALSA: hda/hdmi: fix race in monitor detection during probe

From: Kai Vehmanen <[email protected]>

[ 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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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);
}

--
2.20.1



2020-05-18 18:25:51

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 30/80] gfs2: Another gfs2_walk_metadata fix

From: Andreas Gruenbacher <[email protected]>

[ 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: [email protected] # v5.3+
Signed-off-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Bob Peterson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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;
}

--
2.20.1



2020-05-18 18:26:17

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 05/80] drop_monitor: work around gcc-10 stringop-overflow warning

From: Arnd Bergmann <[email protected]>

[ 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 <[email protected]>
Acked-by: Neil Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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)) {
--
2.20.1



2020-05-18 19:17:39

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 16/80] hinic: fix a bug of ndo_stop

From: Luo bin <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);


2020-05-18 19:17:47

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 19/80] netprio_cgroup: Fix unlimited memory leak of v2 cgroups

From: Zefan Li <[email protected]>

[ 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 <[email protected]>
Tested-by: Yang Yingliang <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;



2020-05-18 19:17:57

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 20/80] net: tcp: fix rx timestamp behavior for tcp_recvmsg

From: Kelly Littlepage <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Iris Liu <[email protected]>
Signed-off-by: Kelly Littlepage <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Acked-by: Soheil Hassas Yeganeh <[email protected]>
Acked-by: Willem de Bruijn <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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))


2020-05-18 19:19:08

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 33/80] i40iw: Fix error handling in i40iw_manage_arp_cache()

From: Dan Carpenter <[email protected]>

[ 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 <[email protected]>
Acked-by: Shiraz Saleem <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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)
--
2.20.1



2020-05-18 19:19:16

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 38/80] NFSv4: Fix fscache cookie aux_data to ensure change_attr is included

From: Dave Wysochanski <[email protected]>

[ 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 <[email protected]>
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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);
--
2.20.1



2020-05-18 19:19:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

From: Stefano Brivio <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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;
--
2.20.1



2020-05-18 19:22:19

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 69/80] usb: gadget: audio: Fix a missing error return value in audio_bind()

From: Christophe JAILLET <[email protected]>

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 <[email protected]>
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;


2020-05-18 21:15:31

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 02/80] shmem: fix possible deadlocks on shmlock_user_lock

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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (1.07 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments

2020-05-18 23:43:56

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 22/80] riscv: fix vdso build with lld

From: Ilie Halip <[email protected]>

[ 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 <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Ilie Halip <[email protected]>
Reviewed-by: Fangrui Song <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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)

--
2.20.1



2020-05-18 23:44:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 53/80] ALSA: hda/realtek - Limit int mic boost for Thinkpad T530

From: Takashi Iwai <[email protected]>

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: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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"},


2020-05-18 23:44:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 54/80] ALSA: rawmidi: Fix racy buffer resize under concurrent accesses

From: Takashi Iwai <[email protected]>

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 <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/CAFcO6XMWpUVK_yzzCpp8_XP7+=oUpQvuBeCbMffEDkpe8jWrfg@mail.gmail.com
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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);


2020-05-18 23:44:08

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 60/80] ARM: dts: dra7: Fix bus_dma_limit for PCIe

From: Kishon Vijay Abraham I <[email protected]>

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: [email protected]
Signed-off-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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>;


2020-05-18 23:44:16

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 77/80] arm64: dts: renesas: r8a77980: Fix IPMMU VIP[01] nodes

From: Yoshihiro Shimoda <[email protected]>

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 <[email protected]>
Link: https://lore.kernel.org/r/1587108543-23786-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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>;
};


2020-05-18 23:44:17

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 80/80] Makefile: disallow data races on gcc-10 as well

From: Sergei Trofimovich <[email protected]>

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 <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Cc: Thomas Backlund <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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


2020-05-18 23:44:18

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 72/80] Revert "ALSA: hda/realtek: Fix pop noise on ALC225"

From: Kai-Heng Feng <[email protected]>

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;


2020-05-18 23:47:00

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 62/80] cifs: fix leaked reference on requeued write

From: Adam McCoy <[email protected]>

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 <[email protected]>
Signed-off-by: Steve French <[email protected]>
CC: Stable <[email protected]>
Reviewed-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;


2020-05-19 01:14:59

by Hugh Dickins

[permalink] [raw]
Subject: Re: [PATCH 4.19 02/80] shmem: fix possible deadlocks on shmlock_user_lock

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

2020-05-19 05:54:02

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 02/80] shmem: fix possible deadlocks on shmlock_user_lock

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

2020-05-19 07:37:48

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/80] 4.19.124-rc1 review

On Mon, 18 May 2020 at 23:21, Greg Kroah-Hartman
<[email protected]> 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-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

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-81-gff1170bc0ae9

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

--
Linaro LKFT
https://lkft.linaro.org

2020-05-19 12:08:42

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

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

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (726.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2020-05-19 12:13:59

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/80] 4.19.124-rc1 review


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-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

All tests are passing for Tegra.

I am having issues pulling the report, but looks good to me.

Cheers
Jon

--
nvpublic

2020-05-19 12:16:04

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

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

2020-05-19 12:21:34

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

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
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (1.47 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments

2020-05-19 12:53:27

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

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

2020-05-19 13:55:42

by Stefano Brivio

[permalink] [raw]
Subject: Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

On Tue, 19 May 2020 14:51:13 +0200
Greg Kroah-Hartman <[email protected]> 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 <[email protected]>).

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>.

--
Stefano

2020-05-19 14:10:27

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

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 <[email protected]> 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 <[email protected]>).
>
> 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

2020-05-19 15:03:10

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/80] 4.19.124-rc1 review

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-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
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

2020-05-19 16:33:39

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/80] 4.19.124-rc1 review

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

2020-05-21 07:52:02

by Chris Paterson

[permalink] [raw]
Subject: RE: [PATCH 4.19 00/80] 4.19.124-rc1 review

Hello Greg,

> From: [email protected] <[email protected]> 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/147257412
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=ff1170#table

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 <[email protected]>
> Linux 4.19.124-rc1
>
> Sergei Trofimovich <[email protected]>
> Makefile: disallow data races on gcc-10 as well
>
> Jim Mattson <[email protected]>
> KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce
>
> Geert Uytterhoeven <[email protected]>
> ARM: dts: r8a7740: Add missing extal2 to CPG node
>
> Yoshihiro Shimoda <[email protected]>
> arm64: dts: renesas: r8a77980: Fix IPMMU VIP[01] nodes
>
> Geert Uytterhoeven <[email protected]>
> ARM: dts: r8a73a4: Add missing CMT1 interrupts
>
> Chen-Yu Tsai <[email protected]>
> arm64: dts: rockchip: Rename dwc3 device nodes on rk3399 to make dtc
> happy
>
> Chen-Yu Tsai <[email protected]>
> arm64: dts: rockchip: Replace RK805 PMIC node name with "pmic" on rk3328
> boards
>
> Marc Zyngier <[email protected]>
> clk: Unlink clock if failed to prepare or enable
>
> Kai-Heng Feng <[email protected]>
> Revert "ALSA: hda/realtek: Fix pop noise on ALC225"
>
> Wei Yongjun <[email protected]>
> usb: gadget: legacy: fix error return code in cdc_bind()
>
> Wei Yongjun <[email protected]>
> usb: gadget: legacy: fix error return code in gncm_bind()
>
> Christophe JAILLET <[email protected]>
> usb: gadget: audio: Fix a missing error return value in audio_bind()
>
> Christophe JAILLET <[email protected]>
> usb: gadget: net2272: Fix a memory leak in an error handling path in
> 'net2272_plat_probe()'
>
> John Stultz <[email protected]>
> dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()
>
> Justin Swartz <[email protected]>
> clk: rockchip: fix incorrect configuration of rk3228 aclk_gpu* clocks
>
> Eric W. Biederman <[email protected]>
> exec: Move would_dump into flush_old_exec
>
> Josh Poimboeuf <[email protected]>
> x86/unwind/orc: Fix error handling in __unwind_start()
>
> Borislav Petkov <[email protected]>
> x86: Fix early boot crash on gcc-10, third try
>
> Adam McCoy <[email protected]>
> cifs: fix leaked reference on requeued write
>
> Fabio Estevam <[email protected]>
> ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries
>
> Kishon Vijay Abraham I <[email protected]>
> ARM: dts: dra7: Fix bus_dma_limit for PCIe
>
> Sriharsha Allenki <[email protected]>
> usb: xhci: Fix NULL pointer dereference when enqueuing trbs from urb sg list
>
> Kyungtae Kim <[email protected]>
> USB: gadget: fix illegal array access in binding with UDC
>
> Li Jun <[email protected]>
> usb: host: xhci-plat: keep runtime active when removing host
>
> Eugeniu Rosca <[email protected]>
> usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B
>
> Jesus Ramos <[email protected]>
> ALSA: usb-audio: Add control message quirk delay for Kingston HyperX
> headset
>
> Takashi Iwai <[email protected]>
> ALSA: rawmidi: Fix racy buffer resize under concurrent accesses
>
> Takashi Iwai <[email protected]>
> ALSA: hda/realtek - Limit int mic boost for Thinkpad T530
>
> Linus Torvalds <[email protected]>
> gcc-10: avoid shadowing standard library 'free()' in crypto
>
> Linus Torvalds <[email protected]>
> gcc-10: disable 'restrict' warning for now
>
> Linus Torvalds <[email protected]>
> gcc-10: disable 'stringop-overflow' warning for now
>
> Linus Torvalds <[email protected]>
> gcc-10: disable 'array-bounds' warning for now
>
> Linus Torvalds <[email protected]>
> gcc-10: disable 'zero-length-bounds' warning for now
>
> Linus Torvalds <[email protected]>
> Stop the ad-hoc games with -Wno-maybe-initialized
>
> Masahiro Yamada <[email protected]>
> kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
>
> Linus Torvalds <[email protected]>
> gcc-10 warnings: fix low-hanging fruit
>
> Jason Gunthorpe <[email protected]>
> pnp: Use list_for_each_entry() instead of open coding
>
> Samu Nuutamo <[email protected]>
> hwmon: (da9052) Synchronize access with mfd
>
> Jack Morgenstein <[email protected]>
> IB/mlx4: Test return value of calls to ib_get_cached_pkey
>
> Stefano Brivio <[email protected]>
> netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()
>
> Christoph Hellwig <[email protected]>
> arm64: fix the flush_icache_range arguments in machine_kexec
>
> Arnd Bergmann <[email protected]>
> netfilter: conntrack: avoid gcc-10 zero-length-bounds warning
>
> Dave Wysochanski <[email protected]>
> NFSv4: Fix fscache cookie aux_data to ensure change_attr is included
>
> Arnd Bergmann <[email protected]>
> nfs: fscache: use timespec64 in inode auxdata
>
> Dave Wysochanski <[email protected]>
> NFS: Fix fscache super_cookie index_key from changing after umount
>
> Adrian Hunter <[email protected]>
> mmc: block: Fix request completion in the CQE timeout path
>
> Veerabhadrarao Badiganti <[email protected]>
> mmc: core: Check request type before completing the request
>
> Dan Carpenter <[email protected]>
> i40iw: Fix error handling in i40iw_manage_arp_cache()
>
> Grace Kao <[email protected]>
> pinctrl: cherryview: Add missing spinlock usage in chv_gpio_irq_handler
>
> Andy Shevchenko <[email protected]>
> pinctrl: baytrail: Enable pin configuration setting for GPIO chip
>
> Andreas Gruenbacher <[email protected]>
> gfs2: Another gfs2_walk_metadata fix
>
> Kai-Heng Feng <[email protected]>
> ALSA: hda/realtek - Fix S3 pop noise on Dell Wyse
>
> Vasily Averin <[email protected]>
> ipc/util.c: sysvipc_find_ipc() incorrectly updates position index
>
> Vasily Averin <[email protected]>
> drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()
>
> Kai Vehmanen <[email protected]>
> ALSA: hda/hdmi: fix race in monitor detection during probe
>
> Chris Wilson <[email protected]>
> cpufreq: intel_pstate: Only mention the BIOS disabling turbo mode once
>
> Lubomir Rintel <[email protected]>
> dmaengine: mmp_tdma: Reset channel error on release
>
> Madhuparna Bhowmik <[email protected]>
> dmaengine: pch_dma.c: Avoid data race between probe and irq handler
>
> Ilie Halip <[email protected]>
> riscv: fix vdso build with lld
>
> Eric Dumazet <[email protected]>
> tcp: fix SO_RCVLOWAT hangs with fat skbs
>
> Kelly Littlepage <[email protected]>
> net: tcp: fix rx timestamp behavior for tcp_recvmsg
>
> Zefan Li <[email protected]>
> netprio_cgroup: Fix unlimited memory leak of v2 cgroups
>
> Paolo Abeni <[email protected]>
> net: ipv4: really enforce backoff for redirects
>
> Florian Fainelli <[email protected]>
> net: dsa: loop: Add module soft dependency
>
> Luo bin <[email protected]>
> hinic: fix a bug of ndo_stop
>
> Michael S. Tsirkin <[email protected]>
> virtio_net: fix lockdep warning on 32 bit
>
> Eric Dumazet <[email protected]>
> tcp: fix error recovery in tcp_zerocopy_receive()
>
> Maciej Żenczykowski <[email protected]>
> Revert "ipv6: add mtu lock check in __ip6_rt_update_pmtu"
>
> Guillaume Nault <[email protected]>
> pppoe: only process PADT targeted at local interfaces
>
> Heiner Kallweit <[email protected]>
> net: phy: fix aneg restart in phy_ethtool_set_eee
>
> Paolo Abeni <[email protected]>
> netlabel: cope with NULL catmap
>
> Cong Wang <[email protected]>
> net: fix a potential recursive NETDEV_FEAT_CHANGE
>
> Raul E Rangel <[email protected]>
> mmc: sdhci-acpi: Add SDHCI_QUIRK2_BROKEN_64_BIT_DMA for AMDI0040
>
> Wu Bo <[email protected]>
> scsi: sg: add sg_remove_request in sg_write
>
> Stefan Hajnoczi <[email protected]>
> virtio-blk: handle block_device_operations callbacks after hot unplug
>
> Arnd Bergmann <[email protected]>
> drop_monitor: work around gcc-10 stringop-overflow warning
>
> Christophe JAILLET <[email protected]>
> net: moxa: Fix a potential double 'free_irq()'
>
> Christophe JAILLET <[email protected]>
> net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'
>
> Hugh Dickins <[email protected]>
> shmem: fix possible deadlocks on shmlock_user_lock
>
> Florian Fainelli <[email protected]>
> 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(-)
>

2020-05-21 08:21:58

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/80] 4.19.124-rc1 review

On Thu, May 21, 2020 at 07:49:42AM +0000, Chris Paterson wrote:
> Hello Greg,
>
> > From: [email protected] <[email protected]> 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/147257412
> GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
> Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=ff1170#table

Thanks for testing all of these and letting me know.

greg k-h