2022-07-27 18:26:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 00/37] 4.14.290-rc1 review

This is the start of the stable review cycle for the 4.14.290 release.
There are 37 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 Fri, 29 Jul 2022 16:09:50 +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.14.290-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.14.290-rc1

Jeffrey Hugo <[email protected]>
PCI: hv: Fix interrupt mapping for multi-MSI

Jeffrey Hugo <[email protected]>
PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()

Jeffrey Hugo <[email protected]>
PCI: hv: Fix hv_arch_irq_unmask() for multi-MSI

Jeffrey Hugo <[email protected]>
PCI: hv: Fix multi-MSI to allow more than one MSI vector

Jose Alonso <[email protected]>
net: usb: ax88179_178a needs FLAG_SEND_ZLP

Jiri Slaby <[email protected]>
tty: use new tty_insert_flip_string_and_push_buffer() in pty_write()

Jiri Slaby <[email protected]>
tty: extract tty_flip_buffer_commit() from tty_flip_buffer_push()

Jiri Slaby <[email protected]>
tty: drop tty_schedule_flip()

Jiri Slaby <[email protected]>
tty: the rest, stop using tty_schedule_flip()

Jiri Slaby <[email protected]>
tty: drivers/tty/, stop using tty_schedule_flip()

Luiz Augusto von Dentz <[email protected]>
Bluetooth: Fix bt_skb_sendmmsg not allocating partial chunks

Luiz Augusto von Dentz <[email protected]>
Bluetooth: SCO: Fix sco_send_frame returning skb->len

Luiz Augusto von Dentz <[email protected]>
Bluetooth: Fix passing NULL to PTR_ERR

Luiz Augusto von Dentz <[email protected]>
Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg

Luiz Augusto von Dentz <[email protected]>
Bluetooth: SCO: Replace use of memcpy_from_msg with bt_skb_sendmsg

Luiz Augusto von Dentz <[email protected]>
Bluetooth: Add bt_skb_sendmmsg helper

Luiz Augusto von Dentz <[email protected]>
Bluetooth: Add bt_skb_sendmsg helper

Takashi Iwai <[email protected]>
ALSA: memalloc: Align buffer allocations in page size

Xiaomeng Tong <[email protected]>
tilcdc: tilcdc_external: fix an incorrect NULL check on list iterator

Jyri Sarha <[email protected]>
drm/tilcdc: Remove obsolete crtc_mode_valid() hack

Eric Dumazet <[email protected]>
bpf: Make sure mac_header was set before using it

Wang Cheng <[email protected]>
mm/mempolicy: fix uninit-value in mpol_rebind_policy()

Jason A. Donenfeld <[email protected]>
Revert "Revert "char/random: silence a lockdep splat with printk()""

Hristo Venev <[email protected]>
be2net: Fix buffer overflow in be_get_module_eeprom

Kuniyuki Iwashima <[email protected]>
tcp: Fix a data-race around sysctl_tcp_notsent_lowat.

Kuniyuki Iwashima <[email protected]>
igmp: Fix a data-race around sysctl_igmp_max_memberships.

Kuniyuki Iwashima <[email protected]>
igmp: Fix data-races around sysctl_igmp_llm_reports.

Junxiao Chang <[email protected]>
net: stmmac: fix dma queue left shift overflow issue

Robert Hancock <[email protected]>
i2c: cadence: Change large transfer count reset logic to be unconditional

Kuniyuki Iwashima <[email protected]>
tcp: Fix a data-race around sysctl_tcp_probe_interval.

Kuniyuki Iwashima <[email protected]>
tcp: Fix a data-race around sysctl_tcp_probe_threshold.

Kuniyuki Iwashima <[email protected]>
tcp/dccp: Fix a data-race around sysctl_tcp_fwmark_accept.

Kuniyuki Iwashima <[email protected]>
ip: Fix a data-race around sysctl_fwmark_reflect.

Peter Zijlstra <[email protected]>
perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()

Miaoqian Lin <[email protected]>
power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe

Hangyu Hua <[email protected]>
xfrm: xfrm_policy: fix a possible double xfrm_pols_put() in xfrm_bundle_lookup()

Demi Marie Obenour <[email protected]>
xen/gntdev: Ignore failure to unmap INVALID_GRANT_HANDLE


-------------

Diffstat:

Makefile | 4 +-
arch/alpha/kernel/srmcons.c | 2 +-
drivers/char/random.c | 4 +-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 28 +++---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 -
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 -
drivers/gpu/drm/tilcdc/tilcdc_external.c | 96 +++-----------------
drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 -
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 9 --
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 9 --
drivers/i2c/busses/i2c-cadence.c | 30 ++-----
drivers/net/ethernet/emulex/benet/be_cmds.c | 10 +--
drivers/net/ethernet/emulex/benet/be_cmds.h | 2 +-
drivers/net/ethernet/emulex/benet/be_ethtool.c | 31 ++++---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 3 +
drivers/net/usb/ax88179_178a.c | 16 ++--
drivers/pci/host/pci-hyperv.c | 101 ++++++++++++++++++----
drivers/power/reset/arm-versatile-reboot.c | 1 +
drivers/s390/char/keyboard.h | 4 +-
drivers/staging/speakup/spk_ttyio.c | 4 +-
drivers/tty/cyclades.c | 6 +-
drivers/tty/goldfish.c | 2 +-
drivers/tty/moxa.c | 4 +-
drivers/tty/pty.c | 14 +--
drivers/tty/serial/lpc32xx_hs.c | 2 +-
drivers/tty/tty_buffer.c | 66 +++++++++-----
drivers/tty/vt/keyboard.c | 6 +-
drivers/tty/vt/vt.c | 2 +-
drivers/xen/gntdev.c | 3 +-
include/linux/tty_flip.h | 4 +-
include/net/bluetooth/bluetooth.h | 65 ++++++++++++++
include/net/inet_sock.h | 3 +-
include/net/ip.h | 2 +-
include/net/tcp.h | 2 +-
kernel/bpf/core.c | 8 +-
kernel/events/core.c | 45 +++++++---
mm/mempolicy.c | 2 +-
net/bluetooth/rfcomm/core.c | 50 +++++++++--
net/bluetooth/rfcomm/sock.c | 46 +++-------
net/bluetooth/sco.c | 30 +++----
net/ipv4/igmp.c | 23 +++--
net/ipv4/tcp_output.c | 4 +-
net/xfrm/xfrm_policy.c | 5 +-
sound/core/memalloc.c | 1 +
44 files changed, 410 insertions(+), 343 deletions(-)



