5.15.84-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.15.84-rc1 review
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.15.84-rc1
Lei Rao <[email protected]>
nvme-pci: clear the prp2 field when not used
Peter Zijlstra <[email protected]>
perf: Fix perf_pending_task() UaF
Charles Keepax <[email protected]>
ASoC: cs42l51: Correct PGA Volume minimum value
Rasmus Villemoes <[email protected]>
net: fec: don't reset irq coalesce settings to defaults on "ip link up"
Yasushi SHOJI <[email protected]>
can: mcba_usb: Fix termination command argument
Heiko Schocher <[email protected]>
can: sja1000: fix size of OCR_MODE_MASK define
Ricardo Ribalda <[email protected]>
pinctrl: meditatek: Startup with the IRQs disabled
Hou Tao <[email protected]>
libbpf: Use page size as max_entries when probing ring buffer map
Mark Brown <[email protected]>
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Shengjiu Wang <[email protected]>
ASoC: fsl_micfil: explicitly clear CHnF flags
Shengjiu Wang <[email protected]>
ASoC: fsl_micfil: explicitly clear software reset bit
Jialiang Wang <[email protected]>
nfp: fix use-after-free in area_cache_get()
Amir Goldstein <[email protected]>
vfs: fix copy_file_range() averts filesystem freeze protection
Nathan Chancellor <[email protected]>
x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
-------------
Diffstat:
Makefile | 4 ++-- arch/x86/entry/vdso/vdso.lds.S | 2 ++ drivers/net/can/usb/mcba_usb.c | 10 +++++++--- drivers/net/ethernet/freescale/fec_main.c | 22 ++++++---------------- .../ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 ++- drivers/nvme/host/pci.c | 2 ++ drivers/pinctrl/mediatek/mtk-eint.c | 9 ++++++--- fs/ksmbd/vfs.c | 6 +++--- fs/nfsd/vfs.c | 4 ++-- fs/read_write.c | 17 +++++++++++++---- include/linux/can/platform/sja1000.h | 2 +- include/linux/fs.h | 8 ++++++++ kernel/events/core.c | 17 +++++++++++++---- sound/soc/codecs/cs42l51.c | 2 +- sound/soc/fsl/fsl_micfil.c | 19 +++++++++++++++++++ sound/soc/soc-ops.c | 6 ++++++ tools/lib/bpf/libbpf_probes.c | 2 +- 17 files changed, 94 insertions(+), 41 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/14 x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
From: Nathan Chancellor <[email protected]>
commit 45be2ad007a9c6bea70249c4cf3e4905afe4caeb upstream.
Recently, ld.lld moved from '--undefined-version' to '--no-undefined-version' as the default, which breaks building the vDSO when CONFIG_X86_SGX is not set:
ld.lld: error: version script assignment of 'LINUX_2.6' to symbol '__vdso_sgx_enter_enclave' failed: symbol not defined
__vdso_sgx_enter_enclave is only included in the vDSO when CONFIG_X86_SGX is set. Only export it if it will be present in the final object, which clears up the error.
--- arch/x86/entry/vdso/vdso.lds.S | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/entry/vdso/vdso.lds.S +2 -0
@@ -27,7 +27,9 @@ VERSION { __vdso_time; clock_getres; __vdso_clock_getres; +#ifdef CONFIG_X86_SGX __vdso_sgx_enter_enclave; +#endif local: *; }; }
Greg Kroah-Hartman
maintainerPATCH 2/14 vfs: fix copy_file_range() averts filesystem freeze protection
In reply to Greg Kroah-HartmanFrom: Amir Goldstein <[email protected]>
commit 10bc8e4af65946b727728d7479c028742321b60a upstream.
Commit 868f9f2f8e00 ("vfs: fix copy_file_range() regression in cross-fs copies") removed fallback to generic_copy_file_range() for cross-fs cases inside vfs_copy_file_range().
To preserve behavior of nfsd and ksmbd server-side-copy, the fallback to generic_copy_file_range() was added in nfsd and ksmbd code, but that call is missing sb_start_write(), fsnotify hooks and more.
Ideally, nfsd and ksmbd would pass a flag to vfs_copy_file_range() that will take care of the fallback, but that code would be subtle and we got vfs_copy_file_range() logic wrong too many times already.
Instead, add a flag to explicitly request vfs_copy_file_range() to perform only generic_copy_file_range() and let nfsd and ksmbd use this flag only in the fallback path.
This choise keeps the logic changes to minimum in the non-nfsd/ksmbd code paths to reduce the risk of further regressions.
--- fs/ksmbd/vfs.c | 6 +++--- fs/nfsd/vfs.c | 4 ++-- fs/read_write.c | 17 +++++++++++++---- include/linux/fs.h | 8 ++++++++ 4 files changed, 26 insertions(+), 9 deletions(-)
fs/ksmbd/vfs.c +3 -3
@@ -1788,9 +1788,9 @@ int ksmbd_vfs_copy_file_ranges(struct ks ret =vfs_copy_file_range (src_fp->filp, src_off, dst_fp->filp, dst_off, len,0 );if (ret == -EOPNOTSUPP || ret == -EXDEV ) - ret =generic_copy_file_range (src_fp->filp, src_off, - dst_fp->filp, dst_off, - len,0 ); + ret =vfs_copy_file_range (src_fp->filp, src_off, + dst_fp->filp, dst_off, len, +COPY_FILE_SPLICE );if (ret <0 )return ret;
fs/nfsd/vfs.c +2 -2
@@ -574,8 +574,8 @@ ssize_t nfsd_copy_file_range(struct file ret =vfs_copy_file_range (src, src_pos, dst, dst_pos, count,0 );if (ret == -EOPNOTSUPP || ret == -EXDEV ) - ret =generic_copy_file_range (src, src_pos, dst, dst_pos, - count,0 ); + ret =vfs_copy_file_range (src, src_pos, dst, dst_pos, count, +COPY_FILE_SPLICE );return ret; }
fs/read_write.c +13 -4
@@ -1418,7 +1418,9 @@ static int generic_copy_file_checks(stru* and several different sets of file_operations, but they all end up * using the same ->copy_file_range() function pointer. */ -if (file_out->f_op->copy_file_range) { +if (flags ©_FILE_SPLICE ) { +/* cross sb splice is allowed */ + }else if (file_out->f_op->copy_file_range) {if (file_in->f_op->copy_file_range != file_out->f_op->copy_file_range)return -EXDEV ;
@@ -1468,8 +1470,9 @@ ssize_t vfs_copy_file_range(struct file size_t len, unsigned int flags) { ssize_t ret; +bool splice = flags ©_FILE_SPLICE ; -if (flags !=0 ) +if (flags & ~COPY_FILE_SPLICE )return -EINVAL ; ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
@@ -1495,14 +1498,14 @@ ssize_t vfs_copy_file_range(struct file* same sb using clone, but for filesystems where both clone and copy * are supported (e.g. nfs,cifs), we only call the copy method. */ -if (file_out->f_op->copy_file_range) { +if (!splice && file_out->f_op->copy_file_range) { ret = file_out->f_op->copy_file_range (file_in, pos_in, file_out, pos_out, len, flags); goto done; } -if (file_in->f_op->remap_file_range && +if (!splice && file_in->f_op->remap_file_range &&file_inode (file_in)->i_sb ==file_inode (file_out)->i_sb) { ret = file_in->f_op->remap_file_range(file_in, pos_in, file_out, pos_out,
@@ -1522,6 +1525,8 @@ ssize_t vfs_copy_file_range(struct file* consistent story about which filesystems support copy_file_range() * and which filesystems do not, that will allow userspace tools to * make consistent desicions w.r.t using copy_file_range(). +* +* We also get here if caller (e.g. nfsd) requested COPY_FILE_SPLICE. */ ret =generic_copy_file_range (file_in, pos_in, file_out, pos_out, len, flags);
@@ -1576,6 +1581,10 @@ SYSCALL_DEFINE6(copy_file_range, int, fd pos_out = f_out.file->f_pos; } + ret = -EINVAL ; +if (flags !=0 ) + goto out; + ret =vfs_copy_file_range (f_in.file, pos_in, f_out.file, pos_out, len, flags);if (ret >0 ) {
include/linux/fs.h +8 -0
@@ -1990,6 +1990,14 @@ struct dir_context {*/ #define REMAP_FILE_ADVISORY (REMAP_FILE_CAN_SHORTEN) +/* +* These flags control the behavior of vfs_copy_file_range(). +* They are not available to the user via syscall. +* +* COPY_FILE_SPLICE: call splice direct instead of fs clone/copy ops +*/ +#define COPY_FILE_SPLICE (1 << 0) +struct iov_iter ;struct file_operations {
Greg Kroah-Hartman
maintainerPATCH 3/14 nfp: fix use-after-free in area_cache_get()
In reply to Greg Kroah-HartmanFrom: Jialiang Wang <[email protected]>
commit 02e1a114fdb71e59ee6770294166c30d437bf86a upstream.
area_cache_get() is used to distribute cache->area and set cache->id,
and if cache->id is not 0 and cache->area->kref refcount is 0, it will release the cache->area by nfp_cpp_area_release(). area_cache_get() set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().
But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
is already set but the refcount is not increased as expected. At this time, calling the nfp_cpp_area_release() will cause use-after-free.
To avoid the use-after-free, set cache->id after area_init() and
nfp_cpp_area_acquire() complete successfully.
Note: This vulnerability is triggerable by providing emulated device
equipped with specified configuration.
BUG: KASAN: use-after-free in nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1 Call Trace: <TASK> nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884) Allocated by task 1: nfp_cpp_area_alloc_with_name (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303) nfp_cpp_area_cache_add (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802) nfp6000_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:1230) nfp_cpp_from_operations (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215) nfp_pci_probe (drivers/net/ethernet/netronome/nfp/nfp_main.c:744) Freed by task 1: kfree (mm/slub.c:4562) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873) nfp_cpp_read (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:924 drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973) nfp_cpp_readl (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpplib.c:48)
--- drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c +2 -1
@@ -874,7 +874,6 @@ area_cache_get(struct nfp_cpp *cpp, u32 }/* Adjust the start address to be cache size aligned */ - cache->id = id; cache->addr = addr & ~(u64)(cache->size -1 );/* Re-init to the new ID and address */
@@ -894,6 +893,8 @@ area_cache_get(struct nfp_cpp *cpp, u32return NULL ; } + cache->id = id; + exit:/* Adjust offset */ *offset = addr - cache->addr;
Greg Kroah-Hartman
maintainerPATCH 4/14 ASoC: fsl_micfil: explicitly clear software reset bit
In reply to Greg Kroah-HartmanFrom: Shengjiu Wang <[email protected]>
[ Upstream commit 292709b9cf3ba470af94b62c9bb60284cc581b79 ]
SRES is self-cleared bit, but REG_MICFIL_CTRL1 is defined as non volatile register, it still remain in regmap cache after set, then every update of REG_MICFIL_CTRL1, software reset happens. to avoid this, clear it explicitly.
--- sound/soc/fsl/fsl_micfil.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
sound/soc/fsl/fsl_micfil.c +11 -0
@@ -191,6 +191,17 @@ static int fsl_micfil_reset(struct device *dev)return ret; } +/* +* SRES is self-cleared bit, but REG_MICFIL_CTRL1 is defined +* as non-volatile register, so SRES still remain in regmap +* cache after set, that every update of REG_MICFIL_CTRL1, +* software reset happens. so clear it explicitly. +*/ + ret =regmap_clear_bits (micfil->regmap,REG_MICFIL_CTRL1 , +MICFIL_CTRL1_SRES ); +if (ret) +return ret; +return 0 ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 5/14 ASoC: fsl_micfil: explicitly clear CHnF flags
In reply to Greg Kroah-HartmanFrom: Shengjiu Wang <[email protected]>
[ Upstream commit b776c4a4618ec1b5219d494c423dc142f23c4e8f ]
There may be failure when start 1 channel recording after 8 channels recording. The reason is that the CHnF flags are not cleared successfully by software reset.
This issue is triggerred by the change of clearing software reset bit.
CHnF flags are write 1 clear bits. Clear them by force write.
--- sound/soc/fsl/fsl_micfil.c | 8 ++++++++ 1 file changed, 8 insertions(+)
sound/soc/fsl/fsl_micfil.c +8 -0
@@ -202,6 +202,14 @@ static int fsl_micfil_reset(struct device *dev)if (ret)return ret; +/* +* Set SRES should clear CHnF flags, But even add delay here +* the CHnF may not be cleared sometimes, so clear CHnF explicitly. +*/ + ret =regmap_write_bits (micfil->regmap,REG_MICFIL_STAT ,0xFF ,0xFF ); +if (ret) +return ret; +return 0 ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 6/14 ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
[ Upstream commit 97eea946b93961fffd29448dcda7398d0d51c4b2 ]
The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks.
--- sound/soc/soc-ops.c | 6 ++++++ 1 file changed, 6 insertions(+)
sound/soc/soc-ops.c +6 -0
@@ -451,6 +451,12 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol, val_mask = mask << rshift; val2 = (ucontrol->value.integer.value[1 ] + min) & mask; + +if (mc->platform_max && val2 > mc->platform_max) +return -EINVAL ; +if (val2 > max) +return -EINVAL ; + val2 = val2 << rshift; err = snd_soc_component_update_bits(component, reg2, val_mask,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 7/14 libbpf: Use page size as max_entries when probing ring buffer map
In reply to Greg Kroah-HartmanFrom: Hou Tao <[email protected]>
[ Upstream commit 689eb2f1ba46b4b02195ac2a71c55b96d619ebf8 ]
Using page size as max_entries when probing ring buffer map, else the probe may fail on host with 64KB page size (e.g., an ARM64 host).
After the fix, the output of "bpftool feature" on above host will be correct.
Before :
eBPF map_type ringbuf is NOT available
eBPF map_type user_ringbuf is NOT available
After :
eBPF map_type ringbuf is available
eBPF map_type user_ringbuf is available
--- tools/lib/bpf/libbpf_probes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/lib/bpf/libbpf_probes.c +1 -1
@@ -245,7 +245,7 @@ bool bpf_probe_map_type(enum bpf_map_type map_type, __u32 ifindex)case BPF_MAP_TYPE_RINGBUF : key_size =0 ; value_size =0 ; - max_entries =4096 ; + max_entries =sysconf (_SC_PAGE_SIZE);break ;case BPF_MAP_TYPE_UNSPEC :case BPF_MAP_TYPE_HASH :
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 8/14 pinctrl: meditatek: Startup with the IRQs disabled
In reply to Greg Kroah-HartmanFrom: Ricardo Ribalda <[email protected]>
[ Upstream commit 11780e37565db4dd064d3243ca68f755c13f65b4 ]
If the system is restarted via kexec(), the peripherals do not start with a known state.
If the previous system had enabled an IRQs we will receive unexected IRQs that can lock the system.
[ 28.109251] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:0] [ 28.109263] Modules linked in: [ 28.109273] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.79-14458-g4b9edf7b1ac6 #1 9f2e76613148af94acccd64c609a552fb4b4354b [ 28.109284] Hardware name: Google Elm (DT) [ 28.109290] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.109298] pc : __do_softirq+0xa0/0x388 [ 28.109309] lr : __do_softirq+0x70/0x388 [ 28.109316] sp : ffffffc008003ee0 [ 28.109321] x29: ffffffc008003f00 x28: 000000000000000a x27: 0000000000000080 [ 28.109334] x26: 0000000000000001 x25: ffffffefa7b350c0 x24: ffffffefa7b47480 [ 28.109346] x23: ffffffefa7b3d000 x22: 0000000000000000 x21: ffffffefa7b0fa40 [ 28.109358] x20: ffffffefa7b005b0 x19: ffffffefa7b47480 x18: 0000000000065b6b [ 28.109370] x17: ffffffefa749c8b0 x16: 000000000000018c x15: 00000000000001b8 [ 28.109382] x14: 00000000000d3b6b x13: 0000000000000006 x12: 0000000000057e91 [ 28.109394] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffefa7b47480 [ 28.109406] x8 : 00000000000000e0 x7 : 000000000f424000 x6 : 0000000000000000 [ 28.109418] x5 : ffffffefa7dfaca0 x4 : ffffffefa7dfadf0 x3 : 000000000000000f [ 28.109429] x2 : 0000000000000000 x1 : 0000000000000100 x0 : 0000000001ac65c5 [ 28.109441] Call trace: [ 28.109447] __do_softirq+0xa0/0x388 [ 28.109454] irq_exit+0xc0/0xe0 [ 28.109464] handle_domain_irq+0x68/0x90 [ 28.109473] gic_handle_irq+0xac/0xf0 [ 28.109480] call_on_irq_stack+0x28/0x50 [ 28.109488] do_interrupt_handler+0x44/0x58 [ 28.109496] el1_interrupt+0x30/0x58 [ 28.109506] el1h_64_irq_handler+0x18/0x24 [ 28.109512] el1h_64_irq+0x7c/0x80 [ 28.109519] arch_local_irq_enable+0xc/0x18 [ 28.109529] default_idle_call+0x40/0x140 [ 28.109539] do_idle+0x108/0x290 [ 28.109547] cpu_startup_entry+0x2c/0x30 [ 28.109554] rest_init+0xe8/0xf8 [ 28.109562] arch_call_rest_init+0x18/0x24 [ 28.109571] start_kernel+0x338/0x42c [ 28.109578] __primary_switched+0xbc/0xc4 [ 28.109588] Kernel panic - not syncing: softlockup: hung tasks
--- drivers/pinctrl/mediatek/mtk-eint.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/pinctrl/mediatek/mtk-eint.c +6 -3
@@ -287,12 +287,15 @@ static struct irq_chip mtk_eint_irq_chip = {static unsigned int mtk_eint_hw_init (struct mtk_eint *eint) { -void __iomem *reg = eint->base + eint->regs->dom_en; +void __iomem *dom_en = eint->base + eint->regs->dom_en; +void __iomem *mask_set = eint->base + eint->regs->mask_set;unsigned int i;for (i =0 ; i < eint->hw->ap_num; i +=32 ) { -writel (0xffffffff , reg); - reg +=4 ; +writel (0xffffffff , dom_en); +writel (0xffffffff , mask_set); + dom_en +=4 ; + mask_set +=4 ; }return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 9/14 can: sja1000: fix size of OCR_MODE_MASK define
In reply to Greg Kroah-HartmanFrom: Heiko Schocher <[email protected]>
[ Upstream commit 26e8f6a75248247982458e8237b98c9fb2ffcf9d ]
bitfield mode in ocr register has only 2 bits not 3, so correct the OCR_MODE_MASK define.
--- include/linux/can/platform/sja1000.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/can/platform/sja1000.h +1 -1
@@ -14,7 +14,7 @@#define OCR_MODE_TEST 0x01#define OCR_MODE_NORMAL 0x02#define OCR_MODE_CLOCK 0x03 -#define OCR_MODE_MASK 0x07 +#define OCR_MODE_MASK 0x03#define OCR_TX0_INVERT 0x04#define OCR_TX0_PULLDOWN 0x08#define OCR_TX0_PULLUP 0x10
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 10/14 can: mcba_usb: Fix termination command argument
In reply to Greg Kroah-HartmanFrom: Yasushi SHOJI <[email protected]>
[ Upstream commit 1a8e3bd25f1e789c8154e11ea24dc3ec5a4c1da0 ]
Microchip USB Analyzer can activate the internal termination resistors by setting the "termination" option ON, or OFF to to deactivate them. As I've observed, both with my oscilloscope and captured USB packets below, you must send "0" to turn it ON, and "1" to turn it OFF.
Quoted 1 line
From the schematics in the user's guide, I can confirm that you must
drive the CAN_RES signal LOW "0" to activate the resistors.
Reverse the argument value of usb_msg.termination to fix this.
These are the two commands sequence, ON then OFF.
Quoted 7 lines
No. Time Source Destination Protocol Length Info 1 0.000000 host 1.3.1 USB 46 URB_BULK outFrame 1: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) USB URB
Leftover Capture Data:a80000000000000000000000000000000000a8
Quoted 6 lines
No. Time Source Destination Protocol Length Info 2 4.372547 host 1.3.1 USB 46 URB_BULK outFrame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) USB URB
Leftover Capture Data:a80100000000000000000000000000000000a9
--- drivers/net/can/usb/mcba_usb.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/can/usb/mcba_usb.c +7 -3
@@ -47,6 +47,10 @@#define MCBA_VER_REQ_USB 1#define MCBA_VER_REQ_CAN 2 +/* Drive the CAN_RES signal LOW "0" to activate R24 and R25 */ +#define MCBA_VER_TERMINATION_ON 0 +#define MCBA_VER_TERMINATION_OFF 1 +#define MCBA_SIDL_EXID_MASK 0x8#define MCBA_DLC_MASK 0xf#define MCBA_DLC_RTR_MASK 0x40
@@ -469,7 +473,7 @@ static void mcba_usb_process_ka_usb(struct mcba_priv *priv, priv->usb_ka_first_pass = false; } -if (msg->termination_state) +if (msg->termination_state ==MCBA_VER_TERMINATION_ON ) priv->can.termination =MCBA_TERMINATION_ENABLED ;else priv->can.termination =MCBA_TERMINATION_DISABLED ;
@@ -789,9 +793,9 @@ static int mcba_set_termination(struct net_device *netdev, u16 term) };if (term ==MCBA_TERMINATION_ENABLED ) - usb_msg.termination =1 ; + usb_msg.termination =MCBA_VER_TERMINATION_ON ;else - usb_msg.termination =0 ; + usb_msg.termination =MCBA_VER_TERMINATION_OFF ;mcba_usb_xmit_cmd (priv, (struct mcba_usb_msg *)&usb_msg);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 11/14 net: fec: dont reset irq coalesce settings to defaults on "ip link up"
In reply to Greg Kroah-HartmanFrom: Rasmus Villemoes <[email protected]>
[ Upstream commit df727d4547de568302b0ed15b0d4e8a469bdb456 ]
Currently, when a FEC device is brought up, the irq coalesce settings are reset to their default values (1000us, 200 frames). That's unexpected, and breaks for example use of an appropriate .link file to make systemd-udev apply the desired
settings (https://www.freedesktop.org/software/systemd/man/systemd.link.html),
or any other method that would do a one-time setup during early boot.
Refactor the code so that fec_restart() instead uses fec_enet_itr_coal_set(), which simply applies the settings that are stored in the private data, and initialize that private data with the default values.
--- drivers/net/ethernet/freescale/fec_main.c | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-)
drivers/net/ethernet/freescale/fec_main.c +6 -16
@@ -72,7 +72,7 @@#include "fec.h" static void set_multicast_list (struct net_device *ndev); -static void fec_enet_itr_coal_init (struct net_device *ndev); +static void fec_enet_itr_coal_set (struct net_device *ndev);#define DRIVER_NAME "fec"
@@ -1163,8 +1163,7 @@ fec_restart(struct net_device *ndev)writel (0 , fep->hwp +FEC_IMASK );/* Init the interrupt coalescing */ -fec_enet_itr_coal_init (ndev); - +fec_enet_itr_coal_set (ndev); }static void fec_enet_stop_mode (struct fec_enet_private *fep,bool enabled)
@@ -2760,19 +2759,6 @@ static int fec_enet_set_coalesce(struct net_device *ndev,return 0 ; } -static void fec_enet_itr_coal_init (struct net_device *ndev) -{ -struct ethtool_coalesce ec; - - ec.rx_coalesce_usecs =FEC_ITR_ICTT_DEFAULT ; - ec.rx_max_coalesced_frames =FEC_ITR_ICFT_DEFAULT ; - - ec.tx_coalesce_usecs =FEC_ITR_ICTT_DEFAULT ; - ec.tx_max_coalesced_frames =FEC_ITR_ICFT_DEFAULT ; - -fec_enet_set_coalesce (ndev, &ec,NULL ,NULL ); -} -static int fec_enet_get_tunable (struct net_device *netdev,const struct ethtool_tunable *tuna,void *data)
@@ -3526,6 +3512,10 @@ static int fec_enet_init(struct net_device *ndev) fep->rx_align =0x3 ; fep->tx_align =0x3 ;#endif + fep->rx_pkts_itr =FEC_ITR_ICFT_DEFAULT ; + fep->tx_pkts_itr =FEC_ITR_ICFT_DEFAULT ; + fep->rx_time_itr =FEC_ITR_ICTT_DEFAULT ; + fep->tx_time_itr =FEC_ITR_ICTT_DEFAULT ;/* Check mask of the streaming and coherent API */ ret =dma_set_mask_and_coherent (&fep->pdev->dev,DMA_BIT_MASK (32 ));
Signature · 1 line
2.35.1
Re: [PATCH 5.15 11/14] net: fec: dont reset irq coalesce settings to defaults on "ip link up"
Quoted 3 lines · Greg Kroah-Hartman
From: Rasmus Villemoes <[email protected]>
[ Upstream commit
df727d4547de568302b0ed15b0d4e8a469bdb456]
You should not take this unless you at the same time also take
commit 7e6303567ce3ca506e4a2704e4baa86f1d8bde02
Author: Rasmus Villemoes <[email protected]> Date: Mon Dec 5 21:46:04 2022 +0100
net: fec: properly guard irq coalesce setup
which
defaults on "ip link up")
The same of course applies to the 6.0.y series.
I don't know if your scripts already do this and it just somehow failed here, but it would probably be a good idea to always check if there is already a Fixes for a commit that gets chosen for -stable.
Rasmus
Greg Kroah-Hartman
maintainerRe: [PATCH 5.15 11/14] net: fec: dont reset irq coalesce settings to defaults on "ip link up"
Quoted 15 lines · Rasmus Villemoes
Quoted 3 lines · Greg Kroah-Hartman
From: Rasmus Villemoes <[email protected]>
[ Upstream commit
df727d4547de568302b0ed15b0d4e8a469bdb456]You should not take this unless you at the same time also take
commit
7e6303567ce3ca506e4a2704e4baa86f1d8bde02Author: Rasmus Villemoes <[email protected]> Date: Mon Dec 5 21:46:04 2022 +0100net: fec: properly guard irq coalesce setup
which
Quoted 8 lines
Fixes df727d4547de (net: fec: don't reset irq coalesce settings todefaults on "ip link up")
The same of course applies to the 6.0.y series.
I don't know if your scripts already do this and it just somehow failed here, but it would probably be a good idea to always check if there is already a Fixes for a commit that gets chosen for -stable.
Ick, sorry, I thought I did run my "are there fixes for the queue" script, but it looks like I did not at all, thank you for catching this! I've now queued it up.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 12/14 ASoC: cs42l51: Correct PGA Volume minimum value
In reply to Greg Kroah-HartmanFrom: Charles Keepax <[email protected]>
[ Upstream commit 3d1bb6cc1a654c8693a85b1d262e610196edec8b ]
The table in the datasheet actually shows the volume values in the wrong order, with the two -3dB values being reversed. This appears to have caused the lower of the two values to be used in the driver when the higher should have been, correct this mixup.
--- sound/soc/codecs/cs42l51.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/cs42l51.c +1 -1
@@ -146,7 +146,7 @@ static const struct snd_kcontrol_new cs42l51_snd_controls[] = { 0, 0xA0, 96, adc_att_tlv),SOC_DOUBLE_R_SX_TLV ("PGA Volume" ,CS42L51_ALC_PGA_CTL ,CS42L51_ALC_PGB_CTL , -0 ,0x19 ,30 , pga_tlv), +0 ,0x1A ,30 , pga_tlv),SOC_SINGLE ("Playback Deemphasis Switch" ,CS42L51_DAC_CTL ,3 ,1 ,0 ),SOC_SINGLE ("Auto-Mute Switch" ,CS42L51_DAC_CTL ,2 ,1 ,0 ), SOC_SINGLE("Soft Ramp Switch", CS42L51_DAC_CTL, 1, 1, 0),
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 13/14 perf: Fix perf_pending_task() UaF
In reply to Greg Kroah-HartmanFrom: Peter Zijlstra <[email protected]>
[ Upstream commit 517e6a301f34613bff24a8e35b5455884f2d83d8 ]
Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases:
- the task_work was already queued before destroying the event;
- destroying the event itself queues the task_work.
The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry.
The simplest alternative is extending the perf_event lifetime to cover the task_work.
The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down.
--- kernel/events/core.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
kernel/events/core.c +13 -4
@@ -2367,6 +2367,7 @@ event_sched_out(struct perf_event *event, !event->pending_work) { event->pending_work =1 ; dec = false; +WARN_ON_ONCE (!atomic_long_inc_not_zero (&event->refcount));task_work_add (current, &event->pending_task,TWA_RESUME ); }if (dec)
@@ -2412,6 +2413,7 @@ group_sched_out(struct perf_event *group_event,#define DETACH_GROUP 0x01UL#define DETACH_CHILD 0x02UL +#define DETACH_DEAD 0x04UL/* * Cross CPU call to remove a performance event
@@ -2432,12 +2434,20 @@ __perf_remove_from_context(struct perf_event *event,update_cgrp_time_from_cpuctx (cpuctx, false); } +/* +* Ensure event_sched_out() switches to OFF, at the very least +* this avoids raising perf_pending_task() at this time. +*/ +if (flags &DETACH_DEAD ) + event->pending_disable =1 ;event_sched_out (event, cpuctx, ctx);if (flags &DETACH_GROUP )perf_group_detach (event);if (flags &DETACH_CHILD )perf_child_detach (event);list_del_event (event, ctx); +if (flags &DETACH_DEAD ) + event->state =PERF_EVENT_STATE_DEAD ;if (!ctx->nr_events && ctx->is_active) {if (ctx == &cpuctx->ctx)
@@ -5212,9 +5222,7 @@ int perf_event_release_kernel(struct perf_event *event) ctx =perf_event_ctx_lock (event);WARN_ON_ONCE (ctx->parent_ctx); -perf_remove_from_context (event,DETACH_GROUP ); -raw_spin_lock_irq (&ctx->lock);/* * Mark this event as STATE_DEAD, there is no external reference to it * anymore.
@@ -5226,8 +5234,7 @@ int perf_event_release_kernel(struct perf_event *event)* Thus this guarantees that we will in fact observe and kill _ALL_ * child events. */ - event->state =PERF_EVENT_STATE_DEAD ; -raw_spin_unlock_irq (&ctx->lock); +perf_remove_from_context (event,DETACH_GROUP |DETACH_DEAD );perf_event_ctx_unlock (event, ctx);
@@ -6662,6 +6669,8 @@ static void perf_pending_task(struct callback_head *head)if (rctx >=0 )perf_swevent_put_recursion_context (rctx);preempt_enable_notrace (); + +put_event (event); }/*
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 14/14 nvme-pci: clear the prp2 field when not used
In reply to Greg Kroah-HartmanFrom: Lei Rao <[email protected]>
[ Upstream commit a56ea6147facce4ac1fc38675455f9733d96232b ]
If the prp2 field is not filled in nvme_setup_prp_simple(), the prp2 field is garbage data. According to nvme spec, the prp2 is reserved if the data transfer does not cross a memory page boundary, so clear it to zero if it is not used.
--- drivers/nvme/host/pci.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/nvme/host/pci.c +2 -0
@@ -814,6 +814,8 @@ static blk_status_t nvme_setup_prp_simple(struct nvme_dev *dev, cmnd->dptr.prp1 =cpu_to_le64 (iod->first_dma);if (bv->bv_len > first_prp_len) cmnd->dptr.prp2 =cpu_to_le64 (iod->first_dma + first_prp_len); +else + cmnd->dptr.prp2 =0 ;return BLK_STS_OK ; }
Signature · 1 line
2.35.1
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and powerpc (ps3_defconfig, GCC 12.2.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 8 lines
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
Quoted 7 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
Compiled and booted on my x86_64 and ARM64 test systems. No errors or regressions.
Thanks.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.15.84-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: 1d22ad610255f0c61903c1e4fefce61227ec73b6
* git describe: v5.15.83-15-g1d22ad610255
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.83-15-g1d22ad610255
## Test Regressions (compared to v5.15.82-124-gd731c63c25d1)
## Metric Regressions (compared to v5.15.82-124-gd731c63c25d1)
## Test Fixes (compared to v5.15.82-124-gd731c63c25d1)
## Metric Fixes (compared to v5.15.82-124-gd731c63c25d1)
## Test result summary
total: 144723, pass: 125385, fail: 3089, skip: 15690, xfail: 559
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 151 total, 148 passed, 3 failed
* arm64: 49 total, 47 passed, 2 failed
* i386: 39 total, 35 passed, 4 failed
* mips: 31 total, 29 passed, 2 failed
* parisc: 8 total, 8 passed, 0 failed
* powerpc: 34 total, 32 passed, 2 failed
* riscv: 14 total, 14 passed, 0 failed
* s390: 16 total, 14 passed, 2 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 42 total, 40 passed, 2 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* lt[
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 114 pass, 0 failLinux version: 5.15.84-rc1-g1d22ad610255
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
Build test (gcc version 12.2.1 20221127):
mips: 62 configs -> no failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/2363
[2]. https://openqa.qa.codethink.co.uk/tests/2369
[3]. https://openqa.qa.codethink.co.uk/tests/2365
Signature · 2 lines
Regards Sudip
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 489 pass: 489 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.84 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).