5.10.224-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 150/352 tools/memory-model: Fix bug in lock.cat
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 4c830eef806679dc243e191f962c488dd9d00708 upstream.
Andrea reported that the following innocuous litmus test:
C T
{}
P0(spinlock_t *x)
{
int r0;
spin_lock(x);
spin_unlock(x);
r0 = spin_is_locked(x);
}gives rise to a nonsensical empty result with no executions:
$ herd7 -conf linux-kernel.cfg T.litmus Test T Required States 0 Ok Witnesses Positive: 0 Negative: 0 Condition forall (true) Observation T Never 0 0 Time T 0.00 Hash=6fa204e139ddddf2cb6fa963bad117c0
The problem is caused by a bug in the lock.cat part of the LKMM. Its computation of the rf relation for RU (read-unlocked) events is faulty; it implicitly assumes that every RU event must read from either a UL (unlock) event in another thread or from the lock's initial state. Neither is true in the litmus test above, so the computation yields no possible executions.
The lock.cat code tries to make up for this deficiency by allowing RU events outside of critical sections to read from the last po-previous UL event. But it does this incorrectly, trying to keep these rfi links separate from the rfe links that might also be needed, and passing only the latter to herd7's cross() macro.
The problem is fixed by merging the two sets of possible rf links for RU events and using them all in the call to cross().
--- tools/memory-model/lock.cat | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
tools/memory-model/lock.cat +10 -10
@@ -102,19 +102,19 @@ let rf-lf = rfe-lf | rfi-lf * within one of the lock's critical sections returns False. *) -(* rfi for RU events: an RU may read from the last po-previous UL *) -let rfi-ru = ([UL] ; po-loc ; [RU]) \ ([UL] ; po-loc ; [LKW] ; po-loc) - -(* rfe for RU events: an RU may read from an external UL or the initial write *) -let all-possible-rfe-ru = - let possible-rfe-ru r = +(* + * rf for RU events: an RU may read from an external UL or the initial write, + * or from the last po-previous UL + *) +let all-possible-rf-ru = + let possible-rf-ru r = let pair-to-relation p = p ++ 0 - in map pair-to-relation (((UL | IW) * {r}) & loc & ext) - in map possible-rfe-ru RU + in map pair-to-relation ((((UL | IW) * {r}) & loc & ext) | + (((UL * {r}) & po-loc) \ ([UL] ; po-loc ; [LKW] ; po-loc))) + in map possible-rf-ru RU (* Generate all rf relations for RU events *) -with rfe-ru from cross(all-possible-rfe-ru) -let rf-ru = rfe-ru | rfi-ru +with rf-ru from cross(all-possible-rf-ru) (* Final rf relation *) let rf = rf | rf-lf | rf-ru
Greg Kroah-Hartman
maintainerPATCH 151/352 hwrng: amd - Convert PCIBIOS_* return codes to errnos
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilpo Järvinen <[email protected]>
commit 14cba6ace79627a57fb9058582b03f0ed3832390 upstream.
amd_rng_mod_init() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is then returned as is but amd_rng_mod_init() is a module_init() function that should return normal errnos.
Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it.
--- drivers/char/hw_random/amd-rng.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/char/hw_random/amd-rng.c +3 -1
@@ -142,8 +142,10 @@ static int __init mod_init(void) found: err =pci_read_config_dword (pdev,0x58 , &pmbase); -if (err) +if (err) { + err =pcibios_err_to_errno (err); goto put_dev; + } pmbase &=0x0000FF00 ;if (pmbase ==0 ) {
Greg Kroah-Hartman
maintainerPATCH 152/352 PCI: hv: Return zero, not garbage, when reading PCI_INTERRUPT_PIN
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Liu <[email protected]>
commit fea93a3e5d5e6a09eb153866d2ce60ea3287a70d upstream.
The intent of the code snippet is to always return 0 for both PCI_INTERRUPT_LINE and PCI_INTERRUPT_PIN.
The check misses PCI_INTERRUPT_PIN. This patch fixes that.
This is discovered by this call in VFIO:
pci_read_config_byte(vdev->pdev, PCI_INTERRUPT_PIN, &pin);
The old code does not set *val to 0 because it misses the check for PCI_INTERRUPT_PIN. Garbage is returned in that case.
--- drivers/pci/controller/pci-hyperv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/pci/controller/pci-hyperv.c +2 -2
@@ -680,8 +680,8 @@ static void _hv_pcifront_read_config(str PCI_CAPABILITY_LIST) {/* ROM BARs are unimplemented */ *val =0 ; - } else if (where >= PCI_INTERRUPT_LINE && where + size <= - PCI_INTERRUPT_PIN) { + } else if ((where >= PCI_INTERRUPT_LINE && where + size <= PCI_INTERRUPT_PIN) || + (where >= PCI_INTERRUPT_PIN && where + size <= PCI_MIN_GNT)) {/* * Interrupt Line and Interrupt PIN are hard-wired to zero * because this front-end only supports message-signaled
Greg Kroah-Hartman
maintainerPATCH 153/352 PCI: rockchip: Use GPIOD_OUT_LOW flag while requesting ep_gpio
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manivannan Sadhasivam <[email protected]>
commit 840b7a5edf88fe678c60dee88a135647c0ea4375 upstream.
Rockchip platforms use 'GPIO_ACTIVE_HIGH' flag in the devicetree definition for ep_gpio. This means, whatever the logical value set by the driver for the ep_gpio, physical line will output the same logic level.
For instance,
gpiod_set_value_cansleep(rockchip->ep_gpio, 0); --> Level low gpiod_set_value_cansleep(rockchip->ep_gpio, 1); --> Level high
But while requesting the ep_gpio, GPIOD_OUT_HIGH flag is currently used. Now, this also causes the physical line to output 'high' creating trouble for endpoint devices during host reboot.
When host reboot happens, the ep_gpio will initially output 'low' due to the GPIO getting reset to its POR value. Then during host controller probe, it will output 'high' due to GPIOD_OUT_HIGH flag. Then during rockchip_pcie_host_init_port(), it will first output 'low' and then 'high' indicating the completion of controller initialization.
On the endpoint side, each output 'low' of ep_gpio is accounted for PERST# assert and 'high' for PERST# deassert. With the above mentioned flow during host reboot, endpoint will witness below state changes for PERST#:
(1) PERST# assert - GPIO POR state
(2) PERST# deassert - GPIOD_OUT_HIGH while requesting GPIO
(3) PERST# assert - rockchip_pcie_host_init_port()
(4) PERST# deassert - rockchip_pcie_host_init_port()
Now the time interval between (2) and (3) is very short as both happen during the driver probe(), and this results in a race in the endpoint. Because, before completing the PERST# deassertion in (2), endpoint got another PERST# assert in (3).
A proper way to fix this issue is to change the GPIOD_OUT_HIGH flag in (2) to GPIOD_OUT_LOW. Because the usual convention is to request the GPIO with a state corresponding to its 'initial/default' value and let the driver change the state of the GPIO when required.
As per that, the ep_gpio should be requested with GPIOD_OUT_LOW as it corresponds to the POR value of '0' (PERST# assert in the endpoint). Then the driver can change the state of the ep_gpio later in rockchip_pcie_host_init_port() as per the initialization sequence.
This fixes the firmware crash issue in Qcom based modems connected to Rockpro64 based board.
--- drivers/pci/controller/pcie-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/controller/pcie-rockchip.c +1 -1
@@ -120,7 +120,7 @@ int rockchip_pcie_parse_dt(struct rockchif (rockchip->is_rc) { rockchip->ep_gpio =devm_gpiod_get_optional (dev,"ep" , -GPIOD_OUT_HIGH ); +GPIOD_OUT_LOW );if (IS_ERR (rockchip->ep_gpio))return dev_err_probe (dev,PTR_ERR (rockchip->ep_gpio),"failed to get ep GPIO\n" );
Greg Kroah-Hartman
maintainerPATCH 154/352 binder: fix hang of unregistered readers
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Carlos Llamas <[email protected]>
commit 31643d84b8c3d9c846aa0e20bc033e46c68c7e7d upstream.
With the introduction of binder_available_for_proc_work_ilocked() in commit 1b77e9dcc3da ("ANDROID: binder: remove proc waitqueue") a binder thread can only "wait_for_proc_work" after its thread->looper has been marked as BINDER_LOOPER_STATE_{ENTERED|REGISTERED}.
This means an unregistered reader risks waiting indefinitely for work since it never gets added to the proc->waiting_threads. If there are no further references to its waitqueue either the task will hang. The same applies to readers using the (e)poll interface.
I couldn't find the rationale behind this restriction. So this patch restores the previous behavior of allowing unregistered threads to "wait_for_proc_work". Note that an error message for this scenario, which had previously become unreachable, is now re-enabled.
--- drivers/android/binder.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/android/binder.c +1 -3
@@ -928,9 +928,7 @@ static bool binder_has_work(struct bindestatic bool binder_available_for_proc_work_ilocked (struct binder_thread *thread) {return !thread->transaction_stack && -binder_worklist_empty_ilocked (&thread->todo) && - (thread->looper & (BINDER_LOOPER_STATE_ENTERED | -BINDER_LOOPER_STATE_REGISTERED )); +binder_worklist_empty_ilocked (&thread->todo); } static void binder_wakeup_poll_threads_ilocked(struct binder_proc *proc,
Greg Kroah-Hartman
maintainerPATCH 155/352 dev/parport: fix the array out-of-bounds risk
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: tuhaowen <[email protected]>
commit ab11dac93d2d568d151b1918d7b84c2d02bacbd5 upstream.
Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]
--- drivers/parport/procfs.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/parport/procfs.c +12 -12
@@ -51,12 +51,12 @@ static int do_active_device(struct ctl_tfor (dev = port->devices; dev ; dev = dev->next) {if (dev == port->cad) { - len +=sprintf (buffer,"%s\n" , dev->name); + len +=snprintf (buffer,sizeof (buffer),"%s\n" , dev->name); } }if (!len) { - len +=sprintf (buffer,"%s\n" ,"none" ); + len +=snprintf (buffer,sizeof (buffer),"%s\n" ,"none" ); }if (len > *lenp)
@@ -87,19 +87,19 @@ static int do_autoprobe(struct ctl_table }if ((str = info->class_name) !=NULL ) - len +=sprintf (buffer + len,"CLASS:%s;\n" , str); + len +=snprintf (buffer + len,sizeof (buffer) - len,"CLASS:%s;\n" , str);if ((str = info->model) !=NULL ) - len +=sprintf (buffer + len,"MODEL:%s;\n" , str); + len +=snprintf (buffer + len,sizeof (buffer) - len,"MODEL:%s;\n" , str);if ((str = info->mfr) !=NULL ) - len +=sprintf (buffer + len,"MANUFACTURER:%s;\n" , str); + len +=snprintf (buffer + len,sizeof (buffer) - len,"MANUFACTURER:%s;\n" , str);if ((str = info->description) !=NULL ) - len +=sprintf (buffer + len,"DESCRIPTION:%s;\n" , str); + len +=snprintf (buffer + len,sizeof (buffer) - len,"DESCRIPTION:%s;\n" , str);if ((str = info->cmdset) !=NULL ) - len +=sprintf (buffer + len,"COMMAND SET:%s;\n" , str); + len +=snprintf (buffer + len,sizeof (buffer) - len,"COMMAND SET:%s;\n" , str);if (len > *lenp) len = *lenp;
@@ -117,7 +117,7 @@ static int do_hardware_base_addr(struct void *result, size_t *lenp, loff_t *ppos) { struct parport *port = (struct parport *)table->extra1; -char buffer[20 ]; +char buffer[64 ];int len =0 ;if (*ppos) {
@@ -128,7 +128,7 @@ static int do_hardware_base_addr(structif (write)/* permissions prevent this anyway */ return -EACCES ; - len +=sprintf (buffer,"%lu\t%lu\n" , port->base, port->base_hi); + len +=snprintf (buffer,sizeof (buffer),"%lu\t%lu\n" , port->base, port->base_hi);if (len > *lenp) len = *lenp;
@@ -155,7 +155,7 @@ static int do_hardware_irq(struct ctl_taif (write)/* permissions prevent this anyway */ return -EACCES ; - len +=sprintf (buffer,"%d\n" , port->irq); + len +=snprintf (buffer,sizeof (buffer),"%d\n" , port->irq);if (len > *lenp) len = *lenp;
@@ -182,7 +182,7 @@ static int do_hardware_dma(struct ctl_taif (write)/* permissions prevent this anyway */ return -EACCES ; - len +=sprintf (buffer,"%d\n" , port->dma); + len +=snprintf (buffer,sizeof (buffer),"%d\n" , port->dma);if (len > *lenp) len = *lenp;
@@ -213,7 +213,7 @@ static int do_hardware_modes(struct ctl_#define printmode (x) \ do { \ if (port->modes & PARPORT_MODE_##x) \ - len += sprintf(buffer + len, "%s%s", f++ ? "," : "", #x); \ + len += snprintf(buffer + len, sizeof(buffer) - len, "%s%s", f++ ? "," : "", #x); \ } while (0)int f =0 ;printmode (PCSPP );
Greg Kroah-Hartman
maintainerPATCH 156/352 scsi: qla2xxx: Return ENOBUFS if sg_cnt is more than one for ELS cmds
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Saurav Kashyap <[email protected]>
commit ce2065c4cc4f05635413f63f6dc038d7d4842e31 upstream.
Firmware only supports single DSDs in ELS Pass-through IOCB (0x53h), sg cnt is decided by the SCSI ML. User is not aware of the cause of an acutal error.
Return the appropriate return code that will be decoded by API and application and proper error message will be displayed to user.
--- drivers/scsi/qla2xxx/qla_bsg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_bsg.c +1 -1
@@ -306,7 +306,7 @@ qla2x00_process_els(struct bsg_job *bsg_"request_sg_cnt=%x reply_sg_cnt=%x.\n" , bsg_job->request_payload.sg_cnt, bsg_job->reply_payload.sg_cnt); - rval = -EPERM ; + rval = -ENOBUFS ; goto done; }
Greg Kroah-Hartman
maintainerPATCH 157/352 f2fs: fix to dont dirty inode for readonly filesystem
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
commit 192b8fb8d1c8ca3c87366ebbef599fa80bb626b8 upstream.
syzbot reports f2fs bug as below:
kernel BUG at fs/f2fs/inode.c:933!
RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b
The root cause is:
- do_sys_open
- f2fs_lookup
- __f2fs_find_entry
- f2fs_i_depth_write
- f2fs_mark_inode_dirty_sync
- f2fs_dirty_inode
- set_inode_flag(inode, FI_DIRTY_INODE)
- umount
- kill_f2fs_super
- kill_block_super
- generic_shutdown_super
- sync_filesystem
: sb is readonly, skip sync_filesystem()
- evict_inodes
- iput
- f2fs_evict_inode
- f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic
When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode().
--- fs/f2fs/inode.c | 3 +++ 1 file changed, 3 insertions(+)
fs/f2fs/inode.c +3 -0
@@ -23,6 +23,9 @@ void f2fs_mark_inode_dirty_sync(struct iif (is_inode_flag_set (inode,FI_NEW_INODE ))return ; +if (f2fs_readonly (F2FS_I_SB (inode)->sb)) +return ; +if (f2fs_inode_dirtied (inode, sync))return ;
Greg Kroah-Hartman
maintainerPATCH 158/352 clk: davinci: da8xx-cfgchip: Initialize clk_init_data before use
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bastien Curutchet <[email protected]>
commit a83b22754e351f13fb46596c85f667dc33da71ec upstream.
The flag attribute of the struct clk_init_data isn't initialized before the devm_clk_hw_register() call. This can lead to unexpected behavior during registration.
Initialize the entire clk_init_data to zero at declaration.
--- drivers/clk/davinci/da8xx-cfgchip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/clk/davinci/da8xx-cfgchip.c +2 -2
@@ -505,7 +505,7 @@ da8xx_cfgchip_register_usb0_clk48(structconst char *const parent_names[] = {"usb_refclkin" ,"pll0_auxclk" };struct clk *fck_clk;struct da8xx_usb0_clk48 *usb0; -struct clk_init_data init; +struct clk_init_data init = {};int ret; fck_clk =devm_clk_get (dev,"fck" );
@@ -580,7 +580,7 @@ da8xx_cfgchip_register_usb1_clk48(struct {const char *const parent_names[] = {"usb0_clk48" ,"usb_refclkin" };struct da8xx_usb1_clk48 *usb1; -struct clk_init_data init; +struct clk_init_data init = {};int ret; usb1 =devm_kzalloc (dev,sizeof (*usb1),GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 159/352 ubi: eba: properly rollback inside self_check_eba
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fedor Pchelkin <[email protected]>
commit 745d9f4a31defec731119ee8aad8ba9f2536dd9a upstream.
In case of a memory allocation failure in the volumes loop we can only process the already allocated scan_eba and fm_eba array elements on the error path - others are still uninitialized.
Found by Linux Verification Center (linuxtesting.org).
--- drivers/mtd/ubi/eba.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mtd/ubi/eba.c +2 -1
@@ -1560,6 +1560,7 @@ int self_check_eba(struct ubi_device *ub GFP_KERNEL);if (!fm_eba[i]) { ret = -ENOMEM ; +kfree (scan_eba[i]); goto out_free; }
@@ -1595,7 +1596,7 @@ int self_check_eba(struct ubi_device *ub } out_free: -for (i =0 ; i < num_volumes; i++) { +while (--i >=0 ) {if (!ubi->volumes[i])continue ;
Greg Kroah-Hartman
maintainerPATCH 160/352 decompress_bunzip2: fix rare decompression failure
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ross Lagerwall <[email protected]>
commit bf6acd5d16057d7accbbb1bf7dc6d8c56eeb4ecc upstream.
The decompression code parses a huffman tree and counts the number of symbols for a given bit length. In rare cases, there may be >= 256 symbols with a given bit length, causing the unsigned char to overflow. This causes a decompression failure later when the code tries and fails to find the bit length for a given symbol.
Since the maximum number of symbols is 258, use unsigned short instead.
--- lib/decompress_bunzip2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
lib/decompress_bunzip2.c +2 -1
@@ -232,7 +232,8 @@ static int INIT get_next_block(struct buRUNB) */ symCount = symTotal+2 ;for (j =0 ; j < groupCount; j++) { -unsigned char length[MAX_SYMBOLS ], temp[MAX_HUFCODE_BITS +1 ]; +unsigned char length[MAX_SYMBOLS ]; +unsigned short temp[MAX_HUFCODE_BITS +1 ];int minLen, maxLen, pp;/* Read Huffman code lengths for each symbol. They're stored in a way similar to mtf; record a starting
Greg Kroah-Hartman
maintainerPATCH 161/352 kbuild: Fix -S -c in x86 stack protector scripts
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 3415b10a03945b0da4a635e146750dfe5ce0f448 upstream.
After a recent change in clang to stop consuming all instances of '-S' and '-c' [1], the stack protector scripts break due to the kernel's use of -Werror=unused-command-line-argument to catch cases where flags are not being properly consumed by the compiler driver:
$ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
This results in CONFIG_STACKPROTECTOR getting disabled because CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
'-c' and '-S' both instruct the compiler to stop at different stages of the pipeline ('-S' after compiling, '-c' after assembling), so having them present together in the same command makes little sense. In this case, the test wants to stop before assembling because it is looking at the textual assembly output of the compiler for either '%fs' or '%gs', so remove '-c' from the list of arguments to resolve the error.
All versions of GCC continue to work after this change, along with versions of clang that do or do not contain the change mentioned above.
--- scripts/gcc-x86_32-has-stack-protector.sh | 2 +- scripts/gcc-x86_64-has-stack-protector.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
scripts/gcc-x86_32-has-stack-protector.sh +1 -1
@@ -5,4 +5,4 @@ # -mstack-protector-guard-reg, added by # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 -echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32 -O0 -fstack-protector -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard - -o - 2> /dev/null | grep -q "%fs" +echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -m32 -O0 -fstack-protector -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard - -o - 2> /dev/null | grep -q "%fs"
scripts/gcc-x86_64-has-stack-protector.sh +1 -1
@@ -1,4 +1,4 @@ #!/bin/sh # SPDX-License-Identifier: GPL-2.0 -echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m64 -O0 -mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs" +echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -m64 -O0 -mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
Greg Kroah-Hartman
maintainerPATCH 162/352 kobject_uevent: Fix OOB access within zap_modalias_env()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zijun Hu <[email protected]>
commit dd6e9894b451e7c85cceb8e9dc5432679a70e7dc upstream.
zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.
--- lib/kobject_uevent.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
lib/kobject_uevent.c +16 -1
@@ -432,8 +432,23 @@ static void zap_modalias_env(struct kobj len =strlen (env->envp[i]) +1 ;if (i != env->envp_idx -1 ) { +/* @env->envp[] contains pointers to @env->buf[] +* with @env->buflen chars, and we are removing +* variable MODALIAS here pointed by @env->envp[i] +* with length @len as shown below: +* +* 0 @env->buf[] @env->buflen +* --------------------------------------------- +* ^ ^ ^ ^ +* | |-> @len <-| target block | +* @env->envp[0] @env->envp[i] @env->envp[i + 1] +* +* so the "target block" indicated above is moved +* backward by @len, and its right size is +* @env->buflen - (@env->envp[i + 1] - @env->envp[0]). +*/ memmove (env->envp[i], env->envp[i +1 ], - env->buflen - len); + env->buflen - (env->envp[i +1 ] - env->envp[0 ]));for (j = i; j < env->envp_idx -1 ; j++) env->envp[j] = env->envp[j +1 ] - len;
Greg Kroah-Hartman
maintainerPATCH 163/352 devres: Fix devm_krealloc() wasting memory
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zijun Hu <[email protected]>
commit c884e3249f753dcef7a2b2023541ac1dc46b318e upstream.
Driver API devm_krealloc() calls alloc_dr() with wrong argument @total_new_size, so causes more memory to be allocated than required fix this memory waste by using @new_size as the argument for alloc_dr().
--- drivers/base/devres.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/base/devres.c +4 -1
@@ -901,9 +901,12 @@ void *devm_krealloc(struct device *dev,/* * Otherwise: allocate new, larger chunk. We need to allocate before * taking the lock as most probably the caller uses GFP_KERNEL. +* alloc_dr() will call check_dr_size() to reserve extra memory +* for struct devres automatically, so size @new_size user request +* is delivered to it directly as devm_kmalloc() does. */ new_dr =alloc_dr (devm_kmalloc_release, - total_new_size, gfp,dev_to_node (dev)); + new_size, gfp,dev_to_node (dev));if (!new_dr)return NULL ;
Greg Kroah-Hartman
maintainerPATCH 164/352 rtc: cmos: Fix return value of nvmem callbacks
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joy Chakraborty <[email protected]>
commit 1c184baccf0d5e2ef4cc1562261d0e48508a1c2b upstream.
Read/write callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure.
cmos_nvram_read()/cmos_nvram_write() currently return the number of bytes read or written, fix to return 0 on success and -EIO incase number of bytes requested was not read or written.
--- drivers/rtc/rtc-cmos.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/rtc/rtc-cmos.c +4 -6
@@ -649,11 +649,10 @@ static int cmos_nvram_read(void *priv, u size_t count) {unsigned char *buf = val; -int retval; off +=NVRAM_OFFSET ;spin_lock_irq (&rtc_lock); -for (retval =0 ; count; count--, off++, retval++) { +for (; count; count--, off++) {if (off <128 ) *buf++ =CMOS_READ (off);else if (can_bank2)
@@ -663,7 +662,7 @@ static int cmos_nvram_read(void *priv, u }spin_unlock_irq (&rtc_lock); -return retval; +return count ? -EIO :0 ; } static int cmos_nvram_write(void *priv, unsigned int off, void *val,
@@ -671,7 +670,6 @@ static int cmos_nvram_write(void *priv, {struct cmos_rtc *cmos = priv;unsigned char *buf = val; -int retval;/* NOTE: on at least PCs and Ataris, the boot firmware uses a * checksum on part of the NVRAM data. That's currently ignored
@@ -680,7 +678,7 @@ static int cmos_nvram_write(void *priv,*/ off +=NVRAM_OFFSET ;spin_lock_irq (&rtc_lock); -for (retval =0 ; count; count--, off++, retval++) { +for (; count; count--, off++) {/* don't trash RTC registers */ if (off == cmos->day_alrm || off == cmos->mon_alrm
@@ -695,7 +693,7 @@ static int cmos_nvram_write(void *priv, }spin_unlock_irq (&rtc_lock); -return retval; +return count ? -EIO :0 ; }/*----------------------------------------------------------------*/
Greg Kroah-Hartman
maintainerPATCH 165/352 scsi: qla2xxx: During vport delete send async logout explicitly
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manish Rangankar <[email protected]>
commit 76f480d7c717368f29a3870f7d64471ce0ff8fb2 upstream.
During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting.
BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 </TASK>
Send out async logout explicitly for all the ports during vport delete.
--- drivers/scsi/qla2xxx/qla_mid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_mid.c +1 -1
@@ -164,7 +164,7 @@ qla24xx_disable_vp(scsi_qla_host_t *vha)atomic_set (&vha->loop_state,LOOP_DOWN );atomic_set (&vha->loop_down_timer,LOOP_DOWN_TIME );list_for_each_entry (fcport, &vha->vp_fcports, list) - fcport->logout_on_delete =0 ; + fcport->logout_on_delete =1 ;qla2x00_mark_all_devices_lost (vha);
Greg Kroah-Hartman
maintainerPATCH 166/352 scsi: qla2xxx: Fix for possible memory corruption
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shreyas Deodhar <[email protected]>
commit c03d740152f78e86945a75b2ad541bf972fab92a upstream.
Init Control Block is dereferenced incorrectly. Correctly dereference ICB
--- drivers/scsi/qla2xxx/qla_os.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_os.c +1 -1
@@ -4453,7 +4453,7 @@ static void qla2x00_number_of_exch(scsi_qla_host_t *vha, u32 *ret_cnt, u16 max_cnt) {u32 temp; -struct init_cb_81xx *icb = (struct init_cb_81xx *)&vha->hw->init_cb; +struct init_cb_81xx *icb = (struct init_cb_81xx *)vha->hw->init_cb; *ret_cnt =FW_DEF_EXCHANGES_CNT ;if (max_cnt > vha->hw->max_exchg)
Greg Kroah-Hartman
maintainerPATCH 167/352 scsi: qla2xxx: Fix flash read failure
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quinn Tran <[email protected]>
commit 29e222085d8907ccff18ecd931bdd4c6b1f11b92 upstream.
Link up failure is observed as a result of flash read failure. Current code does not check flash read return code where it relies on FW checksum to detect the problem.
Add check of flash read failure to detect the problem sooner.
--- drivers/scsi/qla2xxx/qla_init.c | 63 ++++++++++++++++++----- drivers/scsi/qla2xxx/qla_sup.c | 108 +++++++++++++++++++++++++++------------- 2 files changed, 125 insertions(+), 46 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +50 -13
@@ -7696,15 +7696,21 @@ qla28xx_get_aux_images(struct qla27xx_image_status pri_aux_image_status, sec_aux_image_status;bool valid_pri_image = false, valid_sec_image = false;bool active_pri_image = false, active_sec_image = false; +int rc;if (!ha->flt_region_aux_img_status_pri) {ql_dbg (ql_dbg_init, vha,0x018a ,"Primary aux image not addressed\n" ); goto check_sec_image; } -qla24xx_read_flash_data (vha, (uint32_t *)&pri_aux_image_status, + rc =qla24xx_read_flash_data (vha, (uint32_t *)&pri_aux_image_status, ha->flt_region_aux_img_status_pri,sizeof (pri_aux_image_status) >>2 ); +if (rc) { +ql_log (ql_log_info, vha,0x01a1 , +"Unable to read Primary aux image(%x).\n" , rc); + goto check_sec_image; + }qla27xx_print_image (vha,"Primary aux image" , &pri_aux_image_status);if (qla28xx_check_aux_image_status_signature (&pri_aux_image_status)) {
@@ -7735,9 +7741,15 @@ check_sec_image: goto check_valid_image; } -qla24xx_read_flash_data (vha, (uint32_t *)&sec_aux_image_status, + rc =qla24xx_read_flash_data (vha, (uint32_t *)&sec_aux_image_status, ha->flt_region_aux_img_status_sec,sizeof (sec_aux_image_status) >>2 ); +if (rc) { +ql_log (ql_log_info, vha,0x01a2 , +"Unable to read Secondary aux image(%x).\n" , rc); + goto check_valid_image; + } +qla27xx_print_image (vha,"Secondary aux image" , &sec_aux_image_status);if (qla28xx_check_aux_image_status_signature (&sec_aux_image_status)) {
@@ -7794,6 +7806,7 @@ qla27xx_get_active_image(struct scsi_qlastruct qla27xx_image_status pri_image_status, sec_image_status;bool valid_pri_image = false, valid_sec_image = false;bool active_pri_image = false, active_sec_image = false; +int rc;if (!ha->flt_region_img_status_pri) {ql_dbg (ql_dbg_init, vha,0x018a ,"Primary image not addressed\n" );
@@ -7835,8 +7848,14 @@ check_sec_image: goto check_valid_image; } -qla24xx_read_flash_data (vha, (uint32_t *)(&sec_image_status), + rc =qla24xx_read_flash_data (vha, (uint32_t *)(&sec_image_status), ha->flt_region_img_status_sec,sizeof (sec_image_status) >>2 ); +if (rc) { +ql_log (ql_log_info, vha,0x01a3 , +"Unable to read Secondary image status(%x).\n" , rc); + goto check_valid_image; + } +qla27xx_print_image (vha,"Secondary image" , &sec_image_status);if (qla27xx_check_image_status_signature (&sec_image_status)) {
@@ -7908,11 +7927,10 @@ qla24xx_load_risc_flash(scsi_qla_host_t "FW: Loading firmware from flash (%x).\n", faddr); dcode = (uint32_t *)req->ring; -qla24xx_read_flash_data (vha, dcode, faddr,8 ); -if (qla24xx_risc_firmware_invalid (dcode)) { + rval =qla24xx_read_flash_data (vha, dcode, faddr,8 ); +if (rval ||qla24xx_risc_firmware_invalid (dcode)) {ql_log (ql_log_fatal, vha,0x008c , -"Unable to verify the integrity of flash firmware " -"image.\n" ); +"Unable to verify the integrity of flash firmware image (rval %x).\n" , rval);ql_log (ql_log_fatal, vha,0x008d ,"Firmware data: %08x %08x %08x %08x.\n" , dcode[0 ], dcode[1 ], dcode[2 ], dcode[3 ]);
@@ -7926,7 +7944,12 @@ qla24xx_load_risc_flash(scsi_qla_host_tfor (j =0 ; j < segments; j++) {ql_dbg (ql_dbg_init, vha,0x008d ,"-> Loading segment %u...\n" , j); -qla24xx_read_flash_data (vha, dcode, faddr,10 ); + rval =qla24xx_read_flash_data (vha, dcode, faddr,10 ); +if (rval) { +ql_log (ql_log_fatal, vha,0x016a , +"-> Unable to read segment addr + size .\n" ); +return QLA_FUNCTION_FAILED ; + } risc_addr =be32_to_cpu ((__force __be32 )dcode[2 ]); risc_size =be32_to_cpu ((__force __be32 )dcode[3 ]);if (!*srisc_addr) {
@@ -7942,7 +7965,13 @@ qla24xx_load_risc_flash(scsi_qla_host_tql_dbg (ql_dbg_init, vha,0x008e ,"-> Loading fragment %u: %#x <- %#x (%#lx dwords)...\n" , fragment, risc_addr, faddr, dlen); -qla24xx_read_flash_data (vha, dcode, faddr, dlen); + rval =qla24xx_read_flash_data (vha, dcode, faddr, dlen); +if (rval) { +ql_log (ql_log_fatal, vha,0x016b , +"-> Unable to read fragment(faddr %#x dlen %#lx).\n" , + faddr, dlen); +return QLA_FUNCTION_FAILED ; + }for (i =0 ; i < dlen; i++) dcode[i] =swab32 (dcode[i]);
@@ -7972,7 +8001,14 @@ qla24xx_load_risc_flash(scsi_qla_host_t fwdt->length =0 ; dcode = (uint32_t *)req->ring; -qla24xx_read_flash_data (vha, dcode, faddr,7 ); + + rval =qla24xx_read_flash_data (vha, dcode, faddr,7 ); +if (rval) { +ql_log (ql_log_fatal, vha,0x016c , +"-> Unable to read template size.\n" ); + goto failed; + } + risc_size =be32_to_cpu ((__force __be32 )dcode[2 ]); ql_dbg(ql_dbg_init, vha, 0x0161, "-> fwdt%u template array at %#x (%#x dwords)\n",
@@ -7998,11 +8034,12 @@ qla24xx_load_risc_flash(scsi_qla_host_t } dcode = fwdt->template; -qla24xx_read_flash_data (vha, dcode, faddr, risc_size); + rval =qla24xx_read_flash_data (vha, dcode, faddr, risc_size); -if (!qla27xx_fwdt_template_valid (dcode)) { +if (rval || !qla27xx_fwdt_template_valid (dcode)) {ql_log (ql_log_warn, vha,0x0165 , -"-> fwdt%u failed template validate\n" , j); +"-> fwdt%u failed template validate (rval %x)\n" , + j, rval); goto failed; }
drivers/scsi/qla2xxx/qla_sup.c +75 -33
188 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 168/352 scsi: qla2xxx: Complete command early within lock
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shreyas Deodhar <[email protected]>
commit 4475afa2646d3fec176fc4d011d3879b26cb26e3 upstream.
A crash was observed while performing NPIV and FW reset,
BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0 ? do_user_addr_fault+0x174/0x7f0 ? exc_page_fault+0x69/0x1a0 ? asm_exc_page_fault+0x22/0x30 ? dma_direct_unmap_sg+0x51/0x1e0 ? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]
The command completion was done early while aborting the commands in driver unload path but outside lock to avoid the WARN_ON condition of performing dma_free_attr within the lock. However this caused race condition while command completion via multiple paths causing system crash.
Hence complete the command early in unload path but within the lock to avoid race condition.
--- drivers/scsi/qla2xxx/qla_os.c | 5 ----- 1 file changed, 5 deletions(-)
drivers/scsi/qla2xxx/qla_os.c +0 -5
@@ -1752,14 +1752,9 @@ __qla2x00_abort_all_cmds(struct qla_qpaifor (cnt =1 ; cnt < req->num_outstanding_cmds; cnt++) { sp = req->outstanding_cmds[cnt];if (sp) { -/* -* perform lockless completion during driver unload -*/ if (qla2x00_chip_is_down (vha)) { req->outstanding_cmds[cnt] =NULL ; -spin_unlock_irqrestore (qp->qp_lock_ptr, flags); sp->done (sp, res); -spin_lock_irqsave (qp->qp_lock_ptr, flags);continue ; }
Greg Kroah-Hartman
maintainerPATCH 169/352 scsi: qla2xxx: validate nvme_local_port correctly
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nilesh Javali <[email protected]>
commit eb1d4ce2609584eeb7694866f34d4b213caa3af9 upstream.
The driver load failed with error message,
qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef
and with a kernel crash,
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 Workqueue: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000 RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Call Trace: qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx]
Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port.
--- drivers/scsi/qla2xxx/qla_nvme.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_nvme.c +4 -1
@@ -27,7 +27,10 @@ int qla_nvme_register_remote(struct scsireturn 0 ; } -if (!vha->nvme_local_port &&qla_nvme_register_hba (vha)) +if (qla_nvme_register_hba (vha)) +return 0 ; + +if (!vha->nvme_local_port)return 0 ; if (!(fcport->nvme_prli_service_param &
Greg Kroah-Hartman
maintainerPATCH 170/352 perf/x86/intel/pt: Fix topa_entry base length
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marco Cavenati <[email protected]>
commit 5638bd722a44bbe97c1a7b3fae5b9efddb3e70ff upstream.
topa_entry->base needs to store a pfn. It obviously needs to be large enough to store the largest possible x86 pfn which is MAXPHYADDR-PAGE_SIZE (52-12). So it is 4 bits too small.
Increase the size of topa_entry->base from 36 bits to 40 bits.
Note, systems where physical addresses can be 256TiB or more are affected.
[ Adrian: Amend commit message as suggested by Dave Hansen ]
--- arch/x86/events/intel/pt.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/events/intel/pt.h +2 -2
@@ -33,8 +33,8 @@ struct topa_entry { u64 rsvd2 : 1; u64 size : 4; u64 rsvd3 : 2; - u64 base : 36; - u64 rsvd4 : 16; + u64 base : 40; + u64 rsvd4 : 12; };/* TSC to Core Crystal Clock Ratio */
Greg Kroah-Hartman
maintainerPATCH 171/352 perf/x86/intel/pt: Fix a topa_entry base address calculation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit ad97196379d0b8cb24ef3d5006978a6554e6467f upstream.
topa_entry->base is a bit-field. Bit-fields are not promoted to a 64-bit type, even if the underlying type is 64-bit, and so, if necessary, must be cast to a larger type when calculations are done.
Fix a topa_entry->base address calculation by adding a cast.
Without the cast, the address was limited to 36-bits i.e. 64GiB.
The address calculation is used on systems that do not support Multiple Entry ToPA (only Broadwell), and affects physical addresses on or above 64GiB. Instead of writing to the correct address, the address comprising the first 36 bits would be written to.
Intel PT snapshot and sampling modes are not affected.
--- arch/x86/events/intel/pt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/events/intel/pt.c +1 -1
@@ -861,7 +861,7 @@ static void pt_update_head(struct pt *pt*/ static void *pt_buffer_region (struct pt_buffer *buf) { -return phys_to_virt (TOPA_ENTRY (buf->cur, buf->cur_idx)->base <<TOPA_SHIFT ); +return phys_to_virt ((phys_addr_t )TOPA_ENTRY (buf->cur, buf->cur_idx)->base <<TOPA_SHIFT ); }/**
Greg Kroah-Hartman
maintainerPATCH 172/352 rtc: isl1208: Fix return value of nvmem callbacks
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joy Chakraborty <[email protected]>
commit 70f1ae5f0e7f44edf842444044615da7b59838c1 upstream.
Read/write callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure.
isl1208_nvmem_read()/isl1208_nvmem_write() currently return the number of bytes read/written on success, fix to return 0 on success and negative on failure.
--- drivers/rtc/rtc-isl1208.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
drivers/rtc/rtc-isl1208.c +4 -7
@@ -743,14 +743,13 @@ static int isl1208_nvmem_read(void *priv {struct isl1208_state *isl1208 = priv;struct i2c_client *client =to_i2c_client (isl1208->rtc->dev.parent); -int ret;/* nvmem sanitizes offset/count for us, but count==0 is possible */ if (!count)return count; - ret =isl1208_i2c_read_regs (client,ISL1208_REG_USR1 + off, buf, + +return isl1208_i2c_read_regs (client,ISL1208_REG_USR1 + off, buf, count); -return ret ==0 ? count : ret; } static int isl1208_nvmem_write(void *priv, unsigned int off, void *buf,
@@ -758,15 +757,13 @@ static int isl1208_nvmem_write(void *pri {struct isl1208_state *isl1208 = priv;struct i2c_client *client =to_i2c_client (isl1208->rtc->dev.parent); -int ret;/* nvmem sanitizes off/count for us, but count==0 is possible */ if (!count)return count; - ret =isl1208_i2c_set_regs (client,ISL1208_REG_USR1 + off, buf, - count); -return ret ==0 ? count : ret; +return isl1208_i2c_set_regs (client,ISL1208_REG_USR1 + off, buf, + count); }static const struct nvmem_config isl1208_nvmem_config = {
Greg Kroah-Hartman
maintainerPATCH 173/352 watchdog/perf: properly initialize the turbo mode timestamp and rearm counter
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit f944ffcbc2e1c759764850261670586ddf3bdabb upstream.
For systems on which the performance counter can expire early due to turbo modes the watchdog handler has a safety net in place which validates that since the last watchdog event there has at least 4/5th of the watchdog period elapsed.
This works reliably only after the first watchdog event because the per CPU variable which holds the timestamp of the last event is never initialized.
So a first spurious event will validate against a timestamp of 0 which results in a delta which is likely to be way over the 4/5 threshold of the period. As this might happen before the first watchdog hrtimer event increments the watchdog counter, this can lead to false positives.
Fix this by initializing the timestamp before enabling the hardware event. Reset the rearm counter as well, as that might be non zero after the watchdog was disabled and reenabled.
--- kernel/watchdog_hld.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
kernel/watchdog_hld.c +8 -3
@@ -91,11 +91,15 @@ static bool watchdog_check_timestamp(voi__this_cpu_write (last_timestamp, now);return true; } -#else -static inline bool watchdog_check_timestamp (void ) + +static void watchdog_init_timestamp (void ) { -return true; +__this_cpu_write (nmi_rearmed,0 ); +__this_cpu_write (last_timestamp,ktime_get_mono_fast_ns ()); } +#else +static inline bool watchdog_check_timestamp (void ) {return true; } +static inline void watchdog_init_timestamp (void ) { }#endif static struct perf_event_attr wd_hw_attr = {
@@ -196,6 +200,7 @@ void hardlockup_detector_perf_enable(voiif (!atomic_fetch_inc (&watchdog_cpus))pr_info ("Enabled. Permanently consumes one hw-PMU counter.\n" ); +watchdog_init_timestamp ();perf_event_enable (this_cpu_read (watchdog_ev)); }
Greg Kroah-Hartman
maintainerPATCH 174/352 platform: mips: cpu_hwmon: Disable driver on unsupported hardware
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit f4d430db17b4ef4e9c3c352a04b2fe3c93011978 upstream.
cpu_hwmon is unsupported on CPUs without loongson_chiptemp register and csr.
--- drivers/platform/mips/cpu_hwmon.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/platform/mips/cpu_hwmon.c +3 -0
@@ -139,6 +139,9 @@ static int __init loongson_hwmon_init(vo csr_temp_enable =csr_readl (LOONGSON_CSR_FEATURES ) &LOONGSON_CSRF_TEMP ; +if (!csr_temp_enable && !loongson_chiptemp[0 ]) +return -ENODEV ; + nr_packages = loongson_sysconf.nr_cpus / loongson_sysconf.cores_per_package;
Greg Kroah-Hartman
maintainerPATCH 175/352 RDMA/iwcm: Fix a use-after-free related to destroying CM IDs
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <[email protected]>
commit aee2424246f9f1dadc33faa78990c1e2eb7826e4 upstream.
iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows:
conn_id->cm_id.iw = cm_id;
cm_id->context = conn_id;
cm_id->cm_handler = cma_iw_handler;rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished.
--- drivers/infiniband/core/iwcm.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/infiniband/core/iwcm.c +7 -4
@@ -370,8 +370,10 @@ EXPORT_SYMBOL(iw_cm_disconnect);* * Clean up all resources associated with the connection and release * the initial reference taken by iw_create_cm_id. +* +* Returns true if and only if the last cm_id_priv reference has been dropped. */ -static void destroy_cm_id (struct iw_cm_id *cm_id) +static bool destroy_cm_id (struct iw_cm_id *cm_id) {struct iwcm_id_private *cm_id_priv;struct ib_qp *qp;
@@ -441,7 +443,7 @@ static void destroy_cm_id(struct iw_cm_iiwpm_remove_mapping (&cm_id->local_addr,RDMA_NL_IWCM ); } - (void )iwcm_deref_id (cm_id_priv); +return iwcm_deref_id (cm_id_priv); }/*
@@ -452,7 +454,8 @@ static void destroy_cm_id(struct iw_cm_i*/ void iw_destroy_cm_id (struct iw_cm_id *cm_id) { -destroy_cm_id (cm_id); +if (!destroy_cm_id (cm_id)) +flush_workqueue (iwcm_wq); }EXPORT_SYMBOL (iw_destroy_cm_id);
@@ -1036,7 +1039,7 @@ static void cm_work_handler(struct work_if (!test_bit (IWCM_F_DROP_EVENTS , &cm_id_priv->flags)) { ret =process_event (cm_id_priv, &levent);if (ret) -destroy_cm_id (&cm_id_priv->id); +WARN_ON_ONCE (destroy_cm_id (&cm_id_priv->id)); }else pr_debug ("dropping event %d\n" , levent.event);if (iwcm_deref_id (cm_id_priv))
Greg Kroah-Hartman
maintainerPATCH 176/352 selftests/sigaltstack: Fix ppc64 GCC build
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <[email protected]>
commit 17c743b9da9e0d073ff19fd5313f521744514939 upstream.
Building the sigaltstack test with GCC on 64-bit powerpc errors with:
gcc -Wall sas.c -o /home/michael/linux/.build/kselftest/sigaltstack/sas
In file included from sas.c:23:
current_stack_pointer.h:22:2: error: #error "implement current_stack_pointer equivalent"
22 | #error "implement current_stack_pointer equivalent"
| ^~~~~
sas.c: In function ‘my_usr1’:
sas.c:50:13: error: ‘sp’ undeclared (first use in this function); did you mean ‘p’?
50 | if (sp < (unsigned long)sstack ||
| ^~This happens because GCC doesn't define __ppc__ for 64-bit builds, only 32-bit builds. Instead use __powerpc__ to detect powerpc builds, which is defined by clang and GCC for 64-bit and 32-bit builds.
--- tools/testing/selftests/sigaltstack/current_stack_pointer.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/sigaltstack/current_stack_pointer.h +1 -1
@@ -8,7 +8,7 @@ register unsigned long sp asm("sp"); registerunsigned long sp asm("esp" );#elif __loongarch64 registerunsigned long sp asm("$sp" ); -#elif __ppc__ +#elif __powerpc__ registerunsigned long sp asm("r1" );#elif __s390x__ registerunsigned long sp asm("%15" );
Greg Kroah-Hartman
maintainerPATCH 177/352 rbd: dont assume rbd_is_lock_owner() for exclusive mappings
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 3ceccb14f5576e02b81cc8b105ab81f224bd87f6 upstream.
Expanding on the previous commit, assuming that rbd_is_lock_owner() always returns true (i.e. that we are either in RBD_LOCK_STATE_LOCKED or RBD_LOCK_STATE_QUIESCING) if the mapping is exclusive is wrong too. In case ceph_cls_set_cookie() fails, the lock would be temporarily released even if the mapping is exclusive, meaning that we can end up even in RBD_LOCK_STATE_UNLOCKED.
IOW, exclusive mappings are really "just" about disabling automatic lock transitions (as documented in the man page), not about grabbing the lock and holding on to it whatever it takes.
--- drivers/block/rbd.c | 5 ----- 1 file changed, 5 deletions(-)
drivers/block/rbd.c +0 -5
@@ -6660,11 +6660,6 @@ static int rbd_add_acquire_lock(struct rif (ret)return ret; -/* -* The lock may have been released by now, unless automatic lock -* transitions are disabled. -*/ -rbd_assert (!rbd_dev->opts->exclusive ||rbd_is_lock_owner (rbd_dev));return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 178/352 MIPS: ip30: ip30-console: Add missing include
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit 8de4ed75bd14ed197119ac509c6902a8561e0c1c upstream.
Include linux/processor.h to fix build error:
arch/mips/sgi-ip30/ip30-console.c: In function ‘prom_putchar’:arch/mips/sgi-ip30/ip30-console.c:21:17: error: implicit declaration of function ‘cpu_relax’ [-Werror=implicit-function-declaration]
21 | cpu_relax();
--- arch/mips/sgi-ip30/ip30-console.c | 1 + 1 file changed, 1 insertion(+)
arch/mips/sgi-ip30/ip30-console.c +1 -0
@@ -1,6 +1,7 @@// SPDX-License-Identifier: GPL-2.0 #include <linux/io.h> +#include <linux/processor.h> #include <asm/sn/ioc3.h>
Greg Kroah-Hartman
maintainerPATCH 179/352 MIPS: Loongson64: env: Hook up Loongsson-2K
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit 77543269ff23c75bebfb8e6e9a1177b350908ea7 upstream.
Somehow those enablement bits were left over when we were adding initial Loongson-2K support.
Set up basic information and select proper builtin DTB for Loongson-2K.
--- arch/mips/include/asm/mach-loongson64/boot_param.h | 2 ++ arch/mips/loongson64/env.c | 8 ++++++++ 2 files changed, 10 insertions(+)
arch/mips/include/asm/mach-loongson64/boot_param.h +2 -0
@@ -38,12 +38,14 @@ enum loongson_cpu_type { Legacy_1B =0x5 , Legacy_2G =0x6 , Legacy_2H =0x7 , + Legacy_2K =0x8 , Loongson_1A =0x100 , Loongson_1B =0x101 , Loongson_2E =0x200 , Loongson_2F =0x201 , Loongson_2G =0x202 , Loongson_2H =0x203 , + Loongson_2K =0x204 , Loongson_3A =0x300 , Loongson_3B =0x301 };
arch/mips/loongson64/env.c +8 -0
@@ -65,6 +65,12 @@ void __init prom_init_env(void) cpu_clock_freq = ecpu->cpu_clock_freq; loongson_sysconf.cputype = ecpu->cputype;switch (ecpu->cputype) { +case Legacy_2K: +case Loongson_2K: + smp_group[0 ] =0x900000001fe11000 ; + loongson_sysconf.cores_per_node =2 ; + loongson_sysconf.cores_per_package =2 ; +break ;case Legacy_3A:case Loongson_3A: loongson_sysconf.cores_per_node =4 ;
@@ -213,6 +219,8 @@ void __init prom_init_env(void)default :break ; } + }else if ((read_c0_prid () &PRID_IMP_MASK ) ==PRID_IMP_LOONGSON_64R ) { + loongson_fdt_blob = __dtb_loongson64_2core_2k1000_begin; }else if ((read_c0_prid () &PRID_IMP_MASK ) ==PRID_IMP_LOONGSON_64G ) {if (loongson_sysconf.bridgetype ==LS7A ) loongson_fdt_blob = __dtb_loongson64g_4core_ls7a_begin;
Greg Kroah-Hartman
maintainerPATCH 180/352 drm/panfrost: Mark simple_ondemand governor as softdep
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dragan Simic <[email protected]>
commit 80f4e62730a91572b7fdc657f7bb747e107ae308 upstream.
Panfrost DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Panfrost, to have its kernel module included in the initial ramdisk.
This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or has forced users to introduce some unnecessary workarounds. [3]
For future reference, not having support for the simple_ondemand governor in the initial ramdisk produces errors in the kernel log similar to these below, which were taken from a Pine64 RockPro64:
panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq panfrost ff9a0000.gpu: Fatal error during GPU init
panfrost: probe of ff9a0000.gpu failed with error -22
Having simple_ondemand marked as a softdep for Panfrost may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [4] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [5] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet.
[1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/linux61/config?ref_type=heads#L8180
[2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1066
[3] https://forum.pine64.org/showthread.php?tid=15458
[4] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d
[5] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad
--- drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/panfrost/panfrost_drv.c +1 -0
@@ -681,3 +681,4 @@ module_platform_driver(panfrost_driver);MODULE_AUTHOR ("Panfrost Project Developers" );MODULE_DESCRIPTION ("Panfrost DRM Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_SOFTDEP ("pre: governor_simpleondemand" );
Greg Kroah-Hartman
maintainerPATCH 181/352 rbd: rename RBD_LOCK_STATE_RELEASING and releasing_wait
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit f5c466a0fdb2d9f3650d2e3911b0735f17ba00cf upstream.
... to RBD_LOCK_STATE_QUIESCING and quiescing_wait to recognize that this state and the associated completion are backing rbd_quiesce_lock(), which isn't specific to releasing the lock.
While exclusive lock does get quiesced before it's released, it also gets quiesced before an attempt to update the cookie is made and there the lock is not released as long as ceph_cls_set_cookie() succeeds.
--- drivers/block/rbd.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/block/rbd.c +10 -10
@@ -362,7 +362,7 @@ enum rbd_watch_state {enum rbd_lock_state {RBD_LOCK_STATE_UNLOCKED ,RBD_LOCK_STATE_LOCKED , -RBD_LOCK_STATE_RELEASING , +RBD_LOCK_STATE_QUIESCING , };/* WatchNotify::ClientId */
@@ -422,7 +422,7 @@ struct rbd_device {struct list_head running_list;struct completion acquire_wait;int acquire_err; -struct completion releasing_wait; +struct completion quiescing_wait;spinlock_t object_map_lock;u8 *object_map;
@@ -525,7 +525,7 @@ static bool __rbd_is_lock_owner(struct rlockdep_assert_held (&rbd_dev->lock_rwsem);return rbd_dev->lock_state ==RBD_LOCK_STATE_LOCKED || - rbd_dev->lock_state ==RBD_LOCK_STATE_RELEASING ; + rbd_dev->lock_state ==RBD_LOCK_STATE_QUIESCING ; }static bool rbd_is_lock_owner (struct rbd_device *rbd_dev)
@@ -3523,12 +3523,12 @@ static void rbd_lock_del_request(structspin_lock (&rbd_dev->lock_lists_lock);if (!list_empty (&img_req->lock_item)) {list_del_init (&img_req->lock_item); - need_wakeup = (rbd_dev->lock_state ==RBD_LOCK_STATE_RELEASING && + need_wakeup = (rbd_dev->lock_state ==RBD_LOCK_STATE_QUIESCING &&list_empty (&rbd_dev->running_list)); }spin_unlock (&rbd_dev->lock_lists_lock);if (need_wakeup) -complete (&rbd_dev->releasing_wait); +complete (&rbd_dev->quiescing_wait); }static int rbd_img_exclusive_lock (struct rbd_img_request *img_req)
@@ -4237,16 +4237,16 @@ static bool rbd_quiesce_lock(struct rbd_/* * Ensure that all in-flight IO is flushed. */ - rbd_dev->lock_state =RBD_LOCK_STATE_RELEASING ; -rbd_assert (!completion_done (&rbd_dev->releasing_wait)); + rbd_dev->lock_state =RBD_LOCK_STATE_QUIESCING ; +rbd_assert (!completion_done (&rbd_dev->quiescing_wait));if (list_empty (&rbd_dev->running_list))return true;up_write (&rbd_dev->lock_rwsem); -wait_for_completion (&rbd_dev->releasing_wait); +wait_for_completion (&rbd_dev->quiescing_wait);down_write (&rbd_dev->lock_rwsem); -if (rbd_dev->lock_state !=RBD_LOCK_STATE_RELEASING ) +if (rbd_dev->lock_state !=RBD_LOCK_STATE_QUIESCING )return false;rbd_assert (list_empty (&rbd_dev->running_list));
@@ -5455,7 +5455,7 @@ static struct rbd_device *__rbd_dev_creaINIT_LIST_HEAD (&rbd_dev->acquiring_list);INIT_LIST_HEAD (&rbd_dev->running_list);init_completion (&rbd_dev->acquire_wait); -init_completion (&rbd_dev->releasing_wait); +init_completion (&rbd_dev->quiescing_wait);spin_lock_init (&rbd_dev->object_map_lock);
Greg Kroah-Hartman
maintainerPATCH 182/352 rbd: dont assume RBD_LOCK_STATE_LOCKED for exclusive mappings
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 2237ceb71f89837ac47c5dce2aaa2c2b3a337a3c upstream.
Every time a watch is reestablished after getting lost, we need to update the cookie which involves quiescing exclusive lock. For this, we transition from RBD_LOCK_STATE_LOCKED to RBD_LOCK_STATE_QUIESCING roughly for the duration of rbd_reacquire_lock() call. If the mapping is exclusive and I/O happens to arrive in this time window, it's failed with EROFS (later translated to EIO) based on the wrong assumption in rbd_img_exclusive_lock() -- "lock got released?" check there stopped making sense with commit a2b1da09793d ("rbd: lock should be quiesced on reacquire").
To make it worse, any such I/O is added to the acquiring list before EROFS is returned and this sets up for violating rbd_lock_del_request() precondition that the request is either on the running list or not on any list at all -- see commit ded080c86b3f ("rbd: don't move requests to the running list on errors"). rbd_lock_del_request() ends up processing these requests as if they were on the running list which screws up quiescing_wait completion counter and ultimately leads to
rbd_assert(!completion_done(&rbd_dev->quiescing_wait));
being triggered on the next watch error.
--- drivers/block/rbd.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/block/rbd.c +5 -5
@@ -3522,6 +3522,7 @@ static void rbd_lock_del_request(structlockdep_assert_held (&rbd_dev->lock_rwsem);spin_lock (&rbd_dev->lock_lists_lock);if (!list_empty (&img_req->lock_item)) { +rbd_assert (!list_empty (&rbd_dev->running_list));list_del_init (&img_req->lock_item); need_wakeup = (rbd_dev->lock_state ==RBD_LOCK_STATE_QUIESCING &&list_empty (&rbd_dev->running_list));
@@ -3541,11 +3542,6 @@ static int rbd_img_exclusive_lock(structif (rbd_lock_add_request (img_req))return 1 ; -if (rbd_dev->opts->exclusive) { -WARN_ON (1 );/* lock got released? */ -return -EROFS ; - } -/* * Note the use of mod_delayed_work() in rbd_acquire_lock() * and cancel_delayed_work() in wake_lock_waiters().
@@ -4657,6 +4653,10 @@ static void rbd_reacquire_lock(struct rbrbd_warn (rbd_dev,"failed to update lock cookie: %d" , ret); +if (rbd_dev->opts->exclusive) +rbd_warn (rbd_dev, +"temporarily releasing lock on exclusive mapping" ); +/* * Lock cookie cannot be updated on older OSDs, so do * a manual release and queue an acquire.
Greg Kroah-Hartman
maintainerPATCH 183/352 Bluetooth: btusb: Add RTL8852BE device 0489:e125 to device tables
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hilda Wu <[email protected]>
commit 295ef07a9dae6182ad4b689aa8c6a7dbba21474c upstream.
Add the support ID 0489:e125 to usb_device_id table for Realtek RTL8852B chip.
The device info from /sys/kernel/debug/usb/devices as below.
T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e125 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/bluetooth/btusb.c +2 -0
@@ -428,6 +428,8 @@ static const struct usb_device_id blackl BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3571), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x0489, 0xe125), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH },/* Realtek Bluetooth devices */ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01),
Greg Kroah-Hartman
maintainerPATCH 184/352 Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x13d3:0x3591
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
commit 473a89b4ed7fd52a419340f7c540d5c8fc96fc75 upstream.
Add the support ID(0x13d3, 0x3591) to usb_device_id table for Realtek RTL8852BE.
The device table is as follows:
T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3591 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/bluetooth/btusb.c +2 -0
@@ -428,6 +428,8 @@ static const struct usb_device_id blackl BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3571), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3591), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0489, 0xe125), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH },
Greg Kroah-Hartman
maintainerPATCH 185/352 nilfs2: handle inconsistent state in nilfs_btnode_create_block()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <[email protected]>
commit 4811f7af6090e8f5a398fbdd766f903ef6c0d787 upstream.
Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug.
It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state.
So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.
--- fs/nilfs2/btnode.c | 25 ++++++++++++++++++++----- fs/nilfs2/btree.c | 4 ++-- 2 files changed, 22 insertions(+), 7 deletions(-)
fs/nilfs2/btnode.c +20 -5
@@ -51,12 +51,21 @@ nilfs_btnode_create_block(struct address bh =nilfs_grab_buffer (inode, btnc, blocknr,BIT (BH_NILFS_Node));if (unlikely (!bh)) -return NULL ; +return ERR_PTR (-ENOMEM );if (unlikely (buffer_mapped (bh) ||buffer_uptodate (bh) ||buffer_dirty (bh))) { -brelse (bh); -BUG (); +/* +* The block buffer at the specified new address was already +* in use. This can happen if it is a virtual block number +* and has been reallocated due to corruption of the bitmap +* used to manage its allocation state (if not, the buffer +* clearing of an abandoned b-tree node is missing somewhere). +*/ +nilfs_error (inode->i_sb, +"state inconsistency probably due to duplicate use of b-tree node block address %llu (ino=%lu)" , + (unsigned long long )blocknr, inode->i_ino); + goto failed; }memset (bh->b_data,0 ,i_blocksize (inode)); bh->b_bdev = inode->i_sb->s_bdev;
@@ -67,6 +76,12 @@ nilfs_btnode_create_block(struct addressunlock_page (bh->b_page);put_page (bh->b_page);return bh; + +failed: +unlock_page (bh->b_page); +put_page (bh->b_page); +brelse (bh); +return ERR_PTR (-EIO ); } int nilfs_btnode_submit_block(struct address_space *btnc, __u64 blocknr,
@@ -217,8 +232,8 @@ retry: } nbh =nilfs_btnode_create_block (btnc, newkey); -if (!nbh) -return -ENOMEM ; +if (IS_ERR (nbh)) +return PTR_ERR (nbh);BUG_ON (nbh == obh); ctxt->newbh = nbh;
fs/nilfs2/btree.c +2 -2
@@ -63,8 +63,8 @@ static int nilfs_btree_get_new_block(construct buffer_head *bh; bh =nilfs_btnode_create_block (btnc, ptr); -if (!bh) -return -ENOMEM ; +if (IS_ERR (bh)) +return PTR_ERR (bh);set_buffer_nilfs_volatile (bh); *bhp = bh;
Greg Kroah-Hartman
maintainerPATCH 186/352 io_uring/io-wq: limit retrying worker initialisation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
commit 0453aad676ff99787124b9b3af4a5f59fbe808e2 upstream.
If io-wq worker creation fails, we retry it by queueing up a task_work. tasK_work is needed because it should be done from the user process context. The problem is that retries are not limited, and if queueing a task_work is the reason for the failure, we might get into an infinite loop.
It doesn't seem to happen now but it would with the following patch executing task_work in the freezer's loop. For now, arbitrarily limit the number of attempts to create a worker.
--- io_uring/io-wq.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
io_uring/io-wq.c +7 -3
@@ -19,6 +19,7 @@#include "io-wq.h" #define WORKER_IDLE_TIMEOUT (5 * HZ) +#define WORKER_INIT_LIMIT 3enum {IO_WORKER_F_UP =1 ,/* up and active */
@@ -54,6 +55,7 @@ struct io_worker {unsigned long create_state;struct callback_head create_work;int create_index; +int init_retries;union {struct rcu_head rcu;
@@ -732,7 +734,7 @@ static bool io_wq_work_match_all(structreturn true; } -static inline bool io_should_retry_thread (long err) +static inline bool io_should_retry_thread (struct io_worker *worker,long err) {/* * Prevent perpetual task_work retry, if the task (or its group) is
@@ -740,6 +742,8 @@ static inline bool io_should_retry_threa*/ if (fatal_signal_pending (current))return false; +if (worker->init_retries++ >=WORKER_INIT_LIMIT ) +return false;switch (err) {case -EAGAIN :
@@ -766,7 +770,7 @@ static void create_worker_cont(struct caio_init_new_worker (wqe, worker, tsk);io_worker_release (worker);return ; - }else if (!io_should_retry_thread (PTR_ERR (tsk))) { + }else if (!io_should_retry_thread (worker,PTR_ERR (tsk))) {struct io_wqe_acct *acct =io_wqe_get_acct (worker);atomic_dec (&acct->nr_running);
@@ -831,7 +835,7 @@ fail: tsk =create_io_thread (io_wqe_worker, worker, wqe->node);if (!IS_ERR (tsk)) {io_init_new_worker (wqe, worker, tsk); - }else if (!io_should_retry_thread (PTR_ERR (tsk))) { + }else if (!io_should_retry_thread (worker,PTR_ERR (tsk))) {kfree (worker); goto fail; }else {
Greg Kroah-Hartman
maintainerPATCH 187/352 kernel: rerun task_work while freezing in get_signal()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
commit 943ad0b62e3c21f324c4884caa6cb4a871bca05c upstream.
io_uring can asynchronously add a task_work while the task is getting freezed. TIF_NOTIFY_SIGNAL will prevent the task from sleeping in do_freezer_trap(), and since the get_signal()'s relock loop doesn't retry task_work, the task will spin there not being able to sleep until the freezing is cancelled / the task is killed / etc.
Run task_works in the freezer path. Keep the patch small and simple so it can be easily back ported, but we might need to do some cleaning after and look if there are other places with similar problems.
--- include/linux/sched/signal.h | 6 ++++++ kernel/signal.c | 8 ++++++++ 2 files changed, 14 insertions(+)
include/linux/sched/signal.h +6 -0
@@ -348,6 +348,12 @@ extern void sigqueue_free(struct sigqueuextern int send_sigqueue (struct sigqueue *,struct pid *,enum pid_type );extern int do_sigaction (int ,struct k_sigaction *,struct k_sigaction *); +static inline void clear_notify_signal (void ) +{ +clear_thread_flag (TIF_NOTIFY_SIGNAL ); +smp_mb__after_atomic (); +} +static inline int restart_syscall (void ) {set_tsk_thread_flag (current,TIF_SIGPENDING );
kernel/signal.c +8 -0
@@ -2464,6 +2464,14 @@ static void do_freezer_trap(void)spin_unlock_irq (¤t->sighand->siglock);cgroup_enter_frozen ();freezable_schedule (); + +/* +* We could've been woken by task_work, run it to clear +* TIF_NOTIFY_SIGNAL. The caller will retry if necessary. +*/ +clear_notify_signal (); +if (unlikely (READ_ONCE (current->task_works))) +task_work_run (); }static int ptrace_signal (int signr,kernel_siginfo_t *info)
Greg Kroah-Hartman
maintainerPATCH 188/352 kdb: address -Wformat-security warnings
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 70867efacf4370b6c7cdfc7a5b11300e9ef7de64 ]
When -Wformat-security is not disabled, using a string pointer as a format causes a warning:
kernel/debug/kdb/kdb_io.c: In function 'kdb_read':kernel/debug/kdb/kdb_io.c:365:36: error: format not a string literal and no format arguments [-Werror=format-security]
365 | kdb_printf(kdb_prompt_str);
| ^~~~~~~~~~~~~~
kernel/debug/kdb/kdb_io.c: In function 'kdb_getstr':
kernel/debug/kdb/kdb_io.c:456:20: error: format not a string literal and no format arguments [-Werror=format-security]
456 | kdb_printf(kdb_prompt_str);
| ^~~~~~~~~~~~~~Use an explcit "%s" format instead.
--- kernel/debug/kdb/kdb_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/debug/kdb/kdb_io.c +2 -2
@@ -358,7 +358,7 @@ static char *kdb_read(char *buffer, size_t bufsize)if (i >= dtab_count)kdb_printf ("..." );kdb_printf ("\n" ); -kdb_printf (kdb_prompt_str); +kdb_printf ("%s" , kdb_prompt_str);kdb_printf ("%s" , buffer);if (cp != lastchar)kdb_position_cursor (kdb_prompt_str, buffer, cp);
@@ -450,7 +450,7 @@ char *kdb_getstr(char *buffer, size_t bufsize, const char *prompt) {if (prompt && kdb_prompt_str != prompt)strscpy (kdb_prompt_str, prompt,CMD_BUFLEN ); -kdb_printf (kdb_prompt_str); +kdb_printf ("%s" , kdb_prompt_str); kdb_nextline =1 ;/* Prompt and input resets line number */ return kdb_read (buffer, bufsize); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 189/352 kdb: Use the passed prompt in kdb_position_cursor()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Anderson <[email protected]>
[ Upstream commit e2e821095949cde46256034975a90f88626a2a73 ]
The function kdb_position_cursor() takes in a "prompt" parameter but never uses it. This doesn't _really_ matter since all current callers of the function pass the same value and it's a global variable, but it's a bit ugly. Let's clean it up.
Found by code inspection. This patch is expected to functionally be a no-op.
--- kernel/debug/kdb/kdb_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/debug/kdb/kdb_io.c +1 -1
@@ -194,7 +194,7 @@ char kdb_getchar(void)*/ static void kdb_position_cursor (char *prompt,char *buffer,char *cp) { -kdb_printf ("\r%s" , kdb_prompt_str); +kdb_printf ("\r%s" , prompt);if (cp > buffer)kdb_printf ("%.*s" , (int )(cp - buffer), buffer); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 190/352 jfs: Fix array-index-out-of-bounds in diFree
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeongjun Park <[email protected]>
[ Upstream commit f73f969b2eb39ad8056f6c7f3a295fa2f85e313a ]
--- fs/jfs/jfs_imap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/jfs/jfs_imap.c +4 -1
@@ -292,7 +292,7 @@ int diSync(struct inode *ipimap)int diRead (struct inode *ip) {struct jfs_sb_info *sbi =JFS_SBI (ip->i_sb); -int iagno, ino, extno, rc; +int iagno, ino, extno, rc, agno;struct inode *ipimap;struct dinode *dp;struct iag *iagp;
@@ -341,8 +341,11 @@ int diRead(struct inode *ip)/* get the ag for the iag */ agstart =le64_to_cpu (iagp->agstart); + agno =BLKTOAG (agstart,JFS_SBI (ip->i_sb));release_metapage (mp); +if (agno >=MAXAG || agno <0 ) +return -EIO ; rel_inode = (ino & (INOSPERPAGE -1 )); pageno = blkno >> sbi->l2nbperpage;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 191/352 um: time-travel: fix time-travel-start option
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ Upstream commit 7d0a8a490aa3a2a82de8826aaf1dfa38575cb77a ]
We need to have the = as part of the option so that the value can be parsed properly. Also document that it must be given in nanoseconds, not seconds.
--- arch/um/kernel/time.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/um/kernel/time.c +2 -2
@@ -756,9 +756,9 @@ int setup_time_travel_start(char *str) return 1; } -__setup ("time-travel-start" , setup_time_travel_start); +__setup ("time-travel-start=" , setup_time_travel_start);__uml_help (setup_time_travel_start, -"time-travel-start=<seconds>\n" +"time-travel-start=<nanoseconds>\n" "Configure the UML instance's wall clock to start at this value rather than\n" "the host's wall clock at the time of UML boot.\n" );#endif
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 192/352 f2fs: fix start segno of large section
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sheng Yong <[email protected]>
[ Upstream commit 8c409989678e92e4a737e7cd2bb04f3efb81071a ]
get_ckpt_valid_blocks() checks valid ckpt blocks in current section. It counts all vblocks from the first to the last segment in the large section. However, START_SEGNO() is used to get the first segno in an SIT block. This patch fixes that to get the correct start segno.
--- fs/f2fs/segment.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/f2fs/segment.h +2 -1
@@ -371,7 +371,8 @@ static inline unsigned int get_ckpt_valid_blocks(struct f2fs_sb_info *sbi, unsigned int segno, bool use_section) {if (use_section &&__is_large_section (sbi)) { -unsigned int start_segno =START_SEGNO (segno); +unsigned int secno =GET_SEC_FROM_SEG (sbi, segno); +unsigned int start_segno =GET_SEG_FROM_SEC (sbi, secno);unsigned int blocks =0 ;int i;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 193/352 libbpf: Fix no-args func prototype BTF dumping syntax
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrii Nakryiko <[email protected]>
[ Upstream commit 189f1a976e426011e6a5588f1d3ceedf71fe2965 ]
For all these years libbpf's BTF dumper has been emitting not strictly valid syntax for function prototypes that have no input arguments.
Instead of int (*blah)() we should emit int (*blah)(void).
This is not normally a problem, but it manifests when we get kfuncs in vmlinux.h that have no input arguments. Due to compiler internal specifics, we get no BTF information for such kfuncs, if they are not declared with proper (void).
The fix is trivial. We also need to adjust a few ancient tests that happily assumed () is correct.
--- tools/lib/bpf/btf_dump.c | 8 +++++--- .../selftests/bpf/progs/btf_dump_test_case_multidim.c | 4 ++-- .../selftests/bpf/progs/btf_dump_test_case_syntax.c | 4 ++-- 3 files changed, 9 insertions(+), 7 deletions(-)
tools/lib/bpf/btf_dump.c +5 -3
@@ -1426,10 +1426,12 @@ static void btf_dump_emit_type_chain(struct btf_dump *d,* Clang for BPF target generates func_proto with no * args as a func_proto with a single void arg (e.g., * `int (*f)(void)` vs just `int (*f)()`). We are -* going to pretend there are no args for such case. +* going to emit valid empty args (void) syntax for +* such case. Similarly and conveniently, valid +* no args case can be special-cased here as well. */ -if (vlen ==1 && p->type ==0 ) { -btf_dump_printf (d,")" ); +if (vlen ==0 || (vlen ==1 && p->type ==0 )) { +btf_dump_printf (d,"void)" );return ; }
tools/testing/selftests/bpf/progs/btf_dump_test_case_multidim.c +2 -2
@@ -14,9 +14,9 @@ typedef int *ptr_arr_t[6];typedef int *ptr_multiarr_t [7 ][8 ][9 ][10 ]; -typedef int * (*fn_ptr_arr_t [11 ])(); +typedef int * (*fn_ptr_arr_t [11 ])(void ); -typedef int * (*fn_ptr_multiarr_t [12 ][13 ])(); +typedef int * (*fn_ptr_multiarr_t [12 ][13 ])(void );struct root_struct {arr_t _1;
tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c +2 -2
@@ -67,7 +67,7 @@ typedef void (*printf_fn_t)(const char *, ...);* `int -> char *` function and returns pointer to a char. Equivalent: * typedef char * (*fn_input_t)(int); * typedef char * (*fn_output_outer_t)(fn_input_t); -* typedef const fn_output_outer_t (* fn_output_inner_t)(); +* typedef const fn_output_outer_t (* fn_output_inner_t)(void); * typedef const fn_output_inner_t fn_ptr_arr2_t[5]; */ /* ----- START-EXPECTED-OUTPUT ----- */
@@ -94,7 +94,7 @@ typedef void (* (*signal_t)(int, void (*)(int)))(int);typedef char * (*fn_ptr_arr1_t [10 ])(int **); -typedef char * (* (*const fn_ptr_arr2_t [5 ])())(char * (*)(int )); +typedef char * (* (*const fn_ptr_arr2_t [5 ])(void ))(char * (*)(int ));struct struct_w_typedefs {int_t a;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 194/352 dma: fix call order in dmam_free_coherent
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lance Richardson <[email protected]>
[ Upstream commit 28e8b7406d3a1f5329a03aa25a43aa28e087cb20 ]
dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list.
If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match.
Fix by destroying the devres entry before freeing the DMA allocation.
Tested:
kokonut //net/encryption
http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03
--- kernel/dma/mapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/dma/mapping.c +1 -1
@@ -60,8 +60,8 @@ void dmam_free_coherent(struct device *dev, size_t size, void *vaddr, {struct dma_devres match_data = { size, vaddr, dma_handle }; -dma_free_coherent (dev, size, vaddr, dma_handle);WARN_ON (devres_destroy (dev, dmam_release, dmam_match, &match_data)); +dma_free_coherent (dev, size, vaddr, dma_handle); }EXPORT_SYMBOL (dmam_free_coherent);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 195/352 MIPS: SMP-CPS: Fix address for GCR_ACCESS register for CM3 and later
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gregory CLEMENT <[email protected]>
[ Upstream commit a263e5f309f32301e1f3ad113293f4e68a82a646 ]
When the CM block migrated from CM2.5 to CM3.0, the address offset for the Global CSR Access Privilege register was modified. We saw this in the "MIPS64 I6500 Multiprocessing System Programmer's Guide," it is stated that "the Global CSR Access Privilege register is located at offset 0x0120" in section 5.4. It is at least the same for I6400.
This fix allows to use the VP cores in SMP mode if the reset values were modified by the bootloader.
Based on the work of Vladimir Kondratiev <[email protected]> and the feedback from Jiaxun Yang <[email protected]>.
--- arch/mips/include/asm/mips-cm.h | 4 ++++ arch/mips/kernel/smp-cps.c | 5 ++++- 2 files changed, 8 insertions(+), 1 deletion(-)
arch/mips/include/asm/mips-cm.h +4 -0
@@ -228,6 +228,10 @@ GCR_ACCESSOR_RO(32, 0x0d0, gic_status) GCR_ACCESSOR_RO(32, 0x0f0, cpc_status)#define CM_GCR_CPC_STATUS_EX BIT(0) +/* GCR_ACCESS - Controls core/IOCU access to GCRs */ +GCR_ACCESSOR_RW(32, 0x120, access_cm3) +#define CM_GCR_ACCESS_ACCESSEN GENMASK(7, 0) +/* GCR_L2_CONFIG - Indicates L2 cache configuration when Config5.L2C=1 */ GCR_ACCESSOR_RW(32, 0x130, l2_config)#define CM_GCR_L2_CONFIG_BYPASS BIT(20)
arch/mips/kernel/smp-cps.c +4 -1
@@ -229,7 +229,10 @@ static void boot_core(unsigned int core, unsigned int vpe_id)write_gcr_co_reset_ext_base (CM_GCR_Cx_RESET_EXT_BASE_UEB);/* Ensure the core can access the GCRs */ -set_gcr_access (1 << core); +if (mips_cm_revision () <CM_REV_CM3 ) +set_gcr_access (1 << core); +else +set_gcr_access_cm3 (1 << core);if (mips_cpc_present ()) {/* Reset the core */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 196/352 ipv4: Fix incorrect source address in Record Route option
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit cc73bbab4b1fb8a4f53a24645871dafa5f81266a ]
The Record Route IP option records the addresses of the routers that routed the packet. In the case of forwarded packets, the kernel performs a route lookup via fib_lookup() and fills in the preferred source address of the matched route.
The lookup is performed with the DS field of the forwarded packet, but using the RT_TOS() macro which only masks one of the two ECN bits. If the packet is ECT(0) or CE, the matched route might be different than the route via which the packet was forwarded as the input path masks both of the ECN bits, resulting in the wrong address being filled in the Record Route option.
Fix by masking both of the ECN bits.
--- net/ipv4/route.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/route.c +1 -1
@@ -1302,7 +1302,7 @@ void ip_rt_get_source(u8 *addr, struct sk_buff *skb, struct rtable *rt)struct flowi4 fl4 = { .daddr = iph->daddr, .saddr = iph->saddr, - .flowi4_tos =RT_TOS (iph->tos), + .flowi4_tos = iph->tos &IPTOS_RT_MASK , .flowi4_oif = rt->dst.dev->ifindex, .flowi4_iif = skb->dev->ifindex, .flowi4_mark = skb->mark,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 197/352 net: bonding: correctly annotate RCU in bond_should_notify_peers()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ Upstream commit 3ba359c0cd6eb5ea772125a7aededb4a2d516684 ]
RCU use in bond_should_notify_peers() looks wrong, since it does rcu_dereference(), leaves the critical section, and uses the pointer after that.
Luckily, it's called either inside a nested RCU critical section or with the RTNL held.
Annotate it with rcu_dereference_rtnl() instead, and remove the inner RCU critical section.
--- drivers/net/bonding/bond_main.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
drivers/net/bonding/bond_main.c +2 -5
@@ -1052,13 +1052,10 @@ static struct slave *bond_find_best_slave(struct bonding *bond)return bestslave; } +/* must be called in RCU critical section or with RTNL held */ static bool bond_should_notify_peers(struct bonding *bond) { - struct slave *slave; - - rcu_read_lock(); - slave = rcu_dereference(bond->curr_active_slave); - rcu_read_unlock(); + struct slave *slave = rcu_dereference_rtnl(bond->curr_active_slave); if (!slave || !bond->send_peer_notif || bond->send_peer_notif %
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 198/352 netfilter: nft_set_pipapo_avx2: disable softinterrupts
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
[ Upstream commit a16909ae9982e931841c456061cb57fbaec9c59e ]
We need to disable softinterrupts, else we get following problem:
1. pipapo_avx2 called from process context; fpu usable
2. preempt_disable() called, pcpu scratchmap in use
3. softirq handles rx or tx, we re-enter pipapo_avx2
4. fpu busy, fallback to generic non-avx version
5. fallback reuses scratch map and index, which are in use by the preempted process
Handle this same way as generic version by first disabling softinterrupts while the scratchmap is in use.
--- net/netfilter/nft_set_pipapo_avx2.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
net/netfilter/nft_set_pipapo_avx2.c +10 -2
@@ -1129,8 +1129,14 @@ bool nft_pipapo_avx2_lookup(const struct net *net, const struct nft_set *set,bool map_index;int i, ret =0 ; -if (unlikely (!irq_fpu_usable ())) -return nft_pipapo_lookup (net, set, key, ext); +local_bh_disable (); + +if (unlikely (!irq_fpu_usable ())) { +bool fallback_res =nft_pipapo_lookup (net, set, key, ext); + +local_bh_enable (); +return fallback_res; + } m =rcu_dereference (priv->match);
@@ -1140,6 +1146,7 @@ bool nft_pipapo_avx2_lookup(const struct net *net, const struct nft_set *set, scratch = *raw_cpu_ptr (m->scratch);if (unlikely (!scratch)) {kernel_fpu_end (); +local_bh_enable ();return false; }
@@ -1220,6 +1227,7 @@ bool nft_pipapo_avx2_lookup(const struct net *net, const struct nft_set *set,if (i %2 ) scratch->map_index = !map_index;kernel_fpu_end (); +local_bh_enable ();return ret >=0 ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 199/352 tipc: Return non-zero value from tipc_udp_addr2str() on error
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit fa96c6baef1b5385e2f0c0677b32b3839e716076 ]
tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address.
--- net/tipc/udp_media.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/tipc/udp_media.c +4 -1
@@ -129,8 +129,11 @@ static int tipc_udp_addr2str(struct tipc_media_addr *a, char *buf, int size)snprintf (buf, size,"%pI4:%u" , &ua->ipv4,ntohs (ua->port)); else if (ntohs(ua->proto) == ETH_P_IPV6) snprintf(buf, size, "%pI6:%u", &ua->ipv6, ntohs(ua->port)); - else + else {pr_err ("Invalid UDP media address\n" ); +return 1 ; + } +return 0 ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 200/352 net: stmmac: Correct byte order of perfect_match
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Horman <[email protected]>
[ Upstream commit e9dbebae2e3c338122716914fe105458f41e3a4a ]
The perfect_match parameter of the update_vlan_hash operation is __le16, and is correctly converted from host byte-order in the lone caller, stmmac_vlan_update().
However, the implementations of this caller, dwxgmac2_update_vlan_hash() and dwxgmac2_update_vlan_hash(), both treat this parameter as host byte order, using the following pattern:
u32 value = ... ... writel(value | perfect_match, ...);
This is not correct because both:
1) value is host byte order; and
2) writel expects a host byte order value as it's first argument
I believe that this will break on big endian systems. And I expect it has gone unnoticed by only being exercised on little endian systems.
The approach taken by this patch is to update the callback, and it's caller to simply use a host byte order value.
Flagged by Sparse.
Compile tested only.
--- drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +- drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +- drivers/net/ethernet/stmicro/stmmac/hwif.h | 2 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +1 -1
@@ -938,7 +938,7 @@ static void dwmac4_set_mac_loopback(void __iomem *ioaddr, bool enable) }static void dwmac4_update_vlan_hash (struct mac_device_info *hw,u32 hash, -__le16 perfect_match,bool is_double) +u16 perfect_match,bool is_double) {void __iomem *ioaddr = hw->pcsr;u32 value;
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c +1 -1
@@ -581,7 +581,7 @@ static int dwxgmac2_rss_configure(struct mac_device_info *hw, }static void dwxgmac2_update_vlan_hash (struct mac_device_info *hw,u32 hash, -__le16 perfect_match,bool is_double) +u16 perfect_match,bool is_double) {void __iomem *ioaddr = hw->pcsr;
drivers/net/ethernet/stmicro/stmmac/hwif.h +1 -1
@@ -368,7 +368,7 @@ struct stmmac_ops { struct stmmac_rss *cfg, u32 num_rxq);/* VLAN */ void (*update_vlan_hash)(struct mac_device_info *hw,u32 hash, -__le16 perfect_match,bool is_double); +u16 perfect_match,bool is_double);void (*enable_vlan)(struct mac_device_info *hw,u32 type); int (*add_hw_vlan_rx_fltr)(struct net_device *dev, struct mac_device_info *hw,
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +2 -2
@@ -4660,7 +4660,7 @@ static u32 stmmac_vid_crc32_le(__le16 vid_le)static int stmmac_vlan_update (struct stmmac_priv *priv,bool is_double) {u32 crc, hash =0 ; -__le16 pmatch =0 ; +u16 pmatch =0 ;int count =0 ;u16 vid =0 ;
@@ -4675,7 +4675,7 @@ static int stmmac_vlan_update(struct stmmac_priv *priv, bool is_double)if (count >2 )/* VID = 0 always passes filter */ return -EOPNOTSUPP ; - pmatch =cpu_to_le16 (vid); + pmatch = vid; hash =0 ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 201/352 net: nexthop: Initialize all fields in dumped nexthops
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Petr Machata <[email protected]>
[ Upstream commit 6d745cd0e9720282cd291d36b9db528aea18add2 ]
struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity):
# ip nexthop add id 1 dev lo
# ip nexthop add id 101 group 1
# strace -e recvmsg ip nexthop get id 101
...
recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
[{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.
--- net/ipv4/nexthop.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/ipv4/nexthop.c +4 -3
@@ -210,9 +210,10 @@ static int nla_put_nh_group(struct sk_buff *skb, struct nh_group *nhg) p =nla_data (nla);for (i =0 ; i < nhg->num_nh; ++i) { - p->id = nhg->nh_entries[i].nh->id; - p->weight = nhg->nh_entries[i].weight -1 ; - p +=1 ; + *p++ = (struct nexthop_grp ) { + .id = nhg->nh_entries[i].nh->id, + .weight = nhg->nh_entries[i].weight -1 , + }; }return 0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 202/352 bpf: Fix a segment issue when downgrading gso_size
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fred Li <[email protected]>
[ Upstream commit fa5ef655615a01533035c6139248c5b33aa27028 ]
Linearize the skb when downgrading gso_size because it may trigger a BUG_ON() later when the skb is segmented as described in [1,2].
--- net/core/filter.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
net/core/filter.c +11 -4
@@ -3535,13 +3535,20 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32 off, u32 len_diff,if (skb_is_gso (skb)) {struct skb_shared_info *shinfo =skb_shinfo (skb); -/* Due to header grow, MSS needs to be downgraded. */ -if (!(flags &BPF_F_ADJ_ROOM_FIXED_GSO )) -skb_decrease_gso_size (shinfo, len_diff); -/* Header must be checked, and gso_segs recomputed. */ shinfo->gso_type |= gso_type; shinfo->gso_segs =0 ; + +/* Due to header growth, MSS needs to be downgraded. +* There is a BUG_ON() when segmenting the frag_list with +* head_frag true, so linearize the skb after downgrading +* the MSS. +*/ +if (!(flags &BPF_F_ADJ_ROOM_FIXED_GSO )) { +skb_decrease_gso_size (shinfo, len_diff); +if (shinfo->frag_list) +return skb_linearize (skb); + } }return 0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 203/352 mISDN: Fix a use after free in hfcmulti_tx()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 61ab751451f5ebd0b98e02276a44e23a10110402 ]
Don't dereference *sp after calling dev_kfree_skb(*sp).
--- drivers/isdn/hardware/mISDN/hfcmulti.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/isdn/hardware/mISDN/hfcmulti.c +4 -3
@@ -1931,7 +1931,7 @@ hfcmulti_dtmf(struct hfc_multi *hc)static void hfcmulti_tx (struct hfc_multi *hc,int ch) { -int i, ii, temp, len =0 ; +int i, ii, temp, tmp_len, len =0 ;int Zspace, z1, z2;/* must be int for calculation */ int Fspace, f1, f2;u_char *d;
@@ -2152,14 +2152,15 @@ hfcmulti_tx(struct hfc_multi *hc, int ch)HFC_wait_nodebug (hc); } + tmp_len = (*sp)->len;dev_kfree_skb (*sp);/* check for next frame */ if (bch &&get_next_bframe (bch)) { - len = (*sp)->len; + len = tmp_len; goto next_frame; }if (dch &&get_next_dframe (dch)) { - len = (*sp)->len; + len = tmp_len; goto next_frame; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 204/352 apparmor: Fix null pointer deref when receiving skb during sock creation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiao Liang <[email protected]>
[ Upstream commit fce09ea314505a52f2436397608fa0a5d0934fb1 ]
The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set.
BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
<IRQ>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? aa_label_next_confined+0xb/0x40
apparmor_secmark_check+0xec/0x330
security_sock_rcv_skb+0x35/0x50
sk_filter_trim_cap+0x47/0x250
sock_queue_rcv_skb_reason+0x20/0x60
raw_rcv+0x13c/0x210
raw_local_deliver+0x1f3/0x250
ip_protocol_deliver_rcu+0x4f/0x2f0
ip_local_deliver_finish+0x76/0xa0
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x119/0x170
? __netdev_alloc_skb+0x3d/0x140
vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
__napi_poll+0x28/0x1b0
net_rx_action+0x2a4/0x380
__do_softirq+0xd1/0x2c8
__irq_exit_rcu+0xbb/0xf0
common_interrupt+0x86/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x26/0x40
RIP: 0010:apparmor_socket_post_create+0xb/0x200
Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
? __pfx_apparmor_socket_post_create+0x10/0x10
security_socket_post_create+0x4b/0x80
__sock_create+0x176/0x1f0
__sys_socket+0x89/0x100
__x64_sys_socket+0x17/0x20
do_syscall_64+0x5d/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc--- security/apparmor/lsm.c | 7 +++++++ 1 file changed, 7 insertions(+)
security/apparmor/lsm.c +7 -0
@@ -1048,6 +1048,13 @@ static int apparmor_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)if (!skb->secmark)return 0 ; +/* +* If reach here before socket_post_create hook is called, in which +* case label is null, drop the packet. +*/ +if (!ctx->label) +return -EACCES ; +return apparmor_secmark_check (ctx->label,OP_RECVMSG ,AA_MAY_RECEIVE , skb->secmark, sk); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 205/352 powerpc: fix a file leak in kvm_vcpu_ioctl_enable_cap()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
[ Upstream commit b4cf5fc01ce83e5c0bcf3dbb9f929428646b9098 ]
missing fdput() on one of the failure exits
--- arch/powerpc/kvm/powerpc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/powerpc/kvm/powerpc.c +3 -1
@@ -1956,8 +1956,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,break ; r = -ENXIO ; -if (!xive_enabled ()) +if (!xive_enabled ()) { +fdput (f);break ; + } r = -EPERM ; dev =kvm_device_from_filp (f.file);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 206/352 lirc: rc_dev_get_from_fd(): fix file leak
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
[ Upstream commit bba1f6758a9ec90c1adac5dcf78f8a15f1bad65b ]
missing fdput() on a failure exit
--- drivers/media/rc/lirc_dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/media/rc/lirc_dev.c +3 -1
@@ -840,8 +840,10 @@ struct rc_dev *rc_dev_get_from_fd(int fd, bool write)return ERR_PTR (-EINVAL ); } -if (write && !(f.file->f_mode &FMODE_WRITE )) +if (write && !(f.file->f_mode &FMODE_WRITE )) { +fdput (f);return ERR_PTR (-EPERM ); + } fh = f.file->private_data; dev = fh->rc;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 207/352 ASoC: Intel: use soc_intel_is_byt_cr() only when IOSF_MBI is reachable
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pierre-Louis Bossart <[email protected]>
[ Upstream commit 9931f7d5d251882a147cc5811060097df43e79f5 ]
the Intel kbuild bot reports a link failure when IOSF_MBI is built-in but the Merrifield driver is configured as a module. The soc-intel-quirks.h is included for Merrifield platforms, but IOSF_MBI is not selected for that platform.
ld.lld: error: undefined symbol: iosf_mbi_read
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
referenced by
atom.c
sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a
This patch forces the use of the fallback static inline when IOSF_MBI is not reachable.
--- sound/soc/intel/common/soc-intel-quirks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/intel/common/soc-intel-quirks.h +1 -1
@@ -11,7 +11,7 @@#include <linux/platform_data/x86/soc.h> -#if IS_ENABLED (CONFIG_X86 ) +#if IS_REACHABLE (CONFIG_IOSF_MBI )#include <linux/dmi.h> #include <asm/iosf_mbi.h>
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 208/352 ceph: fix incorrect kmalloc size of pagevec mempool
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: ethanwu <[email protected]>
[ Upstream commit 03230edb0bd831662a7c08b6fef66b2a9a817774 ]
The kmalloc size of pagevec mempool is incorrectly calculated.
It misses the size of page pointer and only accounts the number for the array.
--- fs/ceph/super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ceph/super.c +2 -1
@@ -783,7 +783,8 @@ static int __init init_caches(void)if (!ceph_mds_request_cachep) goto bad_mds_req; - ceph_wb_pagevec_pool =mempool_create_kmalloc_pool (10 ,CEPH_MAX_WRITE_SIZE >>PAGE_SHIFT ); + ceph_wb_pagevec_pool =mempool_create_kmalloc_pool (10 , + (CEPH_MAX_WRITE_SIZE >>PAGE_SHIFT ) *sizeof (struct page *));if (!ceph_wb_pagevec_pool) goto bad_pagevec_pool;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 209/352 s390/pci: Do not mask MSI[-X] entries on teardown
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
[ Upstream commit 3998527d2e3ee2bfdf710a45b7b90968ff87babc ]
The PCI core already ensures that the MSI[-X] state is correct when MSI[-X] is disabled. For MSI the reset state is all entries unmasked and for MSI-X all vectors are masked.
S390 masks all MSI entries and masks the already masked MSI-X entries again. Remove it and let the device in the correct state.
Stable-dep-of: ab42fcb511fd ("s390/pci: Allow allocation of more than 1 MSI interrupt")
--- arch/s390/pci/pci_irq.c | 4 ---- drivers/pci/msi.c | 4 ++-- include/linux/msi.h | 2 -- 3 files changed, 2 insertions(+), 8 deletions(-)
arch/s390/pci/pci_irq.c +0 -4
@@ -341,10 +341,6 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev)for_each_pci_msi_entry (msi, pdev) {if (!msi->irq)continue ; -if (msi->msi_attrib.is_msix) -__pci_msix_desc_mask_irq (msi,1 ); -else -__pci_msi_desc_mask_irq (msi,1 ,1 );irq_set_msi_desc (msi->irq,NULL );irq_free_desc (msi->irq); msi->msg.address_lo =0 ;
drivers/pci/msi.c +2 -2
@@ -171,7 +171,7 @@ static inline __attribute_const__ u32 msi_mask(unsigned x)* reliably as devices without an INTx disable bit will then generate a * level IRQ which will never be cleared. */ -void __pci_msi_desc_mask_irq (struct msi_desc *desc,u32 mask,u32 flag) +static void __pci_msi_desc_mask_irq (struct msi_desc *desc,u32 mask,u32 flag) {raw_spinlock_t *lock = &desc->dev->msi_lock;unsigned long flags;
@@ -208,7 +208,7 @@ static void __iomem *pci_msix_desc_addr(struct msi_desc *desc)* file. This saves a few milliseconds when initialising devices with lots * of MSI-X interrupts. */ -u32 __pci_msix_desc_mask_irq (struct msi_desc *desc,u32 flag) +static u32 __pci_msix_desc_mask_irq (struct msi_desc *desc,u32 flag) {u32 mask_bits = desc->masked;void __iomem *desc_addr;
include/linux/msi.h +0 -2
@@ -193,8 +193,6 @@ void free_msi_entry(struct msi_desc *entry);void __pci_read_msi_msg (struct msi_desc *entry,struct msi_msg *msg);void __pci_write_msi_msg (struct msi_desc *entry,struct msi_msg *msg); -u32 __pci_msix_desc_mask_irq (struct msi_desc *desc,u32 flag); -void __pci_msi_desc_mask_irq (struct msi_desc *desc,u32 mask,u32 flag);void pci_msi_mask_irq (struct irq_data *data);void pci_msi_unmask_irq (struct irq_data *data);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 210/352 s390/pci: Rework MSI descriptor walk
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
[ Upstream commit 2ca5e908d0f4cde61d9d3595e8314adca5d914a1 ]
Replace the about to vanish iterators and make use of the filtering.
Stable-dep-of: ab42fcb511fd ("s390/pci: Allow allocation of more than 1 MSI interrupt")
--- arch/s390/pci/pci_irq.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
arch/s390/pci/pci_irq.c +2 -4
@@ -273,7 +273,7 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)/* Request MSI interrupts */ hwirq = bit; -for_each_pci_msi_entry (msi, pdev) { +msi_for_each_desc (msi, &pdev->dev,MSI_DESC_NOTASSOCIATED ) { rc = -EIO ;if (hwirq - bit >= msi_vecs)break ;
@@ -338,9 +338,7 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev)return ;/* Release MSI interrupts */ -for_each_pci_msi_entry (msi, pdev) { -if (!msi->irq) -continue ; +msi_for_each_desc (msi, &pdev->dev,MSI_DESC_ASSOCIATED ) {irq_set_msi_desc (msi->irq,NULL );irq_free_desc (msi->irq); msi->msg.address_lo =0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 211/352 s390/pci: Refactor arch_setup_msi_irqs()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gerd Bayer <[email protected]>
[ Upstream commit 5fd11b96b43708f2f6e3964412c301c1bd20ec0f ]
Factor out adapter interrupt allocation from arch_setup_msi_irqs() in preparation for enabling registration of multiple MSIs. Code movement only, no change of functionality intended.
Stable-dep-of: ab42fcb511fd ("s390/pci: Allow allocation of more than 1 MSI interrupt")
--- arch/s390/pci/pci_irq.c | 54 ++++++++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 22 deletions(-)
arch/s390/pci/pci_irq.c +32 -22
@@ -232,33 +232,20 @@ static void zpci_floating_irq_handler(struct airq_struct *airq, bool floating) } } -int arch_setup_msi_irqs (struct pci_dev *pdev,int nvec,int type) +static int __alloc_airq (struct zpci_dev *zdev,int msi_vecs, +unsigned long *bit) { -struct zpci_dev *zdev =to_zpci (pdev); -unsigned int hwirq, msi_vecs, cpu; -unsigned long bit; -struct msi_desc *msi; -struct msi_msg msg; -int cpu_addr; -int rc, irq; - - zdev->aisb =-1UL ; - zdev->msi_first_bit =-1U ; -if (type ==PCI_CAP_ID_MSI && nvec >1 ) -return 1 ; - msi_vecs = min_t(unsigned int, nvec, zdev->max_msi); -if (irq_delivery ==DIRECTED ) {/* Allocate cpu vector bits */ - bit =airq_iv_alloc (zpci_ibv[0 ], msi_vecs); -if (bit ==-1UL ) + *bit =airq_iv_alloc (zpci_ibv[0 ], msi_vecs); +if (*bit ==-1UL )return -EIO ; }else {/* Allocate adapter summary indicator bit */ - bit =airq_iv_alloc_bit (zpci_sbv); -if (bit ==-1UL ) + *bit =airq_iv_alloc_bit (zpci_sbv); +if (*bit ==-1UL )return -EIO ; - zdev->aisb = bit; + zdev->aisb = *bit;/* Create adapter interrupt vector */ zdev->aibv =airq_iv_create (msi_vecs,AIRQ_IV_DATA |AIRQ_IV_BITLOCK );
@@ -266,10 +253,33 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)return -ENOMEM ;/* Wire up shortcut pointer */ - zpci_ibv[bit] = zdev->aibv; + zpci_ibv[*bit] = zdev->aibv;/* Each function has its own interrupt vector */ - bit =0 ; + *bit =0 ; } +return 0 ; +} + +int arch_setup_msi_irqs (struct pci_dev *pdev,int nvec,int type) +{ +struct zpci_dev *zdev =to_zpci (pdev); +unsigned int hwirq, msi_vecs, cpu; +struct msi_desc *msi; +struct msi_msg msg; +unsigned long bit; +int cpu_addr; +int rc, irq; + + zdev->aisb =-1UL ; + zdev->msi_first_bit =-1U ; + +if (type ==PCI_CAP_ID_MSI && nvec >1 ) +return 1 ; + msi_vecs = min_t(unsigned int, nvec, zdev->max_msi); + + rc =__alloc_airq (zdev, msi_vecs, &bit); +if (rc <0 ) +return rc;/* Request MSI interrupts */ hwirq = bit;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 212/352 s390/pci: Allow allocation of more than 1 MSI interrupt
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gerd Bayer <[email protected]>
[ Upstream commit ab42fcb511fd9d241bbab7cc3ca04e34e9fc0666 ]
On a PCI adapter that provides up to 8 MSI interrupt sources the s390 implementation of PCI interrupts rejected to accommodate them, although the underlying hardware is able to support that.
For MSI-X it is sufficient to allocate a single irq_desc per msi_desc, but for MSI multiple irq descriptors are attached to and controlled by a single msi descriptor. Add the appropriate loops to maintain multiple irq descriptors and tie/untie them to/from the appropriate AIBV bit, if a device driver allocates more than 1 MSI interrupt.
Common PCI code passes on requests to allocate a number of interrupt vectors based on the device drivers' demand and the PCI functions' capabilities. However, the root-complex of s390 systems support just a limited number of interrupt vectors per PCI function. Produce a kernel log message to inform about any architecture-specific capping that might be done.
With this change, we had a PCI adapter successfully raising interrupts to its device driver via all 8 sources.
--- arch/s390/pci/pci_irq.c | 62 ++++++++++++++++++++++++++++------------- 1 file changed, 42 insertions(+), 20 deletions(-)
arch/s390/pci/pci_irq.c +42 -20
@@ -262,8 +262,8 @@ static int __alloc_airq(struct zpci_dev *zdev, int msi_vecs,int arch_setup_msi_irqs (struct pci_dev *pdev,int nvec,int type) { +unsigned int hwirq, msi_vecs, irqs_per_msi, i, cpu;struct zpci_dev *zdev =to_zpci (pdev); -unsigned int hwirq, msi_vecs, cpu;struct msi_desc *msi;struct msi_msg msg;unsigned long bit;
@@ -273,30 +273,46 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type) zdev->aisb =-1UL ; zdev->msi_first_bit =-1U ; -if (type ==PCI_CAP_ID_MSI && nvec >1 ) -return 1 ; msi_vecs = min_t(unsigned int, nvec, zdev->max_msi); +if (msi_vecs < nvec) { +pr_info ("%s requested %d irqs, allocate system limit of %d" , +pci_name (pdev), nvec, zdev->max_msi); + } rc =__alloc_airq (zdev, msi_vecs, &bit);if (rc <0 )return rc; -/* Request MSI interrupts */ +/* +* Request MSI interrupts: +* When using MSI, nvec_used interrupt sources and their irq +* descriptors are controlled through one msi descriptor. +* Thus the outer loop over msi descriptors shall run only once, +* while two inner loops iterate over the interrupt vectors. +* When using MSI-X, each interrupt vector/irq descriptor +* is bound to exactly one msi descriptor (nvec_used is one). +* So the inner loops are executed once, while the outer iterates +* over the MSI-X descriptors. +*/ hwirq = bit;msi_for_each_desc (msi, &pdev->dev,MSI_DESC_NOTASSOCIATED ) { - rc = -EIO ;if (hwirq - bit >= msi_vecs)break ; - irq =__irq_alloc_descs (-1 ,0 ,1 ,0 ,THIS_MODULE , - (irq_delivery ==DIRECTED ) ? - msi->affinity :NULL ); + irqs_per_msi = min_t(unsigned int, msi_vecs, msi->nvec_used); + irq =__irq_alloc_descs (-1 ,0 , irqs_per_msi,0 ,THIS_MODULE , + (irq_delivery ==DIRECTED ) ? + msi->affinity :NULL );if (irq <0 )return -ENOMEM ; - rc =irq_set_msi_desc (irq, msi); -if (rc) -return rc; -irq_set_chip_and_handler (irq, &zpci_irq_chip, - handle_percpu_irq); + +for (i =0 ; i < irqs_per_msi; i++) { + rc =irq_set_msi_desc_off (irq, i, msi); +if (rc) +return rc; +irq_set_chip_and_handler (irq + i, &zpci_irq_chip, + handle_percpu_irq); + } + msg.data = hwirq - bit;if (irq_delivery ==DIRECTED ) {if (msi->affinity)
@@ -309,19 +325,22 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type) msg.address_lo |= (cpu_addr <<8 );for_each_possible_cpu (cpu) { -airq_iv_set_data (zpci_ibv[cpu], hwirq, irq); +for (i =0 ; i < irqs_per_msi; i++) +airq_iv_set_data (zpci_ibv[cpu], + hwirq + i, irq + i); } }else { msg.address_lo = zdev->msi_addr &0xffffffff ; -airq_iv_set_data (zdev->aibv, hwirq, irq); +for (i =0 ; i < irqs_per_msi; i++) +airq_iv_set_data (zdev->aibv, hwirq + i, irq + i); } msg.address_hi = zdev->msi_addr >>32 ;pci_write_msi_msg (irq, &msg); - hwirq++; + hwirq += irqs_per_msi; } zdev->msi_first_bit = bit; - zdev->msi_nr_irqs = msi_vecs; + zdev->msi_nr_irqs = hwirq - bit;if (irq_delivery ==DIRECTED ) rc =zpci_set_directed_irq (zdev);
@@ -330,13 +349,14 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)if (rc)return rc; -return (msi_vecs == nvec) ?0 : msi_vecs; +return (zdev->msi_nr_irqs == nvec) ?0 : zdev->msi_nr_irqs; }void arch_teardown_msi_irqs (struct pci_dev *pdev) {struct zpci_dev *zdev =to_zpci (pdev);struct msi_desc *msi; +unsigned int i;int rc;/* Disable interrupts */
@@ -349,8 +369,10 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev)/* Release MSI interrupts */ msi_for_each_desc (msi, &pdev->dev,MSI_DESC_ASSOCIATED ) { -irq_set_msi_desc (msi->irq,NULL ); -irq_free_desc (msi->irq); +for (i =0 ; i < msi->nvec_used; i++) { +irq_set_msi_desc (msi->irq + i,NULL ); +irq_free_desc (msi->irq + i); + } msi->msg.address_lo =0 ; msi->msg.address_hi =0 ; msi->msg.data =0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 213/352 nvme: split command copy into a helper
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
[ Upstream commit 3233b94cf842984ea7e208d5be1ad2f2af02d495 ]
We'll need it for batched submit as well. Since we now have a copy helper, get rid of the nvme_submit_cmd() wrapper.
Stable-dep-of: c31fad147038 ("nvme-pci: add missing condition check for existence of mapped data")
--- drivers/nvme/host/pci.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-)
drivers/nvme/host/pci.c +12 -14
@@ -486,22 +486,13 @@ static inline void nvme_write_sq_db(struct nvme_queue *nvmeq, bool write_sq) nvmeq->last_sq_tail = nvmeq->sq_tail; } -/** -* nvme_submit_cmd() - Copy a command into a queue and ring the doorbell -* @nvmeq: The queue to use -* @cmd: The command to send -* @write_sq: whether to write to the SQ doorbell -*/ -static void nvme_submit_cmd (struct nvme_queue *nvmeq,struct nvme_command *cmd, -bool write_sq) +static inline void nvme_sq_copy_cmd (struct nvme_queue *nvmeq, +struct nvme_command *cmd) { -spin_lock (&nvmeq->sq_lock);memcpy (nvmeq->sq_cmds + (nvmeq->sq_tail << nvmeq->sqes), - cmd,sizeof (*cmd)); +absolute_pointer (cmd),sizeof (*cmd));if (++nvmeq->sq_tail == nvmeq->q_depth) nvmeq->sq_tail =0 ; -nvme_write_sq_db (nvmeq, write_sq); -spin_unlock (&nvmeq->sq_lock); }static void nvme_commit_rqs (struct blk_mq_hw_ctx *hctx)
@@ -945,7 +936,10 @@ static blk_status_t nvme_queue_rq(struct blk_mq_hw_ctx *hctx, }blk_mq_start_request (req); -nvme_submit_cmd (nvmeq, cmnd, bd->last); +spin_lock (&nvmeq->sq_lock); +nvme_sq_copy_cmd (nvmeq, &iod->cmd); +nvme_write_sq_db (nvmeq, bd->last); +spin_unlock (&nvmeq->sq_lock);return BLK_STS_OK ; out_unmap_data:nvme_unmap_data (dev, req);
@@ -1120,7 +1114,11 @@ static void nvme_pci_submit_async_event(struct nvme_ctrl *ctrl)memset (&c,0 ,sizeof (c)); c.common.opcode = nvme_admin_async_event; c.common.command_id =NVME_AQ_BLK_MQ_DEPTH ; -nvme_submit_cmd (nvmeq, &c, true); + +spin_lock (&nvmeq->sq_lock); +nvme_sq_copy_cmd (nvmeq, &c); +nvme_write_sq_db (nvmeq, true); +spin_unlock (&nvmeq->sq_lock); }static int adapter_delete_queue (struct nvme_dev *dev,u8 opcode,u16 id)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 214/352 nvme-pci: add missing condition check for existence of mapped data
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leon Romanovsky <[email protected]>
[ Upstream commit c31fad1470389666ac7169fe43aa65bf5b7e2cfd ]
nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference.
--- drivers/nvme/host/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/nvme/host/pci.c +2 -1
@@ -942,7 +942,8 @@ static blk_status_t nvme_queue_rq(struct blk_mq_hw_ctx *hctx,spin_unlock (&nvmeq->sq_lock);return BLK_STS_OK ; out_unmap_data: -nvme_unmap_data (dev, req); +if (blk_rq_nr_phys_segments (req)) +nvme_unmap_data (dev, req); out_free_cmd:nvme_cleanup_cmd (req);return ret;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 215/352 fs: dont allow non-init s_user_ns for filesystems without FS_USERNS_MOUNT
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Seth Forshee (DigitalOcean) <[email protected]>
[ Upstream commit e1c5ae59c0f22f7fe5c07fb5513a29e4aad868c9 ]
Christian noticed that it is possible for a privileged user to mount most filesystems with a non-initial user namespace in sb->s_user_ns. When fsopen() is called in a non-init namespace the caller's namespace is recorded in fs_context->user_ns. If the returned file descriptor is then passed to a process priviliged in init_user_ns, that process can call fsconfig(fd_fs, FSCONFIG_CMD_CREATE), creating a new superblock with sb->s_user_ns set to the namespace of the process which called fsopen().
This is problematic. We cannot assume that any filesystem which does not set FS_USERNS_MOUNT has been written with a non-initial s_user_ns in mind, increasing the risk for bugs and security issues.
Prevent this by returning EPERM from sget_fc() when FS_USERNS_MOUNT is not set for the filesystem and a non-initial user namespace will be used. sget() does not need to be updated as it always uses the user namespace of the current context, or the initial user namespace if SB_SUBMOUNT is set.
--- fs/super.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
fs/super.c +11 -0
@@ -518,6 +518,17 @@ struct super_block *sget_fc(struct fs_context *fc,struct user_namespace *user_ns = fc->global ? &init_user_ns : fc->user_ns;int err; +/* +* Never allow s_user_ns != &init_user_ns when FS_USERNS_MOUNT is +* not set, as the filesystem is likely unprepared to handle it. +* This can happen when fsconfig() is called from init_user_ns with +* an fs_fd opened in another user namespace. +*/ +if (user_ns != &init_user_ns && !(fc->fs_type->fs_flags &FS_USERNS_MOUNT )) { +errorfc (fc,"VFS: Mounting from non-initial user namespace is not allowed" ); +return ERR_PTR (-EPERM ); + } + retry:spin_lock (&sb_lock);if (test) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 216/352 powerpc/configs: Update defconfig with now user-visible CONFIG_FSL_IFC
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Esben Haabendal <[email protected]>
commit 45547a0a93d85f704b49788cde2e1d9ab9cd363b upstream.
With CONFIG_FSL_IFC now being user-visible, and thus changed from a select to depends in CONFIG_MTD_NAND_FSL_IFC, the dependencies needs to be selected in defconfigs.
Depends-on: 9ba0cae3cac0 ("memory: fsl_ifc: Make FSL_IFC config visible and selectable")
--- arch/powerpc/configs/85xx-hw.config | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/configs/85xx-hw.config +2 -0
@@ -24,6 +24,7 @@ CONFIG_FS_ENET=y CONFIG_FSL_CORENET_CF=y CONFIG_FSL_DMA=y CONFIG_FSL_HV_MANAGER=y +CONFIG_FSL_IFC=y CONFIG_FSL_PQ_MDIO=y CONFIG_FSL_RIO=y CONFIG_FSL_XGMAC_MDIO=y
@@ -58,6 +59,7 @@ CONFIG_INPUT_FF_MEMLESS=m CONFIG_MARVELL_PHY=y CONFIG_MDIO_BUS_MUX_GPIO=y CONFIG_MDIO_BUS_MUX_MMIOREG=y +CONFIG_MEMORY=y CONFIG_MMC_SDHCI_OF_ESDHC=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI=y
Greg Kroah-Hartman
maintainerPATCH 217/352 fuse: name fs_context consistently
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <[email protected]>
[ Upstream commit 84c215075b5723ab946708a6c74c26bd3c51114c ]
Naming convention under fs/fuse/:
struct fuse_conn *fc; struct fs_context *fsc;
Stable-dep-of: 525bd65aa759 ("fuse: verify {g,u}id mount options correctly")
--- fs/fuse/control.c | 10 ++++---- fs/fuse/inode.c | 60 ++++++++++++++++++++++----------------------- fs/fuse/virtio_fs.c | 12 ++++----- 3 files changed, 41 insertions(+), 41 deletions(-)
fs/fuse/control.c +5 -5
@@ -328,7 +328,7 @@ void fuse_ctl_remove_conn(struct fuse_conn *fc)drop_nlink (d_inode (fuse_control_sb->s_root)); } -static int fuse_ctl_fill_super (struct super_block *sb,struct fs_context *fctx) +static int fuse_ctl_fill_super (struct super_block *sb,struct fs_context *fsc) {static const struct tree_descr empty_descr = {"" };struct fuse_conn *fc;
@@ -354,18 +354,18 @@ static int fuse_ctl_fill_super(struct super_block *sb, struct fs_context *fctx)return 0 ; } -static int fuse_ctl_get_tree (struct fs_context *fc) +static int fuse_ctl_get_tree (struct fs_context *fsc) { -return get_tree_single (fc, fuse_ctl_fill_super); +return get_tree_single (fsc, fuse_ctl_fill_super); }static const struct fs_context_operations fuse_ctl_context_ops = { .get_tree = fuse_ctl_get_tree, }; -static int fuse_ctl_init_fs_context (struct fs_context *fc) +static int fuse_ctl_init_fs_context (struct fs_context *fsc) { - fc->ops = &fuse_ctl_context_ops; + fsc->ops = &fuse_ctl_context_ops;return 0 ; }
fs/fuse/inode.c +30 -30
162 lines not on this page · raw message
fs/fuse/virtio_fs.c +6 -6
@@ -97,14 +97,14 @@ static const struct fs_parameter_spec virtio_fs_parameters[] = { {} }; -static int virtio_fs_parse_param (struct fs_context *fc, +static int virtio_fs_parse_param (struct fs_context *fsc,struct fs_parameter *param) {struct fs_parse_result result; -struct fuse_fs_context *ctx = fc->fs_private; +struct fuse_fs_context *ctx = fsc->fs_private;int opt; - opt =fs_parse (fc, virtio_fs_parameters, param, &result); + opt =fs_parse (fsc, virtio_fs_parameters, param, &result);if (opt <0 )return opt;
@@ -119,9 +119,9 @@ static int virtio_fs_parse_param(struct fs_context *fc,return 0 ; } -static void virtio_fs_free_fc (struct fs_context *fc) +static void virtio_fs_free_fsc (struct fs_context *fsc) { -struct fuse_fs_context *ctx = fc->fs_private; +struct fuse_fs_context *ctx = fsc->fs_private;kfree (ctx); }
@@ -1500,7 +1500,7 @@ static int virtio_fs_get_tree(struct fs_context *fsc) }static const struct fs_context_operations virtio_fs_context_ops = { - .free = virtio_fs_free_fc, + .free = virtio_fs_free_fsc, .parse_param = virtio_fs_parse_param, .get_tree = virtio_fs_get_tree, };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 218/352 fuse: verify {g,u}id mount options correctly
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Sandeen <[email protected]>
[ Upstream commit 525bd65aa759ec320af1dc06e114ed69733e9e23 ]
As was done in0200679fc795 ("tmpfs: verify {g,u}id mount options correctly") we need to validate that the requested uid and/or gid is representable in the filesystem's idmapping.
Cribbing from the above commit log,
The contract for {g,u}id mount options and {g,u}id values in general set from userspace has always been that they are translated according to the caller's idmapping. In so far, fuse has been doing the correct thing. But since fuse is mountable in unprivileged contexts it is also necessary to verify that the resulting {k,g}uid is representable in the namespace of the superblock.
--- fs/fuse/inode.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)
fs/fuse/inode.c +20 -4
@@ -540,6 +540,8 @@ static int fuse_parse_param(struct fs_context *fsc, struct fs_parameter *param)struct fs_parse_result result;struct fuse_fs_context *ctx = fsc->fs_private;int opt; +kuid_t kuid; +kgid_t kgid;if (fsc->purpose ==FS_CONTEXT_FOR_RECONFIGURE ) {/*
@@ -584,16 +586,30 @@ static int fuse_parse_param(struct fs_context *fsc, struct fs_parameter *param)break ;case OPT_USER_ID : - ctx->user_id =make_kuid (fsc->user_ns, result.uint_32); -if (!uid_valid (ctx->user_id)) + kuid =make_kuid (fsc->user_ns, result.uint_32); +if (!uid_valid (kuid))return invalfc (fsc,"Invalid user_id" ); +/* +* The requested uid must be representable in the +* filesystem's idmapping. +*/ +if (!kuid_has_mapping (fsc->user_ns, kuid)) +return invalfc (fsc,"Invalid user_id" ); + ctx->user_id = kuid; ctx->user_id_present = true;break ;case OPT_GROUP_ID : - ctx->group_id =make_kgid (fsc->user_ns, result.uint_32); -if (!gid_valid (ctx->group_id)) + kgid =make_kgid (fsc->user_ns, result.uint_32);; +if (!gid_valid (kgid)) +return invalfc (fsc,"Invalid group_id" ); +/* +* The requested gid must be representable in the +* filesystem's idmapping. +*/ +if (!kgid_has_mapping (fsc->user_ns, kgid))return invalfc (fsc,"Invalid group_id" ); + ctx->group_id = kgid; ctx->group_id_present = true;break ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 219/352 sysctl: always initialize i_uid/i_gid
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weißschuh <[email protected]>
[ Upstream commit 98ca62ba9e2be5863c7d069f84f7166b45a5b2f4 ]
Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them.
Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed.
--- fs/proc/proc_sysctl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
fs/proc/proc_sysctl.c +2 -4
@@ -471,12 +471,10 @@ static struct inode *proc_sys_make_inodemake_empty_dir_inode (inode); } + inode->i_uid =GLOBAL_ROOT_UID ; + inode->i_gid =GLOBAL_ROOT_GID ;if (root->set_ownership) root->set_ownership (head, table, &inode->i_uid, &inode->i_gid); -else { - inode->i_uid =GLOBAL_ROOT_UID ; - inode->i_gid =GLOBAL_ROOT_GID ; - }return inode; }
Greg Kroah-Hartman
maintainerPATCH 220/352 ext4: factor out a common helper to query extent map
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Yi <[email protected]>
[ Upstream commit 8e4e5cdf2fdeb99445a468b6b6436ad79b9ecb30 ]
Factor out a new common helper ext4_map_query_blocks() from the ext4_da_map_blocks(), it query and return the extent map status on the inode's extent path, no logic changes.
Stable-dep-of: 0ea6560abb3b ("ext4: check the extent status again before inserting delalloc block")
--- fs/ext4/inode.c | 57 +++++++++++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 25 deletions(-)
fs/ext4/inode.c +32 -25
@@ -484,6 +484,35 @@ static void ext4_map_blocks_es_recheck(handle_t *handle, }#endif /* ES_AGGRESSIVE_TEST */ +static int ext4_map_query_blocks (handle_t *handle,struct inode *inode, +struct ext4_map_blocks *map) +{ +unsigned int status; +int retval; + +if (ext4_test_inode_flag (inode,EXT4_INODE_EXTENTS )) + retval =ext4_ext_map_blocks (handle, inode, map,0 ); +else + retval =ext4_ind_map_blocks (handle, inode, map,0 ); + +if (retval <=0 ) +return retval; + +if (unlikely (retval != map->m_len)) { +ext4_warning (inode->i_sb, +"ES len assertion failed for inode " +"%lu: retval %d != map->m_len %d" , + inode->i_ino, retval, map->m_len); +WARN_ON (1 ); + } + + status = map->m_flags &EXT4_MAP_UNWRITTEN ? +EXTENT_STATUS_UNWRITTEN :EXTENT_STATUS_WRITTEN ; +ext4_es_insert_extent (inode, map->m_lblk, map->m_len, + map->m_pblk, status); +return retval; +} +/* * The ext4_map_blocks() function tries to look up the requested blocks, * and returns if the blocks are already mapped.
@@ -1767,33 +1796,11 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,down_read (&EXT4_I (inode)->i_data_sem);if (ext4_has_inline_data (inode)) retval =0 ; -else if (ext4_test_inode_flag (inode,EXT4_INODE_EXTENTS )) - retval =ext4_ext_map_blocks (NULL , inode, map,0 );else - retval =ext4_ind_map_blocks (NULL , inode, map,0 ); -if (retval <0 ) { -up_read (&EXT4_I (inode)->i_data_sem); -return retval; - } -if (retval >0 ) { -unsigned int status; - -if (unlikely (retval != map->m_len)) { -ext4_warning (inode->i_sb, -"ES len assertion failed for inode " -"%lu: retval %d != map->m_len %d" , - inode->i_ino, retval, map->m_len); -WARN_ON (1 ); - } - - status = map->m_flags &EXT4_MAP_UNWRITTEN ? -EXTENT_STATUS_UNWRITTEN :EXTENT_STATUS_WRITTEN ; -ext4_es_insert_extent (inode, map->m_lblk, map->m_len, - map->m_pblk, status); -up_read (&EXT4_I (inode)->i_data_sem); -return retval; - } + retval =ext4_map_query_blocks (NULL , inode, map);up_read (&EXT4_I (inode)->i_data_sem); +if (retval) +return retval; add_delayed:down_write (&EXT4_I (inode)->i_data_sem);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 221/352 ext4: check the extent status again before inserting delalloc block
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Yi <[email protected]>
[ Upstream commit 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c ]
ext4_da_map_blocks looks up for any extent entry in the extent status tree (w/o i_data_sem) and then the looks up for any ondisk extent mapping (with i_data_sem in read mode).
If it finds a hole in the extent status tree or if it couldn't find any entry at all, it then takes the i_data_sem in write mode to add a da entry into the extent status tree. This can actually race with page mkwrite & fallocate path.
Note that this is ok between
1. ext4 buffered-write path v/s ext4_page_mkwrite(), because of the folio lock
2. ext4 buffered write path v/s ext4 fallocate because of the inode lock.
But this can race between ext4_page_mkwrite() & ext4 fallocate path
ext4_page_mkwrite() ext4_fallocate()
block_page_mkwrite()
ext4_da_map_blocks()
//find hole in extent status tree
ext4_alloc_file_blocks()
ext4_map_blocks()
//allocate block and unwritten extent
ext4_insert_delayed_block()
ext4_da_reserve_space()
//reserve one more block
ext4_es_insert_delayed_block()
//drop unwritten extent and add delayed extent by mistakeThen, the delalloc extent is wrong until writeback and the extra reserved block can't be released any more and it triggers below warning:
EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared!
Fix the problem by looking up extent status tree again while the i_data_sem is held in write mode. If it still can't find any entry, then we insert a new da entry into the extent status tree.
--- fs/ext4/inode.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
fs/ext4/inode.c +21 -0
@@ -1760,6 +1760,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,if (ext4_es_is_hole (&es)) goto add_delayed; +found:/* * Delayed extent could be allocated by fallocate. * So we need to check it.
@@ -1804,6 +1805,26 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, add_delayed:down_write (&EXT4_I (inode)->i_data_sem); +/* +* Page fault path (ext4_page_mkwrite does not take i_rwsem) +* and fallocate path (no folio lock) can race. Make sure we +* lookup the extent status tree here again while i_data_sem +* is held in write mode, before inserting a new da entry in +* the extent status tree. +*/ +if (ext4_es_lookup_extent (inode, iblock,NULL , &es)) { +if (!ext4_es_is_hole (&es)) { +up_write (&EXT4_I (inode)->i_data_sem); + goto found; + } + }else if (!ext4_has_inline_data (inode)) { + retval =ext4_map_query_blocks (NULL , inode, map); +if (retval) { +up_write (&EXT4_I (inode)->i_data_sem); +return retval; + } + } + retval =ext4_insert_delayed_block (inode, map->m_lblk);up_write (&EXT4_I (inode)->i_data_sem);if (retval)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 222/352 soc: xilinx: move PM_INIT_FINALIZE to zynqmp_pm_domains driver
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Tretter <[email protected]>
[ Upstream commit 7fd890b89dea55eb5866640eb8befad26d558161 ]
PM_INIT_FINALIZE tells the PMU FW that Linux is able to handle the power management nodes that are provided by the PMU FW. Nodes that are not requested are shut down after this call.
Calling PM_INIT_FINALIZE from the zynqmp_power driver is wrong. The PM node request mechanism is implemented in the zynqmp_pm_domains driver, which must also call PM_INIT_FINALIZE.
Due to the behavior of the PMU FW, all devices must be powered up before PM_INIT_FINALIZE is called, because otherwise the devices might misbehave. Calling PM_INIT_FINALIZE from the sync_state device callback ensures that all users probed successfully before the PMU FW is allowed to power off unused domains.
Stable-dep-of: 9b003e14801c ("drivers: soc: xilinx: check return status of get_api_version()")
--- drivers/soc/xilinx/zynqmp_pm_domains.c | 16 ++++++++++++++++ drivers/soc/xilinx/zynqmp_power.c | 1 - 2 files changed, 16 insertions(+), 1 deletion(-)
drivers/soc/xilinx/zynqmp_pm_domains.c +16 -0
@@ -152,11 +152,17 @@ static int zynqmp_gpd_power_off(struct generic_pm_domain *domain)static int zynqmp_gpd_attach_dev (struct generic_pm_domain *domain,struct device *dev) { +struct device_link *link;int ret;struct zynqmp_pm_domain *pd; pd = container_of(domain, struct zynqmp_pm_domain, gpd); + link =device_link_add (dev, &domain->dev,DL_FLAG_SYNC_STATE_ONLY ); +if (!link) +dev_dbg (&domain->dev,"failed to create device link for %s\n" , +dev_name (dev)); +/* If this is not the first device to attach there is nothing to do */ if (domain->device_count)return 0 ;
@@ -299,9 +305,19 @@ static int zynqmp_gpd_remove(struct platform_device *pdev)return 0 ; } +static void zynqmp_gpd_sync_state (struct device *dev) +{ +int ret; + + ret =zynqmp_pm_init_finalize (); +if (ret) +dev_warn (dev,"failed to release power management to firmware\n" ); +} +static struct platform_driver zynqmp_power_domain_driver = { .driver = { .name ="zynqmp_power_controller" , + .sync_state = zynqmp_gpd_sync_state, }, .probe = zynqmp_gpd_probe, .remove = zynqmp_gpd_remove,
drivers/soc/xilinx/zynqmp_power.c +0 -1
@@ -178,7 +178,6 @@ static int zynqmp_pm_probe(struct platform_device *pdev)u32 pm_api_version;struct mbox_client *client; -zynqmp_pm_init_finalize ();zynqmp_pm_get_api_version (&pm_api_version);/* Check PM API version number */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 223/352 drivers: soc: xilinx: check return status of get_api_version()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Buddhabhatti <[email protected]>
[ Upstream commit 9b003e14801cf85a8cebeddc87bc9fc77100fdce ]
Currently return status is not getting checked for get_api_version and because of that for x86 arch we are getting below smatch error.
CC drivers/soc/xilinx/zynqmp_power.odrivers/soc/xilinx/zynqmp_power.c: In function 'zynqmp_pm_probe':drivers/soc/xilinx/zynqmp_power.c:295:12: warning: 'pm_api_version' is used uninitialized [-Wuninitialized]
295 | if (pm_api_version < ZYNQMP_PM_VERSION)
| ^
CHECK drivers/soc/xilinx/zynqmp_power.cdrivers/soc/xilinx/zynqmp_power.c:295 zynqmp_pm_probe() error:
uninitialized symbol 'pm_api_version'.
So, check return status of pm_get_api_version and return error in case of failure to avoid checking uninitialized pm_api_version variable.
--- drivers/soc/xilinx/zynqmp_power.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/soc/xilinx/zynqmp_power.c +3 -1
@@ -178,7 +178,9 @@ static int zynqmp_pm_probe(struct platform_device *pdev)u32 pm_api_version;struct mbox_client *client; -zynqmp_pm_get_api_version (&pm_api_version); + ret =zynqmp_pm_get_api_version (&pm_api_version); +if (ret) +return ret;/* Check PM API version number */ if (pm_api_version <ZYNQMP_PM_VERSION )
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 224/352 driver core: Cast to (void *) with __force for __percpu pointer
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit d7aa44f5a1f86cb40659eef06035d8d92604b9d5 ]
Sparse is not happy:
drivers/base/devres.c:1230:9: warning: cast removes address space '__percpu' of expression
Use __force attribute to make it happy.
Stable-dep-of: bd50a974097b ("devres: Fix memory leakage caused by driver API devm_free_percpu()")
--- drivers/base/devres.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/devres.c +1 -1
@@ -1231,6 +1231,6 @@ EXPORT_SYMBOL_GPL(__devm_alloc_percpu);void devm_free_percpu (struct device *dev,void __percpu *pdata) {WARN_ON (devres_destroy (dev, devm_percpu_release, devm_percpu_match, - (void *)pdata)); + (__force void *)pdata)); }EXPORT_SYMBOL_GPL (devm_free_percpu);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 225/352 devres: Fix memory leakage caused by driver API devm_free_percpu()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zijun Hu <[email protected]>
[ Upstream commit bd50a974097bb82d52a458bd3ee39fb723129a0c ]
It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().
--- drivers/base/devres.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/base/devres.c +5 -1
@@ -1230,7 +1230,11 @@ EXPORT_SYMBOL_GPL(__devm_alloc_percpu);*/ void devm_free_percpu (struct device *dev,void __percpu *pdata) { -WARN_ON (devres_destroy (dev, devm_percpu_release, devm_percpu_match, +/* +* Use devres_release() to prevent memory leakage as +* devm_free_pages() does. +*/ +WARN_ON (devres_release (dev, devm_percpu_release, devm_percpu_match, (__force void *)pdata)); }EXPORT_SYMBOL_GPL (devm_free_percpu);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 226/352 genirq: Allow the PM device to originate from irq domain
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
[ Upstream commit 1f8863bfb5ca500ea1c7669b16b1931ba27fce20 ]
As a preparation to moving the reference to the device used for runtime power management, add a new 'dev' field to the irqdomain structure for that exact purpose.
The irq_chip_pm_{get,put}() helpers are made aware of the dual location via a new private helper.
No functional change intended.
Stable-dep-of: 33b1c47d1fc0 ("irqchip/imx-irqsteer: Handle runtime power management correctly")
--- include/linux/irqdomain.h | 10 ++++++++++ kernel/irq/chip.c | 23 ++++++++++++++++++----- 2 files changed, 28 insertions(+), 5 deletions(-)
include/linux/irqdomain.h +10 -0
@@ -149,6 +149,8 @@ struct irq_domain_chip_generic;* @gc: Pointer to a list of generic chips. There is a helper function for * setting up one or more generic chips for interrupt controllers * drivers using the generic chip library which uses this pointer. +* @dev: Pointer to a device that the domain represent, and that will be +* used for power management purposes. * @parent: Pointer to parent irq_domain to support hierarchy irq_domains * @debugfs_file: dentry for the domain debugfs file *
@@ -171,6 +173,7 @@ struct irq_domain {struct fwnode_handle *fwnode;enum irq_domain_bus_token bus_token;struct irq_domain_chip_generic *gc; +struct device *dev;#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY struct irq_domain *parent;#endif
@@ -227,6 +230,13 @@ static inline struct device_node *irq_domain_get_of_node(struct irq_domain *d)return to_of_node (d->fwnode); } +static inline void irq_domain_set_pm_device (struct irq_domain *d, +struct device *dev) +{ +if (d) + d->dev = dev; +} +#ifdef CONFIG_IRQ_DOMAIN struct fwnode_handle *__irq_domain_alloc_fwnode (unsigned int type,int id,const char *name,phys_addr_t *pa);
kernel/irq/chip.c +18 -5
@@ -1586,6 +1586,17 @@ int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)return 0 ; } +static struct device *irq_get_parent_device (struct irq_data *data) +{ +if (data->chip->parent_device) +return data->chip->parent_device; + +if (data->domain) +return data->domain->dev; + +return NULL ; +} +/** * irq_chip_pm_get - Enable power for an IRQ chip * @data: Pointer to interrupt specific data
@@ -1595,12 +1606,13 @@ int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)*/ int irq_chip_pm_get (struct irq_data *data) { +struct device *dev =irq_get_parent_device (data);int retval; -if (IS_ENABLED (CONFIG_PM ) && data->chip->parent_device) { - retval =pm_runtime_get_sync (data->chip->parent_device); +if (IS_ENABLED (CONFIG_PM ) && dev) { + retval =pm_runtime_get_sync (dev);if (retval <0 ) { -pm_runtime_put_noidle (data->chip->parent_device); +pm_runtime_put_noidle (dev);return retval; } }
@@ -1618,10 +1630,11 @@ int irq_chip_pm_get(struct irq_data *data)*/ int irq_chip_pm_put (struct irq_data *data) { +struct device *dev =irq_get_parent_device (data);int retval =0 ; -if (IS_ENABLED (CONFIG_PM ) && data->chip->parent_device) - retval =pm_runtime_put (data->chip->parent_device); +if (IS_ENABLED (CONFIG_PM ) && dev) + retval =pm_runtime_put (dev);return (retval <0 ) ? retval :0 ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 227/352 irqchip/imx-irqsteer: Constify irq_chip struct
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas Stach <[email protected]>
[ Upstream commit e9a50f12e579a48e124ac5adb93dafc35f0a46b8 ]
The imx_irqsteer_irq_chip struct is constant data.
Stable-dep-of: 33b1c47d1fc0 ("irqchip/imx-irqsteer: Handle runtime power management correctly")
--- drivers/irqchip/irq-imx-irqsteer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/irqchip/irq-imx-irqsteer.c +1 -1
@@ -70,7 +70,7 @@ static void imx_irqsteer_irq_mask(struct irq_data *d)raw_spin_unlock_irqrestore (&data->lock, flags); } -static struct irq_chip imx_irqsteer_irq_chip = { +static const struct irq_chip imx_irqsteer_irq_chip = { .name ="irqsteer" , .irq_mask = imx_irqsteer_irq_mask, .irq_unmask = imx_irqsteer_irq_unmask,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 228/352 irqchip/imx-irqsteer: Add runtime PM support
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas Stach <[email protected]>
[ Upstream commit 4730d2233311d86cad9dc510318d1b40e4b53cf2 ]
There are now SoCs that integrate the irqsteer controller within a separate power domain. In order to allow this domain to be powered down when not needed, add runtime PM support to the driver.
Stable-dep-of: 33b1c47d1fc0 ("irqchip/imx-irqsteer: Handle runtime power management correctly")
--- drivers/irqchip/irq-imx-irqsteer.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/irqchip/irq-imx-irqsteer.c +11 -3
@@ -12,6 +12,7 @@#include <linux/kernel.h> #include <linux/of_irq.h> #include <linux/of_platform.h> +#include <linux/pm_runtime.h> #include <linux/spinlock.h> #define CTRL_STRIDE_OFF (_t, _r) (_t * 4 * _r)
@@ -178,7 +179,7 @@ static int imx_irqsteer_probe(struct platform_device *pdev) data->irq_count =DIV_ROUND_UP (irqs_num,64 ); data->reg_num = irqs_num /32 ; -if (IS_ENABLED (CONFIG_PM_SLEEP )) { +if (IS_ENABLED (CONFIG_PM )) { data->saved_reg =devm_kzalloc (&pdev->dev,sizeof (u32) * data->reg_num,GFP_KERNEL );
@@ -202,6 +203,7 @@ static int imx_irqsteer_probe(struct platform_device *pdev) ret = -ENOMEM ; goto out; } +irq_domain_set_pm_device (data->domain, &pdev->dev);if (!data->irq_count || data->irq_count >CHAN_MAX_OUTPUT_INT ) { ret = -EINVAL ;
@@ -222,6 +224,9 @@ static int imx_irqsteer_probe(struct platform_device *pdev)platform_set_drvdata (pdev, data); +pm_runtime_set_active (&pdev->dev); +pm_runtime_enable (&pdev->dev); +return 0 ; out:clk_disable_unprepare (data->ipg_clk);
@@ -244,7 +249,7 @@ static int imx_irqsteer_remove(struct platform_device *pdev)return 0 ; } -#ifdef CONFIG_PM_SLEEP +#ifdef CONFIG_PM static void imx_irqsteer_save_regs (struct irqsteer_data *data) {int i;
@@ -291,7 +296,10 @@ static int imx_irqsteer_resume(struct device *dev)#endif static const struct dev_pm_ops imx_irqsteer_pm_ops = { -SET_NOIRQ_SYSTEM_SLEEP_PM_OPS (imx_irqsteer_suspend, imx_irqsteer_resume) + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, + pm_runtime_force_resume) +SET_RUNTIME_PM_OPS (imx_irqsteer_suspend, + imx_irqsteer_resume,NULL ) };static const struct of_device_id imx_irqsteer_dt_ids[] = {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 229/352 irqchip/imx-irqsteer: Handle runtime power management correctly
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shenwei Wang <[email protected]>
[ Upstream commit 33b1c47d1fc0b5f06a393bb915db85baacba18ea ]
The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing:
BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0
Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context.
[ tglx: Rewrote change log, added Fixes tag ]
--- drivers/irqchip/irq-imx-irqsteer.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-)
drivers/irqchip/irq-imx-irqsteer.c +21 -3
@@ -35,6 +35,7 @@ struct irqsteer_data {int channel;struct irq_domain *domain;u32 *saved_reg; +struct device *dev; }; static int imx_irqsteer_get_reg_index(struct irqsteer_data *data,
@@ -71,10 +72,26 @@ static void imx_irqsteer_irq_mask(struct irq_data *d)raw_spin_unlock_irqrestore (&data->lock, flags); } +static void imx_irqsteer_irq_bus_lock (struct irq_data *d) +{ +struct irqsteer_data *data = d->chip_data; + +pm_runtime_get_sync (data->dev); +} + +static void imx_irqsteer_irq_bus_sync_unlock (struct irq_data *d) +{ +struct irqsteer_data *data = d->chip_data; + +pm_runtime_put_autosuspend (data->dev); +} +static const struct irq_chip imx_irqsteer_irq_chip = { - .name ="irqsteer" , - .irq_mask = imx_irqsteer_irq_mask, - .irq_unmask = imx_irqsteer_irq_unmask, + .name ="irqsteer" , + .irq_mask = imx_irqsteer_irq_mask, + .irq_unmask = imx_irqsteer_irq_unmask, + .irq_bus_lock = imx_irqsteer_irq_bus_lock, + .irq_bus_sync_unlock = imx_irqsteer_irq_bus_sync_unlock, }; static int imx_irqsteer_irq_map(struct irq_domain *h, unsigned int irq,
@@ -152,6 +169,7 @@ static int imx_irqsteer_probe(struct platform_device *pdev)if (!data)return -ENOMEM ; + data->dev = &pdev->dev; data->regs =devm_platform_ioremap_resource (pdev,0 );if (IS_ERR (data->regs)) {dev_err (&pdev->dev,"failed to initialize reg\n" );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 230/352 remoteproc: imx_rproc: ignore mapping vdev regions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit 8f2d8961640f0346cbe892273c3260a0d30c1931 ]
vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar. They are handled by remoteproc common code, no need to map in imx rproc driver.
Stable-dep-of: 2fa26ca8b786 ("remoteproc: imx_rproc: Skip over memory region when node value is NULL")
--- drivers/remoteproc/imx_rproc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/remoteproc/imx_rproc.c +3 -0
@@ -287,6 +287,9 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,struct resource res; node =of_parse_phandle (np,"memory-region" , a); +/* Not map vdev region */ +if (!strcmp (node->name,"vdev" )) +continue ; err =of_address_to_resource (node,0 , &res);if (err) {dev_err (dev,"unable to resolve memory region\n" );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 231/352 remoteproc: imx_rproc: Fix ignoring mapping vdev regions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dong Aisheng <[email protected]>
[ Upstream commit afe670e23af91d8a74a8d7049f6e0984bbf6ea11 ]
vdev regions are typically named vdev0buffer, vdev0ring0, vdev0ring1 and etc. Change to strncmp to cover them all.
Stable-dep-of: 2fa26ca8b786 ("remoteproc: imx_rproc: Skip over memory region when node value is NULL")
--- drivers/remoteproc/imx_rproc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/remoteproc/imx_rproc.c +2 -2
@@ -287,8 +287,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,struct resource res; node =of_parse_phandle (np,"memory-region" , a); -/* Not map vdev region */ -if (!strcmp (node->name,"vdev" )) +/* Not map vdevbuffer, vdevring region */ +if (!strncmp (node->name,"vdev" ,strlen ("vdev" )))continue ; err =of_address_to_resource (node,0 , &res);if (err) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 232/352 remoteproc: imx_rproc: Skip over memory region when node value is NULL
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aleksandr Mishin <[email protected]>
[ Upstream commit 2fa26ca8b786888673689ccc9da6094150939982 ]
In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/remoteproc/imx_rproc.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/remoteproc/imx_rproc.c +2 -0
@@ -287,6 +287,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,struct resource res; node =of_parse_phandle (np,"memory-region" , a); +if (!node) +continue ;/* Not map vdevbuffer, vdevring region */ if (!strncmp (node->name,"vdev" ,strlen ("vdev" )))continue ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 233/352 drm/nouveau: prime: fix refcount underflow
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Danilo Krummrich <[email protected]>
[ Upstream commit a9bf3efc33f1fbf88787a277f7349459283c9b95 ]
Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow.
Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually.
--- drivers/gpu/drm/nouveau/nouveau_prime.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_prime.c +2 -1
@@ -81,7 +81,8 @@ struct drm_gem_object *nouveau_gem_prime_import_sg_table(struct drm_device *dev,* to the caller, instead of a normal nouveau_bo ttm reference. */ ret =drm_gem_object_init (dev, &nvbo->bo.base, size);if (ret) { -nouveau_bo_ref (NULL , &nvbo); +drm_gem_object_release (&nvbo->bo.base); +kfree (nvbo); obj =ERR_PTR (-ENOMEM ); goto unlock; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 234/352 drm/vmwgfx: Fix overlay when using Screen Targets
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Forbes <[email protected]>
[ Upstream commit cb372a505a994cb39aa75acfb8b3bcf94787cf94 ]
This code was never updated to support Screen Targets.
Fixes a bug where Xv playback displays a green screen instead of actual video contents when 3D acceleration is disabled in the guest.
--- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c +1 -1
@@ -98,7 +98,7 @@ static int vmw_overlay_send_put(struct vmw_private *dev_priv, {struct vmw_escape_video_flush *flush;size_t fifo_size; -bool have_so = (dev_priv->active_display_unit == vmw_du_screen_object); +bool have_so = (dev_priv->active_display_unit != vmw_du_legacy);int i, num_items;SVGAGuestPtr ptr;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 235/352 sched: act_ct: take care of padding in struct zones_ht_key
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 2191a54f63225b548fd8346be3611c3219a24738 ]
Blamed commit increased lookup key size from 2 bytes to 16 bytes, because zones_ht_key got a struct net pointer.
Make sure rhashtable_lookup() is not using the padding bytes which are not initialized.
BUG: KMSAN: uninit-value in rht_ptr_rcu include/linux/rhashtable.h:376 [inline] BUG: KMSAN: uninit-value in __rhashtable_lookup include/linux/rhashtable.h:607 [inline] BUG: KMSAN: uninit-value in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KMSAN: uninit-value in rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] BUG: KMSAN: uninit-value in tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329 rht_ptr_rcu include/linux/rhashtable.h:376 [inline] __rhashtable_lookup include/linux/rhashtable.h:607 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329 tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408 tcf_action_init_1+0x6cc/0xb30 net/sched/act_api.c:1425 tcf_action_init+0x458/0xf00 net/sched/act_api.c:1488 tcf_action_add net/sched/act_api.c:2061 [inline] tc_ctl_action+0x4be/0x19d0 net/sched/act_api.c:2118 rtnetlink_rcv_msg+0x12fc/0x1410 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2550 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6665 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2597 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2651 __sys_sendmsg net/socket.c:2680 [inline] __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2687 x64_sys_call+0x2dd6/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable key created at:
tcf_ct_flow_table_get+0x4a/0x2260 net/sched/act_ct.c:324 tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408
--- net/sched/act_ct.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/sched/act_ct.c +3 -1
@@ -41,6 +41,8 @@ static DEFINE_MUTEX(zones_mutex);struct zones_ht_key {struct net *net;u16 zone; +/* Note : pad[] must be the last field. */ +u8 pad[]; };struct tcf_ct_flow_table {
@@ -57,7 +59,7 @@ struct tcf_ct_flow_table {static const struct rhashtable_params zones_params = { .head_offset = offsetof(struct tcf_ct_flow_table , node), .key_offset = offsetof(struct tcf_ct_flow_table , key), - .key_len = sizeof_field(struct tcf_ct_flow_table, key), + .key_len = offsetof(struct zones_ht_key , pad), .automatic_shrinking = true, };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 236/352 net/iucv: fix use after free in iucv_sock_close()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandra Winter <[email protected]>
[ Upstream commit f558120cd709682b739207b48cf7479fd9568431 ]
iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn().
Example:
[452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt
Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing.
Ideas for a future clean-up patch:
A) Correct usage of bh_lock_sock() in tasklet context, as described in
Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv.
B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.
--- net/iucv/af_iucv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/iucv/af_iucv.c +2 -2
@@ -359,8 +359,8 @@ static void iucv_sever_path(struct sock *sk, int with_user_data)struct iucv_sock *iucv =iucv_sk (sk);struct iucv_path *path = iucv->path; -if (iucv->path) { - iucv->path =NULL ; +/* Whoever resets the path pointer, must sever and free it. */ +if (xchg (&iucv->path,NULL )) {if (with_user_data) {low_nmcpy (user_data, iucv->src_name);high_nmcpy (user_data, iucv->dst_name);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 237/352 net/mlx5e: Add a check for the return value from mlx5_port_set_eth_ptys
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shahar Shitrit <[email protected]>
[ Upstream commit 3f8e82a020a5c22f9b791f4ac499b8e18007fbda ]
Since the documentation for mlx5_toggle_port_link states that it should only be used after setting the port register, we add a check for the return value from mlx5_port_set_eth_ptys to ensure the register was successfully set before calling it.
--- drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c +6 -1
@@ -1155,7 +1155,12 @@ int mlx5e_ethtool_set_link_ksettings(struct mlx5e_priv *priv,if (!an_changes && link_modes == eproto.admin) goto out; -mlx5_port_set_eth_ptys (mdev, an_disable, link_modes, ext); + err =mlx5_port_set_eth_ptys (mdev, an_disable, link_modes, ext); +if (err) { +netdev_err (priv->netdev,"%s: failed to set ptys reg: %d\n" , __func__, err); + goto out; + } +mlx5_toggle_port_link (mdev); out:
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 238/352 ipv6: fix ndisc_is_useropt() handling for PIO
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej Żenczykowski <[email protected]>
[ Upstream commit a46c68debf3be3a477a69ccbf0a1d050df841676 ]
The current logic only works if the PIO is between two other ND user options. This fixes it so that the PIO can also be either before or after other ND user options (for example the first or last option in the RA).
side note: there's actually Android tests verifying a portion of the old broken behaviour, so:
https://android-review.googlesource.com/c/kernel/tests/+/3196704
fixes those up.
--- net/ipv6/ndisc.c | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-)
net/ipv6/ndisc.c +18 -16
@@ -226,6 +226,7 @@ struct ndisc_options *ndisc_parse_options(const struct net_device *dev,return NULL ;memset (ndopts,0 ,sizeof (*ndopts));while (opt_len) { +bool unknown = false;int l;if (opt_len <sizeof (struct nd_opt_hdr ))return NULL ;
@@ -261,22 +262,23 @@ struct ndisc_options *ndisc_parse_options(const struct net_device *dev,break ;#endif default : -if (ndisc_is_useropt (dev, nd_opt)) { - ndopts->nd_useropts_end = nd_opt; -if (!ndopts->nd_useropts) - ndopts->nd_useropts = nd_opt; - }else { -/* -* Unknown options must be silently ignored, -* to accommodate future extension to the -* protocol. -*/ -ND_PRINTK (2 , notice, -"%s: ignored unsupported option; type=%d, len=%d\n" , - __func__, - nd_opt->nd_opt_type, - nd_opt->nd_opt_len); - } + unknown = true; + } +if (ndisc_is_useropt (dev, nd_opt)) { + ndopts->nd_useropts_end = nd_opt; +if (!ndopts->nd_useropts) + ndopts->nd_useropts = nd_opt; + }else if (unknown) { +/* +* Unknown options must be silently ignored, +* to accommodate future extension to the +* protocol. +*/ +ND_PRINTK (2 , notice, +"%s: ignored unsupported option; type=%d, len=%d\n" , + __func__, + nd_opt->nd_opt_type, + nd_opt->nd_opt_len); } next_opt: opt_len -= l;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 239/352 riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhe Qiao <[email protected]>
[ Upstream commit 0c710050c47d45eb77b28c271cddefc5c785cb40 ]
Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.
--- arch/riscv/mm/fault.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
arch/riscv/mm/fault.c +9 -8
@@ -39,26 +39,27 @@ static inline void no_context(struct pt_regs *regs, unsigned long addr)static inline void mm_fault_error (struct pt_regs *regs,unsigned long addr,vm_fault_t fault) { +if (!user_mode (regs)) { +no_context (regs, addr); +return ; + } +if (fault &VM_FAULT_OOM ) {/* * We ran out of memory, call the OOM killer, and return the userspace * (which will retry the fault, or kill us if we got oom-killed). */ -if (!user_mode (regs)) { -no_context (regs, addr); -return ; - }pagefault_out_of_memory ();return ; }else if (fault &VM_FAULT_SIGBUS ) {/* Kernel mode? Handle exceptions or die */ -if (!user_mode (regs)) { -no_context (regs, addr); -return ; - }do_trap (regs,SIGBUS ,BUS_ADRERR , addr);return ; + }else if (fault &VM_FAULT_SIGSEGV ) { +do_trap (regs,SIGSEGV ,SEGV_MAPERR , addr); +return ; } +BUG (); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 240/352 platform/chrome: cros_ec_proto: Lock device when updating MKBP version
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patryk Duda <[email protected]>
commit df615907f1bf907260af01ccb904d0e9304b5278 upstream.
The cros_ec_get_host_command_version_mask() function requires that the caller must have ec_dev->lock mutex before calling it. This requirement was not met and as a result it was possible that two commands were sent to the device at the same time.
The problem was observed while using UART backend which doesn't use any additional locks, unlike SPI backend which locks the controller until response is received.
--- drivers/platform/chrome/cros_ec_proto.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/platform/chrome/cros_ec_proto.c +2 -0
@@ -780,9 +780,11 @@ int cros_ec_get_next_event(struct cros_eif (ret == -ENOPROTOOPT ) {dev_dbg (ec_dev->dev,"GET_NEXT_EVENT returned invalid version error.\n" ); +mutex_lock (&ec_dev->lock); ret =cros_ec_get_host_command_version_mask (ec_dev,EC_CMD_GET_NEXT_EVENT , &ver_mask); +mutex_unlock (&ec_dev->lock);if (ret <0 || ver_mask ==0 )/* * Do not change the MKBP supported version if we can't
Greg Kroah-Hartman
maintainerPATCH 241/352 HID: wacom: Modify pen IDs
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tatsunosuke Tobita <[email protected]>
commit f0d17d696dfce77c9abc830e4ac2d677890a2dad upstream.
The pen ID, 0x80842, was not the correct ID for wacom driver to treat. The ID was corrected to 0x8842.
Also, 0x4200 was not the expected ID used on any Wacom device. Therefore, 0x4200 was removed.
--- drivers/hid/wacom_wac.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/hid/wacom_wac.c +1 -2
@@ -714,13 +714,12 @@ static int wacom_intuos_get_tool_type(incase 0x8e2 :/* IntuosHT2 pen */ case 0x022 :case 0x200 :/* Pro Pen 3 */ -case 0x04200 :/* Pro Pen 3 */ case 0x10842 :/* MobileStudio Pro Pro Pen slim */ case 0x14802 :/* Intuos4/5 13HD/24HD Classic Pen */ case 0x16802 :/* Cintiq 13HD Pro Pen */ case 0x18802 :/* DTH2242 Pen */ case 0x10802 :/* Intuos4/5 13HD/24HD General Pen */ -case 0x80842 :/* Intuos Pro and Cintiq Pro 3D Pen */ +case 0x8842 :/* Intuos Pro and Cintiq Pro 3D Pen */ tool_type =BTN_TOOL_PEN ;break ;
Greg Kroah-Hartman
maintainerPATCH 242/352 protect the fetch of ->fd[fd] in do_dup2() from mispredictions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 8aa37bde1a7b645816cda8b80df4753ecf172bf1 upstream.
both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with
tofree = fdt->fd[fd];
being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.
--- fs/file.c | 1 + 1 file changed, 1 insertion(+)
fs/file.c +1 -0
@@ -1057,6 +1057,7 @@ __releases(&files->file_lock)* tables and this condition does not arise without those. */ fdt =files_fdtable (files); + fd =array_index_nospec (fd, fdt->max_fds); tofree = fdt->fd[fd];if (!tofree &&fd_is_open (fd, fdt)) goto Ebusy;
Greg Kroah-Hartman
maintainerPATCH 243/352 ALSA: usb-audio: Correct surround channels in UAC1 channel map
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit b7b7e1ab7619deb3b299b5e5c619c3e6f183a12d upstream.
USB-audio driver puts SNDRV_CHMAP_SL and _SR as left and right surround channels for UAC1 channel map, respectively. But they should have been SNDRV_CHMAP_RL and _RR; the current value *_SL and _SR are rather "side" channels, not "surround". I guess I took those mistakenly when I read the spec mentioning "surround left".
This patch corrects those entries to be the right channels.
--- sound/usb/stream.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/usb/stream.c +2 -2
@@ -245,8 +245,8 @@ static struct snd_pcm_chmap_elem *converSNDRV_CHMAP_FR ,/* right front */ SNDRV_CHMAP_FC ,/* center front */ SNDRV_CHMAP_LFE ,/* LFE */ -SNDRV_CHMAP_SL ,/* left surround */ -SNDRV_CHMAP_SR ,/* right surround */ +SNDRV_CHMAP_RL ,/* left surround */ +SNDRV_CHMAP_RR ,/* right surround */ SNDRV_CHMAP_FLC ,/* left of center */ SNDRV_CHMAP_FRC ,/* right of center */ SNDRV_CHMAP_RC, /* surround */
Greg Kroah-Hartman
maintainerPATCH 244/352 ALSA: hda/realtek: Add quirk for Acer Aspire E5-574G
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mavroudis Chatzilazaridis <[email protected]>
commit 3c0b6f924e1259ade38587ea719b693f6f6f2f3e upstream.
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST fixes combo jack detection and limits the internal microphone boost that causes clipping on this model.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -8893,6 +8893,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x1025 ,0x079b ,"Acer Aspire V5-573G" ,ALC282_FIXUP_ASPIRE_V5_PINS ),SND_PCI_QUIRK (0x1025 ,0x080d ,"Acer Aspire V5-122P" ,ALC269_FIXUP_ASPIRE_HEADSET_MIC ),SND_PCI_QUIRK (0x1025 ,0x0840 ,"Acer Aspire E1" ,ALC269VB_FIXUP_ASPIRE_E1_COEF ), +SND_PCI_QUIRK (0x1025 ,0x100c ,"Acer Aspire E5-574G" ,ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST ),SND_PCI_QUIRK (0x1025 ,0x101c ,"Acer Veriton N2510G" ,ALC269_FIXUP_LIFEBOOK ),SND_PCI_QUIRK (0x1025 ,0x102b ,"Acer Aspire C24-860" ,ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE ), SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820", ALC269VC_FIXUP_ACER_HEADSET_MIC),
Greg Kroah-Hartman
maintainerPATCH 245/352 net: usb: sr9700: fix uninitialized variable use in sr_mdio_read
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit 08f3a5c38087d1569e982a121aad1e6acbf145ce upstream.
It could lead to error happen because the variable res is not updated if the call to sr_share_read_word returns an error. In this particular case error code was returned and res stayed uninitialized. Same issue also applies to sr_read_reg.
This can be avoided by checking the return value of sr_share_read_word and sr_read_reg, and propagating the error if the read operation failed.
Found by code review.
--- drivers/net/usb/sr9700.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/net/usb/sr9700.c +9 -2
@@ -178,6 +178,7 @@ static int sr_mdio_read(struct net_devicstruct usbnet *dev =netdev_priv (netdev);__le16 res;int rc =0 ; +int err;if (phy_id) {netdev_dbg (netdev,"Only internal phy supported\n" );
@@ -188,11 +189,17 @@ static int sr_mdio_read(struct net_devicif (loc ==MII_BMSR ) {u8 value; -sr_read_reg (dev,SR_NSR , &value); + err =sr_read_reg (dev,SR_NSR , &value); +if (err <0 ) +return err; +if (value &NSR_LINKST ) rc =1 ; } -sr_share_read_word (dev,1 , loc, &res); + err =sr_share_read_word (dev,1 , loc, &res); +if (err <0 ) +return err; +if (rc ==1 ) res =le16_to_cpu (res) |BMSR_LSTATUS ;else
Greg Kroah-Hartman
maintainerPATCH 246/352 r8169: dont increment tx_dropped in case of NETDEV_TX_BUSY
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
commit d516b187a9cc2e842030dd005be2735db3e8f395 upstream.
The skb isn't consumed in case of NETDEV_TX_BUSY, therefore don't increment the tx_dropped counter.
--- drivers/net/ethernet/realtek/r8169_main.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/net/ethernet/realtek/r8169_main.c +2 -6
@@ -4288,7 +4288,8 @@ static netdev_tx_t rtl8169_start_xmit(stif (unlikely (!rtl_tx_slots_avail (tp))) {if (net_ratelimit ())netdev_err (dev,"BUG! Tx Ring full when queue awake!\n" ); - goto err_stop_0; +netif_stop_queue (dev); +return NETDEV_TX_BUSY ; } opts[1 ] =rtl8169_tx_vlan_tag (skb);
@@ -4361,11 +4362,6 @@ err_dma_0:dev_kfree_skb_any (skb); dev->stats.tx_dropped++;return NETDEV_TX_OK ; - -err_stop_0: -netif_stop_queue (dev); - dev->stats.tx_dropped++; -return NETDEV_TX_BUSY ; }static unsigned int rtl_last_frag_len (struct sk_buff *skb)
Greg Kroah-Hartman
maintainerPATCH 247/352 mptcp: fix duplicate data handling
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit 68cc924729ffcfe90d0383177192030a9aeb2ee4 upstream.
When a subflow receives and discards duplicate data, the mptcp stack assumes that the consumed offset inside the current skb is zero.
With multiple subflows receiving data simultaneously such assertion does not held true. As a result the subflow-level copied_seq will be incorrectly increased and later on the same subflow will observe a bad mapping, leading to subflow reset.
Address the issue taking into account the skb consumed offset in mptcp_subflow_discard_data().
--- net/mptcp/subflow.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
net/mptcp/subflow.c +12 -4
@@ -863,14 +863,22 @@ static void mptcp_subflow_discard_data(s {struct mptcp_subflow_context *subflow =mptcp_subflow_ctx (ssk);bool fin =TCP_SKB_CB (skb)->tcp_flags &TCPHDR_FIN ; -u32 incr; +struct tcp_sock *tp =tcp_sk (ssk); +u32 offset, incr, avail_len; - incr = limit >= skb->len ? skb->len + fin : limit; + offset = tp->copied_seq -TCP_SKB_CB (skb)->seq; +if (WARN_ON_ONCE (offset > skb->len)) + goto out; -pr_debug ("discarding=%d len=%d seq=%d" , incr, skb->len, - subflow->map_subflow_seq); + avail_len = skb->len - offset; + incr = limit >= avail_len ? avail_len + fin : limit; + +pr_debug ("discarding=%d len=%d offset=%d seq=%d" , incr, skb->len, + offset, subflow->map_subflow_seq);MPTCP_INC_STATS (sock_net (ssk),MPTCP_MIB_DUPDATA );tcp_sk (ssk)->copied_seq += incr; + +out:if (!before (tcp_sk (ssk)->copied_seq,TCP_SKB_CB (skb)->end_seq))sk_eat_skb (ssk, skb);if (mptcp_subflow_get_map_offset (subflow) >= subflow->map_data_len)
Re: [PATCH 5.10 247/352] mptcp: fix duplicate data handling
Hi all,
Quoted 53 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit
68cc924729ffcfe90d0383177192030a9aeb2ee4upstream.When a subflow receives and discards duplicate data, the mptcp stack assumes that the consumed offset inside the current skb is zero.
With multiple subflows receiving data simultaneously such assertion does not held true. As a result the subflow-level
copied_seqwill be incorrectly increased and later on the same subflow will observe a bad mapping, leading to subflow reset.Address the issue taking into account the skb consumed offset in
mptcp_subflow_discard_data().Fixes 04e4cd4f7ca4 ("mptcp: cleanup mptcp_subflow_discard_data()")Signed-off-by Paolo Abeni <[email protected]>Reviewed-by Mat Martineau <[email protected]>Signed-off-by Matthieu Baerts (NGI0) <[email protected]>Signed-off-by Paolo Abeni <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- net/mptcp/subflow.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)net/mptcp/subflow.c +7
-4@@ -863,14 +863,22 @@ static void mptcp_subflow_discard_data(s {struct mptcp_subflow_context *subflow =mptcp_subflow_ctx (ssk);bool fin =TCP_SKB_CB (skb)->tcp_flags &TCPHDR_FIN ; -u32 incr; +struct tcp_sock *tp =tcp_sk (ssk); +u32 offset, incr, avail_len; - incr = limit >= skb->len ? skb->len + fin : limit; + offset = tp->copied_seq -TCP_SKB_CB (skb)->seq; +if (WARN_ON_ONCE (offset > skb->len)) + goto out; -pr_debug ("discarding=%d len=%d seq=%d" , incr, skb->len, - subflow->map_subflow_seq); + avail_len = skb->len - offset; + incr = limit >= avail_len ? avail_len + fin : limit;
net/mptcp/subflow.c static void mptcp_subflow_discard_data(s · line 884
Quoted 10 lines
net/mptcp/subflow.c +5
-0+ +pr_debug ("discarding=%d len=%d offset=%d seq=%d" , incr, skb->len, + offset, subflow->map_subflow_seq);MPTCP_INC_STATS (sock_net (ssk),MPTCP_MIB_DUPDATA );tcp_sk (ssk)->copied_seq += incr; + +out:if (!before (tcp_sk (ssk)->copied_seq,TCP_SKB_CB (skb)->end_seq))sk_eat_skb (ssk, skb);if (mptcp_subflow_get_map_offset (subflow) >= subflow->map_data_len)
This change in 5.10 appears to introduce an instance of -Wsometimes-uninitialized because 5.10 does not include commit ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling"), which removed the use of incr in the error path added by this change:
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 LLVM_IAS=1 mrproper allmodconfig net/mptcp/subflow.o
net/mptcp/subflow.c:877:6: warning: variable 'incr' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
877 | if (WARN_ON_ONCE(offset > skb->len))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:101:33: note: expanded from macro 'WARN_ON_ONCE'
101 | #define WARN_ON_ONCE(condition) ({ \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
102 | int __ret_warn_on = !!(condition); \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103 | if (unlikely(__ret_warn_on)) \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
104 | __WARN_FLAGS(BUGFLAG_ONCE | \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
105 | BUGFLAG_TAINT(TAINT_WARN)); \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
106 | unlikely(__ret_warn_on); \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
107 | })
| ~~
net/mptcp/subflow.c:893:6: note: uninitialized use occurs here
893 | if (incr)
| ^~~~
net/mptcp/subflow.c:877:2: note: remove the 'if' if its condition is always false
877 | if (WARN_ON_ONCE(offset > skb->len))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
878 | goto out;
| ~~~~~~~~
net/mptcp/subflow.c:874:18: note: initialize the variable 'incr' to silence this warning
874 | u32 offset, incr, avail_len;
| ^
| = 0
1 warning generated.That change does not really look suitable for stable (unless folks feel otherwise), so maybe a stable only patch to adddress this is in order?
Sorry for the delay in reporting this, I guess I do not build older stable releases as often as I should.
Cheers,
Nathan
Re: [PATCH 5.10 247/352] mptcp: fix duplicate data handling
Hi Nathan,
Quoted 22 lines · Nathan Chancellor
Hi all,
Quoted 19 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit
68cc924729ffcfe90d0383177192030a9aeb2ee4upstream.When a subflow receives and discards duplicate data, the mptcp stack assumes that the consumed offset inside the current skb is zero.
With multiple subflows receiving data simultaneously such assertion does not held true. As a result the subflow-level
copied_seqwill be incorrectly increased and later on the same subflow will observe a bad mapping, leading to subflow reset.Address the issue taking into account the skb consumed offset in
mptcp_subflow_discard_data().
(...)
Quoted 4 lines
This change in 5.10 appears to introduce an instance of -Wsometimes-uninitialized because 5.10 does not include commit
ea4ca586b16f("mptcp: refine MPTCP-level ack scheduling"), which removed the use of incr in the error path added by this change:
Thank you for having reported this issue!
Quoted 2 lines
That change does not really look suitable for stable (unless folks feel otherwise), so maybe a stable only patch to adddress this is in order?
Indeed, better to address this issue in a dedicated patch. This is what I did:
https://lore.kernel.org/[email protected]
Cheers,
Matt
Signature · 1 line
Sponsored by the NGI0 Core fund.
Greg Kroah-Hartman
maintainerPATCH 248/352 netfilter: ipset: Add list flush to cancel_gc
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Maltsev <[email protected]>
[ Upstream commit c1193d9bbbd379defe9be3c6de566de684de8a6f ]
Flushing list in cancel_gc drops references to other lists right away, without waiting for RCU to destroy list. Fixes race when referenced ipsets can't be destroyed while referring list is scheduled for destroy.
--- net/netfilter/ipset/ip_set_list_set.c | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/ipset/ip_set_list_set.c +3 -0
@@ -547,6 +547,9 @@ list_set_cancel_gc(struct ip_set *set)if (SET_WITH_TIMEOUT (set))del_timer_sync (&map->gc); + +/* Flush list to drop references to other ipsets */ +list_set_flush (set); }static const struct ip_set_type_variant set_variant = {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 249/352 genirq: Allow irq_chip registration functions to take a const irq_chip
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
[ Upstream commit 393e1280f765661cf39785e967676a4e57324126 ]
In order to let a const irqchip be fed to the irqchip layer, adjust the various prototypes. An extra cast in irq_set_chip()() is required to avoid a warning.
--- include/linux/irq.h | 7 ++++--- kernel/irq/chip.c | 9 +++------ 2 files changed, 7 insertions(+), 9 deletions(-)
include/linux/irq.h +4 -3
@@ -708,10 +708,11 @@ extern struct irq_chip no_irq_chip;extern struct irq_chip dummy_irq_chip;extern void -irq_set_chip_and_handler_name (unsigned int irq,struct irq_chip *chip, +irq_set_chip_and_handler_name (unsigned int irq,const struct irq_chip *chip,irq_flow_handler_t handle,const char *name); -static inline void irq_set_chip_and_handler (unsigned int irq,struct irq_chip *chip, +static inline void irq_set_chip_and_handler (unsigned int irq, +const struct irq_chip *chip,irq_flow_handler_t handle) {irq_set_chip_and_handler_name (irq, chip, handle,NULL );
@@ -801,7 +802,7 @@ static inline void irq_set_percpu_devid_flags(unsigned int irq) }/* Set/get chip/data for an IRQ: */ -extern int irq_set_chip (unsigned int irq,struct irq_chip *chip); +extern int irq_set_chip (unsigned int irq,const struct irq_chip *chip);extern int irq_set_handler_data (unsigned int irq,void *data);extern int irq_set_chip_data (unsigned int irq,void *data);extern int irq_set_irq_type (unsigned int irq,unsigned int type);
kernel/irq/chip.c +3 -6
@@ -38,7 +38,7 @@ struct irqaction chained_action = {* @irq: irq number * @chip: pointer to irq chip description structure */ -int irq_set_chip (unsigned int irq,struct irq_chip *chip) +int irq_set_chip (unsigned int irq,const struct irq_chip *chip) {unsigned long flags;struct irq_desc *desc =irq_get_desc_lock (irq, &flags,0 );
@@ -46,10 +46,7 @@ int irq_set_chip(unsigned int irq, struct irq_chip *chip)if (!desc)return -EINVAL ; -if (!chip) - chip = &no_irq_chip; - - desc->irq_data.chip = chip; + desc->irq_data.chip = (struct irq_chip *)(chip ?: &no_irq_chip);irq_put_desc_unlock (desc, flags);/* * For !CONFIG_SPARSE_IRQ make the irq show up in
@@ -1102,7 +1099,7 @@ irq_set_chained_handler_and_data(unsigned int irq, irq_flow_handler_t handle,EXPORT_SYMBOL_GPL (irq_set_chained_handler_and_data);void -irq_set_chip_and_handler_name (unsigned int irq,struct irq_chip *chip, +irq_set_chip_and_handler_name (unsigned int irq,const struct irq_chip *chip,irq_flow_handler_t handle,const char *name) {irq_set_chip (irq, chip);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 250/352 irqchip/mbigen: Fix mbigen node address layout
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yipeng Zou <[email protected]>
[ Upstream commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ]
The mbigen interrupt chip has its per node registers located in a contiguous region of page sized chunks. The code maps them into virtual address space as a contiguous region and determines the address of a node by using the node ID as index.
mbigen chip
|-----------------|------------|--------------|
mgn_node_0 mgn_node_1 ... mgn_node_i
|--------------| |--------------| |----------------------|
[0x0000, 0x0x0FFF] [0x1000, 0x1FFF] [i*0x1000, (i+1)*0x1000 - 1]This works correctly up to 10 nodes, but then fails because the 11th's array slot is used for the MGN_CLEAR registers.
mbigen chip
|-----------|--------|--------|---------------|--------|
mgn_node_0 mgn_node_1 ... mgn_clear_register ... mgn_node_i
|-----------------|
[0xA000, 0xAFFF]Skip the MGN_CLEAR register space when calculating the offset for node IDs greater than or equal to ten.
--- drivers/irqchip/irq-mbigen.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
drivers/irqchip/irq-mbigen.c +16 -4
@@ -64,6 +64,20 @@ struct mbigen_device {void __iomem *base; }; +static inline unsigned int get_mbigen_node_offset (unsigned int nid) +{ +unsigned int offset = nid *MBIGEN_NODE_OFFSET ; + +/* +* To avoid touched clear register in unexpected way, we need to directly +* skip clear register when access to more than 10 mbigen nodes. +*/ +if (nid >= (REG_MBIGEN_CLEAR_OFFSET /MBIGEN_NODE_OFFSET )) + offset +=MBIGEN_NODE_OFFSET ; + +return offset; +} +static inline unsigned int get_mbigen_vec_reg (irq_hw_number_t hwirq) {unsigned int nid, pin;
@@ -72,8 +86,7 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq) nid = hwirq /IRQS_PER_MBIGEN_NODE +1 ; pin = hwirq %IRQS_PER_MBIGEN_NODE ; -return pin *4 + nid *MBIGEN_NODE_OFFSET - +REG_MBIGEN_VEC_OFFSET ; +return pin *4 +get_mbigen_node_offset (nid) +REG_MBIGEN_VEC_OFFSET ; } static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
@@ -88,8 +101,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq, *mask =1 << (irq_ofst %32 ); ofst = irq_ofst /32 *4 ; - *addr = ofst + nid *MBIGEN_NODE_OFFSET - +REG_MBIGEN_TYPE_OFFSET ; + *addr = ofst +get_mbigen_node_offset (nid) +REG_MBIGEN_TYPE_OFFSET ; } static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 251/352 x86/mm: Fix pti_clone_pgtable() alignment assumption
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
[ Upstream commit 41e71dbb0e0a0fe214545fe64af031303a08524c ]
Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard.
It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386.
These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text?
Use the correct increment form for addr to avoid alignment assumptions.
--- arch/x86/mm/pti.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/x86/mm/pti.c +3 -3
@@ -374,14 +374,14 @@ pti_clone_pgtable(unsigned long start, unsigned long end,*/ *target_pmd = *pmd; - addr +=PMD_SIZE ; + addr =round_up (addr +1 ,PMD_SIZE ); }else if (level ==PTI_CLONE_PTE ) {/* Walk the page-table down to the pte level */ pte =pte_offset_kernel (pmd, addr);if (pte_none (*pte)) { - addr +=PAGE_SIZE ; + addr =round_up (addr +1 ,PAGE_SIZE );continue ; }
@@ -401,7 +401,7 @@ pti_clone_pgtable(unsigned long start, unsigned long end,/* Clone the PTE */ *target_pte = *pte; - addr +=PAGE_SIZE ; + addr =round_up (addr +1 ,PAGE_SIZE ); }else {BUG ();
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 252/352 x86/mm: Fix pti_clone_entry_text() for i386
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
[ Upstream commit 3db03fb4995ef85fc41e86262ead7b4852f4bcf0 ]
While x86_64 has PMD aligned text sections, i386 does not have this luxery. Notably ALIGN_ENTRY_TEXT_END is empty and _etext has PAGE alignment.
This means that text on i386 can be page granular at the tail end, which in turn means that the PTI text clones should consistently account for this.
Make pti_clone_entry_text() consistent with pti_clone_kernel_text().
--- arch/x86/mm/pti.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/mm/pti.c +1 -1
@@ -497,7 +497,7 @@ static void pti_clone_entry_text(void) {pti_clone_pgtable ((unsigned long ) __entry_text_start, (unsigned long ) __entry_text_end, -PTI_CLONE_PMD ); +PTI_LEVEL_KERNEL_IMAGE ); }/*
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 253/352 sctp: move hlist_node and hashent out of sctp_ep_common
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ Upstream commit 3d3b2f57d4447e6e9f4096ad01d0e4129f7bc7e9 ]
Struct sctp_ep_common is included in both asoc and ep, but hlist_node and hashent are only needed by ep after asoc_hashtable was dropped by Commit b5eff7128366 ("sctp: drop the old assoc hashtable of sctp").
So it is better to move hlist_node and hashent from sctp_ep_common to sctp_endpoint, and it saves some space for each asoc.
Stable-dep-of: 9ab0faa7f9ff ("sctp: Fix null-ptr-deref in reuseport_add_sock().")
--- include/net/sctp/sctp.h | 4 ++-- include/net/sctp/structs.h | 8 ++++---- net/sctp/input.c | 27 ++++++++++----------------- net/sctp/proc.c | 10 ++++------ net/sctp/socket.c | 6 +++--- 5 files changed, 23 insertions(+), 32 deletions(-)
include/net/sctp/sctp.h +2 -2
@@ -506,8 +506,8 @@ static inline int sctp_ep_hashfn(struct net *net, __u16 lport)return (net_hash_mix (net) + lport) & (sctp_ep_hashsize -1 ); } -#define sctp_for_each_hentry (epb, head) \ - hlist_for_each_entry(epb, head, node) +#define sctp_for_each_hentry (ep, head) \ + hlist_for_each_entry(ep, head, node)/* Is a socket of this style? */ #define sctp_style (sk, style) __sctp_style((sk), (SCTP_SOCKET_##style))
include/net/sctp/structs.h +4 -4
@@ -1218,10 +1218,6 @@ enum sctp_endpoint_type {*/ struct sctp_ep_common { -/* Fields to help us manage our entries in the hash tables. */ -struct hlist_node node; -int hashent; -/* Runtime type information. What kind of endpoint is this? */ enum sctp_endpoint_type type;
@@ -1273,6 +1269,10 @@ struct sctp_endpoint {/* Common substructure for endpoint and association. */ struct sctp_ep_common base; +/* Fields to help us manage our entries in the hash tables. */ +struct hlist_node node; +int hashent; +/* Associations: A list of current associations and mappings * to the data consumers for each association. This * may be in the form of a hash table or other
net/sctp/input.c +10 -17
@@ -723,23 +723,21 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep)struct sock *sk = ep->base.sk;struct net *net =sock_net (sk);struct sctp_hashbucket *head; -struct sctp_ep_common *epb; - epb = &ep->base; - epb->hashent =sctp_ep_hashfn (net, epb->bind_addr.port); - head = &sctp_ep_hashtable[epb->hashent]; + ep->hashent =sctp_ep_hashfn (net, ep->base.bind_addr.port); + head = &sctp_ep_hashtable[ep->hashent];if (sk->sk_reuseport) {bool any =sctp_is_ep_boundall (sk); -struct sctp_ep_common *epb2; +struct sctp_endpoint *ep2;struct list_head *list;int cnt =0 , err =1 ;list_for_each (list, &ep->base.bind_addr.address_list) cnt++; -sctp_for_each_hentry (epb2, &head->chain) { -struct sock *sk2 = epb2->sk; +sctp_for_each_hentry (ep2, &head->chain) { +struct sock *sk2 = ep2->base.sk; if (!net_eq(sock_net(sk2), net) || sk2 == sk || !uid_eq(sock_i_uid(sk2), sock_i_uid(sk)) ||
@@ -766,7 +764,7 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep) }write_lock (&head->lock); -hlist_add_head (&epb->node, &head->chain); +hlist_add_head (&ep->node, &head->chain);write_unlock (&head->lock);return 0 ; }
@@ -788,19 +786,16 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep) {struct sock *sk = ep->base.sk;struct sctp_hashbucket *head; -struct sctp_ep_common *epb; - epb = &ep->base; + ep->hashent =sctp_ep_hashfn (sock_net (sk), ep->base.bind_addr.port); - epb->hashent =sctp_ep_hashfn (sock_net (sk), epb->bind_addr.port); - - head = &sctp_ep_hashtable[epb->hashent]; + head = &sctp_ep_hashtable[ep->hashent];if (rcu_access_pointer (sk->sk_reuseport_cb))reuseport_detach_sock (sk);write_lock (&head->lock); -hlist_del_init (&epb->node); +hlist_del_init (&ep->node);write_unlock (&head->lock); }
@@ -833,7 +828,6 @@ static struct sctp_endpoint *__sctp_rcv_lookup_endpoint( const union sctp_addr *paddr) {struct sctp_hashbucket *head; -struct sctp_ep_common *epb;struct sctp_endpoint *ep;struct sock *sk;__be16 lport;
@@ -843,8 +837,7 @@ static struct sctp_endpoint *__sctp_rcv_lookup_endpoint( hash =sctp_ep_hashfn (net,ntohs (lport)); head = &sctp_ep_hashtable[hash];read_lock (&head->lock); -sctp_for_each_hentry (epb, &head->chain) { - ep =sctp_ep (epb); +sctp_for_each_hentry (ep, &head->chain) {if (sctp_endpoint_is_match (ep, net, laddr)) goto hit; }
net/sctp/proc.c +4 -6
@@ -161,7 +161,6 @@ static void *sctp_eps_seq_next(struct seq_file *seq, void *v, loff_t *pos)static int sctp_eps_seq_show (struct seq_file *seq,void *v) {struct sctp_hashbucket *head; -struct sctp_ep_common *epb;struct sctp_endpoint *ep;struct sock *sk;int hash = *(loff_t *)v;
@@ -171,18 +170,17 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v) head = &sctp_ep_hashtable[hash];read_lock_bh (&head->lock); -sctp_for_each_hentry (epb, &head->chain) { - ep =sctp_ep (epb); - sk = epb->sk; +sctp_for_each_hentry (ep, &head->chain) { + sk = ep->base.sk;if (!net_eq (sock_net (sk),seq_file_net (seq)))continue ;seq_printf (seq,"%8pK %8pK %-3d %-3d %-4d %-5d %5u %5lu " , ep, sk,sctp_sk (sk)->type, sk->sk_state, hash, - epb->bind_addr.port, + ep->base.bind_addr.port,from_kuid_munged (seq_user_ns (seq),sock_i_uid (sk)),sock_i_ino (sk)); -sctp_seq_dump_local_addrs (seq, epb); +sctp_seq_dump_local_addrs (seq, &ep->base);seq_printf (seq,"\n" ); }read_unlock_bh (&head->lock);
net/sctp/socket.c +3 -3
@@ -5193,14 +5193,14 @@ int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *), void *p) {int err =0 ;int hash =0 ; -struct sctp_ep_common *epb; +struct sctp_endpoint *ep;struct sctp_hashbucket *head;for (head = sctp_ep_hashtable; hash < sctp_ep_hashsize; hash++, head++) {read_lock_bh (&head->lock); -sctp_for_each_hentry (epb, &head->chain) { - err =cb (sctp_ep (epb), p); +sctp_for_each_hentry (ep, &head->chain) { + err =cb (ep, p);if (err)break ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 254/352 sctp: Fix null-ptr-deref in reuseport_add_sock().
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 9ab0faa7f9ffe31296dbb9bbe6f76c72c14eea18 ]
syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in reuseport_add_sock(). [0]
The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener.
The second listen() calls reuseport_add_sock() with the first listener as sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, but the close() does clear it by reuseport_detach_sock().
The problem is SCTP does not properly synchronise reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock().
The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must provide synchronisation for sockets that are classified into the same reuseport group.
Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead.
1. Two sockets call listen() concurrently
2. No socket in the same group found in sctp_ep_hashtable[]
3. Two sockets call reuseport_alloc() and form two reuseport groups
4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packets
Also, the reported null-ptr-deref could occur.
TCP/UDP guarantees that would not happen by holding the hash bucket lock.
Let's apply the locking strategy to __sctp_hash_endpoint() and __sctp_unhash_endpoint().
[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: 00007f24e465a5dc R14: 0020000000000001 R15: 00007ffcced5f7d8 </TASK> Modules linked in:
--- net/sctp/input.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
net/sctp/input.c +11 -8
@@ -723,15 +723,19 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep)struct sock *sk = ep->base.sk;struct net *net =sock_net (sk);struct sctp_hashbucket *head; +int err =0 ; ep->hashent =sctp_ep_hashfn (net, ep->base.bind_addr.port); head = &sctp_ep_hashtable[ep->hashent]; +write_lock (&head->lock);if (sk->sk_reuseport) {bool any =sctp_is_ep_boundall (sk);struct sctp_endpoint *ep2;struct list_head *list; -int cnt =0 , err =1 ; +int cnt =0 ; + + err =1 ;list_for_each (list, &ep->base.bind_addr.address_list) cnt++;
@@ -749,24 +753,24 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep)if (!err) { err =reuseport_add_sock (sk, sk2, any);if (err) -return err; + goto out;break ; }else if (err <0 ) { -return err; + goto out; } }if (err) { err =reuseport_alloc (sk, any);if (err) -return err; + goto out; } } -write_lock (&head->lock);hlist_add_head (&ep->node, &head->chain); +out:write_unlock (&head->lock); -return 0 ; +return err; }/* Add an endpoint to the hash. Local BH-safe. */
@@ -791,10 +795,9 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep) head = &sctp_ep_hashtable[ep->hashent]; +write_lock (&head->lock);if (rcu_access_pointer (sk->sk_reuseport_cb))reuseport_detach_sock (sk); - -write_lock (&head->lock);hlist_del_init (&ep->node);write_unlock (&head->lock); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 255/352 net: usb: qmi_wwan: fix memory leak for not ip packets
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniele Palmas <[email protected]>
[ Upstream commit 7ab107544b777c3bd7feb9fe447367d8edd5b202 ]
Free the unused skb when not ip packets arrive.
--- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/usb/qmi_wwan.c +1 -0
@@ -216,6 +216,7 @@ static int qmimux_rx_fixup(struct usbnet *dev, struct sk_buff *skb)break ;default :/* not ip - do not know what to do */ +kfree_skb (skbn); goto skip; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 256/352 net: linkwatch: use system_unbound_wq
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 3e7917c0cdad835a5121520fc5686d954b7a61ab ]
linkwatch_event() grabs possibly very contended RTNL mutex.
system_wq is not suitable for such work.
Inspired by many noisy syzbot reports.
3 locks held by kworker/0:7/5266:
#0: ffff888015480948 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3206 [inline] #0: ffff888015480948 ((wq_completion)events){+.+.}-{0:0}, at: process_scheduled_works+0x90a/0x1830 kernel/workqueue.c:3312 #1: ffffc90003f6fd00 ((linkwatch_work).work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3207 [inline] , at: process_scheduled_works+0x945/0x1830 kernel/workqueue.c:3312
#2: ffffffff8fa6f208 (rtnl_mutex){+.+.}-{3:3}, at: linkwatch_event+0xe/0x60 net/core/link_watch.c:276
--- net/core/link_watch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/core/link_watch.c +2 -2
@@ -138,9 +138,9 @@ static void linkwatch_schedule_work(int urgent)* override the existing timer. */ if (test_bit (LW_URGENT , &linkwatch_flags)) -mod_delayed_work (system_wq, &linkwatch_work,0 ); +mod_delayed_work (system_unbound_wq, &linkwatch_work,0 );else -schedule_delayed_work (&linkwatch_work, delay); +queue_delayed_work (system_unbound_wq, &linkwatch_work, delay); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 257/352 Bluetooth: l2cap: always unlock channel in l2cap_conless_channel()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Antipov <[email protected]>
[ Upstream commit c531e63871c0b50c8c4e62c048535a08886fba3e ]
Add missing call to 'l2cap_chan_unlock()' on receive error handling path in 'l2cap_conless_channel()'.
--- net/bluetooth/l2cap_core.c | 1 + 1 file changed, 1 insertion(+)
net/bluetooth/l2cap_core.c +1 -0
@@ -7762,6 +7762,7 @@ static void l2cap_conless_channel(struct l2cap_conn *conn, __le16 psm,bt_cb (skb)->l2cap.psm = psm;if (!chan->ops->recv (chan, skb)) { +l2cap_chan_unlock (chan);l2cap_chan_put (chan);return ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 258/352 net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Hattori <[email protected]>
[ Upstream commit e3862093ee93fcfbdadcb7957f5f8974fffa806a ]
bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak.
This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount.
--- drivers/net/dsa/bcm_sf2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/dsa/bcm_sf2.c +3 -1
@@ -558,8 +558,10 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)of_remove_property (child, prop); phydev =of_phy_find_device (child); -if (phydev) +if (phydev) {phy_device_remove (phydev); +phy_device_free (phydev); + } } err =mdiobus_register (priv->slave_mii_bus);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 259/352 l2tp: fix lockdep splat
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Chapman <[email protected]>
[ Upstream commit 86a41ea9fd79ddb6145cb8ebf5aeafceabca6f7d ]
When l2tp tunnels use a socket provided by userspace, we can hit lockdep splats like the below when data is transmitted through another (unrelated) userspace socket which then gets routed over l2tp.
This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/
The solution is to have lockdep treat socket locks of l2tp tunnel sockets separately than those of standard INET sockets. To do so, use a different lockdep subclass where lock nesting is possible.
============================================
WARNING: possible recursive locking detected
6.10.0+ #34 Not tainted
--------------------------------------------
iperf3/771 is trying to acquire lock:
ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0
but task is already holding lock:
ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(slock-AF_INET/1);
lock(slock-AF_INET/1);*** DEADLOCK ***
May be due to missing lock nesting notation
10 locks held by iperf3/771:
#0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
#1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
#2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
#3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
#4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
#5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450
stack backtrace: CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x69/0xa0 dump_stack+0xc/0x20 __lock_acquire+0x135d/0x2600 ? srso_alias_return_thunk+0x5/0xfbef5 lock_acquire+0xc4/0x2a0 ? l2tp_xmit_skb+0x243/0x9d0 ? __skb_checksum+0xa3/0x540 _raw_spin_lock_nested+0x35/0x50 ? l2tp_xmit_skb+0x243/0x9d0 l2tp_xmit_skb+0x243/0x9d0 l2tp_eth_dev_xmit+0x3c/0xc0 dev_hard_start_xmit+0x11e/0x420 sch_direct_xmit+0xc3/0x640 __dev_queue_xmit+0x61c/0x1450 ? ip_finish_output2+0xf4c/0x1130 ip_finish_output2+0x6b6/0x1130 ? srso_alias_return_thunk+0x5/0xfbef5 ? __ip_finish_output+0x217/0x380 ? srso_alias_return_thunk+0x5/0xfbef5 __ip_finish_output+0x217/0x380 ip_output+0x99/0x120 __ip_queue_xmit+0xae4/0xbc0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? tcp_options_write.constprop.0+0xcb/0x3e0 ip_queue_xmit+0x34/0x40 __tcp_transmit_skb+0x1625/0x1890 __tcp_send_ack+0x1b8/0x340 tcp_send_ack+0x23/0x30 __tcp_ack_snd_check+0xa8/0x530 ? srso_alias_return_thunk+0x5/0xfbef5 tcp_rcv_established+0x412/0xd70 tcp_v4_do_rcv+0x299/0x420 tcp_v4_rcv+0x1991/0x1e10 ip_protocol_deliver_rcu+0x50/0x220 ip_local_deliver_finish+0x158/0x260 ip_local_deliver+0xc8/0xe0 ip_rcv+0xe5/0x1d0 ? __pfx_ip_rcv+0x10/0x10 __netif_receive_skb_one_core+0xce/0xe0 ? process_backlog+0x28b/0x9f0 __netif_receive_skb+0x34/0xd0 ? process_backlog+0x28b/0x9f0 process_backlog+0x2cb/0x9f0 __napi_poll.constprop.0+0x61/0x280 net_rx_action+0x332/0x670 ? srso_alias_return_thunk+0x5/0xfbef5 ? find_held_lock+0x2b/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 handle_softirqs+0xda/0x480 ? __dev_queue_xmit+0xa2c/0x1450 do_softirq+0xa1/0xd0 </IRQ> <TASK> __local_bh_enable_ip+0xc8/0xe0 ? __dev_queue_xmit+0xa2c/0x1450 __dev_queue_xmit+0xa48/0x1450 ? ip_finish_output2+0xf4c/0x1130 ip_finish_output2+0x6b6/0x1130 ? srso_alias_return_thunk+0x5/0xfbef5 ? __ip_finish_output+0x217/0x380 ? srso_alias_return_thunk+0x5/0xfbef5 __ip_finish_output+0x217/0x380 ip_output+0x99/0x120 __ip_queue_xmit+0xae4/0xbc0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? tcp_options_write.constprop.0+0xcb/0x3e0 ip_queue_xmit+0x34/0x40 __tcp_transmit_skb+0x1625/0x1890 tcp_write_xmit+0x766/0x2fb0 ? __entry_text_end+0x102ba9/0x102bad ? srso_alias_return_thunk+0x5/0xfbef5 ? __might_fault+0x74/0xc0 ? srso_alias_return_thunk+0x5/0xfbef5 __tcp_push_pending_frames+0x56/0x190 tcp_push+0x117/0x310 tcp_sendmsg_locked+0x14c1/0x1740 tcp_sendmsg+0x28/0x40 inet_sendmsg+0x5d/0x90 sock_write_iter+0x242/0x2b0 vfs_write+0x68d/0x800 ? __pfx_sock_write_iter+0x10/0x10 ksys_write+0xc8/0xf0 __x64_sys_write+0x3d/0x50 x64_sys_call+0xfaf/0x1f50 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4d143af992 Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0 RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992 RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005 RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0 </TASK>
--- net/l2tp/l2tp_core.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
net/l2tp/l2tp_core.c +13 -2
@@ -88,6 +88,11 @@/* Default trace flags */ #define L2TP_DEFAULT_DEBUG_FLAGS 0 +#define L2TP_DEPTH_NESTING 2 +#if L2TP_DEPTH_NESTING ==SINGLE_DEPTH_NESTING +#error "L2TP requires its own lockdep subclass" +#endif +/* Private data stored for received packets in the skb. */ struct l2tp_skb_cb {
@@ -1041,7 +1046,13 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, unsIPCB (skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE |IPSKB_XFRM_TRANSFORMED |IPSKB_REROUTED );nf_reset_ct (skb); -bh_lock_sock_nested (sk); +/* L2TP uses its own lockdep subclass to avoid lockdep splats caused by +* nested socket calls on the same lockdep socket class. This can +* happen when data from a user socket is routed over l2tp, which uses +* another userspace socket. +*/ +spin_lock_nested (&sk->sk_lock.slock,L2TP_DEPTH_NESTING ); +if (sock_owned_by_user (sk)) {kfree_skb (skb); ret =NET_XMIT_DROP ;
@@ -1093,7 +1104,7 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, uns ret =l2tp_xmit_queue (tunnel, skb, &inet->cork.fl); out_unlock: -bh_unlock_sock (sk); +spin_unlock (&sk->sk_lock.slock);return ret; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 260/352 net: fec: Stop PPS on driver remove
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Csókás, Bence <[email protected]>
[ Upstream commit 8fee6d5ad5fa18c270eedb2a2cdf58dbadefb94b ]
PPS was not stopped in fec_ptp_stop(), called when the adapter was removed. Consequentially, you couldn't safely reload the driver with the PPS signal on.
--- drivers/net/ethernet/freescale/fec_ptp.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/freescale/fec_ptp.c +3 -0
@@ -640,6 +640,9 @@ void fec_ptp_stop(struct platform_device *pdev)struct net_device *ndev =platform_get_drvdata (pdev);struct fec_enet_private *fep =netdev_priv (ndev); +if (fep->pps_enable) +fec_ptp_enable_pps (fep,0 ); +cancel_delayed_work_sync (&fep->time_keep);if (fep->ptp_clock)ptp_clock_unregister (fep->ptp_clock);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 261/352 rcutorture: Fix rcu_torture_fwd_cb_cr() data race
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul E. McKenney <[email protected]>
[ Upstream commit 6040072f4774a575fa67b912efe7722874be337b ]
On powerpc systems, spinlock acquisition does not order prior stores against later loads. This means that this statement:
rfcp->rfc_next = NULL;
Can be reordered to follow this statement:
WRITE_ONCE(*rfcpp, rfcp);
Which is then a data race with rcu_torture_fwd_prog_cr(), specifically, this statement:
rfcpn = READ_ONCE(rfcp->rfc_next)
KCSAN located this data race, which represents a real failure on powerpc.
--- kernel/rcu/rcutorture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/rcu/rcutorture.c +1 -1
@@ -1867,7 +1867,7 @@ static void rcu_torture_fwd_cb_cr(struct rcu_head *rhp)spin_lock_irqsave (&rfp->rcu_fwd_lock, flags); rfcpp = rfp->rcu_fwd_cb_tail; rfp->rcu_fwd_cb_tail = &rfcp->rfc_next; -WRITE_ONCE (*rfcpp, rfcp); +smp_store_release (rfcpp, rfcp);WRITE_ONCE (rfp->n_launders_cb, rfp->n_launders_cb +1 ); i = ((jiffies - rfp->rcu_fwd_startat) / (HZ /FWD_CBS_HIST_DIV ));if (i >=ARRAY_SIZE (rfp->n_launders_hist))
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 262/352 md: do not delete safemode_timer in mddev_suspend
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Nan <[email protected]>
[ Upstream commit a8768a134518e406d41799a3594aeb74e0889cf7 ]
The deletion of safemode_timer in mddev_suspend() is redundant and potentially harmful now. If timer is about to be woken up but gets deleted, 'in_sync' will remain 0 until the next write, causing array to stay in the 'active' state instead of transitioning to 'clean'.
Commit 0d9f4f135eb6 ("MD: Add del_timer_sync to mddev_suspend (fix nasty panic))" introduced this deletion for dm, because if timer fired after dm is destroyed, the resource which the timer depends on might have been freed.
However, commit 0dd84b319352 ("md: call __md_stop_writes in md_stop") added __md_stop_writes() to md_stop(), which is called before freeing resource. Timer is deleted in __md_stop_writes(), and the origin issue is resolved. Therefore, delete safemode_timer can be removed safely now.
--- drivers/md/md.c | 1 - 1 file changed, 1 deletion(-)
drivers/md/md.c +0 -1
@@ -524,7 +524,6 @@ void mddev_suspend(struct mddev *mddev)clear_bit_unlock (MD_ALLOW_SB_UPDATE , &mddev->flags);wait_event (mddev->sb_wait, !test_bit (MD_UPDATING_SB , &mddev->flags)); -del_timer_sync (&mddev->safemode_timer);/* restrict memory reclaim I/O during raid array is suspend */ mddev->noio_flag =memalloc_noio_save (); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 263/352 md/raid5: avoid BUG_ON() while continue reshape after reassembling
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <[email protected]>
[ Upstream commit 305a5170dc5cf3d395bb4c4e9239bca6d0b54b49 ]
Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test:
kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace: <TASK> raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 </TASK>
Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail.
Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail.
Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata.
--- drivers/md/raid5.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-)
drivers/md/raid5.c +13 -7
@@ -6005,7 +6005,9 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk safepos = conf->reshape_safe;sector_div (safepos, data_disks);if (mddev->reshape_backwards) { -BUG_ON (writepos < reshape_sectors); +if (WARN_ON (writepos < reshape_sectors)) +return MaxSector; + writepos -= reshape_sectors; readpos += reshape_sectors; safepos += reshape_sectors;
@@ -6023,14 +6025,18 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk* to set 'stripe_addr' which is where we will write to. */ if (mddev->reshape_backwards) { -BUG_ON (conf->reshape_progress ==0 ); +if (WARN_ON (conf->reshape_progress ==0 )) +return MaxSector; + stripe_addr = writepos; -BUG_ON ((mddev->dev_sectors & - ~((sector_t )reshape_sectors -1 )) - - reshape_sectors - stripe_addr - != sector_nr); +if (WARN_ON ((mddev->dev_sectors & + ~((sector_t )reshape_sectors -1 )) - + reshape_sectors - stripe_addr != sector_nr)) +return MaxSector; }else { -BUG_ON (writepos != sector_nr + reshape_sectors); +if (WARN_ON (writepos != sector_nr + reshape_sectors)) +return MaxSector; + stripe_addr = sector_nr; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 264/352 clocksource/drivers/sh_cmt: Address race condition for clock events
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Söderlund <[email protected]>
[ Upstream commit db19d3aa77612983a02bd223b3f273f896b243cf ]
There is a race condition in the CMT interrupt handler. In the interrupt handler the driver sets a driver private flag, FLAG_IRQCONTEXT. This flag is used to indicate any call to set_next_event() should not be directly propagated to the device, but instead cached. This is done as the interrupt handler itself reprograms the device when needed before it completes and this avoids this operation to take place twice.
It is unclear why this design was chosen, my suspicion is to allow the struct clock_event_device.event_handler callback, which is called while the FLAG_IRQCONTEXT is set, can update the next event without having to write to the device twice.
Unfortunately there is a race between when the FLAG_IRQCONTEXT flag is set and later cleared where the interrupt handler have already started to write the next event to the device. If set_next_event() is called in this window the value is only cached in the driver but not written. This leads to the board to misbehave, or worse lockup and produce a splat.
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 0-...!: (0 ticks this GP) idle=f5e0/0/0x0 softirq=519/519 fqs=0 (false positive?)
rcu: (detected by 1, t=6502 jiffies, g=-595, q=77 ncpus=2)
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.10.0-rc5-arm64-renesas-00019-g74a6f86eaf1c-dirty #20
Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : tick_check_broadcast_expired+0xc/0x40
lr : cpu_idle_poll.isra.0+0x8c/0x168
sp : ffff800081c63d70
x29: ffff800081c63d70 x28: 00000000580000c8 x27: 00000000bfee5610
x26: 0000000000000027 x25: 0000000000000000 x24: 0000000000000000
x23: ffff00007fbb9100 x22: ffff8000818f1008 x21: ffff8000800ef07c
x20: ffff800081c79ec0 x19: ffff800081c70c28 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffc2c717d8
x14: 0000000000000000 x13: ffff000009c18080 x12: ffff8000825f7fc0
x11: 0000000000000000 x10: ffff8000818f3cd4 x9 : 0000000000000028
x8 : ffff800081c79ec0 x7 : ffff800081c73000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : ffff7ffffe286000 x3 : 0000000000000000
x2 : ffff7ffffe286000 x1 : ffff800082972900 x0 : ffff8000818f1008
Call trace:
tick_check_broadcast_expired+0xc/0x40
do_idle+0x9c/0x280
cpu_startup_entry+0x34/0x40
kernel_init+0x0/0x11c
do_one_initcall+0x0/0x260
__primary_switched+0x80/0x88
rcu: rcu_preempt kthread timer wakeup didn't happen for 6501 jiffies! g-595 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: Possible timer handling issue on cpu=0 timer-softirq=262
rcu: rcu_preempt kthread starved for 6502 jiffies! g-595 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 flags:0x00000008
Call trace:
__switch_to+0xbc/0x100
__schedule+0x358/0xbe0
schedule+0x48/0x148
schedule_timeout+0xc4/0x138
rcu_gp_fqs_loop+0x12c/0x764
rcu_gp_kthread+0x208/0x298
kthread+0x10c/0x110
ret_from_fork+0x10/0x20The design have been part of the driver since it was first merged in early 2009. It becomes increasingly harder to trigger the issue the older kernel version one tries. It only takes a few boots on v6.10-rc5, while hundreds of boots are needed to trigger it on v5.10.
Close the race condition by using the CMT channel lock for the two competing sections. The channel lock was added to the driver after its initial design.
--- drivers/clocksource/sh_cmt.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/clocksource/sh_cmt.c +12 -1
@@ -530,6 +530,7 @@ static void sh_cmt_set_next(struct sh_cmt_channel *ch, unsigned long delta)static irqreturn_t sh_cmt_interrupt (int irq,void *dev_id) {struct sh_cmt_channel *ch = dev_id; +unsigned long flags;/* clear flags */ sh_cmt_write_cmcsr(ch, sh_cmt_read_cmcsr(ch) &
@@ -560,6 +561,8 @@ static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id) ch->flags &= ~FLAG_SKIPEVENT ; +raw_spin_lock_irqsave (&ch->lock, flags); +if (ch->flags &FLAG_REPROGRAM ) { ch->flags &= ~FLAG_REPROGRAM ;sh_cmt_clock_event_program_verify (ch,1 );
@@ -572,6 +575,8 @@ static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id) ch->flags &= ~FLAG_IRQCONTEXT ; +raw_spin_unlock_irqrestore (&ch->lock, flags); +return IRQ_HANDLED ; }
@@ -770,12 +775,18 @@ static int sh_cmt_clock_event_next(unsigned long delta, struct clock_event_device *ced) {struct sh_cmt_channel *ch =ced_to_sh_cmt (ced); +unsigned long flags;BUG_ON (!clockevent_state_oneshot (ced)); + +raw_spin_lock_irqsave (&ch->lock, flags); +if (likely (ch->flags &FLAG_IRQCONTEXT )) ch->next_match_value = delta -1 ;else -sh_cmt_set_next (ch, delta -1 ); +__sh_cmt_set_next (ch, delta -1 ); + +raw_spin_unlock_irqrestore (&ch->lock, flags);return 0 ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 265/352 ACPI: battery: create alarm sysfs attribute atomically
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weißschuh <[email protected]>
[ Upstream commit a231eed10ed5a290129fda36ad7bcc263c53ff7d ]
Let the power supply core register the attribute. This ensures that the attribute is created before the device is announced to userspace, avoid a race condition.
--- drivers/acpi/battery.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
drivers/acpi/battery.c +12 -4
@@ -670,12 +670,18 @@ static ssize_t acpi_battery_alarm_store(struct device *dev,return count; } -static const struct device_attribute alarm_attr = { +static struct device_attribute alarm_attr = { .attr = {.name ="alarm" , .mode =0644 }, .show = acpi_battery_alarm_show, .store = acpi_battery_alarm_store, }; +static struct attribute *acpi_battery_attrs[] = { + &alarm_attr.attr, +NULL +}; +ATTRIBUTE_GROUPS (acpi_battery); +/* * The Battery Hooking API *
@@ -812,7 +818,10 @@ static void __exit battery_hook_exit(void)static int sysfs_add_battery (struct acpi_battery *battery) { -struct power_supply_config psy_cfg = { .drv_data = battery, }; +struct power_supply_config psy_cfg = { + .drv_data = battery, + .attr_grp = acpi_battery_groups, + };bool full_cap_broken = false; if (!ACPI_BATTERY_CAPACITY_VALID(battery->full_charge_capacity) &&
@@ -857,7 +866,7 @@ static int sysfs_add_battery(struct acpi_battery *battery)return result; }battery_hook_add_battery (battery); -return device_create_file (&battery->bat->dev, &alarm_attr); +return 0 ; }static void sysfs_remove_battery (struct acpi_battery *battery)
@@ -868,7 +877,6 @@ static void sysfs_remove_battery(struct acpi_battery *battery)return ; }battery_hook_remove_battery (battery); -device_remove_file (&battery->bat->dev, &alarm_attr);power_supply_unregister (battery->bat); battery->bat =NULL ;mutex_unlock (&battery->sysfs_lock);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 266/352 ACPI: SBS: manage alarm sysfs attribute through psy core
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weißschuh <[email protected]>
[ Upstream commit 6bad28cfc30988a845fb3f59a99f4b8a4ce8fe95 ]
Let the power supply core register the attribute.
This ensures that the attribute is created before the device is announced to userspace, avoiding a race condition.
--- drivers/acpi/sbs.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)
drivers/acpi/sbs.c +12 -11
@@ -77,7 +77,6 @@ struct acpi_battery {u16 spec;u8 id; u8 present:1; - u8 have_sysfs_alarm:1; };#define to_acpi_battery (x) power_supply_get_drvdata(x)
@@ -462,12 +461,18 @@ static ssize_t acpi_battery_alarm_store(struct device *dev,return count; } -static const struct device_attribute alarm_attr = { +static struct device_attribute alarm_attr = { .attr = {.name ="alarm" , .mode =0644 }, .show = acpi_battery_alarm_show, .store = acpi_battery_alarm_store, }; +static struct attribute *acpi_battery_attrs[] = { + &alarm_attr.attr, +NULL +}; +ATTRIBUTE_GROUPS (acpi_battery); +/* -------------------------------------------------------------------------- Driver Interface -------------------------------------------------------------------------- */
@@ -509,7 +514,10 @@ static int acpi_battery_read(struct acpi_battery *battery)static int acpi_battery_add (struct acpi_sbs *sbs,int id) {struct acpi_battery *battery = &sbs->battery[id]; -struct power_supply_config psy_cfg = { .drv_data = battery, }; +struct power_supply_config psy_cfg = { + .drv_data = battery, + .attr_grp = acpi_battery_groups, + };int result; battery->id = id;
@@ -539,10 +547,6 @@ static int acpi_battery_add(struct acpi_sbs *sbs, int id) goto end; } - result =device_create_file (&battery->bat->dev, &alarm_attr); -if (result) - goto end; - battery->have_sysfs_alarm =1 ; end: printk(KERN_INFO PREFIX "%s [%s]: Battery Slot [%s] (battery %s)\n", ACPI_SBS_DEVICE_NAME, acpi_device_bid(sbs->device),
@@ -554,11 +558,8 @@ static void acpi_battery_remove(struct acpi_sbs *sbs, int id) {struct acpi_battery *battery = &sbs->battery[id]; -if (battery->bat) { -if (battery->have_sysfs_alarm) -device_remove_file (&battery->bat->dev, &alarm_attr); +if (battery->bat)power_supply_unregister (battery->bat); - } }static int acpi_charger_add (struct acpi_sbs *sbs)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 267/352 selftests/bpf: Fix send_signal test with nested CONFIG_PARAVIRT
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yonghong Song <[email protected]>
[ Upstream commit 7015843afcaf68c132784c89528dfddc0005e483 ]
Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue.
The main qemu command line includes:
-enable-kvm -smp 16 -cpu host
The failure log looks like:
$ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty #69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK>
In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe.
The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed.
In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well.
[1] https://lore.kernel.org/bpf/[email protected]/
--- tools/testing/selftests/bpf/prog_tests/send_signal.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
tools/testing/selftests/bpf/prog_tests/send_signal.c +2 -1
@@ -155,7 +155,8 @@ static void test_send_signal_tracepoint(bool signal_thread)static void test_send_signal_perf (bool signal_thread) {struct perf_event_attr attr = { - .sample_period =1 , + .freq =1 , + .sample_freq =1000 , .type =PERF_TYPE_SOFTWARE , .config =PERF_COUNT_SW_CPU_CLOCK , };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 268/352 PCI: Add Edimax Vendor ID to pci_ids.h
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: FUJITA Tomonori <[email protected]>
[ Upstream commit eee5528890d54b22b46f833002355a5ee94c3bb4 ]
Add the Edimax Vendor ID (0x1432) for an ethernet driver for Tehuti Networks TN40xx chips. This ID can be used for Realtek 8180 and Ralink rt28xx wireless drivers.
--- include/linux/pci_ids.h | 2 ++ 1 file changed, 2 insertions(+)
include/linux/pci_ids.h +2 -0
@@ -2137,6 +2137,8 @@#define PCI_VENDOR_ID_CHELSIO 0x1425 +#define PCI_VENDOR_ID_EDIMAX 0x1432 +#define PCI_VENDOR_ID_ADLINK 0x144a#define PCI_VENDOR_ID_SAMSUNG 0x144d
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 269/352 udf: prevent integer overflow in udf_bitmap_free_blocks()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Smirnov <[email protected]>
[ Upstream commit 56e69e59751d20993f243fb7dd6991c4e522424c ]
An overflow may occur if the function is called with the last block and an offset greater than zero. It is necessary to add a check to avoid this.
Found by Linux Verification Center (linuxtesting.org) with Svace.
[JK: Make test cover also unalloc table freeing]
--- fs/udf/balloc.c | 36 +++++++++++++----------------------- 1 file changed, 13 insertions(+), 23 deletions(-)
fs/udf/balloc.c +13 -23
@@ -22,6 +22,7 @@#include "udfdecl.h" #include <linux/bitops.h> +#include <linux/overflow.h> #include "udf_i.h" #include "udf_sb.h"
@@ -144,7 +145,6 @@ static void udf_bitmap_free_blocks(struct super_block *sb, {struct udf_sb_info *sbi =UDF_SB (sb);struct buffer_head *bh =NULL ; -struct udf_part_map *partmap;unsigned long block;unsigned long block_group;unsigned long bit;
@@ -153,19 +153,9 @@ static void udf_bitmap_free_blocks(struct super_block *sb,unsigned long overflow;mutex_lock (&sbi->s_alloc_mutex); - partmap = &sbi->s_partmaps[bloc->partitionReferenceNum]; -if (bloc->logicalBlockNum + count < count || - (bloc->logicalBlockNum + count) > partmap->s_partition_len) { -udf_debug ("%u < %d || %u + %u > %u\n" , - bloc->logicalBlockNum,0 , - bloc->logicalBlockNum, count, - partmap->s_partition_len); - goto error_return; - } - +/* We make sure this cannot overflow when mounting the filesystem */ block = bloc->logicalBlockNum + offset + (sizeof (struct spaceBitmapDesc ) <<3 ); - do { overflow = 0; block_group = block >> (sb->s_blocksize_bits + 3);
@@ -395,7 +385,6 @@ static void udf_table_free_blocks(struct super_block *sb, uint32_t count) {struct udf_sb_info *sbi =UDF_SB (sb); -struct udf_part_map *partmap;uint32_t start, end;uint32_t elen;struct kernel_lb_addr eloc;
@@ -404,16 +393,6 @@ static void udf_table_free_blocks(struct super_block *sb,struct udf_inode_info *iinfo;mutex_lock (&sbi->s_alloc_mutex); - partmap = &sbi->s_partmaps[bloc->partitionReferenceNum]; -if (bloc->logicalBlockNum + count < count || - (bloc->logicalBlockNum + count) > partmap->s_partition_len) { -udf_debug ("%u < %d || %u + %u > %u\n" , - bloc->logicalBlockNum,0 , - bloc->logicalBlockNum, count, - partmap->s_partition_len); - goto error_return; - } - iinfo =UDF_I (table);udf_add_free_space (sb, sbi->s_partition, count);
@@ -688,6 +667,17 @@ void udf_free_blocks(struct super_block *sb, struct inode *inode, {uint16_t partition = bloc->partitionReferenceNum;struct udf_part_map *map = &UDF_SB (sb)->s_partmaps[partition]; +uint32_t blk; + +if (check_add_overflow (bloc->logicalBlockNum, offset, &blk) || +check_add_overflow (blk, count, &blk) || + bloc->logicalBlockNum + count > map->s_partition_len) { +udf_debug ("Invalid request to free blocks: (%d, %u), off %u, " +"len %u, partition len %u\n" , + partition, bloc->logicalBlockNum, offset, count, + map->s_partition_len); +return ; + }if (map->s_partition_flags &UDF_PART_FLAG_UNALLOC_BITMAP ) { udf_bitmap_free_blocks(sb, map->s_uspace.s_bitmap,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 270/352 wifi: nl80211: dont give key data to userspace
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ Upstream commit a7e5793035792cc46a1a4b0a783655ffa897dfe9 ]
When a key is requested by userspace, there's really no need to include the key data, the sequence counter is really what userspace needs in this case. The fact that it's included is just a historic quirk.
Remove the key data.
--- net/wireless/nl80211.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
net/wireless/nl80211.c +2 -8
@@ -3968,10 +3968,7 @@ static void get_key_callback(void *c, struct key_params *params)struct nlattr *key;struct get_key_cookie *cookie = c; - if ((params->key && - nla_put(cookie->msg, NL80211_ATTR_KEY_DATA, - params->key_len, params->key)) || - (params->seq && + if ((params->seq && nla_put(cookie->msg, NL80211_ATTR_KEY_SEQ, params->seq_len, params->seq)) || (params->cipher &&
@@ -3983,10 +3980,7 @@ static void get_key_callback(void *c, struct key_params *params)if (!key) goto nla_put_failure; - if ((params->key && - nla_put(cookie->msg, NL80211_KEY_DATA, - params->key_len, params->key)) || - (params->seq && + if ((params->seq && nla_put(cookie->msg, NL80211_KEY_SEQ, params->seq_len, params->seq)) || (params->cipher &&
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 271/352 btrfs: fix bitmap leak when loading free space cache on duplicate entry
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
[ Upstream commit 320d8dc612660da84c3b70a28658bb38069e5a9a ]
If we failed to link a free space entry because there's already a conflicting entry for the same offset, we free the free space entry but we don't free the associated bitmap that we had just allocated before. Fix that by freeing the bitmap before freeing the entry.
--- fs/btrfs/free-space-cache.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/free-space-cache.c +1 -0
@@ -798,6 +798,7 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode,spin_unlock (&ctl->tree_lock);btrfs_err (fs_info,"Duplicate entries in free space cache, dumping" ); +kmem_cache_free (btrfs_free_space_bitmap_cachep, e->bitmap);kmem_cache_free (btrfs_free_space_cachep, e); goto free_cache; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 272/352 drm/amdgpu: Fix the null pointer dereference to ras_manager
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Jun <[email protected]>
[ Upstream commit 4c11d30c95576937c6c35e6f29884761f2dddb43 ]
Check ras_manager before using it
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +5 -2
@@ -1351,12 +1351,15 @@ static void amdgpu_ras_interrupt_process_handler(struct work_struct *work)int amdgpu_ras_interrupt_dispatch (struct amdgpu_device *adev,struct ras_dispatch_if *info) { -struct ras_manager *obj =amdgpu_ras_find_obj (adev, &info->head); -struct ras_ih_data *data = &obj->ih_data; +struct ras_manager *obj; +struct ras_ih_data *data; + obj =amdgpu_ras_find_obj (adev, &info->head);if (!obj)return -EINVAL ; + data = &obj->ih_data; +if (data->inuse ==0 )return 0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 273/352 drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Jun <[email protected]>
[ Upstream commit d19fb10085a49b77578314f69fff21562f7cd054 ]
Check the pointer value to fix potential null pointer dereference
--- .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 7 +++++-- .../gpu/drm/amd/pm/powerplay/hwmgr/smu8_hwmgr.c | 14 ++++++++------ .../gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 7 +++++-- 3 files changed, 18 insertions(+), 10 deletions(-)
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c +5 -2
@@ -2983,8 +2983,7 @@ static int smu7_apply_state_adjust_rules(struct pp_hwmgr *hwmgr, const struct pp_power_state *current_ps) {struct amdgpu_device *adev = hwmgr->adev; -struct smu7_power_state *smu7_ps = -cast_phw_smu7_power_state (&request_ps->hardware); +struct smu7_power_state *smu7_ps;uint32_t sclk;uint32_t mclk;struct PP_Clocks minimum_clocks = {0 };
@@ -2998,6 +2997,10 @@ static int smu7_apply_state_adjust_rules(struct pp_hwmgr *hwmgr,int32_t count;int32_t stable_pstate_sclk =0 , stable_pstate_mclk =0 ; + smu7_ps =cast_phw_smu7_power_state (&request_ps->hardware); +if (!smu7_ps) +return -EINVAL ; + data->battery_state = (PP_StateUILabel_Battery == request_ps->classification.ui_label);
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu8_hwmgr.c +8 -6
@@ -1051,16 +1051,18 @@ static int smu8_apply_state_adjust_rules(struct pp_hwmgr *hwmgr,struct pp_power_state *prequest_ps, const struct pp_power_state *pcurrent_ps) { - struct smu8_power_state *smu8_ps = -cast_smu8_power_state (&prequest_ps->hardware); - -const struct smu8_power_state *smu8_current_ps = -cast_const_smu8_power_state (&pcurrent_ps->hardware); - + struct smu8_power_state *smu8_ps; +const struct smu8_power_state *smu8_current_ps;struct smu8_hwmgr *data = hwmgr->backend;struct PP_Clocks clocks = {0 ,0 ,0 ,0 };bool force_high; + smu8_ps =cast_smu8_power_state (&prequest_ps->hardware); + smu8_current_ps =cast_const_smu8_power_state (&pcurrent_ps->hardware); + +if (!smu8_ps || !smu8_current_ps) +return -EINVAL ; + smu8_ps->need_dfs_bypass = true; data->battery_state = (PP_StateUILabel_Battery == prequest_ps->classification.ui_label);
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c +5 -2
@@ -3232,8 +3232,7 @@ static int vega10_apply_state_adjust_rules(struct pp_hwmgr *hwmgr, const struct pp_power_state *current_ps) {struct amdgpu_device *adev = hwmgr->adev; -struct vega10_power_state *vega10_ps = -cast_phw_vega10_power_state (&request_ps->hardware); +struct vega10_power_state *vega10_ps;uint32_t sclk;uint32_t mclk;struct PP_Clocks minimum_clocks = {0 };
@@ -3251,6 +3250,10 @@ static int vega10_apply_state_adjust_rules(struct pp_hwmgr *hwmgr,uint32_t stable_pstate_sclk =0 , stable_pstate_mclk =0 ;uint32_t latency; + vega10_ps =cast_phw_vega10_power_state (&request_ps->hardware); +if (!vega10_ps) +return -EINVAL ; + data->battery_state = (PP_StateUILabel_Battery == request_ps->classification.ui_label);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 274/352 media: uvcvideo: Ignore empty TS packets
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo Ribalda <[email protected]>
[ Upstream commit 5cd7c25f6f0576073b3d03bc4cfb1e8ca63a1195 ]
Some SunplusIT cameras took a borderline interpretation of the UVC 1.5 standard, and fill the PTS and SCR fields with invalid data if the package does not contain data.
"STC must be captured when the first video data of a video frame is put on the USB bus."
Some SunplusIT devices send, e.g.,
buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
buffer: 0xa7755c00 len 000668 header:0x8c stc 73779dba sof 070c pts 7376d37a
While the UVC specification meant that the first two packets shouldn't have had the SCR bit set in the header.
This borderline/buggy interpretation has been implemented in a variety of devices, from directly SunplusIT and from other OEMs that rebrand SunplusIT products. So quirking based on VID:PID will be problematic.
All the affected modules have the following extension unit:
VideoControl Interface Descriptor:
guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d}
But the vendor plans to use that GUID in the future and fix the bug, this means that we should use heuristic to figure out the broken packets.
This patch takes care of this.
lsusb of one of the affected cameras:
Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc. Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.01
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1bcf Sunplus Innovation Technology Inc.
idProduct 0x2a01
bcdDevice 0.02
iManufacturer 1 SunplusIT Inc iProduct 2 HanChen Wise Camera iSerial 3 01.00.00 bNumConfigurations 1
--- drivers/media/usb/uvc/uvc_video.c | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-)
drivers/media/usb/uvc/uvc_video.c +30 -1
@@ -468,6 +468,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,ktime_t time;u16 host_sof;u16 dev_sof; +u32 dev_stc;switch (data[1 ] & (UVC_STREAM_PTS |UVC_STREAM_SCR )) {case UVC_STREAM_PTS |UVC_STREAM_SCR :
@@ -512,6 +513,34 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,if (dev_sof == stream->clock.last_sof)return ; + dev_stc =get_unaligned_le32 (&data[header_size -6 ]); + +/* +* STC (Source Time Clock) is the clock used by the camera. The UVC 1.5 +* standard states that it "must be captured when the first video data +* of a video frame is put on the USB bus". This is generally understood +* as requiring devices to clear the payload header's SCR bit before +* the first packet containing video data. +* +* Most vendors follow that interpretation, but some (namely SunplusIT +* on some devices) always set the `UVC_STREAM_SCR` bit, fill the SCR +* field with 0's,and expect that the driver only processes the SCR if +* there is data in the packet. +* +* Ignore all the hardware timestamp information if we haven't received +* any data for this frame yet, the packet contains no data, and both +* STC and SOF are zero. This heuristics should be safe on compliant +* devices. This should be safe with compliant devices, as in the very +* unlikely case where a UVC 1.1 device would send timing information +* only before the first packet containing data, and both STC and SOF +* happen to be zero for a particular frame, we would only miss one +* clock sample from many and the clock recovery algorithm wouldn't +* suffer from this condition. +*/ +if (buf && buf->bytesused ==0 && len == header_size && + dev_stc ==0 && dev_sof ==0 ) +return ; + stream->clock.last_sof = dev_sof; host_sof =usb_get_current_frame_number (stream->dev->udev);
@@ -549,7 +578,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,spin_lock_irqsave (&stream->clock.lock, flags); sample = &stream->clock.samples[stream->clock.head]; - sample->dev_stc =get_unaligned_le32 (&data[header_size -6 ]); + sample->dev_stc = dev_stc; sample->dev_sof = dev_sof; sample->host_sof = host_sof; sample->host_time = time;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 275/352 media: uvcvideo: Fix the bandwdith quirk on USB 3.x
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Pecio <[email protected]>
[ Upstream commit 9e3d55fbd160b3ca376599a68b4cddfdc67d4153 ]
The bandwidth fixup quirk doesn't know that SuperSpeed exists and has the same 8 service intervals per millisecond as High Speed, hence its calculations are wrong.
Assume that all speeds from HS up use 8 intervals per millisecond.
No further changes are needed, updated code has been confirmed to work with all speeds from FS to SS.
--- drivers/media/usb/uvc/uvc_video.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/media/usb/uvc/uvc_video.c +3 -3
@@ -207,13 +207,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,/* Compute a bandwidth estimation by multiplying the frame * size by the number of video frames per second, divide the * result by the number of USB frames (or micro-frames for -* high-speed devices) per second and add the UVC header size -* (assumed to be 12 bytes long). +* high- and super-speed devices) per second and add the UVC +* header size (assumed to be 12 bytes long). */ bandwidth = frame->wWidth * frame->wHeight /8 * format->bpp; bandwidth *=10000000 / interval +1 ; bandwidth /=1000 ; -if (stream->dev->udev->speed ==USB_SPEED_HIGH ) +if (stream->dev->udev->speed >=USB_SPEED_HIGH ) bandwidth /=8 ; bandwidth +=12 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 276/352 jbd2: avoid memleak in jbd2_journal_write_metadata_buffer
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kemeng Shi <[email protected]>
[ Upstream commit cc102aa24638b90e04364d64e4f58a1fa91a1976 ]
The new_bh is from alloc_buffer_head, we should call free_buffer_head to free it in error case.
--- fs/jbd2/journal.c | 1 + 1 file changed, 1 insertion(+)
fs/jbd2/journal.c +1 -0
@@ -412,6 +412,7 @@ int jbd2_journal_write_metadata_buffer(transaction_t *transaction, tmp =jbd2_alloc (bh_in->b_size,GFP_NOFS );if (!tmp) {brelse (new_bh); +free_buffer_head (new_bh);return -ENOMEM ; }spin_lock (&jh_in->b_state_lock);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 277/352 s390/sclp: Prevent release of buffer in I/O
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Oberparleiter <[email protected]>
[ Upstream commit bf365071ea92b9579d5a272679b74052a5643e35 ]
When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.
Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.
--- drivers/s390/char/sclp_sd.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/s390/char/sclp_sd.c +8 -2
@@ -319,8 +319,14 @@ static int sclp_sd_store_data(struct sclp_sd_data *result, u8 di) &esize);if (rc) {/* Cancel running request if interrupted */ -if (rc == -ERESTARTSYS ) -sclp_sd_sync (page,SD_EQ_HALT , di,0 ,0 ,NULL ,NULL ); +if (rc == -ERESTARTSYS ) { +if (sclp_sd_sync (page,SD_EQ_HALT , di,0 ,0 ,NULL ,NULL )) { +pr_warn ("Could not stop Store Data request - leaking at least %zu bytes\n" , + (size_t )dsize *PAGE_SIZE ); + data =NULL ; + asce =0 ; + } + }vfree (data); goto out; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 278/352 SUNRPC: Fix a race to wake a sync task
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Coddington <[email protected]>
[ Upstream commit ed0172af5d6fc07d1b40ca82f5ca3979300369f7 ]
We've observed NFS clients with sync tasks sleeping in __rpc_execute waiting on RPC_TASK_QUEUED that have not responded to a wake-up from rpc_make_runnable(). I suspect this problem usually goes unnoticed, because on a busy client the task will eventually be re-awoken by another task completion or xprt event. However, if the state manager is draining the slot table, a sync task missing a wake-up can result in a hung client.
We've been able to prove that the waker in rpc_make_runnable() successfully calls wake_up_bit() (ie- there's no race to tk_runstate), but the wake_up_bit() call fails to wake the waiter. I suspect the waker is missing the load of the bit's wait_queue_head, so waitqueue_active() is false. There are some very helpful comments about this problem above wake_up_bit(), prepare_to_wait(), and waitqueue_active().
Fix this by inserting smp_mb__after_atomic() before the wake_up_bit(), which pairs with prepare_to_wait() calling set_current_state().
--- net/sunrpc/sched.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/sunrpc/sched.c +3 -1
@@ -348,8 +348,10 @@ static void rpc_make_runnable(struct workqueue_struct *wq,if (RPC_IS_ASYNC (task)) {INIT_WORK (&task->u.tk_work, rpc_async_schedule);queue_work (wq, &task->u.tk_work); - }else + }else { +smp_mb__after_atomic ();wake_up_bit (&task->tk_runstate,RPC_TASK_QUEUED ); + } }/*
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 279/352 sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheng Zucheng <[email protected]>
commit 77baa5bafcbe1b2a15ef9c37232c21279c95481c upstream.
In extreme test scenarios:
the 14th field utime in /proc/xx/stat is greater than sum_exec_runtime, utime = 18446744073709518790 ns, rtime = 135989749728000 ns
In cputime_adjust() process, stime is greater than rtime due to mul_u64_u64_div_u64() precision problem.
before call mul_u64_u64_div_u64(),
stime = 175136586720000, rtime = 135989749728000, utime = 1416780000. after call mul_u64_u64_div_u64(),
stime = 135989949653530
unsigned reversion occurs because rtime is less than stime. utime = rtime - stime = 135989749728000 - 135989949653530
= -199925530 = (u64)18446744073709518790
Trigger condition:
1). User task run in kernel mode most of time 2). ARM64 architecture
3). TICK_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
Fix mul_u64_u64_div_u64() conversion precision by reset stime to rtime
--- kernel/sched/cputime.c | 6 ++++++ 1 file changed, 6 insertions(+)
kernel/sched/cputime.c +6 -0
@@ -579,6 +579,12 @@ void cputime_adjust(struct task_cputime } stime =mul_u64_u64_div_u64 (stime, rtime, stime + utime); +/* +* Because mul_u64_u64_div_u64() can approximate on some +* achitectures; enforce the constraint that: a*b/(b+c) <= a. +*/ +if (unlikely (stime > rtime)) + stime = rtime; update:/*
Greg Kroah-Hartman
maintainerPATCH 280/352 ext4: fix wrong unit use in ext4_mb_find_by_goal
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kemeng Shi <[email protected]>
[ Upstream commit 99c515e3a860576ba90c11acbc1d6488dfca6463 ]
We need start in block unit while fe_start is in cluster unit. Use ext4_grp_offs_to_block helper to convert fe_start to get start in block unit.
--- fs/ext4/mballoc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/ext4/mballoc.c +1 -2
@@ -1927,8 +1927,7 @@ int ext4_mb_find_by_goal(struct ext4_allocation_context *ac,if (max >= ac->ac_g_ex.fe_len && ac->ac_g_ex.fe_len == sbi->s_stripe) {ext4_fsblk_t start; - start =ext4_group_first_block_no (ac->ac_sb, e4b->bd_group) + - ex.fe_start; + start =ext4_grp_offs_to_block (ac->ac_sb, &ex);/* use do_div to get remainder (would be 64-bit modulo) */ if (do_div (start, sbi->s_stripe) ==0 ) { ac->ac_found++;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 281/352 arm64: cpufeature: Force HWCAP to be based on the sysreg visible to user-space
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
[ Upstream commit 237405ebef580a7352a52129b2465c117145eafa ]
arm64 advertises hardware features to user-space via HWCAPs, and by emulating access to the CPUs id registers. The cpufeature code has a sanitised system-wide view of an id register, and a sanitised user-space view of an id register, where some features use their 'safe' value instead of the hardware value.
It is currently possible for a HWCAP to be advertised where the user-space view of the id register does not show the feature as supported. Erratum workaround need to remove both the HWCAP, and the feature from the user-space view of the id register. This involves duplicating the code, and spreading it over cpufeature.c and cpu_errata.c.
Make the HWCAP code use the user-space view of id registers. This ensures the values never diverge, and allows erratum workaround to remove HWCAP by modifying the user-space view of the id register.
--- arch/arm64/kernel/cpufeature.c | 36 +++++++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 7 deletions(-)
arch/arm64/kernel/cpufeature.c +29 -7
@@ -1196,17 +1196,39 @@ feature_matches(u64 reg, const struct arm64_cpu_capabilities *entry)return val >= entry->min_field_value; } -static bool -has_cpuid_feature (const struct arm64_cpu_capabilities *entry,int scope) +static u64 +read_scoped_sysreg (const struct arm64_cpu_capabilities *entry,int scope) { -u64 val; -WARN_ON (scope ==SCOPE_LOCAL_CPU &&preemptible ());if (scope ==SCOPE_SYSTEM ) - val =read_sanitised_ftr_reg (entry->sys_reg); +return read_sanitised_ftr_reg (entry->sys_reg);else - val =__read_sysreg_by_encoding (entry->sys_reg); +return __read_sysreg_by_encoding (entry->sys_reg); +} + +static bool +has_user_cpuid_feature (const struct arm64_cpu_capabilities *entry,int scope) +{ +int mask; +struct arm64_ftr_reg *regp; +u64 val =read_scoped_sysreg (entry, scope); + + regp =get_arm64_ftr_reg (entry->sys_reg); +if (!regp) +return false; + + mask =cpuid_feature_extract_unsigned_field (regp->user_mask, + entry->field_pos); +if (!mask) +return false; + +return feature_matches (val, entry); +} +static bool +has_cpuid_feature (const struct arm64_cpu_capabilities *entry,int scope) +{ +u64 val =read_scoped_sysreg (entry, scope);return feature_matches (val, entry); }
@@ -2172,7 +2194,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = { };#define HWCAP_CPUID_MATCH (reg, field, s, min_value) \ - .matches = has_cpuid_feature, \ + .matches = has_user_cpuid_feature, \ .sys_reg = reg, \ .field_pos = field, \ .sign = s, \
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 282/352 arm64: Add Neoverse-V2 part
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Besar Wicaksono <[email protected]>
[ Upstream commit f4d9d9dcc70b96b5e5d7801bd5fbf8491b07b13d ]
Add the part number and MIDR for Neoverse-V2
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -84,6 +84,7 @@#define ARM_CPU_PART_CORTEX_X2 0xD48#define ARM_CPU_PART_NEOVERSE_N2 0xD49#define ARM_CPU_PART_CORTEX_A78C 0xD4B +#define ARM_CPU_PART_NEOVERSE_V2 0xD4F#define APM_CPU_PART_POTENZA 0x000
@@ -136,6 +137,7 @@#define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2)#define MIDR_NEOVERSE_N2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N2)#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C) +#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2)#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 283/352 arm64: cputype: Add Cortex-X4 definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 02a0a04676fa7796d9cbc9eb5ca120aaa194d2dd ]
Add cputype definitions for Cortex-X4. These will be used for errata detection in subsequent patches.
These values can be found in Table B-249 ("MIDR_EL1 bit descriptions") in issue 0002-05 of the Cortex-X4 TRM, which can be found at:
https://developer.arm.com/documentation/102484/0002/?lang=en
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -85,6 +85,7 @@#define ARM_CPU_PART_NEOVERSE_N2 0xD49#define ARM_CPU_PART_CORTEX_A78C 0xD4B#define ARM_CPU_PART_NEOVERSE_V2 0xD4F +#define ARM_CPU_PART_CORTEX_X4 0xD82#define APM_CPU_PART_POTENZA 0x000
@@ -138,6 +139,7 @@#define MIDR_NEOVERSE_N2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N2)#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C)#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2) +#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4)#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 284/352 arm64: cputype: Add Neoverse-V3 definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 0ce85db6c2141b7ffb95709d76fc55a27ff3cdc1 ]
Add cputype definitions for Neoverse-V3. These will be used for errata detection in subsequent patches.
These values can be found in Table B-249 ("MIDR_EL1 bit descriptions") in issue 0001-04 of the Neoverse-V3 TRM, which can be found at:
https://developer.arm.com/documentation/107734/0001/?lang=en
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -86,6 +86,7 @@#define ARM_CPU_PART_CORTEX_A78C 0xD4B#define ARM_CPU_PART_NEOVERSE_V2 0xD4F#define ARM_CPU_PART_CORTEX_X4 0xD82 +#define ARM_CPU_PART_NEOVERSE_V3 0xD84#define APM_CPU_PART_POTENZA 0x000
@@ -140,6 +141,7 @@#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C)#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2)#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4) +#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 285/352 arm64: errata: Add workaround for Arm errata 3194386 and 3312417
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 7187bb7d0b5c7dfa18ca82e9e5c75e13861b1d88 ]
Cortex-X4 and Neoverse-V3 suffer from errata whereby an MSR to the SSBS special-purpose register does not affect subsequent speculative instructions, permitting speculative store bypassing for a window of time. This is described in their Software Developer Errata Notice (SDEN) documents:
* Cortex-X4 SDEN v8.0, erratum 3194386:
https://developer.arm.com/documentation/SDEN-2432808/0800/
* Neoverse-V3 SDEN v6.0, erratum 3312417:
https://developer.arm.com/documentation/SDEN-2891958/0600/
To workaround these errata, it is necessary to place a speculation barrier (SB) after MSR to the SSBS special-purpose register. This patch adds the requisite SB after writes to SSBS within the kernel, and hides the presence of SSBS from EL0 such that userspace software which cares about SSBS will manipulate this via prctl(PR_GET_SPECULATION_CTRL, ...).
--- Documentation/arm64/silicon-errata.rst | 4 +++ arch/arm64/Kconfig | 41 ++++++++++++++++++++++++++ arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/kernel/cpu_errata.c | 19 ++++++++++++ arch/arm64/kernel/cpufeature.c | 12 ++++++++ arch/arm64/kernel/proton-pack.c | 12 ++++++++ 6 files changed, 90 insertions(+), 1 deletion(-)
Documentation/arm64/silicon-errata.rst +4 -0
@@ -98,12 +98,16 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1349291 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3312417 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+
arch/arm64/Kconfig +41 -0
47 lines not on this page · raw message
arch/arm64/include/asm/cpucaps.h +2 -1
@@ -69,7 +69,8 @@#define ARM64_SPECTRE_BHB 59#define ARM64_WORKAROUND_2457168 60#define ARM64_WORKAROUND_1742098 61 +#define ARM64_WORKAROUND_SPECULATIVE_SSBS 62 -#define ARM64_NCAPS 62 +#define ARM64_NCAPS 63#endif /* __ASM_CPUCAPS_H */
arch/arm64/kernel/cpu_errata.c +19 -0
@@ -364,6 +364,18 @@ static struct midr_range broken_aarch32_aes[] = { };#endif +#ifdef CONFIG_ARM64_WORKAROUND_SPECULATIVE_SSBS +static const struct midr_range erratum_spec_ssbs_list[] = { +#ifdef CONFIG_ARM64_ERRATUM_3194386 +MIDR_ALL_VERSIONS (MIDR_CORTEX_X4 ), +#endif +#ifdef CONFIG_ARM64_ERRATUM_3312417 +MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V3 ), +#endif + {} +}; +#endif + const struct arm64_cpu_capabilities arm64_errata[] = {#ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE {
@@ -570,6 +582,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = { CAP_MIDR_RANGE_LIST(broken_aarch32_aes), .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, }, +#endif +#ifdef CONFIG_ARM64_WORKAROUND_SPECULATIVE_SSBS + { + .desc = "ARM errata 3194386, 3312417", + .capability = ARM64_WORKAROUND_SPECULATIVE_SSBS, + ERRATA_MIDR_RANGE_LIST(erratum_spec_ssbs_list), + }, #endif { }
arch/arm64/kernel/cpufeature.c +12 -0
@@ -1753,6 +1753,17 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap) }#endif /* CONFIG_ARM64_MTE */ +static void user_feature_fixup (void ) +{ +if (cpus_have_cap (ARM64_WORKAROUND_SPECULATIVE_SSBS )) { +struct arm64_ftr_reg *regp; + + regp =get_arm64_ftr_reg (SYS_ID_AA64PFR1_EL1 ); +if (regp) + regp->user_mask &= ~GENMASK (7 ,4 );/* SSBS */ + } +} +static void elf_hwcap_fixup (void ) {#ifdef CONFIG_ARM64_ERRATUM_1742098
@@ -2764,6 +2775,7 @@ void __init setup_cpu_features(void)u32 cwg;setup_system_capabilities (); +user_feature_fixup ();setup_elf_hwcaps (arm64_elf_hwcaps);if (system_supports_32bit_el0 ()) {
arch/arm64/kernel/proton-pack.c +12 -0
@@ -574,6 +574,18 @@ static enum mitigation_state spectre_v4_enable_hw_mitigation(void)/* SCTLR_EL1.DSSBS was initialised to 0 during boot */ asm volatile(SET_PSTATE_SSBS(0)); + +/* +* SSBS is self-synchronizing and is intended to affect subsequent +* speculative instructions, but some CPUs can speculate with a stale +* value of SSBS. +* +* Mitigate this with an unconditional speculation barrier, as CPUs +* could mis-speculate branches and bypass a conditional barrier. +*/ +if (IS_ENABLED (CONFIG_ARM64_WORKAROUND_SPECULATIVE_SSBS )) +spec_bar (); +return SPECTRE_MITIGATED ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 286/352 arm64: cputype: Add Cortex-X3 definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit be5a6f238700f38b534456608588723fba96c5ab ]
Add cputype definitions for Cortex-X3. These will be used for errata detection in subsequent patches.
These values can be found in Table A-263 ("MIDR_EL1 bit descriptions") in issue 07 of the Cortex-X3 TRM, which can be found at:
https://developer.arm.com/documentation/101593/0102/?lang=en
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -84,6 +84,7 @@#define ARM_CPU_PART_CORTEX_X2 0xD48#define ARM_CPU_PART_NEOVERSE_N2 0xD49#define ARM_CPU_PART_CORTEX_A78C 0xD4B +#define ARM_CPU_PART_CORTEX_X3 0xD4E#define ARM_CPU_PART_NEOVERSE_V2 0xD4F#define ARM_CPU_PART_CORTEX_X4 0xD82#define ARM_CPU_PART_NEOVERSE_V3 0xD84
@@ -139,6 +140,7 @@#define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2)#define MIDR_NEOVERSE_N2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N2)#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C) +#define MIDR_CORTEX_X3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X3)#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2)#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4)#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 287/352 arm64: cputype: Add Cortex-A720 definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit add332c40328cf06fe35e4b3cde8ec315c4629e5 ]
Add cputype definitions for Cortex-A720. These will be used for errata detection in subsequent patches.
These values can be found in Table A-186 ("MIDR_EL1 bit descriptions") in issue 0002-05 of the Cortex-A720 TRM, which can be found at:
https://developer.arm.com/documentation/102530/0002/?lang=en
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -86,6 +86,7 @@#define ARM_CPU_PART_CORTEX_A78C 0xD4B#define ARM_CPU_PART_CORTEX_X3 0xD4E#define ARM_CPU_PART_NEOVERSE_V2 0xD4F +#define ARM_CPU_PART_CORTEX_A720 0xD81#define ARM_CPU_PART_CORTEX_X4 0xD82#define ARM_CPU_PART_NEOVERSE_V3 0xD84
@@ -142,6 +143,7 @@#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C)#define MIDR_CORTEX_X3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X3)#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2) +#define MIDR_CORTEX_A720 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720)#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4)#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 288/352 arm64: cputype: Add Cortex-X925 definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit fd2ff5f0b320f418288e7a1f919f648fbc8a0dfc ]
Add cputype definitions for Cortex-X925. These will be used for errata detection in subsequent patches.
These values can be found in Table A-285 ("MIDR_EL1 bit descriptions") in issue 0001-05 of the Cortex-X925 TRM, which can be found at:
https://developer.arm.com/documentation/102807/0001/?lang=en
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -89,6 +89,7 @@#define ARM_CPU_PART_CORTEX_A720 0xD81#define ARM_CPU_PART_CORTEX_X4 0xD82#define ARM_CPU_PART_NEOVERSE_V3 0xD84 +#define ARM_CPU_PART_CORTEX_X925 0xD85#define APM_CPU_PART_POTENZA 0x000
@@ -146,6 +147,7 @@#define MIDR_CORTEX_A720 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720)#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4)#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3) +#define MIDR_CORTEX_X925 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X925)#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 289/352 arm64: errata: Unify speculative SSBS errata logic
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit ec768766608092087dfb5c1fc45a16a6f524dee2 ]
Cortex-X4 erratum 3194386 and Neoverse-V3 erratum 3312417 are identical, with duplicate Kconfig text and some unsightly ifdeffery. While we try to share code behind CONFIG_ARM64_WORKAROUND_SPECULATIVE_SSBS, having separate options results in a fair amount of boilerplate code, and this will only get worse as we expand the set of affected CPUs.
To reduce this boilerplate, unify the two behind a common Kconfig option. This removes the duplicate text and Kconfig logic, and removes the need for the intermediate ARM64_WORKAROUND_SPECULATIVE_SSBS option. The set of affected CPUs is described as a list so that this can easily be extended.
I've used ARM64_ERRATUM_3194386 (matching the Neoverse-V3 erratum ID) as the common option, matching the way we use ARM64_ERRATUM_1319367 to cover Cortex-A57 erratum 1319537 and Cortex-A72 erratum 1319367.
--- Documentation/arm64/silicon-errata.rst | 2 +- arch/arm64/Kconfig | 28 ++++---------------------- arch/arm64/kernel/cpu_errata.c | 8 ++------ arch/arm64/kernel/proton-pack.c | 2 +- 4 files changed, 8 insertions(+), 32 deletions(-)
Documentation/arm64/silicon-errata.rst +1 -1
@@ -106,7 +106,7 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 | +----------------+-----------------+-----------------+-----------------------------+ -| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3312417 | +| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A | +----------------+-----------------+-----------------+-----------------------------+
arch/arm64/Kconfig +4 -24
@@ -691,34 +691,14 @@ config ARM64_ERRATUM_2457168 If unsure, say Y. -config ARM64_WORKAROUND_SPECULATIVE_SSBS - bool - config ARM64_ERRATUM_3194386 - bool "Cortex-X4: 3194386: workaround for MSR SSBS not self-synchronizing" - select ARM64_WORKAROUND_SPECULATIVE_SSBS + bool "Cortex-X4/Neoverse-V3: workaround for MSR SSBS not self-synchronizing" default y help - This option adds the workaround for ARM Cortex-X4 erratum 3194386. - - On affected cores "MSR SSBS, #0" instructions may not affect - subsequent speculative instructions, which may permit unexepected - speculative store bypassing. - - Work around this problem by placing a speculation barrier after - kernel changes to SSBS. The presence of the SSBS special-purpose - register is hidden from hwcaps and EL0 reads of ID_AA64PFR1_EL1, such - that userspace will use the PR_SPEC_STORE_BYPASS prctl to change - SSBS. + This option adds the workaround for the following errata: - If unsure, say Y. - -config ARM64_ERRATUM_3312417 - bool "Neoverse-V3: 3312417: workaround for MSR SSBS not self-synchronizing" - select ARM64_WORKAROUND_SPECULATIVE_SSBS - default y - help - This option adds the workaround for ARM Neoverse-V3 erratum 3312417. + * ARM Cortex-X4 erratum 3194386 + * ARM Neoverse-V3 erratum 3312417 On affected cores "MSR SSBS, #0" instructions may not affect subsequent speculative instructions, which may permit unexepected
arch/arm64/kernel/cpu_errata.c +2 -6
@@ -364,14 +364,10 @@ static struct midr_range broken_aarch32_aes[] = { };#endif -#ifdef CONFIG_ARM64_WORKAROUND_SPECULATIVE_SSBS -static const struct midr_range erratum_spec_ssbs_list[] = {#ifdef CONFIG_ARM64_ERRATUM_3194386 +static const struct midr_range erratum_spec_ssbs_list[] = {MIDR_ALL_VERSIONS (MIDR_CORTEX_X4 ), -#endif -#ifdef CONFIG_ARM64_ERRATUM_3312417MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V3 ), -#endif {} };#endif
@@ -583,7 +579,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = { .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, },#endif -#ifdef CONFIG_ARM64_WORKAROUND_SPECULATIVE_SSBS +#ifdef CONFIG_ARM64_ERRATUM_3194386 { .desc = "ARM errata 3194386, 3312417", .capability = ARM64_WORKAROUND_SPECULATIVE_SSBS,
arch/arm64/kernel/proton-pack.c +1 -1
@@ -583,7 +583,7 @@ static enum mitigation_state spectre_v4_enable_hw_mitigation(void)* Mitigate this with an unconditional speculation barrier, as CPUs * could mis-speculate branches and bypass a conditional barrier. */ -if (IS_ENABLED (CONFIG_ARM64_WORKAROUND_SPECULATIVE_SSBS )) +if (IS_ENABLED (CONFIG_ARM64_ERRATUM_3194386 ))spec_bar ();return SPECTRE_MITIGATED ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 290/352 arm64: errata: Expand speculative SSBS workaround
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 75b3c43eab594bfbd8184ec8ee1a6b820950819a ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS special-purpose register does not affect subsequent speculative instructions, permitting speculative store bypassing for a window of time.
We worked around this for Cortex-X4 and Neoverse-V3, in commit:
7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
... as per their Software Developer Errata Notice (SDEN) documents:
* Cortex-X4 SDEN v8.0, erratum 3194386:
https://developer.arm.com/documentation/SDEN-2432808/0800/
* Neoverse-V3 SDEN v6.0, erratum 3312417:
https://developer.arm.com/documentation/SDEN-2891958/0600/
Since then, similar errata have been published for a number of other Arm Ltd CPUs, for which the mitigation is the same. This is described in their respective SDEN documents:
* Cortex-A710 SDEN v19.0, errataum 3324338
https://developer.arm.com/documentation/SDEN-1775101/1900/?lang=en
* Cortex-A720 SDEN v11.0, erratum 3456091
https://developer.arm.com/documentation/SDEN-2439421/1100/?lang=en
* Cortex-X2 SDEN v19.0, erratum 3324338
https://developer.arm.com/documentation/SDEN-1775100/1900/?lang=en
* Cortex-X3 SDEN v14.0, erratum 3324335
https://developer.arm.com/documentation/SDEN-2055130/1400/?lang=en
* Cortex-X925 SDEN v8.0, erratum 3324334
https://developer.arm.com/documentation/109108/800/?lang=en
* Neoverse-N2 SDEN v17.0, erratum 3324339
https://developer.arm.com/documentation/SDEN-1982442/1700/?lang=en
* Neoverse-V2 SDEN v9.0, erratum 3324336
https://developer.arm.com/documentation/SDEN-2332927/900/?lang=en
Note that due to shared design lineage, some CPUs share the same erratum number.
Add these to the existing mitigation under CONFIG_ARM64_ERRATUM_3194386. As listing all of the erratum IDs in the runtime description would be unwieldy, this is reduced to:
"SSBS not fully self-synchronizing"
... matching the description of the errata in all of the SDENs.
--- Documentation/arm64/silicon-errata.rst | 14 ++++++++++++++ arch/arm64/Kconfig | 9 ++++++++- arch/arm64/kernel/cpu_errata.c | 9 ++++++++- 3 files changed, 30 insertions(+), 2 deletions(-)
Documentation/arm64/silicon-errata.rst +14 -0
@@ -98,14 +98,28 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A710 | #3324338 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X2 | #3324338 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X3 | #3324335 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X925 | #3324334 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1349291 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A |
arch/arm64/Kconfig +8 -1
@@ -692,12 +692,19 @@ config ARM64_ERRATUM_2457168 If unsure, say Y. config ARM64_ERRATUM_3194386 - bool "Cortex-X4/Neoverse-V3: workaround for MSR SSBS not self-synchronizing" + bool "Cortex-{A720,X4,X925}/Neoverse-V3: workaround for MSR SSBS not self-synchronizing" default y help This option adds the workaround for the following errata: + * ARM Cortex-A710 erratam 3324338 + * ARM Cortex-A720 erratum 3456091 + * ARM Cortex-X2 erratum 3324338 + * ARM Cortex-X3 erratum 3324335 * ARM Cortex-X4 erratum 3194386 + * ARM Cortex-X925 erratum 3324334 + * ARM Neoverse N2 erratum 3324339 + * ARM Neoverse V2 erratum 3324336 * ARM Neoverse-V3 erratum 3312417 On affected cores "MSR SSBS, #0" instructions may not affect
arch/arm64/kernel/cpu_errata.c +8 -1
@@ -366,8 +366,15 @@ static struct midr_range broken_aarch32_aes[] = {#ifdef CONFIG_ARM64_ERRATUM_3194386 static const struct midr_range erratum_spec_ssbs_list[] = { +MIDR_ALL_VERSIONS (MIDR_CORTEX_A710 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_A720 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_X2 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_X3 ),MIDR_ALL_VERSIONS (MIDR_CORTEX_X4 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_X925 ), +MIDR_ALL_VERSIONS (MIDR_NEOVERSE_N2 ),MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V3 ), +MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V2 ), {} };#endif
@@ -581,7 +588,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {#endif #ifdef CONFIG_ARM64_ERRATUM_3194386 { - .desc = "ARM errata 3194386, 3312417", + .desc = "SSBS not fully self-synchronizing", .capability = ARM64_WORKAROUND_SPECULATIVE_SSBS, ERRATA_MIDR_RANGE_LIST(erratum_spec_ssbs_list), },
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 291/352 arm64: cputype: Add Cortex-X1C definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 58d245e03c324d083a0ec3b9ab8ebd46ec9848d7 ]
Add cputype definitions for Cortex-X1C. These will be used for errata detection in subsequent patches.
These values can be found in the Cortex-X1C TRM:
https://developer.arm.com/documentation/101968/0002/
... in section B2.107 ("MIDR_EL1, Main ID Register, EL1").
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -84,6 +84,7 @@#define ARM_CPU_PART_CORTEX_X2 0xD48#define ARM_CPU_PART_NEOVERSE_N2 0xD49#define ARM_CPU_PART_CORTEX_A78C 0xD4B +#define ARM_CPU_PART_CORTEX_X1C 0xD4C#define ARM_CPU_PART_CORTEX_X3 0xD4E#define ARM_CPU_PART_NEOVERSE_V2 0xD4F#define ARM_CPU_PART_CORTEX_A720 0xD81
@@ -142,6 +143,7 @@#define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2)#define MIDR_NEOVERSE_N2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N2)#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C) +#define MIDR_CORTEX_X1C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X1C)#define MIDR_CORTEX_X3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X3)#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2)#define MIDR_CORTEX_A720 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 292/352 arm64: cputype: Add Cortex-A725 definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 9ef54a384526911095db465e77acc1cb5266b32c ]
Add cputype definitions for Cortex-A725. These will be used for errata detection in subsequent patches.
These values can be found in the Cortex-A725 TRM:
https://developer.arm.com/documentation/107652/0001/
... in table A-247 ("MIDR_EL1 bit descriptions").
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -91,6 +91,7 @@#define ARM_CPU_PART_CORTEX_X4 0xD82#define ARM_CPU_PART_NEOVERSE_V3 0xD84#define ARM_CPU_PART_CORTEX_X925 0xD85 +#define ARM_CPU_PART_CORTEX_A725 0xD87#define APM_CPU_PART_POTENZA 0x000
@@ -150,6 +151,7 @@#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4)#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)#define MIDR_CORTEX_X925 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X925) +#define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 293/352 arm64: errata: Expand speculative SSBS workaround (again)
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit adeec61a4723fd3e39da68db4cc4d924e6d7f641 ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS special-purpose register does not affect subsequent speculative instructions, permitting speculative store bypassing for a window of time.
We worked around this for a number of CPUs in commits:
* 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
* 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround")
Since then, similar errata have been published for a number of other Arm Ltd CPUs, for which the same mitigation is sufficient. This is described in their respective Software Developer Errata Notice (SDEN) documents:
* Cortex-A76 (MP052) SDEN v31.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885749/3100/
* Cortex-A77 (MP074) SDEN v19.0, erratum 3324348
https://developer.arm.com/documentation/SDEN-1152370/1900/
* Cortex-A78 (MP102) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401784/2100/
* Cortex-A78C (MP138) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707916/1600/
* Cortex-A78C (MP154) SDEN v10.0, erratum 3324347
https://developer.arm.com/documentation/SDEN-2004089/1000/
* Cortex-A725 (MP190) SDEN v5.0, erratum 3456106
https://developer.arm.com/documentation/SDEN-2832921/0500/
* Cortex-X1 (MP077) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401782/2100/
* Cortex-X1C (MP136) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707914/1600/
* Neoverse-N1 (MP050) SDEN v32.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885747/3200/
* Neoverse-V1 (MP076) SDEN v19.0, erratum 3324341
https://developer.arm.com/documentation/SDEN-1401781/1900/
Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number and some CPUs have multiple erratum numbers for the same HW issue.
On parts without SB, it is necessary to use ISB for the workaround. The spec_bar() macro used in the mitigation will expand to a "DSB SY; ISB" sequence in this case, which is sufficient on all affected parts.
Enable the existing mitigation by adding the relevant MIDRs to erratum_spec_ssbs_list. The list is sorted alphanumerically (involving moving Neoverse-V3 after Neoverse-V2) so that this is easy to audit and potentially extend again in future. The Kconfig text is also updated to clarify the set of affected parts and the mitigation.
--- Documentation/arm64/silicon-errata.rst | 18 ++++++++++++++++++ arch/arm64/Kconfig | 22 ++++++++++++++++------ arch/arm64/kernel/cpu_errata.c | 11 ++++++++++- 3 files changed, 44 insertions(+), 7 deletions(-)
Documentation/arm64/silicon-errata.rst +18 -0
@@ -94,14 +94,28 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #3324338 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-X2 | #3324338 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-X3 | #3324335 | ARM64_ERRATUM_3194386 |
@@ -116,8 +130,12 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
arch/arm64/Kconfig +16 -6
@@ -692,18 +692,28 @@ config ARM64_ERRATUM_2457168 If unsure, say Y. config ARM64_ERRATUM_3194386 - bool "Cortex-{A720,X4,X925}/Neoverse-V3: workaround for MSR SSBS not self-synchronizing" + bool "Cortex-*/Neoverse-*: workaround for MSR SSBS not self-synchronizing" default y help This option adds the workaround for the following errata: + * ARM Cortex-A76 erratum 3324349 + * ARM Cortex-A77 erratum 3324348 + * ARM Cortex-A78 erratum 3324344 + * ARM Cortex-A78C erratum 3324346 + * ARM Cortex-A78C erratum 3324347 * ARM Cortex-A710 erratam 3324338 * ARM Cortex-A720 erratum 3456091 + * ARM Cortex-A725 erratum 3456106 + * ARM Cortex-X1 erratum 3324344 + * ARM Cortex-X1C erratum 3324346 * ARM Cortex-X2 erratum 3324338 * ARM Cortex-X3 erratum 3324335 * ARM Cortex-X4 erratum 3194386 * ARM Cortex-X925 erratum 3324334 + * ARM Neoverse-N1 erratum 3324349 * ARM Neoverse N2 erratum 3324339 + * ARM Neoverse-V1 erratum 3324341 * ARM Neoverse V2 erratum 3324336 * ARM Neoverse-V3 erratum 3312417
@@ -711,11 +721,11 @@ config ARM64_ERRATUM_3194386 subsequent speculative instructions, which may permit unexepected speculative store bypassing. - Work around this problem by placing a speculation barrier after - kernel changes to SSBS. The presence of the SSBS special-purpose - register is hidden from hwcaps and EL0 reads of ID_AA64PFR1_EL1, such - that userspace will use the PR_SPEC_STORE_BYPASS prctl to change - SSBS. + Work around this problem by placing a Speculation Barrier (SB) or + Instruction Synchronization Barrier (ISB) after kernel changes to + SSBS. The presence of the SSBS special-purpose register is hidden + from hwcaps and EL0 reads of ID_AA64PFR1_EL1, such that userspace + will use the PR_SPEC_STORE_BYPASS prctl to change SSBS. If unsure, say Y.
arch/arm64/kernel/cpu_errata.c +10 -1
@@ -366,15 +366,24 @@ static struct midr_range broken_aarch32_aes[] = {#ifdef CONFIG_ARM64_ERRATUM_3194386 static const struct midr_range erratum_spec_ssbs_list[] = { +MIDR_ALL_VERSIONS (MIDR_CORTEX_A76 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_A77 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_A78 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_A78C ),MIDR_ALL_VERSIONS (MIDR_CORTEX_A710 ),MIDR_ALL_VERSIONS (MIDR_CORTEX_A720 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_A725 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_X1 ), +MIDR_ALL_VERSIONS (MIDR_CORTEX_X1C ),MIDR_ALL_VERSIONS (MIDR_CORTEX_X2 ),MIDR_ALL_VERSIONS (MIDR_CORTEX_X3 ),MIDR_ALL_VERSIONS (MIDR_CORTEX_X4 ),MIDR_ALL_VERSIONS (MIDR_CORTEX_X925 ), +MIDR_ALL_VERSIONS (MIDR_NEOVERSE_N1 ),MIDR_ALL_VERSIONS (MIDR_NEOVERSE_N2 ), -MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V3 ), +MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V1 ),MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V2 ), +MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V3 ), {} };#endif
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 294/352 i2c: smbus: Improve handling of stuck alerts
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit 37c526f00bc1c4f847fc800085f8f009d2e11be6 ]
The following messages were observed while testing alert functionality on systems with multiple I2C devices on a single bus if alert was active on more than one chip.
smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0 smbus_alert 3-000c: no driver alert()!
and:
smbus_alert 3-000c: SMBALERT# from dev 0x28, flag 0
Once it starts, this message repeats forever at high rate. There is no device at any of the reported addresses.
Analysis shows that this is seen if multiple devices have the alert pin active. Apparently some devices do not support SMBus arbitration correctly. They keep sending address bits after detecting an address collision and handle the collision not at all or too late.
Specifically, address 0x0c is seen with ADT7461A at address 0x4c and ADM1021 at address 0x18 if alert is active on both chips. Address 0x28 is seen with ADT7483 at address 0x2a and ADT7461 at address 0x4c if alert is active on both chips.
Once the system is in bad state (alert is set by more than one chip), it often only recovers by power cycling.
To reduce the impact of this problem, abort the endless loop in smbus_alert() if the same address is read more than once and not handled by a driver.
--- drivers/i2c/i2c-smbus.c | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-)
drivers/i2c/i2c-smbus.c +25 -7
@@ -34,6 +34,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)struct i2c_client *client =i2c_verify_client (dev);struct alert_data *data = addrp;struct i2c_driver *driver; +int ret;if (!client || client->addr != data->addr)return 0 ;
@@ -47,16 +48,21 @@ static int smbus_do_alert(struct device *dev, void *addrp)device_lock (dev);if (client->dev.driver) { driver =to_i2c_driver (client->dev.driver); -if (driver->alert) +if (driver->alert) { +/* Stop iterating after we find the device */ driver->alert (client, data->type, data->data); -else + ret = -EBUSY ; + }else {dev_warn (&client->dev,"no driver alert()!\n" ); - }else + ret = -EOPNOTSUPP ; + } + }else {dev_dbg (&client->dev,"alert with no driver\n" ); + ret = -ENODEV ; + }device_unlock (dev); -/* Stop iterating after we find the device */ -return -EBUSY ; +return ret; }/*
@@ -67,6 +73,7 @@ static irqreturn_t smbus_alert(int irq, void *d) {struct i2c_smbus_alert *alert = d;struct i2c_client *ara; +unsigned short prev_addr =I2C_CLIENT_END ;/* Not a valid address */ ara = alert->ara;
@@ -94,8 +101,19 @@ static irqreturn_t smbus_alert(int irq, void *d) data.addr, data.data);/* Notify driver for the device which issued the alert */ -device_for_each_child (&ara->adapter->dev, &data, - smbus_do_alert); + status =device_for_each_child (&ara->adapter->dev, &data, + smbus_do_alert); +/* +* If we read the same address more than once, and the alert +* was not handled by a driver, it won't do any good to repeat +* the loop because it will never terminate. +* Bail out in this case. +* Note: This assumes that a driver with alert handler handles +* the alert properly and clears it if necessary. +*/ +if (data.addr == prev_addr && status != -EBUSY ) +break ; + prev_addr = data.addr; }return IRQ_HANDLED ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 295/352 ASoC: codecs: wsa881x: Correct Soundwire ports mask
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
[ Upstream commit eb11c3bb64ad0a05aeacdb01039863aa2aa3614b ]
Device has up to WSA881X_MAX_SWR_PORTS number of ports and the array assigned to prop.sink_dpn_prop has 0..WSA881X_MAX_SWR_PORTS-1 elements. On the other hand, GENMASK(high, low) creates an inclusive mask between <high, low>, so we need the mask from 0 up to WSA881X_MAX_SWR_PORTS-1.
Theoretically, too wide mask could cause an out of bounds read in sdw_get_slave_dpn_prop() in stream.c, however only in the case of buggy driver, e.g. adding incorrect number of ports via sdw_stream_add_slave().
--- sound/soc/codecs/wsa881x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/wsa881x.c +1 -1
@@ -1120,7 +1120,7 @@ static int wsa881x_probe(struct sdw_slave *pdev, wsa881x->sconfig.frame_rate =48000 ; wsa881x->sconfig.direction =SDW_DATA_DIR_RX ; wsa881x->sconfig.type =SDW_STREAM_PDM ; - pdev->prop.sink_ports =GENMASK (WSA881X_MAX_SWR_PORTS ,0 ); + pdev->prop.sink_ports =GENMASK (WSA881X_MAX_SWR_PORTS -1 ,0 ); pdev->prop.sink_dpn_prop = wsa_sink_dpn_prop; pdev->prop.scp_int1_mask =SDW_SCP_INT1_BUS_CLASH |SDW_SCP_INT1_PARITY ;gpiod_direction_output (wsa881x->sd_n,1 );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 296/352 i2c: smbus: Send alert notifications to all devices if source not found
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit f6c29f710c1ff2590109f83be3e212b86c01e0f3 ]
If a SMBus alert is received and the originating device is not found, the reason may be that the address reported on the SMBus alert address is corrupted, for example because multiple devices asserted alert and do not correctly implement SMBus arbitration.
If this happens, call alert handlers on all devices connected to the given I2C bus, in the hope that this cleans up the situation.
This change reliably fixed the problem on a system with multiple devices on a single bus. Example log where the device on address 0x18 (ADM1021) and on address 0x4c (ADT7461A) both had the alert line asserted:
smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0 smbus_alert 3-000c: no driver alert()! smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0 smbus_alert 3-000c: no driver alert()!
lm90 3-0018: temp1 out of range, please check! lm90 3-0018: Disabling ALERT#
lm90 3-0029: Everything OK
lm90 3-002a: Everything OK
lm90 3-004c: temp1 out of range, please check! lm90 3-004c: temp2 out of range, please check! lm90 3-004c: Disabling ALERT#
--- drivers/i2c/i2c-smbus.c | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-)
drivers/i2c/i2c-smbus.c +35 -3
@@ -65,6 +65,32 @@ static int smbus_do_alert(struct device *dev, void *addrp)return ret; } +/* Same as above, but call back all drivers with alert handler */ + +static int smbus_do_alert_force (struct device *dev,void *addrp) +{ +struct i2c_client *client =i2c_verify_client (dev); +struct alert_data *data = addrp; +struct i2c_driver *driver; + +if (!client || (client->flags &I2C_CLIENT_TEN )) +return 0 ; + +/* +* Drivers should either disable alerts, or provide at least +* a minimal handler. Lock so the driver won't change. +*/ +device_lock (dev); +if (client->dev.driver) { + driver =to_i2c_driver (client->dev.driver); +if (driver->alert) + driver->alert (client, data->type, data->data); + } +device_unlock (dev); + +return 0 ; +} +/* * The alert IRQ handler needs to hand work off to a task which can issue * SMBus calls, because those sleeping calls can't be made in IRQ context.
@@ -106,13 +132,19 @@ static irqreturn_t smbus_alert(int irq, void *d)/* * If we read the same address more than once, and the alert * was not handled by a driver, it won't do any good to repeat -* the loop because it will never terminate. -* Bail out in this case. +* the loop because it will never terminate. Try again, this +* time calling the alert handlers of all devices connected to +* the bus, and abort the loop afterwards. If this helps, we +* are all set. If it doesn't, there is nothing else we can do, +* so we might as well abort the loop. * Note: This assumes that a driver with alert handler handles * the alert properly and clears it if necessary. */ -if (data.addr == prev_addr && status != -EBUSY ) +if (data.addr == prev_addr && status != -EBUSY ) { +device_for_each_child (&ara->adapter->dev, &data, + smbus_do_alert_force);break ; + } prev_addr = data.addr; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 297/352 bpf: kprobe: remove unused declaring of bpf_kprobe_override
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Menglong Dong <[email protected]>
[ Upstream commit 0e8b53979ac86eddb3fd76264025a70071a25574 ]
After the commit 66665ad2f102 ("tracing/kprobe: bpf: Compare instruction pointer with original one"), "bpf_kprobe_override" is not used anywhere anymore, and we can remove it now.
--- include/linux/trace_events.h | 1 - 1 file changed, 1 deletion(-)
include/linux/trace_events.h +0 -1
@@ -729,7 +729,6 @@ do { \struct perf_event ; DECLARE_PER_CPU(struct pt_regs, perf_trace_regs); -DECLARE_PER_CPU (int, bpf_kprobe_override);extern int perf_trace_init (struct perf_event *event);extern void perf_trace_destroy (struct perf_event *event);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 298/352 kprobes: Fix to check symbol prefixes correctly
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu (Google) <[email protected]>
[ Upstream commit 8c8acb8f26cbde665b233dd1b9bbcbb9b86822dc ]
Since str_has_prefix() takes the prefix as the 2nd argument and the string as the first, is_cfi_preamble_symbol() always fails to check the prefix. Fix the function parameter order so that it correctly check the prefix.
--- kernel/kprobes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/kprobes.c +2 -2
@@ -1632,8 +1632,8 @@ static bool is_cfi_preamble_symbol(unsigned long addr)if (lookup_symbol_name (addr, symbuf))return false; -return str_has_prefix ("__cfi_" , symbuf) || -str_has_prefix ("__pfx_" , symbuf); +return str_has_prefix (symbuf,"__cfi_" ) || +str_has_prefix (symbuf,"__pfx_" ); } static int check_kprobe_address_safe(struct kprobe *p,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 299/352 spi: spi-fsl-lpspi: Fix scldiv calculation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <[email protected]>
[ Upstream commit 730bbfaf7d4890bd99e637db7767dc68cfeb24e7 ]
The effective SPI clock frequency should never exceed speed_hz otherwise this might result in undefined behavior of the SPI device.
Currently the scldiv calculation could violate this constraint. For the example parameters perclk_rate = 24 MHz and speed_hz = 7 MHz, the function fsl_lpspi_set_bitrate will determine perscale = 0 and scldiv = 1, which is a effective SPI clock of 8 MHz.
So fix this by rounding up the quotient of perclk_rate and speed_hz. While this never change within the loop, we can pull this out.
--- drivers/spi/spi-fsl-lpspi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/spi/spi-fsl-lpspi.c +4 -2
@@ -297,7 +297,7 @@ static void fsl_lpspi_set_watermark(struct fsl_lpspi_data *fsl_lpspi)static int fsl_lpspi_set_bitrate (struct fsl_lpspi_data *fsl_lpspi) {struct lpspi_config config = fsl_lpspi->config; -unsigned int perclk_rate, scldiv; +unsigned int perclk_rate, scldiv, div;u8 prescale; perclk_rate =clk_get_rate (fsl_lpspi->clk_per);
@@ -308,8 +308,10 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data *fsl_lpspi)return -EINVAL ; } + div =DIV_ROUND_UP (perclk_rate, config.speed_hz); +for (prescale =0 ; prescale <8 ; prescale++) { - scldiv = perclk_rate / config.speed_hz / (1 << prescale) -2 ; + scldiv = div / (1 << prescale) -2 ;if (scldiv <256 ) { fsl_lpspi->config.prescale = prescale;break ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 300/352 ALSA: usb-audio: Re-add ScratchAmp quirk entries
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
[ Upstream commit 03898691d42e0170e7d00f07cbe21ce0e9f3a8fa ]
At the code refactoring of USB-audio quirk handling, I assumed that the quirk entries of Stanton ScratchAmp devices were only about the device name, and moved them completely into the rename table. But it seems that the device requires the quirk entry so that it's probed by the driver itself.
This re-adds back the quirk entries of ScratchAmp, but in a minimalistic manner.
--- sound/usb/quirks-table.h | 4 ++++ 1 file changed, 4 insertions(+)
sound/usb/quirks-table.h +4 -0
@@ -2573,6 +2573,10 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, +/* Stanton ScratchAmp */ +{ USB_DEVICE(0x103d, 0x0100) }, +{ USB_DEVICE(0x103d, 0x0101) }, +/* Novation EMS devices */ { USB_DEVICE_VENDOR_SPEC(0x1235, 0x0001),
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 301/352 drm/client: fix null pointer dereference in drm_client_modeset_probe
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit 113fd6372a5bb3689aba8ef5b8a265ed1529a78f upstream.
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
--- drivers/gpu/drm/drm_client_modeset.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/drm_client_modeset.c +5 -0
@@ -866,6 +866,11 @@ int drm_client_modeset_probe(struct drm_kfree (modeset->mode); modeset->mode =drm_mode_duplicate (dev, mode); +if (!modeset->mode) { + ret = -ENOMEM ; +break ; + } +drm_connector_get (connector); modeset->connectors[modeset->num_connectors++] = connector; modeset->x = offset->x;
Greg Kroah-Hartman
maintainerPATCH 302/352 ALSA: line6: Fix racy access to midibuf
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 15b7a03205b31bc5623378c190d22b7ff60026f1 upstream.
There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).
This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.
--- sound/usb/line6/driver.c | 5 +++++ 1 file changed, 5 insertions(+)
sound/usb/line6/driver.c +5 -0
@@ -286,12 +286,14 @@ static void line6_data_received(struct u {struct usb_line6 *line6 = (struct usb_line6 *)urb->context;struct midi_buffer *mb = &line6->line6midi->midibuf_in; +unsigned long flags;int done;if (urb->status == -ESHUTDOWN )return ;if (line6->properties->capabilities &LINE6_CAP_CONTROL_MIDI ) { +spin_lock_irqsave (&line6->line6midi->lock, flags); done =line6_midibuf_write (mb, urb->transfer_buffer, urb->actual_length);
@@ -300,12 +302,15 @@ static void line6_data_received(struct udev_dbg (line6->ifcdev,"%d %d buffer overflow - message skipped\n" , done, urb->actual_length); } +spin_unlock_irqrestore (&line6->line6midi->lock, flags);for (;;) { +spin_lock_irqsave (&line6->line6midi->lock, flags); done =line6_midibuf_read (mb, line6->buffer_message,LINE6_MIDI_MESSAGE_MAXLEN ,LINE6_MIDIBUF_READ_RX ); +spin_unlock_irqrestore (&line6->line6midi->lock, flags);if (done <=0 )break ;
Greg Kroah-Hartman
maintainerPATCH 303/352 ALSA: hda: Add HP MP9 G4 Retail System AMS to force connect list
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven 'Steve' Kendall <[email protected]>
commit 7e1e206b99f4b3345aeb49d94584a420b7887f1d upstream.
In recent HP UEFI firmware (likely v2.15 and above, tested on 2.27), these pins are incorrectly set for HDMI/DP audio. Tested on HP MP9 G4 Retail System AMS. Tested audio with two monitors connected via DisplayPort.
--- sound/pci/hda/patch_hdmi.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_hdmi.c +1 -0
@@ -1963,6 +1963,7 @@ static int hdmi_add_cvt(struct hda_codec }static const struct snd_pci_quirk force_connect_list[] = { +SND_PCI_QUIRK (0x103c ,0x83ef ,"HP MP9 G4 Retail System AMS" ,1 ),SND_PCI_QUIRK (0x103c ,0x870f ,"HP" ,1 ),SND_PCI_QUIRK (0x103c ,0x871a ,"HP" ,1 ),SND_PCI_QUIRK (0x103c ,0x8711 ,"HP" ,1 ),
Greg Kroah-Hartman
maintainerPATCH 304/352 ALSA: hda/hdmi: Yet more pin fix for HP EliteDesk 800 G4
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 176fd1511dd9086ab4fa9323cb232177c6235288 upstream.
HP EliteDesk 800 G4 (PCI SSID 103c:83e2) is another Kabylake machine where BIOS misses the HDMI pin initializations. Add the quirk entry.
--- sound/pci/hda/patch_hdmi.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_hdmi.c +1 -0
@@ -1963,6 +1963,7 @@ static int hdmi_add_cvt(struct hda_codec }static const struct snd_pci_quirk force_connect_list[] = { +SND_PCI_QUIRK (0x103c ,0x83e2 ,"HP EliteDesk 800 G4" ,1 ),SND_PCI_QUIRK (0x103c ,0x83ef ,"HP MP9 G4 Retail System AMS" ,1 ),SND_PCI_QUIRK (0x103c ,0x870f ,"HP" ,1 ),SND_PCI_QUIRK (0x103c ,0x871a ,"HP" ,1 ),
Greg Kroah-Hartman
maintainerPATCH 305/352 usb: vhci-hcd: Do not drop references before new references are gained
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit afdcfd3d6fcdeca2735ca8d994c5f2d24a368f0a upstream.
At a few places the driver carries stale pointers
to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.
--- drivers/usb/usbip/vhci_hcd.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/usb/usbip/vhci_hcd.c +6 -3
@@ -745,6 +745,7 @@ static int vhci_urb_enqueue(struct usb_h* */ if (usb_pipedevice (urb->pipe) ==0 ) { +struct usb_device *old;__u8 type =usb_pipetype (urb->pipe);struct usb_ctrlrequest *ctrlreq = (struct usb_ctrlrequest *) urb->setup_packet;
@@ -755,14 +756,15 @@ static int vhci_urb_enqueue(struct usb_h goto no_need_xmit; } + old = vdev->udev;switch (ctrlreq->bRequest) {case USB_REQ_SET_ADDRESS :/* set_address may come when a device is reset */ dev_info (dev,"SetAddress Request (%d) to port %d\n" , ctrlreq->wValue, vdev->rhport); -usb_put_dev (vdev->udev); vdev->udev =usb_get_dev (urb->dev); +usb_put_dev (old);spin_lock (&vdev->ud.lock); vdev->ud.status =VDEV_ST_USED ;
@@ -781,8 +783,8 @@ static int vhci_urb_enqueue(struct usb_husbip_dbg_vhci_hc ("Not yet?:Get_Descriptor to device 0 (get max pipe size)\n" ); -usb_put_dev (vdev->udev); vdev->udev =usb_get_dev (urb->dev); +usb_put_dev (old); goto out;default :
@@ -1095,6 +1097,7 @@ static void vhci_shutdown_connection(strstatic void vhci_device_reset (struct usbip_device *ud) { struct vhci_device *vdev = container_of(ud, struct vhci_device, ud); +struct usb_device *old = vdev->udev;unsigned long flags;spin_lock_irqsave (&ud->lock, flags);
@@ -1102,8 +1105,8 @@ static void vhci_device_reset(struct usb vdev->speed =0 ; vdev->devid =0 ; -usb_put_dev (vdev->udev); vdev->udev =NULL ; +usb_put_dev (old);if (ud->tcp_socket) {sockfd_put (ud->tcp_socket);
Greg Kroah-Hartman
maintainerPATCH 306/352 USB: serial: debug: do not echo input by default
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Marczykowski-Górecki <[email protected]>
commit 00af4f3dda1461ec90d892edc10bec6d3c50c554 upstream.
This driver is intended as a "client" end of the console connection. When connected to a host it's supposed to receive debug logs, and possibly allow to interact with whatever debug console is available there. Feeding messages back, depending on a configuration may cause log messages be executed as shell commands (which can be really bad if one is unlucky, imagine a log message like "prevented running rm -rf /home"). In case of Xen, it exposes sysrq-like debug interface, and feeding it its own logs will pretty quickly hit 'R' for "instant reboot".
Contrary to a classic serial console, the USB one cannot be configured ahead of time, as the device shows up only when target OS is up. And at the time device is opened to execute relevant ioctl, it's already too late, especially when logs start flowing shortly after device is initialized.
Avoid the issue by changing default to no echo for this type of devices.
--- drivers/usb/serial/usb_debug.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/usb/serial/usb_debug.c +7 -0
@@ -69,6 +69,11 @@ static void usb_debug_process_read_urb(susb_serial_generic_process_read_urb (urb); } +static void usb_debug_init_termios (struct tty_struct *tty) +{ + tty->termios.c_lflag &= ~(ECHO |ECHONL ); +} +static struct usb_serial_driver debug_device = { .driver = { .owner =THIS_MODULE ,
@@ -78,6 +83,7 @@ static struct usb_serial_driver debug_de .num_ports = 1, .bulk_out_size = USB_DEBUG_MAX_PACKET_SIZE, .break_ctl = usb_debug_break_ctl, + .init_termios = usb_debug_init_termios, .process_read_urb = usb_debug_process_read_urb, };
@@ -89,6 +95,7 @@ static struct usb_serial_driver dbc_devi .id_table = dbc_id_table, .num_ports = 1, .break_ctl = usb_debug_break_ctl, + .init_termios = usb_debug_init_termios, .process_read_urb = usb_debug_process_read_urb, };
Greg Kroah-Hartman
maintainerPATCH 307/352 usb: gadget: core: Check for unset descriptor
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wulff <[email protected]>
commit 973a57891608a98e894db2887f278777f564de18 upstream.
Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case.
This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found.
No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets.
--- drivers/usb/gadget/udc/core.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/usb/gadget/udc/core.c +4 -6
@@ -99,12 +99,10 @@ int usb_ep_enable(struct usb_ep *ep) goto out;/* UDC drivers can't handle endpoints with maxpacket size 0 */ -if (usb_endpoint_maxp (ep->desc) ==0 ) { -/* -* We should log an error message here, but we can't call -* dev_err() because there's no way to find the gadget -* given only ep. -*/ +if (!ep->desc ||usb_endpoint_maxp (ep->desc) ==0 ) { +WARN_ONCE (1 ,"%s: ep%d (%s) has %s\n" , __func__, ep->address, ep->name, + (!ep->desc) ?"NULL descriptor" :"maxpacket 0" ); + ret = -EINVAL ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 308/352 usb: gadget: u_serial: Set start_delayed during suspend
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prashanth K <[email protected]>
commit 5a444bea37e2759549ef72bfe83d1c8712e76b3d upstream.
Upstream commit aba3a8d01d62 ("usb: gadget: u_serial: add suspend resume callbacks") added started_delayed flag, so that new ports which are opened after USB suspend can start IO while resuming. But if the port was already opened, and gadget suspend kicks in afterwards, start_delayed will never be set. This causes resume to bail out before calling gs_start_io(). Fix this by setting start_delayed during suspend.
--- drivers/usb/gadget/function/u_serial.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/function/u_serial.c +1 -0
@@ -1438,6 +1438,7 @@ void gserial_suspend(struct gserial *gsespin_lock (&port->port_lock);spin_unlock (&serial_port_lock); port->suspended = true; + port->start_delayed = true;spin_unlock_irqrestore (&port->port_lock, flags); }EXPORT_SYMBOL_GPL (gserial_suspend);
Greg Kroah-Hartman
maintainerPATCH 309/352 scsi: ufs: core: Fix hba->last_dme_cmd_tstamp timestamp updating logic
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vamshi Gajjela <[email protected]>
commit ab9fd06cb8f0db0854291833fc40c789e43a361f upstream.
The ufshcd_add_delay_before_dme_cmd() always introduces a delay of MIN_DELAY_BEFORE_DME_CMDS_US between DME commands even when it's not required. The delay is added when the UFS host controller supplies the quirk UFSHCD_QUIRK_DELAY_BEFORE_DME_CMDS.
Fix the logic to update hba->last_dme_cmd_tstamp to ensure subsequent DME commands have the correct delay in the range of 0 to MIN_DELAY_BEFORE_DME_CMDS_US.
Update the timestamp at the end of the function to ensure it captures the latest time after any necessary delay has been applied.
--- drivers/scsi/ufs/ufshcd.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/scsi/ufs/ufshcd.c +8 -3
@@ -3653,11 +3653,16 @@ static inline void ufshcd_add_delay_befo min_sleep_time_us =MIN_DELAY_BEFORE_DME_CMDS_US - delta; else - return;/* no more delay required */ + min_sleep_time_us =0 ;/* no more delay required */ } -/* allow sleep for extra 50us if needed */ -usleep_range (min_sleep_time_us, min_sleep_time_us +50 ); +if (min_sleep_time_us >0 ) { +/* allow sleep for extra 50us if needed */ +usleep_range (min_sleep_time_us, min_sleep_time_us +50 ); + } + +/* update the last_dme_cmd_tstamp */ + hba->last_dme_cmd_tstamp =ktime_get (); }/**