2022-07-27 18:27:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 15/37] Revert "Revert "char/random: silence a lockdep splat with printk()""

From: "Jason A. Donenfeld" <[email protected]>

In 2019, Sergey fixed a lockdep splat with 15341b1dd409 ("char/random:
silence a lockdep splat with printk()"), but that got reverted soon
after from 4.19 because back then it apparently caused various problems.
But the issue it was fixing is still there, and more generally, many
patches turning printk() into printk_deferred() have landed since,
making me suspect it's okay to try this out again.

This should fix the following deadlock found by the kernel test robot:

[ 18.287691] WARNING: possible circular locking dependency detected
[ 18.287692] 4.19.248-00165-g3d1f971aa81f #1 Not tainted
[ 18.287693] ------------------------------------------------------
[ 18.287712] stop/202 is trying to acquire lock:
[ 18.287713] (ptrval) (console_owner){..-.}, at: console_unlock (??:?)
[ 18.287717]
[ 18.287718] but task is already holding lock:
[ 18.287718] (ptrval) (&(&port->lock)->rlock){-...}, at: pty_write (pty.c:?)
[ 18.287722]
[ 18.287722] which lock already depends on the new lock.
[ 18.287723]
[ 18.287724]
[ 18.287725] the existing dependency chain (in reverse order) is:
[ 18.287725]
[ 18.287726] -> #2 (&(&port->lock)->rlock){-...}:
[ 18.287729] validate_chain+0x84a/0xe00
[ 18.287729] __lock_acquire (lockdep.c:?)
[ 18.287730] lock_acquire (??:?)
[ 18.287731] _raw_spin_lock_irqsave (??:?)
[ 18.287732] tty_port_tty_get (??:?)
[ 18.287733] tty_port_default_wakeup (tty_port.c:?)
[ 18.287734] tty_port_tty_wakeup (??:?)
[ 18.287734] uart_write_wakeup (??:?)
[ 18.287735] serial8250_tx_chars (??:?)
[ 18.287736] serial8250_handle_irq (??:?)
[ 18.287737] serial8250_default_handle_irq (8250_port.c:?)
[ 18.287738] serial8250_interrupt (8250_core.c:?)
[ 18.287738] __handle_irq_event_percpu (??:?)
[ 18.287739] handle_irq_event_percpu (??:?)
[ 18.287740] handle_irq_event (??:?)
[ 18.287741] handle_edge_irq (??:?)
[ 18.287742] handle_irq (??:?)
[ 18.287742] do_IRQ (??:?)
[ 18.287743] common_interrupt (entry_32.o:?)
[ 18.287744] _raw_spin_unlock_irqrestore (??:?)
[ 18.287745] uart_write (serial_core.c:?)
[ 18.287746] process_output_block (n_tty.c:?)
[ 18.287747] n_tty_write (n_tty.c:?)
[ 18.287747] tty_write (tty_io.c:?)
[ 18.287748] __vfs_write (??:?)
[ 18.287749] vfs_write (??:?)
[ 18.287750] ksys_write (??:?)
[ 18.287750] sys_write (??:?)
[ 18.287751] do_fast_syscall_32 (??:?)
[ 18.287752] entry_SYSENTER_32 (??:?)
[ 18.287752]
[ 18.287753] -> #1 (&port_lock_key){-.-.}:
[ 18.287756]
[ 18.287756] -> #0 (console_owner){..-.}:
[ 18.287759] check_prevs_add (lockdep.c:?)
[ 18.287760] validate_chain+0x84a/0xe00
[ 18.287761] __lock_acquire (lockdep.c:?)
[ 18.287761] lock_acquire (??:?)
[ 18.287762] console_unlock (??:?)
[ 18.287763] vprintk_emit (??:?)
[ 18.287764] vprintk_default (??:?)
[ 18.287764] vprintk_func (??:?)
[ 18.287765] printk (??:?)
[ 18.287766] get_random_u32 (??:?)
[ 18.287767] shuffle_freelist (slub.c:?)
[ 18.287767] allocate_slab (slub.c:?)
[ 18.287768] new_slab (slub.c:?)
[ 18.287769] ___slab_alloc+0x6d0/0xb20
[ 18.287770] __slab_alloc+0xd6/0x2e0
[ 18.287770] __kmalloc (??:?)
[ 18.287771] tty_buffer_alloc (tty_buffer.c:?)
[ 18.287772] __tty_buffer_request_room (tty_buffer.c:?)
[ 18.287773] tty_insert_flip_string_fixed_flag (??:?)
[ 18.287774] pty_write (pty.c:?)
[ 18.287775] process_output_block (n_tty.c:?)
[ 18.287776] n_tty_write (n_tty.c:?)
[ 18.287777] tty_write (tty_io.c:?)
[ 18.287778] __vfs_write (??:?)
[ 18.287779] vfs_write (??:?)
[ 18.287780] ksys_write (??:?)
[ 18.287780] sys_write (??:?)
[ 18.287781] do_fast_syscall_32 (??:?)
[ 18.287782] entry_SYSENTER_32 (??:?)
[ 18.287783]
[ 18.287783] other info that might help us debug this:
[ 18.287784]
[ 18.287785] Chain exists of:
[ 18.287785] console_owner --> &port_lock_key --> &(&port->lock)->rlock
[ 18.287789]
[ 18.287790] Possible unsafe locking scenario:
[ 18.287790]
[ 18.287791] CPU0 CPU1
[ 18.287792] ---- ----
[ 18.287792] lock(&(&port->lock)->rlock);
[ 18.287794] lock(&port_lock_key);
[ 18.287814] lock(&(&port->lock)->rlock);
[ 18.287815] lock(console_owner);
[ 18.287817]
[ 18.287818] *** DEADLOCK ***
[ 18.287818]
[ 18.287819] 6 locks held by stop/202:
[ 18.287820] #0: (ptrval) (&tty->ldisc_sem){++++}, at: ldsem_down_read (??:?)
[ 18.287823] #1: (ptrval) (&tty->atomic_write_lock){+.+.}, at: tty_write_lock (tty_io.c:?)
[ 18.287826] #2: (ptrval) (&o_tty->termios_rwsem/1){++++}, at: n_tty_write (n_tty.c:?)
[ 18.287830] #3: (ptrval) (&ldata->output_lock){+.+.}, at: process_output_block (n_tty.c:?)
[ 18.287834] #4: (ptrval) (&(&port->lock)->rlock){-...}, at: pty_write (pty.c:?)
[ 18.287838] #5: (ptrval) (console_lock){+.+.}, at: console_trylock_spinning (printk.c:?)
[ 18.287841]
[ 18.287842] stack backtrace:
[ 18.287843] CPU: 0 PID: 202 Comm: stop Not tainted 4.19.248-00165-g3d1f971aa81f #1
[ 18.287843] Call Trace:
[ 18.287844] dump_stack (??:?)
[ 18.287845] print_circular_bug.cold+0x78/0x8b
[ 18.287846] check_prev_add+0x66a/0xd20
[ 18.287847] check_prevs_add (lockdep.c:?)
[ 18.287848] validate_chain+0x84a/0xe00
[ 18.287848] __lock_acquire (lockdep.c:?)
[ 18.287849] lock_acquire (??:?)
[ 18.287850] ? console_unlock (??:?)
[ 18.287851] console_unlock (??:?)
[ 18.287851] ? console_unlock (??:?)
[ 18.287852] ? native_save_fl (??:?)
[ 18.287853] vprintk_emit (??:?)
[ 18.287854] vprintk_default (??:?)
[ 18.287855] vprintk_func (??:?)
[ 18.287855] printk (??:?)
[ 18.287856] get_random_u32 (??:?)
[ 18.287857] ? shuffle_freelist (slub.c:?)
[ 18.287858] shuffle_freelist (slub.c:?)
[ 18.287858] ? page_address (??:?)
[ 18.287859] allocate_slab (slub.c:?)
[ 18.287860] new_slab (slub.c:?)
[ 18.287861] ? pvclock_clocksource_read (??:?)
[ 18.287862] ___slab_alloc+0x6d0/0xb20
[ 18.287862] ? kvm_sched_clock_read (kvmclock.c:?)
[ 18.287863] ? __slab_alloc+0xbc/0x2e0
[ 18.287864] ? native_wbinvd (paravirt.c:?)
[ 18.287865] __slab_alloc+0xd6/0x2e0
[ 18.287865] __kmalloc (??:?)
[ 18.287866] ? __lock_acquire (lockdep.c:?)
[ 18.287867] ? tty_buffer_alloc (tty_buffer.c:?)
[ 18.287868] tty_buffer_alloc (tty_buffer.c:?)
[ 18.287869] __tty_buffer_request_room (tty_buffer.c:?)
[ 18.287869] tty_insert_flip_string_fixed_flag (??:?)
[ 18.287870] pty_write (pty.c:?)
[ 18.287871] process_output_block (n_tty.c:?)
[ 18.287872] n_tty_write (n_tty.c:?)
[ 18.287873] ? print_dl_stats (??:?)
[ 18.287874] ? n_tty_ioctl (n_tty.c:?)
[ 18.287874] tty_write (tty_io.c:?)
[ 18.287875] ? n_tty_ioctl (n_tty.c:?)
[ 18.287876] ? tty_write_unlock (tty_io.c:?)
[ 18.287877] __vfs_write (??:?)
[ 18.287877] vfs_write (??:?)
[ 18.287878] ? __fget_light (file.c:?)
[ 18.287879] ksys_write (??:?)

Cc: Sergey Senozhatsky <[email protected]>
Cc: Qian Cai <[email protected]>
Cc: Lech Perczak <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: John Ogness <[email protected]>
Reported-by: kernel test robot <[email protected]>
Link: https://lore.kernel.org/lkml/Ytz+lo4zRQYG3JUR@xsang-OptiPlex-9020
Signed-off-by: Jason A. Donenfeld <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/random.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -183,8 +183,8 @@ static void __cold process_random_ready_

#define warn_unseeded_randomness() \
if (IS_ENABLED(CONFIG_WARN_ALL_UNSEEDED_RANDOM) && !crng_ready()) \
- pr_notice("%s called from %pS with crng_init=%d\n", \
- __func__, (void *)_RET_IP_, crng_init)
+ printk_deferred(KERN_NOTICE "random: %s called from %pS with crng_init=%d\n", \
+ __func__, (void *)_RET_IP_, crng_init)


/*********************************************************************


2022-07-27 18:27:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 33/37] net: usb: ax88179_178a needs FLAG_SEND_ZLP

From: Jose Alonso <[email protected]>

commit 36a15e1cb134c0395261ba1940762703f778438c upstream.

The extra byte inserted by usbnet.c when
(length % dev->maxpacket == 0) is causing problems to device.

This patch sets FLAG_SEND_ZLP to avoid this.

Tested with: 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet

Problems observed:
======================================================================
1) Using ssh/sshfs. The remote sshd daemon can abort with the message:
"message authentication code incorrect"
This happens because the tcp message sent is corrupted during the
USB "Bulk out". The device calculate the tcp checksum and send a
valid tcp message to the remote sshd. Then the encryption detects
the error and aborts.
2) NETDEV WATCHDOG: ... (ax88179_178a): transmit queue 0 timed out
3) Stop normal work without any log message.
The "Bulk in" continue receiving packets normally.
The host sends "Bulk out" and the device responds with -ECONNRESET.
(The netusb.c code tx_complete ignore -ECONNRESET)
Under normal conditions these errors take days to happen and in
intense usage take hours.

A test with ping gives packet loss, showing that something is wrong:
ping -4 -s 462 {destination} # 462 = 512 - 42 - 8
Not all packets fail.
My guess is that the device tries to find another packet starting
at the extra byte and will fail or not depending on the next
bytes (old buffer content).
======================================================================

Signed-off-by: Jose Alonso <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/ax88179_178a.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1707,7 +1707,7 @@ static const struct driver_info ax88179_
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1720,7 +1720,7 @@ static const struct driver_info ax88178a
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1733,7 +1733,7 @@ static const struct driver_info cypress_
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1746,7 +1746,7 @@ static const struct driver_info dlink_du
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1759,7 +1759,7 @@ static const struct driver_info sitecom_
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1772,7 +1772,7 @@ static const struct driver_info samsung_
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1785,7 +1785,7 @@ static const struct driver_info lenovo_i
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1798,7 +1798,7 @@ static const struct driver_info belkin_i
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};


2022-07-27 18:27:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 32/37] tty: use new tty_insert_flip_string_and_push_buffer() in pty_write()

From: Jiri Slaby <[email protected]>

commit a501ab75e7624d133a5a3c7ec010687c8b961d23 upstream.

There is a race in pty_write(). pty_write() can be called in parallel
with e.g. ioctl(TIOCSTI) or ioctl(TCXONC) which also inserts chars to
the buffer. Provided, tty_flip_buffer_push() in pty_write() is called
outside the lock, it can commit inconsistent tail. This can lead to out
of bounds writes and other issues. See the Link below.

To fix this, we have to introduce a new helper called
tty_insert_flip_string_and_push_buffer(). It does both
tty_insert_flip_string() and tty_flip_buffer_commit() under the port
lock. It also calls queue_work(), but outside the lock. See
71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in
pty_write) for the reasons.

Keep the helper internal-only (in drivers' tty.h). It is not intended to
be used widely.

Link: https://seclists.org/oss-sec/2022/q2/155
Fixes: 71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in pty_write)
Cc: 一只狗 <[email protected]>
Cc: Dan Carpenter <[email protected]>
Suggested-by: Hillf Danton <[email protected]>
Signed-off-by: Jiri Slaby <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/pty.c | 14 ++------------
drivers/tty/tty_buffer.c | 31 +++++++++++++++++++++++++++++++
include/linux/tty_flip.h | 3 +++
3 files changed, 36 insertions(+), 12 deletions(-)

--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -111,21 +111,11 @@ static void pty_unthrottle(struct tty_st
static int pty_write(struct tty_struct *tty, const unsigned char *buf, int c)
{
struct tty_struct *to = tty->link;
- unsigned long flags;

- if (tty->stopped)
+ if (tty->stopped || !c)
return 0;

- if (c > 0) {
- spin_lock_irqsave(&to->port->lock, flags);
- /* Stuff the data into the input queue of the other end */
- c = tty_insert_flip_string(to->port, buf, c);
- spin_unlock_irqrestore(&to->port->lock, flags);
- /* And shovel */
- if (c)
- tty_flip_buffer_push(to->port);
- }
- return c;
+ return tty_insert_flip_string_and_push_buffer(to->port, buf, c);
}

