This is the start of the stable review cycle for the 4.14.269 release.
There are 31 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, 02 Mar 2022 17:20:16 +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.269-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.269-rc1
Linus Torvalds <[email protected]>
fget: clarify and improve __fget_files() implementation
Miaohe Lin <[email protected]>
memblock: use kfree() to release kmalloced memblock regions
Karol Herbst <[email protected]>
Revert "drm/nouveau/pmu/gm200-: avoid touching PMU outside of DEVINIT/PREOS/ACR"
[email protected] <[email protected]>
tty: n_gsm: fix proper link termination after failed open
[email protected] <[email protected]>
tty: n_gsm: fix encoding of control signal octet bit DV
Hongyu Xie <[email protected]>
xhci: Prevent futile URB re-submissions due to incorrect return value.
Puma Hsu <[email protected]>
xhci: re-initialize the HC during resume if HCE was set
Sebastian Andrzej Siewior <[email protected]>
usb: dwc3: gadget: Let the interrupt handler disable bottom halves.
Daniele Palmas <[email protected]>
USB: serial: option: add Telit LE910R1 compositions
Slark Xiao <[email protected]>
USB: serial: option: add support for DW5829e
Steven Rostedt (Google) <[email protected]>
tracefs: Set the group ownership in apply_options() not parse_options()
Szymon Heidrich <[email protected]>
USB: gadget: validate endpoint index for xilinx udc
Daehwan Jung <[email protected]>
usb: gadget: rndis: add spinlock for rndis response list
Dmytro Bagrii <[email protected]>
Revert "USB: serial: ch341: add new Product ID for CH341A"
Sergey Shtylyov <[email protected]>
ata: pata_hpt37x: disable primary channel on HPT371
Christophe JAILLET <[email protected]>
iio: adc: men_z188_adc: Fix a resource leak in an error handling path
Bart Van Assche <[email protected]>
RDMA/ib_srp: Fix a deadlock
ChenXiaoSong <[email protected]>
configfs: fix a race in configfs_{,un}register_subsystem()
Gal Pressman <[email protected]>
net/mlx5e: Fix wrong return value on ioctl EEPROM query failure
Maxime Ripard <[email protected]>
drm/edid: Always set RGB444
Paul Blakey <[email protected]>
openvswitch: Fix setting ipv6 fields causing hw csum failure
Tao Liu <[email protected]>
gso: do not skip outer ip header in case of ipip and net_failover
Eric Dumazet <[email protected]>
net: __pskb_pull_tail() & pskb_carve_frag_list() drop_monitor friends
Xin Long <[email protected]>
ping: remove pr_err from ping_lookup
Robert Hancock <[email protected]>
serial: 8250: of: Fix mapped region size when using reg-offset property
Oliver Neukum <[email protected]>
USB: zaurus: support another broken Zaurus
Oliver Neukum <[email protected]>
sr9700: sanity check for packet length
Helge Deller <[email protected]>
parisc/unaligned: Fix ldw() and stw() unalignment handlers
Helge Deller <[email protected]>
parisc/unaligned: Fix fldd and fstd unaligned handlers on 32-bit kernel
Stefano Garzarella <[email protected]>
vhost/vsock: don't check owner in vhost_vsock_stop() while releasing
Zhang Qiao <[email protected]>
cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug
-------------
Diffstat:
Makefile | 4 +-
arch/parisc/kernel/unaligned.c | 14 ++---
drivers/ata/pata_hpt37x.c | 14 +++++
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c | 37 +++++------
drivers/iio/adc/men_z188_adc.c | 9 ++-
drivers/infiniband/ulp/srp/ib_srp.c | 6 +-
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 2 +-
drivers/net/usb/cdc_ether.c | 12 ++++
drivers/net/usb/sr9700.c | 2 +-
drivers/net/usb/zaurus.c | 12 ++++
drivers/tty/n_gsm.c | 4 +-
drivers/tty/serial/8250/8250_of.c | 11 +++-
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/rndis.c | 8 +++
drivers/usb/gadget/function/rndis.h | 1 +
drivers/usb/gadget/udc/udc-xilinx.c | 6 ++
drivers/usb/host/xhci.c | 28 ++++++---
drivers/usb/serial/ch341.c | 1 -
drivers/usb/serial/option.c | 12 ++++
drivers/vhost/vsock.c | 21 ++++---
fs/configfs/dir.c | 14 +++++
fs/file.c | 73 +++++++++++++++++-----
fs/tracefs/inode.c | 5 +-
include/net/checksum.h | 5 ++
kernel/cgroup/cpuset.c | 2 +
mm/memblock.c | 10 ++-
net/core/skbuff.c | 4 +-
net/ipv4/af_inet.c | 5 +-
net/ipv4/ping.c | 1 -
net/ipv6/ip6_offload.c | 2 +
net/openvswitch/actions.c | 46 +++++++++++---
32 files changed, 287 insertions(+), 88 deletions(-)
From: Eric Dumazet <[email protected]>
commit ef527f968ae05c6717c39f49c8709a7e2c19183a upstream.
Whenever one of these functions pull all data from an skb in a frag_list,
use consume_skb() instead of kfree_skb() to avoid polluting drop
monitoring.
Fixes: 6fa01ccd8830 ("skbuff: Add pskb_extract() helper function")
Signed-off-by: Eric Dumazet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/skbuff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1974,7 +1974,7 @@ void *__pskb_pull_tail(struct sk_buff *s
/* Free pulled out fragments. */
while ((list = skb_shinfo(skb)->frag_list) != insp) {
skb_shinfo(skb)->frag_list = list->next;
- kfree_skb(list);
+ consume_skb(list);
}
/* And insert new clone at head. */
if (clone) {
@@ -5408,7 +5408,7 @@ static int pskb_carve_frag_list(struct s
/* Free pulled out fragments. */
while ((list = shinfo->frag_list) != insp) {
shinfo->frag_list = list->next;
- kfree_skb(list);
+ consume_skb(list);
}
/* And insert new clone at head. */
if (clone) {
From: [email protected] <[email protected]>
commit e3b7468f082d106459e86e8dc6fb9bdd65553433 upstream.
Trying to open a DLCI by sending a SABM frame may fail with a timeout.
The link is closed on the initiator side without informing the responder
about this event. The responder assumes the link is open after sending a
UA frame to answer the SABM frame. The link gets stuck in a half open
state.
This patch fixes this by initiating the proper link termination procedure
after link setup timeout instead of silently closing it down.
Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Cc: [email protected]
Signed-off-by: Daniel Starke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/n_gsm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1502,7 +1502,7 @@ static void gsm_dlci_t1(unsigned long da
dlci->mode = DLCI_MODE_ADM;
gsm_dlci_open(dlci);
} else {
- gsm_dlci_close(dlci);
+ gsm_dlci_begin_close(dlci); /* prevent half open link */
}
break;
From: [email protected] <[email protected]>
commit 737b0ef3be6b319d6c1fd64193d1603311969326 upstream.
n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516
The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
the newer 27.010 here. Chapter 5.4.6.3.7 describes the encoding of the
control signal octet used by the MSC (modem status command). The same
encoding is also used in convergence layer type 2 as described in chapter
5.5.2. Table 7 and 24 both require the DV (data valid) bit to be set 1 for
outgoing control signal octets sent by the DTE (data terminal equipment),
i.e. for the initiator side.
Currently, the DV bit is only set if CD (carrier detect) is on, regardless
of the side.
This patch fixes this behavior by setting the DV bit on the initiator side
unconditionally.
Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Cc: [email protected]
Signed-off-by: Daniel Starke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/n_gsm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -440,7 +440,7 @@ static u8 gsm_encode_modem(const struct
modembits |= MDM_RTR;
if (dlci->modem_tx & TIOCM_RI)
modembits |= MDM_IC;
- if (dlci->modem_tx & TIOCM_CD)
+ if (dlci->modem_tx & TIOCM_CD || dlci->gsm->initiator)
modembits |= MDM_DV;
return modembits;
}
From: Helge Deller <[email protected]>
commit a97279836867b1cb50a3d4f0b1bf60e0abe6d46c upstream.
Fix 3 bugs:
a) emulate_stw() doesn't return the error code value, so faulting
instructions are not reported and aborted.
b) Tell emulate_ldw() to handle fldw_l as floating point instruction
c) Tell emulate_ldw() to handle ldw_m as integer instruction
Signed-off-by: Helge Deller <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/kernel/unaligned.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/parisc/kernel/unaligned.c
+++ b/arch/parisc/kernel/unaligned.c
@@ -354,7 +354,7 @@ static int emulate_stw(struct pt_regs *r
: "r" (val), "r" (regs->ior), "r" (regs->isr)
: "r19", "r20", "r21", "r22", "r1", FIXUP_BRANCH_CLOBBER );
- return 0;
+ return ret;
}
static int emulate_std(struct pt_regs *regs, int frreg, int flop)
{
@@ -634,10 +634,10 @@ void handle_unaligned(struct pt_regs *re
{
case OPCODE_FLDW_L:
flop=1;
- ret = emulate_ldw(regs, R2(regs->iir),0);
+ ret = emulate_ldw(regs, R2(regs->iir), 1);
break;
case OPCODE_LDW_M:
- ret = emulate_ldw(regs, R2(regs->iir),1);
+ ret = emulate_ldw(regs, R2(regs->iir), 0);
break;
case OPCODE_FSTW_L:
From: Helge Deller <[email protected]>
commit dd2288f4a020d693360e3e8d72f8b9d9c25f5ef6 upstream.
Usually the kernel provides fixup routines to emulate the fldd and fstd
floating-point instructions if they load or store 8-byte from/to a not
natuarally aligned memory location.
On a 32-bit kernel I noticed that those unaligned handlers didn't worked and
instead the application got a SEGV.
While checking the code I found two problems:
First, the OPCODE_FLDD_L and OPCODE_FSTD_L cases were ifdef'ed out by the
CONFIG_PA20 option, and as such those weren't built on a pure 32-bit kernel.
This is now fixed by moving the CONFIG_PA20 #ifdef to prevent the compilation
of OPCODE_LDD_L and OPCODE_FSTD_L only, and handling the fldd and fstd
instructions.
The second problem are two bugs in the 32-bit inline assembly code, where the
wrong registers where used. The calculation of the natural alignment used %2
(vall) instead of %3 (ior), and the first word was stored back to address %1
(valh) instead of %3 (ior).
Signed-off-by: Helge Deller <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/kernel/unaligned.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/parisc/kernel/unaligned.c
+++ b/arch/parisc/kernel/unaligned.c
@@ -411,7 +411,7 @@ static int emulate_std(struct pt_regs *r
__asm__ __volatile__ (
" mtsp %4, %%sr1\n"
" zdep %2, 29, 2, %%r19\n"
-" dep %%r0, 31, 2, %2\n"
+" dep %%r0, 31, 2, %3\n"
" mtsar %%r19\n"
" zvdepi -2, 32, %%r19\n"
"1: ldw 0(%%sr1,%3),%%r20\n"
@@ -423,7 +423,7 @@ static int emulate_std(struct pt_regs *r
" andcm %%r21, %%r19, %%r21\n"
" or %1, %%r20, %1\n"
" or %2, %%r21, %2\n"
-"3: stw %1,0(%%sr1,%1)\n"
+"3: stw %1,0(%%sr1,%3)\n"
"4: stw %%r1,4(%%sr1,%3)\n"
"5: stw %2,8(%%sr1,%3)\n"
" copy %%r0, %0\n"
@@ -611,7 +611,6 @@ void handle_unaligned(struct pt_regs *re
ret = ERR_NOTHANDLED; /* "undefined", but lets kill them. */
break;
}
-#ifdef CONFIG_PA20
switch (regs->iir & OPCODE2_MASK)
{
case OPCODE_FLDD_L:
@@ -622,14 +621,15 @@ void handle_unaligned(struct pt_regs *re
flop=1;
ret = emulate_std(regs, R2(regs->iir),1);
break;
+#ifdef CONFIG_PA20
case OPCODE_LDD_L:
ret = emulate_ldd(regs, R2(regs->iir),0);
break;
case OPCODE_STD_L:
ret = emulate_std(regs, R2(regs->iir),0);
break;
- }
#endif
+ }
switch (regs->iir & OPCODE3_MASK)
{
case OPCODE_FLDW_L:
On Mon, 28 Feb 2022 at 22:58, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.14.269 release.
> There are 31 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, 02 Mar 2022 17:20:16 +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.269-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.269-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.14.y
* git commit: 43ab82ea0bf0a7b6afb31831af7cefaa3e21c9d6
* git describe: v4.14.268-32-g43ab82ea0bf0
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.268-32-g43ab82ea0bf0
## Test Regressions (compared to v4.14.268)
No test regressions found.
## Metric Regressions (compared to v4.14.268)
No metric regressions found.
## Test Fixes (compared to v4.14.268)
No test fixes found.
## Metric Fixes (compared to v4.14.268)
No metric fixes found.
## Test result summary
total: 79045, pass: 65997, fail: 354, skip: 11390, xfail: 1304
## Build Summary
* arm: 280 total, 270 passed, 10 failed
* arm64: 35 total, 35 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 19 total, 19 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* powerpc: 60 total, 12 passed, 48 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 34 total, 34 passed, 0 failed
## Test suites summary
* fwts
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
On Mon, Feb 28, 2022 at 06:23:56PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.269 release.
> There are 31 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, 02 Mar 2022 17:20:16 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 424 pass: 424 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Mon, Feb 28, 2022, at 12:23 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.269 release.
> There are 31 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, 02 Mar 2022 17:20:16 +0000.
> Anything received after that time might be too late.
4.14.269-rc1 compiled and booted with no errors or regressions on my x86_64 test system.
Tested-by: Slade Watkins <[email protected]>
Cheers,
Slade