5.10.238-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 154/270 arm64: tegra: p2597: Fix gpio for vdd-1v8-dis regulator
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Diogo Ivo <[email protected]>
[ Upstream commit f34621f31e3be81456c903287f7e4c0609829e29 ]
According to the board schematics the enable pin of this regulator is connected to gpio line #9 of the first instance of the TCA9539 GPIO expander, so adjust it.
--- arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi +1 -1
@@ -1638,7 +1638,7 @@ vdd_1v8_dis: regulator@7 { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-always-on; - gpio = <&exp1 14 GPIO_ACTIVE_HIGH>; + gpio = <&exp1 9 GPIO_ACTIVE_HIGH>; enable-active-high; vin-supply = <&vdd_1v8>; };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 155/270 powerpc/prom_init: Fixup missing #size-cells on PowerBook6,7
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Schwab <[email protected]>
[ Upstream commit 7e67ef889c9ab7246547db73d524459f47403a77 ]
Similar to the PowerMac3,1, the PowerBook6,7 is missing the #size-cells property on the i2s node.
Depends-on: commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling")
--- arch/powerpc/kernel/prom_init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/powerpc/kernel/prom_init.c +2 -2
@@ -2944,11 +2944,11 @@ static void __init fixup_device_tree_pmac(void)char type[8 ];phandle node; -// Some pmacs are missing #size-cells on escc nodes +// Some pmacs are missing #size-cells on escc or i2s nodes for (node =0 ;prom_next_node (&node); ) { type[0 ] ='\0' ;prom_getprop (node,"device_type" , type,sizeof (type)); -if (prom_strcmp (type,"escc" )) +if (prom_strcmp (type,"escc" ) &&prom_strcmp (type,"i2s" ))continue ;if (prom_getproplen (node,"#size-cells" ) !=PROM_ERROR )
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 156/270 tcp: bring back NUMA dispersion in inet_ehash_locks_alloc()
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 f8ece40786c9342249aa0a1b55e148ee23b2a746 ]
We have platforms with 6 NUMA nodes and 480 cpus.
inet_ehash_locks_alloc() currently allocates a single 64KB page to hold all ehash spinlocks. This adds more pressure on a single node.
Change inet_ehash_locks_alloc() to use vmalloc() to spread the spinlocks on all online nodes, driven by NUMA policies.
At boot time, NUMA policy is interleave=all, meaning that tcp_hashinfo.ehash_locks gets hash dispersion on all nodes.
Tested:
lack5:~# grep inet_ehash_locks_alloc /proc/vmallocinfo 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2
lack5:~# echo 8192 >/proc/sys/net/ipv4/tcp_child_ehash_entries lack5:~# numactl --interleave=all unshare -n bash -c "grep inet_ehash_locks_alloc /proc/vmallocinfo" 0x000000004e99d30c-0x00000000763f3279 36864 inet_ehash_locks_alloc+0x90/0x100 pages=8 vmalloc N0=1 N1=2 N2=2 N3=1 N4=1 N5=1 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2
lack5:~# numactl --interleave=0,5 unshare -n bash -c "grep inet_ehash_locks_alloc /proc/vmallocinfo" 0x00000000fd73a33e-0x0000000004b9a177 36864 inet_ehash_locks_alloc+0x90/0x100 pages=8 vmalloc N0=4 N5=4 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2
lack5:~# echo 1024 >/proc/sys/net/ipv4/tcp_child_ehash_entries lack5:~# numactl --interleave=all unshare -n bash -c "grep inet_ehash_locks_alloc /proc/vmallocinfo" 0x00000000db07d7a2-0x00000000ad697d29 8192 inet_ehash_locks_alloc+0x90/0x100 pages=1 vmalloc N2=1 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2
--- net/ipv4/inet_hashtables.c | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-)
net/ipv4/inet_hashtables.c +26 -11
@@ -934,22 +934,37 @@ int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo) {unsigned int locksz =sizeof (spinlock_t);unsigned int i, nblocks =1 ; +spinlock_t *ptr =NULL ; -if (locksz !=0 ) { -/* allocate 2 cache lines or at least one spinlock per cpu */ - nblocks =max (2U *L1_CACHE_BYTES / locksz,1U ); - nblocks =roundup_pow_of_two (nblocks *num_possible_cpus ()); +if (locksz ==0 ) + goto set_mask; -/* no more locks than number of hash buckets */ - nblocks =min (nblocks, hashinfo->ehash_mask +1 ); +/* Allocate 2 cache lines or at least one spinlock per cpu. */ + nblocks =max (2U *L1_CACHE_BYTES / locksz,1U ) *num_possible_cpus (); - hashinfo->ehash_locks =kvmalloc_array (nblocks, locksz,GFP_KERNEL ); -if (!hashinfo->ehash_locks) -return -ENOMEM ; +/* At least one page per NUMA node. */ + nblocks =max (nblocks,num_online_nodes () *PAGE_SIZE / locksz); + + nblocks =roundup_pow_of_two (nblocks); + +/* No more locks than number of hash buckets. */ + nblocks =min (nblocks, hashinfo->ehash_mask +1 ); -for (i =0 ; i < nblocks; i++) -spin_lock_init (&hashinfo->ehash_locks[i]); +if (num_online_nodes () >1 ) { +/* Use vmalloc() to allow NUMA policy to spread pages +* on all available nodes if desired. +*/ + ptr =vmalloc_array (nblocks, locksz); + } +if (!ptr) { + ptr =kvmalloc_array (nblocks, locksz,GFP_KERNEL ); +if (!ptr) +return -ENOMEM ; } +for (i =0 ; i < nblocks; i++) +spin_lock_init (&ptr[i]); + hashinfo->ehash_locks = ptr; +set_mask: hashinfo->ehash_locks_mask = nblocks -1 ;return 0 ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 157/270 rtc: ds1307: stop disabling alarms on probe
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
[ Upstream commit dcec12617ee61beed928e889607bf37e145bf86b ]
It is a bad practice to disable alarms on probe or remove as this will prevent alarms across reboots.
--- drivers/rtc/rtc-ds1307.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/rtc/rtc-ds1307.c +1 -3
@@ -1864,10 +1864,8 @@ static int ds1307_probe(struct i2c_client *client,* For some variants, be sure alarms can trigger when we're * running on Vbackup (BBSQI/BBSQW) */ -if (want_irq || ds1307_can_wakeup_device) { +if (want_irq || ds1307_can_wakeup_device) regs[0 ] |=DS1337_BIT_INTCN | chip->bbsqi_bit; - regs[0 ] &= ~(DS1337_BIT_A2IE |DS1337_BIT_A1IE ); - }regmap_write (ds1307->regmap,DS1337_REG_CONTROL , regs[0 ]);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 158/270 ieee802154: ca8210: Use proper setters and getters for bitwise types
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 169b2262205836a5d1213ff44dca2962276bece1 ]
Sparse complains that the driver doesn't respect the bitwise types:
drivers/net/ieee802154/ca8210.c:1796:27: warning: incorrect type in assignment (different base types)drivers/net/ieee802154/ca8210.c:1796:27: expected restricted __le16 [addressable] [assigned] [usertype] pan_iddrivers/net/ieee802154/ca8210.c:1796:27: got unsigned short [usertype]drivers/net/ieee802154/ca8210.c:1801:25: warning: incorrect type in assignment (different base types)drivers/net/ieee802154/ca8210.c:1801:25: expected restricted __le16 [addressable] [assigned] [usertype] pan_iddrivers/net/ieee802154/ca8210.c:1801:25: got unsigned short [usertype]drivers/net/ieee802154/ca8210.c:1928:28: warning: incorrect type in argument 3 (different base types)drivers/net/ieee802154/ca8210.c:1928:28: expected unsigned short [usertype] dst_pan_iddrivers/net/ieee802154/ca8210.c:1928:28: got restricted __le16 [addressable] [usertype] pan_id
Use proper setters and getters for bitwise types.
Note, in accordance with [1] the protocol is little endian.
--- drivers/net/ieee802154/ca8210.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/net/ieee802154/ca8210.c +4 -5
@@ -1488,8 +1488,7 @@ static u8 mcps_data_request( command.pdata.data_req.src_addr_mode = src_addr_mode; command.pdata.data_req.dst.mode = dst_address_mode;if (dst_address_mode !=MAC_MODE_NO_ADDR ) { - command.pdata.data_req.dst.pan_id[0 ] =LS_BYTE (dst_pan_id); - command.pdata.data_req.dst.pan_id[1 ] =MS_BYTE (dst_pan_id); +put_unaligned_le16 (dst_pan_id, command.pdata.data_req.dst.pan_id);if (dst_address_mode ==MAC_MODE_SHORT_ADDR ) { command.pdata.data_req.dst.address[0 ] =LS_BYTE ( dst_addr->short_address
@@ -1838,12 +1837,12 @@ static int ca8210_skb_rx( } hdr.source.mode = data_ind[0 ];dev_dbg (&priv->spi->dev,"srcAddrMode: %#03x\n" , hdr.source.mode); - hdr.source.pan_id = *(u16 *)&data_ind[1 ]; + hdr.source.pan_id =cpu_to_le16 (get_unaligned_le16 (&data_ind[1 ]));dev_dbg (&priv->spi->dev,"srcPanId: %#06x\n" , hdr.source.pan_id);memcpy (&hdr.source.extended_addr, &data_ind[3 ],8 ); hdr.dest.mode = data_ind[11 ];dev_dbg (&priv->spi->dev,"dstAddrMode: %#03x\n" , hdr.dest.mode); - hdr.dest.pan_id = *(u16 *)&data_ind[12 ]; + hdr.dest.pan_id =cpu_to_le16 (get_unaligned_le16 (&data_ind[12 ]));dev_dbg (&priv->spi->dev,"dstPanId: %#06x\n" , hdr.dest.pan_id);memcpy (&hdr.dest.extended_addr, &data_ind[14 ],8 );
@@ -1970,7 +1969,7 @@ static int ca8210_skb_tx( status = mcps_data_request( header.source.mode, header.dest.mode, - header.dest.pan_id, + le16_to_cpu(header.dest.pan_id), (union macaddr *)&header.dest.extended_addr, skb->len - mac_len, &skb->data[mac_len],
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 159/270 ARM: tegra: Switch DSI-B clock parent to PLLD on Tegra114
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Svyatoslav Ryhel <[email protected]>
[ Upstream commit 2b3db788f2f614b875b257cdb079adadedc060f3 ]
PLLD is usually used as parent clock for internal video devices, like DSI for example, while PLLD2 is used as parent for HDMI.
--- arch/arm/boot/dts/tegra114.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/tegra114.dtsi +1 -1
@@ -126,7 +126,7 @@ dsi@54400000 { reg = <0x54400000 0x00040000>; clocks = <&tegra_car TEGRA114_CLK_DSIB>, <&tegra_car TEGRA114_CLK_DSIBLP>, - <&tegra_car TEGRA114_CLK_PLL_D2_OUT0>; + <&tegra_car TEGRA114_CLK_PLL_D_OUT0>; clock-names = "dsi", "lp", "parent"; resets = <&tegra_car 82>; reset-names = "dsi";
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 160/270 media: c8sectpfe: Call of_node_put(i2c_bus) only once in c8sectpfe_probe()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Elfring <[email protected]>
[ Upstream commit b773530a34df0687020520015057075f8b7b4ac4 ]
An of_node_put(i2c_bus) call was immediately used after a pointer check for an of_find_i2c_adapter_by_node() call in this function implementation. Thus call such a function only once instead directly before the check.
This issue was transformed by using the Coccinelle software.
--- drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c +1 -2
@@ -811,13 +811,12 @@ static int c8sectpfe_probe(struct platform_device *pdev) } tsin->i2c_adapter =of_find_i2c_adapter_by_node (i2c_bus); +of_node_put (i2c_bus);if (!tsin->i2c_adapter) {dev_err (&pdev->dev,"No i2c adapter found\n" ); -of_node_put (i2c_bus); ret = -ENODEV ; goto err_clk_disable; } -of_node_put (i2c_bus); tsin->rst_gpio =of_get_named_gpio (child,"reset-gpios" ,0 );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 161/270 dm cache: prevent BUG_ON by blocking retries on failed device resumes
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming-Hung Tsai <[email protected]>
[ Upstream commit 5da692e2262b8f81993baa9592f57d12c2703dea ]
A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object.
Reproduce steps:
1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.
cat <<EOF >> cmeta.xml
<superblock uuid="" block_size="128" nr_cache_blocks="512" \
policy="smq" hint_width="4">
<mappings>
<mapping cache_block="0" origin_block="0" dirty="false"/>
</mappings>
</superblock>
EOF
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta
2. wipe the second array block of the mapping array to simulate data degradations.
mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \
2>/dev/null | hexdump -e '1/8 "%u\n"')
ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \
2>/dev/null | hexdump -e '1/8 "%u\n"')
dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock
3. try bringing up the cache device. The resume is expected to fail due to the broken array block.
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable
dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache
4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.
dmsetup resume cache
Kernel logs:
(snip)
------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570
Fix by disallowing resume operations for devices that failed the initial attempt.
--- drivers/md/dm-cache-target.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/md/dm-cache-target.c +24 -0
@@ -2958,6 +2958,27 @@ static dm_cblock_t get_cache_dev_size(struct cache *cache)return to_cblock (size); } +static bool can_resume (struct cache *cache) +{ +/* +* Disallow retrying the resume operation for devices that failed the +* first resume attempt, as the failure leaves the policy object partially +* initialized. Retrying could trigger BUG_ON when loading cache mappings +* into the incomplete policy object. +*/ +if (cache->sized && !cache->loaded_mappings) { +if (get_cache_mode (cache) !=CM_WRITE ) +DMERR ("%s: unable to resume a failed-loaded cache, please check metadata." , +cache_device_name (cache)); +else +DMERR ("%s: unable to resume cache due to missing proper cache table reload" , +cache_device_name (cache)); +return false; + } + +return true; +} +static bool can_resize (struct cache *cache,dm_cblock_t new_size) {if (from_cblock (new_size) >from_cblock (cache->cache_size)) {
@@ -3006,6 +3027,9 @@ static int cache_preresume(struct dm_target *ti)struct cache *cache = ti->private;dm_cblock_t csize =get_cache_dev_size (cache); +if (!can_resume (cache)) +return -EINVAL ; +/* * Check to see if the cache has resized. */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 162/270 orangefs: Do not truncate file size
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Wilcox (Oracle) <[email protected]>
[ Upstream commit 062e8093592fb866b8e016641a8b27feb6ac509d ]
'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.
--- fs/orangefs/inode.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
fs/orangefs/inode.c +3 -4
@@ -22,9 +22,9 @@ static int orangefs_writepage_locked(struct page *page,struct orangefs_write_range *wr =NULL ;struct iov_iter iter;struct bio_vec bv; -size_t len, wlen; +size_t wlen;ssize_t ret; -loff_t off; +loff_t len, off;set_page_writeback (page);
@@ -93,8 +93,7 @@ static int orangefs_writepages_work(struct orangefs_writepages *ow,struct orangefs_write_range *wrp, wr;struct iov_iter iter;ssize_t ret; -size_t len; -loff_t off; +loff_t len, off;int i; len =i_size_read (inode);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 163/270 drm/amdgpu: Do not program AGP BAR regs under SRIOV in gfxhub_v1_0.c
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victor Lu <[email protected]>
[ Upstream commit 057fef20b8401110a7bc1c2fe9d804a8a0bf0d24 ]
SRIOV VF does not have write access to AGP BAR regs. Skip the writes to avoid a dmesg warning.
--- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c +5 -5
@@ -70,12 +70,12 @@ static void gfxhub_v1_0_init_system_aperture_regs(struct amdgpu_device *adev) {uint64_t value; -/* Program the AGP BAR */ -WREG32_SOC15_RLC (GC ,0 , mmMC_VM_AGP_BASE,0 ); -WREG32_SOC15_RLC (GC ,0 , mmMC_VM_AGP_BOT, adev->gmc.agp_start >>24 ); -WREG32_SOC15_RLC (GC ,0 , mmMC_VM_AGP_TOP, adev->gmc.agp_end >>24 ); -if (!amdgpu_sriov_vf (adev) || adev->asic_type <=CHIP_VEGA10 ) { +/* Program the AGP BAR */ +WREG32_SOC15_RLC (GC ,0 , mmMC_VM_AGP_BASE,0 ); +WREG32_SOC15_RLC (GC ,0 , mmMC_VM_AGP_BOT, adev->gmc.agp_start >>24 ); +WREG32_SOC15_RLC (GC ,0 , mmMC_VM_AGP_TOP, adev->gmc.agp_end >>24 ); +/* Program the system aperture low logical page number. */ WREG32_SOC15_RLC (GC ,0 , mmMC_VM_SYSTEM_APERTURE_LOW_ADDR,min (adev->gmc.fb_start, adev->gmc.agp_start) >>18 );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 164/270 media: cx231xx: set device_caps for 417
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ Upstream commit a79efc44b51432490538a55b9753a721f7d3ea42 ]
The video_device for the MPEG encoder did not set device_caps.
Add this, otherwise the video device can't be registered (you get a WARN_ON instead).
Not seen before since currently 417 support is disabled, but I found this while experimenting with it.
--- drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/media/usb/cx231xx/cx231xx-417.c +2 -0
@@ -1722,6 +1722,8 @@ static void cx231xx_video_dev_init( vfd->lock = &dev->lock; vfd->release = video_device_release_empty; vfd->ctrl_handler = &dev->mpeg_ctrl_handler.hdl; + vfd->device_caps =V4L2_CAP_READWRITE |V4L2_CAP_STREAMING | +V4L2_CAP_VIDEO_CAPTURE ;video_set_drvdata (vfd, dev);if (dev->tuner_type ==TUNER_ABSENT ) {v4l2_disable_ioctl (vfd,VIDIOC_G_FREQUENCY );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 165/270 pinctrl: bcm281xx: Use "unsigned int" instead of bare "unsigned"
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artur Weber <[email protected]>
[ Upstream commit 07b5a2a13f4704c5eae3be7277ec54ffdba45f72 ]
Replace uses of bare "unsigned" with "unsigned int" to fix checkpatch warnings. No functional change.
--- drivers/pinctrl/bcm/pinctrl-bcm281xx.c | 44 +++++++++++++------------- 1 file changed, 22 insertions(+), 22 deletions(-)
drivers/pinctrl/bcm/pinctrl-bcm281xx.c +22 -22
@@ -79,7 +79,7 @@ static enum bcm281xx_pin_type hdmi_pin = BCM281XX_PIN_TYPE_HDMI;struct bcm281xx_pin_function {const char *name;const char *const *groups; -const unsigned ngroups; +const unsigned int ngroups; };/*
@@ -91,10 +91,10 @@ struct bcm281xx_pinctrl_data {/* List of all pins */ const struct pinctrl_pin_desc *pins; -const unsigned npins; +const unsigned int npins;const struct bcm281xx_pin_function *functions; -const unsigned nfunctions; +const unsigned int nfunctions;struct regmap *regmap; };
@@ -948,7 +948,7 @@ static struct bcm281xx_pinctrl_data bcm281xx_pinctrl = { };static inline enum bcm281xx_pin_type pin_type_get (struct pinctrl_dev *pctldev, -unsigned pin) +unsigned int pin) {struct bcm281xx_pinctrl_data *pdata =pinctrl_dev_get_drvdata (pctldev);
@@ -992,7 +992,7 @@ static int bcm281xx_pinctrl_get_groups_count(struct pinctrl_dev *pctldev) }static const char *bcm281xx_pinctrl_get_group_name (struct pinctrl_dev *pctldev, -unsigned group) +unsigned int group) {struct bcm281xx_pinctrl_data *pdata =pinctrl_dev_get_drvdata (pctldev);
@@ -1000,9 +1000,9 @@ static const char *bcm281xx_pinctrl_get_group_name(struct pinctrl_dev *pctldev, }static int bcm281xx_pinctrl_get_group_pins (struct pinctrl_dev *pctldev, -unsigned group, +unsigned int group,const unsigned **pins, -unsigned *num_pins) +unsigned int *num_pins) {struct bcm281xx_pinctrl_data *pdata =pinctrl_dev_get_drvdata (pctldev);
@@ -1014,7 +1014,7 @@ static int bcm281xx_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,static void bcm281xx_pinctrl_pin_dbg_show (struct pinctrl_dev *pctldev,struct seq_file *s, -unsigned offset) +unsigned int offset) {seq_printf (s," %s" ,dev_name (pctldev->dev)); }
@@ -1036,7 +1036,7 @@ static int bcm281xx_pinctrl_get_fcns_count(struct pinctrl_dev *pctldev) }static const char *bcm281xx_pinctrl_get_fcn_name (struct pinctrl_dev *pctldev, -unsigned function) +unsigned int function) {struct bcm281xx_pinctrl_data *pdata =pinctrl_dev_get_drvdata (pctldev);
@@ -1044,9 +1044,9 @@ static const char *bcm281xx_pinctrl_get_fcn_name(struct pinctrl_dev *pctldev, }static int bcm281xx_pinctrl_get_fcn_groups (struct pinctrl_dev *pctldev, -unsigned function, +unsigned int function,const char *const **groups, -unsigned *const num_groups) +unsigned int *const num_groups) {struct bcm281xx_pinctrl_data *pdata =pinctrl_dev_get_drvdata (pctldev);
@@ -1057,8 +1057,8 @@ static int bcm281xx_pinctrl_get_fcn_groups(struct pinctrl_dev *pctldev, }static int bcm281xx_pinmux_set (struct pinctrl_dev *pctldev, -unsigned function, -unsigned group) +unsigned int function, +unsigned int group) {struct bcm281xx_pinctrl_data *pdata =pinctrl_dev_get_drvdata (pctldev);const struct bcm281xx_pin_function *f = &pdata->functions[function];
@@ -1089,7 +1089,7 @@ static const struct pinmux_ops bcm281xx_pinctrl_pinmux_ops = { };static int bcm281xx_pinctrl_pin_config_get (struct pinctrl_dev *pctldev, -unsigned pin, +unsigned int pin,unsigned long *config) {return -ENOTSUPP ;
@@ -1098,9 +1098,9 @@ static int bcm281xx_pinctrl_pin_config_get(struct pinctrl_dev *pctldev,/* Goes through the configs and update register val/mask */ static int bcm281xx_std_pin_update (struct pinctrl_dev *pctldev, -unsigned pin, +unsigned int pin,unsigned long *configs, -unsigned num_configs, +unsigned int num_configs,u32 *val,u32 *mask) {
@@ -1214,9 +1214,9 @@ static const u16 bcm281xx_pullup_map[] = {/* Goes through the configs and update register val/mask */ static int bcm281xx_i2c_pin_update (struct pinctrl_dev *pctldev, -unsigned pin, +unsigned int pin,unsigned long *configs, -unsigned num_configs, +unsigned int num_configs,u32 *val,u32 *mask) {
@@ -1284,9 +1284,9 @@ static int bcm281xx_i2c_pin_update(struct pinctrl_dev *pctldev,/* Goes through the configs and update register val/mask */ static int bcm281xx_hdmi_pin_update (struct pinctrl_dev *pctldev, -unsigned pin, +unsigned int pin,unsigned long *configs, -unsigned num_configs, +unsigned int num_configs,u32 *val,u32 *mask) {
@@ -1328,9 +1328,9 @@ static int bcm281xx_hdmi_pin_update(struct pinctrl_dev *pctldev, }static int bcm281xx_pinctrl_pin_config_set (struct pinctrl_dev *pctldev, -unsigned pin, +unsigned int pin,unsigned long *configs, -unsigned num_configs) +unsigned int num_configs) {struct bcm281xx_pinctrl_data *pdata =pinctrl_dev_get_drvdata (pctldev);enum bcm281xx_pin_type pin_type;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 166/270 net: ethernet: ti: cpsw_new: populate netdev of_node
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Sverdlin <[email protected]>
[ Upstream commit 7ff1c88fc89688c27f773ba956f65f0c11367269 ]
So that of_find_net_device_by_node() can find CPSW ports and other DSA switches can be stacked downstream. Tested in conjunction with KSZ8873.
--- drivers/net/ethernet/ti/cpsw_new.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/ti/cpsw_new.c +1 -0
@@ -1427,6 +1427,7 @@ static int cpsw_create_ports(struct cpsw_common *cpsw) ndev->netdev_ops = &cpsw_netdev_ops; ndev->ethtool_ops = &cpsw_ethtool_ops;SET_NETDEV_DEV (ndev, dev); + ndev->dev.of_node = slave_data->slave_node;if (!napi_ndev) {/* CPSW Host port CPDMA interface is shared between
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 167/270 net: pktgen: fix mpls maximum labels list parsing
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Seiderer <[email protected]>
[ Upstream commit 2b15a0693f70d1e8119743ee89edbfb1271b3ea8 ]
Fix mpls maximum labels list parsing up to MAX_MPLS_LABELS entries (instead of up to MAX_MPLS_LABELS - 1).
Addresses the following:
$ echo "mpls 00000f00,00000f01,00000f02,00000f03,00000f04,00000f05,00000f06,00000f07,00000f08,00000f09,00000f0a,00000f0b,00000f0c,00000f0d,00000f0e,00000f0f" > /proc/net/pktgen/lo\@0 -bash: echo: write error: Argument list too long
--- net/core/pktgen.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/core/pktgen.c +4 -2
@@ -805,6 +805,10 @@ static ssize_t get_labels(const char __user *buffer, struct pktgen_dev *pkt_dev) pkt_dev->nr_labels =0 ; do { __u32 tmp; + + if (n >= MAX_MPLS_LABELS) + return -E2BIG; + len = hex32_arg(&buffer[i], 8, &tmp); if (len <= 0) return len;
@@ -816,8 +820,6 @@ static ssize_t get_labels(const char __user *buffer, struct pktgen_dev *pkt_dev)return -EFAULT ; i++; n++; -if (n >=MAX_MPLS_LABELS ) -return -E2BIG ; }while (c ==',' ); pkt_dev->nr_labels = n;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 168/270 ipv4: fib: Move fib_valid_key_len() to rtm_to_fib_config().
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 254ba7e6032d3fc738050d500b0c1d8197af90ca ]
fib_valid_key_len() is called in the beginning of fib_table_insert() or fib_table_delete() to check if the prefix length is valid.
fib_table_insert() and fib_table_delete() are called from 3 paths
- ip_rt_ioctl()
- inet_rtm_newroute() / inet_rtm_delroute()
- fib_magic()
In the first ioctl() path, rtentry_to_fib_config() checks the prefix length with bad_mask(). Also, fib_magic() always passes the correct
prefix: 32 or ifa->ifa_prefixlen, which is already validated.
Let's move fib_valid_key_len() to the rtnetlink path, rtm_to_fib_config().
While at it, 2 direct returns in rtm_to_fib_config() are changed to goto to match other places in the same function
--- net/ipv4/fib_frontend.c | 18 ++++++++++++++++-- net/ipv4/fib_trie.c | 22 ---------------------- 2 files changed, 16 insertions(+), 24 deletions(-)
net/ipv4/fib_frontend.c +16 -2
@@ -817,19 +817,33 @@ static int rtm_to_fib_config(struct net *net, struct sk_buff *skb, } } +if (cfg->fc_dst_len >32 ) { +NL_SET_ERR_MSG (extack,"Invalid prefix length" ); + err = -EINVAL ; + goto errout; + } + +if (cfg->fc_dst_len <32 && (ntohl (cfg->fc_dst) << cfg->fc_dst_len)) { +NL_SET_ERR_MSG (extack,"Invalid prefix for given prefix length" ); + err = -EINVAL ; + goto errout; + } +if (cfg->fc_nh_id) {if (cfg->fc_oif || cfg->fc_gw_family || cfg->fc_encap || cfg->fc_mp) {NL_SET_ERR_MSG (extack,"Nexthop specification and nexthop id are mutually exclusive" ); -return -EINVAL ; + err = -EINVAL ; + goto errout; } }if (has_gw && has_via) {NL_SET_ERR_MSG (extack,"Nexthop configuration can not contain both GATEWAY and VIA" ); -return -EINVAL ; + err = -EINVAL ; + goto errout; }if (!cfg->fc_table)
net/ipv4/fib_trie.c +0 -22
@@ -1145,22 +1145,6 @@ static int fib_insert_alias(struct trie *t, struct key_vector *tp,return 0 ; } -static bool fib_valid_key_len (u32 key,u8 plen,struct netlink_ext_ack *extack) -{ -if (plen >KEYLENGTH ) { -NL_SET_ERR_MSG (extack,"Invalid prefix length" ); -return false; - } - -if ((plen <KEYLENGTH ) && (key << plen)) { -NL_SET_ERR_MSG (extack, -"Invalid prefix for given prefix length" ); -return false; - } - -return true; -} -static void fib_remove_alias (struct trie *t,struct key_vector *tp,struct key_vector *l,struct fib_alias *old);
@@ -1181,9 +1165,6 @@ int fib_table_insert(struct net *net, struct fib_table *tb, key =ntohl (cfg->fc_dst); -if (!fib_valid_key_len (key, plen, extack)) -return -EINVAL ; -pr_debug ("Insert table=%u %08x/%d\n" , tb->tb_id, key, plen); fi =fib_create_info (cfg, extack);
@@ -1671,9 +1652,6 @@ int fib_table_delete(struct net *net, struct fib_table *tb, key =ntohl (cfg->fc_dst); -if (!fib_valid_key_len (key, plen, extack)) -return -EINVAL ; - l =fib_find_node (t, &tp, key);if (!l)return -ESRCH ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 169/270 clk: imx8mp: inform CCF of maximum frequency of clocks
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ahmad Fatoum <[email protected]>
[ Upstream commit 06a61b5cb6a8638fa8823cd09b17233b29696fa2 ]
The IMX8MPCEC datasheet lists maximum frequencies allowed for different modules. Some of these limits are universal, but some depend on whether the SoC is operating in nominal or in overdrive mode.
The imx8mp.dtsi currently assumes overdrive mode and configures some clocks in accordance with this. Boards wishing to make use of nominal mode will need to override some of the clock rates manually.
As operating the clocks outside of their allowed range can lead to difficult to debug issues, it makes sense to register the maximum rates allowed in the driver, so the CCF can take them into account.
--- drivers/clk/imx/clk-imx8mp.c | 151 +++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+)
drivers/clk/imx/clk-imx8mp.c +151 -0
@@ -8,6 +8,7 @@#include <linux/err.h> #include <linux/io.h> #include <linux/module.h> +#include <linux/units.h> #include <linux/of_address.h> #include <linux/platform_device.h> #include <linux/slab.h>
@@ -417,11 +418,151 @@ static const char * const imx8mp_clkout_sels[] = {"audio_pll1_out", "audio_pll2_static struct clk_hw **hws;static struct clk_hw_onecell_data *clk_hw_data; +struct imx8mp_clock_constraints { +unsigned int clkid; +u32 maxrate; +}; + +/* +* Below tables are taken from IMX8MPCEC Rev. 2.1, 07/2023 +* Table 13. Maximum frequency of modules. +* Probable typos fixed are marked with a comment. +*/ +static const struct imx8mp_clock_constraints imx8mp_clock_common_constraints[] = { + {IMX8MP_CLK_A53_DIV ,1000 *HZ_PER_MHZ }, + {IMX8MP_CLK_ENET_AXI ,266666667 },/* Datasheet claims 266MHz */ + {IMX8MP_CLK_NAND_USDHC_BUS ,266666667 },/* Datasheet claims 266MHz */ + {IMX8MP_CLK_MEDIA_APB ,200 *HZ_PER_MHZ }, + {IMX8MP_CLK_HDMI_APB ,133333333 },/* Datasheet claims 133MHz */ + {IMX8MP_CLK_ML_AXI ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_AHB ,133333333 }, + {IMX8MP_CLK_IPG_ROOT ,66666667 }, + {IMX8MP_CLK_AUDIO_AHB ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_DISP2_PIX ,170 *HZ_PER_MHZ }, + {IMX8MP_CLK_DRAM_ALT ,666666667 }, + {IMX8MP_CLK_DRAM_APB ,200 *HZ_PER_MHZ }, + {IMX8MP_CLK_CAN1 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_CAN2 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_PCIE_AUX ,10 *HZ_PER_MHZ }, + {IMX8MP_CLK_I2C5 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_I2C6 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_SAI1 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_SAI2 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_SAI3 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_SAI5 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_SAI6 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_ENET_QOS ,125 *HZ_PER_MHZ }, + {IMX8MP_CLK_ENET_QOS_TIMER ,200 *HZ_PER_MHZ }, + {IMX8MP_CLK_ENET_REF ,125 *HZ_PER_MHZ }, + {IMX8MP_CLK_ENET_TIMER ,125 *HZ_PER_MHZ }, + {IMX8MP_CLK_ENET_PHY_REF ,125 *HZ_PER_MHZ }, + {IMX8MP_CLK_NAND ,500 *HZ_PER_MHZ }, + {IMX8MP_CLK_QSPI ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_USDHC1 ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_USDHC2 ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_I2C1 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_I2C2 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_I2C3 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_I2C4 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_UART1 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_UART2 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_UART3 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_UART4 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_ECSPI1 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_ECSPI2 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_PWM1 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_PWM2 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_PWM3 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_PWM4 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_GPT1 ,100 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPT2 ,100 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPT3 ,100 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPT4 ,100 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPT5 ,100 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPT6 ,100 *HZ_PER_MHZ }, + {IMX8MP_CLK_WDOG ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_IPP_DO_CLKO1 ,200 *HZ_PER_MHZ }, + {IMX8MP_CLK_IPP_DO_CLKO2 ,200 *HZ_PER_MHZ }, + {IMX8MP_CLK_HDMI_REF_266M ,266 *HZ_PER_MHZ }, + {IMX8MP_CLK_USDHC3 ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_MIPI_PHY1_REF ,300 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_DISP1_PIX ,250 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_CAM2_PIX ,277 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_LDB ,595 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_MIPI_TEST_BYTE ,200 *HZ_PER_MHZ }, + {IMX8MP_CLK_ECSPI3 ,80 *HZ_PER_MHZ }, + {IMX8MP_CLK_PDM ,200 *HZ_PER_MHZ }, + {IMX8MP_CLK_SAI7 ,66666667 },/* Datasheet claims 66MHz */ + {IMX8MP_CLK_MAIN_AXI ,400 *HZ_PER_MHZ }, + {/* Sentinel */ } +}; + +static const struct imx8mp_clock_constraints imx8mp_clock_nominal_constraints[] = { + {IMX8MP_CLK_M7_CORE ,600 *HZ_PER_MHZ }, + {IMX8MP_CLK_ML_CORE ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU3D_CORE ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU3D_SHADER_CORE ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU2D_CORE ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_AUDIO_AXI_SRC ,600 *HZ_PER_MHZ }, + {IMX8MP_CLK_HSIO_AXI ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_ISP ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_BUS ,600 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_AXI ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_HDMI_AXI ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU_AXI ,600 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU_AHB ,300 *HZ_PER_MHZ }, + {IMX8MP_CLK_NOC ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_NOC_IO ,600 *HZ_PER_MHZ }, + {IMX8MP_CLK_ML_AHB ,300 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_G1 ,600 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_G2 ,500 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_CAM1_PIX ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_VC8000E ,400 *HZ_PER_MHZ },/* Datasheet claims 500MHz */ + {IMX8MP_CLK_DRAM_CORE ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_GIC ,400 *HZ_PER_MHZ }, + {/* Sentinel */ } +}; + +static const struct imx8mp_clock_constraints imx8mp_clock_overdrive_constraints[] = { + {IMX8MP_CLK_M7_CORE ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_ML_CORE ,1000 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU3D_CORE ,1000 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU3D_SHADER_CORE ,1000 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU2D_CORE ,1000 *HZ_PER_MHZ }, + {IMX8MP_CLK_AUDIO_AXI_SRC ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_HSIO_AXI ,500 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_ISP ,500 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_BUS ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_AXI ,500 *HZ_PER_MHZ }, + {IMX8MP_CLK_HDMI_AXI ,500 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU_AXI ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_GPU_AHB ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_NOC ,1000 *HZ_PER_MHZ }, + {IMX8MP_CLK_NOC_IO ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_ML_AHB ,400 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_G1 ,800 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_G2 ,700 *HZ_PER_MHZ }, + {IMX8MP_CLK_MEDIA_CAM1_PIX ,500 *HZ_PER_MHZ }, + {IMX8MP_CLK_VPU_VC8000E ,500 *HZ_PER_MHZ },/* Datasheet claims 400MHz */ + {IMX8MP_CLK_DRAM_CORE ,1000 *HZ_PER_MHZ }, + {IMX8MP_CLK_GIC ,500 *HZ_PER_MHZ }, + {/* Sentinel */ } +}; + +static void imx8mp_clocks_apply_constraints (const struct imx8mp_clock_constraints constraints[]) +{ +const struct imx8mp_clock_constraints *constr; + +for (constr = constraints; constr->clkid; constr++) +clk_hw_set_rate_range (hws[constr->clkid],0 , constr->maxrate); +} +static int imx8mp_clocks_probe (struct platform_device *pdev) {struct device *dev = &pdev->dev;struct device_node *np = dev->of_node;void __iomem *anatop_base, *ccm_base; +const char *opmode;int err; np =of_find_compatible_node (NULL ,NULL ,"fsl,imx8mp-anatop" );
@@ -736,6 +877,16 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)imx_check_clk_hws (hws,IMX8MP_CLK_END ); +imx8mp_clocks_apply_constraints (imx8mp_clock_common_constraints); + + err =of_property_read_string (np,"fsl,operating-mode" , &opmode); +if (!err) { +if (!strcmp (opmode,"nominal" )) +imx8mp_clocks_apply_constraints (imx8mp_clock_nominal_constraints); +else if (!strcmp (opmode,"overdrive" )) +imx8mp_clocks_apply_constraints (imx8mp_clock_overdrive_constraints); + } + err =of_clk_add_hw_provider (np, of_clk_hw_onecell_get, clk_hw_data);if (err <0 ) {dev_err (dev,"failed to register hws for i.MX8MP\n" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 170/270 x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit 98fdaeb296f51ef08e727a7cc72e5b5c864c4f4d ]
Change the default value of spectre v2 in user mode to respect the CONFIG_MITIGATION_SPECTRE_V2 config option.
Currently, user mode spectre v2 is set to auto
(SPECTRE_V2_USER_CMD_AUTO) by default, even ifCONFIG_MITIGATION_SPECTRE_V2 is disabled.
Set the spectre_v2 value to auto (SPECTRE_V2_USER_CMD_AUTO) if the Spectre v2 config (CONFIG_MITIGATION_SPECTRE_V2) is enabled, otherwise set the value to none (SPECTRE_V2_USER_CMD_NONE).
Important to say the command line argument "spectre_v2_user" overwrites the default value in both cases.
When CONFIG_MITIGATION_SPECTRE_V2 is not set, users have the flexibility to opt-in for specific mitigations independently. In this scenario, setting spectre_v2= will not enable spectre_v2_user=, and command line options spectre_v2_user and spectre_v2 are independent when CONFIG_MITIGATION_SPECTRE_V2=n.
--- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/kernel/cpu/bugs.c | 10 +++++++--- 2 files changed, 9 insertions(+), 3 deletions(-)
Documentation/admin-guide/kernel-parameters.txt +2 -0
@@ -5122,6 +5122,8 @@ Selecting 'on' will also enable the mitigation against user space to user space task attacks. + Selecting specific mitigation does not force enable + user mitigations. Selecting 'off' will disable both the kernel and the user space protections.
arch/x86/kernel/cpu/bugs.c +7 -3
@@ -1231,9 +1231,13 @@ static __ro_after_init enum spectre_v2_mitigation_cmd spectre_v2_cmd;static enum spectre_v2_user_cmd __init spectre_v2_parse_user_cmdline (void ) { +enum spectre_v2_user_cmd mode;char arg[20 ];int ret, i; + mode =IS_ENABLED (CONFIG_MITIGATION_SPECTRE_V2 ) ? +SPECTRE_V2_USER_CMD_AUTO :SPECTRE_V2_USER_CMD_NONE ; +switch (spectre_v2_cmd) {case SPECTRE_V2_CMD_NONE :return SPECTRE_V2_USER_CMD_NONE ;
@@ -1246,7 +1250,7 @@ spectre_v2_parse_user_cmdline(void) ret =cmdline_find_option (boot_command_line,"spectre_v2_user" , arg,sizeof (arg));if (ret <0 ) -return SPECTRE_V2_USER_CMD_AUTO ; +return mode;for (i =0 ; i <ARRAY_SIZE (v2_user_options); i++) {if (match_option (arg, ret, v2_user_options[i].option)) {
@@ -1256,8 +1260,8 @@ spectre_v2_parse_user_cmdline(void) } } -pr_err ("Unknown user space protection option (%s). Switching to AUTO select\n" , arg); -return SPECTRE_V2_USER_CMD_AUTO ; +pr_err ("Unknown user space protection option (%s). Switching to default\n" , arg); +return mode; }static inline bool spectre_v2_in_eibrs_mode (enum spectre_v2_mitigation mode)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 171/270 hwmon: (gpio-fan) Add missing mutex locks
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Stein <[email protected]>
[ Upstream commit 9fee7d19bab635f89223cc40dfd2c8797fdc4988 ]
set_fan_speed() is expected to be called with fan_data->lock being locked. Add locking for proper synchronization.
--- drivers/hwmon/gpio-fan.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
drivers/hwmon/gpio-fan.c +15 -1
@@ -394,7 +394,12 @@ static int gpio_fan_set_cur_state(struct thermal_cooling_device *cdev,if (state >= fan_data->num_speed)return -EINVAL ; +mutex_lock (&fan_data->lock); +set_fan_speed (fan_data, state); + +mutex_unlock (&fan_data->lock); +return 0 ; }
@@ -490,7 +495,11 @@ MODULE_DEVICE_TABLE(of, of_gpio_fan_match);static void gpio_fan_stop (void *data) { +struct gpio_fan_data *fan_data = data; + +mutex_lock (&fan_data->lock);set_fan_speed (data,0 ); +mutex_unlock (&fan_data->lock); }static int gpio_fan_probe (struct platform_device *pdev)
@@ -564,7 +573,9 @@ static int gpio_fan_suspend(struct device *dev)if (fan_data->gpios) { fan_data->resume_speed = fan_data->speed_index; +mutex_lock (&fan_data->lock);set_fan_speed (fan_data,0 ); +mutex_unlock (&fan_data->lock); }return 0 ;
@@ -574,8 +585,11 @@ static int gpio_fan_resume(struct device *dev) {struct gpio_fan_data *fan_data =dev_get_drvdata (dev); -if (fan_data->gpios) +if (fan_data->gpios) { +mutex_lock (&fan_data->lock);set_fan_speed (fan_data, fan_data->resume_speed); +mutex_unlock (&fan_data->lock); + }return 0 ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 172/270 drm/mediatek: mtk_dpi: Add checks for reg_h_fre_con existence
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: AngeloGioacchino Del Regno <[email protected]>
[ Upstream commit 8c9da7cd0bbcc90ab444454fecf535320456a312 ]
In preparation for adding support for newer DPI instances which do support direct-pin but do not have any H_FRE_CON register, like the one found in MT8195 and MT8188, add a branch to check if the reg_h_fre_con variable was declared in the mtk_dpi_conf structure for the probed SoC DPI version.
As a note, this is useful specifically only for cases in which the support_direct_pin variable is true, so mt8195-dpintf is not affected by any issue.
--- drivers/gpu/drm/mediatek/mtk_dpi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/mediatek/mtk_dpi.c +3 -2
@@ -340,12 +340,13 @@ static void mtk_dpi_config_swap_input(struct mtk_dpi *dpi, bool enable)static void mtk_dpi_config_2n_h_fre (struct mtk_dpi *dpi) { -mtk_dpi_mask (dpi, dpi->conf->reg_h_fre_con,H_FRE_2N ,H_FRE_2N ); +if (dpi->conf->reg_h_fre_con) +mtk_dpi_mask (dpi, dpi->conf->reg_h_fre_con,H_FRE_2N ,H_FRE_2N ); }static void mtk_dpi_config_disable_edge (struct mtk_dpi *dpi) { -if (dpi->conf->edge_sel_en) +if (dpi->conf->edge_sel_en && dpi->conf->reg_h_fre_con)mtk_dpi_mask (dpi, dpi->conf->reg_h_fre_con,0 ,EDGE_SEL_EN ); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 173/270 fpga: altera-cvp: Increase credit timeout
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuhanh Murugasen Krishnan <[email protected]>
[ Upstream commit 0f05886a40fdc55016ba4d9ae0a9c41f8312f15b ]
Increase the timeout for SDM (Secure device manager) data credits from 20ms to 40ms. Internal stress tests running at 500 loops failed with the current timeout of 20ms. At the start of a FPGA configuration, the CVP host driver reads the transmit credits from SDM. It then sends bitstream FPGA data to SDM based on the total credits. Each credit allows the CVP host driver to send 4kBytes of data. There are situations whereby, the SDM did not respond in time during testing.
--- drivers/fpga/altera-cvp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/fpga/altera-cvp.c +1 -1
@@ -52,7 +52,7 @@/* V2 Defines */ #define VSE_CVP_TX_CREDITS 0x49/* 8bit */ -#define V2_CREDIT_TIMEOUT_US 20000 +#define V2_CREDIT_TIMEOUT_US 40000#define V2_CHECK_CREDIT_US 10#define V2_POLL_TIMEOUT_US 1000000#define V2_USER_TIMEOUT_US 500000
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 174/270 PCI: brcmstb: Expand inbound window size up to 64GB
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanimir Varbanov <[email protected]>
[ Upstream commit 25a98c727015638baffcfa236e3f37b70cedcf87 ]
The BCM2712 memory map can support up to 64GB of system memory, thus expand the inbound window size in calculation helper function.
The change is safe for the currently supported SoCs that have smaller inbound window sizes.
--- drivers/pci/controller/pcie-brcmstb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/pci/controller/pcie-brcmstb.c +2 -2
@@ -300,8 +300,8 @@ static int brcm_pcie_encode_ibar_size(u64 size)if (log2_in >=12 && log2_in <=15 )/* Covers 4KB to 32KB (inclusive) */ return (log2_in -12 ) +0x1c ; -else if (log2_in >=16 && log2_in <=35 ) -/* Covers 64KB to 32GB, (inclusive) */ +else if (log2_in >=16 && log2_in <=36 ) +/* Covers 64KB to 64GB, (inclusive) */ return log2_in -15 ;/* Something is awry so disable */ return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 175/270 PCI: brcmstb: Add a softdep to MIP MSI-X driver
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanimir Varbanov <[email protected]>
[ Upstream commit 2294059118c550464dd8906286324d90c33b152b ]
Then the brcmstb PCIe driver and MIP MSI-X interrupt controller drivers are built as modules there could be a race in probing.
To avoid this, add a softdep to MIP driver to guarantee that MIP driver will be load first.
--- drivers/pci/controller/pcie-brcmstb.c | 1 + 1 file changed, 1 insertion(+)
drivers/pci/controller/pcie-brcmstb.c +1 -0
@@ -1326,3 +1326,4 @@ module_platform_driver(brcm_pcie_driver);MODULE_LICENSE ("GPL" );MODULE_DESCRIPTION ("Broadcom STB PCIe RC driver" );MODULE_AUTHOR ("Broadcom" ); +MODULE_SOFTDEP ("pre: irq_bcm2712_mip" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 176/270 net/mlx5: Avoid report two health errors on same syndrome
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Moshe Shemesh <[email protected]>
[ Upstream commit b5d7b2f04ebcff740f44ef4d295b3401aeb029f4 ]
In case health counter has not increased for few polling intervals, miss counter will reach max misses threshold and health report will be triggered for FW health reporter. In case syndrome found on same health poll another health report will be triggered.
Avoid two health reports on same syndrome by marking this syndrome as already known.
--- drivers/net/ethernet/mellanox/mlx5/core/health.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/mellanox/mlx5/core/health.c +1 -0
@@ -733,6 +733,7 @@ static void poll_health(struct timer_list *t) health->prev = count;if (health->miss_counter ==MAX_MISSES ) {mlx5_core_err (dev,"device's health compromised - reached miss count\n" ); + health->synd =ioread8 (&h->synd);print_health_info (dev);queue_work (health->wq, &health->report_work); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 177/270 drm/amdkfd: KFD release_work possible circular locking
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Philip Yang <[email protected]>
[ Upstream commit 1b9366c601039d60546794c63fbb83ce8e53b978 ]
If waiting for gpu reset done in KFD release_work, thers is WARNING:
possible circular locking dependency detected
#2 kfd_create_process
kfd_process_mutex
flush kfd release work
#1 kfd release work
wait for amdgpu reset work
#0 amdgpu_device_gpu_reset
kgd2kfd_pre_reset
kfd_process_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((work_completion)(&p->release_work));
lock((wq_completion)kfd_process_wq);
lock((work_completion)(&p->release_work));lock((wq_completion)amdgpu-reset-dev);
To fix this, KFD create process move flush release work outside kfd_process_mutex.
--- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/gpu/drm/amd/amdkfd/kfd_process.c +8 -8
@@ -755,6 +755,14 @@ struct kfd_process *kfd_create_process(struct file *filep)if (thread->group_leader->mm != thread->mm)return ERR_PTR (-EINVAL ); +/* If the process just called exec(3), it is possible that the +* cleanup of the kfd_process (following the release of the mm +* of the old process image) is still in the cleanup work queue. +* Make sure to drain any job before trying to recreate any +* resource for this process. +*/ +flush_workqueue (kfd_process_wq); +/* * take kfd processes mutex before starting of process creation * so there won't be a case where two threads of the same process
@@ -767,14 +775,6 @@ struct kfd_process *kfd_create_process(struct file *filep)if (process) {pr_debug ("Process already found\n" ); }else { -/* If the process just called exec(3), it is possible that the -* cleanup of the kfd_process (following the release of the mm -* of the old process image) is still in the cleanup work queue. -* Make sure to drain any job before trying to recreate any -* resource for this process. -*/ -flush_workqueue (kfd_process_wq); - process =create_process (thread);if (IS_ERR (process)) goto out;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 178/270 net: xgene-v2: remove incorrect ACPI_PTR annotation
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 01358e8fe922f716c05d7864ac2213b2440026e7 ]
Building with W=1 shows a warning about xge_acpi_match being unused when CONFIG_ACPI is disabled:
drivers/net/ethernet/apm/xgene-v2/main.c:723:36: error: unused variable 'xge_acpi_match' [-Werror,-Wunused-const-variable]
--- drivers/net/ethernet/apm/xgene-v2/main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/net/ethernet/apm/xgene-v2/main.c +1 -3
@@ -9,8 +9,6 @@#include "main.h" -static const struct acpi_device_id xge_acpi_match[]; -static int xge_get_resources (struct xge_pdata *pdata) {struct platform_device *pdev;
@@ -733,7 +731,7 @@ MODULE_DEVICE_TABLE(acpi, xge_acpi_match);static struct platform_driver xge_driver = { .driver = { .name ="xgene-enet-v2" , - .acpi_match_table =ACPI_PTR (xge_acpi_match), + .acpi_match_table = xge_acpi_match, }, .probe = xge_probe, .remove = xge_remove,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 179/270 bonding: report duplicate MAC address in all situations
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangbin Liu <[email protected]>
[ Upstream commit 28d68d396a1cd21591e8c6d74afbde33a7ea107e ]
Normally, a bond uses the MAC address of the first added slave as the bond’s MAC address. And the bond will set active slave’s MAC address to bond’s address if fail_over_mac is set to none (0) or follow (2).
When the first slave is removed, the bond will still use the removed slave’s MAC address, which can lead to a duplicate MAC address and potentially cause issues with the switch. To avoid confusion, let's warn the user in all situations, including when fail_over_mac is set to 2 or not in active-backup mode.
--- drivers/net/bonding/bond_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/bonding/bond_main.c +1 -1
@@ -2239,7 +2239,7 @@ static int __bond_release_one(struct net_device *bond_dev,RCU_INIT_POINTER (bond->current_arp_slave,NULL ); -if (!all && (!bond->params.fail_over_mac || +if (!all && (bond->params.fail_over_mac !=BOND_FOM_ACTIVE ||BOND_MODE (bond) !=BOND_MODE_ACTIVEBACKUP )) {if (ether_addr_equal_64bits (bond_dev->dev_addr, slave->perm_hwaddr) &&bond_has_slaves (bond))
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 180/270 soc: ti: k3-socinfo: Do not use syscon helper to build regmap
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Davis <[email protected]>
[ Upstream commit a5caf03188e44388e8c618dcbe5fffad1a249385 ]
The syscon helper device_node_to_regmap() is used to fetch a regmap registered to a device node. It also currently creates this regmap if the node did not already have a regmap associated with it. This should only be used on "syscon" nodes. This driver is not such a device and instead uses device_node_to_regmap() on its own node as a hacky way to create a regmap for itself.
This will not work going forward and so we should create our regmap the normal way by defining our regmap_config, fetching our memory resource, then using the normal regmap_init_mmio() function.
--- drivers/soc/ti/k3-socinfo.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/soc/ti/k3-socinfo.c +12 -1
@@ -57,6 +57,12 @@ k3_chipinfo_partno_to_names(unsigned int partno,return -EINVAL ; } +static const struct regmap_config k3_chipinfo_regmap_cfg = { + .reg_bits =32 , + .val_bits =32 , + .reg_stride =4 , +}; +static int k3_chipinfo_probe (struct platform_device *pdev) {struct device_node *node = pdev->dev.of_node;
@@ -64,13 +70,18 @@ static int k3_chipinfo_probe(struct platform_device *pdev)struct device *dev = &pdev->dev;struct soc_device *soc_dev;struct regmap *regmap; +void __iomem *base;u32 partno_id;u32 variant;u32 jtag_id;u32 mfg;int ret; - regmap =device_node_to_regmap (node); + base =devm_platform_ioremap_resource (pdev,0 ); +if (IS_ERR (base)) +return PTR_ERR (base); + + regmap =regmap_init_mmio (dev, base, &k3_chipinfo_regmap_cfg);if (IS_ERR (regmap))return PTR_ERR (regmap);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 181/270 x86/nmi: Add an emergency handler in nmi_desc & use it in nmi_shootdown_cpus()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Waiman Long <[email protected]>
[ Upstream commit fe37c699ae3eed6e02ee55fbf5cb9ceb7fcfd76c ]
Depending on the type of panics, it was found that the __register_nmi_handler() function can be called in NMI context from nmi_shootdown_cpus() leading to a lockdep splat:
WARNING: inconsistent lock state
inconsistent {INITIAL USE} -> {IN-NMI} usage.
lock(&nmi_desc[0].lock);
<Interrupt>
lock(&nmi_desc[0].lock); Call Trace:
_raw_spin_lock_irqsave
__register_nmi_handler
nmi_shootdown_cpus
kdump_nmi_shootdown_cpus
native_machine_crash_shutdown
__crash_kexecIn this particular case, the following panic message was printed before:
Kernel panic - not syncing: Fatal hardware error!
This message seemed to be given out from __ghes_panic() running in NMI context.
The __register_nmi_handler() function which takes the nmi_desc lock with irq disabled shouldn't be called from NMI context as this can lead to deadlock.
The nmi_shootdown_cpus() function can only be invoked once. After the first invocation, all other CPUs should be stuck in the newly added crash_nmi_callback() and cannot respond to a second NMI.
Fix it by adding a new emergency NMI handler to the nmi_desc structure and provide a new set_emergency_nmi_handler() helper to set crash_nmi_callback() in any context. The new emergency handler will preempt other handlers in the linked list. That will eliminate the need to take any lock and serve the panic in NMI use case.
--- arch/x86/include/asm/nmi.h | 2 ++ arch/x86/kernel/nmi.c | 42 ++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/reboot.c | 10 +++------ 3 files changed, 47 insertions(+), 7 deletions(-)
arch/x86/include/asm/nmi.h +2 -0
@@ -59,6 +59,8 @@ int __register_nmi_handler(unsigned int, struct nmiaction *);void unregister_nmi_handler (unsigned int ,const char *); +void set_emergency_nmi_handler (unsigned int type,nmi_handler_t handler); +void stop_nmi (void );void restart_nmi (void );void local_touch_nmi (void );
arch/x86/kernel/nmi.c +42 -0
65 lines not on this page · raw message
arch/x86/kernel/reboot.c +3 -7
@@ -874,15 +874,11 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback) shootdown_callback = callback;atomic_set (&waiting_for_crash_ipi,num_online_cpus () -1 ); -/* Would it be better to replace the trap vector here? */ -if (register_nmi_handler (NMI_LOCAL , crash_nmi_callback, -NMI_FLAG_FIRST ,"crash" )) -return ;/* Return what? */ +/* -* Ensure the new callback function is set before sending -* out the NMI +* Set emergency handler to preempt other handlers. */ -wmb (); +set_emergency_nmi_handler (NMI_LOCAL , crash_nmi_callback);apic_send_IPI_allbutself (NMI_VECTOR );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 182/270 cpuidle: menu: Avoid discarding useful information
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit 85975daeaa4d6ec560bfcd354fc9c08ad7f38888 ]
When giving up on making a high-confidence prediction, get_typical_interval() always returns UINT_MAX which means that the next idle interval prediction will be based entirely on the time till the next timer. However, the information represented by the most recent intervals may not be completely useless in those cases.
Namely, the largest recent idle interval is an upper bound on the recently observed idle duration, so it is reasonable to assume that the next idle duration is unlikely to exceed it. Moreover, this is still true after eliminating the suspected outliers if the sample set still under consideration is at least as large as 50% of the maximum sample set size.
Accordingly, make get_typical_interval() return the current maximum recent interval value in that case instead of UINT_MAX.
--- drivers/cpuidle/governors/menu.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/cpuidle/governors/menu.c +12 -1
@@ -249,8 +249,19 @@ static unsigned int get_typical_interval(struct menu_device *data,* This can deal with workloads that have long pauses interspersed * with sporadic activity with a bunch of short pauses. */ -if ((divisor *4 ) <=INTERVALS *3 ) +if (divisor *4 <=INTERVALS *3 ) { +/* +* If there are sufficiently many data points still under +* consideration after the outliers have been eliminated, +* returning without a prediction would be a mistake because it +* is likely that the next interval will not exceed the current +* maximum, so return the latter in that case. +*/ +if (divisor >=INTERVALS /2 ) +return max; +return UINT_MAX ; + } thresh = max -1 ; goto again;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 183/270 libbpf: Fix out-of-bound read
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nandakumar Edamana <[email protected]>
[ Upstream commit 236d3910117e9f97ebf75e511d8bcc950f1a4e5f ]
In set_kcfg_value_str, an untrusted string is accessed with the assumption that it will be at least two characters long due to the presence of checks for opening and closing quotes. But the check for the closing quote (value[len - 1] != '"') misses the fact that it could be checking the opening quote itself in case of an invalid input that consists of just the opening quote.
This commit adds an explicit check to make sure the string is at least two characters long.
--- tools/lib/bpf/libbpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/lib/bpf/libbpf.c +1 -1
@@ -1503,7 +1503,7 @@ static int set_kcfg_value_str(struct extern_desc *ext, char *ext_val, } len =strlen (value); -if (value[len -1 ] !='"' ) { +if (len <2 || value[len -1 ] !='"' ) {pr_warn ("extern (kcfg) '%s': invalid string config '%s'\n" , ext->name, value);return -EINVAL ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 184/270 MIPS: Use arch specific syscall name match function
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bibo Mao <[email protected]>
[ Upstream commit 756276ce78d5624dc814f9d99f7d16c8fd51076e ]
On MIPS system, most of the syscall function name begin with prefix sys_. Some syscalls are special such as clone/fork, function name of these begin with __sys_. Since scratch registers need be saved in stack when these system calls happens.
With ftrace system call method, system call functions are declared with SYSCALL_DEFINEx, metadata of the system call symbol name begins with sys_. Here mips specific function arch_syscall_match_sym_name is used to compare function name between sys_call_table[] and metadata of syscall symbol.
--- arch/mips/include/asm/ftrace.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
arch/mips/include/asm/ftrace.h +16 -0
@@ -87,4 +87,20 @@ struct dyn_arch_ftrace {#endif /* CONFIG_DYNAMIC_FTRACE */ #endif /* __ASSEMBLY__ */ #endif /* CONFIG_FUNCTION_TRACER */ + +#ifdef CONFIG_FTRACE_SYSCALLS +#ifndef __ASSEMBLY__ +/* +* Some syscall entry functions on mips start with "__sys_" (fork and clone, +* for instance). We should also match the sys_ variant with those. +*/ +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME +static inline bool arch_syscall_match_sym_name (const char *sym, +const char *name) +{ +return !strcmp (sym, name) || + (!strncmp (sym,"__sys_" ,6 ) && !strcmp (sym +6 , name +4 )); +} +#endif /* __ASSEMBLY__ */ +#endif /* CONFIG_FTRACE_SYSCALLS */ #endif /* _ASM_MIPS_FTRACE_H */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 185/270 MIPS: pm-cps: Use per-CPU variables as per-CPU, not per-core
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
[ Upstream commit 00a134fc2bb4a5f8fada58cf7ff4259149691d64 ]
The pm-cps code has up until now used per-CPU variables indexed by core, rather than CPU number, in order to share data amongst sibling CPUs (ie. VPs/threads in a core). This works fine for single cluster systems, but with multi-cluster systems a core number is no longer unique in the system, leading to sharing between CPUs that are not actually siblings.
Avoid this issue by using per-CPU variables as they are more generally used - ie. access them using CPU numbers rather than core numbers. Sharing between siblings is then accomplished by:
- Assigning the same pointer to entries for each sibling CPU for the nc_asm_enter & ready_count variables, which allow this by virtue of being per-CPU pointers.
- Indexing by the first CPU set in a CPUs cpu_sibling_map in the case of pm_barrier, for which we can't use the previous approach because the per-CPU variable is not a pointer.
--- arch/mips/kernel/pm-cps.c | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-)
arch/mips/kernel/pm-cps.c +17 -13
@@ -56,10 +56,7 @@ static DEFINE_PER_CPU_ALIGNED(u32*, ready_count);/* Indicates online CPUs coupled with the current CPU */ static DEFINE_PER_CPU_ALIGNED(cpumask_t, online_coupled); -/* -* Used to synchronize entry to deep idle states. Actually per-core rather -* than per-CPU. -*/ +/* Used to synchronize entry to deep idle states */ static DEFINE_PER_CPU_ALIGNED(atomic_t, pm_barrier);/* Saved CPU state across the CPS_PM_POWER_GATED state */
@@ -118,9 +115,10 @@ int cps_pm_enter_state(enum cps_pm_state state)cps_nc_entry_fn entry;struct core_boot_config *core_cfg;struct vpe_boot_config *vpe_cfg; +atomic_t *barrier;/* Check that there is an entry function for this state */ - entry =per_cpu (nc_asm_enter, core)[state]; + entry =per_cpu (nc_asm_enter, cpu)[state];if (!entry)return -EINVAL ;
@@ -156,7 +154,7 @@ int cps_pm_enter_state(enum cps_pm_state state)smp_mb__after_atomic ();/* Create a non-coherent mapping of the core ready_count */ - core_ready_count =per_cpu (ready_count, core); + core_ready_count =per_cpu (ready_count, cpu); nc_addr =kmap_noncoherent (virt_to_page (core_ready_count), (unsigned long )core_ready_count); nc_addr += ((unsigned long )core_ready_count & ~PAGE_MASK );
@@ -164,7 +162,8 @@ int cps_pm_enter_state(enum cps_pm_state state)/* Ensure ready_count is zero-initialised before the assembly runs */ WRITE_ONCE (*nc_core_ready_count,0 ); -coupled_barrier (&per_cpu (pm_barrier, core), online); + barrier = &per_cpu (pm_barrier,cpumask_first (&cpu_sibling_map[cpu])); +coupled_barrier (barrier, online);/* Run the generated entry code */ left =entry (online, nc_core_ready_count);
@@ -635,12 +634,14 @@ static void *cps_gen_entry_code(unsigned cpu, enum cps_pm_state state)static int cps_pm_online_cpu (unsigned int cpu) { -enum cps_pm_state state; -unsigned core =cpu_core (&cpu_data[cpu]); +unsigned int sibling, core;void *entry_fn, *core_rc; +enum cps_pm_state state; + + core =cpu_core (&cpu_data[cpu]);for (state =CPS_PM_NC_WAIT ; state <CPS_PM_STATE_COUNT ; state++) { -if (per_cpu (nc_asm_enter, core)[state]) +if (per_cpu (nc_asm_enter, cpu)[state])continue ;if (!test_bit (state, state_support))continue ;
@@ -652,16 +653,19 @@ static int cps_pm_online_cpu(unsigned int cpu)clear_bit (state, state_support); } -per_cpu (nc_asm_enter, core)[state] = entry_fn; +for_each_cpu (sibling, &cpu_sibling_map[cpu]) +per_cpu (nc_asm_enter, sibling)[state] = entry_fn; } -if (!per_cpu (ready_count, core)) { +if (!per_cpu (ready_count, cpu)) { core_rc =kmalloc (sizeof (u32),GFP_KERNEL );if (!core_rc) {pr_err ("Failed allocate core %u ready_count\n" , core);return -ENOMEM ; } -per_cpu (ready_count, core) = core_rc; + +for_each_cpu (sibling, &cpu_sibling_map[cpu]) +per_cpu (ready_count, sibling) = core_rc; }return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 186/270 clocksource: mips-gic-timer: Enable counter when CPUs start
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
[ Upstream commit 3128b0a2e0cf6e07aa78e5f8cf7dd9cd59dc8174 ]
In multi-cluster MIPS I6500 systems there is a GIC in each cluster, each with its own counter. When a cluster powers up the counter will be stopped, with the COUNTSTOP bit set in the GIC_CONFIG register.
In single cluster systems, it has been fine to clear COUNTSTOP once in gic_clocksource_of_init() to start the counter. In multi-cluster systems, this will only have started the counter in the boot cluster, and any CPUs in other clusters will find their counter stopped which will break the GIC clock_event_device.
Resolve this by having CPUs clear the COUNTSTOP bit when they come online, using the existing gic_starting_cpu() CPU hotplug callback. This will allow CPUs in secondary clusters to ensure that the cluster's GIC counter is running as expected.
--- drivers/clocksource/mips-gic-timer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/clocksource/mips-gic-timer.c +3 -3
@@ -119,6 +119,9 @@ static void gic_update_frequency(void *data)static int gic_starting_cpu (unsigned int cpu) { +/* Ensure the GIC counter is running */ +clear_gic_config (GIC_CONFIG_COUNTSTOP ); +gic_clockevent_cpu_init (cpu,this_cpu_ptr (&gic_clockevent_device));return 0 ; }
@@ -253,9 +256,6 @@ static int __init gic_clocksource_of_init(struct device_node *node)pr_warn ("Unable to register clock notifier\n" ); } -/* And finally start the counter */ -clear_gic_config (GIC_CONFIG_COUNTSTOP ); -/* * It's safe to use the MIPS GIC timer as a sched clock source only if * its ticks are stable, which is true on either the platforms with
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 187/270 scsi: mpt3sas: Send a diag reset if target reset fails
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shivasharan S <[email protected]>
[ Upstream commit 5612d6d51ed2634a033c95de2edec7449409cbb9 ]
When an IOCTL times out and driver issues a target reset, if firmware fails the task management elevate the recovery by issuing a diag reset to controller.
--- drivers/scsi/mpt3sas/mpt3sas_ctl.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/scsi/mpt3sas/mpt3sas_ctl.c +10 -2
@@ -676,6 +676,7 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command karg,size_t data_in_sz =0 ;long ret;u16 device_handle =MPT3SAS_INVALID_DEVICE_HANDLE ; +int tm_ret; issue_reset =0 ;
@@ -1107,18 +1108,25 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command karg,if (pcie_device && (!ioc->tm_custom_handling) && (!(mpt3sas_scsih_is_pcie_scsi_device ( pcie_device->device_info)))) -mpt3sas_scsih_issue_locked_tm (ioc, + tm_ret =mpt3sas_scsih_issue_locked_tm (ioc,le16_to_cpu (mpi_request->FunctionDependent1),0 ,0 ,0 ,MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET ,0 ,0 , pcie_device->reset_timeout,MPI26_SCSITASKMGMT_MSGFLAGS_PROTOCOL_LVL_RST_PCIE );else -mpt3sas_scsih_issue_locked_tm (ioc, + tm_ret =mpt3sas_scsih_issue_locked_tm (ioc,le16_to_cpu (mpi_request->FunctionDependent1),0 ,0 ,0 ,MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET ,0 ,0 ,30 ,MPI2_SCSITASKMGMT_MSGFLAGS_LINK_RESET ); + +if (tm_ret !=SUCCESS ) { +ioc_info (ioc, +"target reset failed, issue hard reset: handle (0x%04x)\n" , +le16_to_cpu (mpi_request->FunctionDependent1)); +mpt3sas_base_hard_reset_handler (ioc,FORCE_BIG_HAMMER ); + } }else mpt3sas_base_hard_reset_handler (ioc,FORCE_BIG_HAMMER ); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 188/270 wifi: rtw88: Fix rtw_init_vht_cap() for RTL8814AU
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
[ Upstream commit 6be7544d19fcfcb729495e793bc6181f85bb8949 ]
Set the MCS maps and the highest rates according to the number of spatial streams the chip has. For RTL8814AU that is 3.
--- drivers/net/wireless/realtek/rtw88/main.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-)
drivers/net/wireless/realtek/rtw88/main.c +9 -14
@@ -1175,8 +1175,9 @@ static void rtw_init_vht_cap(struct rtw_dev *rtwdev, struct ieee80211_sta_vht_cap *vht_cap) {struct rtw_efuse *efuse = &rtwdev->efuse; -u16 mcs_map; +u16 mcs_map =0 ;__le16 highest; +int i;if (efuse->hw_cap.ptcl !=EFUSE_HW_CAP_IGNORE && efuse->hw_cap.ptcl !=EFUSE_HW_CAP_PTCL_VHT )
@@ -1199,21 +1200,15 @@ static void rtw_init_vht_cap(struct rtw_dev *rtwdev,if (rtw_chip_has_rx_ldpc (rtwdev)) vht_cap->cap |=IEEE80211_VHT_CAP_RXLDPC ; - mcs_map =IEEE80211_VHT_MCS_SUPPORT_0_9 <<0 | -IEEE80211_VHT_MCS_NOT_SUPPORTED <<4 | -IEEE80211_VHT_MCS_NOT_SUPPORTED <<6 | -IEEE80211_VHT_MCS_NOT_SUPPORTED <<8 | -IEEE80211_VHT_MCS_NOT_SUPPORTED <<10 | -IEEE80211_VHT_MCS_NOT_SUPPORTED <<12 | -IEEE80211_VHT_MCS_NOT_SUPPORTED <<14 ; -if (efuse->hw_cap.nss >1 ) { - highest =cpu_to_le16 (780 ); - mcs_map |=IEEE80211_VHT_MCS_SUPPORT_0_9 <<2 ; - }else { - highest =cpu_to_le16 (390 ); - mcs_map |=IEEE80211_VHT_MCS_NOT_SUPPORTED <<2 ; +for (i =0 ; i <8 ; i++) { +if (i < efuse->hw_cap.nss) + mcs_map |=IEEE80211_VHT_MCS_SUPPORT_0_9 << (i *2 ); +else + mcs_map |=IEEE80211_VHT_MCS_NOT_SUPPORTED << (i *2 ); } + highest =cpu_to_le16 (390 * efuse->hw_cap.nss); + vht_cap->vht_mcs.rx_mcs_map =cpu_to_le16 (mcs_map); vht_cap->vht_mcs.tx_mcs_map =cpu_to_le16 (mcs_map); vht_cap->vht_mcs.rx_highest = highest;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 189/270 wifi: rtw88: Fix rtw_init_ht_cap() for RTL8814AU
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
[ Upstream commit c7eea1ba05ca5b0dbf77a27cf2e1e6e2fb3c0043 ]
Set the RX mask and the highest RX rate according to the number of spatial streams the chip can receive. For RTL8814AU that is 3.
--- drivers/net/wireless/realtek/rtw88/main.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-)
drivers/net/wireless/realtek/rtw88/main.c +6 -11
@@ -1141,6 +1141,7 @@ static void rtw_init_ht_cap(struct rtw_dev *rtwdev, struct ieee80211_sta_ht_cap *ht_cap) {struct rtw_efuse *efuse = &rtwdev->efuse; +int i; ht_cap->ht_supported = true; ht_cap->cap =0 ;
@@ -1158,17 +1159,11 @@ static void rtw_init_ht_cap(struct rtw_dev *rtwdev, ht_cap->ampdu_factor =IEEE80211_HT_MAX_AMPDU_64K ; ht_cap->ampdu_density =IEEE80211_HT_MPDU_DENSITY_16 ; ht_cap->mcs.tx_params =IEEE80211_HT_MCS_TX_DEFINED ; -if (efuse->hw_cap.nss >1 ) { - ht_cap->mcs.rx_mask[0 ] =0xFF ; - ht_cap->mcs.rx_mask[1 ] =0xFF ; - ht_cap->mcs.rx_mask[4 ] =0x01 ; - ht_cap->mcs.rx_highest =cpu_to_le16 (300 ); - }else { - ht_cap->mcs.rx_mask[0 ] =0xFF ; - ht_cap->mcs.rx_mask[1 ] =0x00 ; - ht_cap->mcs.rx_mask[4 ] =0x01 ; - ht_cap->mcs.rx_highest =cpu_to_le16 (150 ); - } + +for (i =0 ; i < efuse->hw_cap.nss; i++) + ht_cap->mcs.rx_mask[i] =0xFF ; + ht_cap->mcs.rx_mask[4 ] =0x01 ; + ht_cap->mcs.rx_highest =cpu_to_le16 (150 * efuse->hw_cap.nss); } static void rtw_init_vht_cap(struct rtw_dev *rtwdev,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 190/270 wifi: rtw88: Fix rtw_desc_to_mcsrate() to handle MCS16-31
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
[ Upstream commit 86d04f8f991a0509e318fe886d5a1cf795736c7d ]
This function translates the rate number reported by the hardware into something mac80211 can understand. It was ignoring the 3SS and 4SS HT rates. Translate them too.
Also set *nss to 0 for the HT rates, just to make sure it's initialised.
--- drivers/net/wireless/realtek/rtw88/util.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/realtek/rtw88/util.c +2 -1
@@ -101,7 +101,8 @@ void rtw_desc_to_mcsrate(u16 rate, u8 *mcs, u8 *nss) *nss =4 ; *mcs = rate -DESC_RATEVHT4SS_MCS0 ; }else if (rate >=DESC_RATEMCS0 && - rate <=DESC_RATEMCS15 ) { + rate <=DESC_RATEMCS31 ) { + *nss =0 ; *mcs = rate -DESC_RATEMCS0 ; } }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 191/270 net: pktgen: fix access outside of user given buffer in pktgen_thread_write()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Seiderer <[email protected]>
[ Upstream commit 425e64440ad0a2f03bdaf04be0ae53dededbaa77 ]
Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer).
--- net/core/pktgen.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/core/pktgen.c +4 -3
@@ -1770,8 +1770,8 @@ static ssize_t pktgen_thread_write(struct file *file, i = len;/* Read variable name */ - - len =strn_len (&user_buffer[i],sizeof (name) -1 ); + max =min (sizeof (name) -1 , count - i); + len =strn_len (&user_buffer[i], max);if (len <0 )return len;
@@ -1801,7 +1801,8 @@ static ssize_t pktgen_thread_write(struct file *file,if (!strcmp (name,"add_device" )) {char f[32 ];memset (f,0 ,32 ); - len =strn_len (&user_buffer[i],sizeof (f) -1 ); + max =min (sizeof (f) -1 , count - i); + len =strn_len (&user_buffer[i], max);if (len <0 ) { ret = len; goto out;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 192/270 EDAC/ie31200: work around false positive build warning
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 c29dfd661fe2f8d1b48c7f00590929c04b25bf40 ]
gcc-14 produces a bogus warning in some configurations:
drivers/edac/ie31200_edac.c: In function 'ie31200_probe1.isra':drivers/edac/ie31200_edac.c:412:26: error: 'dimm_info' is used uninitialized [-Werror=uninitialized]
412 | struct dimm_data dimm_info[IE31200_CHANNELS][IE31200_DIMMS_PER_CHANNEL];
| ^~~~~~~~~
drivers/edac/ie31200_edac.c:412:26: note: 'dimm_info' declared here
412 | struct dimm_data dimm_info[IE31200_CHANNELS][IE31200_DIMMS_PER_CHANNEL];
| ^~~~~~~~~I don't see any way the unintialized access could really happen here, but I can see why the compiler gets confused by the two loops.
Instead, rework the two nested loops to only read the addr_decode registers and then keep only one instance of the dimm info structure.
[Tony: Qiuxu pointed out that the "populate DIMM info" comment was left behind in the refactor and suggested moving it. I deleted the comment as unnecessry in front os a call to populate_dimm_info(). That seems pretty self-describing.]
--- drivers/edac/ie31200_edac.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-)
drivers/edac/ie31200_edac.c +13 -15
@@ -398,10 +398,9 @@ static int ie31200_probe1(struct pci_dev *pdev, int dev_idx)int i, j, ret;struct mem_ctl_info *mci =NULL ;struct edac_mc_layer layers[2 ]; -struct dimm_data dimm_info[IE31200_CHANNELS ][IE31200_DIMMS_PER_CHANNEL ];void __iomem *window;struct ie31200_priv *priv; -u32 addr_decode, mad_offset; +u32 addr_decode[IE31200_CHANNELS ], mad_offset;/* * Kaby Lake, Coffee Lake seem to work like Skylake. Please re-visit
@@ -459,19 +458,10 @@ static int ie31200_probe1(struct pci_dev *pdev, int dev_idx) mad_offset =IE31200_MAD_DIMM_0_OFFSET ; } -/* populate DIMM info */ for (i =0 ; i <IE31200_CHANNELS ; i++) { - addr_decode =readl (window + mad_offset + + addr_decode[i] =readl (window + mad_offset + (i *4 )); -edac_dbg (0 ,"addr_decode: 0x%x\n" , addr_decode); -for (j =0 ; j <IE31200_DIMMS_PER_CHANNEL ; j++) { -populate_dimm_info (&dimm_info[i][j], addr_decode, j, - skl); -edac_dbg (0 ,"size: 0x%x, rank: %d, width: %d\n" , - dimm_info[i][j].size, - dimm_info[i][j].dual_rank, - dimm_info[i][j].x16_width); - } +edac_dbg (0 ,"addr_decode: 0x%x\n" , addr_decode[i]); }/*
@@ -482,14 +472,22 @@ static int ie31200_probe1(struct pci_dev *pdev, int dev_idx)*/ for (i =0 ; i <IE31200_DIMMS_PER_CHANNEL ; i++) {for (j =0 ; j <IE31200_CHANNELS ; j++) { +struct dimm_data dimm_info;struct dimm_info *dimm;unsigned long nr_pages; - nr_pages =IE31200_PAGES (dimm_info[j][i].size, skl); +populate_dimm_info (&dimm_info, addr_decode[j], i, + skl); +edac_dbg (0 ,"size: 0x%x, rank: %d, width: %d\n" , + dimm_info.size, + dimm_info.dual_rank, + dimm_info.x16_width); + + nr_pages =IE31200_PAGES (dimm_info.size, skl);if (nr_pages ==0 )continue ; -if (dimm_info[j][i].dual_rank) { +if (dimm_info.dual_rank) { nr_pages = nr_pages /2 ; dimm =edac_get_dimm (mci, (i *2 ) +1 , j,0 ); dimm->nr_pages = nr_pages;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 193/270 can: c_can: Use of_property_present() to test existence of DT property
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 ab1bc2290fd8311d49b87c29f1eb123fcb581bee ]
of_property_read_bool() should be used only on boolean properties.
--- drivers/net/can/c_can/c_can_platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/c_can/c_can_platform.c +1 -1
@@ -330,7 +330,7 @@ static int c_can_plat_probe(struct platform_device *pdev)/* Check if we need custom RAMINIT via syscon. Mostly for TI * platforms. Only supported with DT boot. */ -if (np &&of_property_read_bool (np,"syscon-raminit" )) { +if (np &&of_property_present (np,"syscon-raminit" )) {u32 id;struct c_can_raminit *raminit = &priv->raminit_sys;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 194/270 eth: mlx4: dont try to complete XDP frames in netpoll
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit 8fdeafd66edaf420ea0063a1f13442fe3470fe70 ]
mlx4 doesn't support ndo_xdp_xmit / XDP_REDIRECT and wasn't using page pool until now, so it could run XDP completions in netpoll (NAPI budget == 0) just fine. Page pool has calling context requirements, make sure we don't try to call it from what is potentially HW IRQ context.
--- drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/mellanox/mlx4/en_tx.c +2 -0
@@ -445,6 +445,8 @@ int mlx4_en_process_tx_cq(struct net_device *dev,if (unlikely (!priv->port_up))return 0 ; +if (unlikely (!napi_budget) && cq->type ==TX_XDP ) +return 0 ;netdev_txq_bql_complete_prefetchw (ring->tx_queue);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 195/270 PCI: Fix old_size lower bound in calculate_iosize() too
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]>
[ Upstream commit ff61f380de5652e723168341480cc7adf1dd6213 ]
Commit 903534fa7d30 ("PCI: Fix resource double counting on remove & rescan") fixed double counting of mem resources because of old_size being applied too early.
Fix a similar counting bug on the io resource side.
--- drivers/pci/setup-bus.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/pci/setup-bus.c +2 -4
@@ -806,11 +806,9 @@ static resource_size_t calculate_iosize(resource_size_t size, size = (size &0xff ) + ((size & ~0xffUL ) <<2 );#endif size = size + size1; -if (size < old_size) - size = old_size; - size =ALIGN (max (size, add_size) + children_add_size, align); -return size; + size =max (size, add_size) + children_add_size; +return ALIGN (max (size, old_size), align); } static resource_size_t calculate_memsize(resource_size_t size,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 196/270 ACPI: HED: Always initialize before evged
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiaofei Tan <[email protected]>
[ Upstream commit cccf6ee090c8c133072d5d5b52ae25f3bc907a16 ]
When the HED driver is built-in, it initializes after evged because they both are at the same initcall level, so the initialization ordering depends on the Makefile order. However, this prevents RAS records coming in between the evged driver initialization and the HED driver initialization from being handled.
If the number of such RAS records is above the APEI HEST error source number, the HEST resources may be exhausted, and that may affect subsequent RAS error reporting.
To fix this issue, change the initcall level of HED to subsys_initcall and prevent the driver from being built as a module by changing ACPI_HED in Kconfig from "tristate" to "bool".
--- drivers/acpi/Kconfig | 2 +- drivers/acpi/hed.c | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/acpi/Kconfig +1 -1
@@ -432,7 +432,7 @@ config ACPI_SBS the modules will be called sbs and sbshc. config ACPI_HED - tristate "Hardware Error Device" + bool "Hardware Error Device" help This driver supports the Hardware Error Device (PNP0C33), which is used to report some hardware errors notified via
drivers/acpi/hed.c +6 -1
@@ -72,7 +72,12 @@ static struct acpi_driver acpi_hed_driver = { .notify = acpi_hed_notify, }, }; -module_acpi_driver (acpi_hed_driver); + +static int __init acpi_hed_driver_init (void ) +{ +return acpi_bus_register_driver (&acpi_hed_driver); +} +subsys_initcall (acpi_hed_driver_init);ACPI_MODULE_NAME ("hed" );MODULE_AUTHOR ("Huang Ying" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 197/270 net/mlx5: Modify LSB bitmask in temperature event to include only the first bit
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 633f16d7e07c129a36b882c05379e01ce5bdb542 ]
In the sensor_count field of the MTEWE register, bits 1-62 are supported only for unmanaged switches, not for NICs, and bit 63 is reserved for internal use.
To prevent confusing output that may include set bits that are not relevant to NIC sensors, we update the bitmask to retain only the first bit, which corresponds to the sensor ASIC.
--- drivers/net/ethernet/mellanox/mlx5/core/events.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/events.c +4 -0
@@ -156,6 +156,10 @@ static int temp_warn(struct notifier_block *nb, unsigned long type, void *data)u64 value_msb; value_lsb =be64_to_cpu (eqe->data.temp_warning.sensor_warning_lsb); +/* bit 1-63 are not supported for NICs, +* hence read only bit 0 (asic) from lsb. +*/ + value_lsb &=0x1 ; value_msb =be64_to_cpu (eqe->data.temp_warning.sensor_warning_msb); mlx5_core_warn(events->dev,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 198/270 net/mlx5: Apply rate-limiting to high temperature warning
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 9dd3d5d258aceb37bdf09c8b91fa448f58ea81f0 ]
Wrap the high temperature warning in a temperature event with a call to net_ratelimit() to prevent flooding the kernel log with repeated warning messages when temperature exceeds the threshold multiple times within a short duration.
--- drivers/net/ethernet/mellanox/mlx5/core/events.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/events.c +4 -3
@@ -162,9 +162,10 @@ static int temp_warn(struct notifier_block *nb, unsigned long type, void *data) value_lsb &=0x1 ; value_msb =be64_to_cpu (eqe->data.temp_warning.sensor_warning_msb); -mlx5_core_warn (events->dev, -"High temperature on sensors with bit set %llx %llx" , - value_msb, value_lsb); +if (net_ratelimit ()) +mlx5_core_warn (events->dev, +"High temperature on sensors with bit set %llx %llx" , + value_msb, value_lsb);return NOTIFY_OK ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 199/270 ASoC: ops: Enforce platform maximum on initial value
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Povišer <[email protected]>
[ Upstream commit 783db6851c1821d8b983ffb12b99c279ff64f2ee ]
Lower the volume if it is violating the platform maximum at its initial value (i.e. at the time of the 'snd_soc_limit_volume' call).
--- sound/soc/soc-ops.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-)
sound/soc/soc-ops.c +28 -1
@@ -615,6 +615,33 @@ int snd_soc_get_volsw_range(struct snd_kcontrol *kcontrol, }EXPORT_SYMBOL_GPL (snd_soc_get_volsw_range); +static int snd_soc_clip_to_platform_max (struct snd_kcontrol *kctl) +{ +struct soc_mixer_control *mc = (struct soc_mixer_control *)kctl->private_value; +struct snd_ctl_elem_value uctl; +int ret; + +if (!mc->platform_max) +return 0 ; + + ret = kctl->get (kctl, &uctl); +if (ret <0 ) +return ret; + +if (uctl.value.integer.value[0 ] > mc->platform_max) + uctl.value.integer.value[0 ] = mc->platform_max; + +if (snd_soc_volsw_is_stereo (mc) && + uctl.value.integer.value[1 ] > mc->platform_max) + uctl.value.integer.value[1 ] = mc->platform_max; + + ret = kctl->put (kctl, &uctl); +if (ret <0 ) +return ret; + +return 0 ; +} +/** * snd_soc_limit_volume - Set new limit to an existing volume control. *
@@ -640,7 +667,7 @@ int snd_soc_limit_volume(struct snd_soc_card *card, mc = (struct soc_mixer_control *)kctl->private_value;if (max <= mc->max) { mc->platform_max = max; - ret =0 ; + ret =snd_soc_clip_to_platform_max (kctl); } }return ret;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 200/270 ASoC: tas2764: Power up/down amp on mute ops
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hector Martin <[email protected]>
[ Upstream commit 1c3b5f37409682184669457a5bdf761268eafbe5 ]
The ASoC convention is that clocks are removed after codec mute, and power up/down is more about top level power management. For these chips, the "mute" state still expects a TDM clock, and yanking the clock in this state will trigger clock errors. So, do the full shutdown<->mute<->active transition on the mute operation, so the amp is in software shutdown by the time the clocks are removed.
This fixes TDM clock errors when streams are stopped.
--- sound/soc/codecs/tas2764.c | 51 ++++++++++++++++---------------------- 1 file changed, 21 insertions(+), 30 deletions(-)
sound/soc/codecs/tas2764.c +21 -30
@@ -130,33 +130,6 @@ static SOC_ENUM_SINGLE_DECL(static const struct snd_kcontrol_new tas2764_asi1_mux =SOC_DAPM_ENUM ("ASI1 Source" , tas2764_ASI1_src_enum); -static int tas2764_dac_event (struct snd_soc_dapm_widget *w, -struct snd_kcontrol *kcontrol,int event) -{ -struct snd_soc_component *component =snd_soc_dapm_to_component (w->dapm); -struct tas2764_priv *tas2764 =snd_soc_component_get_drvdata (component); -int ret; - -switch (event) { -case SND_SOC_DAPM_POST_PMU : - tas2764->dac_powered = true; - ret =tas2764_update_pwr_ctrl (tas2764); -break ; -case SND_SOC_DAPM_PRE_PMD : - tas2764->dac_powered = false; - ret =tas2764_update_pwr_ctrl (tas2764); -break ; -default : -dev_err (tas2764->dev,"Unsupported event\n" ); -return -EINVAL ; - } - -if (ret <0 ) -return ret; - -return 0 ; -} -static const struct snd_kcontrol_new isense_switch =SOC_DAPM_SINGLE ("Switch" ,TAS2764_PWR_CTRL ,TAS2764_ISENSE_POWER_EN ,1 ,1 ); static const struct snd_kcontrol_new vsense_switch =
@@ -169,8 +142,7 @@ static const struct snd_soc_dapm_widget tas2764_dapm_widgets[] = { 1, &isense_switch),SND_SOC_DAPM_SWITCH ("VSENSE" ,TAS2764_PWR_CTRL ,TAS2764_VSENSE_POWER_EN ,1 , &vsense_switch), -SND_SOC_DAPM_DAC_E ("DAC" ,NULL ,SND_SOC_NOPM ,0 ,0 , tas2764_dac_event, -SND_SOC_DAPM_POST_PMU |SND_SOC_DAPM_PRE_PMD ), +SND_SOC_DAPM_DAC ("DAC" ,NULL ,SND_SOC_NOPM ,0 ,0 ),SND_SOC_DAPM_OUTPUT ("OUT" ),SND_SOC_DAPM_SIGGEN ("VMON" ),SND_SOC_DAPM_SIGGEN ("IMON" )
@@ -191,9 +163,28 @@ static int tas2764_mute(struct snd_soc_dai *dai, int mute, int direction) {struct tas2764_priv *tas2764 =snd_soc_component_get_drvdata (dai->component); +int ret; + +if (!mute) { + tas2764->dac_powered = true; + ret =tas2764_update_pwr_ctrl (tas2764); +if (ret) +return ret; + } tas2764->unmuted = !mute; -return tas2764_update_pwr_ctrl (tas2764); + ret =tas2764_update_pwr_ctrl (tas2764); +if (ret) +return ret; + +if (mute) { + tas2764->dac_powered = false; + ret =tas2764_update_pwr_ctrl (tas2764); +if (ret) +return ret; + } + +return 0 ; }static int tas2764_set_bitwidth (struct tas2764_priv *tas2764,int bitwidth)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 201/270 ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuninori Morimoto <[email protected]>
[ Upstream commit 7f1186a8d738661b941b298fd6d1d5725ed71428 ]
snd_soc_dai_set_tdm_slot() calls .xlate_tdm_slot_mask() or snd_soc_xlate_tdm_slot_mask(), but didn't check its return value. Let's check it.
This patch might break existing driver. In such case, let's makes each func to void instead of int.
--- sound/soc/soc-dai.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
sound/soc/soc-dai.c +5 -3
@@ -208,10 +208,11 @@ int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai,if (dai->driver->ops && dai->driver->ops->xlate_tdm_slot_mask) - dai->driver->ops->xlate_tdm_slot_mask (slots, - &tx_mask, &rx_mask); + ret = dai->driver->ops->xlate_tdm_slot_mask (slots, &tx_mask, &rx_mask);else -snd_soc_xlate_tdm_slot_mask (slots, &tx_mask, &rx_mask); + ret =snd_soc_xlate_tdm_slot_mask (slots, &tx_mask, &rx_mask); +if (ret) + goto err; dai->tx_mask = tx_mask; dai->rx_mask = rx_mask;
@@ -220,6 +221,7 @@ int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai, dai->driver->ops->set_tdm_slot) ret = dai->driver->ops->set_tdm_slot (dai, tx_mask, rx_mask, slots, slot_width); +err:return soc_dai_ret (dai, ret); }EXPORT_SYMBOL_GPL (snd_soc_dai_set_tdm_slot);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 202/270 pinctrl: devicetree: do not goto err when probing hogs in pinctrl_dt_to_map
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valentin Caron <[email protected]>
[ Upstream commit c98868e816209e568c9d72023ba0bc1e4d96e611 ]
Cross case in pinctrl framework make impossible to an hogged pin and another, not hogged, used within the same device-tree node. For example with this simplified device-tree :
&pinctrl {
pinctrl_pin_1: pinctrl-pin-1 {
pins = "dummy-pinctrl-pin";
};
};
&rtc {
pinctrl-names = "default"
pinctrl-0 = <&pinctrl_pin_1 &rtc_pin_1> rtc_pin_1: rtc-pin-1 {
pins = "dummy-rtc-pin";
};};
"pinctrl_pin_1" configuration is never set. This produces this path in the code:
really_probe()
pinctrl_bind_pins()
| devm_pinctrl_get()
| pinctrl_get()
| create_pinctrl()
| pinctrl_dt_to_map()
| // Hog pin create an abort for all pins of the node
| ret = dt_to_map_one_config()
| | /* Do not defer probing of hogs (circular loop) */
| | if (np_pctldev == p->dev->of_node)
| | return -ENODEV;
| if (ret)
| goto err
|
call_driver_probe()
stm32_rtc_probe()
pinctrl_enable()
pinctrl_claim_hogs()
create_pinctrl()
for_each_maps(maps_node, i, map)
// Not hog pin is skipped
if (pctldev && strcmp(dev_name(pctldev->dev),
map->ctrl_dev_name))
continue;At the first call of create_pinctrl() the hogged pin produces an abort to avoid a defer of hogged pins. All other pin configurations are trashed.
At the second call, create_pinctrl is now called with pctldev parameter to get hogs, but in this context only hogs are set. And other pins are skipped.
To handle this, do not produce an abort in the first call of create_pinctrl(). Classic pin configuration will be set in pinctrl_bind_pins() context. And the hogged pin configuration will be set in pinctrl_claim_hogs() context.
--- drivers/pinctrl/devicetree.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/pinctrl/devicetree.c +8 -2
@@ -143,10 +143,14 @@ static int dt_to_map_one_config(struct pinctrl *p, pctldev =get_pinctrl_dev_from_of_node (np_pctldev);if (pctldev)break ; -/* Do not defer probing of hogs (circular loop) */ +/* +* Do not defer probing of hogs (circular loop) +* +* Return 1 to let the caller catch the case. +*/ if (np_pctldev == p->dev->of_node) {of_node_put (np_pctldev); -return -ENODEV ; +return 1 ; } }of_node_put (np_pctldev);
@@ -265,6 +269,8 @@ int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev) ret =dt_to_map_one_config (p, pctldev, statename, np_config);of_node_put (np_config); +if (ret ==1 ) +continue ;if (ret <0 ) goto err; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 203/270 smack: recognize ipv4 CIPSO w/o categories
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Andreev <[email protected]>
[ Upstream commit a158a937d864d0034fea14913c1f09c6d5f574b8 ]
If SMACK label has CIPSO representation w/o categories, e.g.:
| # cat /smack/cipso2 | foo 10 | @ 250/2 | ...
then SMACK does not recognize such CIPSO in input ipv4 packets and substitues '*' label instead. Audit records may look like
| lsm=SMACK fn=smack_socket_sock_rcv_skb action=denied
| subject="*" object="_" requested=w pid=0 comm="swapper/1" ...
This happens in two steps:
1) security/smack/smackfs.c`smk_set_cipso does not clear NETLBL_SECATTR_MLS_CAT
from (struct smack_known *)skp->smk_netlabel.flags on assigning CIPSO w/o categories:
| rcu_assign_pointer(skp->smk_netlabel.attr.mls.cat, ncats.attr.mls.cat); | skp->smk_netlabel.attr.mls.lvl = ncats.attr.mls.lvl;
2) security/smack/smack_lsm.c`smack_from_secattr
can not match skp->smk_netlabel with input packet's struct netlbl_lsm_secattr *sap
because sap->flags have not NETLBL_SECATTR_MLS_CAT (what is correct) but skp->smk_netlabel.flags have (what is incorrect):
| if ((sap->flags & NETLBL_SECATTR_MLS_CAT) == 0) {
| if ((skp->smk_netlabel.flags &
| NETLBL_SECATTR_MLS_CAT) == 0)
| found = 1;
| break;
| }This commit sets/clears NETLBL_SECATTR_MLS_CAT in skp->smk_netlabel.flags according to the presense of CIPSO categories. The update of smk_netlabel is not atomic, so input packets processing still may be incorrect during short time while update proceeds.
--- security/smack/smackfs.c | 4 ++++ 1 file changed, 4 insertions(+)
security/smack/smackfs.c +4 -0
@@ -921,6 +921,10 @@ static ssize_t smk_set_cipso(struct file *file, const char __user *buf,if (rc >=0 ) { old_cat = skp->smk_netlabel.attr.mls.cat;rcu_assign_pointer (skp->smk_netlabel.attr.mls.cat, ncats.attr.mls.cat); +if (ncats.attr.mls.cat) + skp->smk_netlabel.flags |=NETLBL_SECATTR_MLS_CAT ; +else + skp->smk_netlabel.flags &= ~(u32 )NETLBL_SECATTR_MLS_CAT ; skp->smk_netlabel.attr.mls.lvl = ncats.attr.mls.lvl;synchronize_rcu ();netlbl_catmap_free (old_cat);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 204/270 media: v4l: Memset argument to 0 before calling get_mbus_config pad op
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <[email protected]>
[ Upstream commit 91d6a99acfa5ce9f95ede775074b80f7193bd717 ]
Memset the config argument to get_mbus_config V4L2 sub-device pad operation to zero before calling the operation. This ensures the callers don't need to bother with it nor the implementations need to set all fields that may not be relevant to them.
--- drivers/media/v4l2-core/v4l2-subdev.c | 2 ++ include/media/v4l2-subdev.h | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-)
drivers/media/v4l2-core/v4l2-subdev.c +2 -0
@@ -312,6 +312,8 @@ static int call_enum_dv_timings(struct v4l2_subdev *sd,static int call_get_mbus_config (struct v4l2_subdev *sd,unsigned int pad,struct v4l2_mbus_config *config) { +memset (config,0 ,sizeof (*config)); +return check_pad (sd, pad) ? : sd->ops->pad->get_mbus_config (sd, pad, config); }
include/media/v4l2-subdev.h +3 -1
@@ -676,7 +676,9 @@ struct v4l2_subdev_pad_config {* possible configuration from the remote end, likely calling * this operation as close as possible to stream on time. The * operation shall fail if the pad index it has been called on -* is not valid or in case of unrecoverable failures. +* is not valid or in case of unrecoverable failures. The +* config argument has been memset to 0 just before calling +* the op. * * @set_mbus_config: set the media bus configuration of a remote sub-device. * This operations is intended to allow, in combination with
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 205/270 net/mlx4_core: Avoid impossible mlx4_db_alloc() order value
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
[ Upstream commit 4a6f18f28627e121bd1f74b5fcc9f945d6dbeb1e ]
GCC can see that the value range for "order" is capped, but this leads it to consider that it might be negative, leading to a false positive warning (with GCC 15 with -Warray-bounds -fdiagnostics-details):
../drivers/net/ethernet/mellanox/mlx4/alloc.c:691:47: error: array subscript -1 is below array bounds of 'long unsigned int *[2]' [-Werror=array-bounds=]
691 | i = find_first_bit(pgdir->bits[o], MLX4_DB_PER_PAGE >> o);
| ~~~~~~~~~~~^~~
'mlx4_alloc_db_from_pgdir': events 1-2
691 | i = find_first_bit(pgdir->bits[o], MLX4_DB_PER_PAGE >> o); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | | (2) out of array bounds here
| (1) when the condition is evaluated to true In file included from ../drivers/net/ethernet/mellanox/mlx4/mlx4.h:53,
from ../drivers/net/ethernet/mellanox/mlx4/alloc.c:42:../include/linux/mlx4/device.h:664:33: note: while referencing 'bits'
664 | unsigned long *bits[2];
| ^~~~
Switch the argument to unsigned int, which removes the compiler needing to consider negative values.
--- drivers/net/ethernet/mellanox/mlx4/alloc.c | 6 +++--- include/linux/mlx4/device.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)
drivers/net/ethernet/mellanox/mlx4/alloc.c +3 -3
@@ -682,9 +682,9 @@ static struct mlx4_db_pgdir *mlx4_alloc_db_pgdir(struct device *dma_device) }static int mlx4_alloc_db_from_pgdir (struct mlx4_db_pgdir *pgdir, -struct mlx4_db *db,int order) +struct mlx4_db *db,unsigned int order) { -int o; +unsigned int o;int i;for (o = order; o <=1 ; ++o) {
@@ -712,7 +712,7 @@ static int mlx4_alloc_db_from_pgdir(struct mlx4_db_pgdir *pgdir,return 0 ; } -int mlx4_db_alloc (struct mlx4_dev *dev,struct mlx4_db *db,int order) +int mlx4_db_alloc (struct mlx4_dev *dev,struct mlx4_db *db,unsigned int order) {struct mlx4_priv *priv =mlx4_priv (dev);struct mlx4_db_pgdir *pgdir;
include/linux/mlx4/device.h +1 -1
@@ -1116,7 +1116,7 @@ int mlx4_write_mtt(struct mlx4_dev *dev, struct mlx4_mtt *mtt,int mlx4_buf_write_mtt (struct mlx4_dev *dev,struct mlx4_mtt *mtt,struct mlx4_buf *buf); -int mlx4_db_alloc (struct mlx4_dev *dev,struct mlx4_db *db,int order); +int mlx4_db_alloc (struct mlx4_dev *dev,struct mlx4_db *db,unsigned int order);void mlx4_db_free (struct mlx4_dev *dev,struct mlx4_db *db); int mlx4_alloc_hwq_res(struct mlx4_dev *dev, struct mlx4_hwq_resources *wqres,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 206/270 phy: core: dont require set_mode() callback for phy_get_mode() to work
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Baryshkov <[email protected]>
[ Upstream commit d58c04e305afbaa9dda7969151f06c4efe2c98b0 ]
As reported by Damon Ding, the phy_get_mode() call doesn't work as expected unless the PHY driver has a .set_mode() call. This prompts PHY drivers to have empty stubs for .set_mode() for the sake of being able to get the mode.
Make .set_mode() callback truly optional and update PHY's mode even if it there is none.
--- drivers/phy/phy-core.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/phy/phy-core.c +4 -3
@@ -360,13 +360,14 @@ EXPORT_SYMBOL_GPL(phy_power_off);int phy_set_mode_ext (struct phy *phy,enum phy_mode mode,int submode) { -int ret; +int ret =0 ; -if (!phy || !phy->ops->set_mode) +if (!phy)return 0 ;mutex_lock (&phy->mutex); - ret = phy->ops->set_mode (phy, mode, submode); +if (phy->ops->set_mode) + ret = phy->ops->set_mode (phy, mode, submode);if (!ret) phy->attrs.mode = mode;mutex_unlock (&phy->mutex);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 207/270 drm/amd/display: Initial psr_version with correct setting
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Chung <[email protected]>
[ Upstream commit d8c782cac5007e68e7484d420168f12d3490def6 ]
[Why & How]
The initial setting for psr_version is not correct while create a virtual link.
The default psr_version should be DC_PSR_VERSION_UNSUPPORTED.
--- drivers/gpu/drm/amd/display/dc/core/dc.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/display/dc/core/dc.c +1 -0
@@ -228,6 +228,7 @@ static bool create_links( link->link_id.type =OBJECT_TYPE_CONNECTOR ; link->link_id.id =CONNECTOR_ID_VIRTUAL ; link->link_id.enum_id =ENUM_ID_1 ; + link->psr_settings.psr_version =DC_PSR_VERSION_UNSUPPORTED ; link->link_enc =kzalloc (sizeof (*link->link_enc),GFP_KERNEL );if (!link->link_enc) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 208/270 net/mlx5: Extend Ethtool loopback selftest to support non-linear SKB
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexei Lazar <[email protected]>
[ Upstream commit 95b9606b15bb3ce1198d28d2393dd0e1f0a5f3e9 ]
Current loopback test validation ignores non-linear SKB case in the SKB access, which can lead to failures in scenarios such as when HW GRO is enabled.
Linearize the SKB so both cases will be handled.
--- drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c +3 -0
@@ -188,6 +188,9 @@ mlx5e_test_loopback_validate(struct sk_buff *skb,struct udphdr *udph;struct iphdr *iph; +if (skb_linearize (skb)) + goto out; +/* We are only going to peek, no need to clone the SKB */ if (MLX5E_TEST_PKT_SIZE -ETH_HLEN >skb_headlen (skb)) goto out;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 209/270 net/mlx5e: set the tx_queue_len for pfifo_fast
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Tu <[email protected]>
[ Upstream commit a38cc5706fb9f7dc4ee3a443f61de13ce1e410ed ]
By default, the mq netdev creates a pfifo_fast qdisc. On a system with 16 core, the pfifo_fast with 3 bands consumes 16 * 3 * 8 (size of pointer) * 1024 (default tx queue len) = 393KB. The patch sets the tx qlen to representor default value, 128 (1<<MLX5E_REP_PARAMS_DEF_LOG_SQ_SIZE), which consumes 16 * 3 * 8 * 128 = 49KB, saving 344KB for each representor at ECPF.
--- drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +2 -0
@@ -740,6 +740,8 @@ static void mlx5e_build_rep_netdev(struct net_device *netdev) } netdev->watchdog_timeo =15 *HZ ; +if (mlx5_core_is_ecpf (mdev)) + netdev->tx_queue_len =1 <<MLX5E_REP_PARAMS_DEF_LOG_SQ_SIZE ; netdev->features |=NETIF_F_NETNS_LOCAL ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 210/270 net/mlx5e: reduce rep rxq depth to 256 for ECPF
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Tu <[email protected]>
[ Upstream commit b9cc8f9d700867aaa77aedddfea85e53d5e5d584 ]
By experiments, a single queue representor netdev consumes kernel memory around 2.8MB, and 1.8MB out of the 2.8MB is due to page pool for the RXQ. Scaling to a thousand representors consumes 2.8GB, which becomes a memory pressure issue for embedded devices such as BlueField-2 16GB / BlueField-3 32GB memory.
Since representor netdevs mostly handles miss traffic, and ideally, most of the traffic will be offloaded, reduce the default non-uplink rep netdev's RXQ default depth from 1024 to 256 if mdev is ecpf eswitch manager. This saves around 1MB of memory per regular RQ, (1024 - 256) * 2KB, allocated from page pool.
With rxq depth of 256, the netlink page pool tool reports $./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml \
--dump page-pool-get
{'id': 277,
'ifindex': 9,
'inflight': 128,
'inflight-mem': 786432,
'napi-id': 775}]
This is due to mtu 1500 + headroom consumes half pages, so 256 rxq entries consumes around 128 pages (thus create a page pool with size 128), shown above at inflight.
Note that each netdev has multiple types of RQs, including Regular RQ, XSK, PTP, Drop, Trap RQ. Since non-uplink representor only supports regular rq, this patch only changes the regular RQ's default depth.
--- drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +3 -0
@@ -53,6 +53,7 @@#define MLX5E_REP_PARAMS_DEF_LOG_SQ_SIZE \ max(0x7, MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE)#define MLX5E_REP_PARAMS_DEF_NUM_CHANNELS 1 +#define MLX5E_REP_PARAMS_DEF_LOG_RQ_SIZE 0x8static const char mlx5e_rep_driver_name[] ="mlx5e_rep" ;
@@ -702,6 +703,8 @@ static void mlx5e_build_rep_params(struct net_device *netdev)/* RQ */ mlx5e_build_rq_params (mdev, params); +if (!mlx5e_is_uplink_rep (priv) &&mlx5_core_is_ecpf (mdev)) + params->log_rq_mtu_frames =MLX5E_REP_PARAMS_DEF_LOG_RQ_SIZE ;/* CQ moderation params */ params->rx_dim_enabled =MLX5_CAP_GEN (mdev, cq_moderation);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 211/270 ip: fib_rules: Fetch net from fib_rule in fib[46]_rule_configure().
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 5a1ccffd30a08f5a2428cd5fbb3ab03e8eb6c66d ]
The following patch will not set skb->sk from VRF path.
Let's fetch net from fib_rule->fr_net instead of sock_net(skb->sk) in fib[46]_rule_configure().
--- net/ipv4/fib_rules.c | 4 ++-- net/ipv6/fib6_rules.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
net/ipv4/fib_rules.c +2 -2
@@ -226,9 +226,9 @@ static int fib4_rule_configure(struct fib_rule *rule, struct sk_buff *skb,struct nlattr **tb, struct netlink_ext_ack *extack) { - struct net *net = sock_net(skb->sk); + struct fib4_rule *rule4 = (struct fib4_rule *)rule; +struct net *net = rule->fr_net;int err = -EINVAL ; -struct fib4_rule *rule4 = (struct fib4_rule *) rule;if (frh->tos & ~IPTOS_TOS_MASK ) {NL_SET_ERR_MSG (extack,"Invalid tos" );
net/ipv6/fib6_rules.c +2 -2
@@ -353,9 +353,9 @@ static int fib6_rule_configure(struct fib_rule *rule, struct sk_buff *skb,struct nlattr **tb, struct netlink_ext_ack *extack) { + struct fib6_rule *rule6 = (struct fib6_rule *)rule; +struct net *net = rule->fr_net;int err = -EINVAL ; -struct net *net =sock_net (skb->sk); -struct fib6_rule *rule6 = (struct fib6_rule *) rule;if (rule->action ==FR_ACT_TO_TBL && !rule->l3mdev) {if (rule->table ==RT6_TABLE_UNSPEC ) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 212/270 wifi: rtw88: Fix download_firmware_validate() for RTL8814AU
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
[ Upstream commit 9e8243025cc06abc975c876dffda052073207ab3 ]
After the firmware is uploaded, download_firmware_validate() checks some bits in REG_MCUFW_CTRL to see if everything went okay. The RTL8814AU power on sequence sets bits 13 and 12 to 2, which this function does not expect, so it thinks the firmware upload failed.
Make download_firmware_validate() ignore bits 13 and 12.
--- drivers/net/wireless/realtek/rtw88/reg.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/realtek/rtw88/reg.h +2 -1
@@ -107,6 +107,7 @@#define BIT_SHIFT_ROM_PGE 16#define BIT_FW_INIT_RDY BIT(15)#define BIT_FW_DW_RDY BIT(14) +#define BIT_CPU_CLK_SEL (BIT(12) | BIT(13))#define BIT_RPWM_TOGGLE BIT(7)#define BIT_RAM_DL_SEL BIT(7)/* legacy only */ #define BIT_DMEM_CHKSUM_OK BIT(6)
@@ -124,7 +125,7 @@ BIT_CHECK_SUM_OK)#define FW_READY_LEGACY (BIT_MCUFWDL_RDY | BIT_FWDL_CHK_RPT | \ BIT_WINTINI_RDY | BIT_RAM_DL_SEL) -#define FW_READY_MASK 0xffff +#define FW_READY_MASK (0xffff & ~BIT_CPU_CLK_SEL)#define REG_MCU_TST_CFG 0x84#define VAL_FW_TRIGGER 0x1
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 213/270 hwmon: (xgene-hwmon) use appropriate type for the latency value
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Vatoropin <[email protected]>
[ Upstream commit 8df0f002827e18632dcd986f7546c1abf1953a6f ]
The expression PCC_NUM_RETRIES * pcc_chan->latency is currently being evaluated using 32-bit arithmetic.
Since a value of type 'u64' is used to store the eventual result, and this result is later sent to the function usecs_to_jiffies with input parameter unsigned int, the current data type is too wide to store the value of ctx->usecs_lat.
Change the data type of "usecs_lat" to a more suitable (narrower) type.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/hwmon/xgene-hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/xgene-hwmon.c +1 -1
@@ -110,7 +110,7 @@ struct xgene_hwmon_dev {phys_addr_t comm_base_addr;void *pcc_comm_addr; -u64 usecs_lat; +unsigned int usecs_lat; };/*
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 214/270 vxlan: Annotate FDB data races
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 f6205f8215f12a96518ac9469ff76294ae7bd612 ]
The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2].
Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE().
[1]
BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit
write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:
vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:
vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f
Reported by Kernel Concurrency Sanitizer on:
CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[2]
#!/bin/bash
set +H
echo whitelist > /sys/kernel/debug/kcsan
echo !vxlan_xmit > /sys/kernel/debug/kcsan
ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
--- drivers/net/vxlan/vxlan_core.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/net/vxlan/vxlan_core.c +9 -9
@@ -333,9 +333,9 @@ static int vxlan_fdb_info(struct sk_buff *skb, struct vxlan_dev *vxlan, be32_to_cpu(fdb->vni))) goto nla_put_failure; - ci.ndm_used =jiffies_to_clock_t (now - fdb->used); + ci.ndm_used =jiffies_to_clock_t (now -READ_ONCE (fdb->used)); ci.ndm_confirmed =0 ; - ci.ndm_updated =jiffies_to_clock_t (now - fdb->updated); + ci.ndm_updated =jiffies_to_clock_t (now -READ_ONCE (fdb->updated)); ci.ndm_refcnt =0 ;if (nla_put (skb,NDA_CACHEINFO ,sizeof (ci), &ci))
@@ -541,8 +541,8 @@ static struct vxlan_fdb *vxlan_find_mac(struct vxlan_dev *vxlan,struct vxlan_fdb *f; f =__vxlan_find_mac (vxlan, mac, vni); -if (f && f->used != jiffies) - f->used = jiffies; +if (f &&READ_ONCE (f->used) != jiffies) +WRITE_ONCE (f->used, jiffies);return f; }
@@ -1072,12 +1072,12 @@ static int vxlan_fdb_update_existing(struct vxlan_dev *vxlan, !(f->flags & NTF_VXLAN_ADDED_BY_USER)) {if (f->state != state) { f->state = state; - f->updated = jiffies; +WRITE_ONCE (f->updated, jiffies); notify =1 ; }if (f->flags != fdb_flags) { f->flags = fdb_flags; - f->updated = jiffies; +WRITE_ONCE (f->updated, jiffies); notify =1 ; } }
@@ -1111,7 +1111,7 @@ static int vxlan_fdb_update_existing(struct vxlan_dev *vxlan, }if (ndm_flags &NTF_USE ) - f->used = jiffies; +WRITE_ONCE (f->used, jiffies);if (notify) {if (rd ==NULL )
@@ -1524,7 +1524,7 @@ static bool vxlan_snoop(struct net_device *dev, src_mac, &rdst->remote_ip.sa, &src_ip->sa); rdst->remote_ip = *src_ip; - f->updated = jiffies; +WRITE_ONCE (f->updated, jiffies);vxlan_fdb_notify (vxlan, f, rdst,RTM_NEWNEIGH , true,NULL ); }else {u32 hash_index =fdb_head_index (vxlan, src_mac, vni);
@@ -2999,7 +2999,7 @@ static void vxlan_cleanup(struct timer_list *t)if (f->flags &NTF_EXT_LEARNED )continue ; - timeout = f->used + vxlan->cfg.age_interval *HZ ; + timeout =READ_ONCE (f->used) + vxlan->cfg.age_interval *HZ ;if (time_before_eq (timeout, jiffies)) { netdev_dbg(vxlan->dev, "garbage collect %pM\n",
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 215/270 rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ankur Arora <[email protected]>
[ Upstream commit 83b28cfe796464ebbde1cf7916c126da6d572685 ]
With PREEMPT_RCU=n, cond_resched() provides urgently needed quiescent states for read-side critical sections via rcu_all_qs(). One reason why this was needed: lacking preempt-count, the tick handler has no way of knowing whether it is executing in a read-side critical section or not.
With (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), we get (PREEMPT_COUNT=y, PREEMPT_RCU=n). In this configuration cond_resched() is a stub and does not provide quiescent states via rcu_all_qs(). (PREEMPT_RCU=y provides this information via rcu_read_unlock() and its nesting counter.)
So, use the availability of preempt_count() to report quiescent states in rcu_flavor_sched_clock_irq().
--- kernel/rcu/tree_plugin.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
kernel/rcu/tree_plugin.h +7 -4
@@ -919,13 +919,16 @@ static void rcu_preempt_check_blocked_tasks(struct rcu_node *rnp)*/ static void rcu_flavor_sched_clock_irq (int user) { -if (user ||rcu_is_cpu_rrupt_from_idle ()) { +if (user ||rcu_is_cpu_rrupt_from_idle () || + (IS_ENABLED (CONFIG_PREEMPT_COUNT ) && + (preempt_count () ==HARDIRQ_OFFSET ))) {/* * Get here if this CPU took its interrupt from user -* mode or from the idle loop, and if this is not a -* nested interrupt. In this case, the CPU is in -* a quiescent state, so note it. +* mode, from the idle loop without this being a nested +* interrupt, or while not holding the task preempt count +* (with PREEMPT_COUNT=y). In this case, the CPU is in a +* quiescent state, so note it. * * No memory barrier is required here because rcu_qs() * references only CPU-local variables that other CPUs
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 216/270 rcu: fix header guard for rcu_all_qs()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ankur Arora <[email protected]>
[ Upstream commit ad6b5b73ff565e88aca7a7d1286788d80c97ba71 ]
rcu_all_qs() is defined for !CONFIG_PREEMPT_RCU but the declaration is conditioned on CONFIG_PREEMPTION.
With CONFIG_PREEMPT_LAZY, CONFIG_PREEMPTION=y does not imply CONFIG_PREEMPT_RCU=y.
Decouple the two.
--- include/linux/rcutree.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/rcutree.h +1 -1
@@ -64,7 +64,7 @@ extern int rcu_scheduler_active __read_mostly;void rcu_end_inkernel_boot (void );bool rcu_inkernel_boot_has_ended (void );bool rcu_is_watching (void ); -#ifndef CONFIG_PREEMPTION +#ifndef CONFIG_PREEMPT_RCU void rcu_all_qs (void );#endif
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 217/270 scsi: lpfc: Handle duplicate D_IDs in ndlp search-by D_ID routine
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Justin Tee <[email protected]>
[ Upstream commit 56c3d809b7b450379162d0b8a70bbe71ab8db706 ]
After a port swap between separate fabrics, there may be multiple nodes in the vport's fc_nodes list with the same fabric well known address. Duplication is temporary and eventually resolves itself after dev_loss_tmo expires, but nameserver queries may still occur before dev_loss_tmo. This possibly results in returning stale fabric ndlp objects. Fix by adding an nlp_state check to ensure the ndlp search routine returns the correct newer allocated ndlp fabric object.
--- drivers/scsi/lpfc/lpfc_hbadisc.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/scsi/lpfc/lpfc_hbadisc.c +12 -5
@@ -5407,6 +5407,7 @@ static struct lpfc_nodelist * __lpfc_findnode_did(struct lpfc_vport *vport, uint32_t did) {struct lpfc_nodelist *ndlp; +struct lpfc_nodelist *np =NULL ;uint32_t data1;list_for_each_entry (ndlp, &vport->fc_nodes, nlp_listp) {
@@ -5421,14 +5422,20 @@ __lpfc_findnode_did(struct lpfc_vport *vport, uint32_t did) ndlp, ndlp->nlp_DID, ndlp->nlp_flag, data1, ndlp->nlp_rpi, ndlp->active_rrqs_xri_bitmap); -return ndlp; + +/* Check for new or potentially stale node */ +if (ndlp->nlp_state !=NLP_STE_UNUSED_NODE ) +return ndlp; + np = ndlp; } } -/* FIND node did <did> NOT FOUND */ -lpfc_printf_vlog (vport,KERN_INFO ,LOG_NODE , -"0932 FIND node did x%x NOT FOUND.\n" , did); -return NULL ; +if (!np) +/* FIND node did <did> NOT FOUND */ +lpfc_printf_vlog (vport,KERN_INFO ,LOG_NODE , +"0932 FIND node did x%x NOT FOUND.\n" , did); + +return np; } struct lpfc_nodelist *
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 218/270 scsi: st: Restore some drive settings after reset
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai Mäkisara <[email protected]>
[ Upstream commit 7081dc75df79696d8322d01821c28e53416c932c ]
Some of the allowed operations put the tape into a known position to continue operation assuming only the tape position has changed. But reset sets partition, density and block size to drive default values. These should be restored to the values before reset.
Normally the current block size and density are stored by the drive. If the settings have been changed, the changed values have to be saved by the driver across reset.
--- drivers/scsi/st.c | 24 +++++++++++++++++++++--- drivers/scsi/st.h | 2 ++ 2 files changed, 23 insertions(+), 3 deletions(-)
drivers/scsi/st.c +21 -3
@@ -951,7 +951,6 @@ static void reset_state(struct scsi_tape *STp) STp->partition =find_partition (STp);if (STp->partition <0 ) STp->partition =0 ; - STp->new_partition = STp->partition; } }
@@ -2921,14 +2920,17 @@ static int st_int_ioctl(struct scsi_tape *STp, unsigned int cmd_in, unsigned lonif (cmd_in ==MTSETDENSITY ) { (STp->buffer)->b_data[4 ] = arg; STp->density_changed =1 ;/* At least we tried ;-) */ + STp->changed_density = arg; }else if (cmd_in ==SET_DENS_AND_BLK ) (STp->buffer)->b_data[4 ] = arg >>24 ;else (STp->buffer)->b_data[4 ] = STp->density;if (cmd_in ==MTSETBLK || cmd_in ==SET_DENS_AND_BLK ) { ltmp = arg &MT_ST_BLKSIZE_MASK ; -if (cmd_in ==MTSETBLK ) +if (cmd_in ==MTSETBLK ) { STp->blksize_changed =1 ;/* At least we tried ;-) */ + STp->changed_blksize = arg; + } }else ltmp = STp->block_size; (STp->buffer)->b_data[9 ] = (ltmp >>16 );
@@ -3628,9 +3630,25 @@ static long st_ioctl_common(struct file *file, unsigned int cmd_in, void __user retval = (-EIO ); goto out; } -reset_state (STp); +reset_state (STp);/* Clears pos_unknown */ /* remove this when the midlevel properly clears was_reset */ STp->device->was_reset =0 ; + +/* Fix the device settings after reset, ignore errors */ +if (mtc.mt_op ==MTREW || mtc.mt_op ==MTSEEK || + mtc.mt_op ==MTEOM ) { +if (STp->can_partitions) { +/* STp->new_partition contains the +* latest partition set +*/ + STp->partition =0 ; +switch_partition (STp); + } +if (STp->density_changed) +st_int_ioctl (STp,MTSETDENSITY , STp->changed_density); +if (STp->blksize_changed) +st_int_ioctl (STp,MTSETBLK , STp->changed_blksize); + } } if (mtc.mt_op != MTNOP && mtc.mt_op != MTSETBLK &&
drivers/scsi/st.h +2 -0
@@ -168,12 +168,14 @@ struct scsi_tape {unsigned char compression_changed;unsigned char drv_buffer;unsigned char density; +unsigned char changed_density;unsigned char door_locked;unsigned char autorew_dev;/* auto-rewind device */ unsigned char rew_at_close;/* rewind necessary at close */ unsigned char inited;unsigned char cleaning_req;/* cleaning requested? */ int block_size; +int changed_blksize;int min_block;int max_block;int recover_count;/* From tape opening */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 219/270 HID: usbkbd: Fix the bit shift number for LED_KANA
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: junan <[email protected]>
[ Upstream commit d73a4bfa2881a6859b384b75a414c33d4898b055 ]
Since "LED_KANA" was defined as "0x04", the shift number should be "4".
--- drivers/hid/usbhid/usbkbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/usbhid/usbkbd.c +1 -1
@@ -160,7 +160,7 @@ static int usb_kbd_event(struct input_dev *dev, unsigned int type,return -1 ;spin_lock_irqsave (&kbd->leds_lock, flags); - kbd->newleds = (!!test_bit (LED_KANA , dev->led) <<3 ) | (!!test_bit (LED_COMPOSE , dev->led) <<3 ) | + kbd->newleds = (!!test_bit (LED_KANA , dev->led) <<4 ) | (!!test_bit (LED_COMPOSE , dev->led) <<3 ) | (!!test_bit (LED_SCROLLL , dev->led) <<2 ) | (!!test_bit (LED_CAPSL , dev->led) <<1 ) | (!!test_bit (LED_NUML , dev->led));
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 220/270 drm/ast: Find VBIOS mode from regular display size
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
[ Upstream commit c81202906b5cd56db403e95db3d29c9dfc8c74c1 ]
The ast driver looks up supplied display modes from an internal list of display modes supported by the VBIOS.
Do not use the crtc_-prefixed display values from struct drm_display_mode for looking up the VBIOS mode. The fields contain raw values that the driver programs to hardware. They are affected by display settings like double-scan or interlace.
Instead use the regular vdisplay and hdisplay fields for lookup. As the programmed values can now differ from the values used for lookup, set struct drm_display_mode.crtc_vdisplay and .crtc_hdisplay from the VBIOS mode.
--- drivers/gpu/drm/ast/ast_mode.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/gpu/drm/ast/ast_mode.c +6 -4
@@ -104,7 +104,7 @@ static bool ast_get_vbios_mode_info(const struct drm_format_info *format,return false; } -switch (mode->crtc_hdisplay) { +switch (mode->hdisplay) {case 640 : vbios_mode->enh_table = &res_640x480[refresh_rate_index];break ;
@@ -115,7 +115,7 @@ static bool ast_get_vbios_mode_info(const struct drm_format_info *format, vbios_mode->enh_table = &res_1024x768[refresh_rate_index];break ;case 1280 : -if (mode->crtc_vdisplay ==800 ) +if (mode->vdisplay ==800 ) vbios_mode->enh_table = &res_1280x800[refresh_rate_index];else vbios_mode->enh_table = &res_1280x1024[refresh_rate_index];
@@ -127,7 +127,7 @@ static bool ast_get_vbios_mode_info(const struct drm_format_info *format, vbios_mode->enh_table = &res_1440x900[refresh_rate_index];break ;case 1600 : -if (mode->crtc_vdisplay ==900 ) +if (mode->vdisplay ==900 ) vbios_mode->enh_table = &res_1600x900[refresh_rate_index];else vbios_mode->enh_table = &res_1600x1200[refresh_rate_index];
@@ -136,7 +136,7 @@ static bool ast_get_vbios_mode_info(const struct drm_format_info *format, vbios_mode->enh_table = &res_1680x1050[refresh_rate_index];break ;case 1920 : -if (mode->crtc_vdisplay ==1080 ) +if (mode->vdisplay ==1080 ) vbios_mode->enh_table = &res_1920x1080[refresh_rate_index];else vbios_mode->enh_table = &res_1920x1200[refresh_rate_index];
@@ -180,6 +180,7 @@ static bool ast_get_vbios_mode_info(const struct drm_format_info *format, hborder = (vbios_mode->enh_table->flags & HBorder) ?8 :0 ; vborder = (vbios_mode->enh_table->flags & VBorder) ?8 :0 ; + adjusted_mode->crtc_hdisplay = vbios_mode->enh_table->hde; adjusted_mode->crtc_htotal = vbios_mode->enh_table->ht; adjusted_mode->crtc_hblank_start = vbios_mode->enh_table->hde + hborder; adjusted_mode->crtc_hblank_end = vbios_mode->enh_table->ht - hborder;
@@ -189,6 +190,7 @@ static bool ast_get_vbios_mode_info(const struct drm_format_info *format, vbios_mode->enh_table->hfp + vbios_mode->enh_table->hsync); + adjusted_mode->crtc_vdisplay = vbios_mode->enh_table->vde; adjusted_mode->crtc_vtotal = vbios_mode->enh_table->vt; adjusted_mode->crtc_vblank_start = vbios_mode->enh_table->vde + vborder; adjusted_mode->crtc_vblank_end = vbios_mode->enh_table->vt - vborder;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 221/270 bpftool: Fix readlink usage in get_fd_type
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viktor Malik <[email protected]>
[ Upstream commit 0053f7d39d491b6138d7c526876d13885cbb65f1 ]
The readlink(path, buf, sizeof(buf)) call reads at most sizeof(buf) bytes and *does not* append null-terminator to buf. With respect to that, fix two pieces in get_fd_type:
1. Change the truncation check to contain sizeof(buf) rather than sizeof(path).
2. Append null-terminator to buf.
Reported by Coverity.
--- tools/bpf/bpftool/common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
tools/bpf/bpftool/common.c +2 -1
@@ -311,10 +311,11 @@ int get_fd_type(int fd)p_err ("can't read link type: %s" ,strerror (errno));return -1 ; } -if (n ==sizeof (path)) { +if (n ==sizeof (buf)) {p_err ("can't read link type: path too long!" );return -1 ; } + buf[n] ='\0' ;if (strstr (buf,"bpf-map" ))return BPF_OBJ_MAP ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 222/270 perf/amd/ibs: Fix perf_ibs_op.cnt_mask for CurCnt
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ravi Bangoria <[email protected]>
[ Upstream commit 46dcf85566170d4528b842bf83ffc350d71771fa ]
IBS Op uses two counters: MaxCnt and CurCnt. MaxCnt is programmed with the desired sample period. IBS hw generates sample when CurCnt reaches to MaxCnt. The size of these counter used to be 20 bits but later they were extended to 27 bits. The 7 bit extension is indicated by CPUID Fn8000_001B_EAX[6 / OpCntExt].
perf_ibs->cnt_mask variable contains bit masks for MaxCnt and CurCnt. But IBS driver does not set upper 7 bits of CurCnt in cnt_mask even when OpCntExt CPUID bit is set. Fix this.
IBS driver uses cnt_mask[CurCnt] bits only while disabling an event. Fortunately, CurCnt bits are not read from MSR while re-enabling the event, instead MaxCnt is programmed with desired period and CurCnt is set to 0. Hence, we did not see any issues so far.
--- arch/x86/events/amd/ibs.c | 3 ++- arch/x86/include/asm/perf_event.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)
arch/x86/events/amd/ibs.c +2 -1
@@ -808,7 +808,8 @@ static __init int perf_event_ibs_init(void)if (ibs_caps &IBS_CAPS_OPCNTEXT ) { perf_ibs_op.max_period |=IBS_OP_MAX_CNT_EXT_MASK ; perf_ibs_op.config_mask |=IBS_OP_MAX_CNT_EXT_MASK ; - perf_ibs_op.cnt_mask |=IBS_OP_MAX_CNT_EXT_MASK ; + perf_ibs_op.cnt_mask |= (IBS_OP_MAX_CNT_EXT_MASK | +IBS_OP_CUR_CNT_EXT_MASK ); } ret =perf_ibs_pmu_init (&perf_ibs_op,"ibs_op" );
arch/x86/include/asm/perf_event.h +1 -0
@@ -402,6 +402,7 @@ struct pebs_xmm {*/ #define IBS_OP_CUR_CNT (0xFFF80ULL<<32)#define IBS_OP_CUR_CNT_RAND (0x0007FULL<<32) +#define IBS_OP_CUR_CNT_EXT_MASK (0x7FULL<<52)#define IBS_OP_CNT_CTL (1ULL<<19)#define IBS_OP_VAL (1ULL<<18)#define IBS_OP_ENABLE (1ULL<<17)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 223/270 wifi: rtw88: Dont use static local variable in rtw8822b_set_tx_power_index_by_rate
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
[ Upstream commit 00451eb3bec763f708e7e58326468c1e575e5a66 ]
Some users want to plug two identical USB devices at the same time. This static variable could theoretically cause them to use incorrect TX power values.
Move the variable to the caller and pass a pointer to it to rtw8822b_set_tx_power_index_by_rate().
--- drivers/net/wireless/realtek/rtw88/rtw8822b.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/net/wireless/realtek/rtw88/rtw8822b.c +8 -6
@@ -954,11 +954,11 @@ static void rtw8822b_query_rx_desc(struct rtw_dev *rtwdev, u8 *rx_desc, }static void -rtw8822b_set_tx_power_index_by_rate (struct rtw_dev *rtwdev,u8 path,u8 rs) +rtw8822b_set_tx_power_index_by_rate (struct rtw_dev *rtwdev,u8 path, +u8 rs,u32 *phy_pwr_idx) {struct rtw_hal *hal = &rtwdev->hal;static const u32 offset_txagc[2 ] = {0x1d00 ,0x1d80 }; -static u32 phy_pwr_idx;u8 rate, rate_idx, pwr_index, shift;int j;
@@ -966,12 +966,12 @@ rtw8822b_set_tx_power_index_by_rate(struct rtw_dev *rtwdev, u8 path, u8 rs) rate = rtw_rate_section[rs][j]; pwr_index = hal->tx_pwr_tbl[path][rate]; shift = rate &0x3 ; - phy_pwr_idx |= ((u32 )pwr_index << (shift *8 )); + *phy_pwr_idx |= ((u32 )pwr_index << (shift *8 ));if (shift ==0x3 ) { rate_idx = rate &0xfc ;rtw_write32 (rtwdev, offset_txagc[path] + rate_idx, - phy_pwr_idx); - phy_pwr_idx =0 ; + *phy_pwr_idx); + *phy_pwr_idx =0 ; } } }
@@ -979,11 +979,13 @@ rtw8822b_set_tx_power_index_by_rate(struct rtw_dev *rtwdev, u8 path, u8 rs)static void rtw8822b_set_tx_power_index (struct rtw_dev *rtwdev) {struct rtw_hal *hal = &rtwdev->hal; +u32 phy_pwr_idx =0 ;int rs, path;for (path =0 ; path < hal->rf_path_num; path++) {for (rs =0 ; rs <RTW_RATE_SECTION_MAX ; rs++) -rtw8822b_set_tx_power_index_by_rate (rtwdev, path, rs); +rtw8822b_set_tx_power_index_by_rate (rtwdev, path, rs, + &phy_pwr_idx); } }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 224/270 spi: zynqmp-gqspi: Always acknowledge interrupts
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Anderson <[email protected]>
[ Upstream commit 89785306453ce6d949e783f6936821a0b7649ee2 ]
RXEMPTY can cause an IRQ, even though we may not do anything about it (such as if we are waiting for more received data). We must still handle these IRQs because we can tell they were caused by the device.
--- drivers/spi/spi-zynqmp-gqspi.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-)
drivers/spi/spi-zynqmp-gqspi.c +8 -12
@@ -689,7 +689,6 @@ static void zynqmp_process_dma_irq(struct zynqmp_qspi *xqspi)static irqreturn_t zynqmp_qspi_irq (int irq,void *dev_id) {struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_id; -irqreturn_t ret =IRQ_NONE ;u32 status, mask, dma_status =0 ; status =zynqmp_gqspi_read (xqspi,GQSPI_ISR_OFST );
@@ -704,27 +703,24 @@ static irqreturn_t zynqmp_qspi_irq(int irq, void *dev_id) dma_status); } -if (mask &GQSPI_ISR_TXNOT_FULL_MASK ) { +if (!mask && !dma_status) +return IRQ_NONE ; + +if (mask &GQSPI_ISR_TXNOT_FULL_MASK )zynqmp_qspi_filltxfifo (xqspi,GQSPI_TX_FIFO_FILL ); - ret =IRQ_HANDLED ; - } -if (dma_status &GQSPI_QSPIDMA_DST_I_STS_DONE_MASK ) { +if (dma_status &GQSPI_QSPIDMA_DST_I_STS_DONE_MASK )zynqmp_process_dma_irq (xqspi); - ret =IRQ_HANDLED ; - }else if (!(mask &GQSPI_IER_RXEMPTY_MASK ) && - (mask &GQSPI_IER_GENFIFOEMPTY_MASK )) { +else if (!(mask &GQSPI_IER_RXEMPTY_MASK ) && + (mask &GQSPI_IER_GENFIFOEMPTY_MASK ))zynqmp_qspi_readrxfifo (xqspi,GQSPI_RX_FIFO_FILL ); - ret =IRQ_HANDLED ; - }if (xqspi->bytes_to_receive ==0 && xqspi->bytes_to_transfer ==0 && ((status &GQSPI_IRQ_MASK ) ==GQSPI_IRQ_MASK )) {zynqmp_gqspi_write (xqspi,GQSPI_IDR_OFST ,GQSPI_ISR_IDR_MASK );complete (&xqspi->data_completion); - ret =IRQ_HANDLED ; } -return ret; +return IRQ_HANDLED ; }/**
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 225/270 regulator: ad5398: Add device tree support
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Isaac Scott <[email protected]>
[ Upstream commit 5a6a461079decea452fdcae955bccecf92e07e97 ]
Previously, the ad5398 driver used only platform_data, which is deprecated in favour of device tree. This caused the AD5398 to fail to probe as it could not load its init_data. If the AD5398 has a device tree node, pull the init_data from there using of_get_regulator_init_data.
--- drivers/regulator/ad5398.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/regulator/ad5398.c +9 -3
@@ -14,6 +14,7 @@#include <linux/platform_device.h> #include <linux/regulator/driver.h> #include <linux/regulator/machine.h> +#include <linux/regulator/of_regulator.h> #define AD5398_CURRENT_EN_MASK 0x8000
@@ -221,15 +222,20 @@ static int ad5398_probe(struct i2c_client *client,const struct ad5398_current_data_format *df = (struct ad5398_current_data_format *)id->driver_data; -if (!init_data) -return -EINVAL ; - chip =devm_kzalloc (&client->dev,sizeof (*chip),GFP_KERNEL );if (!chip)return -ENOMEM ; config.dev = &client->dev; +if (client->dev.of_node) + init_data =of_get_regulator_init_data (&client->dev, + client->dev.of_node, + &ad5398_reg); +if (!init_data) +return -EINVAL ; + config.init_data = init_data; + config.of_node = client->dev.of_node; config.driver_data = chip; chip->client = client;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 226/270 drm/atomic: clarify the rules around drm_atomic_state->allow_modeset
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simona Vetter <[email protected]>
[ Upstream commit c5e3306a424b52e38ad2c28c7f3399fcd03e383d ]
msm is automagically upgrading normal commits to full modesets, and that's a big no-no:
- for one this results in full on->off->on transitions on all these crtc, at least if you're using the usual helpers. Which seems to be the case, and is breaking uapi
- further even if the ctm change itself would not result in flicker, this can hide modesets for other reasons. Which again breaks the uapi
v2: I forgot the case of adding unrelated crtc state. Add that case and link to the existing kerneldoc explainers. This has come up in an irc discussion with Manasi and Ville about intel's bigjoiner mode. Also cc everyone involved in the msm irc discussion, more people joined after I sent out v1.
v3: Wording polish from Pekka and Thomas
--- include/drm/drm_atomic.h | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)
include/drm/drm_atomic.h +21 -2
@@ -332,8 +332,27 @@ struct drm_atomic_state {* * Allow full modeset. This is used by the ATOMIC IOCTL handler to * implement the DRM_MODE_ATOMIC_ALLOW_MODESET flag. Drivers should -* never consult this flag, instead looking at the output of -* drm_atomic_crtc_needs_modeset(). +* generally not consult this flag, but instead look at the output of +* drm_atomic_crtc_needs_modeset(). The detailed rules are: +* +* - Drivers must not consult @allow_modeset in the atomic commit path. +* Use drm_atomic_crtc_needs_modeset() instead. +* +* - Drivers must consult @allow_modeset before adding unrelated struct +* drm_crtc_state to this commit by calling +* drm_atomic_get_crtc_state(). See also the warning in the +* documentation for that function. +* +* - Drivers must never change this flag, it is under the exclusive +* control of userspace. +* +* - Drivers may consult @allow_modeset in the atomic check path, if +* they have the choice between an optimal hardware configuration +* which requires a modeset, and a less optimal configuration which +* can be committed without a modeset. An example would be suboptimal +* scanout FIFO allocation resulting in increased idle power +* consumption. This allows userspace to avoid flickering and delays +* for the normal composition loop at reasonable cost. */ bool allow_modeset : 1; bool legacy_cursor_update : 1;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 227/270 drm: Add valid clones check
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jessica Zhang <[email protected]>
[ Upstream commit 41b4b11da02157c7474caf41d56baae0e941d01a ]
Check that all encoders attached to a given CRTC are valid possible_clones of each other.
--- drivers/gpu/drm/drm_atomic_helper.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
drivers/gpu/drm/drm_atomic_helper.c +28 -0
@@ -557,6 +557,30 @@ mode_valid(struct drm_atomic_state *state)return 0 ; } +static int drm_atomic_check_valid_clones (struct drm_atomic_state *state, +struct drm_crtc *crtc) +{ +struct drm_encoder *drm_enc; +struct drm_crtc_state *crtc_state =drm_atomic_get_new_crtc_state (state, + crtc); + +drm_for_each_encoder_mask (drm_enc, crtc->dev, crtc_state->encoder_mask) { +if (!drm_enc->possible_clones) { +DRM_DEBUG ("enc%d possible_clones is 0\n" , drm_enc->base.id); +continue ; + } + +if ((crtc_state->encoder_mask & drm_enc->possible_clones) != + crtc_state->encoder_mask) { +DRM_DEBUG ("crtc%d failed valid clone check for mask 0x%x\n" , + crtc->base.id, crtc_state->encoder_mask); +return -EINVAL ; + } + } + +return 0 ; +} +/** * drm_atomic_helper_check_modeset - validate state object for modeset changes * @dev: DRM device
@@ -720,6 +744,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, ret =drm_atomic_add_affected_planes (state, crtc);if (ret !=0 )return ret; + + ret =drm_atomic_check_valid_clones (state, crtc); +if (ret !=0 ) +return ret; }/*
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 228/270 pinctrl: meson: define the pull up/down resistor value as 60 kOhm
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Blumenstingl <[email protected]>
[ Upstream commit e56088a13708757da68ad035269d69b93ac8c389 ]
The public datasheets of the following Amlogic SoCs describe a typical resistor value for the built-in pull up/down resistor:
- Meson8/8b/8m2: not documented
- GXBB (S905): 60 kOhm
- GXL (S905X): 60 kOhm
- GXM (S912): 60 kOhm
- G12B (S922X): 60 kOhm
- SM1 (S905D3): 60 kOhm
The public G12B and SM1 datasheets additionally state min and max values:
- min value: 50 kOhm for both, pull-up and pull-down
- max value for the pull-up: 70 kOhm
- max value for the pull-down: 130 kOhm
Use 60 kOhm in the pinctrl-meson driver as well so it's shown in the debugfs output. It may not be accurate for Meson8/8b/8m2 but in reality 60 kOhm is closer to the actual value than 1 Ohm.
--- drivers/pinctrl/meson/pinctrl-meson.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/meson/pinctrl-meson.c +1 -1
@@ -483,7 +483,7 @@ static int meson_pinconf_get(struct pinctrl_dev *pcdev, unsigned int pin,case PIN_CONFIG_BIAS_PULL_DOWN :case PIN_CONFIG_BIAS_PULL_UP :if (meson_pinconf_get_pull (pc, pin) == param) - arg =1 ; + arg =60000 ;else return -EINVAL ;break ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 229/270 ASoC: Intel: bytcr_rt5640: Add DMI quirk for Acer Aspire SW3-013
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 a549b927ea3f5e50b1394209b64e6e17e31d4db8 ]
Acer Aspire SW3-013 requires the very same quirk as other Acer Aspire model for making it working.
--- sound/soc/intel/boards/bytcr_rt5640.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
sound/soc/intel/boards/bytcr_rt5640.c +13 -0
@@ -431,6 +431,19 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = {BYT_RT5640_SSP0_AIF2 | BYT_RT5640_MCLK_EN), }, + { /* Acer Aspire SW3-013 */ + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Acer" ), + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire SW3-013"), + }, + .driver_data = (void *)(BYT_RT5640_DMIC1_MAP | +BYT_RT5640_JD_SRC_JD2_IN4N | +BYT_RT5640_OVCD_TH_2000UA | +BYT_RT5640_OVCD_SF_0P75 | +BYT_RT5640_DIFF_MIC | +BYT_RT5640_SSP0_AIF1 | + BYT_RT5640_MCLK_EN), + }, { .matches = { DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 230/270 ALSA: hda/realtek: Add quirk for HP Spectre x360 15-df1xxx
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 be0c40da888840fe91b45474cb70779e6cbaf7ca ]
HP Spectre x360 15-df1xxx with SSID 13c:863e requires similar workarounds that were applied to another HP Spectre x360 models; it has a mute LED only, no micmute LEDs, and needs the speaker GPIO seup.
--- sound/pci/hda/patch_realtek.c | 42 +++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)
sound/pci/hda/patch_realtek.c +42 -0
@@ -6702,6 +6702,41 @@ static void alc285_fixup_hp_spectre_x360_eb1(struct hda_codec *codec, } } +/* GPIO1 = amplifier on/off */ +static void alc285_fixup_hp_spectre_x360_df1 (struct hda_codec *codec, +const struct hda_fixup *fix, +int action) +{ +struct alc_spec *spec = codec->spec; +static const hda_nid_t conn[] = {0x02 }; +static const struct hda_pintbl pincfgs[] = { + {0x14 ,0x90170110 },/* front/high speakers */ + {0x17 ,0x90170130 },/* back/bass speakers */ + { } + }; + +// enable mute led +alc285_fixup_hp_mute_led_coefbit (codec, fix, action); + +switch (action) { +case HDA_FIXUP_ACT_PRE_PROBE : +/* needed for amp of back speakers */ + spec->gpio_mask |=0x01 ; + spec->gpio_dir |=0x01 ; +snd_hda_apply_pincfgs (codec, pincfgs); +/* share DAC to have unified volume control */ +snd_hda_override_conn_list (codec,0x14 ,ARRAY_SIZE (conn), conn); +snd_hda_override_conn_list (codec,0x17 ,ARRAY_SIZE (conn), conn); +break ; +case HDA_FIXUP_ACT_INIT : +/* need to toggle GPIO to enable the amp of back speakers */ +alc_update_gpio_data (codec,0x01 , true); +msleep (100 ); +alc_update_gpio_data (codec,0x01 , false); +break ; + } +} +static void alc285_fixup_hp_spectre_x360 (struct hda_codec *codec,const struct hda_fixup *fix,int action) {
@@ -6984,6 +7019,7 @@ enum {ALC280_FIXUP_HP_9480M ,ALC245_FIXUP_HP_X360_AMP ,ALC285_FIXUP_HP_SPECTRE_X360_EB1 , +ALC285_FIXUP_HP_SPECTRE_X360_DF1 ,ALC285_FIXUP_HP_ENVY_X360 ,ALC288_FIXUP_DELL_HEADSET_MODE , ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
@@ -8818,6 +8854,10 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc285_fixup_hp_spectre_x360_eb1 }, + [ALC285_FIXUP_HP_SPECTRE_X360_DF1] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc285_fixup_hp_spectre_x360_df1 + }, [ALC285_FIXUP_HP_ENVY_X360] = { .type = HDA_FIXUP_FUNC, .v.func = alc285_fixup_hp_envy_x360,
@@ -9223,6 +9263,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {SND_PCI_QUIRK (0x103c ,0x86c1 ,"HP Laptop 15-da3001TU" ,ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 ),SND_PCI_QUIRK (0x103c ,0x86c7 ,"HP Envy AiO 32" ,ALC274_FIXUP_HP_ENVY_GPIO ),SND_PCI_QUIRK (0x103c ,0x86e7 ,"HP Spectre x360 15-eb0xxx" ,ALC285_FIXUP_HP_SPECTRE_X360_EB1 ), +SND_PCI_QUIRK (0x103c ,0x863e ,"HP Spectre x360 15-df1xxx" ,ALC285_FIXUP_HP_SPECTRE_X360_DF1 ),SND_PCI_QUIRK (0x103c ,0x86e8 ,"HP Spectre x360 15-eb0xxx" ,ALC285_FIXUP_HP_SPECTRE_X360_EB1 ),SND_PCI_QUIRK (0x103c ,0x86f9 ,"HP Spectre x360 13-aw0xxx" ,ALC285_FIXUP_HP_SPECTRE_X360_MUTE_LED ), SND_PCI_QUIRK(0x103c, 0x8716, "HP Elite Dragonfly G2 Notebook PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
@@ -9750,6 +9791,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC295_FIXUP_HP_OMEN, .name = "alc295-hp-omen"}, {.id = ALC285_FIXUP_HP_SPECTRE_X360, .name = "alc285-hp-spectre-x360"}, {.id = ALC285_FIXUP_HP_SPECTRE_X360_EB1, .name = "alc285-hp-spectre-x360-eb1"}, + {.id = ALC285_FIXUP_HP_SPECTRE_X360_DF1, .name = "alc285-hp-spectre-x360-df1"}, {.id = ALC285_FIXUP_HP_ENVY_X360, .name = "alc285-hp-envy-x360"}, {.id = ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP, .name = "alc287-ideapad-bass-spk-amp"}, {.id = ALC623_FIXUP_LENOVO_THINKSTATION_P340, .name = "alc623-lenovo-thinkstation-p340"},
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 231/270 nvmet-tcp: dont restore null sk_state_change
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alistair Francis <[email protected]>
[ Upstream commit 46d22b47df2741996af277a2838b95f130436c13 ]
queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if the TCP connection isn't established when nvmet_tcp_set_queue_sock() is called then queue->state_change isn't set and sock->sk->sk_state_change isn't replaced.
As such we don't need to restore sock->sk->sk_state_change if queue->state_change is NULL.
This avoids NULL pointer dereferences such as this:
[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode [ 286.463796][ C0] #PF: error_code(0x0010) - not-present page [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary) [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Call Trace: [ 286.476102][ C0] <IRQ> [ 286.476719][ C0] tcp_fin+0x2bb/0x440 [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60 [ 286.478174][ C0] ? __build_skb_around+0x234/0x330 [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10 [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0 [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30 [ 286.482769][ C0] ? ktime_get+0x66/0x150 [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050 [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0 [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10 [ 286.486917][ C0] ? lock_release+0x217/0x2c0 [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0 [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0 [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10 [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10 [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack] [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370 [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420 [ 286.494268][ C0] ip_local_deliver+0x168/0x430 [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10 [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20 [ 286.496806][ C0] ? lock_release+0x217/0x2c0 [ 286.497414][ C0] ip_rcv+0x455/0x6e0 [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10 [ 286.498550][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.499137][ C0] ? __pfx_ip_rcv_finish+0x10/0x10 [ 286.499763][ C0] ? lock_release+0x217/0x2c0 [ 286.500327][ C0] ? dl_scaled_delta_exec+0xd1/0x2c0 [ 286.500922][ C0] ? __pfx_ip_rcv+0x10/0x10 [ 286.501480][ C0] __netif_receive_skb_one_core+0x166/0x1b0 [ 286.502173][ C0] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 286.502903][ C0] ? lock_acquire+0x2b2/0x310 [ 286.503487][ C0] ? process_backlog+0x372/0x1350 [ 286.504087][ C0] ? lock_release+0x217/0x2c0 [ 286.504642][ C0] process_backlog+0x3b9/0x1350 [ 286.505214][ C0] ? process_backlog+0x372/0x1350 [ 286.505779][ C0] __napi_poll.constprop.0+0xa6/0x490 [ 286.506363][ C0] net_rx_action+0x92e/0xe10 [ 286.506889][ C0] ? __pfx_net_rx_action+0x10/0x10 [ 286.507437][ C0] ? timerqueue_add+0x1f0/0x320 [ 286.507977][ C0] ? sched_clock_cpu+0x68/0x540 [ 286.508492][ C0] ? lock_acquire+0x2b2/0x310 [ 286.509043][ C0] ? kvm_sched_clock_read+0xd/0x20 [ 286.509607][ C0] ? handle_softirqs+0x1aa/0x7d0 [ 286.510187][ C0] handle_softirqs+0x1f2/0x7d0 [ 286.510754][ C0] ? __pfx_handle_softirqs+0x10/0x10 [ 286.511348][ C0] ? irqtime_account_irq+0x181/0x290 [ 286.511937][ C0] ? __dev_queue_xmit+0x85d/0x3450 [ 286.512510][ C0] do_softirq.part.0+0x89/0xc0 [ 286.513100][ C0] </IRQ> [ 286.513548][ C0] <TASK> [ 286.513953][ C0] __local_bh_enable_ip+0x112/0x140 [ 286.514522][ C0] ? __dev_queue_xmit+0x85d/0x3450 [ 286.515072][ C0] __dev_queue_xmit+0x872/0x3450 [ 286.515619][ C0] ? nft_do_chain+0xe16/0x15b0 [nf_tables] [ 286.516252][ C0] ? __pfx___dev_queue_xmit+0x10/0x10 [ 286.516817][ C0] ? selinux_ip_postroute+0x43c/0xc50 [ 286.517433][ C0] ? __pfx_selinux_ip_postroute+0x10/0x10 [ 286.518061][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.518606][ C0] ? ip_output+0x164/0x4a0 [ 286.519149][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.519671][ C0] ? ip_finish_output2+0x17d5/0x1fb0 [ 286.520258][ C0] ip_finish_output2+0xb4b/0x1fb0 [ 286.520787][ C0] ? __pfx_ip_finish_output2+0x10/0x10 [ 286.521355][ C0] ? __ip_finish_output+0x15d/0x750 [ 286.521890][ C0] ip_output+0x164/0x4a0 [ 286.522372][ C0] ? __pfx_ip_output+0x10/0x10 [ 286.522872][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.523402][ C0] ? _raw_spin_unlock_irqrestore+0x4c/0x60 [ 286.524031][ C0] ? __pfx_ip_finish_output+0x10/0x10 [ 286.524605][ C0] ? __ip_queue_xmit+0x999/0x2260 [ 286.525200][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.525744][ C0] ? ipv4_dst_check+0x16a/0x2b0 [ 286.526279][ C0] ? lock_release+0x217/0x2c0 [ 286.526793][ C0] __ip_queue_xmit+0x1883/0x2260 [ 286.527324][ C0] ? __skb_clone+0x54c/0x730 [ 286.527827][ C0] __tcp_transmit_skb+0x209b/0x37a0 [ 286.528374][ C0] ? __pfx___tcp_transmit_skb+0x10/0x10 [ 286.528952][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.529472][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.530152][ C0] ? trace_hardirqs_on+0x12/0x120 [ 286.530691][ C0] tcp_write_xmit+0xb81/0x88b0 [ 286.531224][ C0] ? mod_memcg_state+0x4d/0x60 [ 286.531736][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.532253][ C0] __tcp_push_pending_frames+0x90/0x320 [ 286.532826][ C0] tcp_send_fin+0x141/0xb50 [ 286.533352][ C0] ? __pfx_tcp_send_fin+0x10/0x10 [ 286.533908][ C0] ? __local_bh_enable_ip+0xab/0x140 [ 286.534495][ C0] inet_shutdown+0x243/0x320 [ 286.535077][ C0] nvme_tcp_alloc_queue+0xb3b/0x2590 [nvme_tcp] [ 286.535709][ C0] ? do_raw_spin_lock+0x129/0x260 [ 286.536314][ C0] ? __pfx_nvme_tcp_alloc_queue+0x10/0x10 [nvme_tcp] [ 286.536996][ C0] ? do_raw_spin_unlock+0x54/0x1e0 [ 286.537550][ C0] ? _raw_spin_unlock+0x29/0x50 [ 286.538127][ C0] ? do_raw_spin_lock+0x129/0x260 [ 286.538664][ C0] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 286.539249][ C0] ? nvme_tcp_alloc_admin_queue+0xd5/0x340 [nvme_tcp] [ 286.539892][ C0] ? __wake_up+0x40/0x60 [ 286.540392][ C0] nvme_tcp_alloc_admin_queue+0xd5/0x340 [nvme_tcp] [ 286.541047][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.541589][ C0] nvme_tcp_setup_ctrl+0x8b/0x7a0 [nvme_tcp] [ 286.542254][ C0] ? _raw_spin_unlock_irqrestore+0x4c/0x60 [ 286.542887][ C0] ? __pfx_nvme_tcp_setup_ctrl+0x10/0x10 [nvme_tcp] [ 286.543568][ C0] ? trace_hardirqs_on+0x12/0x120 [ 286.544166][ C0] ? _raw_spin_unlock_irqrestore+0x35/0x60 [ 286.544792][ C0] ? nvme_change_ctrl_state+0x196/0x2e0 [nvme_core] [ 286.545477][ C0] nvme_tcp_create_ctrl+0x839/0xb90 [nvme_tcp] [ 286.546126][ C0] nvmf_dev_write+0x3db/0x7e0 [nvme_fabrics] [ 286.546775][ C0] ? rw_verify_area+0x69/0x520 [ 286.547334][ C0] vfs_write+0x218/0xe90 [ 286.547854][ C0] ? do_syscall_64+0x9f/0x190 [ 286.548408][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.549037][ C0] ? syscall_exit_to_user_mode+0x93/0x280 [ 286.549659][ C0] ? __pfx_vfs_write+0x10/0x10 [ 286.550259][ C0] ? do_syscall_64+0x9f/0x190 [ 286.550840][ C0] ? syscall_exit_to_user_mode+0x8e/0x280 [ 286.551516][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.552180][ C0] ? syscall_exit_to_user_mode+0x93/0x280 [ 286.552834][ C0] ? ksys_read+0xf5/0x1c0 [ 286.553386][ C0] ? __pfx_ksys_read+0x10/0x10 [ 286.553964][ C0] ksys_write+0xf5/0x1c0 [ 286.554499][ C0] ? __pfx_ksys_write+0x10/0x10 [ 286.555072][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.555698][ C0] ? syscall_exit_to_user_mode+0x93/0x280 [ 286.556319][ C0] ? do_syscall_64+0x54/0x190 [ 286.556866][ C0] do_syscall_64+0x93/0x190 [ 286.557420][ C0] ? rcu_read_unlock+0x17/0x60 [ 286.557986][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.558526][ C0] ? lock_release+0x217/0x2c0 [ 286.559087][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.559659][ C0] ? count_memcg_events.constprop.0+0x4a/0x60 [ 286.560476][ C0] ? exc_page_fault+0x7a/0x110 [ 286.561064][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.561647][ C0] ? lock_release+0x217/0x2c0 [ 286.562257][ C0] ? do_user_addr_fault+0x171/0xa00 [ 286.562839][ C0] ? do_user_addr_fault+0x4a2/0xa00 [ 286.563453][ C0] ? irqentry_exit_to_user_mode+0x84/0x270 [ 286.564112][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.564677][ C0] ? irqentry_exit_to_user_mode+0x84/0x270 [ 286.565317][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.565922][ C0] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 286.566542][ C0] RIP: 0033:0x7fe3c05e6504 [ 286.567102][ C0] Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d c5 8b 10 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 [ 286.568931][ C0] RSP: 002b:00007fff76444f58 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ 286.569807][ C0] RAX: ffffffffffffffda RBX: 000000003b40d930 RCX: 00007fe3c05e6504 [ 286.570621][ C0] RDX: 00000000000000cf RSI: 000000003b40d930 RDI: 0000000000000003 [ 286.571443][ C0] RBP: 0000000000000003 R08: 00000000000000cf R09: 000000003b40d930 [ 286.572246][ C0] R10: 0000000000000000 R11: 0000000000000202 R12: 000000003b40cd60 [ 286.573069][ C0] R13: 00000000000000cf R14: 00007fe3c07417f8 R15: 00007fe3c073502e [ 286.573886][ C0] </TASK>
--- drivers/nvme/target/tcp.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/nvme/target/tcp.c +3 -0
@@ -1395,6 +1395,9 @@ static void nvmet_tcp_restore_socket_callbacks(struct nvmet_tcp_queue *queue) {struct socket *sock = queue->sock; +if (!queue->state_change) +return ; +write_lock_bh (&sock->sk->sk_callback_lock); sock->sk->sk_data_ready = queue->data_ready; sock->sk->sk_state_change = queue->state_change;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 232/270 btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Goldwyn Rodrigues <[email protected]>
[ Upstream commit bc7e0975093567f51be8e1bdf4aa5900a3cf0b1e ]
btrfs_prelim_ref() calls the old and new reference variables in the incorrect order. This causes a NULL pointer dereference because oldref is passed as NULL to trace_btrfs_prelim_ref_insert().
Note, trace_btrfs_prelim_ref_insert() is being called with newref as oldref (and oldref as NULL) on purpose in order to print out the values of newref.
To reproduce:
echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable
Perform some writeback operations.
Backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0
--- include/trace/events/btrfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/trace/events/btrfs.h +1 -1
@@ -1788,7 +1788,7 @@ DECLARE_EVENT_CLASS(btrfs__prelim_ref, TP_PROTO(const struct btrfs_fs_info *fs_info, const struct prelim_ref *oldref, const struct prelim_ref *newref, u64 tree_size), -TP_ARGS (fs_info, newref, oldref, tree_size), +TP_ARGS (fs_info, oldref, newref, tree_size),TP_STRUCT__entry_btrfs ( __field( u64, root_id )
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 233/270 xenbus: Allow PVH dom0 a non-local xenstore
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Andryuk <[email protected]>
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a xenstore stubdom, dom0 can be handled as a regular XS_HVM following the late init path.
Ideally we'd drop the use of xen_initial_domain() and just check for the event channel instead. However, ARM has a xen,enhanced no-xenstore mode, where the event channel and PFN would both be 0. Retain the xen_initial_domain() check, and use that for an additional check when the event channel is 0.
Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off chance that high bits are set for the 32bit event channel.
Message-ID: <[email protected]>
--- drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/xen/xenbus/xenbus_probe.c +8 -6
@@ -864,9 +864,15 @@ static int __init xenbus_init(void)if (xen_pv_domain ()) xen_store_domain_type =XS_PV ;if (xen_hvm_domain ()) + { xen_store_domain_type =XS_HVM ; -if (xen_hvm_domain () &&xen_initial_domain ()) - xen_store_domain_type =XS_LOCAL ; + err =hvm_get_parameter (HVM_PARAM_STORE_EVTCHN , &v); +if (err) + goto out_error; + xen_store_evtchn = (int )v; +if (!v &&xen_initial_domain ()) + xen_store_domain_type =XS_LOCAL ; + }if (xen_pv_domain () && !xen_start_info->store_evtchn) xen_store_domain_type =XS_LOCAL ;if (xen_pv_domain () && xen_start_info->store_evtchn)
@@ -885,10 +891,6 @@ static int __init xenbus_init(void) xen_store_interface =gfn_to_virt (xen_store_gfn);break ;case XS_HVM : - err =hvm_get_parameter (HVM_PARAM_STORE_EVTCHN , &v); -if (err) - goto out_error; - xen_store_evtchn = (int )v; err =hvm_get_parameter (HVM_PARAM_STORE_PFN , &v);if (err) goto out_error;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 234/270 __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
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 250cf3693060a5f803c5f1ddc082bb06b16112a9 ]
... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput().
Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.
--- fs/namespace.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
fs/namespace.c +1 -5
@@ -572,12 +572,8 @@ int __legitimize_mnt(struct vfsmount *bastard, unsigned seq)smp_mb ();// see mntput_no_expire() and do_umount() if (likely (!read_seqretry (&mount_lock, seq)))return 0 ; -if (bastard->mnt_flags &MNT_SYNC_UMOUNT ) { -mnt_add_count (mnt,-1 ); -return 1 ; - }lock_mount_hash (); -if (unlikely (bastard->mnt_flags &MNT_DOOMED )) { +if (unlikely (bastard->mnt_flags & (MNT_SYNC_UMOUNT |MNT_DOOMED ))) {mnt_add_count (mnt,-1 );unlock_mount_hash ();return 1 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 235/270 xfrm: Sanitize marks before insert
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Chaignon <[email protected]>
[ Upstream commit 0b91fda3a1f044141e1e615456ff62508c32b202 ]
Prior to this patch, the mark is sanitized (applying the state's mask to the state's value) only on inserts when checking if a conflicting XFRM state or policy exists.
We discovered in Cilium that this same sanitization does not occur in the hot-path __xfrm_state_lookup. In the hot-path, the sk_buff's mark is simply compared to the state's value:
if ((mark & x->mark.m) != x->mark.v)
continue;Therefore, users can define unsanitized marks (ex. 0xf42/0xf00) which will never match any packet.
This commit updates __xfrm_state_insert and xfrm_policy_insert to store the sanitized marks, thus removing this footgun.
This has the side effect of changing the ip output, as the returned mark will have the mask applied to it when printed.
--- net/xfrm/xfrm_policy.c | 3 +++ net/xfrm/xfrm_state.c | 3 +++ 2 files changed, 6 insertions(+)
net/xfrm/xfrm_policy.c +3 -0
@@ -1594,6 +1594,9 @@ int xfrm_policy_insert(int dir, struct xfrm_policy *policy, int excl)struct xfrm_policy *delpol;struct hlist_head *chain; +/* Sanitize mark before store */ + policy->mark.v &= policy->mark.m; +spin_lock_bh (&net->xfrm.xfrm_policy_lock); chain =policy_hash_bysel (net, &policy->selector, policy->family, dir);if (chain)
net/xfrm/xfrm_state.c +3 -0
@@ -1249,6 +1249,9 @@ static void __xfrm_state_insert(struct xfrm_state *x)list_add (&x->km.all, &net->xfrm.state_all); +/* Sanitize mark before store */ + x->mark.v &= x->mark.m; + h =xfrm_dst_hash (net, &x->id.daddr, &x->props.saddr, x->props.reqid, x->props.family);hlist_add_head_rcu (&x->bydst, net->xfrm.state_bydst + h);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 236/270 bridge: netfilter: Fix forwarding of fragmented packets
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 91b6dbced0ef1d680afdd69b14fc83d50ebafaf3 ]
When netfilter defrag hooks are loaded (due to the presence of conntrack rules, for example), fragmented packets entering the bridge will be defragged by the bridge's pre-routing hook (br_nf_pre_routing() -> ipv4_conntrack_defrag()).
Later on, in the bridge's post-routing hook, the defragged packet will be fragmented again. If the size of the largest fragment is larger than what the kernel has determined as the destination MTU (using ip_skb_dst_mtu()), the defragged packet will be dropped.
Before commit ac6627a28dbf ("net: ipv4: Consolidate ipv4_mtu and ip_dst_mtu_maybe_forward"), ip_skb_dst_mtu() would return dst_mtu() as the destination MTU. Assuming the dst entry attached to the packet is the bridge's fake rtable one, this would simply be the bridge's MTU (see fake_mtu()).
However, after above mentioned commit, ip_skb_dst_mtu() ends up returning the route's MTU stored in the dst entry's metrics. Ideally, in case the dst entry is the bridge's fake rtable one, this should be the bridge's MTU as the bridge takes care of updating this metric when its MTU changes (see br_change_mtu()).
Unfortunately, the last operation is a no-op given the metrics attached to the fake rtable entry are marked as read-only. Therefore, ip_skb_dst_mtu() ends up returning 1500 (the initial MTU value) and defragged packets are dropped during fragmentation when dealing with large fragments and high MTU (e.g., 9k).
Fix by moving the fake rtable entry's metrics to be per-bridge (in a similar fashion to the fake rtable entry itself) and marking them as writable, thereby allowing MTU changes to be reflected.
--- net/bridge/br_nf_core.c | 7 ++----- net/bridge/br_private.h | 1 + 2 files changed, 3 insertions(+), 5 deletions(-)
net/bridge/br_nf_core.c +2 -5
@@ -65,17 +65,14 @@ static struct dst_ops fake_dst_ops = {* ipt_REJECT needs it. Future netfilter modules might * require us to fill additional fields. */ -static const u32 br_dst_default_metrics[RTAX_MAX ] = { - [RTAX_MTU -1 ] =1500 , -}; -void br_netfilter_rtable_init (struct net_bridge *br) {struct rtable *rt = &br->fake_rtable;atomic_set (&rt->dst.__refcnt,1 ); rt->dst.dev = br->dev; -dst_init_metrics (&rt->dst, br_dst_default_metrics, true); +dst_init_metrics (&rt->dst, br->metrics, false); +dst_metric_set (&rt->dst,RTAX_MTU , br->dev->mtu); rt->dst.flags =DST_NOXFRM |DST_FAKE_RTABLE ; rt->dst.ops = &fake_dst_ops; }
net/bridge/br_private.h +1 -0
@@ -400,6 +400,7 @@ struct net_bridge {struct rtable fake_rtable; struct rt6_info fake_rt6_info; }; +u32 metrics[RTAX_MAX ];#endif u16 group_fwd_mask;u16 group_fwd_mask_required;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 237/270 net: dwmac-sun8i: Use parsed internal PHY address instead of 1
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Kocialkowski <[email protected]>
[ Upstream commit 47653e4243f2b0a26372e481ca098936b51ec3a8 ]
While the MDIO address of the internal PHY on Allwinner sun8i chips is generally 1, of_mdio_parse_addr is used to cleanly parse the address from the device-tree instead of hardcoding it.
A commit reworking the code ditched the parsed value and hardcoded the value 1 instead, which didn't really break anything but is more fragile and not future-proof.
Restore the initial behavior using the parsed address returned from the helper.
--- drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c +1 -1
@@ -936,7 +936,7 @@ static int sun8i_dwmac_set_syscon(struct device *dev,/* of_mdio_parse_addr returns a valid (0 ~ 31) PHY * address. No need to mask it again. */ - reg |=1 <<H3_EPHY_ADDR_SHIFT ; + reg |= ret <<H3_EPHY_ADDR_SHIFT ; }else {/* For SoCs without internal PHY the PHY selection bit should be * set to 0 (external PHY).
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 238/270 sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cong Wang <[email protected]>
[ Upstream commit 3f981138109f63232a5fb7165938d4c945cc1b9d ]
When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free.
This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.
--- net/sched/sch_hfsc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
net/sched/sch_hfsc.c +3 -3
@@ -1571,6 +1571,9 @@ hfsc_enqueue(struct sk_buff *skb, struct Qdisc *sch, struct sk_buff **to_free)return err; } + sch->qstats.backlog += len; + sch->q.qlen++; +if (first && !cl->cl_nactive) {if (cl->cl_flags &HFSC_RSC )init_ed (cl, len);
@@ -1586,9 +1589,6 @@ hfsc_enqueue(struct sk_buff *skb, struct Qdisc *sch, struct sk_buff **to_free) } - sch->qstats.backlog += len; - sch->q.qlen++; -return NET_XMIT_SUCCESS ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 239/270 net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Liang <[email protected]>
[ Upstream commit e279024617134c94fd3e37470156534d5f2b3472 ]
Syzbot reported a slab-use-after-free with the following call trace:
==================================================================
BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue.
I reproduce this issue by:
ip netns add ns1
ip link add veth1 type veth peer name veth2
ip link set veth1 netns ns1
ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1
The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited.
tipc_disc_timeout
tipc_bearer_xmit_skb
tipc_crypto_xmit
tipc_aead_encrypt
crypto_aead_encrypt
// encrypt()
simd_aead_encrypt
// crypto_simd_usable() is false
child = &ctx->cryptd_tfm->base; simd_aead_encrypt
crypto_aead_encrypt
// encrypt()
cryptd_aead_encrypt_enqueue
cryptd_aead_enqueue
cryptd_enqueue_request
// trigger cryptd_queue_worker
queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)Fix this by holding net reference count before encrypt.
--- net/tipc/crypto.c | 5 +++++ 1 file changed, 5 insertions(+)
net/tipc/crypto.c +5 -0
@@ -821,12 +821,16 @@ static int tipc_aead_encrypt(struct tipc_aead *aead, struct sk_buff *skb, goto exit; } +/* Get net to avoid freed tipc_crypto when delete namespace */ +get_net (aead->crypto->net); +/* Now, do encrypt */ rc =crypto_aead_encrypt (req);if (rc == -EINPROGRESS || rc == -EBUSY )return rc;tipc_bearer_put (b); +put_net (aead->crypto->net); exit:kfree (ctx);
@@ -864,6 +868,7 @@ static void tipc_aead_encrypt_done(struct crypto_async_request *base, int err)kfree (tx_ctx);tipc_bearer_put (b);tipc_aead_put (aead); +put_net (net); }/**
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 240/270 crypto: algif_hash - fix double free in hash_accept
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Pravdin <[email protected]>
commit b2df03ed4052e97126267e8c13ad4204ea6ba9b6 upstream.
If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error.
--- crypto/algif_hash.c | 4 ---- 1 file changed, 4 deletions(-)
crypto/algif_hash.c +0 -4
@@ -262,10 +262,6 @@ static int hash_accept(struct socket *soreturn err; err =crypto_ahash_import (&ctx2->req, state); -if (err) { -sock_orphan (sk2); -sock_put (sk2); - }return err; }
Greg Kroah-Hartman
maintainerPATCH 241/270 padata: do not leak refcount in reorder_work
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dominik Grzegorzek <[email protected]>
commit d6ebcde6d4ecf34f8495fb30516645db3aea8993 upstream.
A recent patch that addressed a UAF introduced a reference count leak:
the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented.
Fix this by checking the return value of queue_work() and decrementing the refcount when necessary.
Resolves:
Unreferenced object 0xffff9d9f421e3d80 (size 192):
comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes):
80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............
d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#.
backtrace (crc 838fb36):
__kmalloc_cache_noprof+0x284/0x320
padata_alloc_pd+0x20/0x1e0
padata_alloc_shell+0x3b/0xa0
0xffffffffc040a54d
cryptomgr_probe+0x43/0xc0
kthread+0xf6/0x1f0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30--- kernel/padata.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/padata.c +2 -1
@@ -363,7 +363,8 @@ static void padata_reorder(struct parall* To avoid UAF issue, add pd ref here, and put pd ref after reorder_work finish. */ padata_get_pd (pd); -queue_work (pinst->serial_wq, &pd->reorder_work); +if (!queue_work (pinst->serial_wq, &pd->reorder_work)) +padata_put_pd (pd); } }
Greg Kroah-Hartman
maintainerPATCH 242/270 can: bcm: add locking for bcm_op runtime updates
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Hartkopp <[email protected]>
commit c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7 upstream.
The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero.
Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.
--- net/can/bcm.c | 66 +++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 45 insertions(+), 21 deletions(-)
net/can/bcm.c +45 -21
@@ -58,6 +58,7 @@#include <linux/can/skb.h> #include <linux/can/bcm.h> #include <linux/slab.h> +#include <linux/spinlock.h> #include <net/sock.h> #include <net/net_namespace.h>
@@ -120,6 +121,7 @@ struct bcm_op {struct canfd_frame last_sframe;struct sock *sk;struct net_device *rx_reg_dev; +spinlock_t bcm_tx_lock;/* protect currframe/count in runtime updates */ };struct bcm_sock {
@@ -273,13 +275,18 @@ static void bcm_can_tx(struct bcm_op *op {struct sk_buff *skb;struct net_device *dev; -struct canfd_frame *cf = op->frames + op->cfsiz * op->currframe; +struct canfd_frame *cf;int err;/* no target device? => exit */ if (!op->ifindex)return ; +/* read currframe under lock protection */ +spin_lock_bh (&op->bcm_tx_lock); + cf = op->frames + op->cfsiz * op->currframe; +spin_unlock_bh (&op->bcm_tx_lock); + dev =dev_get_by_index (sock_net (op->sk), op->ifindex);if (!dev) {/* RFC: should this bcm_op remove itself here? */
@@ -300,6 +307,10 @@ static void bcm_can_tx(struct bcm_op *op skb->dev = dev;can_skb_set_owner (skb, op->sk); err =can_send (skb,1 ); + +/* update currframe and count under lock protection */ +spin_lock_bh (&op->bcm_tx_lock); +if (!err) op->frames_abs++;
@@ -308,6 +319,11 @@ static void bcm_can_tx(struct bcm_op *op/* reached last frame? */ if (op->currframe >= op->nframes) op->currframe =0 ; + +if (op->count >0 ) + op->count--; + +spin_unlock_bh (&op->bcm_tx_lock); out:dev_put (dev); }
@@ -404,7 +420,7 @@ static enum hrtimer_restart bcm_tx_timeostruct bcm_msg_head msg_head;if (op->kt_ival1 && (op->count >0 )) { - op->count--; +bcm_can_tx (op);if (!op->count && (op->flags &TX_COUNTEVT )) {/* create notification to user */
@@ -419,7 +435,6 @@ static enum hrtimer_restart bcm_tx_timeobcm_send_to_user (op, &msg_head,NULL ,0 ); } -bcm_can_tx (op); }else if (op->kt_ival2) {bcm_can_tx (op);
@@ -909,6 +924,27 @@ static int bcm_tx_setup(struct bcm_msg_h } op->flags = msg_head->flags; +/* only lock for unlikely count/nframes/currframe changes */ +if (op->nframes != msg_head->nframes || + op->flags &TX_RESET_MULTI_IDX || + op->flags &SETTIMER ) { + +spin_lock_bh (&op->bcm_tx_lock); + +if (op->nframes != msg_head->nframes || + op->flags &TX_RESET_MULTI_IDX ) { +/* potentially update changed nframes */ + op->nframes = msg_head->nframes; +/* restart multiple frame transmission */ + op->currframe =0 ; + } + +if (op->flags &SETTIMER ) + op->count = msg_head->count; + +spin_unlock_bh (&op->bcm_tx_lock); + } + }else {/* insert new BCM operation for the given can_id */
@@ -916,9 +952,14 @@ static int bcm_tx_setup(struct bcm_msg_hif (!op)return -ENOMEM ; +spin_lock_init (&op->bcm_tx_lock); op->can_id = msg_head->can_id; op->cfsiz =CFSIZ (msg_head->flags); op->flags = msg_head->flags; + op->nframes = msg_head->nframes; + +if (op->flags &SETTIMER ) + op->count = msg_head->count;/* create array for CAN frames and copy the data */ if (msg_head->nframes >1 ) {
@@ -977,22 +1018,8 @@ static int bcm_tx_setup(struct bcm_msg_h }/* if ((op = bcm_find_op(&bo->tx_ops, msg_head->can_id, ifindex))) */ -if (op->nframes != msg_head->nframes) { - op->nframes = msg_head->nframes; -/* start multiple frame transmission with index 0 */ - op->currframe =0 ; - } - -/* check flags */ - -if (op->flags &TX_RESET_MULTI_IDX ) { -/* start multiple frame transmission with index 0 */ - op->currframe =0 ; - } -if (op->flags &SETTIMER ) {/* set timer values */ - op->count = msg_head->count; op->ival1 = msg_head->ival1; op->ival2 = msg_head->ival2; op->kt_ival1 =bcm_timeval_to_ktime (msg_head->ival1);
@@ -1009,11 +1036,8 @@ static int bcm_tx_setup(struct bcm_msg_h op->flags |=TX_ANNOUNCE ; } -if (op->flags &TX_ANNOUNCE ) { +if (op->flags &TX_ANNOUNCE )bcm_can_tx (op); -if (op->count) - op->count--; - }if (op->flags &STARTTIMER )bcm_tx_start_timer (op);
Greg Kroah-Hartman
maintainerPATCH 243/270 can: bcm: add missing rcu read protection for procfs content
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Hartkopp <[email protected]>
commit dac5e6249159ac255dad9781793dbe5908ac9ddb upstream.
When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF).
As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.
--- net/can/bcm.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
net/can/bcm.c +9 -4
@@ -207,7 +207,9 @@ static int bcm_proc_show(struct seq_fileseq_printf (m," / bound %s" ,bcm_proc_getifname (net, ifname, bo->ifindex));seq_printf (m," <<<\n" ); -list_for_each_entry (op, &bo->rx_ops, list) { +rcu_read_lock (); + +list_for_each_entry_rcu (op, &bo->rx_ops, list) {unsigned long reduction;
@@ -263,6 +265,9 @@ static int bcm_proc_show(struct seq_file seq_printf(m, "# sent %ld\n", op->frames_abs); }seq_putc (m,'\n' ); + +rcu_read_unlock (); +return 0 ; }#endif /* CONFIG_PROC_FS */
@@ -811,7 +816,7 @@ static int bcm_delete_rx_op(struct list_REGMASK (op->can_id), bcm_rx_handler, op); -list_del (&op->list); +list_del_rcu (&op->list);bcm_remove_op (op);return 1 ;/* done */ }
@@ -831,7 +836,7 @@ static int bcm_delete_tx_op(struct list_list_for_each_entry_safe (op, n, ops, list) {if ((op->can_id == mh->can_id) && (op->ifindex == ifindex) && (op->flags &CAN_FD_FRAME ) == (mh->flags &CAN_FD_FRAME )) { -list_del (&op->list); +list_del_rcu (&op->list);bcm_remove_op (op);return 1 ;/* done */ }
@@ -1253,7 +1258,7 @@ static int bcm_rx_setup(struct bcm_msg_h bcm_rx_handler, op, "bcm", sk);if (err) {/* this bcm rx op is broken -> remove it */ -list_del (&op->list); +list_del_rcu (&op->list);bcm_remove_op (op);return err; }
Greg Kroah-Hartman
maintainerPATCH 244/270 ALSA: pcm: Fix race of buffer access at PCM OSS layer
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 93a81ca0657758b607c3f4ba889ae806be9beb73 upstream.
The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops.
For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.
--- include/sound/pcm.h | 2 ++ sound/core/oss/pcm_oss.c | 3 +-- sound/core/pcm_native.c | 11 +++++++++++ 3 files changed, 14 insertions(+), 2 deletions(-)
include/sound/pcm.h +2 -0
@@ -1334,6 +1334,8 @@ int snd_pcm_lib_mmap_iomem(struct snd_pc#define snd_pcm_lib_mmap_iomem NULL#endif +void snd_pcm_runtime_buffer_set_silence (struct snd_pcm_runtime *runtime); +/** * snd_pcm_limit_isa_dma_size - Get the max size fitting with ISA DMA transfer * @dma: DMA number
sound/core/oss/pcm_oss.c +1 -2
@@ -1078,8 +1078,7 @@ static int snd_pcm_oss_change_params_loc runtime->oss.params =0 ; runtime->oss.prepare =1 ; runtime->oss.buffer_used =0 ; -if (runtime->dma_area) -snd_pcm_format_set_silence (runtime->format, runtime->dma_area,bytes_to_samples (runtime, runtime->dma_bytes)); +snd_pcm_runtime_buffer_set_silence (runtime); runtime->oss.period_frames =snd_pcm_alsa_frames (substream, oss_period_size);
sound/core/pcm_native.c +11 -0
@@ -685,6 +685,17 @@ static void snd_pcm_buffer_access_unlockatomic_inc (&runtime->buffer_accessing); } +/* fill the PCM buffer with the current silence format; called from pcm_oss.c */ +void snd_pcm_runtime_buffer_set_silence (struct snd_pcm_runtime *runtime) +{ +snd_pcm_buffer_access_lock (runtime); +if (runtime->dma_area) +snd_pcm_format_set_silence (runtime->format, runtime->dma_area, +bytes_to_samples (runtime, runtime->dma_bytes)); +snd_pcm_buffer_access_unlock (runtime); +} +EXPORT_SYMBOL_GPL (snd_pcm_runtime_buffer_set_silence); +#if IS_ENABLED (CONFIG_SND_PCM_OSS )#define is_oss_stream (substream) ((substream)->oss.oss)#else
Greg Kroah-Hartman
maintainerPATCH 245/270 llc: fix data loss when reading from a socket in llc_ui_recvmsg()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilia Gavrilov <[email protected]>
commit 239af1970bcb039a1551d2c438d113df0010c149 upstream.
For SOCK_STREAM sockets, if user buffer size (len) is less than skb size (skb->len), the remaining data from skb will be lost after calling kfree_skb().
To fix this, move the statement for partial reading above skb deletion.
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org)
--- net/llc/af_llc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
net/llc/af_llc.c +4 -4
@@ -887,15 +887,15 @@ static int llc_ui_recvmsg(struct socketif (sk->sk_type !=SOCK_STREAM ) goto copy_uaddr; +/* Partial read */ +if (used + offset < skb_len) +continue ; +if (!(flags &MSG_PEEK )) {skb_unlink (skb, &sk->sk_receive_queue);kfree_skb (skb); *seq =0 ; } - -/* Partial read */ -if (used + offset < skb_len) -continue ; }while (len >0 ); out:
Greg Kroah-Hartman
maintainerPATCH 246/270 drm/edid: fixed the bug that hdr metadata was not reset
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: feijuan.li <[email protected]>
commit 6692dbc15e5ed40a3aa037aced65d7b8826c58cd upstream.
When DP connected to a device with HDR capability, the hdr structure was filled.Then connected to another sink device without hdr capability, but the hdr info still exist.
--- drivers/gpu/drm/drm_edid.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/drm_edid.c +1 -0
@@ -5097,6 +5097,7 @@ drm_reset_display_info(struct drm_connec info->has_hdmi_infoframe = false; info->rgb_quant_range_selectable = false;memset (&info->hdmi,0 ,sizeof (info->hdmi)); +memset (&connector->hdr_sink_metadata,0 ,sizeof (connector->hdr_sink_metadata)); info->non_desktop =0 ;memset (&info->monitor_range,0 ,sizeof (info->monitor_range));
Greg Kroah-Hartman
maintainerPATCH 247/270 memcg: always call cond_resched() after fn()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
commit 06717a7b6c86514dbd6ab322e8083ffaa4db5712 upstream.
I am seeing soft lockup on certain machine types when a cgroup OOMs. This is happening because killing the process in certain machine might be very slow, which causes the soft lockup and RCU stalls. This happens usually when the cgroup has MANY processes and memory.oom.group is set.
Example I am seeing in real production:
[462012.244552] Memory cgroup out of memory: Killed process 3370438 (crosvm) ....
....
[462037.318059] Memory cgroup out of memory: Killed process 4171372 (adb) ....
[462037.348314] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [stat_manager-ag:1618982]
....Quick look at why this is so slow, it seems to be related to serial flush for certain machine types. For all the crashes I saw, the target CPU was at console_flush_all().
In the case above, there are thousands of processes in the cgroup, and it is soft locking up before it reaches the 1024 limit in the code (which would call the cond_resched()). So, cond_resched() in 1024 blocks is not sufficient.
Remove the counter-based conditional rescheduling logic and call cond_resched() unconditionally after each task iteration, after fn() is called. This avoids the lockup independently of how slow fn() is.
--- mm/memcontrol.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
mm/memcontrol.c +2 -4
@@ -1312,7 +1312,6 @@ int mem_cgroup_scan_tasks(struct mem_cgr {struct mem_cgroup *iter;int ret =0 ; -int i =0 ;BUG_ON (memcg == root_mem_cgroup);
@@ -1322,10 +1321,9 @@ int mem_cgroup_scan_tasks(struct mem_cgrcss_task_iter_start (&iter->css,CSS_TASK_ITER_PROCS , &it);while (!ret && (task =css_task_iter_next (&it))) { -/* Avoid potential softlockup warning */ -if ((++i &1023 ) ==0 ) -cond_resched (); ret =fn (task, arg); +/* Avoid potential softlockup warning */ +cond_resched (); }css_task_iter_end (&it);if (ret) {
Greg Kroah-Hartman
maintainerPATCH 248/270 mm/page_alloc.c: avoid infinite retries caused by cpuset race
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tianyang Zhang <[email protected]>
commit e05741fb10c38d70bbd7ec12b23c197b6355d519 upstream.
__alloc_pages_slowpath has no change detection for ac->nodemask in the part of retry path, while cpuset can modify it in parallel. For some processes that set mempolicy as MPOL_BIND, this results ac->nodemask changes, and then the should_reclaim_retry will judge based on the latest nodemask and jump to retry, while the get_page_from_freelist only traverses the zonelist from ac->preferred_zoneref, which selected by a expired nodemask and may cause infinite retries in some cases
cpu 64:
__alloc_pages_slowpath {
/* ..... */
retry:
/* ac->nodemask = 0x1, ac->preferred->zone->nid = 1 */
if (alloc_flags & ALLOC_KSWAPD)
wake_all_kswapds(order, gfp_mask, ac);
/* cpu 1:
cpuset_write_resmask
update_nodemask
update_nodemasks_hier
update_tasks_nodemask
mpol_rebind_task
mpol_rebind_policy
mpol_rebind_nodemask
// mempolicy->nodes has been modified,
// which ac->nodemask point to
*/
/* ac->nodemask = 0x3, ac->preferred->zone->nid = 1 */
if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
did_some_progress > 0, &no_progress_loops))
goto retry;
}Simultaneously starting multiple cpuset01 from LTP can quickly reproduce this issue on a multi node server when the maximum memory pressure is reached and the swap is enabled
--- mm/page_alloc.c | 8 ++++++++ 1 file changed, 8 insertions(+)
mm/page_alloc.c +8 -0
@@ -4758,6 +4758,14 @@ restart: } retry: +/* +* Deal with possible cpuset update races or zonelist updates to avoid +* infinite retries. +*/ +if (check_retry_cpuset (cpuset_mems_cookie, ac) || +check_retry_zonelist (zonelist_iter_cookie)) + goto restart; +/* Ensure kswapd doesn't accidentally go to sleep as long as we loop */ if (alloc_flags &ALLOC_KSWAPD )wake_all_kswapds (order, gfp_mask, ac);
Greg Kroah-Hartman
maintainerPATCH 249/270 spi: spi-fsl-dspi: restrict register range for regmap access
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larisa Grigore <[email protected]>
[ Upstream commit 283ae0c65e9c592f4a1ba4f31917f5e766da7f31 ]
DSPI registers are NOT continuous, some registers are reserved and accessing them from userspace will trigger external abort, add regmap register access table to avoid below abort.
For example on S32G:
# cat /sys/kernel/debug/regmap/401d8000.spi/registers
Internal error: synchronous external abort: 96000210 1 PREEMPT SMP ... Call trace: regmap_mmio_read32le+0x24/0x48 regmap_mmio_read+0x48/0x70 _regmap_bus_reg_read+0x38/0x48 _regmap_read+0x68/0x1b0 regmap_read+0x50/0x78 regmap_read_debugfs+0x120/0x338
--- drivers/spi/spi-fsl-dspi.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
drivers/spi/spi-fsl-dspi.c +19 -1
@@ -1,7 +1,7 @@// SPDX-License-Identifier: GPL-2.0+ // // Copyright 2013 Freescale Semiconductor, Inc. -// Copyright 2020 NXP +// Copyright 2020-2025 NXP // // Freescale DSPI driver // This file contains a driver for the Freescale DSPI
@@ -1128,6 +1128,20 @@ static int dspi_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(dspi_pm, dspi_suspend, dspi_resume); +static const struct regmap_range dspi_yes_ranges[] = { +regmap_reg_range (SPI_MCR ,SPI_MCR ), +regmap_reg_range (SPI_TCR ,SPI_CTAR (3 )), +regmap_reg_range (SPI_SR ,SPI_TXFR3 ), +regmap_reg_range (SPI_RXFR0 ,SPI_RXFR3 ), +regmap_reg_range (SPI_CTARE (0 ),SPI_CTARE (3 )), +regmap_reg_range (SPI_SREX ,SPI_SREX ), +}; + +static const struct regmap_access_table dspi_access_table = { + .yes_ranges = dspi_yes_ranges, + .n_yes_ranges =ARRAY_SIZE (dspi_yes_ranges), +}; +static const struct regmap_range dspi_volatile_ranges[] = {regmap_reg_range (SPI_MCR ,SPI_TCR ),regmap_reg_range (SPI_SR ,SPI_SR ),
@@ -1145,6 +1159,8 @@ static const struct regmap_config dspi_regmap_config = { .reg_stride = 4, .max_register = 0x88, .volatile_table = &dspi_volatile_table, + .rd_table = &dspi_access_table, + .wr_table = &dspi_access_table, };static const struct regmap_range dspi_xspi_volatile_ranges[] = {
@@ -1166,6 +1182,8 @@ static const struct regmap_config dspi_xspi_regmap_config[] = { .reg_stride = 4, .max_register = 0x13c, .volatile_table = &dspi_xspi_volatile_table, + .rd_table = &dspi_access_table, + .wr_table = &dspi_access_table, }, { .name = "pushr",
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 250/270 spi: spi-fsl-dspi: Halt the module after a new message transfer
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bogdan-Gabriel Roman <[email protected]>
[ Upstream commit 8a30a6d35a11ff5ccdede7d6740765685385a917 ]
The XSPI mode implementation in this driver still uses the EOQ flag to signal the last word in a transmission and deassert the PCS signal. However, at speeds lower than ~200kHZ, the PCS signal seems to remain asserted even when SR[EOQF] = 1 indicates the end of a transmission. This is a problem for target devices which require the deassertation of the PCS signal between transfers.
Hence, this commit 'forces' the deassertation of the PCS by stopping the module through MCR[HALT] after completing a new transfer. According to the reference manual, the module stops or transitions from the Running state to the Stopped state after the current frame, when any one of the following conditions exist:
- The value of SR[EOQF] = 1.
- The chip is in Debug mode and the value of MCR[FRZ] = 1.
- The value of MCR[HALT] = 1.
This shouldn't be done if the last transfer in the message has cs_change set.
--- drivers/spi/spi-fsl-dspi.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/spi/spi-fsl-dspi.c +24 -0
@@ -61,6 +61,7 @@#define SPI_SR_TFIWF BIT(18)#define SPI_SR_RFDF BIT(17)#define SPI_SR_CMDFFF BIT(16) +#define SPI_SR_TXRXS BIT(30)#define SPI_SR_CLEAR (SPI_SR_TCFQF | \ SPI_SR_TFUF | SPI_SR_TFFF | \ SPI_SR_CMDTCF | SPI_SR_SPEF | \
@@ -907,9 +908,20 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,struct spi_device *spi = message->spi;struct spi_transfer *transfer;int status =0 ; +u32 val =0 ; +bool cs_change = false; message->actual_length =0 ; +/* Put DSPI in running mode if halted. */ +regmap_read (dspi->regmap,SPI_MCR , &val); +if (val &SPI_MCR_HALT ) { +regmap_update_bits (dspi->regmap,SPI_MCR ,SPI_MCR_HALT ,0 ); +while (regmap_read (dspi->regmap,SPI_SR , &val) >=0 && + !(val &SPI_SR_TXRXS )) + ; + } +list_for_each_entry (transfer, &message->transfers, transfer_list) { dspi->cur_transfer = transfer; dspi->cur_msg = message;
@@ -934,6 +946,7 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr, dspi->tx_cmd |=SPI_PUSHR_CMD_CONT ; } + cs_change = transfer->cs_change; dspi->tx = transfer->tx_buf; dspi->rx = transfer->rx_buf; dspi->len = transfer->len;
@@ -966,6 +979,15 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,spi_transfer_delay_exec (transfer); } +if (status || !cs_change) { +/* Put DSPI in stop mode */ +regmap_update_bits (dspi->regmap,SPI_MCR , +SPI_MCR_HALT ,SPI_MCR_HALT ); +while (regmap_read (dspi->regmap,SPI_SR , &val) >=0 && + val &SPI_SR_TXRXS ) + ; + } + message->status = status;spi_finalize_current_message (ctlr);
@@ -1206,6 +1228,8 @@ static int dspi_init(struct fsl_dspi *dspi)if (!spi_controller_is_slave (dspi->ctlr)) mcr |=SPI_MCR_MASTER ; + mcr |=SPI_MCR_HALT ; +regmap_write (dspi->regmap,SPI_MCR , mcr);regmap_write (dspi->regmap,SPI_SR ,SPI_SR_CLEAR );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 251/270 spi: spi-fsl-dspi: Reset SR flags before sending a new message
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larisa Grigore <[email protected]>
[ Upstream commit 7aba292eb15389073c7f3bd7847e3862dfdf604d ]
If, in a previous transfer, the controller sends more data than expected by the DSPI target, SR.RFDF (RX FIFO is not empty) will remain asserted. When flushing the FIFOs at the beginning of a new transfer (writing 1 into MCR.CLR_TXF and MCR.CLR_RXF), SR.RFDF should also be cleared. Otherwise, when running in target mode with DMA, if SR.RFDF remains asserted, the DMA callback will be fired before the controller sends any data.
Take this opportunity to reset all Status Register fields.
--- drivers/spi/spi-fsl-dspi.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/spi/spi-fsl-dspi.c +2 -0
@@ -956,6 +956,8 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,SPI_MCR_CLR_TXF |SPI_MCR_CLR_RXF , SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF); +regmap_write (dspi->regmap,SPI_SR ,SPI_SR_CLEAR ); +spi_take_timestamp_pre (dspi->ctlr, dspi->cur_transfer, dspi->progress, !dspi->irq);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 252/270 kbuild: Disable -Wdefault-const-init-unsafe
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 d0afcfeb9e3810ec89d1ffde1a0e36621bb75dca upstream.
A new on by default warning in clang [1] aims to flags instances where const variables without static or thread local storage or const members in aggregate types are not initialized because it can lead to an indeterminate value. This is quite noisy for the kernel due to instances originating from header files such as:
drivers/gpu/drm/i915/gt/intel_ring.h:62:2: error: default initialization of an object of type 'typeof (ring->size)' (aka 'const unsigned int') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe]
62 | typecheck(typeof(ring->size), next);
| ^
include/linux/typecheck.h:10:9: note: expanded from macro 'typecheck'
10 | ({ type __dummy; \
| ^ include/net/ip.h:478:14: error: default initialization of an object of type 'typeof (rt->dst.expires)' (aka 'const unsigned long') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe]
478 | if (mtu && time_before(jiffies, rt->dst.expires))
| ^
include/linux/jiffies.h:138:26: note: expanded from macro 'time_before'
138 | #define time_before(a,b) time_after(b,a)
| ^
include/linux/jiffies.h:128:3: note: expanded from macro 'time_after'
128 | (typecheck(unsigned long, a) && \
| ^
include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck'
11 | typeof(x) __dummy2; \
| ^ include/linux/list.h:409:27: warning: default initialization of an object of type 'union (unnamed union at include/linux/list.h:409:27)' with const member leaves the object uninitialized [-Wdefault-const-init-field-unsafe]
409 | struct list_head *next = smp_load_acquire(&head->next);
| ^
include/asm-generic/barrier.h:176:29: note: expanded from macro 'smp_load_acquire'
176 | #define smp_load_acquire(p) __smp_load_acquire(p)
| ^
arch/arm64/include/asm/barrier.h:164:59: note: expanded from macro '__smp_load_acquire'
164 | union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u; \
| ^ include/linux/list.h:409:27: note: member '__val' declared 'const' here
crypto/scatterwalk.c:66:22: error: default initialization of an object of type 'struct scatter_walk' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
66 | struct scatter_walk walk;
| ^
include/crypto/algapi.h:112:15: note: member 'addr' declared 'const' here
112 | void *const addr;
| ^ fs/hugetlbfs/inode.c:733:24: error: default initialization of an object of type 'struct vm_area_struct' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
733 | struct vm_area_struct pseudo_vma;
| ^
include/linux/mm_types.h:803:20: note: member 'vm_flags' declared 'const' here
803 | const vm_flags_t vm_flags;
| ^Silencing the instances from typecheck.h is difficult because '= {}' is not available in older but supported compilers and '= {0}' would cause warnings about a literal 0 being treated as NULL. While it might be possible to come up with a local hack to silence the warning for clang-21+, it may not be worth it since -Wuninitialized will still trigger if an uninitialized const variable is actually used.
In all audited cases of the "field" variant of the warning, the members are either not used in the particular call path, modified through other means such as memset() / memcpy() because the containing object is not const, or are within a union with other non-const members.
Since this warning does not appear to have a high signal to noise ratio, just disable it.
[nathan: Apply change to Makefile instead of scripts/Makefile.extrawarn
due to lack of e88ca24319e4 in older stable branches]
--- Makefile | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Makefile +12 -0
@@ -795,6 +795,18 @@ KBUILD_CFLAGS += -Wno-gnu # source of a reference will be _MergedGlobals and not on of the whitelisted names. # See modpost pattern 2 KBUILD_CFLAGS += -mno-global-merge + +# Clang may emit a warning when a const variable, such as the dummy variables +# in typecheck(), or const member of an aggregate type are not initialized, +# which can result in unexpected behavior. However, in many audited cases of +# the "field" variant of the warning, this is intentional because the field is +# never used within a particular call path, the field is within a union with +# other non-const members, or the containing object is not const so the field +# can be modified via memcpy() / memset(). While the variable warning also gets +# disabled with this same switch, there should not be too much coverage lost +# because -Wuninitialized will still flag when an uninitialized const variable +# is used. +KBUILD_CFLAGS += $(call cc-disable-warning, default-const-init-unsafe) else # Warn about unmarked fall-throughs in switch statement.
Greg Kroah-Hartman
maintainerPATCH 253/270 drm/i915/gvt: fix unterminated-string-initialization warning
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
commit 2e43ae7dd71cd9bb0d1bce1d3306bf77523feb81 upstream.
Initializing const char opregion_signature[16] = OPREGION_SIGNATURE (which is "IntelGraphicsMem") drops the NUL termination of the string. This is intentional, but the compiler doesn't know this.
Switch to initializing header->signature directly from the string litaral, with sizeof destination rather than source. We don't treat the signature as a string other than for initialization; it's really just a blob of binary data.
Add a static assert for good measure to cross-check the sizes.
[nathan: Move static_assert() to top of function to avoid instance of
-Wdeclaration-after-statement due to lack of b5ec6fd286df]
--- drivers/gpu/drm/i915/gvt/opregion.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/gvt/opregion.c +5 -3
@@ -222,7 +222,8 @@ int intel_vgpu_init_opregion(struct inteu8 *buf;struct opregion_header *header;struct vbt v; -const char opregion_signature[16 ] =OPREGION_SIGNATURE ; + +static_assert (sizeof (header->signature) ==sizeof (OPREGION_SIGNATURE ) -1 );gvt_dbg_core ("init vgpu%d opregion\n" , vgpu->id); vgpu_opregion(vgpu)->va = (void *)__get_free_pages(GFP_KERNEL |
@@ -236,8 +237,9 @@ int intel_vgpu_init_opregion(struct inte/* emulated opregion with VBT mailbox only */ buf = (u8 *)vgpu_opregion (vgpu)->va; header = (struct opregion_header *)buf; -memcpy (header->signature, opregion_signature, -sizeof (opregion_signature)); + +memcpy (header->signature,OPREGION_SIGNATURE ,sizeof (header->signature)); + header->size =0x8 ; header->opregion_ver =0x02000000 ; header->mboxes =MBOX_VBT ;
Greg Kroah-Hartman
maintainerPATCH 254/270 smb: client: Fix use-after-free in cifs_fill_dirent
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Zhaolong <[email protected]>
commit a7a8fe56e932a36f43e031b398aef92341bf5ea0 upstream.
There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning.
==================================================================
BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]
Read of size 4 at addr ffff8880099b819c by task a.out/342975
CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_report+0xce/0x640
kasan_report+0xb8/0xf0
cifs_fill_dirent+0xb03/0xb60 [cifs]
cifs_readdir+0x12cb/0x3190 [cifs]
iterate_dir+0x1a1/0x520
__x64_sys_getdents+0x134/0x220
do_syscall_64+0x4b/0x110
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f996f64b9f9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 0d f7 c3 0c 00 f7 d8 64 89 8
RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e
RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88
R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000
</TASK>
Allocated by task 408:
kasan_save_stack+0x20/0x40
kasan_save_track+0x14/0x30
__kasan_slab_alloc+0x6e/0x70
kmem_cache_alloc_noprof+0x117/0x3d0
mempool_alloc_noprof+0xf2/0x2c0
cifs_buf_get+0x36/0x80 [cifs]
allocate_buffers+0x1d2/0x330 [cifs]
cifs_demultiplex_thread+0x22b/0x2690 [cifs]
kthread+0x394/0x720
ret_from_fork+0x34/0x70
ret_from_fork_asm+0x1a/0x30
Freed by task 342979:
kasan_save_stack+0x20/0x40
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x37/0x50
kmem_cache_free+0x2b8/0x500
cifs_buf_release+0x3c/0x70 [cifs]
cifs_readdir+0x1c97/0x3190 [cifs]
iterate_dir+0x1a1/0x520
__x64_sys_getdents64+0x134/0x220
do_syscall_64+0x4b/0x110
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff8880099b8000
which belongs to the cache cifs_request of size 16588
The buggy address is located 412 bytes inside of
freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0x80000000000040(head|node=0|zone=1)
page_type: f5(slab)
raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000
head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001
head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000
head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================POC is available in the link [1].
The problem triggering process is as follows:
Process 1 Process 2
-----------------------------------------------------------------cifs_readdir
/* file->private_data == NULL */
initiate_cifs_search
cifsFile = kzalloc(sizeof(struct cifsFileInfo), GFP_KERNEL);
smb2_query_dir_first ->query_dir_first()
SMB2_query_directory
SMB2_query_directory_init
cifs_send_recv
smb2_parse_query_directory
srch_inf->ntwrk_buf_start = (char *)rsp;
srch_inf->srch_entries_start = (char *)rsp + ...
srch_inf->last_entry = (char *)rsp + ...
srch_inf->smallBuf = true;
find_cifs_entry
/* if (cfile->srch_inf.ntwrk_buf_start) */
cifs_small_buf_release(cfile->srch_inf // free
cifs_readdir ->iterate_shared()
/* file->private_data != NULL */
find_cifs_entry
/* in while (...) loop */
smb2_query_dir_next ->query_dir_next()
SMB2_query_directory
SMB2_query_directory_init
cifs_send_recv
compound_send_recv
smb_send_rqst
__smb_send_rqst
rc = -ERESTARTSYS;
/* if (fatal_signal_pending()) */
goto out;
return rc
/* if (cfile->srch_inf.last_entry) */
cifs_save_resume_key()
cifs_fill_dirent // UAF
/* if (rc) */
return -ENOENT;Fix this by ensuring the return code is checked before using pointers from the srch_inf.
--- fs/cifs/readdir.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/cifs/readdir.c +2 -2
@@ -778,11 +778,11 @@ find_cifs_entry(const unsigned int xid, rc = server->ops->query_dir_next (xid, tcon, &cfile->fid, search_flags, &cfile->srch_inf); +if (rc) +return -ENOENT ;/* FindFirst/Next set last_entry to NULL on malformed reply */ if (cfile->srch_inf.last_entry)cifs_save_resume_key (cfile->srch_inf.last_entry, cfile); -if (rc) -return -ENOENT ; }if (index_to_find < cfile->srch_inf.index_of_last_entry) {/* we found the buffer that contains the entry */
Greg Kroah-Hartman
maintainerPATCH 255/270 smb: client: Reset all search buffer pointers when releasing buffer
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Zhaolong <[email protected]>
commit e48f9d849bfdec276eebf782a84fd4dfbe1c14c0 upstream.
Multiple pointers in struct cifs_search_info (ntwrk_buf_start, srch_entries_start, and last_entry) point to the same allocated buffer. However, when freeing this buffer, only ntwrk_buf_start was set to NULL, while the other pointers remained pointing to freed memory.
This is defensive programming to prevent potential issues with stale pointers. While the active UAF vulnerability is fixed by the previous patch, this change ensures consistent pointer state and more robust error handling.
--- fs/cifs/readdir.c | 3 +++ 1 file changed, 3 insertions(+)
fs/cifs/readdir.c +3 -0
@@ -755,7 +755,10 @@ find_cifs_entry(const unsigned int xid,else cifs_buf_release (cfile->srch_inf. ntwrk_buf_start); +/* Reset all pointers to the network buffer to prevent stale references */ cfile->srch_inf.ntwrk_buf_start =NULL ; + cfile->srch_inf.srch_entries_start =NULL ; + cfile->srch_inf.last_entry =NULL ; } rc =initiate_cifs_search (xid, file, full_path);if (rc) {
Greg Kroah-Hartman
maintainerPATCH 256/270 net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pedro Tammela <[email protected]>
commit ac9fe7dd8e730a103ae4481147395cc73492d786 upstream.
Savino says:
"We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1]
can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.
The patch only checks the cl->cl_nactive field to determine whether it is the first insertion or not [2], but this field is only incremented by init_vf [3].
By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in hfsc_dequeue for the reasons we already explained in this report [5].
However, if TBF is added as root qdisc and it is configured with a very low rate,
it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF."
To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set.
[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547
[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572
[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677
[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574
[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u
--- net/sched/sch_hfsc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
net/sched/sch_hfsc.c +8 -1
@@ -176,6 +176,11 @@ struct hfsc_sched {#define HT_INFINITY 0xffffffffffffffffULL/* infinite time value */ +static bool cl_in_el_or_vttree (struct hfsc_class *cl) +{ +return ((cl->cl_flags &HFSC_FSC ) && cl->cl_nactive) || + ((cl->cl_flags &HFSC_RSC ) && !RB_EMPTY_NODE (&cl->el_node)); +}/* * eligible tree holds backlogged classes being sorted by their eligible times.
@@ -1038,6 +1043,8 @@ hfsc_change_class(struct Qdisc *sch, u32if (cl ==NULL )return -ENOBUFS ; +RB_CLEAR_NODE (&cl->el_node); + err =tcf_block_get (&cl->block, &cl->filter_list, sch, extack);if (err) {kfree (cl);
@@ -1574,7 +1581,7 @@ hfsc_enqueue(struct sk_buff *skb, struct sch->qstats.backlog += len; sch->q.qlen++; -if (first && !cl->cl_nactive) { +if (first && !cl_in_el_or_vttree (cl)) {if (cl->cl_flags &HFSC_RSC )init_ed (cl, len);if (cl->cl_flags &HFSC_FSC )
Greg Kroah-Hartman
maintainerPATCH 257/270 coredump: fix error handling for replace_fd()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit 95c5f43181fe9c1b5e5a4bd3281c857a5259991f upstream.
The replace_fd() helper returns the file descriptor number on success and a negative error code on failure. The current error handling in umh_pipe_setup() only works because the file descriptor that is replaced is zero but that's pretty volatile. Explicitly check for a negative error code.
--- fs/coredump.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
fs/coredump.c +7 -2
@@ -564,7 +564,9 @@ static int umh_pipe_setup(struct subproc {struct file *files[2 ];struct coredump_params *cp = (struct coredump_params *)info->data; -int err =create_pipe_files (files,0 ); +int err; + + err =create_pipe_files (files,0 );if (err)return err;
@@ -572,10 +574,13 @@ static int umh_pipe_setup(struct subproc err =replace_fd (0 , files[0 ],0 );fput (files[0 ]); +if (err <0 ) +return err; +/* and disallow core files too */ current->signal->rlim[RLIMIT_CORE ] = (struct rlimit ){1 ,1 }; -return err; +return 0 ; }void do_coredump (const kernel_siginfo_t *siginfo)
Greg Kroah-Hartman
maintainerPATCH 258/270 pid: add pidfd_prepare()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit 6ae930d9dbf2d093157be33428538c91966d8a9f upstream.
Add a new helper that allows to reserve a pidfd and allocates a new pidfd file that stashes the provided struct pid. This will allow us to remove places that either open code this function or that call pidfd_create() but then have to call close_fd() because there are still failure points after pidfd_create() has been called.
Message-Id: <[email protected]>
--- include/linux/pid.h | 1 kernel/fork.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 86 insertions(+)
include/linux/pid.h +1 -0
@@ -79,6 +79,7 @@ struct file;extern struct pid *pidfd_pid (const struct file *file);struct pid *pidfd_get_pid (unsigned int fd,unsigned int *flags);int pidfd_create (struct pid *pid,unsigned int flags); +int pidfd_prepare (struct pid *pid,unsigned int flags,struct file **ret);static inline struct pid *get_pid (struct pid *pid) {
kernel/fork.c +85 -0
91 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 259/270 fork: use pidfd_prepare()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit ca7707f5430ad6b1c9cb7cee0a7f67d69328bb2d upstream.
Stop open-coding get_unused_fd_flags() and anon_inode_getfile(). That's brittle just for keeping the flags between both calls in sync. Use the dedicated helper.
Message-Id: <[email protected]>
--- kernel/fork.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-)
kernel/fork.c +2 -11
@@ -2238,21 +2238,12 @@ static __latent_entropy struct task_stru* if the fd table isn't shared). */ if (clone_flags &CLONE_PIDFD ) { - retval =get_unused_fd_flags (O_RDWR |O_CLOEXEC ); +/* Note that no task has been attached to @pid yet. */ + retval =__pidfd_prepare (pid,O_RDWR |O_CLOEXEC , &pidfile);if (retval <0 ) goto bad_fork_free_pid; - pidfd = retval; - pidfile =anon_inode_getfile ("[pidfd]" , &pidfd_fops, pid, -O_RDWR |O_CLOEXEC ); -if (IS_ERR (pidfile)) { -put_unused_fd (pidfd); - retval =PTR_ERR (pidfile); - goto bad_fork_free_pid; - } -get_pid (pid);/* held by pidfile now */ - retval =put_user (pidfd, args->pidfd);if (retval) goto bad_fork_put_pidfd;
Greg Kroah-Hartman
maintainerPATCH 260/270 coredump: hand a pidfd to the usermode coredump helper
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit b5325b2a270fcaf7b2a9a0f23d422ca8a5a8bdea upstream.
Give userspace a way to instruct the kernel to install a pidfd into the usermode helper process. This makes coredump handling a lot more reliable for userspace. In parallel with this commit we already have systemd adding support for this in [1].
We create a pidfs file for the coredumping process when we process the corename pattern. When the usermode helper process is forked we then install the pidfs file as file descriptor three into the usermode helpers file descriptor table so it's available to the exec'd program.
Since usermode helpers are either children of the system_unbound_wq workqueue or kthreadd we know that the file descriptor table is empty and can thus always use three as the file descriptor number.
Note, that we'll install a pidfd for the thread-group leader even if a subthread is calling do_coredump(). We know that task linkage hasn't been removed due to delay_group_leader() and even if this @current isn't the actual thread-group leader we know that the thread-group leader cannot be reaped until @current has exited.
[brauner: This is a backport for the v5.10 series. Upstream has significantly changed and backporting all that infra is a non-starter. So simply backport the pidfd_prepare() helper and waste the file descriptor we allocated. Then we minimally massage the umh coredump setup code.]
--- fs/coredump.c | 78 +++++++++++++++++++++++++++++++++++++++++++----- include/linux/binfmts.h | 1 2 files changed, 72 insertions(+), 7 deletions(-)
fs/coredump.c +71 -7
@@ -42,6 +42,7 @@#include <linux/path.h> #include <linux/timekeeping.h> #include <linux/elf.h> +#include <uapi/linux/pidfd.h> #include <linux/uaccess.h> #include <asm/mmu_context.h>
@@ -56,6 +57,13 @@static bool dump_vma_snapshot (struct coredump_params *cprm);static void free_vma_snapshot (struct coredump_params *cprm); +/* +* File descriptor number for the pidfd for the thread-group leader of +* the coredumping task installed into the usermode helper's file +* descriptor table. +*/ +#define COREDUMP_PIDFD_NUMBER 3 +int core_uses_pid;unsigned int core_pipe_limit;char core_pattern[CORENAME_MAX_SIZE ] ="core" ;
@@ -327,6 +335,27 @@ static int format_corename(struct core_n err =cn_printf (cn,"%lu" ,rlimit (RLIMIT_CORE ));break ; +/* pidfd number */ +case 'F' : { +/* +* Installing a pidfd only makes sense if +* we actually spawn a usermode helper. +*/ +if (!ispipe) +break ; + +/* +* Note that we'll install a pidfd for the +* thread-group leader. We know that task +* linkage hasn't been removed yet and even if +* this @current isn't the actual thread-group +* leader we know that the thread-group leader +* cannot be reaped until @current has exited. +*/ + cprm->pid =task_tgid (current); + err =cn_printf (cn,"%d" ,COREDUMP_PIDFD_NUMBER ); +break ; + }default :break ; }
@@ -550,7 +579,7 @@ static void wait_for_dump_helpers(struct }/* -* umh_pipe_setup +* umh_coredump_setup * helper function to customize the process used * to collect the core in userspace. Specifically * it sets up a pipe and installs it as fd 0 (stdin)
@@ -560,27 +589,62 @@ static void wait_for_dump_helpers(struct* is a special value that we use to trap recursive * core dumps */ -static int umh_pipe_setup (struct subprocess_info *info,struct cred *new) +static int umh_coredump_setup (struct subprocess_info *info,struct cred *new) {struct file *files[2 ]; +struct file *pidfs_file =NULL ;struct coredump_params *cp = (struct coredump_params *)info->data;int err; +if (cp->pid) { +int fd; + + fd =pidfd_prepare (cp->pid,0 , &pidfs_file); +if (fd <0 ) +return fd; + +/* +* We don't care about the fd. We also cannot simply +* replace it below because dup2() will refuse to close +* this file descriptor if its in a larval state. So +* close it! +*/ +put_unused_fd (fd); + +/* +* Usermode helpers are childen of either +* system_unbound_wq or of kthreadd. So we know that +* we're starting off with a clean file descriptor +* table. So we should always be able to use +* COREDUMP_PIDFD_NUMBER as our file descriptor value. +*/ + err =replace_fd (COREDUMP_PIDFD_NUMBER , pidfs_file,0 ); +if (err <0 ) + goto out_fail; + + pidfs_file =NULL ; + } + err =create_pipe_files (files,0 );if (err) -return err; + goto out_fail; cp->file = files[1 ]; err =replace_fd (0 , files[0 ],0 );fput (files[0 ]);if (err <0 ) -return err; + goto out_fail;/* and disallow core files too */ current->signal->rlim[RLIMIT_CORE ] = (struct rlimit ){1 ,1 }; -return 0 ; + err =0 ; + +out_fail: +if (pidfs_file) +fput (pidfs_file); +return err; }void do_coredump (const kernel_siginfo_t *siginfo)
@@ -656,7 +720,7 @@ void do_coredump(const kernel_siginfo_t }if (cprm.limit ==1 ) { -/* See umh_pipe_setup() which sets RLIMIT_CORE = 1. +/* See umh_coredump_setup() which sets RLIMIT_CORE = 1. * * Normally core limits are irrelevant to pipes, since * we're not writing to the file system, but we use
@@ -701,7 +765,7 @@ void do_coredump(const kernel_siginfo_t retval = -ENOMEM ; sub_info =call_usermodehelper_setup (helper_argv[0 ], helper_argv,NULL ,GFP_KERNEL , - umh_pipe_setup,NULL , &cprm); + umh_coredump_setup,NULL , &cprm);if (sub_info) retval =call_usermodehelper_exec (sub_info,UMH_WAIT_EXEC );
include/linux/binfmts.h +1 -0
@@ -89,6 +89,7 @@ struct coredump_params {int vma_count;size_t vma_data_size;struct core_vma_metadata *vma_meta; +struct pid *pid; };/*
Greg Kroah-Hartman
maintainerPATCH 261/270 HID: quirks: Add ADATA XPG alpha wireless mouse support
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Milton Barrera <[email protected]>
[ Upstream commit fa9fdeea1b7d6440c22efa6d59a769eae8bc89f1 ]
This patch adds HID_QUIRK_ALWAYS_POLL for the ADATA XPG wireless gaming mouse (USB ID 125f:7505) and its USB dongle (USB ID 125f:7506). Without this quirk, the device does not generate input events properly.
--- drivers/hid/hid-ids.h | 4 ++++ drivers/hid/hid-quirks.c | 2 ++ 2 files changed, 6 insertions(+)
drivers/hid/hid-ids.h +4 -0
@@ -41,6 +41,10 @@#define USB_VENDOR_ID_ACTIONSTAR 0x2101#define USB_DEVICE_ID_ACTIONSTAR_1011 0x1011 +#define USB_VENDOR_ID_ADATA_XPG 0x125f +#define USB_VENDOR_ID_ADATA_XPG_WL_GAMING_MOUSE 0x7505 +#define USB_VENDOR_ID_ADATA_XPG_WL_GAMING_MOUSE_DONGLE 0x7506 +#define USB_VENDOR_ID_ADS_TECH 0x06e1#define USB_DEVICE_ID_ADS_TECH_RADIO_SI470X 0xa155
drivers/hid/hid-quirks.c +2 -0
@@ -27,6 +27,8 @@static const struct hid_device_id hid_quirks[] = { {HID_USB_DEVICE (USB_VENDOR_ID_AASHIMA ,USB_DEVICE_ID_AASHIMA_GAMEPAD ),HID_QUIRK_BADPAD }, {HID_USB_DEVICE (USB_VENDOR_ID_AASHIMA ,USB_DEVICE_ID_AASHIMA_PREDATOR ),HID_QUIRK_BADPAD }, + {HID_USB_DEVICE (USB_VENDOR_ID_ADATA_XPG ,USB_VENDOR_ID_ADATA_XPG_WL_GAMING_MOUSE ),HID_QUIRK_ALWAYS_POLL }, + {HID_USB_DEVICE (USB_VENDOR_ID_ADATA_XPG ,USB_VENDOR_ID_ADATA_XPG_WL_GAMING_MOUSE_DONGLE ),HID_QUIRK_ALWAYS_POLL }, {HID_USB_DEVICE (USB_VENDOR_ID_AFATECH ,USB_DEVICE_ID_AFATECH_AF9016 ),HID_QUIRK_FULLSPEED_INTERVAL }, {HID_USB_DEVICE (USB_VENDOR_ID_AIREN ,USB_DEVICE_ID_AIREN_SLIMPLUS ),HID_QUIRK_NOGET }, {HID_USB_DEVICE (USB_VENDOR_ID_AKAI_09E8 ,USB_DEVICE_ID_AKAI_09E8_MIDIMIX ),HID_QUIRK_NO_INIT_REPORTS },
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 262/270 nfs: dont share pNFS DS connections between net namespaces
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
[ Upstream commit 6b9785dc8b13d9fb75ceec8cf4ea7ec3f3b1edbc ]
Currently, different NFS clients can share the same DS connections, even when they are in different net namespaces. If a containerized client creates a DS connection, another container can find and use it. When the first client exits, the connection will close which can lead to stalls in other clients.
Add a net namespace pointer to struct nfs4_pnfs_ds, and compare those value to the caller's netns in _data_server_lookup_locked() when searching for a nfs4_pnfs_ds to match.
--- fs/nfs/filelayout/filelayoutdev.c | 6 +++--- fs/nfs/flexfilelayout/flexfilelayoutdev.c | 6 +++--- fs/nfs/pnfs.h | 4 +++- fs/nfs/pnfs_nfs.c | 9 +++++---- 4 files changed, 14 insertions(+), 11 deletions(-)
fs/nfs/filelayout/filelayoutdev.c +3 -3
@@ -75,6 +75,7 @@ nfs4_fl_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev,struct page *scratch;struct list_head dsaddrs;struct nfs4_pnfs_ds_addr *da; +struct net *net = server->nfs_client->cl_net;/* set up xdr stream */ scratch =alloc_page (gfp_flags);
@@ -160,8 +161,7 @@ nfs4_fl_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev, mp_count =be32_to_cpup (p);/* multipath count */ for (j =0 ; j < mp_count; j++) { - da =nfs4_decode_mp_ds_addr (server->nfs_client->cl_net, - &stream, gfp_flags); + da =nfs4_decode_mp_ds_addr (net, &stream, gfp_flags);if (da)list_add_tail (&da->da_node, &dsaddrs); }
@@ -171,7 +171,7 @@ nfs4_fl_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev, goto out_err_free_deviceid; } - dsaddr->ds_list[i] =nfs4_pnfs_ds_add (&dsaddrs, gfp_flags); + dsaddr->ds_list[i] =nfs4_pnfs_ds_add (net, &dsaddrs, gfp_flags);if (!dsaddr->ds_list[i]) goto out_err_drain_dsaddrs;
fs/nfs/flexfilelayout/flexfilelayoutdev.c +3 -3
@@ -49,6 +49,7 @@ nfs4_ff_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev,struct nfs4_pnfs_ds_addr *da;struct nfs4_ff_layout_ds *new_ds =NULL ;struct nfs4_ff_ds_version *ds_versions =NULL ; +struct net *net = server->nfs_client->cl_net;u32 mp_count;u32 version_count;__be32 *p;
@@ -80,8 +81,7 @@ nfs4_ff_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev,for (i =0 ; i < mp_count; i++) {/* multipath ds */ - da =nfs4_decode_mp_ds_addr (server->nfs_client->cl_net, - &stream, gfp_flags); + da =nfs4_decode_mp_ds_addr (net, &stream, gfp_flags);if (da)list_add_tail (&da->da_node, &dsaddrs); }
@@ -147,7 +147,7 @@ nfs4_ff_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev, new_ds->ds_versions = ds_versions; new_ds->ds_versions_cnt = version_count; - new_ds->ds =nfs4_pnfs_ds_add (&dsaddrs, gfp_flags); + new_ds->ds =nfs4_pnfs_ds_add (net, &dsaddrs, gfp_flags);if (!new_ds->ds) goto out_err_drain_dsaddrs;
fs/nfs/pnfs.h +3 -1
@@ -57,6 +57,7 @@ struct nfs4_pnfs_ds {struct list_head ds_node;/* nfs4_pnfs_dev_hlist dev_dslist */ char *ds_remotestr;/* comma sep list of addrs */ struct list_head ds_addrs; +const struct net *ds_net;struct nfs_client *ds_clp;refcount_t ds_count;unsigned long ds_state;
@@ -405,7 +406,8 @@ int pnfs_generic_commit_pagelist(struct inode *inode,int pnfs_generic_scan_commit_lists (struct nfs_commit_info *cinfo,int max);void pnfs_generic_write_commit_done (struct rpc_task *task,void *data);void nfs4_pnfs_ds_put (struct nfs4_pnfs_ds *ds); -struct nfs4_pnfs_ds *nfs4_pnfs_ds_add (struct list_head *dsaddrs, +struct nfs4_pnfs_ds *nfs4_pnfs_ds_add (const struct net *net, +struct list_head *dsaddrs,gfp_t gfp_flags);void nfs4_pnfs_v3_ds_connect_unload (void ); int nfs4_pnfs_ds_connect(struct nfs_server *mds_srv, struct nfs4_pnfs_ds *ds,
fs/nfs/pnfs_nfs.c +5 -4
@@ -651,12 +651,12 @@ _same_data_server_addrs_locked(const struct list_head *dsaddrs1,* Lookup DS by addresses. nfs4_ds_cache_lock is held */ static struct nfs4_pnfs_ds * -_data_server_lookup_locked (const struct list_head *dsaddrs) +_data_server_lookup_locked (const struct net *net,const struct list_head *dsaddrs) {struct nfs4_pnfs_ds *ds;list_for_each_entry (ds, &nfs4_data_server_cache, ds_node) -if (_same_data_server_addrs_locked (&ds->ds_addrs, dsaddrs)) +if (ds->ds_net == net &&_same_data_server_addrs_locked (&ds->ds_addrs, dsaddrs))return ds;return NULL ; }
@@ -749,7 +749,7 @@ nfs4_pnfs_remotestr(struct list_head *dsaddrs, gfp_t gfp_flags)* uncached and return cached struct nfs4_pnfs_ds. */ struct nfs4_pnfs_ds * -nfs4_pnfs_ds_add (struct list_head *dsaddrs,gfp_t gfp_flags) +nfs4_pnfs_ds_add (const struct net *net,struct list_head *dsaddrs,gfp_t gfp_flags) {struct nfs4_pnfs_ds *tmp_ds, *ds =NULL ;char *remotestr;
@@ -767,13 +767,14 @@ nfs4_pnfs_ds_add(struct list_head *dsaddrs, gfp_t gfp_flags) remotestr =nfs4_pnfs_remotestr (dsaddrs, gfp_flags);spin_lock (&nfs4_ds_cache_lock); - tmp_ds =_data_server_lookup_locked (dsaddrs); + tmp_ds =_data_server_lookup_locked (net, dsaddrs);if (tmp_ds ==NULL ) {INIT_LIST_HEAD (&ds->ds_addrs);list_splice_init (dsaddrs, &ds->ds_addrs); ds->ds_remotestr = remotestr;refcount_set (&ds->ds_count,1 );INIT_LIST_HEAD (&ds->ds_node); + ds->ds_net = net; ds->ds_clp =NULL ;list_add (&ds->ds_node, &nfs4_data_server_cache); dprintk("%s add new data server %s\n", __func__,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 263/270 platform/x86: thinkpad_acpi: Support also NEC Lavie X1475JAS
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Chau <[email protected]>
[ Upstream commit a032f29a15412fab9f4352e0032836d51420a338 ]
Change get_thinkpad_model_data() to check for additional vendor name "NEC" in order to support NEC Lavie X1475JAS notebook (and perhaps more).
The reason of this works with minimal changes is because NEC Lavie X1475JAS is a Thinkpad inside. ACPI dumps reveals its OEM ID to be "LENOVO", BIOS version "R2PET30W" matches typical Lenovo BIOS version, the existence of HKEY of LEN0268, with DMI fw string is "R2PHT24W".
I compiled and tested with my own machine, attached the dmesg below as proof of work:
[ 6.288932] thinkpad_acpi: ThinkPad ACPI Extras v0.26 [ 6.288937] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 6.288938] thinkpad_acpi: ThinkPad BIOS R2PET30W (1.11 ), EC R2PHT24W [ 6.307000] thinkpad_acpi: radio switch found; radios are enabled [ 6.307030] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver [ 6.307033] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... [ 6.320322] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 6.371963] thinkpad_acpi: secondary fan control detected & enabled [ 6.391922] thinkpad_acpi: battery 1 registered (start 0, stop 85, behaviours: 0x7) [ 6.398375] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input13
--- drivers/platform/x86/thinkpad_acpi.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/platform/x86/thinkpad_acpi.c +2 -0
@@ -10233,6 +10233,8 @@ static int __must_check __init get_thinkpad_model_data( tp->vendor =PCI_VENDOR_ID_IBM ; else if (dmi_name_in_vendors("LENOVO")) tp->vendor =PCI_VENDOR_ID_LENOVO ; + else if (dmi_name_in_vendors("NEC")) + tp->vendor =PCI_VENDOR_ID_LENOVO ; else return 0;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 264/270 um: let make clean properly clean underlying SUBARCH as well
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masahiro Yamada <[email protected]>
[ Upstream commit ab09da75700e9d25c7dfbc7f7934920beb5e39b9 ]
Building the kernel with O= is affected by stale in-tree build artifacts.
So, if the source tree is not clean, Kbuild displays the following:
$ make ARCH=um O=build defconfig make[1]: Entering directory '/.../linux/build' *** *** The source tree is not clean, please run 'make ARCH=um mrproper' *** in /.../linux *** make[2]: *** [/.../linux/Makefile:673: outputmakefile] Error 1 make[1]: *** [/.../linux/Makefile:248: __sub-make] Error 2 make[1]: Leaving directory '/.../linux/build' make: *** [Makefile:248: __sub-make] Error 2
Usually, running 'make mrproper' is sufficient for cleaning the source tree for out-of-tree builds.
However, building UML generates build artifacts not only in arch/um/, but also in the SUBARCH directory (i.e., arch/x86/). If in-tree stale files remain under arch/x86/, Kbuild will reuse them instead of creating new ones under the specified build directory.
This commit makes 'make ARCH=um clean' recurse into the SUBARCH directory.
--- arch/um/Makefile | 1 + 1 file changed, 1 insertion(+)
arch/um/Makefile +1 -0
@@ -153,5 +153,6 @@ MRPROPER_FILES += $(HOST_DIR)/include/generated archclean: @find . \( -name '*.bb' -o -name '*.bbg' -o -name '*.da' \ -o -name '*.gcov' \) -type f -print | xargs rm -f + $(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) clean export HEADER_ARCH SUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS DEV_NULL_PATH
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 265/270 spi: spi-sun4i: fix early activation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alessandro Grassi <[email protected]>
[ Upstream commit fb98bd0a13de2c9d96cb5c00c81b5ca118ac9d71 ]
The SPI interface is activated before the CPOL setting is applied. In that moment, the clock idles high and CS goes low. After a short delay, CPOL and other settings are applied, which may cause the clock to change state and idle low. This transition is not part of a clock cycle, and it can confuse the receiving device.
To prevent this unexpected transition, activate the interface while CPOL and the other settings are being applied.
--- drivers/spi/spi-sun4i.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/spi/spi-sun4i.c +4 -1
@@ -263,6 +263,9 @@ static int sun4i_spi_transfer_one(struct spi_master *master,else reg |=SUN4I_CTL_DHB ; +/* Now that the settings are correct, enable the interface */ + reg |=SUN4I_CTL_ENABLE ; +sun4i_spi_write (sspi,SUN4I_CTL_REG , reg);/* Ensure that we have a parent clock fast enough */
@@ -403,7 +406,7 @@ static int sun4i_spi_runtime_resume(struct device *dev) }sun4i_spi_write (sspi,SUN4I_CTL_REG , -SUN4I_CTL_ENABLE |SUN4I_CTL_MASTER |SUN4I_CTL_TP ); +SUN4I_CTL_MASTER |SUN4I_CTL_TP );return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 266/270 tpm: tis: Double the timeout B to 4s
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Suchanek <[email protected]>
[ Upstream commit 2f661f71fda1fc0c42b7746ca5b7da529eb6b5be ]
With some Infineon chips the timeouts in tpm_tis_send_data (both B and
C) can reach up to about 2250 ms.
Timeout C is retried since
commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices")
Timeout B still needs to be extended.
The problem is most commonly encountered with context related operation such as load context/save context. These are issued directly by the kernel, and there is no retry logic for them.
When a filesystem is set up to use the TPM for unlocking the boot fails, and restarting the userspace service is ineffective. This is likely because ignoring a load context/save context result puts the real TPM state and the TPM state expected by the kernel out of sync.
Chips known to be affected:tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54)
Description: SLB9672
Firmware Revision: 15.22
tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22) Firmware Revision: 7.83
tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16) Firmware Revision: 5.63
--- drivers/char/tpm/tpm_tis_core.h | 2 +- include/linux/tpm.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/char/tpm/tpm_tis_core.h +1 -1
@@ -53,7 +53,7 @@ enum tis_int_flags {enum tis_defaults {TIS_MEM_LEN =0x5000 ,TIS_SHORT_TIMEOUT =750 ,/* ms */ -TIS_LONG_TIMEOUT =2000 ,/* 2 sec */ +TIS_LONG_TIMEOUT =4000 ,/* 4 secs */ TIS_TIMEOUT_MIN_ATML =14700 ,/* usecs */ TIS_TIMEOUT_MAX_ATML =15000 ,/* usecs */ };
include/linux/tpm.h +1 -1
@@ -174,7 +174,7 @@ enum tpm2_const {enum tpm2_timeouts {TPM2_TIMEOUT_A =750 , -TPM2_TIMEOUT_B =2000 , +TPM2_TIMEOUT_B =4000 ,TPM2_TIMEOUT_C =200 ,TPM2_TIMEOUT_D =30 ,TPM2_DURATION_SHORT =20 ,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 267/270 platform/x86: fujitsu-laptop: Support Lifebook S2110 hotkeys
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valtteri Koskivuori <[email protected]>
[ Upstream commit a7e255ff9fe4d9b8b902023aaf5b7a673786bb50 ]
The S2110 has an additional set of media playback control keys enabled by a hardware toggle button that switches the keys between "Application" and "Player" modes. Toggling "Player" mode just shifts the scancode of each hotkey up by 4.
Add defines for new scancodes, and a keymap and dmi id for the S2110.
Tested on a Fujitsu Lifebook S2110.
--- drivers/platform/x86/fujitsu-laptop.c | 33 +++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-)
drivers/platform/x86/fujitsu-laptop.c +29 -4
@@ -17,13 +17,13 @@/* * fujitsu-laptop.c - Fujitsu laptop support, providing access to additional * features made available on a range of Fujitsu laptops including the -* P2xxx/P5xxx/S6xxx/S7xxx series. +* P2xxx/P5xxx/S2xxx/S6xxx/S7xxx series. * * This driver implements a vendor-specific backlight control interface for * Fujitsu laptops and provides support for hotkeys present on certain Fujitsu * laptops. * -* This driver has been tested on a Fujitsu Lifebook S6410, S7020 and +* This driver has been tested on a Fujitsu Lifebook S2110, S6410, S7020 and * P8010. It should work on most P-series and S-series Lifebooks, but * YMMV. *
@@ -102,7 +102,11 @@#define KEY2_CODE 0x411#define KEY3_CODE 0x412#define KEY4_CODE 0x413 -#define KEY5_CODE 0x420 +#define KEY5_CODE 0x414 +#define KEY6_CODE 0x415 +#define KEY7_CODE 0x416 +#define KEY8_CODE 0x417 +#define KEY9_CODE 0x420/* Hotkey ringbuffer limits */ #define MAX_HOTKEY_RINGBUFFER_SIZE 100
@@ -450,7 +454,7 @@ static const struct key_entry keymap_default[] = { { KE_KEY, KEY2_CODE, { KEY_PROG2 } }, { KE_KEY, KEY3_CODE, { KEY_PROG3 } }, { KE_KEY, KEY4_CODE, { KEY_PROG4 } }, - { KE_KEY, KEY5_CODE, { KEY_RFKILL } }, + { KE_KEY, KEY9_CODE, { KEY_RFKILL } },/* Soft keys read from status flags */ { KE_KEY, FLAG_RFKILL, { KEY_RFKILL } }, { KE_KEY, FLAG_TOUCHPAD_TOGGLE, { KEY_TOUCHPAD_TOGGLE } },
@@ -474,6 +478,18 @@ static const struct key_entry keymap_p8010[] = { { KE_END, 0 } }; +static const struct key_entry keymap_s2110[] = { + {KE_KEY ,KEY1_CODE , {KEY_PROG1 } },/* "A" */ + {KE_KEY ,KEY2_CODE , {KEY_PROG2 } },/* "B" */ + {KE_KEY ,KEY3_CODE , {KEY_WWW } },/* "Internet" */ + {KE_KEY ,KEY4_CODE , {KEY_EMAIL } },/* "E-mail" */ + {KE_KEY ,KEY5_CODE , {KEY_STOPCD } }, + {KE_KEY ,KEY6_CODE , {KEY_PLAYPAUSE } }, + {KE_KEY ,KEY7_CODE , {KEY_PREVIOUSSONG } }, + {KE_KEY ,KEY8_CODE , {KEY_NEXTSONG } }, + {KE_END ,0 } +}; +static const struct key_entry *keymap = keymap_default;static int fujitsu_laptop_dmi_keymap_override (const struct dmi_system_id *id)
@@ -511,6 +527,15 @@ static const struct dmi_system_id fujitsu_laptop_dmi_table[] = { }, .driver_data = (void *)keymap_p8010 }, + { + .callback = fujitsu_laptop_dmi_keymap_override, + .ident = "Fujitsu LifeBook S2110", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"), + DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK S2110"), + }, + .driver_data = (void *)keymap_s2110 + }, {} };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 268/270 platform/x86: thinkpad_acpi: Ignore battery threshold change event notification
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Pearson <[email protected]>
[ Upstream commit 29e4e6b4235fefa5930affb531fe449cac330a72 ]
If user modifies the battery charge threshold an ACPI event is generated. Confirmed with Lenovo FW team this is only generated on user event. As no action is needed, ignore the event and prevent spurious kernel logs.
--- drivers/platform/x86/thinkpad_acpi.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/platform/x86/thinkpad_acpi.c +5 -0
@@ -195,6 +195,7 @@ enum tpacpi_hkey_event_t {/* Thermal events */ TP_HKEY_EV_ALARM_BAT_HOT =0x6011 ,/* battery too hot */ TP_HKEY_EV_ALARM_BAT_XHOT =0x6012 ,/* battery critically hot */ +TP_HKEY_EV_ALARM_BAT_LIM_CHANGE =0x6013 ,/* battery charge limit changed*/ TP_HKEY_EV_ALARM_SENSOR_HOT =0x6021 ,/* sensor too hot */ TP_HKEY_EV_ALARM_SENSOR_XHOT =0x6022 ,/* sensor critically hot */ TP_HKEY_EV_THM_TABLE_CHANGED = 0x6030, /* windows; thermal table changed */
@@ -4049,6 +4050,10 @@ static bool hotkey_notify_6xxx(const u32 hkey,pr_alert ("THERMAL EMERGENCY: battery is extremely hot!\n" );/* recommended action: immediate sleep/hibernate */ break ; +case TP_HKEY_EV_ALARM_BAT_LIM_CHANGE : +pr_debug ("Battery Info: battery charge threshold changed\n" ); +/* User changed charging threshold. No action needed */ +return true;case TP_HKEY_EV_ALARM_SENSOR_HOT :pr_crit ("THERMAL ALARM: a sensor reports something is too hot!\n" );/* recommended action: warn user through gui, that */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 269/270 xen/swiotlb: relax alignment requirements
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
commit 85fcb57c983f423180ba6ec5d0034242da05cc54 upstream.
When mapping a buffer for DMA via .map_page or .map_sg DMA operations, there is no need to check the machine frames to be aligned according to the mapped areas size. All what is needed in these cases is that the buffer is contiguous at machine level.
So carve out the alignment check from range_straddles_page_boundary() and move it to a helper called by xen_swiotlb_alloc_coherent() and xen_swiotlb_free_coherent() directly.
--- drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
drivers/xen/swiotlb-xen.c +11 -7
@@ -87,19 +87,21 @@ static inline dma_addr_t xen_virt_to_busreturn xen_phys_to_dma (dev,virt_to_phys (address)); } +static inline bool range_requires_alignment (phys_addr_t p,size_t size) +{ +phys_addr_t algn =1ULL << (get_order (size) +PAGE_SHIFT ); +phys_addr_t bus_addr =pfn_to_bfn (XEN_PFN_DOWN (p)) <<XEN_PAGE_SHIFT ; + +return IS_ALIGNED (p, algn) && !IS_ALIGNED (bus_addr, algn); +} +static inline int range_straddles_page_boundary (phys_addr_t p,size_t size) {unsigned long next_bfn, xen_pfn =XEN_PFN_DOWN (p);unsigned int i, nr_pages =XEN_PFN_UP (xen_offset_in_page (p) + size); -phys_addr_t algn =1ULL << (get_order (size) +PAGE_SHIFT ); next_bfn =pfn_to_bfn (xen_pfn); -/* If buffer is physically aligned, ensure DMA alignment. */ -if (IS_ALIGNED (p, algn) && - !IS_ALIGNED ((phys_addr_t )next_bfn <<XEN_PAGE_SHIFT , algn)) -return 1 ; -for (i =1 ; i < nr_pages; i++)if (pfn_to_bfn (++xen_pfn) != ++next_bfn)return 1 ;
@@ -321,7 +323,8 @@ xen_swiotlb_alloc_coherent(struct device phys =dma_to_phys (hwdev, *dma_handle); dev_addr =xen_phys_to_dma (hwdev, phys);if (((dev_addr + size -1 <= dma_mask)) && - !range_straddles_page_boundary (phys, size)) + !range_straddles_page_boundary (phys, size) && + !range_requires_alignment (phys, size)) *dma_handle = dev_addr;else { if (xen_create_contiguous_region(phys, order,
@@ -362,6 +365,7 @@ xen_swiotlb_free_coherent(struct deviceif (!WARN_ON ((dev_addr + size -1 > dma_mask) ||range_straddles_page_boundary (phys, size)) && + !range_requires_alignment (phys, size) &&TestClearPageXenRemapped (page))xen_destroy_contiguous_region (phys, order);
Greg Kroah-Hartman
maintainerPATCH 270/270 perf/arm-cmn: Initialise cmn->cpu earlier
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robin Murphy <[email protected]>
commit 597704e201068db3d104de3c7a4d447ff8209127 upstream.
For all the complexity of handling affinity for CPU hotplug, what we've apparently managed to overlook is that arm_cmn_init_irqs() has in fact always been setting the *initial* affinity of all IRQs to CPU 0, not the CPU we subsequently choose for event scheduling. Oh dear.
--- drivers/perf/arm-cmn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/perf/arm-cmn.c +1 -1
@@ -1512,6 +1512,7 @@ static int arm_cmn_probe(struct platformreturn -ENOMEM ; cmn->dev = &pdev->dev; + cmn->cpu =raw_smp_processor_id ();platform_set_drvdata (pdev, cmn);if (has_acpi_companion (cmn->dev))
@@ -1533,7 +1534,6 @@ static int arm_cmn_probe(struct platformif (err)return err; - cmn->cpu =raw_smp_processor_id (); cmn->pmu = (struct pmu ) { .module =THIS_MODULE , .attr_groups = arm_cmn_attr_groups,
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.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:
Similar build warning as reported for 5.4, due to the same commit:
commit b47e6abc7dc5772ecb45383d9956f9fcb7fdf33c
Author: Jeongjun Park <[email protected]> Date: Tue Apr 22 20:30:25 2025 +0900
tracing: Fix oob write in trace_seq_to_buffer()
commit f5178c41bb43444a6008150fe6094497135d07cb upstream.
In file included from ./include/linux/kernel.h:15,
from ./include/asm-generic/bug.h:20,
from ./arch/arm/include/asm/bug.h:60,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/mm.h:9,
from ./include/linux/ring_buffer.h:5,
from kernel/trace/trace.c:15:kernel/trace/trace.c: In function 'tracing_splice_read_pipe':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~
./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~
./include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp'
45 | #define min(x, y) __careful_cmp(x, y, <)
| ^~~~~~~~~~~~~kernel/trace/trace.c:6688:43: note: in expansion of macro 'min'
6688 |
min((size_t)trace_seq_used(&iter->seq),
| ^~~
Signature · 1 line
Florian
Quoted 49 lines · Florian Fainelli
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-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.10.y and the diffstat can be found below.Quoted 3 lines
thanks,
greg k-h
On
ARCH_BRCMSTBusing 32-bit and 64-bit ARM kernels, build tested onBMIPS_GENERIC:Tested-by Florian Fainelli <[email protected]>Similar build warning as reported for 5.4, due to the same commit:
commit
b47e6abc7dc5772ecb45383d9956f9fcb7fdf33c
Author: Jeongjun Park <[email protected]>
Date: Tue Apr 22 20:30:25 2025 +0900tracing: Fix oob write in
trace_seq_to_buffer()commit
f5178c41bb43444a6008150fe6094497135d07cbupstream.In file included from
./include/linux/kernel.h:15,
from./include/asm-generic/bug.h:20,
from./arch/arm/include/asm/bug.h:60,
from./include/linux/bug.h:5,
from./include/linux/mmdebug.h:5,
from./include/linux/mm.h:9,
from./include/linux/ring_buffer.h:5,
fromkernel/trace/trace.c:15:kernel/trace/trace.c: In function 'tracing_splice_read_pipe':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y)&&__no_side_effects(x, y))
| ^~~~~~~~~~~./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'
Quoted 9 lines
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~./include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp'
45 | #definemin(x, y)__careful_cmp(x, y, <)
| ^~~~~~~~~~~~~kernel/trace/trace.c:6688:43: note: in expansion of macro 'min'
6688 | min((size_t)trace_seq_used(&iter->seq),
| ^~~
And also this one:
commit e0a3a33cecd3ce2fde1de4ff0e223dc1db484a8d
Author: Eric Dumazet <[email protected]> Date: Wed Mar 5 13:05:50 2025 +0000
tcp: bring back NUMA dispersion in inet_ehash_locks_alloc()
[ Upstream commit f8ece40786c9342249aa0a1b55e148ee23b2a746 ]
on ARM64:
In file included from ./include/linux/kernel.h:15,
from ./include/linux/list.h:9,
from ./include/linux/module.h:12,
from net/ipv4/inet_hashtables.c:12:net/ipv4/inet_hashtables.c: In function 'inet_ehash_locks_alloc':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~
./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~
./include/linux/minmax.h:52:25: note: in expansion of macro '__careful_cmp'
52 | #define max(x, y) __careful_cmp(x, y, >)
| ^~~~~~~~~~~~~net/ipv4/inet_hashtables.c:946:19: note: in expansion of macro 'max'
946 | nblocks = max(nblocks, num_online_nodes() * PAGE_SIZE /
locksz);
| ^~~
Signature · 1 line
Florian
Greg Kroah-Hartman
maintainerQuoted 95 lines · Florian Fainelli
Quoted 53 lines · Florian Fainelli
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-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.10.y
and the diffstat can be found below.Quoted 3 lines
thanks,
greg k-h
On
ARCH_BRCMSTBusing 32-bit and 64-bit ARM kernels, build tested onBMIPS_GENERIC:Tested-by Florian Fainelli <[email protected]>Similar build warning as reported for 5.4, due to the same commit:
commit
b47e6abc7dc5772ecb45383d9956f9fcb7fdf33c
Author: Jeongjun Park <[email protected]>
Date: Tue Apr 22 20:30:25 2025 +0900tracing: Fix oob write in
trace_seq_to_buffer()commit
f5178c41bb43444a6008150fe6094497135d07cbupstream.In file included from
./include/linux/kernel.h:15,
from./include/asm-generic/bug.h:20,
from./arch/arm/include/asm/bug.h:60,
from./include/linux/bug.h:5,
from./include/linux/mmdebug.h:5,
from./include/linux/mm.h:9,
from./include/linux/ring_buffer.h:5,
fromkernel/trace/trace.c:15:kernel/trace/trace.c: In function 'tracing_splice_read_pipe':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y)&&__no_side_effects(x, y)) | ^~~~~~~~~~~./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'Quoted 9 lines
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~./include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp'
45 | #definemin(x, y)__careful_cmp(x, y, <)
| ^~~~~~~~~~~~~kernel/trace/trace.c:6688:43: note: in expansion of macro 'min'
6688 | min((size_t)trace_seq_used(&iter->seq),
| ^~~And also this one:
commit
e0a3a33cecd3ce2fde1de4ff0e223dc1db484a8dAuthor: Eric Dumazet <[email protected]> Date: Wed Mar 5 13:05:50 2025 +0000tcp: bring back NUMA dispersion in
inet_ehash_locks_alloc()[ Upstream commit
f8ece40786c9342249aa0a1b55e148ee23b2a746]on ARM64:
In file included from
./include/linux/kernel.h:15,from ./include/linux/list.h:9, from ./include/linux/module.h:12, from net/ipv4/inet_hashtables.c:12:
net/ipv4/inet_hashtables.c: In function 'inet_ehash_locks_alloc':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y)&&__no_side_effects(x, y))| ^~~~~~~~~~~ ./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp' 36 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:52:25: note: in expansion of macro '__careful_cmp' 52 | #define max(x, y) __careful_cmp(x, y, >) | ^~~~~~~~~~~~~
Quoted 5 lines
net/ipv4/inet_hashtables.c:946:19: note: in expansion of macro 'max'
946 | nblocks = max(nblocks,num_online_nodes()*PAGE_SIZE/
locksz);
| ^~~
For both of these, I'll just let them be as they are ok, it's just the mess of our min/max macro unwinding causes these issues.
Unless they really bother someone, and in that case, a patch to add the correct type to the backport to make the noise go away would be greatly appreciated.
thanks,
greg k-h
Quoted 102 lines · Greg Kroah-Hartman
Quoted 95 lines · Florian Fainelli
Quoted 53 lines · Florian Fainelli
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-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.10.y
and the diffstat can be found below.Quoted 3 lines
thanks,
greg k-h
On
ARCH_BRCMSTBusing 32-bit and 64-bit ARM kernels, build tested onBMIPS_GENERIC:Tested-by Florian Fainelli <[email protected]>Similar build warning as reported for 5.4, due to the same commit:
commit
b47e6abc7dc5772ecb45383d9956f9fcb7fdf33c
Author: Jeongjun Park <[email protected]>
Date: Tue Apr 22 20:30:25 2025 +0900tracing: Fix oob write in
trace_seq_to_buffer()commit
f5178c41bb43444a6008150fe6094497135d07cbupstream.In file included from
./include/linux/kernel.h:15,
from./include/asm-generic/bug.h:20,
from./arch/arm/include/asm/bug.h:60,
from./include/linux/bug.h:5,
from./include/linux/mmdebug.h:5,
from./include/linux/mm.h:9,
from./include/linux/ring_buffer.h:5,
fromkernel/trace/trace.c:15:kernel/trace/trace.c: In function 'tracing_splice_read_pipe':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y)&&__no_side_effects(x, y)) | ^~~~~~~~~~~./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'Quoted 9 lines
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~./include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp'
45 | #definemin(x, y)__careful_cmp(x, y, <)
| ^~~~~~~~~~~~~kernel/trace/trace.c:6688:43: note: in expansion of macro 'min'
6688 | min((size_t)trace_seq_used(&iter->seq),
| ^~~And also this one:
commit
e0a3a33cecd3ce2fde1de4ff0e223dc1db484a8dAuthor: Eric Dumazet <[email protected]> Date: Wed Mar 5 13:05:50 2025 +0000tcp: bring back NUMA dispersion in
inet_ehash_locks_alloc()[ Upstream commit
f8ece40786c9342249aa0a1b55e148ee23b2a746]on ARM64:
In file included from
./include/linux/kernel.h:15,from ./include/linux/list.h:9, from ./include/linux/module.h:12, from net/ipv4/inet_hashtables.c:12: net/ipv4/inet_hashtables.c: In function 'inet_ehash_locks_alloc': ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ ./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck' 26 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ ./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp' 36 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:52:25: note: in expansion of macro '__careful_cmp' 52 | #define max(x, y) __careful_cmp(x, y, >) | ^~~~~~~~~~~~~Quoted 5 lines
net/ipv4/inet_hashtables.c:946:19: note: in expansion of macro 'max'
946 | nblocks = max(nblocks,num_online_nodes()*PAGE_SIZE/
locksz);
| ^~~
Quoted 6 lines
For both of these, I'll just let them be as they are ok, it's just the mess of our min/max macro unwinding causes these issues.
Unless they really bother someone, and in that case, a patch to add the correct type to the backport to make the noise go away would be greatly appreciated.
Yeah that's a reasonable resolution, I will try to track down the missing patches for minmax.h so we are warning free for the stable kernels.
Thanks
Signature · 1 line
Florian
Greg Kroah-Hartman
maintainerQuoted 106 lines · Florian Fainelli
Quoted 105 lines · Greg Kroah-Hartman
Quoted 95 lines · Florian Fainelli
Quoted 53 lines · Florian Fainelli
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-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.10.y
and the diffstat can be found below.Quoted 3 lines
thanks,
greg k-h
On
ARCH_BRCMSTBusing 32-bit and 64-bit ARM kernels, build tested onBMIPS_GENERIC:Tested-by Florian Fainelli <[email protected]>Similar build warning as reported for 5.4, due to the same commit:
commit
b47e6abc7dc5772ecb45383d9956f9fcb7fdf33c
Author: Jeongjun Park <[email protected]>
Date: Tue Apr 22 20:30:25 2025 +0900tracing: Fix oob write in
trace_seq_to_buffer()commit
f5178c41bb43444a6008150fe6094497135d07cbupstream.In file included from
./include/linux/kernel.h:15,
from./include/asm-generic/bug.h:20,
from./arch/arm/include/asm/bug.h:60,
from./include/linux/bug.h:5,
from./include/linux/mmdebug.h:5,
from./include/linux/mm.h:9,
from./include/linux/ring_buffer.h:5,
fromkernel/trace/trace.c:15:kernel/trace/trace.c: In function 'tracing_splice_read_pipe':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y)&&__no_side_effects(x, y)) | ^~~~~~~~~~~./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'Quoted 9 lines
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~./include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp'
45 | #definemin(x, y)__careful_cmp(x, y, <)
| ^~~~~~~~~~~~~kernel/trace/trace.c:6688:43: note: in expansion of macro 'min'
6688 | min((size_t)trace_seq_used(&iter->seq),
| ^~~And also this one:
commit
e0a3a33cecd3ce2fde1de4ff0e223dc1db484a8dAuthor: Eric Dumazet <[email protected]> Date: Wed Mar 5 13:05:50 2025 +0000tcp: bring back NUMA dispersion in
inet_ehash_locks_alloc()[ Upstream commit
f8ece40786c9342249aa0a1b55e148ee23b2a746]on ARM64:
In file included from
./include/linux/kernel.h:15,from ./include/linux/list.h:9, from ./include/linux/module.h:12, from net/ipv4/inet_hashtables.c:12: net/ipv4/inet_hashtables.c: In function 'inet_ehash_locks_alloc': ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ ./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck' 26 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ ./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp' 36 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:52:25: note: in expansion of macro '__careful_cmp' 52 | #define max(x, y) __careful_cmp(x, y, >) | ^~~~~~~~~~~~~Quoted 5 lines
net/ipv4/inet_hashtables.c:946:19: note: in expansion of macro 'max'
946 | nblocks = max(nblocks,num_online_nodes()*PAGE_SIZE/
locksz);
| ^~~For both of these, I'll just let them be as they are ok, it's just the mess of our min/max macro unwinding causes these issues.
Quoted 6 lines
Quoted 3 lines
Unless they really bother someone, and in that case, a patch to add the correct type to the backport to make the noise go away would be greatly appreciated.
Yeah that's a reasonable resolution, I will try to track down the missing patches for
minmax.hso we are warning free for the stable kernels.
I tried in the past, it's non-trivial. What would be easier is to just properly cast the variables in the places where this warning is showing up to get rid of that warning. We've done that in some backports in the past as well.
good luck!
greg k-h
Quoted 114 lines · Greg Kroah-Hartman
Quoted 106 lines · Florian Fainelli
Quoted 105 lines · Greg Kroah-Hartman
Quoted 95 lines · Florian Fainelli
Quoted 53 lines · Florian Fainelli
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-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.10.y
and the diffstat can be found below.Quoted 3 lines
thanks,
greg k-h
On
ARCH_BRCMSTBusing 32-bit and 64-bit ARM kernels, build tested onBMIPS_GENERIC:Tested-by Florian Fainelli <[email protected]>Similar build warning as reported for 5.4, due to the same commit:
commit
b47e6abc7dc5772ecb45383d9956f9fcb7fdf33c
Author: Jeongjun Park <[email protected]>
Date: Tue Apr 22 20:30:25 2025 +0900tracing: Fix oob write in
trace_seq_to_buffer()commit f5178c41bb43444a6008150fe6094497135d07cb upstream.In file included from
./include/linux/kernel.h:15,
from./include/asm-generic/bug.h:20,
from./arch/arm/include/asm/bug.h:60, from./include/linux/bug.h:5,
from./include/linux/mmdebug.h:5,
from./include/linux/mm.h:9,
from./include/linux/ring_buffer.h:5, fromkernel/trace/trace.c:15:kernel/trace/trace.c: In function 'tracing_splice_read_pipe':./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y)&&__no_side_effects(x, y)) | ^~~~~~~~~~~./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'Quoted 9 lines
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~./include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp'
45 | #definemin(x, y)__careful_cmp(x, y, <)
| ^~~~~~~~~~~~~kernel/trace/trace.c:6688:43: note: in expansion of macro 'min'
6688 | min((size_t)trace_seq_used(&iter->seq),
| ^~~And also this one:
commit
e0a3a33cecd3ce2fde1de4ff0e223dc1db484a8dAuthor: Eric Dumazet <[email protected]> Date: Wed Mar 5 13:05:50 2025 +0000tcp: bring back NUMA dispersion in
inet_ehash_locks_alloc()[ Upstream commit
f8ece40786c9342249aa0a1b55e148ee23b2a746]on ARM64:
In file included from
./include/linux/kernel.h:15,from ./include/linux/list.h:9, from ./include/linux/module.h:12, from net/ipv4/inet_hashtables.c:12: net/ipv4/inet_hashtables.c: In function 'inet_ehash_locks_alloc': ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ ./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck' 26 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ ./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp' 36 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:52:25: note: in expansion of macro '__careful_cmp' 52 | #define max(x, y) __careful_cmp(x, y, >) | ^~~~~~~~~~~~~Quoted 5 lines
net/ipv4/inet_hashtables.c:946:19: note: in expansion of macro 'max'
946 | nblocks = max(nblocks,num_online_nodes()*PAGE_SIZE/
locksz);
| ^~~For both of these, I'll just let them be as they are ok, it's just the mess of our min/max macro unwinding causes these issues.
Quoted 6 lines
Quoted 3 lines
Unless they really bother someone, and in that case, a patch to add the correct type to the backport to make the noise go away would be greatly appreciated.
Yeah that's a reasonable resolution, I will try to track down the missing patches for
minmax.hso we are warning free for the stable kernels.
Quoted 6 lines
I tried in the past, it's non-trivial. What would be easier is to just properly cast the variables in the places where this warning is showing up to get rid of that warning. We've done that in some backports in the past as well.
good luck!
I see now that in 5.4.295-rc1 you have backported:
commit 36d6c6cd65043d553126b934bf1fcb79dcb58499
Author: Pan Taixi <[email protected]> Date: Mon May 26 09:37:31 2025 +0800
tracing: Fix compilation warning on arm32
commit 2fbdb6d8e03b70668c0876e635506540ae92ab05 upstream.
which takes care of resolving the warning, thanks!
Signature · 1 line
Florian
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.238 release. There are 270 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.
We see build problem on risc-v:
drivers/clocksource/timer-riscv.c: In function 'riscv_timer_dying_cpu':
1932drivers/clocksource/timer-riscv.c:82:2: error: implicit declaration of function 'riscv_clock_event_stop' [-Werror=implicit-function-declaration] 1933
82 | riscv_clock_event_stop();
1934
| ^~~~~~~~~~~~~~~~~~~~~~
1935
CC fs/namei.o
1936
CC net/sunrpc/rpcb_clnt.o
1937
cc1: some warnings being treated as errors
1938
make[2]: *** [scripts/Makefile.build:286: drivers/clocksource/timer-riscv.o] Error 1 1939
make[1]: *** [scripts/Makefile.build:503: drivers/clocksource] Error 2 1940
make[1]: *** Waiting for unfinished jobs....
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/1849177067
Huh. And on arm....?
drivers/clocksource/timer-riscv.c: In function 'riscv_timer_dying_cpu':
2053drivers/clocksource/timer-riscv.c:82:2: error: implicit declaration of function 'riscv_clock_event_stop' [-Werror=implicit-function-declaration] 2054
82 | riscv_clock_event_stop();
2055
| ^~~~~~~~~~~~~~~~~~~~~~
2056
CC drivers/mmc/core/slot-gpio.o
2057
CC drivers/crypto/virtio/virtio_crypto_core.o
2058
CC drivers/firmware/efi/libstub/lib-cmdline.o
2059
cc1: some warnings being treated as errors
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
There are two issues,
1)
Regressions on riscv defconfig builds failing with gcc-12, gcc-8 and clang-20 toolchains on 5.10.238-rc1.
Regression Analysis:
- New regression? Yes
- Reproducible? Yes
Build regression: riscv defconfig timer-riscv.c:82:2: error: implicit declaration of function 'riscv_clock_event_stop'
Build log:
---------drivers/clocksource/timer-riscv.c:82:2: error: implicit declaration of function 'riscv_clock_event_stop' [-Werror,-Wimplicit-function-declaration]
82 | riscv_clock_event_stop();
| ^1 error generated.
This patch caused the build error,
clocksource/drivers/timer-riscv: Stop stimecmp when cpu hotplug [ Upstream commit 70c93b026ed07078e933583591aa9ca6701cd9da ]
## Steps to reproduce
- tuxmake --runtime podman --target-arch riscv --toolchain clang-20
--kconfig defconfig LLVM=1 LLVM_IAS=1
## Build riscv
* Build log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.237-271-g8bfb88108193/testrun/28635871/suite/build/test/clang-20-defconfig/log
* Build details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.237-271-g8bfb88108193/testrun/28635871/suite/build/test/clang-20-defconfig/details/
* Build history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.237-271-g8bfb88108193/testrun/28635871/suite/build/test/clang-20-defconfig/history/
* architecture: riscv
* toolchain: gcc-8, gcc-12, clang-20
* config : defconfig
* Build config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2xxPulf5bqlsj7nSlN9PnLY9NXG/config
* Build: https://storage.tuxsuite.com/public/linaro/lkft/builds/2xxPulf5bqlsj7nSlN9PnLY9NXG/
2) The following build warnings were noticed on arm with clang-20.
Build regression: arm at91_dt_defconfig warning comparison of distinct pointer types ('typeof (nblocks) *' (aka 'unsigned int *') and 'typeof (num_node_state(N_ONLINE) * ((1UL) << 12) / locksz) *' (aka 'unsigned long *')) [-Wcompare-distinct-pointer-types]
Build warnings on arm:
---------net/ipv4/inet_hashtables.c:946:12: warning: comparison of distinct pointer types ('typeof (nblocks) *' (aka 'unsigned int *') and 'typeof (num_node_state(N_ONLINE) * ((1UL) << 12) / locksz) *' (aka 'unsigned long *')) [-Wcompare-distinct-pointer-types]
946 | nblocks = max(nblocks, num_online_nodes() * PAGE_SIZE / locksz);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~1 warning generated.
This commit is causing build warnings,
tcp: bring back NUMA dispersion in inet_ehash_locks_alloc() [ Upstream commit f8ece40786c9342249aa0a1b55e148ee23b2a746 ]
# Steps to reproduce
- tuxmake --runtime podman --target-arch arm --toolchain clang-20
--kconfig at91_dt_defconfig LLVM=1 LLVM_IAS=0
## Build arm
* architecture: arm
* toolchain: clang-20
* config: at91_dt_defconfig
* Build config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2xxPtpUSdrY70QnawZR0ftSwhPt/config
* Build: https://storage.tuxsuite.com/public/linaro/lkft/builds/2xxPtpUSdrY70QnawZR0ftSwhPt/
## Build
* kernel: 5.10.238-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 8bfb881081935b7a621f358516e28f4470af3296
* git describe: v5.10.237-271-g8bfb88108193
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.237-271-g8bfb88108193
## Test Regressions (compared to v5.10.236-287-gce0fd5a9f1a4)
* riscv, build
- clang-20-defconfig
- gcc-12-defconfig
- gcc-8-defconfig
## Metric Regressions (compared to v5.10.236-287-gce0fd5a9f1a4)
## Test Fixes (compared to v5.10.236-287-gce0fd5a9f1a4)
## Metric Fixes (compared to v5.10.236-287-gce0fd5a9f1a4)
## Test result summary
total: 36900, pass: 27422, fail: 1956, skip: 7366, xfail: 156
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 100 total, 100 passed, 0 failed
* arm64: 28 total, 28 passed, 0 failed
* i386: 20 total, 20 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 21 total, 21 passed, 0 failed
* riscv: 9 total, 6 passed, 3 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 24 total, 24 passed, 0 failed
## Test suites summary
* boot
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-exec
* kselftest-fpu
* kselftest-futex
* kselftest-intel_pstate
* kselftest-kcmp
* kselftest-membarrier
* kselftest-mincore
* kselftest-mqueue
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-crypto
* ltp-cve
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 41 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
There are two issues,
1)
Regressions on riscv defconfig builds failing with gcc-12, gcc-8 and clang-20 toolchains on 5.10.238-rc1.Regression Analysis:
- New regression? Yes
- Reproducible? YesBuild regression: riscv defconfig timer-riscv.c:82:2: error: implicit declaration of function '
riscv_clock_event_stop'Build log:
---------drivers/clocksource/timer-riscv.c:82:2: error: implicit declaration of function 'riscv_clock_event_stop' [-Werror,-Wimplicit-function-declaration]
Quoted 8 lines
82 | riscv_clock_event_stop(); | ^1 error generated.
This patch caused the build error,
clocksource/drivers/timer-riscv: Stop stimecmp when cpu hotplug [ Upstream commit
70c93b026ed07078e933583591aa9ca6701cd9da]
Now dropped, thanks!
greg k-h
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 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.
This fails to boot with a NFS root on Raspberry Pi 3b+, due to 558a48d4fabd70213117ec20f476adff48f72365 ("net: phy: microchip: force IRQ polling mode for lan88xx") as was also a problem for other stables.
Greg Kroah-Hartman
maintainerQuoted 9 lines · Mark Brown
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 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.
This fails to boot with a NFS root on Raspberry Pi 3b+, due to
558a48d4fabd70213117ec20f476adff48f72365("net: phy: microchip: force IRQ polling mode for lan88xx") as was also a problem for other stables.
Odd, I see it in the 5.15.y released tree, so did we get a fix for it with a different commit or should it just be dropped entirely from the 5.10.y queue?
thanks,
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
Quoted 3 lines · Mark Brown
This fails to boot with a NFS root on Raspberry Pi 3b+, due to
558a48d4fabd70213117ec20f476adff48f72365("net: phy: microchip: force IRQ polling mode for lan88xx") as was also a problem for other stables.Odd, I see it in the 5.15.y released tree, so did we get a fix for it with a different commit or should it just be dropped entirely from the 5.10.y queue?
There's a revert in the v5.15 tree as 2edc296e2107a003e383f87cdc7e29bddcb6b17e, IIRC it went it while I was on holiday so I didn't test the release it went into.
Greg Kroah-Hartman
maintainerQuoted 7 lines · Mark Brown
Quoted 5 lines · Greg Kroah-Hartman
Quoted 3 lines · Mark Brown
This fails to boot with a NFS root on Raspberry Pi 3b+, due to
558a48d4fabd70213117ec20f476adff48f72365("net: phy: microchip: force IRQ polling mode for lan88xx") as was also a problem for other stables.
Quoted 7 lines
Quoted 3 lines
Odd, I see it in the 5.15.y released tree, so did we get a fix for it with a different commit or should it just be dropped entirely from the 5.10.y queue?
There's a revert in the v5.15 tree as
2edc296e2107a003e383f87cdc7e29bddcb6b17e, IIRC it went it while I was on holiday so I didn't test the release it went into.
Ah, that makes sense. All now dropped, thanks for warning me.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.238 release. There are 270 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 04 Jun 2025 13:42:20 +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.10.238-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.10:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
67 tests: 67 pass, 0 failLinux version: 5.10.238-rc1-g8bfb88108193
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