/**
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -547,6 +547,37 @@ void tty_flip_buffer_push(struct tty_por
EXPORT_SYMBOL(tty_flip_buffer_push);

/**
+ * tty_insert_flip_string_and_push_buffer - add characters to the tty buffer and
+ * push
+ * @port: tty port
+ * @chars: characters
+ * @size: size
+ *
+ * The function combines tty_insert_flip_string() and tty_flip_buffer_push()
+ * with the exception of properly holding the @port->lock.
+ *
+ * To be used only internally (by pty currently).
+ *
+ * Returns: the number added.
+ */
+int tty_insert_flip_string_and_push_buffer(struct tty_port *port,
+ const unsigned char *chars, size_t size)
+{
+ struct tty_bufhead *buf = &port->buf;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+ size = tty_insert_flip_string(port, chars, size);
+ if (size)
+ tty_flip_buffer_commit(buf->tail);
+ spin_unlock_irqrestore(&port->lock, flags);
+
+ queue_work(system_unbound_wq, &buf->work);
+
+ return size;
+}
+
+/**
* tty_buffer_init - prepare a tty buffer structure
* @tty: tty to initialise
*
--- a/include/linux/tty_flip.h
+++ b/include/linux/tty_flip.h
@@ -39,4 +39,7 @@ static inline int tty_insert_flip_string
extern void tty_buffer_lock_exclusive(struct tty_port *port);
extern void tty_buffer_unlock_exclusive(struct tty_port *port);

+int tty_insert_flip_string_and_push_buffer(struct tty_port *port,
+ const unsigned char *chars, size_t cnt);
+
#endif /* _LINUX_TTY_FLIP_H */


