4.14.281-rc1 review
Greg Kroah-Hartman
maintainercover 4.14.281-rc1 review
This is the start of the stable review cycle for the 4.14.281 release. There are 33 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, 25 May 2022 16:56:55 +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.281-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.281-rc1
Linus Torvalds <[email protected]>
Reinstate some of "swiotlb: rework "fix info leak with DMA_FROM_DEVICE""
Halil Pasic <[email protected]>
swiotlb: fix info leak with DMA_FROM_DEVICE
Grant Grundler <[email protected]>
net: atlantic: verify hw_head_ lies within TX buffer ring
Yang Yingliang <[email protected]>
net: stmmac: fix missing pci_disable_device() on error in stmmac_pci_probe()
Yang Yingliang <[email protected]>
ethernet: tulip: fix missing pci_disable_device() on error in tulip_init_one()
Felix Fietkau <[email protected]>
mac80211: fix rx reordering with non explicit / psmp ack policy
Gleb Chesnokov <[email protected]>
scsi: qla2xxx: Fix missed DMA unmap for aborted commands
Thomas Richter <[email protected]>
perf bench numa: Address compiler error on s390
Uwe Kleine-König <[email protected]>
gpio: mvebu/pwm: Refuse requests with inverted polarity
Haibo Chen <[email protected]>
gpio: gpio-vf610: do not touch other bits when set the target bit
Andrew Lunn <[email protected]>
net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.
Kevin Mitchell <[email protected]>
igb: skip phy status check where unavailable
Ard Biesheuvel <[email protected]>
ARM: 9197/1: spectre-bhb: fix loop8 sequence for Thumb2
Ard Biesheuvel <[email protected]>
ARM: 9196/1: spectre-bhb: enable for Cortex-A15
Jiasheng Jiang <[email protected]>
net: af_key: add check for pfkey_broadcast in function pfkey_process
Duoming Zhou <[email protected]>
NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
Christophe JAILLET <[email protected]>
net/qla3xxx: Fix a test in ql_reset_work()
Codrin Ciubotariu <[email protected]>
clk: at91: generated: consider range when calculating best rate
Zixuan Fu <[email protected]>
net: vmxnet3: fix possible NULL pointer dereference in vmxnet3_rq_cleanup()
Zixuan Fu <[email protected]>
net: vmxnet3: fix possible use-after-free bugs in vmxnet3_rq_alloc_rx_buf()
Ulf Hansson <[email protected]>
mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()
Ulf Hansson <[email protected]>
mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
Ulf Hansson <[email protected]>
mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
Hangyu Hua <[email protected]>
drm/dp/mst: fix a possible memory leak in fetch_monitor_name()
Peter Zijlstra <[email protected]>
perf: Fix sys_perf_event_open() race against self
Takashi Iwai <[email protected]>
ALSA: wavefront: Proper check of get_user() error
linyujun <[email protected]>
ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()
Jakob Koschel <[email protected]>
drbd: remove usage of list iterator variable after loop
Xiaoke Wang <[email protected]>
MIPS: lantiq: check the return value of kzalloc()
Zheng Yongjun <[email protected]>
Input: stmfts - fix reference leak in stmfts_input_open
Jeff LaBundy <[email protected]>
Input: add bounds checking to input_set_capability()
David Gow <[email protected]>
um: Cleanup syscall_handler_t definition/cast, fix warning
Willy Tarreau <[email protected]>
floppy: use a statically allocated error counter
-------------
Diffstat:
Makefile | 4 +- arch/arm/kernel/entry-armv.S | 2 +- arch/arm/kernel/stacktrace.c | 10 ++--- arch/arm/mm/proc-v7-bugs.c | 1 + arch/mips/lantiq/falcon/sysctrl.c | 2 + arch/mips/lantiq/xway/gptu.c | 2 + arch/mips/lantiq/xway/sysctrl.c | 46 ++++++++++++++-------- arch/x86/um/shared/sysdep/syscalls_64.h | 5 +-- drivers/block/drbd/drbd_main.c | 7 +++- drivers/block/floppy.c | 17 ++++---- drivers/clk/at91/clk-generated.c | 4 ++ drivers/gpio/gpio-mvebu.c | 3 ++ drivers/gpio/gpio-vf610.c | 8 +++- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/input/input.c | 19 +++++++++ drivers/input/touchscreen/stmfts.c | 8 ++-- drivers/mmc/core/block.c | 6 +-- drivers/mmc/core/mmc_ops.c | 27 +++++++------ .../ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 7 ++++ drivers/net/ethernet/dec/tulip/tulip_core.c | 5 ++- drivers/net/ethernet/intel/igb/igb_main.c | 3 +- drivers/net/ethernet/qlogic/qla3xxx.c | 3 +- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +- drivers/net/vmxnet3/vmxnet3_drv.c | 6 +++ drivers/scsi/qla2xxx/qla_target.c | 3 ++ kernel/events/core.c | 14 +++++++ lib/swiotlb.c | 12 ++++-- net/bridge/br_input.c | 7 ++++ net/key/af_key.c | 6 ++- net/mac80211/rx.c | 3 +- net/nfc/nci/data.c | 2 +- net/nfc/nci/hci.c | 4 +- sound/isa/wavefront/wavefront_synth.c | 3 +- tools/perf/bench/numa.c | 2 +- 34 files changed, 177 insertions(+), 79 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/33 floppy: use a statically allocated error counter
From: Willy Tarreau <[email protected]>
commit f71f01394f742fc4558b3f9f4c7ef4c4cf3b07c8 upstream.
Interrupt handler bad_flp_intr() may cause a UAF on the recently freed request just to increment the error count. There's no point keeping that one in the request anyway, and since the interrupt handler uses a static pointer to the error which cannot be kept in sync with the pending request, better make it use a static error counter that's reset for each new request. This reset now happens when entering redo_fd_request() for a new request via set_next_request().
One initial concern about a single error counter was that errors on one floppy drive could be reported on another one, but this problem is not real given that the driver uses a single drive at a time, as that PC-compatible controllers also have this limitation by using shared signals. As such the error count is always for the "current" drive.
--- drivers/block/floppy.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-)
drivers/block/floppy.c +7 -10
@@ -516,8 +516,8 @@ static unsigned long fdc_busy;static DECLARE_WAIT_QUEUE_HEAD (fdc_wait);static DECLARE_WAIT_QUEUE_HEAD (command_done); -/* Errors during formatting are counted here. */ -static int format_errors; +/* errors encountered on the current (or last) request */ +static int floppy_errors;/* Format request descriptor. */ static struct format_descr format_req;
@@ -537,7 +537,6 @@ static struct format_descr format_req;static char *floppy_track_buffer;static int max_buffer_sectors; -static int *errors;typedef void (*done_f )(int ); static const struct cont_t { void (*interrupt)(void);
@@ -1426,7 +1425,7 @@ static int interpret_errors(void)if (DP ->flags &FTD_MSG )DPRINT ("Over/Underrun - retrying\n" ); bad =0 ; - }else if (*errors >=DP ->max_errors.reporting) { + }else if (floppy_errors >=DP ->max_errors.reporting) {print_errors (); }if (ST2 &ST2_WC ||ST2 &ST2_BC )
@@ -2049,7 +2048,7 @@ static void bad_flp_intr(void)if (!next_valid_format ())return ; } - err_count = ++(*errors); + err_count = ++floppy_errors;INFBOUND (DRWE ->badness, err_count);if (err_count >DP ->max_errors.abort) cont->done (0 );
@@ -2194,9 +2193,8 @@ static int do_format(int drive, struct freturn -EINVAL ; } format_req = *tmp_format_req; - format_errors =0 ; cont = &format_cont; - errors = &format_errors; + floppy_errors =0 ; ret =wait_til_done (redo_format, true);if (ret == -EINTR )return -EINTR ;
@@ -2679,7 +2677,7 @@ static int make_raw_rw_request(void)*/ if (!direct || (indirect *2 > direct *3 && - *errors <DP ->max_errors.read_track && + floppy_errors <DP ->max_errors.read_track && ((!probing || (DP ->read_track & (1 <<DRS ->probed_format)))))) { max_size =blk_rq_sectors (current_req);
@@ -2813,7 +2811,7 @@ static int set_next_request(void)if (q) { current_req =blk_fetch_request (q);if (current_req) { - current_req->error_count =0 ; + floppy_errors =0 ;break ; } }
@@ -2875,7 +2873,6 @@ do_request: _floppy = floppy_type +DP ->autodetect[DRS ->probed_format]; }else probing =0 ; - errors = &(current_req->error_count); tmp =make_raw_rw_request ();if (tmp <2 ) {request_done (tmp);
Greg Kroah-Hartman
maintainerPATCH 2/33 um: Cleanup syscall_handler_t definition/cast, fix warning
In reply to Greg Kroah-HartmanFrom: David Gow <[email protected]>
[ Upstream commit f4f03f299a56ce4d73c5431e0327b3b6cb55ebb9 ]
The syscall_handler_t type for x86_64 was defined as 'long (*)(void)', but always cast to 'long (*)(long, long, long, long, long, long)' before use. This now triggers a warning (see below).
Define syscall_handler_t as the latter instead, and remove the cast. This simplifies the code, and fixes the warning.
Warning:
In file included from ../arch/um/include/asm/processor-generic.h:13
from ../arch/x86/um/asm/processor.h:41
from ../include/linux/rcupdate.h:30
from ../include/linux/rculist.h:11
from ../include/linux/pid.h:5
from ../include/linux/sched.h:14
from ../include/linux/ptrace.h:6
from ../arch/um/kernel/skas/syscall.c:7:../arch/um/kernel/skas/syscall.c: In function ‘handle_syscall’:../arch/x86/um/shared/sysdep/syscalls_64.h:18:11: warning: cast between incompatible function types from ‘long int (*)(void)’ to ‘long int (*)(long int, long int, long int, long int, long int, long int)’ [ -Wcast-function-type]
18 | (((long (*)(long, long, long, long, long, long)) \
| ^../arch/x86/um/asm/ptrace.h:36:62: note: in definition of macro ‘PT_REGS_SET_SYSCALL_RETURN’
36 | #define PT_REGS_SET_SYSCALL_RETURN(r, res) (PT_REGS_AX(r) = (res))
| ^~~../arch/um/kernel/skas/syscall.c:46:33: note: in expansion of macro ‘EXECUTE_SYSCALL’
46 | EXECUTE_SYSCALL(syscall, regs));
| ^~~~~~~~~~~~~~~--- arch/x86/um/shared/sysdep/syscalls_64.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
arch/x86/um/shared/sysdep/syscalls_64.h +2 -3
@@ -10,13 +10,12 @@#include <linux/msg.h> #include <linux/shm.h> -typedef long syscall_handler_t (void ); +typedef long syscall_handler_t (long ,long ,long ,long ,long ,long );extern syscall_handler_t *sys_call_table[];#define EXECUTE_SYSCALL (syscall, regs) \ - (((long (*)(long, long, long, long, long, long)) \ - (*sys_call_table[syscall]))(UPT_SYSCALL_ARG1(®s->regs), \ + (((*sys_call_table[syscall]))(UPT_SYSCALL_ARG1(®s->regs), \ UPT_SYSCALL_ARG2(®s->regs), \ UPT_SYSCALL_ARG3(®s->regs), \ UPT_SYSCALL_ARG4(®s->regs), \
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 3/33 Input: add bounds checking to input_set_capability()
In reply to Greg Kroah-HartmanFrom: Jeff LaBundy <[email protected]>
[ Upstream commit 409353cbe9fe48f6bc196114c442b1cff05a39bc ]
Update input_set_capability() to prevent kernel panic in case the event code exceeds the bitmap for the given event type.
--- drivers/input/input.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
drivers/input/input.c +19 -0
@@ -50,6 +50,17 @@ static DEFINE_MUTEX(input_mutex);static const struct input_value input_value_sync = {EV_SYN ,SYN_REPORT ,1 }; +static const unsigned int input_max_code[EV_CNT ] = { + [EV_KEY ] =KEY_MAX , + [EV_REL ] =REL_MAX , + [EV_ABS ] =ABS_MAX , + [EV_MSC ] =MSC_MAX , + [EV_SW ] =SW_MAX , + [EV_LED ] =LED_MAX , + [EV_SND ] =SND_MAX , + [EV_FF ] =FF_MAX , +}; +static inline int is_event_supported (unsigned int code,unsigned long *bm,unsigned int max) {
@@ -1915,6 +1926,14 @@ EXPORT_SYMBOL(input_free_device);*/ void input_set_capability (struct input_dev *dev,unsigned int type,unsigned int code) { +if (type <EV_CNT && input_max_code[type] && + code > input_max_code[type]) { +pr_err ("%s: invalid code %u for type %u\n" , __func__, code, + type); +dump_stack (); +return ; + } +switch (type) {case EV_KEY :__set_bit (code, dev->keybit);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 4/33 Input: stmfts - fix reference leak in stmfts_input_open
In reply to Greg Kroah-HartmanFrom: Zheng Yongjun <[email protected]>
[ Upstream commit 26623eea0da3476446909af96c980768df07bbd9 ]
pm_runtime_get_sync() will increment pm usage counter even it failed. Forgetting to call pm_runtime_put_noidle will result in reference leak in stmfts_input_open, so we should fix it.
--- drivers/input/touchscreen/stmfts.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/input/touchscreen/stmfts.c +5 -3
@@ -344,11 +344,11 @@ static int stmfts_input_open(struct input_dev *dev) err =pm_runtime_get_sync (&sdata->client->dev);if (err <0 ) -return err; + goto out; err =i2c_smbus_write_byte (sdata->client,STMFTS_MS_MT_SENSE_ON );if (err) -return err; + goto out;mutex_lock (&sdata->mutex); sdata->running = true;
@@ -371,7 +371,9 @@ static int stmfts_input_open(struct input_dev *dev) "failed to enable touchkey\n"); } -return 0 ; +out: +pm_runtime_put_noidle (&sdata->client->dev); +return err; }static void stmfts_input_close (struct input_dev *dev)
Signature · 1 line
2.35.1
Re: [PATCH 4.14 04/33] Input: stmfts - fix reference leak in stmfts_input_open
Hi!
Quoted 7 lines
From: Zheng Yongjun <[email protected]>
[ Upstream commit
26623eea0da3476446909af96c980768df07bbd9]
pm_runtime_get_sync()will increment pm usage counter even it failed. Forgetting to callpm_runtime_put_noidlewill result in reference leak instmfts_input_open, so we should fix it.
This is wrong, AFAICT.
Quoted 22 lines
drivers/input/touchscreen/stmfts.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)drivers/input/touchscreen/stmfts.c +2
-2@@ -344,11 +344,11 @@ static int stmfts_input_open(struct input_dev *dev) err =pm_runtime_get_sync (&sdata->client->dev);if (err <0 ) -return err; + goto out; err =i2c_smbus_write_byte (sdata->client,STMFTS_MS_MT_SENSE_ON );if (err) -return err; + goto out;mutex_lock (&sdata->mutex); sdata->running = true;
drivers/input/touchscreen/stmfts.c static int stmfts_input_open(struct input_dev *dev) · line 379
Quoted 10 lines
drivers/input/touchscreen/stmfts.c +3
-1@@ -371,7 +371,9 @@ static int stmfts_input_open(struct input_dev *dev) "failed to enable touchkey\n"); } -return 0 ; +out: +pm_runtime_put_noidle (&sdata->client->dev); +return err; }static void stmfts_input_close (struct input_dev *dev)
We are now doing put even on the success path. That will break the device... and will result in non-functional device and double put due to the close path.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: [PATCH 4.14 04/33] Input: stmfts - fix reference leak in stmfts_input_open
Quoted 11 lines · Pavel Machek
Hi!
Quoted 7 lines
From: Zheng Yongjun <[email protected]>
[ Upstream commit
26623eea0da3476446909af96c980768df07bbd9]
pm_runtime_get_sync()will increment pm usage counter even it failed. Forgetting to callpm_runtime_put_noidlewill result in reference leak instmfts_input_open, so we should fix it.This is wrong, AFAICT.
Yes, I think you are right. How about below?
Thanks.
Signature · 22 lines
Dmitry Input: stmfts - do not leave device disabled in stmfts_input_open From: Dmitry Torokhov <[email protected]> The commit 26623eea0da3 attempted to deal with potential leak of runtime PM counter when opening the touchscreen device, however it ended up erroneously dropping the counter in the case of successfully enabling the device. Let's address this by using pm_runtime_resume_and_get() and then executing pm_runtime_put_sync() only when we fail to send "sense on" command to the device. Fixes: 26623eea0da3 ("Input: stmfts - fix reference leak in stmfts_input_open") Reported-by: Pavel Machek <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> --- drivers/input/touchscreen/stmfts.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/input/touchscreen/stmfts.c +8 -8
@@ -337,13 +337,15 @@ static int stmfts_input_open(struct input_dev *dev)struct stmfts_data *sdata =input_get_drvdata (dev);int err; - err =pm_runtime_get_sync (&sdata->client->dev); -if (err <0 ) - goto out; + err =pm_runtime_resume_and_get (&sdata->client->dev); +if (err) +return err; err =i2c_smbus_write_byte (sdata->client,STMFTS_MS_MT_SENSE_ON ); -if (err) - goto out; +if (err) { +pm_runtime_put_sync (&sdata->client->dev); +return err; + }mutex_lock (&sdata->mutex); sdata->running = true;
@@ -366,9 +368,7 @@ static int stmfts_input_open(struct input_dev *dev) "failed to enable touchkey\n"); } -out: -pm_runtime_put_noidle (&sdata->client->dev); -return err; +return 0 ; }static void stmfts_input_close (struct input_dev *dev)
Pavel Machek
Reviewed-byRe: [PATCH 4.14 04/33] Input: stmfts - fix reference leak in stmfts_input_open
Hi!
Quoted 11 lines
Quoted 9 lines
Quoted 7 lines
From: Zheng Yongjun <[email protected]>
[ Upstream commit
26623eea0da3476446909af96c980768df07bbd9]
pm_runtime_get_sync()will increment pm usage counter even it failed. Forgetting to callpm_runtime_put_noidlewill result in reference leak instmfts_input_open, so we should fix it.This is wrong, AFAICT.
Yes, I think you are right. How about below?
Looks good to me.
Quoted 9 lines
Input: stmfts - do not leave device disabled in
stmfts_input_openFrom: Dmitry Torokhov <[email protected]>
The commit
26623eea0da3attempted to deal with potential leak of runtime PM counter when opening the touchscreen device, however it ended up erroneously dropping the counter in the case of successfully enabling the device.
Quoted 5 lines
Let's address this by using
pm_runtime_resume_and_get()and then executingpm_runtime_put_sync()only when we fail to send "sense on" command to the device.Fixes 26623eea0da3 ("Input: stmfts - fix reference leak in stmfts_input_open")
Thank you,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Greg Kroah-Hartman
maintainerPATCH 5/33 MIPS: lantiq: check the return value of kzalloc()
In reply to Greg Kroah-HartmanFrom: Xiaoke Wang <[email protected]>
[ Upstream commit 34123208bbcc8c884a0489f543a23fe9eebb5514 ]
kzalloc() is a memory allocation function which can return NULL when some internal memory errors happen. So it is better to check the return value of it to prevent potential wrong memory access or memory leak.
--- arch/mips/lantiq/falcon/sysctrl.c | 2 ++ arch/mips/lantiq/xway/gptu.c | 2 ++ arch/mips/lantiq/xway/sysctrl.c | 46 ++++++++++++++++++++----------- 3 files changed, 34 insertions(+), 16 deletions(-)
arch/mips/lantiq/falcon/sysctrl.c +2 -0
@@ -169,6 +169,8 @@ static inline void clkdev_add_sys(const char *dev, unsigned int module, {struct clk *clk =kzalloc (sizeof (struct clk ),GFP_KERNEL ); +if (!clk) +return ; clk->cl.dev_id = dev; clk->cl.con_id =NULL ; clk->cl.clk = clk;
arch/mips/lantiq/xway/gptu.c +2 -0
@@ -124,6 +124,8 @@ static inline void clkdev_add_gptu(struct device *dev, const char *con, {struct clk *clk =kzalloc (sizeof (struct clk ),GFP_KERNEL ); +if (!clk) +return ; clk->cl.dev_id =dev_name (dev); clk->cl.con_id = con; clk->cl.clk = clk;
arch/mips/lantiq/xway/sysctrl.c +30 -16
75 lines not on this page · raw message
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 6/33 drbd: remove usage of list iterator variable after loop
In reply to Greg Kroah-HartmanFrom: Jakob Koschel <[email protected]>
[ Upstream commit 901aeda62efa21f2eae937bccb71b49ae531be06 ]
In preparation to limit the scope of a list iterator to the list traversal loop, use a dedicated pointer to iterate through the list [1].
Since that variable should not be used past the loop iteration, a separate variable is used to 'remember the current location within the loop'.
To either continue iterating from that position or skip the iteration (if the previous iteration was complete) list_prepare_entry() is used.
--- drivers/block/drbd/drbd_main.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/block/drbd/drbd_main.c +5 -2
@@ -195,7 +195,7 @@ void tl_release(struct drbd_connection *connection, unsigned int barrier_nr, unsigned int set_size) {struct drbd_request *r; -struct drbd_request *req =NULL ; +struct drbd_request *req =NULL , *tmp =NULL ;int expect_epoch =0 ;int expect_size =0 ;
@@ -249,8 +249,11 @@ void tl_release(struct drbd_connection *connection, unsigned int barrier_nr,* to catch requests being barrier-acked "unexpectedly". * It usually should find the same req again, or some READ preceding it. */ list_for_each_entry (req, &connection->transfer_log, tl_requests) -if (req->epoch == expect_epoch) +if (req->epoch == expect_epoch) { + tmp = req;break ; + } + req =list_prepare_entry (tmp, &connection->transfer_log, tl_requests);list_for_each_entry_safe_from (req, r, &connection->transfer_log, tl_requests) {if (req->epoch != expect_epoch)break ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 7/33 ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()
In reply to Greg Kroah-HartmanFrom: linyujun <[email protected]>
[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]
The following KASAN warning is detected by QEMU.
==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870 Read of size 4 at addr c36bba90 by task cat/163 CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 #40 Hardware name: ARM-Versatile Express [<c0113fac>] (unwind_backtrace) from [<c010e71c>] (show_stack+0x10/0x14) [<c010e71c>] (show_stack) from [<c0b805b4>] (dump_stack+0x98/0xb0) [<c0b805b4>] (dump_stack) from [<c0b7d658>] (print_address_description.constprop.0+0x58/0x4bc) [<c0b7d658>] (print_address_description.constprop.0) from [<c031435c>] (kasan_report+0x154/0x170) [<c031435c>] (kasan_report) from [<c0113c44>] (unwind_frame+0x508/0x870) [<c0113c44>] (unwind_frame) from [<c010e298>] (__save_stack_trace+0x110/0x134) [<c010e298>] (__save_stack_trace) from [<c01ce0d8>] (stack_trace_save+0x8c/0xb4) [<c01ce0d8>] (stack_trace_save) from [<c0313520>] (kasan_set_track+0x38/0x60) [<c0313520>] (kasan_set_track) from [<c0314cb8>] (kasan_set_free_info+0x20/0x2c) [<c0314cb8>] (kasan_set_free_info) from [<c0313474>] (__kasan_slab_free+0xec/0x120) [<c0313474>] (__kasan_slab_free) from [<c0311e20>] (kmem_cache_free+0x7c/0x334) [<c0311e20>] (kmem_cache_free) from [<c01c35dc>] (rcu_core+0x390/0xccc) [<c01c35dc>] (rcu_core) from [<c01013a8>] (__do_softirq+0x180/0x518) [<c01013a8>] (__do_softirq) from [<c0135214>] (irq_exit+0x9c/0xe0) [<c0135214>] (irq_exit) from [<c01a40e4>] (__handle_domain_irq+0xb0/0x110) [<c01a40e4>] (__handle_domain_irq) from [<c0691248>] (gic_handle_irq+0xa0/0xb8) [<c0691248>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x94) Exception stack(0xc36bb928 to 0xc36bb970)
b920: c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[<c0100b0c>] (__irq_svc) from [<c011373c>] (unwind_frame+0x0/0x870) [<c011373c>] (unwind_frame) from [<00000000>] (0x0)
The buggy address belongs to the page: page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb flags: 0x0() raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000 page dumped because: kasan: bad access detected
addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
stack_trace_save+0x0/0xb4
this frame has 1 object:
[32, 48) 'trace'
Memory state around the buggy address:
c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
^
c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================There is a same issue on x86 and has been resolved by the commit f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.
--- arch/arm/kernel/stacktrace.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
arch/arm/kernel/stacktrace.c +5 -5
@@ -51,17 +51,17 @@ int notrace unwind_frame(struct stackframe *frame)return -EINVAL ; frame->sp = frame->fp; - frame->fp = *(unsigned long *)(fp); - frame->pc = *(unsigned long *)(fp +4 ); + frame->fp =READ_ONCE_NOCHECK (*(unsigned long *)(fp)); + frame->pc =READ_ONCE_NOCHECK (*(unsigned long *)(fp +4 ));#else /* check current frame pointer is within bounds */ if (fp < low +12 || fp > high -4 )return -EINVAL ;/* restore the registers from the stack frame */ - frame->fp = *(unsigned long *)(fp -12 ); - frame->sp = *(unsigned long *)(fp -8 ); - frame->pc = *(unsigned long *)(fp -4 ); + frame->fp =READ_ONCE_NOCHECK (*(unsigned long *)(fp -12 )); + frame->sp =READ_ONCE_NOCHECK (*(unsigned long *)(fp -8 )); + frame->pc =READ_ONCE_NOCHECK (*(unsigned long *)(fp -4 ));#endif return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 8/33 ALSA: wavefront: Proper check of get_user() error
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit a34ae6c0660d3b96b0055f68ef74dc9478852245 upstream.
The antient ISA wavefront driver reads its sample patch data (uploaded over an ioctl) via __get_user() with no good reason; likely just for some performance optimizations in the past. Let's change this to the standard get_user() and the error check for handling the fault case properly.
--- sound/isa/wavefront/wavefront_synth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/isa/wavefront/wavefront_synth.c +2 -1
@@ -1092,7 +1092,8 @@ wavefront_send_sample (snd_wavefront_t *if (dataptr < data_end) { -__get_user (sample_short, dataptr); +if (get_user (sample_short, dataptr)) +return -EFAULT ; dataptr += skip;if (data_is_unsigned) {/* GUS ? */
Greg Kroah-Hartman
maintainerPATCH 9/33 perf: Fix sys_perf_event_open() race against self
In reply to Greg Kroah-HartmanFrom: Peter Zijlstra <[email protected]>
commit 3ac6487e584a1eb54071dbe1212e05b884136704 upstream.
Norbert reported that it's possible to race sys_perf_event_open() such that the looser ends up in another context from the group leader, triggering many WARNs.
The move_group case checks for races against itself, but the !move_group case doesn't, seemingly relying on the previous group_leader->ctx == ctx check. However, that check is racy due to not holding any locks at that time.
Therefore, re-check the result after acquiring locks and bailing if they no longer match.
Additionally, clarify the not_move_group case from the move_group-vs-move_group race.
--- kernel/events/core.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
kernel/events/core.c +14 -0
@@ -10228,6 +10228,9 @@ SYSCALL_DEFINE5(perf_event_open,* Do not allow to attach to a group in a different task * or CPU context. If we're moving SW events, we'll fix * this up later, so allow that. +* +* Racy, not holding group_leader->ctx->mutex, see comment with +* perf_event_ctx_lock(). */ if (!move_group && group_leader->ctx != ctx) goto err_context;
@@ -10277,11 +10280,22 @@ SYSCALL_DEFINE5(perf_event_open, }else {perf_event_ctx_unlock (group_leader, gctx); move_group =0 ; + goto not_move_group; } } }else {mutex_lock (&ctx->mutex); + +/* +* Now that we hold ctx->lock, (re)validate group_leader->ctx == ctx, +* see the group_leader && !move_group test earlier. +*/ +if (group_leader && group_leader->ctx != ctx) { + err = -EINVAL ; + goto err_locked; + } } +not_move_group:if (ctx->task ==TASK_TOMBSTONE ) { err = -ESRCH ;
Greg Kroah-Hartman
maintainerPATCH 10/33 drm/dp/mst: fix a possible memory leak in fetch_monitor_name()
In reply to Greg Kroah-HartmanFrom: Hangyu Hua <[email protected]>
commit 6e03b13cc7d9427c2c77feed1549191015615202 upstream.
drm_dp_mst_get_edid call kmemdup to create mst_edid. So mst_edid need to be freed after use.
--- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/drm_dp_mst_topology.c +1 -0
@@ -2910,6 +2910,7 @@ static void fetch_monitor_name(struct dr mst_edid =drm_dp_mst_get_edid (port->connector, mgr, port);drm_edid_get_monitor_name (mst_edid, name, namelen); +kfree (mst_edid); }/**
Greg Kroah-Hartman
maintainerPATCH 11/33 mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
In reply to Greg Kroah-HartmanFrom: Ulf Hansson <[email protected]>
commit 24ed3bd01d6a844fd5e8a75f48d0a3d10ed71bf9 upstream
The timeout values used while waiting for a CMD6 for BKOPS or a CACHE_FLUSH to complete, are not defined by the eMMC spec. However, a timeout of 10 minutes as is currently being used, is just silly for both of these cases. Instead, let's specify more reasonable timeouts, 120s for BKOPS and 30s for CACHE_FLUSH.
--- drivers/mmc/core/mmc_ops.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/mmc/core/mmc_ops.c +6 -3
@@ -23,7 +23,9 @@#include "host.h" #include "mmc_ops.h" -#define MMC_OPS_TIMEOUT_MS (10 * 60 * 1000)/* 10 minute timeout */ +#define MMC_OPS_TIMEOUT_MS (10 * 60 * 1000)/* 10min*/ +#define MMC_BKOPS_TIMEOUT_MS (120 * 1000)/* 120s */ +#define MMC_CACHE_FLUSH_TIMEOUT_MS (30 * 1000)/* 30s */ static const u8 tuning_blk_pattern_4bit[] = {0xff ,0x0f ,0xff ,0x00 ,0xff ,0xcc ,0xc3 ,0xcc ,
@@ -979,7 +981,7 @@ void mmc_start_bkops(struct mmc_card *cammc_claim_host (card->host);if (card->ext_csd.raw_bkops_status >=EXT_CSD_BKOPS_LEVEL_2 ) { - timeout =MMC_OPS_TIMEOUT_MS ; + timeout =MMC_BKOPS_TIMEOUT_MS ; use_busy_signal = true; }else { timeout =0 ;
@@ -1022,7 +1024,8 @@ int mmc_flush_cache(struct mmc_card *car (card->ext_csd.cache_size > 0) && (card->ext_csd.cache_ctrl & 1)) { err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , -EXT_CSD_FLUSH_CACHE ,1 ,0 ); +EXT_CSD_FLUSH_CACHE ,1 , +MMC_CACHE_FLUSH_TIMEOUT_MS );if (err)pr_err ("%s: cache flush error %d\n" ,mmc_hostname (card->host), err);
Greg Kroah-Hartman
maintainerPATCH 12/33 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
In reply to Greg Kroah-HartmanFrom: Ulf Hansson <[email protected]>
commit ad91619aa9d78ab1c6d4a969c3db68bc331ae76c upstream
The INAND_CMD38_ARG_EXT_CSD is a vendor specific EXT_CSD register, which is used to prepare an erase/trim operation. However, it doesn't make sense to use a timeout of 10 minutes while updating the register, which becomes the case when the timeout_ms argument for mmc_switch() is set to zero.
Instead, let's use the generic_cmd6_time, as that seems like a reasonable timeout to use for these cases.
--- drivers/mmc/core/block.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mmc/core/block.c +3 -3
@@ -1345,7 +1345,7 @@ static void mmc_blk_issue_discard_rq(str arg ==MMC_TRIM_ARG ?INAND_CMD38_ARG_TRIM :INAND_CMD38_ARG_ERASE , - 0); + card->ext_csd.generic_cmd6_time); }if (!err) err =mmc_erase (card, from, nr, arg);
@@ -1387,7 +1387,7 @@ retry: arg ==MMC_SECURE_TRIM1_ARG ?INAND_CMD38_ARG_SECTRIM1 :INAND_CMD38_ARG_SECERASE , - 0); + card->ext_csd.generic_cmd6_time);if (err) goto out_retry; }
@@ -1405,7 +1405,7 @@ retry: err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL ,INAND_CMD38_ARG_EXT_CSD ,INAND_CMD38_ARG_SECTRIM2 , -0 ); + card->ext_csd.generic_cmd6_time);if (err) goto out_retry; }
Greg Kroah-Hartman
maintainerPATCH 13/33 mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()
In reply to Greg Kroah-HartmanFrom: Ulf Hansson <[email protected]>
commit 533a6cfe08f96a7b5c65e06d20916d552c11b256 upstream
All callers of __mmc_switch() should now be specifying a valid timeout for the CMD6 command. However, just to be sure, let's print a warning and default to use the generic_cmd6_time in case the provided timeout_ms argument is zero.
In this context, let's also simplify some of the corresponding code and clarify some related comments.
--- drivers/mmc/core/mmc_ops.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-)
drivers/mmc/core/mmc_ops.c +8 -10
@@ -458,10 +458,6 @@ static int mmc_poll_for_busy(struct mmc_bool expired = false;bool busy = false; -/* We have an unspecified cmd timeout, use the fallback value. */ -if (!timeout_ms) - timeout_ms =MMC_OPS_TIMEOUT_MS ; -/* * In cases when not allowed to poll by using CMD13 or because we aren't * capable of polling by using ->card_busy(), then rely on waiting the
@@ -534,14 +530,20 @@ int __mmc_switch(struct mmc_card *card,mmc_retune_hold (host); +if (!timeout_ms) { +pr_warn ("%s: unspecified timeout for CMD6 - use generic\n" , +mmc_hostname (host)); + timeout_ms = card->ext_csd.generic_cmd6_time; + } +/* * If the cmd timeout and the max_busy_timeout of the host are both * specified, let's validate them. A failure means we need to prevent * the host from doing hw busy detection, which is done by converting * to a R1 response instead of a R1B. */ -if (timeout_ms && host->max_busy_timeout && - (timeout_ms > host->max_busy_timeout)) +if (host->max_busy_timeout && + (timeout_ms > host->max_busy_timeout)) use_r1b_resp = false; cmd.opcode =MMC_SWITCH ;
@@ -552,10 +554,6 @@ int __mmc_switch(struct mmc_card *card, cmd.flags =MMC_CMD_AC ;if (use_r1b_resp) { cmd.flags |=MMC_RSP_SPI_R1B |MMC_RSP_R1B ; -/* -* A busy_timeout of zero means the host can decide to use -* whatever value it finds suitable. -*/ cmd.busy_timeout = timeout_ms; }else { cmd.flags |=MMC_RSP_SPI_R1 |MMC_RSP_R1 ;
Greg Kroah-Hartman
maintainerPATCH 14/33 net: vmxnet3: fix possible use-after-free bugs in vmxnet3_rq_alloc_rx_buf()
In reply to Greg Kroah-HartmanFrom: Zixuan Fu <[email protected]>
[ Upstream commit 9e7fef9521e73ca8afd7da9e58c14654b02dfad8 ]
In vmxnet3_rq_alloc_rx_buf(), when dma_map_single() fails, rbi->skb is freed immediately. Similarly, in another branch, when dma_map_page() fails, rbi->page is also freed. In the two cases, vmxnet3_rq_alloc_rx_buf() returns an error to its callers vmxnet3_rq_init() -> vmxnet3_rq_init_all() -> vmxnet3_activate_dev(). Then vmxnet3_activate_dev() calls vmxnet3_rq_cleanup_all() in error handling code, and rbi->skb or rbi->page are freed again in vmxnet3_rq_cleanup_all(), causing use-after-free bugs.
To fix these possible bugs, rbi->skb and rbi->page should be cleared after they are freed.
The error log in our fault-injection testing is shown as follows:
[ 14.319016] BUG: KASAN: use-after-free in consume_skb+0x2f/0x150 ... [ 14.321586] Call Trace: ... [ 14.325357] consume_skb+0x2f/0x150 [ 14.325671] vmxnet3_rq_cleanup_all+0x33a/0x4e0 [vmxnet3] [ 14.326150] vmxnet3_activate_dev+0xb9d/0x2ca0 [vmxnet3] [ 14.326616] vmxnet3_open+0x387/0x470 [vmxnet3] ... [ 14.361675] Allocated by task 351: ... [ 14.362688] __netdev_alloc_skb+0x1b3/0x6f0 [ 14.362960] vmxnet3_rq_alloc_rx_buf+0x1b0/0x8d0 [vmxnet3] [ 14.363317] vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3] [ 14.363661] vmxnet3_open+0x387/0x470 [vmxnet3] ... [ 14.367309] [ 14.367412] Freed by task 351: ... [ 14.368932] __dev_kfree_skb_any+0xd2/0xe0 [ 14.369193] vmxnet3_rq_alloc_rx_buf+0x71e/0x8d0 [vmxnet3] [ 14.369544] vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3] [ 14.369883] vmxnet3_open+0x387/0x470 [vmxnet3] [ 14.370174] __dev_open+0x28a/0x420 [ 14.370399] __dev_change_flags+0x192/0x590 [ 14.370667] dev_change_flags+0x7a/0x180 [ 14.370919] do_setlink+0xb28/0x3570 [ 14.371150] rtnl_newlink+0x1160/0x1740 [ 14.371399] rtnetlink_rcv_msg+0x5bf/0xa50 [ 14.371661] netlink_rcv_skb+0x1cd/0x3e0 [ 14.371913] netlink_unicast+0x5dc/0x840 [ 14.372169] netlink_sendmsg+0x856/0xc40 [ 14.372420] ____sys_sendmsg+0x8a7/0x8d0 [ 14.372673] __sys_sendmsg+0x1c2/0x270 [ 14.372914] do_syscall_64+0x41/0x90 [ 14.373145] entry_SYSCALL_64_after_hwframe+0x44/0xae
...
--- drivers/net/vmxnet3/vmxnet3_drv.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/vmxnet3/vmxnet3_drv.c +2 -0
@@ -595,6 +595,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,if (dma_mapping_error (&adapter->pdev->dev, rbi->dma_addr)) {dev_kfree_skb_any (rbi->skb); + rbi->skb =NULL ; rq->stats.rx_buf_alloc_failure++;break ; }
@@ -619,6 +620,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,if (dma_mapping_error (&adapter->pdev->dev, rbi->dma_addr)) {put_page (rbi->page); + rbi->page =NULL ; rq->stats.rx_buf_alloc_failure++;break ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 15/33 net: vmxnet3: fix possible NULL pointer dereference in vmxnet3_rq_cleanup()
In reply to Greg Kroah-HartmanFrom: Zixuan Fu <[email protected]>
[ Upstream commit edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd ]
In vmxnet3_rq_create(), when dma_alloc_coherent() fails, vmxnet3_rq_destroy() is called. It sets rq->rx_ring[i].base to NULL. Then vmxnet3_rq_create() returns an error to its callers mxnet3_rq_create_all() -> vmxnet3_change_mtu(). Then vmxnet3_change_mtu() calls vmxnet3_force_close() -> dev_close() in error handling code. And the driver calls vmxnet3_close() -> vmxnet3_quiesce_dev() -> vmxnet3_rq_cleanup_all() -> vmxnet3_rq_cleanup(). In vmxnet3_rq_cleanup(), rq->rx_ring[ring_idx].base is accessed, but this variable is NULL, causing a NULL pointer dereference.
To fix this possible bug, an if statement is added to check whether rq->rx_ring[0].base is NULL in vmxnet3_rq_cleanup() and exit early if so.
The error log in our fault-injection testing is shown as follows:
[ 65.220135] BUG: kernel NULL pointer dereference, address: 0000000000000008 ... [ 65.222633] RIP: 0010:vmxnet3_rq_cleanup_all+0x396/0x4e0 [vmxnet3] ... [ 65.227977] Call Trace: ... [ 65.228262] vmxnet3_quiesce_dev+0x80f/0x8a0 [vmxnet3] [ 65.228580] vmxnet3_close+0x2c4/0x3f0 [vmxnet3] [ 65.228866] __dev_close_many+0x288/0x350 [ 65.229607] dev_close_many+0xa4/0x480 [ 65.231124] dev_close+0x138/0x230 [ 65.231933] vmxnet3_force_close+0x1f0/0x240 [vmxnet3] [ 65.232248] vmxnet3_change_mtu+0x75d/0x920 [vmxnet3]
...
--- drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/vmxnet3/vmxnet3_drv.c +4 -0
@@ -1573,6 +1573,10 @@ vmxnet3_rq_cleanup(struct vmxnet3_rx_queue *rq,u32 i, ring_idx;struct Vmxnet3_RxDesc *rxd; +/* ring has already been cleaned up */ +if (!rq->rx_ring[0 ].base) +return ; +for (ring_idx =0 ; ring_idx <2 ; ring_idx++) {for (i =0 ; i < rq->rx_ring[ring_idx].size; i++) {#ifdef __BIG_ENDIAN_BITFIELD
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 16/33 clk: at91: generated: consider range when calculating best rate
In reply to Greg Kroah-HartmanFrom: Codrin Ciubotariu <[email protected]>
[ Upstream commit d0031e6fbed955ff8d5f5bbc8fe7382482559cec ]
clk_generated_best_diff() helps in finding the parent and the divisor to compute a rate closest to the required one. However, it doesn't take into account the request's range for the new rate. Make sure the new rate is within the required range.
--- drivers/clk/at91/clk-generated.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/clk/at91/clk-generated.c +4 -0
@@ -119,6 +119,10 @@ static void clk_generated_best_diff(struct clk_rate_request *req, tmp_rate = parent_rate; else tmp_rate = parent_rate / div; + +if (tmp_rate < req->min_rate || tmp_rate > req->max_rate) +return ; + tmp_diff =abs (req->rate - tmp_rate);if (*best_diff <0 || *best_diff > tmp_diff) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 17/33 net/qla3xxx: Fix a test in ql_reset_work()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit 5361448e45fac6fb96738df748229432a62d78b6 ]
test_bit() tests if one bit is set or not.
Here the logic seems to check of bit QL_RESET_PER_SCSI (i.e. 4) OR bit QL_RESET_START (i.e. 3) is set.
In fact, it checks if bit 7 (4 | 3 = 7) is set, that is to say QL_ADAPTER_UP.
This looks harmless, because this bit is likely be set, and when the ql_reset_work() delayed work is scheduled in ql3xxx_isr() (the only place that schedule this work), QL_RESET_START or QL_RESET_PER_SCSI is set.
This has been spotted by smatch.
--- drivers/net/ethernet/qlogic/qla3xxx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/qlogic/qla3xxx.c +2 -1
@@ -3629,7 +3629,8 @@ static void ql_reset_work(struct work_struct *work) qdev->mem_map_registers;unsigned long hw_flags; -if (test_bit ((QL_RESET_PER_SCSI |QL_RESET_START ), &qdev->flags)) { +if (test_bit (QL_RESET_PER_SCSI , &qdev->flags) || +test_bit (QL_RESET_START , &qdev->flags)) {clear_bit (QL_LINK_MASTER , &qdev->flags);/*
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 18/33 NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
In reply to Greg Kroah-HartmanFrom: Duoming Zhou <[email protected]>
[ Upstream commit 23dd4581350d4ffa23d58976ec46408f8f4c1e16 ]
There are sleep in atomic context bugs when the request to secure element of st-nci is timeout. The root cause is that nci_skb_alloc with GFP_KERNEL parameter is called in st_nci_se_wt_timeout which is a timer handler. The call paths that could trigger bugs are shown below:
(interrupt context 1)st_nci_se_wt_timeout
nci_hci_send_event
nci_hci_send_data
nci_skb_alloc(..., GFP_KERNEL) //may sleep (interrupt context 2)st_nci_se_wt_timeout
nci_hci_send_event
nci_hci_send_data
nci_send_data
nci_queue_tx_data_frags
nci_skb_alloc(..., GFP_KERNEL) //may sleepThis patch changes allocation mode of nci_skb_alloc from GFP_KERNEL to GFP_ATOMIC in order to prevent atomic context sleeping. The GFP_ATOMIC flag makes memory allocation operation could be used in atomic context.
--- net/nfc/nci/data.c | 2 +- net/nfc/nci/hci.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
net/nfc/nci/data.c +1 -1
@@ -130,7 +130,7 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev, skb_frag =nci_skb_alloc (ndev, (NCI_DATA_HDR_SIZE + frag_len), -GFP_KERNEL ); +GFP_ATOMIC );if (skb_frag ==NULL ) { rc = -ENOMEM ; goto free_exit;
net/nfc/nci/hci.c +2 -2
@@ -165,7 +165,7 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe, i =0 ; skb =nci_skb_alloc (ndev, conn_info->max_pkt_payload_len + -NCI_DATA_HDR_SIZE ,GFP_KERNEL ); +NCI_DATA_HDR_SIZE ,GFP_ATOMIC );if (!skb)return -ENOMEM ;
@@ -198,7 +198,7 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,if (i < data_len) { skb =nci_skb_alloc (ndev, conn_info->max_pkt_payload_len + -NCI_DATA_HDR_SIZE ,GFP_KERNEL ); +NCI_DATA_HDR_SIZE ,GFP_ATOMIC );if (!skb)return -ENOMEM ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 19/33 net: af_key: add check for pfkey_broadcast in function pfkey_process
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit 4dc2a5a8f6754492180741facf2a8787f2c415d7 ]
If skb_clone() returns null pointer, pfkey_broadcast() will return error.
Therefore, it should be better to check the return value of pfkey_broadcast() and return error if fails.
--- net/key/af_key.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/key/af_key.c +4 -2
@@ -2834,8 +2834,10 @@ static int pfkey_process(struct sock *sk, struct sk_buff *skb, const struct sadbvoid *ext_hdrs[SADB_EXT_MAX ];int err; -pfkey_broadcast (skb_clone (skb,GFP_KERNEL ),GFP_KERNEL , -BROADCAST_PROMISC_ONLY ,NULL ,sock_net (sk)); + err =pfkey_broadcast (skb_clone (skb,GFP_KERNEL ),GFP_KERNEL , +BROADCAST_PROMISC_ONLY ,NULL ,sock_net (sk)); +if (err) +return err;memset (ext_hdrs,0 ,sizeof (ext_hdrs)); err =parse_exthdrs (skb, hdr, ext_hdrs);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 20/33 ARM: 9196/1: spectre-bhb: enable for Cortex-A15
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
[ Upstream commit 0dc14aa94ccd8ba35eb17a0f9b123d1566efd39e ]
The Spectre-BHB mitigations were inadvertently left disabled for Cortex-A15, due to the fact that cpu_v7_bugs_init() is not called in that case. So fix that.
--- arch/arm/mm/proc-v7-bugs.c | 1 + 1 file changed, 1 insertion(+)
arch/arm/mm/proc-v7-bugs.c +1 -0
@@ -297,6 +297,7 @@ void cpu_v7_ca15_ibe(void) {if (check_spectre_auxcr (this_cpu_ptr (&spectre_warned),BIT (0 )))cpu_v7_spectre_v2_init (); +cpu_v7_spectre_bhb_init (); }void cpu_v7_bugs_init (void )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 21/33 ARM: 9197/1: spectre-bhb: fix loop8 sequence for Thumb2
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
[ Upstream commit 3cfb3019979666bdf33a1010147363cf05e0f17b ]
In Thumb2, 'b . + 4' produces a branch instruction that uses a narrow encoding, and so it does not jump to the following instruction as expected. So use W(b) instead.
--- arch/arm/kernel/entry-armv.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/kernel/entry-armv.S +1 -1
@@ -1071,7 +1071,7 @@ vector_bhb_loop8_\name: @ bhb workaround mov r0, #8 -3: b . + 4 +3: W(b) . + 4 subs r0, r0, #1 bne 3b dsb
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 22/33 igb: skip phy status check where unavailable
In reply to Greg Kroah-HartmanFrom: Kevin Mitchell <[email protected]>
[ Upstream commit 942d2ad5d2e0df758a645ddfadffde2795322728 ]
igb_read_phy_reg() will silently return, leaving phy_data untouched, if hw->ops.read_reg isn't set. Depending on the uninitialized value of phy_data, this led to the phy status check either succeeding immediately or looping continuously for 2 seconds before emitting a noisy err-level timeout. This message went out to the console even though there was no actual problem.
Instead, first check if there is read_reg function pointer. If not, proceed without trying to check the phy status register.
--- drivers/net/ethernet/intel/igb/igb_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/igb/igb_main.c +2 -1
@@ -4622,7 +4622,8 @@ static void igb_watchdog_task(struct work_struct *work)break ; } -if (adapter->link_speed !=SPEED_1000 ) +if (adapter->link_speed !=SPEED_1000 || + !hw->phy.ops.read_reg) goto no_wait;/* wait for Remote receiver status OK */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 23/33 net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.
In reply to Greg Kroah-HartmanFrom: Andrew Lunn <[email protected]>
[ Upstream commit fbb3abdf2223cd0dfc07de85fe5a43ba7f435bdf ]
It is possible to stack bridges on top of each other. Consider the following which makes use of an Ethernet switch:
br1
/ \
/ \ / \
br0.11 wlan0
|
br0
/ | \
p1 p2 p3
br0 is offloaded to the switch. Above br0 is a vlan interface, for vlan 11. This vlan interface is then a slave of br1. br1 also has a wireless interface as a slave. This setup trunks wireless lan traffic over the copper network inside a VLAN.
A frame received on p1 which is passed up to the bridge has the skb->offload_fwd_mark flag set to true, indicating that the switch has dealt with forwarding the frame out ports p2 and p3 as needed. This flag instructs the software bridge it does not need to pass the frame back down again. However, the flag is not getting reset when the frame is passed upwards. As a result br1 sees the flag, wrongly interprets it, and fails to forward the frame to wlan0.
When passing a frame upwards, clear the flag. This is the Rx equivalent of br_switchdev_frame_unmark() in br_dev_xmit().
--- net/bridge/br_input.c | 7 +++++++ 1 file changed, 7 insertions(+)
net/bridge/br_input.c +7 -0
@@ -47,6 +47,13 @@ static int br_pass_frame_up(struct sk_buff *skb)u64_stats_update_end (&brstats->syncp); vg =br_vlan_group_rcu (br); + +/* Reset the offload_fwd_mark because there could be a stacked +* bridge above, and it should not think this bridge it doing +* that bridge's work forwarding out its ports. +*/ +br_switchdev_frame_unmark (skb); +/* Bridge is just like any other port. Make sure the * packet is allowed except in promisc modue when someone * may be running packet capture.
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 24/33 gpio: gpio-vf610: do not touch other bits when set the target bit
In reply to Greg Kroah-HartmanFrom: Haibo Chen <[email protected]>
[ Upstream commit 9bf3ac466faa83d51a8fe9212131701e58fdef74 ]
For gpio controller contain register PDDR, when set one target bit, current logic will clear all other bits, this is wrong. Use operator '|=' to fix it.
--- drivers/gpio/gpio-vf610.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpio/gpio-vf610.c +6 -2
@@ -135,9 +135,13 @@ static int vf610_gpio_direction_output(struct gpio_chip *chip, unsigned gpio, {struct vf610_gpio_port *port =gpiochip_get_data (chip);unsigned long mask =BIT (gpio); +u32 val; -if (port->sdata && port->sdata->have_paddr) -vf610_gpio_writel (mask, port->gpio_base +GPIO_PDDR ); +if (port->sdata && port->sdata->have_paddr) { + val =vf610_gpio_readl (port->gpio_base +GPIO_PDDR ); + val |= mask; +vf610_gpio_writel (val, port->gpio_base +GPIO_PDDR ); + }vf610_gpio_set (chip, gpio, value);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 25/33 gpio: mvebu/pwm: Refuse requests with inverted polarity
In reply to Greg Kroah-HartmanFrom: Uwe Kleine-König <[email protected]>
[ Upstream commit 3ecb10175b1f776f076553c24e2689e42953fef5 ]
The driver doesn't take struct pwm_state::polarity into account when configuring the hardware, so refuse requests for inverted polarity.
--- drivers/gpio/gpio-mvebu.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpio/gpio-mvebu.c +3 -0
@@ -694,6 +694,9 @@ static int mvebu_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,unsigned long flags;unsigned int on, off; +if (state->polarity !=PWM_POLARITY_NORMAL ) +return -EINVAL ; + val = (unsigned long long ) mvpwm->clk_rate * state->duty_cycle;do_div (val,NSEC_PER_SEC );if (val >UINT_MAX )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 26/33 perf bench numa: Address compiler error on s390
In reply to Greg Kroah-HartmanFrom: Thomas Richter <[email protected]>
[ Upstream commit f8ac1c478424a9a14669b8cef7389b1e14e5229d ]
The compilation on s390 results in this error:
# make DEBUG=y bench/numa.o
...
bench/numa.c: In function ‘__bench_numa’:
bench/numa.c:1749:81: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size between
10 and 20 [-Werror=format-truncation=]
1749 | snprintf(tname, sizeof(tname), "process%d:thread%d", p, t);
^~
...
bench/numa.c:1749:64: note: directive argument in the range
[-2147483647, 2147483646]
...
#The maximum length of the %d replacement is 11 characters because of the negative sign. Therefore extend the array by two more characters.
Output after:
# make DEBUG=y bench/numa.o > /dev/null 2>&1; ll bench/numa.o -rw-r--r-- 1 root root 418320 May 19 09:11 bench/numa.o #
--- tools/perf/bench/numa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/bench/numa.c +1 -1
@@ -1631,7 +1631,7 @@ static int __bench_numa(const char *name) "GB/sec,", "total-speed", "GB/sec total speed");if (g->p.show_details >=2 ) { -char tname[14 +2 *10 +1 ]; +char tname[14 +2 *11 +1 ];struct thread_data *td;for (p =0 ; p < g->p.nr_proc; p++) {for (t =0 ; t < g->p.nr_threads; t++) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 27/33 scsi: qla2xxx: Fix missed DMA unmap for aborted commands
In reply to Greg Kroah-HartmanFrom: Gleb Chesnokov <[email protected]>
[ Upstream commit 26f9ce53817a8fd84b69a73473a7de852a24c897 ]
Aborting commands that have already been sent to the firmware can cause BUG in qlt_free_cmd(): BUG_ON(cmd->sg_mapped)
For instance:
- Command passes rdx_to_xfer state, maps sgl, sends to the firmware
- Reset occurs, qla2xxx performs ISP error recovery, aborts the command
- Target stack calls qlt_abort_cmd() and then qlt_free_cmd()
- BUG_ON(cmd->sg_mapped) in qlt_free_cmd() occurs because sgl was not unmapped
Thus, unmap sgl in qlt_abort_cmd() for commands with the aborted flag set.
--- drivers/scsi/qla2xxx/qla_target.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/qla2xxx/qla_target.c +3 -0
@@ -3639,6 +3639,9 @@ int qlt_abort_cmd(struct qla_tgt_cmd *cmd)spin_lock_irqsave (&cmd->cmd_lock, flags);if (cmd->aborted) { +if (cmd->sg_mapped) +qlt_unmap_sg (vha, cmd); +spin_unlock_irqrestore (&cmd->cmd_lock, flags);/* * It's normal to see 2 calls in this path:
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 28/33 mac80211: fix rx reordering with non explicit / psmp ack policy
In reply to Greg Kroah-HartmanFrom: Felix Fietkau <[email protected]>
[ Upstream commit 5e469ed9764d4722c59562da13120bd2dc6834c5 ]
When the QoS ack policy was set to non explicit / psmp ack, frames are treated as not being part of a BA session, which causes extra latency on reordering. Fix this by only bypassing reordering for packets with no-ack policy
--- net/mac80211/rx.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
net/mac80211/rx.c +1 -2
@@ -1204,8 +1204,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx, goto dont_reorder;/* not part of a BA session */ -if (ack_policy !=IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK && - ack_policy !=IEEE80211_QOS_CTL_ACK_POLICY_NORMAL ) +if (ack_policy ==IEEE80211_QOS_CTL_ACK_POLICY_NOACK ) goto dont_reorder;/* new, potentially un-ordered, ampdu frame - process it */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 29/33 ethernet: tulip: fix missing pci_disable_device() on error in tulip_init_one()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
[ Upstream commit 51ca86b4c9c7c75f5630fa0dbe5f8f0bd98e3c3e ]
Fix the missing pci_disable_device() before return from tulip_init_one() in the error handling case.
--- drivers/net/ethernet/dec/tulip/tulip_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/dec/tulip/tulip_core.c +4 -1
@@ -1410,8 +1410,10 @@ static int tulip_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)/* alloc_etherdev ensures aligned and zeroed private structures */ dev =alloc_etherdev (sizeof (*tp)); -if (!dev) +if (!dev) { +pci_disable_device (pdev);return -ENOMEM ; + }SET_NETDEV_DEV (dev, &pdev->dev);if (pci_resource_len (pdev,0 ) < tulip_tbl[chip_idx].io_size) {
@@ -1789,6 +1791,7 @@ static int tulip_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) err_out_free_netdev:free_netdev (dev); +pci_disable_device (pdev);return -ENODEV ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 30/33 net: stmmac: fix missing pci_disable_device() on error in stmmac_pci_probe()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
[ Upstream commit 0807ce0b010418a191e0e4009803b2d74c3245d5 ]
Switch to using pcim_enable_device() to avoid missing pci_disable_device().
--- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c +1 -3
@@ -261,7 +261,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,return -ENOMEM ;/* Enable pci device */ - ret =pci_enable_device (pdev); + ret =pcim_enable_device (pdev);if (ret) {dev_err (&pdev->dev,"%s: ERROR: failed to enable device\n" , __func__);
@@ -313,8 +313,6 @@ static void stmmac_pci_remove(struct pci_dev *pdev)pcim_iounmap_regions (pdev,BIT (i));break ; } - -pci_disable_device (pdev); }static int __maybe_unused stmmac_pci_suspend (struct device *dev)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 31/33 net: atlantic: verify hw_head_ lies within TX buffer ring
In reply to Greg Kroah-HartmanFrom: Grant Grundler <[email protected]>
[ Upstream commit 2120b7f4d128433ad8c5f503a9584deba0684901 ]
Bounds check hw_head index provided by NIC to verify it lies within the TX buffer ring.
--- drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c +7 -0
@@ -625,6 +625,13 @@ static int hw_atl_b0_hw_ring_tx_head_update(struct aq_hw_s *self, err = -ENXIO ; goto err_exit; } + +/* Validate that the new hw_head_ is reasonable. */ +if (hw_head_ >= ring->size) { + err = -ENXIO ; + goto err_exit; + } + ring->hw_head = hw_head_; err =aq_hw_err_from_flags (self);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 32/33 swiotlb: fix info leak with DMA_FROM_DEVICE
In reply to Greg Kroah-HartmanFrom: Halil Pasic <[email protected]>
commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e upstream.
The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails.
One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved).
Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce.
--- Documentation/DMA-attributes.txt | 10 ++++++++++ include/linux/dma-mapping.h | 8 ++++++++ lib/swiotlb.c | 3 ++- 3 files changed, 20 insertions(+), 1 deletion(-)
Documentation/DMA-attributes.txt +10 -0
@@ -156,3 +156,13 @@ accesses to DMA buffers in both privileg subsystem that the buffer is fully accessible at the elevated privilege level (and ideally inaccessible or at least read-only at the lesser-privileged levels). + +DMA_ATTR_PRIVILEGED +------------------- + +Some advanced peripherals such as remote processors and GPUs perform +accesses to DMA buffers in both privileged "supervisor" and unprivileged +"user" modes. This attribute is used to indicate to the DMA-mapping +subsystem that the buffer is fully accessible at the elevated privilege +level (and ideally inaccessible or at least read-only at the +lesser-privileged levels).
include/linux/dma-mapping.h +8 -0
@@ -71,6 +71,14 @@#define DMA_ATTR_PRIVILEGED (1UL << 9)/* +* This is a hint to the DMA-mapping subsystem that the device is expected +* to overwrite the entire mapped size, thus the caller does not require any +* of the previous buffer contents to be preserved. This allows +* bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers. +*/ +#define DMA_ATTR_OVERWRITE (1UL << 10) + +/* * A dma_addr_t can hold any valid DMA or bus address for the platform. * It can be given to a device to use as a DMA source or target. A CPU cannot * reference a dma_addr_t directly because there may be translation between
lib/swiotlb.c +2 -1
@@ -601,7 +601,8 @@ found:for (i =0 ; i < nslots; i++) io_tlb_orig_addr[index+i] = orig_addr + (i <<IO_TLB_SHIFT );if (!(attrs &DMA_ATTR_SKIP_CPU_SYNC ) && - (dir ==DMA_TO_DEVICE || dir ==DMA_BIDIRECTIONAL )) + (!(attrs &DMA_ATTR_OVERWRITE ) || dir ==DMA_TO_DEVICE || + dir ==DMA_BIDIRECTIONAL ))swiotlb_bounce (orig_addr, tlb_addr, size,DMA_TO_DEVICE );return tlb_addr;
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.281 release. There are 33 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, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.281-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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.
## Build
* kernel: 4.14.281-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.14.y
* git commit: b14ecd5c89c07852f6db6e723ddfcd15248f9b8d
* git describe: v4.14.280-34-gb14ecd5c89c0
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.280-34-gb14ecd5c89c0
## Test Regressions (compared to v4.14.280)
No test regressions found.
## Metric Regressions (compared to v4.14.280)
No metric regressions found.
## Test Fixes (compared to v4.14.280)
No test fixes found.
## Metric Fixes (compared to v4.14.280)
No metric fixes found.
## Test result summary
total: 76912, pass: 62185, fail: 786, skip: 11760, xfail: 2181
## Build Summary
* arm: 270 total, 270 passed, 0 failed
* arm64: 35 total, 35 passed, 0 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* powerpc: 16 total, 16 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 34 total, 34 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* 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-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* 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
* log-parser-boot
* log-parser-test
* 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
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.281 release. There are 33 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, 25 May 2022 16:56:55 +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
Guenter