2022-07-27 18:28:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 27/37] Bluetooth: Fix bt_skb_sendmmsg not allocating partial chunks

From: Luiz Augusto von Dentz <[email protected]>

commit 29fb608396d6a62c1b85acc421ad7a4399085b9f upstream.

Since bt_skb_sendmmsg can be used with the likes of SOCK_STREAM it
shall return the partial chunks it could allocate instead of freeing
everything as otherwise it can cause problems like bellow.

Fixes: 81be03e026dc ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg")
Reported-by: Paul Menzel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215594
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Tested-by: Paul Menzel <[email protected]> (Nokia N9 (MeeGo/Harmattan)
Signed-off-by: Marcel Holtmann <[email protected]>
Cc: Harshit Mogalapalli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/bluetooth/bluetooth.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -420,8 +420,7 @@ static inline struct sk_buff *bt_skb_sen

tmp = bt_skb_sendmsg(sk, msg, len, mtu, headroom, tailroom);
if (IS_ERR(tmp)) {
- kfree_skb(skb);
- return tmp;
+ return skb;
}

len -= tmp->len;


2022-07-27 18:29:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 06/37] tcp/dccp: Fix a data-race around sysctl_tcp_fwmark_accept.

From: Kuniyuki Iwashima <[email protected]>

[ Upstream commit 1a0008f9df59451d0a17806c1ee1a19857032fa8 ]

While reading sysctl_tcp_fwmark_accept, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader.

Fixes: 84f39b08d786 ("net: support marking accepting TCP sockets")
Signed-off-by: Kuniyuki Iwashima <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
include/net/inet_sock.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 16a1492a5bd3..f279d72273f6 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -110,7 +110,8 @@ static inline struct inet_request_sock *inet_rsk(const struct request_sock *sk)

static inline u32 inet_request_mark(const struct sock *sk, struct sk_buff *skb)
{
- if (!sk->sk_mark && sock_net(sk)->ipv4.sysctl_tcp_fwmark_accept)
+ if (!sk->sk_mark &&
+ READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_fwmark_accept))
return skb->mark;

return sk->sk_mark;
--
2.35.1



2022-07-27 18:30:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 04/37] perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()

From: Peter Zijlstra <[email protected]>

[ Upstream commit 68e3c69803dada336893640110cb87221bb01dcf ]

Yang Jihing reported a race between perf_event_set_output() and
perf_mmap_close():

CPU1 CPU2

perf_mmap_close(e2)
if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0
detach_rest = true

ioctl(e1, IOC_SET_OUTPUT, e2)
perf_event_set_output(e1, e2)

...
list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry)
ring_buffer_attach(e, NULL);
// e1 isn't yet added and
// therefore not detached

ring_buffer_attach(e1, e2->rb)
list_add_rcu(&e1->rb_entry,
&e2->rb->event_list)

After this; e1 is attached to an unmapped rb and a subsequent
perf_mmap() will loop forever more:

again:
mutex_lock(&e->mmap_mutex);
if (event->rb) {
...
if (!atomic_inc_not_zero(&e->rb->mmap_count)) {
...
mutex_unlock(&e->mmap_mutex);
goto again;
}
}

The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach
in perf_event_set_output() holds e1->mmap_mutex. As such there is no
serialization to avoid this race.

Change perf_event_set_output() to take both e1->mmap_mutex and
e2->mmap_mutex to alleviate that problem. Additionally, have the loop
in perf_mmap() detach the rb directly, this avoids having to wait for
the concurrent perf_mmap_close() to get around to doing it to make
progress.

Fixes: 9bb5d40cd93c ("perf: Fix mmap() accounting hole")
Reported-by: Yang Jihong <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Tested-by: Yang Jihong <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/events/core.c | 45 ++++++++++++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 93e21e319d70..2ad8acff03db 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5429,10 +5429,10 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma)

if (!atomic_inc_not_zero(&event->rb->mmap_count)) {
/*
- * Raced against perf_mmap_close() through
- * perf_event_set_output(). Try again, hope for better
- * luck.
+ * Raced against perf_mmap_close(); remove the
+ * event and try again.
*/
+ ring_buffer_attach(event, NULL);
mutex_unlock(&event->mmap_mutex);
goto again;
}
@@ -9859,14 +9859,25 @@ static int perf_copy_attr(struct perf_event_attr __user *uattr,
goto out;
}

+static void mutex_lock_double(struct mutex *a, struct mutex *b)
+{
+ if (b < a)
+ swap(a, b);
+
+ mutex_lock(a);
+ mutex_lock_nested(b, SINGLE_DEPTH_NESTING);
+}
+
static int
perf_event_set_output(struct perf_event *event, struct perf_event *output_event)
{
struct ring_buffer *rb = NULL;
int ret = -EINVAL;

- if (!output_event)
+ if (!output_event) {
+ mutex_lock(&event->mmap_mutex);
goto set;
+ }

/* don't allow circular references */
if (event == output_event)
@@ -9904,8 +9915,15 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event)
event->pmu != output_event->pmu)
goto out;

+ /*
+ * Hold both mmap_mutex to serialize against perf_mmap_close(). Since
+ * output_event is already on rb->event_list, and the list iteration
+ * restarts after every removal, it is guaranteed this new event is
+ * observed *OR* if output_event is already removed, it's guaranteed we
+ * observe !rb->mmap_count.
+ */
+ mutex_lock_double(&event->mmap_mutex, &output_event->mmap_mutex);
set:
- mutex_lock(&event->mmap_mutex);
/* Can't redirect output if we've got an active mmap() */
if (atomic_read(&event->mmap_count))
goto unlock;
@@ -9915,6 +9933,12 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event)
rb = ring_buffer_get(output_event);
if (!rb)
goto unlock;
+
+ /* did we race against perf_mmap_close() */
+ if (!atomic_read(&rb->mmap_count)) {
+ ring_buffer_put(rb);
+ goto unlock;
+ }
}

ring_buffer_attach(event, rb);
@@ -9922,20 +9946,13 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event)
ret = 0;
unlock:
mutex_unlock(&event->mmap_mutex);
+ if (output_event)
+ mutex_unlock(&output_event->mmap_mutex);

out:
return ret;
}

-static void mutex_lock_double(struct mutex *a, struct mutex *b)
-{
- if (b < a)
- swap(a, b);
-
- mutex_lock(a);
- mutex_lock_nested(b, SINGLE_DEPTH_NESTING);
-}
-
static int perf_event_set_clock(struct perf_event *event, clockid_t clk_id)
{
bool nmi_safe = false;
--
2.35.1



2022-07-27 18:31:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 13/37] tcp: Fix a data-race around sysctl_tcp_notsent_lowat.

From: Kuniyuki Iwashima <[email protected]>

[ Upstream commit 55be873695ed8912eb77ff46d1d1cadf028bd0f3 ]

While reading sysctl_tcp_notsent_lowat, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader.

Fixes: c9bee3b7fdec ("tcp: TCP_NOTSENT_LOWAT socket option")
Signed-off-by: Kuniyuki Iwashima <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
include/net/tcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 181db7dab176..5e719f9d60fd 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1882,7 +1882,7 @@ void __tcp_v4_send_check(struct sk_buff *skb, __be32 saddr, __be32 daddr);
static inline u32 tcp_notsent_lowat(const struct tcp_sock *tp)
{
struct net *net = sock_net((struct sock *)tp);
- return tp->notsent_lowat ?: net->ipv4.sysctl_tcp_notsent_lowat;
+ return tp->notsent_lowat ?: READ_ONCE(net->ipv4.sysctl_tcp_notsent_lowat);
}

static inline bool tcp_stream_memory_free(const struct sock *sk)
--
2.35.1



2022-07-27 18:31:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 09/37] i2c: cadence: Change large transfer count reset logic to be unconditional

From: Robert Hancock <[email protected]>

[ Upstream commit 4ca8ca873d454635c20d508261bfc0081af75cf8 ]

Problems were observed on the Xilinx ZynqMP platform with large I2C reads.
When a read of 277 bytes was performed, the controller NAKed the transfer
after only 252 bytes were transferred and returned an ENXIO error on the
transfer.

There is some code in cdns_i2c_master_isr to handle this case by resetting
the transfer count in the controller before it reaches 0, to allow larger
transfers to work, but it was conditional on the CDNS_I2C_BROKEN_HOLD_BIT
quirk being set on the controller, and ZynqMP uses the r1p14 version of
the core where this quirk is not being set. The requirement to do this to
support larger reads seems like an inherently required workaround due to
the core only having an 8-bit transfer size register, so it does not
appear that this should be conditional on the broken HOLD bit quirk which
is used elsewhere in the driver.

Remove the dependency on the CDNS_I2C_BROKEN_HOLD_BIT for this transfer
size reset logic to fix this problem.

Fixes: 63cab195bf49 ("i2c: removed work arounds in i2c driver for Zynq Ultrascale+ MPSoC")
Signed-off-by: Robert Hancock <[email protected]>
Reviewed-by: Shubhrajyoti Datta <[email protected]>
Acked-by: Michal Simek <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/busses/i2c-cadence.c | 30 +++++-------------------------
1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 273f57e277b3..512c61d31fe5 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -203,9 +203,9 @@ static inline bool cdns_is_holdquirk(struct cdns_i2c *id, bool hold_wrkaround)
*/
static irqreturn_t cdns_i2c_isr(int irq, void *ptr)
{
- unsigned int isr_status, avail_bytes, updatetx;
+ unsigned int isr_status, avail_bytes;
unsigned int bytes_to_send;
- bool hold_quirk;
+ bool updatetx;
struct cdns_i2c *id = ptr;
/* Signal completion only after everything is updated */
int done_flag = 0;
@@ -224,11 +224,7 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)
* Check if transfer size register needs to be updated again for a
* large data receive operation.
*/
- updatetx = 0;
- if (id->recv_count > id->curr_recv_count)
- updatetx = 1;
-
- hold_quirk = (id->quirks & CDNS_I2C_BROKEN_HOLD_BIT) && updatetx;
+ updatetx = id->recv_count > id->curr_recv_count;

/* When receiving, handle data interrupt and completion interrupt */
if (id->p_recv_buf &&
@@ -251,7 +247,7 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)
id->recv_count--;
id->curr_recv_count--;

- if (cdns_is_holdquirk(id, hold_quirk))
+ if (cdns_is_holdquirk(id, updatetx))
break;
}

@@ -262,7 +258,7 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)
* maintain transfer size non-zero while performing a large
* receive operation.
*/
- if (cdns_is_holdquirk(id, hold_quirk)) {
+ if (cdns_is_holdquirk(id, updatetx)) {
/* wait while fifo is full */
while (cdns_i2c_readreg(CDNS_I2C_XFER_SIZE_OFFSET) !=
(id->curr_recv_count - CDNS_I2C_FIFO_DEPTH))
@@ -284,22 +280,6 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)
CDNS_I2C_XFER_SIZE_OFFSET);
id->curr_recv_count = id->recv_count;
}
- } else if (id->recv_count && !hold_quirk &&
- !id->curr_recv_count) {
-
- /* Set the slave address in address register*/
- cdns_i2c_writereg(id->p_msg->addr & CDNS_I2C_ADDR_MASK,
- CDNS_I2C_ADDR_OFFSET);
-
- if (id->recv_count > CDNS_I2C_TRANSFER_SIZE) {
- cdns_i2c_writereg(CDNS_I2C_TRANSFER_SIZE,
- CDNS_I2C_XFER_SIZE_OFFSET);
- id->curr_recv_count = CDNS_I2C_TRANSFER_SIZE;
- } else {
- cdns_i2c_writereg(id->recv_count,
- CDNS_I2C_XFER_SIZE_OFFSET);
- id->curr_recv_count = id->recv_count;
- }
}

/* Clear hold (if not repeated start) and signal completion */
--
2.35.1



2022-07-27 18:33:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 05/37] ip: Fix a data-race around sysctl_fwmark_reflect.

From: Kuniyuki Iwashima <[email protected]>

[ Upstream commit 85d0b4dbd74b95cc492b1f4e34497d3f894f5d9a ]

While reading sysctl_fwmark_reflect, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader.

Fixes: e110861f8609 ("net: add a sysctl to reflect the fwmark on replies")
Signed-off-by: Kuniyuki Iwashima <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
include/net/ip.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/ip.h b/include/net/ip.h
index 4aff48d6ba91..2a92a5f4f9b3 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -305,7 +305,7 @@ void ipfrag_init(void);
void ip_static_sysctl_init(void);

#define IP4_REPLY_MARK(net, mark) \
- ((net)->ipv4.sysctl_fwmark_reflect ? (mark) : 0)
+ (READ_ONCE((net)->ipv4.sysctl_fwmark_reflect) ? (mark) : 0)

static inline bool ip_is_fragment(const struct iphdr *iph)
{
--
2.35.1



2022-07-27 18:58:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 37/37] PCI: hv: Fix interrupt mapping for multi-MSI

From: Jeffrey Hugo <[email protected]>

commit a2bad844a67b1c7740bda63e87453baf63c3a7f7 upstream.

According to Dexuan, the hypervisor folks beleive that multi-msi
allocations are not correct. compose_msi_msg() will allocate multi-msi
one by one. However, multi-msi is a block of related MSIs, with alignment
requirements. In order for the hypervisor to allocate properly aligned
and consecutive entries in the IOMMU Interrupt Remapping Table, there
should be a single mapping request that requests all of the multi-msi
vectors in one shot.

Dexuan suggests detecting the multi-msi case and composing a single
request related to the first MSI. Then for the other MSIs in the same
block, use the cached information. This appears to be viable, so do it.

4.14 backport - file moved to host/pci-hyperv.c. add hv_msi_get_int_vector
helper function. Fixed merge conflict due to delivery_mode name change
(APIC_DELIVERY_MODE_FIXED is the value given to dest_Fixed). Removed unused
variable in hv_compose_msi_msg. Fixed reference to msi_desc->pci to point
to the same is_msix variable. Removed changes to compose_msi_req_v3 since
it doesn't exist yet. Added "reason" to put_pcichild (unused in function).

Suggested-by: Dexuan Cui <[email protected]>
Signed-off-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Dexuan Cui <[email protected]>
Tested-by: Michael Kelley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Wei Liu <[email protected]>
Signed-off-by: Carl Vanderlip <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/host/pci-hyperv.c | 62 ++++++++++++++++++++++++++++++++++++------
1 file changed, 54 insertions(+), 8 deletions(-)

--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -846,6 +846,11 @@ static void hv_int_desc_free(struct hv_p
u8 buffer[sizeof(struct pci_delete_interrupt)];
} ctxt;

+ if (!int_desc->vector_count) {
+ kfree(int_desc);
+ return;
+ }
+
memset(&ctxt, 0, sizeof(ctxt));
int_pkt = (struct pci_delete_interrupt *)&ctxt.pkt.message;
int_pkt->message_type.type =
@@ -908,6 +913,13 @@ static void hv_irq_mask(struct irq_data
pci_msi_mask_irq(data);
}

+static unsigned int hv_msi_get_int_vector(struct irq_data *data)
+{
+ struct irq_cfg *cfg = irqd_cfg(data);
+
+ return cfg->vector;
+}
+
static int hv_msi_prepare(struct irq_domain *domain, struct device *dev,
int nvec, msi_alloc_info_t *info)
{
@@ -1050,12 +1062,12 @@ static void hv_pci_compose_compl(void *c

static u32 hv_compose_msi_req_v1(
struct pci_create_interrupt *int_pkt, struct cpumask *affinity,
- u32 slot, u8 vector)
+ u32 slot, u8 vector, u8 vector_count)
{
int_pkt->message_type.type = PCI_CREATE_INTERRUPT_MESSAGE;
int_pkt->wslot.slot = slot;
int_pkt->int_desc.vector = vector;
- int_pkt->int_desc.vector_count = 1;
+ int_pkt->int_desc.vector_count = vector_count;
int_pkt->int_desc.delivery_mode =
(apic->irq_delivery_mode == dest_LowestPrio) ?
dest_LowestPrio : dest_Fixed;
@@ -1071,14 +1083,14 @@ static u32 hv_compose_msi_req_v1(

static u32 hv_compose_msi_req_v2(
struct pci_create_interrupt2 *int_pkt, struct cpumask *affinity,
- u32 slot, u8 vector)
+ u32 slot, u8 vector, u8 vector_count)
{
int cpu;

int_pkt->message_type.type = PCI_CREATE_INTERRUPT_MESSAGE2;
int_pkt->wslot.slot = slot;
int_pkt->int_desc.vector = vector;
- int_pkt->int_desc.vector_count = 1;
+ int_pkt->int_desc.vector_count = vector_count;
int_pkt->int_desc.delivery_mode =
(apic->irq_delivery_mode == dest_LowestPrio) ?
dest_LowestPrio : dest_Fixed;
@@ -1108,7 +1120,6 @@ static u32 hv_compose_msi_req_v2(
*/
static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
{
- struct irq_cfg *cfg = irqd_cfg(data);
struct hv_pcibus_device *hbus;
struct hv_pci_dev *hpdev;
struct pci_bus *pbus;
@@ -1117,6 +1128,8 @@ static void hv_compose_msi_msg(struct ir
unsigned long flags;
struct compose_comp_ctxt comp;
struct tran_int_desc *int_desc;
+ struct msi_desc *msi_desc;
+ u8 vector, vector_count;
struct {
struct pci_packet pci_pkt;
union {
@@ -1137,7 +1150,8 @@ static void hv_compose_msi_msg(struct ir
return;
}

- pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
+ msi_desc = irq_data_get_msi_desc(data);
+ pdev = msi_desc_to_pci_dev(msi_desc);
dest = irq_data_get_effective_affinity_mask(data);
pbus = pdev->bus;
hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
@@ -1149,6 +1163,36 @@ static void hv_compose_msi_msg(struct ir
if (!int_desc)
goto drop_reference;

+ if (!msi_desc->msi_attrib.is_msix && msi_desc->nvec_used > 1) {
+ /*
+ * If this is not the first MSI of Multi MSI, we already have
+ * a mapping. Can exit early.
+ */
+ if (msi_desc->irq != data->irq) {
+ data->chip_data = int_desc;
+ int_desc->address = msi_desc->msg.address_lo |
+ (u64)msi_desc->msg.address_hi << 32;
+ int_desc->data = msi_desc->msg.data +
+ (data->irq - msi_desc->irq);
+ msg->address_hi = msi_desc->msg.address_hi;
+ msg->address_lo = msi_desc->msg.address_lo;
+ msg->data = int_desc->data;
+ put_pcichild(hpdev, hv_pcidev_ref_by_slot);
+ return;
+ }
+ /*
+ * The vector we select here is a dummy value. The correct
+ * value gets sent to the hypervisor in unmask(). This needs
+ * to be aligned with the count, and also not zero. Multi-msi
+ * is powers of 2 up to 32, so 32 will always work here.
+ */
+ vector = 32;
+ vector_count = msi_desc->nvec_used;
+ } else {
+ vector = hv_msi_get_int_vector(data);
+ vector_count = 1;
+ }
+
memset(&ctxt, 0, sizeof(ctxt));
init_completion(&comp.comp_pkt.host_event);
ctxt.pci_pkt.completion_func = hv_pci_compose_compl;
@@ -1159,14 +1203,16 @@ static void hv_compose_msi_msg(struct ir
size = hv_compose_msi_req_v1(&ctxt.int_pkts.v1,
dest,
hpdev->desc.win_slot.slot,
- cfg->vector);
+ vector,
+ vector_count);
break;

case PCI_PROTOCOL_VERSION_1_2:
size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2,
dest,
hpdev->desc.win_slot.slot,
- cfg->vector);
+ vector,
+ vector_count);
break;

default:


2022-07-27 19:02:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 21/37] Bluetooth: Add bt_skb_sendmsg helper

From: Luiz Augusto von Dentz <[email protected]>

commit 38f64f650dc0e44c146ff88d15a7339efa325918 upstream.

bt_skb_sendmsg helps takes care of allocation the skb and copying the
the contents of msg over to the skb while checking for possible errors
so it should be safe to call it without holding lock_sock.

Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Cc: Harshit Mogalapalli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/bluetooth/bluetooth.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)

--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -367,6 +367,34 @@ out:
return NULL;
}

+/* Shall not be called with lock_sock held */
+static inline struct sk_buff *bt_skb_sendmsg(struct sock *sk,
+ struct msghdr *msg,
+ size_t len, size_t mtu,
+ size_t headroom, size_t tailroom)
+{
+ struct sk_buff *skb;
+ size_t size = min_t(size_t, len, mtu);
+ int err;
+
+ skb = bt_skb_send_alloc(sk, size + headroom + tailroom,
+ msg->msg_flags & MSG_DONTWAIT, &err);
+ if (!skb)
+ return ERR_PTR(err);
+
+ skb_reserve(skb, headroom);
+ skb_tailroom_reserve(skb, mtu, tailroom);
+
+ if (!copy_from_iter_full(skb_put(skb, size), size, &msg->msg_iter)) {
+ kfree_skb(skb);
+ return ERR_PTR(-EFAULT);
+ }
+
+ skb->priority = sk->sk_priority;
+
+ return skb;
+}
+
int bt_to_errno(u16 code);

void hci_sock_set_flag(struct sock *sk, int nr);


2022-07-28 10:58:29

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/37] 4.14.290-rc1 review

On Wed, 27 Jul 2022 at 21:53, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.14.290 release.
> There are 37 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 Fri, 29 Jul 2022 16:09:50 +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.14.290-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.14.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.

Tested-by: Linux Kernel Functional Testing <[email protected]>

## Build
* kernel: 4.14.290-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.14.y
* git commit: 7df53ec6e7ae929b9bbdd245504a491e962d6631
* git describe: v4.14.289-38-g7df53ec6e7ae
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.289-38-g7df53ec6e7ae

## Test Regressions (compared to v4.14.289)
No test regressions found.

## Metric Regressions (compared to v4.14.289)
No metric regressions found.

## Test Fixes (compared to v4.14.289)
No test fixes found.

## Metric Fixes (compared to v4.14.289)
No metric fixes found.

## Test result summary
total: 88981, pass: 78369, fail: 158, skip: 9183, xfail: 1271

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 286 total, 281 passed, 5 failed
* arm64: 50 total, 47 passed, 3 failed
* i386: 26 total, 25 passed, 1 failed
* mips: 30 total, 30 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 16 total, 16 passed, 0 failed
* s390: 12 total, 9 passed, 3 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 48 total, 47 passed, 1 failed

## Test suites summary
* fwts
* igt-gpu-tools
* kunit
* kvm-unit-tests
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* rcutorture
* v4l2-compliance
* vdso

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

2022-07-28 23:22:33

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/37] 4.14.290-rc1 review

On Wed, Jul 27, 2022 at 06:10:26PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.290 release.
> There are 37 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 Fri, 29 Jul 2022 16:09:50 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 170 pass: 170 fail: 0
Qemu test results:
total: 424 pass: 424 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter