6.12.64-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 290/567 ARM: dts: microchip: sama5d2: fix spi flexcom fifo size to 32
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Ferre <[email protected]>
commit 7d5864dc5d5ea6a35983dd05295fb17f2f2f44ce upstream.
Unlike standalone spi peripherals, on sama5d2, the flexcom spi have fifo size of 32 data. Fix flexcom/spi nodes where this property is wrong.
--- arch/arm/boot/dts/microchip/sama5d2.dtsi | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
arch/arm/boot/dts/microchip/sama5d2.dtsi +5 -5
@@ -568,7 +568,7 @@ AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(12))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; };
@@ -639,7 +639,7 @@ AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(14))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; };
@@ -851,7 +851,7 @@ AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(16))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; };
@@ -922,7 +922,7 @@ AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(18))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; };
@@ -994,7 +994,7 @@ AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(20))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; };
Greg Kroah-Hartman
maintainerPATCH 291/567 x86/msi: Make irq_retrigger() functional for posted MSI
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
[ Upstream commit 0edc78b82bea85e1b2165d8e870a5c3535919695 ]
Luigi reported that retriggering a posted MSI interrupt does not work correctly.
The reason is that the retrigger happens at the vector domain by sending an IPI to the actual vector on the target CPU. That works correctly exactly once because the posted MSI interrupt chip does not issue an EOI as that's only required for the posted MSI notification vector itself.
As a consequence the vector becomes stale in the ISR, which not only affects this vector but also any lower priority vector in the affected APIC because the ISR bit is not cleared.
Luigi proposed to set the vector in the remap PIR bitmap and raise the posted MSI notification vector. That works, but that still does not cure a related problem:
If there is ever a stray interrupt on such a vector, then the related APIC ISR bit becomes stale due to the lack of EOI as described above. Unlikely to happen, but if it happens it's not debuggable at all.
So instead of playing games with the PIR, this can be actually solved for both cases by:
1) Keeping track of the posted interrupt vector handler state
2) Implementing a posted MSI specific irq_ack() callback which checks that state. If the posted vector handler is inactive it issues an EOI, otherwise it delegates that to the posted handler.
This is correct versus affinity changes and concurrent events on the posted vector as the actual handler invocation is serialized through the interrupt descriptor lock.
--- arch/x86/include/asm/irq_remapping.h | 7 +++++++ arch/x86/kernel/irq.c | 23 +++++++++++++++++++++++ drivers/iommu/intel/irq_remapping.c | 8 ++++---- 3 files changed, 34 insertions(+), 4 deletions(-)
arch/x86/include/asm/irq_remapping.h +7 -0
@@ -72,4 +72,11 @@ static inline void panic_if_irq_remap(co }#endif /* CONFIG_IRQ_REMAP */ + +#ifdef CONFIG_X86_POSTED_MSI +void intel_ack_posted_msi_irq (struct irq_data *irqd); +#else +#define intel_ack_posted_msi_irq NULL +#endif +#endif /* __X86_IRQ_REMAPPING_H */
arch/x86/kernel/irq.c +23 -0
@@ -391,6 +391,7 @@ DEFINE_IDTENTRY_SYSVEC_SIMPLE(sysvec_kvm/* Posted Interrupt Descriptors for coalesced MSIs to be posted */ DEFINE_PER_CPU_ALIGNED(struct pi_desc, posted_msi_pi_desc); +static DEFINE_PER_CPU(bool, posted_msi_handler_active);void intel_posted_msi_init (void ) {
@@ -408,6 +409,25 @@ void intel_posted_msi_init(void)this_cpu_write (posted_msi_pi_desc.ndst, destination); } +void intel_ack_posted_msi_irq (struct irq_data *irqd) +{ +irq_move_irq (irqd); + +/* +* Handle the rare case that irq_retrigger() raised the actual +* assigned vector on the target CPU, which means that it was not +* invoked via the posted MSI handler below. In that case APIC EOI +* is required as otherwise the ISR entry becomes stale and lower +* priority interrupts are never going to be delivered after that. +* +* If the posted handler invoked the device interrupt handler then +* the EOI would be premature because it would acknowledge the +* posted vector. +*/ +if (unlikely (!__this_cpu_read (posted_msi_handler_active))) +apic_eoi (); +} +/* * De-multiplexing posted interrupts is on the performance path, the code * below is written to optimize the cache performance based on the following
@@ -483,6 +503,8 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_posted_msi pid =this_cpu_ptr (&posted_msi_pi_desc); +/* Mark the handler active for intel_ack_posted_msi_irq() */ +__this_cpu_write (posted_msi_handler_active, true);inc_irq_stat (posted_msi_notification_count);irq_enter ();
@@ -511,6 +533,7 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_posted_msiapic_eoi ();irq_exit (); +__this_cpu_write (posted_msi_handler_active, false); set_irq_regs(old_regs); }#endif /* X86_POSTED_MSI */
drivers/iommu/intel/irq_remapping.c +4 -4
@@ -1309,17 +1309,17 @@ static struct irq_chip intel_ir_chip = {* irq_enter(); * handle_edge_irq() * irq_chip_ack_parent() -* irq_move_irq(); // No EOI +* intel_ack_posted_msi_irq(); // No EOI * handle_irq_event() * driver_handler() * handle_edge_irq() * irq_chip_ack_parent() -* irq_move_irq(); // No EOI +* intel_ack_posted_msi_irq(); // No EOI * handle_irq_event() * driver_handler() * handle_edge_irq() * irq_chip_ack_parent() -* irq_move_irq(); // No EOI +* intel_ack_posted_msi_irq(); // No EOI * handle_irq_event() * driver_handler() * apic_eoi()
@@ -1328,7 +1328,7 @@ static struct irq_chip intel_ir_chip = {*/ static struct irq_chip intel_ir_chip_post_msi = { .name ="INTEL-IR-POST" , - .irq_ack = irq_move_irq, + .irq_ack = intel_ack_posted_msi_irq, .irq_set_affinity = intel_ir_set_affinity, .irq_compose_msi_msg = intel_ir_compose_msi_msg, .irq_set_vcpu_affinity = intel_ir_set_vcpu_affinity,
Greg Kroah-Hartman
maintainerPATCH 292/567 iommu/mediatek: fix use-after-free on probe deferral
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit de83d4617f9fe059623e97acf7e1e10d209625b5 upstream.
The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers.
Fix this by keeping the references as expected while the iommu driver is bound.
--- drivers/iommu/mtk_iommu.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-)
drivers/iommu/mtk_iommu.c +18 -7
@@ -1213,16 +1213,19 @@ static int mtk_iommu_mm_dts_parse(struct }component_match_add (dev, match, component_compare_dev, &plarbdev->dev); -platform_device_put (plarbdev); } -if (!frst_avail_smicomm_node) -return -EINVAL ; +if (!frst_avail_smicomm_node) { + ret = -EINVAL ; + goto err_larbdev_put; + } pcommdev =of_find_device_by_node (frst_avail_smicomm_node);of_node_put (frst_avail_smicomm_node); -if (!pcommdev) -return -ENODEV ; +if (!pcommdev) { + ret = -ENODEV ; + goto err_larbdev_put; + } data->smicomm_dev = &pcommdev->dev; link = device_link_add(data->smicomm_dev, dev,
@@ -1230,7 +1233,8 @@ static int mtk_iommu_mm_dts_parse(structplatform_device_put (pcommdev);if (!link) {dev_err (dev,"Unable to link %s.\n" ,dev_name (data->smicomm_dev)); -return -EINVAL ; + ret = -EINVAL ; + goto err_larbdev_put; }return 0 ;
@@ -1402,8 +1406,12 @@ out_sysfs_remove:iommu_device_sysfs_remove (&data->iommu); out_list_del:list_del (&data->list); -if (MTK_IOMMU_IS_TYPE (data->plat_data,MTK_IOMMU_TYPE_MM )) +if (MTK_IOMMU_IS_TYPE (data->plat_data,MTK_IOMMU_TYPE_MM )) {device_link_remove (data->smicomm_dev, dev); + +for (i =0 ; i <MTK_LARB_NR_MAX ; i++) +put_device (data->larb_imu[i].dev); + } out_runtime_disable:pm_runtime_disable (dev);return ret;
@@ -1423,6 +1431,9 @@ static void mtk_iommu_remove(struct platif (MTK_IOMMU_IS_TYPE (data->plat_data,MTK_IOMMU_TYPE_MM )) {device_link_remove (data->smicomm_dev, &pdev->dev);component_master_del (&pdev->dev, &mtk_iommu_com_ops); + +for (i =0 ; i <MTK_LARB_NR_MAX ; i++) +put_device (data->larb_imu[i].dev); }pm_runtime_disable (&pdev->dev);for (i =0 ; i < data->plat_data->banks_num; i++) {
Greg Kroah-Hartman
maintainerPATCH 293/567 fuse: fix readahead reclaim deadlock
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joanne Koong <[email protected]>
commit bd5603eaae0aabf527bfb3ce1bb07e979ce5bd50 upstream.
Commit e26ee4efbc79 ("fuse: allocate ff->release_args only if release is needed") skips allocating ff->release_args if the server does not implement open. However in doing so, fuse_prepare_release() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuse_evict_inode() attempts to remove all folios associated with the inode from the page cache (truncate_inode_pages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim:
Quoted 1 line
Quoted 1 line
Quoted 1 line
stack_trace(1504735)
folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27
Fix this deadlock by allocating ff->release_args and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fuse_file_put() -> fuse_release_end()).
--- fs/fuse/file.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-)
fs/fuse/file.c +19 -7
@@ -109,7 +109,9 @@ static void fuse_file_put(struct fuse_fifuse_file_io_release (ff, ra->inode);if (!args) { -/* Do nothing when server does not implement 'open' */ +/* Do nothing when server does not implement 'opendir' */ + }else if (args->opcode ==FUSE_RELEASE && ff->fm->fc->no_open) { +fuse_release_end (ff->fm, args,0 ); }else if (sync) {fuse_simple_request (ff->fm, args);fuse_release_end (ff->fm, args,0 );
@@ -130,8 +132,17 @@ struct fuse_file *fuse_file_open(structstruct fuse_file *ff;int opcode = isdir ?FUSE_OPENDIR :FUSE_OPEN ;bool open = isdir ? !fc->no_opendir : !fc->no_open; +bool release = !isdir || open; - ff =fuse_file_alloc (fm, open); +/* +* ff->args->release_args still needs to be allocated (so we can hold an +* inode reference while there are pending inflight file operations when +* ->release() is called, see fuse_prepare_release()) even if +* fc->no_open is set else it becomes possible for reclaim to deadlock +* if while servicing the readahead request the server triggers reclaim +* and reclaim evicts the inode of the file being read ahead. +*/ + ff =fuse_file_alloc (fm, release);if (!ff)return ERR_PTR (-ENOMEM );
@@ -151,13 +162,14 @@ struct fuse_file *fuse_file_open(structfuse_file_free (ff);return ERR_PTR (err); }else { -/* No release needed */ -kfree (ff->args); - ff->args =NULL ; -if (isdir) +if (isdir) { +/* No release needed */ +kfree (ff->args); + ff->args =NULL ; fc->no_opendir =1 ; -else + }else { fc->no_open =1 ; + } } }
Greg Kroah-Hartman
maintainerPATCH 294/567 wifi: rtw88: limit indirect IO under powered off for RTL8822CS
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ping-Ke Shih <[email protected]>
[ Upstream commit f3ccdfda345ca9a624ea425840a926b8338c1e25 ]
The indirect IO is necessary for RTL8822CS, but not necessary for other chips. Otherwiese, it throws errors and becomes unusable.
rtw88_8723cs mmc1:0001:1: WOW Firmware version 11.0.0, H2C version 0 rtw88_8723cs mmc1:0001:1: Firmware version 11.0.0, H2C version 0 rtw88_8723cs mmc1:0001:1: sdio read32 failed (0xf0): -110 rtw88_8723cs mmc1:0001:1: sdio write8 failed (0x1c): -110 rtw88_8723cs mmc1:0001:1: sdio read32 failed (0xf0): -110
By vendor driver, only RTL8822CS and RTL8822ES need indirect IO, but RTL8822ES isn't supported yet. Therefore, limit it to RTL8822CS only.
--- drivers/net/wireless/realtek/rtw88/sdio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/wireless/realtek/rtw88/sdio.c +3 -1
@@ -144,8 +144,10 @@ static u32 rtw_sdio_to_io_address(struct rtw_dev *rtwdev, u32 addr,static bool rtw_sdio_use_direct_io (struct rtw_dev *rtwdev,u32 addr) { +bool might_indirect_under_power_off = rtwdev->chip->id ==RTW_CHIP_TYPE_8822C ; +if (!test_bit (RTW_FLAG_POWERON , rtwdev->flags) && - !rtw_sdio_is_bus_addr (addr)) + !rtw_sdio_is_bus_addr (addr) && might_indirect_under_power_off)return false; return !rtw_sdio_is_sdio30_supported(rtwdev) ||
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 295/567 wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cu_tx_fill_desc()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Morning Star <[email protected]>
[ Upstream commit dd39edb445f07400e748da967a07d5dca5c5f96e ]
TID getting from ieee80211_get_tid() might be out of range of array size of sta_entry->tids[], so check TID is less than MAX_TID_COUNT. Othwerwise, UBSAN warn:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtl_tid_data [9]'
--- drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c +2 -1
@@ -511,7 +511,8 @@ void rtl92cu_tx_fill_desc(struct ieee80211_hw *hw,if (sta) { sta_entry = (struct rtl_sta_info *)sta->drv_priv; tid =ieee80211_get_tid (hdr); - agg_state = sta_entry->tids[tid].agg.agg_state; +if (tid <MAX_TID_COUNT ) + agg_state = sta_entry->tids[tid].agg.agg_state; ampdu_density = sta->deflink.ht_cap.ampdu_density; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 296/567 wifi: cfg80211: sme: store capped length in __cfg80211_connect_result()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 2b77b9551d1184cb5af8271ff350e6e2c1b3db0d ]
The QGenie AI code review tool says we should store the capped length to wdev->u.client.ssid_len. The AI is correct.
--- net/wireless/sme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/wireless/sme.c +1 -1
@@ -913,7 +913,7 @@ void __cfg80211_connect_result(struct net_device *dev, ssid_len =min (ssid->datalen,IEEE80211_MAX_SSID_LEN );memcpy (wdev->u.client.ssid, ssid->data, ssid_len); - wdev->u.client.ssid_len = ssid->datalen; + wdev->u.client.ssid_len = ssid_len;break ; }rcu_read_unlock ();
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 297/567 wifi: mac80211: do not use old MBSSID elements
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aloka Dixit <[email protected]>
[ Upstream commit a519be2f5d958c5804f2cfd68f1f384291271fab ]
When userspace brings down and deletes a non-transmitted profile, it is expected to send a new updated Beacon template for the transmitted profile of that multiple BSSID (MBSSID) group which does not include the removed profile in MBSSID element. This update comes via NL80211_CMD_SET_BEACON.
Such updates work well as long as the group continues to have at least one non-transmitted profile as NL80211_ATTR_MBSSID_ELEMS is included in the new Beacon template.
But when the last non-trasmitted profile is removed, it still gets included in Beacon templates sent to driver. This happens because when no MBSSID elements are sent by the userspace, ieee80211_assign_beacon() ends up using the element stored from earlier Beacon template.
Do not copy old MBSSID elements, instead userspace should always include these when applicable.
--- net/mac80211/cfg.c | 10 ---------- 1 file changed, 10 deletions(-)
net/mac80211/cfg.c +0 -10
@@ -1140,7 +1140,6 @@ ieee80211_assign_beacon(struct ieee80211_sub_if_data *sdata, size =sizeof (*new) + new_head_len + new_tail_len; -/* new or old multiple BSSID elements? */ if (params->mbssid_ies) { mbssid = params->mbssid_ies; size +=struct_size (new->mbssid_ies, elem, mbssid->cnt);
@@ -1150,15 +1149,6 @@ ieee80211_assign_beacon(struct ieee80211_sub_if_data *sdata, } size +=ieee80211_get_mbssid_beacon_len (mbssid, rnr, mbssid->cnt); - }else if (old && old->mbssid_ies) { - mbssid = old->mbssid_ies; - size +=struct_size (new->mbssid_ies, elem, mbssid->cnt); -if (old && old->rnr_ies) { - rnr = old->rnr_ies; - size +=struct_size (new->rnr_ies, elem, rnr->cnt); - } - size +=ieee80211_get_mbssid_beacon_len (mbssid, rnr, - mbssid->cnt); } new =kzalloc (size,GFP_KERNEL );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 298/567 i40e: fix scheduling in set_rx_mode
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Przemyslaw Korba <[email protected]>
[ Upstream commit be43abc5514167cc129a8d8e9727b89b8e1d9719 ]
Add service task schedule to set_rx_mode.
In some cases there are error messages printed out in PTP application (ptp4l):
ptp4l[13848.762]: port 1 (ens2f3np3): received SYNC without timestamp ptp4l[13848.825]: port 1 (ens2f3np3): received SYNC without timestamp ptp4l[13848.887]: port 1 (ens2f3np3): received SYNC without timestamp
This happens when service task would not run immediately after set_rx_mode, and we need it for setup tasks. This service task checks, if PTP RX packets are hung in firmware, and propagate correct settings such as multicast address for IEEE 1588 Precision Time Protocol. RX timestamping depends on some of these filters set. Bug happens only with high PTP packets frequency incoming, and not every run since sometimes service task is being ran from a different place immediately after starting ptp4l.
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/intel/i40e/i40e_main.c +1 -0
@@ -2256,6 +2256,7 @@ static void i40e_set_rx_mode(struct net_device *netdev) vsi->flags |=I40E_VSI_FLAG_FILTER_CHANGED ;set_bit (__I40E_MACVLAN_SYNC_PENDING, vsi->back->state); } +i40e_service_event_schedule (vsi->back); }/**
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 299/567 i40e: validate ring_len parameter against hardware-specific values
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gregory Herrero <[email protected]>
[ Upstream commit 69942834215323cd9131db557091b4dec43f19c5 ]
The maximum number of descriptors supported by the hardware is hardware-dependent and can be retrieved using i40e_get_max_num_descriptors(). Move this function to a shared header and use it when checking for valid ring_len parameter rather than using hardcoded value.
By fixing an over-acceptance issue, behavior change could be seen where ring_len could now be rejected while configuring rx and tx queues if its size is larger than the hardware-dependent maximum number of descriptors.
--- drivers/net/ethernet/intel/i40e/i40e.h | 11 +++++++++++ drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 12 ------------ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 4 ++-- 3 files changed, 13 insertions(+), 14 deletions(-)
drivers/net/ethernet/intel/i40e/i40e.h +11 -0
@@ -1415,4 +1415,15 @@ static inline struct i40e_veb *i40e_pf_get_main_veb(struct i40e_pf *pf) return (pf->lan_veb != I40E_NO_VEB) ? pf->veb[pf->lan_veb] : NULL; } +static inline u32 i40e_get_max_num_descriptors (const struct i40e_pf *pf) +{ +const struct i40e_hw *hw = &pf->hw; + +switch (hw->mac.type) { +case I40E_MAC_XL710 : +return I40E_MAX_NUM_DESCRIPTORS_XL710 ; +default : +return I40E_MAX_NUM_DESCRIPTORS ; + } +}#endif /* _I40E_H_ */
drivers/net/ethernet/intel/i40e/i40e_ethtool.c +0 -12
@@ -2010,18 +2010,6 @@ static void i40e_get_drvinfo(struct net_device *netdev, drvinfo->n_priv_flags +=I40E_GL_PRIV_FLAGS_STR_LEN ; } -static u32 i40e_get_max_num_descriptors (struct i40e_pf *pf) -{ -struct i40e_hw *hw = &pf->hw; - -switch (hw->mac.type) { -case I40E_MAC_XL710 : -return I40E_MAX_NUM_DESCRIPTORS_XL710 ; -default : -return I40E_MAX_NUM_DESCRIPTORS ; - } -} - static void i40e_get_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring, struct kernel_ethtool_ringparam *kernel_ring,
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +2 -2
@@ -656,7 +656,7 @@ static int i40e_config_vsi_tx_queue(struct i40e_vf *vf, u16 vsi_id,/* ring_len has to be multiple of 8 */ if (!IS_ALIGNED (info->ring_len,8 ) || - info->ring_len >I40E_MAX_NUM_DESCRIPTORS_XL710 ) { + info->ring_len >i40e_get_max_num_descriptors (pf)) { ret = -EINVAL ; goto error_context; }
@@ -726,7 +726,7 @@ static int i40e_config_vsi_rx_queue(struct i40e_vf *vf, u16 vsi_id,/* ring_len has to be multiple of 32 */ if (!IS_ALIGNED (info->ring_len,32 ) || - info->ring_len >I40E_MAX_NUM_DESCRIPTORS_XL710 ) { + info->ring_len >i40e_get_max_num_descriptors (pf)) { ret = -EINVAL ; goto error_param; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 300/567 iavf: fix off-by-one issues in iavf_config_rss_reg()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kohei Enju <[email protected]>
[ Upstream commit 6daa2893f323981c7894c68440823326e93a7d61 ]
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were:
i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4where rss_{key,lut}_size / 4 is the number of dwords, so the last valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <= accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed the bounds.
[1] KASAN splat about rss_key_size off-by-one
BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800
Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: iavf iavf_watchdog_task
Call Trace:
<TASK>
dump_stack_lvl+0x6f/0xb0
print_report+0x170/0x4f3
kasan_report+0xe1/0x1a0
iavf_config_rss+0x619/0x800
iavf_watchdog_task+0x2be7/0x3230
process_one_work+0x7fd/0x1420
worker_thread+0x4d1/0xd40
kthread+0x344/0x660
ret_from_fork+0x249/0x320
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 63:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x7f/0x90
__kmalloc_noprof+0x246/0x6f0
iavf_watchdog_task+0x28fc/0x3230
process_one_work+0x7fd/0x1420
worker_thread+0x4d1/0xd40
kthread+0x344/0x660
ret_from_fork+0x249/0x320
ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes to the right of
allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50
flags: 0x200000000000000(node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
>ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
^
ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc--- drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/iavf/iavf_main.c +2 -2
@@ -1718,11 +1718,11 @@ static int iavf_config_rss_reg(struct iavf_adapter *adapter)u16 i; dw = (u32 *)adapter->rss_key; -for (i =0 ; i <= adapter->rss_key_size /4 ; i++) +for (i =0 ; i < adapter->rss_key_size /4 ; i++)wr32 (hw,IAVF_VFQF_HKEY (i), dw[i]); dw = (u32 *)adapter->rss_lut; -for (i =0 ; i <= adapter->rss_lut_size /4 ; i++) +for (i =0 ; i < adapter->rss_lut_size /4 ; i++)wr32 (hw,IAVF_VFQF_HLUT (i), dw[i]);iavf_flush (hw);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 301/567 idpf: reduce mbx_task schedule delay to 300us
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Vazquez <[email protected]>
[ Upstream commit b3d6bbae1d6d5638a4ab702ab195476787cde857 ]
During the IDPF init phase, the mailbox runs in poll mode until it is configured to properly handle interrupts. The previous delay of 300ms is excessively long for the mailbox polling mechanism, which causes a slow initialization of ~2s:
echo 0000:06:12.4 > /sys/bus/pci/drivers/idpf/bind
[ 52.444239] idpf 0000:06:12.4: enabling device (0000 -> 0002) [ 52.485005] idpf 0000:06:12.4: Device HW Reset initiated [ 54.177181] idpf 0000:06:12.4: PTP init failed, err=-EOPNOTSUPP [ 54.206177] idpf 0000:06:12.4: Minimum RX descriptor support not provided, using the default [ 54.206182] idpf 0000:06:12.4: Minimum TX descriptor support not provided, using the default
Changing the delay to 300us avoids the delays during the initial mailbox transactions, making the init phase much faster:
[ 83.342590] idpf 0000:06:12.4: enabling device (0000 -> 0002) [ 83.384402] idpf 0000:06:12.4: Device HW Reset initiated [ 83.518323] idpf 0000:06:12.4: PTP init failed, err=-EOPNOTSUPP [ 83.547430] idpf 0000:06:12.4: Minimum RX descriptor support not provided, using the default [ 83.547435] idpf 0000:06:12.4: Minimum TX descriptor support not provided, using the default
--- drivers/net/ethernet/intel/idpf/idpf_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/idpf/idpf_lib.c +1 -1
@@ -1214,7 +1214,7 @@ void idpf_mbx_task(struct work_struct *work)idpf_mb_irq_enable (adapter); else queue_delayed_work(adapter->mbx_wq, &adapter->mbx_task, - msecs_to_jiffies(300)); + usecs_to_jiffies(300));idpf_recv_mb_msg (adapter); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 302/567 crypto: seqiv - Do not use req->iv after crypto_aead_encrypt
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
[ Upstream commit 50fdb78b7c0bcc550910ef69c0984e751cac72fa ]
As soon as crypto_aead_encrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.
Instead of checking req->iv against info, create a new variable unaligned_info and use it for that purpose instead.
--- crypto/seqiv.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
crypto/seqiv.c +5 -3
@@ -50,6 +50,7 @@ static int seqiv_aead_encrypt(struct aead_request *req)struct aead_geniv_ctx *ctx =crypto_aead_ctx (geniv);struct aead_request *subreq =aead_request_ctx (req);crypto_completion_t compl; +bool unaligned_info;void *data;u8 *info;unsigned int ivsize =8 ;
@@ -79,8 +80,9 @@ static int seqiv_aead_encrypt(struct aead_request *req)return err; } -if (unlikely (!IS_ALIGNED ((unsigned long )info, -crypto_aead_alignmask (geniv) +1 ))) { + unaligned_info = !IS_ALIGNED ((unsigned long )info, +crypto_aead_alignmask (geniv) +1 ); +if (unlikely (unaligned_info)) { info =kmemdup (req->iv, ivsize, req->base.flags &CRYPTO_TFM_REQ_MAY_SLEEP ?GFP_KERNEL :GFP_ATOMIC );
@@ -100,7 +102,7 @@ static int seqiv_aead_encrypt(struct aead_request *req)scatterwalk_map_and_copy (info, req->dst, req->assoclen, ivsize,1 ); err =crypto_aead_encrypt (subreq); -if (unlikely (info != req->iv)) +if (unlikely (unaligned_info))seqiv_aead_encrypt_complete2 (req, err);return err; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 303/567 Bluetooth: btusb: revert use of devm_kzalloc in btusb
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raphael Pinsonneault-Thibeault <[email protected]>
[ Upstream commit 252714f1e8bdd542025b16321c790458014d6880 ]
This reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc in btusb.c file").
In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. This ties the lifetime of all the btusb data to the binding of a driver to one interface, INTF. In a driver that binds to other interfaces, ISOC and DIAG, this is an accident waiting to happen.
The issue is revealed in btusb_disconnect(), where calling usb_driver_release_interface(&btusb_driver, data->intf) will have devm free the data that is also being used by the other interfaces of the driver that may not be released yet.
To fix this, revert the use of devm and go back to freeing memory explicitly.
--- drivers/bluetooth/btusb.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/bluetooth/btusb.c +9 -3
@@ -3835,7 +3835,7 @@ static int btusb_probe(struct usb_interface *intf,return -ENODEV ; } - data =devm_kzalloc (&intf->dev,sizeof (*data),GFP_KERNEL ); + data =kzalloc (sizeof (*data),GFP_KERNEL );if (!data)return -ENOMEM ;
@@ -3858,8 +3858,10 @@ static int btusb_probe(struct usb_interface *intf, } } -if (!data->intr_ep || !data->bulk_tx_ep || !data->bulk_rx_ep) +if (!data->intr_ep || !data->bulk_tx_ep || !data->bulk_rx_ep) { +kfree (data);return -ENODEV ; + }if (id->driver_info &BTUSB_AMP ) { data->cmdreq_type =USB_TYPE_CLASS |0x01 ;
@@ -3914,8 +3916,10 @@ static int btusb_probe(struct usb_interface *intf, data->recv_acl = hci_recv_frame; hdev =hci_alloc_dev_priv (priv_size); -if (!hdev) +if (!hdev) { +kfree (data);return -ENOMEM ; + } hdev->bus =HCI_USB ;hci_set_drvdata (hdev, data);
@@ -4187,6 +4191,7 @@ static int btusb_probe(struct usb_interface *intf,if (data->reset_gpio)gpiod_put (data->reset_gpio);hci_free_dev (hdev); +kfree (data);return err; }
@@ -4235,6 +4240,7 @@ static void btusb_disconnect(struct usb_interface *intf) }hci_free_dev (hdev); +kfree (data); }#ifdef CONFIG_PM
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 304/567 net: mdio: aspeed: add dummy read to avoid read-after-write issue
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacky Chou <[email protected]>
[ Upstream commit d1a1a4bade4b20c0858d0b2f81d2611de055f675 ]
The Aspeed MDIO controller may return incorrect data when a read operation follows immediately after a write. Due to a controller bug, the subsequent read can latch stale data, causing the polling logic to terminate earlier than expected.
To work around this hardware issue, insert a dummy read after each write operation. This ensures that the next actual read returns the correct data and prevents premature polling exit.
This workaround has been verified to stabilize MDIO transactions on affected Aspeed platforms.
--- drivers/net/mdio/mdio-aspeed.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/mdio/mdio-aspeed.c +7 -0
@@ -63,6 +63,13 @@ static int aspeed_mdio_op(struct mii_bus *bus, u8 st, u8 op, u8 phyad, u8 regad,iowrite32 (ctrl, ctx->base +ASPEED_MDIO_CTRL ); +/* Workaround for read-after-write issue. +* The controller may return stale data if a read follows immediately +* after a write. A dummy read forces the hardware to update its +* internal state, ensuring that the next real read returns correct data. +*/ +ioread32 (ctx->base +ASPEED_MDIO_CTRL ); + return readl_poll_timeout(ctx->base + ASPEED_MDIO_CTRL, ctrl, !(ctrl & ASPEED_MDIO_CTRL_FIRE), ASPEED_MDIO_INTERVAL_US,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 305/567 net: openvswitch: Avoid needlessly taking the RTNL on vport destroy
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toke Høiland-Jørgensen <[email protected]>
[ Upstream commit 5498227676303e3ffa9a3a46214af96bc3e81314 ]
The openvswitch teardown code will immediately call ovs_netdev_detach_dev() in response to a NETDEV_UNREGISTER notification. It will then start the dp_notify_work workqueue, which will later end up calling the vport destroy() callback. This callback takes the RTNL to do another ovs_netdev_detach_port(), which in this case is unnecessary. This causes extra pressure on the RTNL, in some cases leading to "unregister_netdevice: waiting for XX to become free" warnings on teardown.
We can straight-forwardly avoid the extra RTNL lock acquisition by checking the device flags before taking the lock, and skip the locking altogether if the IFF_OVS_DATAPATH flag has already been unset.
--- net/openvswitch/vport-netdev.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
net/openvswitch/vport-netdev.c +13 -4
@@ -160,10 +160,19 @@ void ovs_netdev_detach_dev(struct vport *vport)static void netdev_destroy (struct vport *vport) { -rtnl_lock (); -if (netif_is_ovs_port (vport->dev)) -ovs_netdev_detach_dev (vport); -rtnl_unlock (); +/* When called from ovs_db_notify_wq() after a dp_device_event(), the +* port has already been detached, so we can avoid taking the RTNL by +* checking this first. +*/ +if (netif_is_ovs_port (vport->dev)) { +rtnl_lock (); +/* Check again while holding the lock to ensure we don't race +* with the netdev notifier and detach twice. +*/ +if (netif_is_ovs_port (vport->dev)) +ovs_netdev_detach_dev (vport); +rtnl_unlock (); + }call_rcu (&vport->rcu, vport_netdev_free); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 306/567 ip6_gre: make ip6gre_header() robust
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit db5b4e39c4e63700c68a7e65fc4e1f1375273476 ]
Over the years, syzbot found many ways to crash the kernel in ip6gre_header() [1].
This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len
In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ip6gre device.
[1]
skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0
------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! <TASK> skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
--- net/ipv6/ip6_gre.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
net/ipv6/ip6_gre.c +8 -1
@@ -1395,9 +1395,16 @@ static int ip6gre_header(struct sk_buff *skb, struct net_device *dev, {struct ip6_tnl *t =netdev_priv (dev);struct ipv6hdr *ipv6h; +int needed;__be16 *p; - ipv6h =skb_push (skb, t->hlen +sizeof (*ipv6h)); + needed = t->hlen +sizeof (*ipv6h); +if (skb_headroom (skb) < needed && +pskb_expand_head (skb,HH_DATA_ALIGN (needed -skb_headroom (skb)), +0 ,GFP_ATOMIC )) +return -needed; + + ipv6h =skb_push (skb, needed);ip6_flow_hdr (ipv6h,0 ,ip6_make_flowlabel (dev_net (dev), skb, t->fl.u.ip6.flowlabel, true, &t->fl.u.ip6));
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 307/567 platform/mellanox: mlxbf-pmc: Remove trailing whitespaces from event names
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shravan Kumar Ramani <[email protected]>
[ Upstream commit f13bce715d1600698310a4a7832f6a52499d5395 ]
Some event names have trailing whitespaces at the end which causes programming of counters using the name for these specific events to fail and hence need to be removed.
--- drivers/platform/mellanox/mlxbf-pmc.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/platform/mellanox/mlxbf-pmc.c +7 -7
@@ -796,18 +796,18 @@ static const struct mlxbf_pmc_events mlxbf_pmc_llt_miss_events[] = { {11, "GDC_MISS_MACHINE_CHI_TXDAT"}, {12, "GDC_MISS_MACHINE_CHI_RXDAT"}, {13, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC0_0"}, - {14, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC0_1 "}, + {14, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC0_1"}, {15, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC0_2"}, - {16, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC0_3 "}, - {17, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_0 "}, - {18, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_1 "}, - {19, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_2 "}, - {20, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_3 "}, + {16, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC0_3"}, + {17, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_0"}, + {18, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_1"}, + {19, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_2"}, + {20, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC1_3"}, {21, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE0_0"}, {22, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE0_1"}, {23, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE0_2"}, {24, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE0_3"}, - {25, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE1_0 "}, + {25, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE1_0"}, {26, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE1_1"}, {27, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE1_2"}, {28, "GDC_MISS_MACHINE_G_FIFO_FF_EXEC_DONE1_3"},
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 308/567 platform/x86: msi-laptop: add missing sysfs_remove_group()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Fourier <[email protected]>
[ Upstream commit 1461209cf813b6ee6d40f29b96b544587df6d2b1 ]
A sysfs group is created in msi_init() when old_ec_model is enabled, but never removed. Remove the msipf_old_attribute_group in that case.
--- drivers/platform/x86/msi-laptop.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/platform/x86/msi-laptop.c +3 -0
@@ -1130,6 +1130,9 @@ static void __exit msi_cleanup(void)sysfs_remove_group (&msipf_device->dev.kobj, &msipf_attribute_group);if (!quirks->old_ec_model && threeg_exists)device_remove_file (&msipf_device->dev, &dev_attr_threeg); +if (quirks->old_ec_model) +sysfs_remove_group (&msipf_device->dev.kobj, + &msipf_old_attribute_group);platform_device_unregister (msipf_device);platform_driver_unregister (&msipf_driver);backlight_device_unregister (msibl_device);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 309/567 platform/x86: ibm_rtl: fix EBDA signature search pointer arithmetic
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junrui Luo <[email protected]>
[ Upstream commit 15dd100349b8526cbdf2de0ce3e72e700eb6c208 ]
The ibm_rtl_init() function searches for the signature but has a pointer arithmetic error. The loop counter suggests searching at 4-byte intervals but the implementation only advances by 1 byte per iteration.
Fix by properly advancing the pointer by sizeof(unsigned int) bytes each iteration.
--- drivers/platform/x86/ibm_rtl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/x86/ibm_rtl.c +1 -1
@@ -273,7 +273,7 @@ static int __init ibm_rtl_init(void) {/* search for the _RTL_ signature at the start of the table */ for (i =0 ; i < ebda_size/sizeof (unsigned int ); i++) {struct ibm_rtl_table __iomem * tmp; - tmp = (struct ibm_rtl_table __iomem *) (ebda_map+i); + tmp = (struct ibm_rtl_table __iomem *) (ebda_map + i*sizeof (unsigned int ));if ((readq (&tmp->signature) &RTL_MASK ) ==RTL_SIGNATURE ) {phys_addr_t addr;unsigned int plen;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 310/567 team: fix check for port enabled in team_queue_override_port_prio_changed()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Pirko <[email protected]>
[ Upstream commit 932ac51d9953eaf77a1252f79b656d4ca86163c6 ]
There has been a syzkaller bug reported recently with the following trace:
list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)
------------[ cut here ]------------ kernel BUG at lib/list_debug.c:59! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The problem is in this flow:
1) Port is enabled, queue_id != 0, in qom_list
2) Port gets disabled
-> team_port_disable()
-> team_queue_override_port_del()
-> del (removed from list)
3) Port is disabled, queue_id != 0, not in any list
4) Priority changes
-> team_queue_override_port_prio_changed()
-> checks: port disabled && queue_id != 0
-> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed() so it returns early if port is not enabled.
--- drivers/net/team/team_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/team/team_core.c +1 -1
@@ -877,7 +877,7 @@ static void __team_queue_override_enabled_check(struct team *team)static void team_queue_override_port_prio_changed (struct team *team,struct team_port *port) { -if (!port->queue_id ||team_port_enabled (port)) +if (!port->queue_id || !team_port_enabled (port))return ;__team_queue_override_port_del (team, port);__team_queue_override_port_add (team, port);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 311/567 net: dsa: fix missing put_device() in dsa_tree_find_first_conduit()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit a9f96dc59b4a50ffbf86158f315e115969172d48 ]
of_find_net_device_by_node() searches net devices by their /sys/class/net/, entry. It is documented in its kernel-doc that:
* If successful, returns a pointer to the net_device with the embedded
* struct device refcount incremented by one, or NULL on failure. The
* refcount must be dropped when done with the net_device.
We are missing a put_device(&conduit->dev) which we could place at the end of dsa_tree_find_first_conduit(). But to explain why calling put_device() right away is safe is the same as to explain why the chosen solution is different.
The code is very poorly split: dsa_tree_find_first_conduit() was first introduced in commit 95f510d0b792 ("net: dsa: allow the DSA master to be seen and changed through rtnetlink") but was first used several commits later, in commit acc43b7bf52a ("net: dsa: allow masters to join a LAG").
Assume there is a switch with 2 CPU ports and 2 conduits, eno2 and eno3. When we create a LAG (bonding or team device) and place eno2 and eno3 beneath it, we create a 3rd conduit (the LAG device itself), but this is slightly different than the first two.
Namely, the cpu_dp->conduit pointer of the CPU ports does not change, and remains pointing towards the physical Ethernet controllers which are now LAG ports. Only 2 things change:
- the LAG device has a dev->dsa_ptr which marks it as a DSA conduit
- dsa_port_to_conduit(user port) finds the LAG and not the physical conduit, because of the dp->cpu_port_in_lag bit being set.
When the LAG device is destroyed, dsa_tree_migrate_ports_from_lag_conduit() is called and this is where dsa_tree_find_first_conduit() kicks in.
This is the logical mistake and the reason why introducing code in one patch and using it from another is bad practice. I didn't realize that I don't have to call of_find_net_device_by_node() again; the cpu_dp->conduit association was never undone, and is still available for direct (re)use. There's only one concern - maybe the conduit disappeared in the meantime, but the netdev_hold() call we made during dsa_port_parse_cpu() (see previous change) ensures that this was not the case.
Therefore, fixing the code means reimplementing it in the simplest way.
I am blaming the time of use, since this is what "git blame" would show if we were to monitor for the conduit's kobject's refcount remaining elevated instead of being freed.
Tested on the NXP LS1028A, using the steps from Documentation/networking/dsa/configuration.rst section "Affinity of user ports to CPU ports", followed by (extra prints added by me):
$ ip link del bond0 mscc_felix 0000:00:00.5 swp3: Link is Down bond0 (unregistering): (slave eno2): Releasing backup interface fsl_enetc 0000:00:00.2 eno2: Link is Down mscc_felix 0000:00:00.5 swp0: bond0 disappeared, migrating to eno2 mscc_felix 0000:00:00.5 swp1: bond0 disappeared, migrating to eno2 mscc_felix 0000:00:00.5 swp2: bond0 disappeared, migrating to eno2 mscc_felix 0000:00:00.5 swp3: bond0 disappeared, migrating to eno2
--- net/dsa/dsa.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
net/dsa/dsa.c +1 -7
@@ -366,16 +366,10 @@ static struct dsa_port *dsa_tree_find_first_cpu(struct dsa_switch_tree *dst)struct net_device *dsa_tree_find_first_conduit (struct dsa_switch_tree *dst) { -struct device_node *ethernet; -struct net_device *conduit;struct dsa_port *cpu_dp; cpu_dp =dsa_tree_find_first_cpu (dst); - ethernet =of_parse_phandle (cpu_dp->dn,"ethernet" ,0 ); - conduit =of_find_net_device_by_node (ethernet); -of_node_put (ethernet); - -return conduit; +return cpu_dp->conduit; }/* Assign the default CPU port (the first one in the tree) to all ports of the
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 312/567 amd-xgbe: reset retries and mode on RX adapt failures
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raju Rangoju <[email protected]>
[ Upstream commit df60c332caf95d70f967aeace826e7e2f0847361 ]
During the stress tests, early RX adaptation handshakes can fail, such as missing the RX_ADAPT ACK or not receiving a coefficient update before block lock is established. Continuing to retry RX adaptation in this state is often ineffective if the current mode selection is not viable.
Resetting the RX adaptation retry counter when an RX_ADAPT request fails to receive ACK or a coefficient update prior to block lock, and clearing mode_set so the next bring-up performs a fresh mode selection rather than looping on a likely invalid configuration.
--- drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c +2 -0
@@ -2036,6 +2036,7 @@ static void xgbe_set_rx_adap_mode(struct xgbe_prv_data *pdata, {if (pdata->rx_adapt_retries++ >=MAX_RX_ADAPT_RETRIES ) { pdata->rx_adapt_retries =0 ; + pdata->mode_set = false;return ; }
@@ -2082,6 +2083,7 @@ static void xgbe_rx_adaptation(struct xgbe_prv_data *pdata)*/ netif_dbg (pdata, link, pdata->netdev,"Block_lock done" ); pdata->rx_adapt_done = true; + pdata->rx_adapt_retries =0 ; pdata->mode_set = false;return ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 313/567 net: usb: rtl8150: fix memory leak on usb_submit_urb() failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepakkumar Karn <[email protected]>
[ Upstream commit 12cab1191d9890097171156d06bfa8d31f1e39c8 ]
In async_set_registers(), when usb_submit_urb() fails, the allocated
async_req structure and URB are not freed, causing a memory leak.
The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.
Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails.
--- drivers/net/usb/rtl8150.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/usb/rtl8150.c +2 -0
@@ -211,6 +211,8 @@ static int async_set_registers(rtl8150_t *dev, u16 indx, u16 size, u16 reg)if (res == -ENODEV )netif_device_detach (dev->netdev);dev_err (&dev->udev->dev,"%s failed with %d\n" , __func__, res); +kfree (req); +usb_free_urb (async_urb); }return res; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 314/567 selftests: net: fix "buffer overflow detected" for tap.c
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alice C. Munduruca <[email protected]>
[ Upstream commit 472c5dd6b95c02b3e5d7395acf542150e91165e7 ]
When the selftest 'tap.c' is compiled with '-D_FORTIFY_SOURCE=3', the strcpy() in rtattr_add_strsz() is replaced with a checked version which causes the test to consistently fail when compiled with toolchains for which this option is enabled by default.
TAP version 13
1..3
# Starting 3 tests from 1 test cases.
# RUN tap.test_packet_valid_udp_gso ...
*** buffer overflow detected ***: terminated
# test_packet_valid_udp_gso: Test terminated by assertion
# FAIL tap.test_packet_valid_udp_gso
not ok 1 tap.test_packet_valid_udp_gso
# RUN tap.test_packet_valid_udp_csum ...
*** buffer overflow detected ***: terminated
# test_packet_valid_udp_csum: Test terminated by assertion
# FAIL tap.test_packet_valid_udp_csum
not ok 2 tap.test_packet_valid_udp_csum
# RUN tap.test_packet_crash_tap_invalid_eth_proto ...
*** buffer overflow detected ***: terminated
# test_packet_crash_tap_invalid_eth_proto: Test terminated by assertion
# FAIL tap.test_packet_crash_tap_invalid_eth_proto
not ok 3 tap.test_packet_crash_tap_invalid_eth_proto
# FAILED: 0 / 3 tests passed.
# Totals: pass:0 fail:3 xfail:0 xpass:0 skip:0 error:0
A buffer overflow is detected by the fortified glibc __strcpy_chk() since the __builtin_object_size() of RTA_DATA(rta) is incorrectly reported as 1, even though there is ample space in its bounding buffer req.
Additionally, given that IFLA_IFNAME also expects a null-terminated string, callers of rtaddr_add_str{,sz}() could simply use the rtaddr_add_strsz() variant. (which has been renamed to remove the trailing sz) memset() has been used for this function since it is unchecked and thus circumvents the issue discussed in the previous paragraph.
--- tools/testing/selftests/net/tap.c | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
tools/testing/selftests/net/tap.c +5 -11
@@ -56,18 +56,12 @@ static void rtattr_end(struct nlmsghdr *nh, struct rtattr *attr)static struct rtattr *rtattr_add_str (struct nlmsghdr *nh,unsigned short type,const char *s) { -struct rtattr *rta =rtattr_add (nh, type,strlen (s)); +unsigned int strsz =strlen (s) +1 ; +struct rtattr *rta; -memcpy (RTA_DATA (rta), s,strlen (s)); -return rta; -} - -static struct rtattr *rtattr_add_strsz (struct nlmsghdr *nh,unsigned short type, -const char *s) -{ -struct rtattr *rta =rtattr_add (nh, type,strlen (s) +1 ); + rta =rtattr_add (nh, type, strsz); -strcpy (RTA_DATA (rta), s); +memcpy (RTA_DATA (rta), s, strsz);return rta; }
@@ -119,7 +113,7 @@ static int dev_create(const char *dev, const char *link_type, link_info =rtattr_begin (&req.nh,IFLA_LINKINFO ); -rtattr_add_strsz (&req.nh,IFLA_INFO_KIND , link_type); +rtattr_add_str (&req.nh,IFLA_INFO_KIND , link_type);if (fill_info_data) { info_data =rtattr_begin (&req.nh,IFLA_INFO_DATA );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 315/567 smc91x: fix broken irq-context in PREEMPT_RT
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yeoreum Yun <[email protected]>
[ Upstream commit 6402078bd9d1ed46e79465e1faaa42e3458f8a33 ]
When smc91x.c is built with PREEMPT_RT, the following splat occurs in FVP_RevC:
[ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000
[ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106]
[ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work
[ 13.062266] C
** replaying previous printk message **
[ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}
[ 13.062353] Hardware name: , BIOS
[ 13.062382] Workqueue: mld mld_ifc_work
[ 13.062469] Call trace:
[ 13.062494] show_stack+0x24/0x40 (C)
[ 13.062602] __dump_stack+0x28/0x48
[ 13.062710] dump_stack_lvl+0x7c/0xb0
[ 13.062818] dump_stack+0x18/0x34
[ 13.062926] process_scheduled_works+0x294/0x450
[ 13.063043] worker_thread+0x260/0x3d8
[ 13.063124] kthread+0x1c4/0x228
[ 13.063235] ret_from_fork+0x10/0x20This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,
but smc_special_unlock() does not restore IRQs on PREEMPT_RT.
The reason is that smc_special_unlock() calls spin_unlock_irqrestore(),
and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invokercu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero.
To address this issue, replace smc_special_trylock() with spin_trylock_irqsave().
--- drivers/net/ethernet/smsc/smc91x.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
drivers/net/ethernet/smsc/smc91x.c +1 -9
@@ -516,15 +516,7 @@ static inline void smc_rcv(struct net_device *dev)* any other concurrent access and C would always interrupt B. But life * isn't that easy in a SMP world... */ -#define smc_special_trylock (lock, flags) \ -({ \ - int __ret; \ - local_irq_save(flags); \ - __ret = spin_trylock(lock); \ - if (!__ret) \ - local_irq_restore(flags); \ - __ret; \ -}) +#define smc_special_trylock (lock, flags) spin_trylock_irqsave(lock, flags)#define smc_special_lock (lock, flags) spin_lock_irqsave(lock, flags)#define smc_special_unlock (lock, flags) spin_unlock_irqrestore(lock, flags)#else
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 316/567 genalloc.h: fix htmldocs warning
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Morton <[email protected]>
[ Upstream commit 5393802c94e0ab1295c04c94c57bcb00222d4674 ]
WARNING: include/linux/genalloc.h:52 function parameter 'start_addr' not described in 'genpool_algo_t'
--- include/linux/genalloc.h | 1 + 1 file changed, 1 insertion(+)
include/linux/genalloc.h +1 -0
@@ -44,6 +44,7 @@ struct gen_pool;* @nr: The number of zeroed bits we're looking for * @data: optional additional data used by the callback * @pool: the pool being allocated from +* @start_addr: start address of memory chunk */ typedef unsigned long (*genpool_algo_t)(unsigned long *map, unsigned long size,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 317/567 firewire: nosy: Fix dma_free_coherent() size
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Fourier <[email protected]>
[ Upstream commit c48c0fd0e19684b6ecdb4108a429e3a4e73f5e21 ]
It looks like the buffer allocated and mapped in add_card() is done with size RCV_BUFFER_SIZE which is 16 KB and 4KB.
--- drivers/firewire/nosy.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/firewire/nosy.c +5 -5
@@ -36,6 +36,8 @@static char driver_name[] =KBUILD_MODNAME ; +#define RCV_BUFFER_SIZE (16 * 1024) +/* this is the physical layout of a PCL, its size is 128 bytes */ struct pcl {__le32 next;
@@ -517,16 +519,14 @@ remove_card(struct pci_dev *dev) lynx->rcv_start_pcl, lynx->rcv_start_pcl_bus);dma_free_coherent (&lynx->pci_device->dev,sizeof (struct pcl ), lynx->rcv_pcl, lynx->rcv_pcl_bus); -dma_free_coherent (&lynx->pci_device->dev,PAGE_SIZE , lynx->rcv_buffer, - lynx->rcv_buffer_bus); +dma_free_coherent (&lynx->pci_device->dev,RCV_BUFFER_SIZE , + lynx->rcv_buffer, lynx->rcv_buffer_bus);iounmap (lynx->registers);pci_disable_device (dev);lynx_put (lynx); } -#define RCV_BUFFER_SIZE (16 * 1024) -static int add_card (struct pci_dev *dev,const struct pci_device_id *unused) {
@@ -680,7 +680,7 @@ add_card(struct pci_dev *dev, const struct pci_device_id *unused)dma_free_coherent (&lynx->pci_device->dev,sizeof (struct pcl ), lynx->rcv_pcl, lynx->rcv_pcl_bus);if (lynx->rcv_buffer) -dma_free_coherent (&lynx->pci_device->dev,PAGE_SIZE , +dma_free_coherent (&lynx->pci_device->dev,RCV_BUFFER_SIZE , lynx->rcv_buffer, lynx->rcv_buffer_bus);iounmap (lynx->registers);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 318/567 net: dsa: b53: skip multicast entries for fdb_dump()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonas Gorski <[email protected]>
[ Upstream commit d42bce414d1c5c0b536758466a1f63ac358e613c ]
port_fdb_dump() is supposed to only add fdb entries, but we iterate over the full ARL table, which also includes multicast entries.
So check if the entry is a multicast entry before passing it on to the callback().
Additionally, the port of those entries is a bitmask, not a port number, so any included entries would have even be for the wrong port.
--- drivers/net/dsa/b53/b53_common.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/dsa/b53/b53_common.c +3 -0
@@ -1972,6 +1972,9 @@ static int b53_fdb_copy(int port, const struct b53_arl_entry *ent,if (!ent->is_valid)return 0 ; +if (is_multicast_ether_addr (ent->mac)) +return 0 ; +if (port != ent->port)return 0 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 319/567 kbuild: fix compilation of dtb specified on command-line without make rule
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas De Schampheleire <[email protected]>
[ Upstream commit b08fc4d0ec2466558f6d5511434efdfabbddf2a6 ]
Since commit e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs"), it is no longer possible to compile a device tree blob that is not specified in a make rule
like:
dtb-$(CONFIG_FOO) += foo.dtb
Before the mentioned commit, one could copy a dts file to e.g. arch/arm64/boot/dts/ (or a new subdirectory) and then convert it to a dtb file using:
make ARCH=arm64 foo.dtb
In this scenario, both 'dtb-y' and 'dtb-' are empty, and the inclusion of scripts/Makefile.dtbs relies on 'targets' to contain the MAKECMDGOALS. The value of 'targets', however, is only final later in the code.
Move the conditional include of scripts/Makefile.dtbs down to where the value of 'targets' is final. Since Makefile.dtbs updates 'always-y' which is used as a prerequisite in the build rule, the build rule also needs to move down.
--- scripts/Makefile.build | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-)
scripts/Makefile.build +14 -12
@@ -449,18 +449,6 @@ ifneq ($(userprogs),) include $(srctree)/scripts/Makefile.userprogs endif -ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets)),) -include $(srctree)/scripts/Makefile.dtbs -endif - -# Build -# --------------------------------------------------------------------------- - -$(obj)/: $(if $(KBUILD_BUILTIN), $(targets-for-builtin)) \ - $(if $(KBUILD_MODULES), $(targets-for-modules)) \ - $(subdir-ym) $(always-y) - @: - # Single targets # ---------------------------------------------------------------------------
@@ -490,6 +478,20 @@ FORCE: targets += $(filter-out $(single-subdir-goals), $(MAKECMDGOALS)) targets := $(filter-out $(PHONY), $(targets)) +# Now that targets is fully known, include dtb rules if needed +ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets)),) +include $(srctree)/scripts/Makefile.dtbs +endif + +# Build +# Needs to be after the include of Makefile.dtbs, which updates always-y +# --------------------------------------------------------------------------- + +$(obj)/: $(if $(KBUILD_BUILTIN), $(targets-for-builtin)) \ + $(if $(KBUILD_MODULES), $(targets-for-modules)) \ + $(subdir-ym) $(always-y) + @: + # Read all saved command lines and dependencies for the $(targets) we # may be building above, using $(if_changed{,_dep}). As an # optimization, we don't need to read them if the target does not
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 320/567 net: usb: asix: validate PHY address before use
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
[ Upstream commit a1e077a3f76eea0dc671ed6792e7d543946227e8 ]
The ASIX driver reads the PHY address from the USB device via asix_read_phy_addr(). A malicious or faulty device can return an invalid address (>= PHY_MAX_ADDR), which causes a warning in mdiobus_get_phy():
addr 207 out of range
WARNING: drivers/net/phy/mdio_bus.c:76
Validate the PHY address in asix_read_phy_addr() and remove the now-redundant check in ax88172a.c.
--- drivers/net/usb/asix_common.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/usb/asix_common.c +5 -0
@@ -335,6 +335,11 @@ int asix_read_phy_addr(struct usbnet *dev, bool internal) offset = (internal ?1 :0 ); ret = buf[offset]; +if (ret >=PHY_MAX_ADDR ) { +netdev_err (dev->net,"invalid PHY address: %d\n" , ret); +return -ENODEV ; + } +netdev_dbg (dev->net,"%s PHY address 0x%x\n" , internal ?"internal" :"external" , ret);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 321/567 net: bridge: Describe @tunnel_hash member in net_bridge_vlan_group struct
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bagas Sanjaya <[email protected]>
[ Upstream commit f79f9b7ace1713e4b83888c385f5f55519dfb687 ]
Sphinx reports kernel-doc warning:
WARNING: ./net/bridge/br_private.h:267 struct member 'tunnel_hash' not described in 'net_bridge_vlan_group'
Fix it by describing @tunnel_hash member.
--- net/bridge/br_private.h | 1 + 1 file changed, 1 insertion(+)
net/bridge/br_private.h +1 -0
@@ -247,6 +247,7 @@ struct net_bridge_vlan {* struct net_bridge_vlan_group * * @vlan_hash: VLAN entry rhashtable +* @tunnel_hash: Hash table to map from tunnel key ID (e.g. VXLAN VNI) to VLAN * @vlan_list: sorted VLAN entry list * @num_vlans: number of total VLAN entries * @pvid: PVID VLAN id
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 322/567 vfio/pds: Fix memory leak in pds_vfio_dirty_enable()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zilin Guan <[email protected]>
[ Upstream commit 665077d78dc7941ce6a330c02023a2b469cc8cc7 ]
pds_vfio_dirty_enable() allocates memory for region_info. If interval_tree_iter_first() returns NULL, the function returns -EINVAL immediately without freeing the allocated memory, causing a memory leak.
Fix this by jumping to the out_free_region_info label to ensure region_info is freed.
--- drivers/vfio/pci/pds/dirty.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/vfio/pci/pds/dirty.c +5 -2
@@ -292,8 +292,11 @@ static int pds_vfio_dirty_enable(struct pds_vfio_pci_device *pds_vfio, len = num_ranges *sizeof (*region_info); node =interval_tree_iter_first (ranges,0 ,ULONG_MAX ); -if (!node) -return -EINVAL ; +if (!node) { + err = -EINVAL ; + goto out_free_region_info; + } +for (int i =0 ; i < num_ranges; i++) {struct pds_lm_dirty_region_info *ri = ®ion_info[i];u64 region_size = node->last - node->start +1 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 323/567 platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junrui Luo <[email protected]>
[ Upstream commit e44c42c830b7ab36e3a3a86321c619f24def5206 ]
The hp_populate_*_elements_from_package() functions in the hp-bioscfg driver contain out-of-bounds array access vulnerabilities.
These functions parse ACPI packages into internal data structures using a for loop with index variable 'elem' that iterates through enum_obj/integer_obj/order_obj/password_obj/string_obj arrays.
When processing multi-element fields like PREREQUISITES and ENUM_POSSIBLE_VALUES, these functions read multiple consecutive array elements using expressions like 'enum_obj[elem + reqs]' and 'enum_obj[elem + pos_values]' within nested loops.
The bug is that the bounds check only validated elem, but did not consider the additional offset when accessing elem + reqs or elem + pos_values.
The fix changes the bounds check to validate the actual accessed index.
--- drivers/platform/x86/hp/hp-bioscfg/enum-attributes.c | 4 ++-- drivers/platform/x86/hp/hp-bioscfg/int-attributes.c | 2 +- drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c | 5 +++++ drivers/platform/x86/hp/hp-bioscfg/passwdobj-attributes.c | 5 +++++ drivers/platform/x86/hp/hp-bioscfg/string-attributes.c | 2 +- 5 files changed, 14 insertions(+), 4 deletions(-)
drivers/platform/x86/hp/hp-bioscfg/enum-attributes.c +2 -2
@@ -207,7 +207,7 @@ static int hp_populate_enumeration_elements_from_package(union acpi_object *enumcase PREREQUISITES : size =min_t (u32, enum_data->common.prerequisites_size,MAX_PREREQUISITES_SIZE );for (reqs =0 ; reqs < size; reqs++) { -if (elem >= enum_obj_count) { +if (elem + reqs >= enum_obj_count) {pr_err ("Error enum-objects package is too small\n" );return -EINVAL ; }
@@ -255,7 +255,7 @@ static int hp_populate_enumeration_elements_from_package(union acpi_object *enumfor (pos_values =0 ; pos_values < size && pos_values <MAX_VALUES_SIZE ; pos_values++) { -if (elem >= enum_obj_count) { +if (elem + pos_values >= enum_obj_count) {pr_err ("Error enum-objects package is too small\n" );return -EINVAL ; }
drivers/platform/x86/hp/hp-bioscfg/int-attributes.c +1 -1
@@ -227,7 +227,7 @@ static int hp_populate_integer_elements_from_package(union acpi_object *integer_ size =min_t (u32, integer_data->common.prerequisites_size,MAX_PREREQUISITES_SIZE );for (reqs =0 ; reqs < size; reqs++) { -if (elem >= integer_obj_count) { +if (elem + reqs >= integer_obj_count) {pr_err ("Error elem-objects package is too small\n" );return -EINVAL ; }
drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c +5 -0
@@ -216,6 +216,11 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord size =min_t (u32, ordered_list_data->common.prerequisites_size,MAX_PREREQUISITES_SIZE );for (reqs =0 ; reqs < size; reqs++) { +if (elem + reqs >= order_obj_count) { +pr_err ("Error elem-objects package is too small\n" ); +return -EINVAL ; + } + ret =hp_convert_hexstr_to_str (order_obj[elem + reqs].string.pointer, order_obj[elem + reqs].string.length, &str_value, &value_len);
drivers/platform/x86/hp/hp-bioscfg/passwdobj-attributes.c +5 -0
@@ -303,6 +303,11 @@ static int hp_populate_password_elements_from_package(union acpi_object *passwor MAX_PREREQUISITES_SIZE);for (reqs =0 ; reqs < size; reqs++) { +if (elem + reqs >= password_obj_count) { +pr_err ("Error elem-objects package is too small\n" ); +return -EINVAL ; + } + ret =hp_convert_hexstr_to_str (password_obj[elem + reqs].string.pointer, password_obj[elem + reqs].string.length, &str_value, &value_len);
drivers/platform/x86/hp/hp-bioscfg/string-attributes.c +1 -1
@@ -217,7 +217,7 @@ static int hp_populate_string_elements_from_package(union acpi_object *string_ob MAX_PREREQUISITES_SIZE);for (reqs =0 ; reqs < size; reqs++) { -if (elem >= string_obj_count) { +if (elem + reqs >= string_obj_count) {pr_err ("Error elem-objects package is too small\n" );return -EINVAL ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 324/567 octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshumali Gaur <[email protected]>
[ Upstream commit 85f4b0c650d9f9db10bda8d3acfa1af83bf78cf7 ]
This patch ensures that the RX ring size (rx_pending) is not set below the permitted length. This avoids UBSAN shift-out-of-bounds errors when users passes small or zero ring sizes via ethtool -G.
--- drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c +8 -0
@@ -432,6 +432,14 @@ static int otx2_set_ringparam(struct net_device *netdev,*/ if (rx_count < pfvf->hw.rq_skid) rx_count = pfvf->hw.rq_skid; + +if (ring->rx_pending <16 ) { +netdev_err (netdev, +"rx ring size %u invalid, min is 16\n" , + ring->rx_pending); +return -EINVAL ; + } + rx_count =Q_COUNT (Q_SIZE (rx_count,3 ));/* Due pipelining impact minimum 2000 unused SQ CQE's
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 325/567 net: stmmac: fix the crash issue for zero copy XDP_TX action
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
[ Upstream commit a48e232210009be50591fdea8ba7c07b0f566a13 ]
There is a crash issue when running zero copy XDP_TX action, the crash log is shown below.
[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcache_clean_poc+0x20/0x38 (P) [ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0 [ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400 [ 216.317701] __stmmac_xdp_run_prog+0x164/0x368 [ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00 [ 216.326576] __napi_poll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt
For XDP_TX action, the xdp_buff is converted to xdp_frame by xdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame depends on the memory type of the xdp_buff. For page pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy XSK pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdp_buff memory type in stmmac_xdp_xmit_back() to fix this issue.
--- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +15 -2
@@ -87,6 +87,7 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");#define STMMAC_XDP_CONSUMED BIT(0)#define STMMAC_XDP_TX BIT(1)#define STMMAC_XDP_REDIRECT BIT(2) +#define STMMAC_XSK_CONSUMED BIT(3)static int flow_ctrl =FLOW_AUTO ;module_param (flow_ctrl, int,0644 );
@@ -4998,6 +4999,7 @@ static int stmmac_xdp_get_tx_queue(struct stmmac_priv *priv,static int stmmac_xdp_xmit_back (struct stmmac_priv *priv,struct xdp_buff *xdp) { +bool zc = !!(xdp->rxq->mem.type ==MEM_TYPE_XSK_BUFF_POOL );struct xdp_frame *xdpf =xdp_convert_buff_to_frame (xdp);int cpu =smp_processor_id ();struct netdev_queue *nq;
@@ -5014,9 +5016,18 @@ static int stmmac_xdp_xmit_back(struct stmmac_priv *priv,/* Avoids TX time-out as we are sharing with slow path */ txq_trans_cond_update (nq); - res =stmmac_xdp_xmit_xdpf (priv, queue, xdpf, false); -if (res ==STMMAC_XDP_TX ) +/* For zero copy XDP_TX action, dma_map is true */ + res =stmmac_xdp_xmit_xdpf (priv, queue, xdpf, zc); +if (res ==STMMAC_XDP_TX ) {stmmac_flush_tx_descriptors (priv, queue); + }else if (res ==STMMAC_XDP_CONSUMED && zc) { +/* xdp has been freed by xdp_convert_buff_to_frame(), +* no need to call xsk_buff_free() again, so return +* STMMAC_XSK_CONSUMED. +*/ + res =STMMAC_XSK_CONSUMED ; +xdp_return_frame (xdpf); + }__netif_tx_unlock (nq);
@@ -5366,6 +5377,8 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)break ;case STMMAC_XDP_CONSUMED :xsk_buff_free (buf->xdp); + fallthrough; +case STMMAC_XSK_CONSUMED : rx_dropped++;break ;case STMMAC_XDP_TX :
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 326/567 ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Rosenberg <[email protected]>
[ Upstream commit 58fc7342b529803d3c221101102fe913df7adb83 ]
There exists a kernel oops caused by a BUG_ON(nhead < 0) at net/core/skbuff.c:2232 in pskb_expand_head().
This bug is triggered as part of the calipso_skbuff_setattr() routine when skb_cow() is passed headroom > INT_MAX (i.e. (int)(skb_headroom(skb) + len_delta) < 0).
The root cause of the bug is due to an implicit integer cast in __skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensure that delta = headroom - skb_headroom(skb) is never negative, otherwise we will trigger a BUG_ON in pskb_expand_head(). However, if headroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, delta becomes negative, and pskb_expand_head() is passed a negative value for nhead.
Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing "negative" headroom sizes to skb_cow() within calipso_skbuff_setattr() by only using skb_cow() to grow headroom.
PoC:
Using `netlabelctl` tool:
netlabelctl map del default
netlabelctl calipso add pass doi:7
netlabelctl map add default address:0::1/128 protocol:calipso,7
Then run the following PoC:
int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
// setup msghdr
int cmsg_size = 2;
int cmsg_len = 0x60;
struct msghdr msg;
struct sockaddr_in6 dest_addr;
struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,
sizeof(struct cmsghdr) + cmsg_len);
msg.msg_name = &dest_addr;
msg.msg_namelen = sizeof(dest_addr);
msg.msg_iov = NULL;
msg.msg_iovlen = 0;
msg.msg_control = cmsg;
msg.msg_controllen = cmsg_len;
msg.msg_flags = 0;
// setup sockaddr
dest_addr.sin6_family = AF_INET6;
dest_addr.sin6_port = htons(31337);
dest_addr.sin6_flowinfo = htonl(31337);
dest_addr.sin6_addr = in6addr_loopback;
dest_addr.sin6_scope_id = 31337;
// setup cmsghdr
cmsg->cmsg_len = cmsg_len;
cmsg->cmsg_level = IPPROTO_IPV6;
cmsg->cmsg_type = IPV6_HOPOPTS;
char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);
hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80
sendmsg(fd, &msg, 0);--- net/ipv6/calipso.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/ipv6/calipso.c +2 -1
@@ -1342,7 +1342,8 @@ static int calipso_skbuff_setattr(struct sk_buff *skb,/* At this point new_end aligns to 4n, so (new_end & 4) pads to 8n */ pad = ((new_end &4 ) + (end &7 )) &7 ; len_delta = new_end - (int )end + pad; - ret_val =skb_cow (skb,skb_headroom (skb) + len_delta); + ret_val =skb_cow (skb, +skb_headroom (skb) + (len_delta >0 ? len_delta :0 ));if (ret_val <0 )return ret_val;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 327/567 ipv4: Fix reference count leak when using error routes with nexthop objects
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit ac782f4e3bfcde145b8a7f8af31d9422d94d172a ]
When a nexthop object is deleted, it is marked as dead and then fib_table_flush() is called to flush all the routes that are using the dead nexthop.
The current logic in fib_table_flush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flush_all=true). Therefore, error routes are not flushed when their nexthop object is deleted:
# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1
As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:
# ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2
Fix by flushing error routes when their nexthop is marked as dead.
IPv6 does not suffer from this problem.
--- net/ipv4/fib_trie.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/ipv4/fib_trie.c +4 -3
@@ -2059,10 +2059,11 @@ int fib_table_flush(struct net *net, struct fib_table *tb, bool flush_all)continue ; } -/* Do not flush error routes if network namespace is -* not being dismantled +/* When not flushing the entire table, skip error +* routes that are not marked for deletion. */ -if (!flush_all && fib_props[fa->fa_type].error) { +if (!flush_all && fib_props[fa->fa_type].error && + !(fi->fib_flags &RTNH_F_DEAD )) { slen = fa->fa_slen;continue ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 328/567 net: rose: fix invalid array index in rose_kill_by_device()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pwnverse <[email protected]>
[ Upstream commit 6595beb40fb0ec47223d3f6058ee40354694c8e4 ]
rose_kill_by_device() collects sockets into a local array[] and then iterates over them to disconnect sockets bound to a device being brought down.
The loop mistakenly indexes array[cnt] instead of array[i]. For cnt < ARRAY_SIZE(array), this reads an uninitialized entry; for cnt == ARRAY_SIZE(array), it is an out-of-bounds read. Either case can lead to an invalid socket pointer dereference and also leaks references taken via sock_hold().
Fix the index to use i.
--- net/rose/af_rose.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/rose/af_rose.c +1 -1
@@ -205,7 +205,7 @@ static void rose_kill_by_device(struct net_device *dev)spin_unlock_bh (&rose_list_lock);for (i =0 ; i < cnt; i++) { - sk = array[cnt]; + sk = array[i]; rose =rose_sk (sk);lock_sock (sk);spin_lock_bh (&rose_list_lock);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 329/567 ipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RT
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiayuan Chen <[email protected]>
[ Upstream commit 1adaea51c61b52e24e7ab38f7d3eba023b2d050d ]
On PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, the current task can be preempted. Another task running on the same CPU may then execute rt6_make_pcpu_route() and successfully install a pcpu_rt entry. When the first task resumes execution, its cmpxchg() in rt6_make_pcpu_route() will fail because rt6i_pcpu is no longer NULL, triggering the BUG_ON(prev). It's easy to reproduce it by adding mdelay() after rt6_get_pcpu_route().
Using preempt_disable/enable is not appropriate here because ip6_rt_pcpu_alloc() may sleep.
Fix this by handling the cmpxchg() failure gracefully on PREEMPT_RT:
free our allocation and return the existing pcpu_rt installed by another task. The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RT kernels where such races should not occur.
--- net/ipv6/route.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
net/ipv6/route.c +12 -1
@@ -1470,7 +1470,18 @@ static struct rt6_info *rt6_make_pcpu_route(struct net *net, p =this_cpu_ptr (res->nh->rt6i_pcpu); prev =cmpxchg (p,NULL , pcpu_rt); -BUG_ON (prev); +if (unlikely (prev)) { +/* +* Another task on this CPU already installed a pcpu_rt. +* This can happen on PREEMPT_RT where preemption is possible. +* Free our allocation and return the existing one. +*/ +WARN_ON_ONCE (!IS_ENABLED (CONFIG_PREEMPT_RT )); + +dst_dev_put (&pcpu_rt->dst); +dst_release (&pcpu_rt->dst); +return prev; + }if (res->f6i->fib6_destroying) {struct fib6_info *from;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 330/567 RDMA/irdma: avoid invalid read in irdma_net_event
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Schmidt <[email protected]>
[ Upstream commit 6f05611728e9d0ab024832a4f1abb74a5f5d0bb0 ]
irdma_net_event() should not dereference anything from "neigh" (alias "ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE. Other events come with different structures pointed to by "ptr" and they may be smaller than struct neighbour.
Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.
The bug is mostly harmless, but it triggers KASAN on debug kernels:
BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma] Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554 CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1 Hardware name: [...] Workqueue: events rt6_probe_deferred Call Trace: <IRQ> dump_stack_lvl+0x60/0xb0 print_address_description.constprop.0+0x2c/0x3f0 print_report+0xb4/0x270 kasan_report+0x92/0xc0 irdma_net_event+0x32e/0x3b0 [irdma] notifier_call_chain+0x9e/0x180 atomic_notifier_call_chain+0x5c/0x110 rt6_do_redirect+0xb91/0x1080 tcp_v6_err+0xe9b/0x13e0 icmpv6_notify+0x2b2/0x630 ndisc_redirect_rcv+0x328/0x530 icmpv6_rcv+0xc16/0x1360 ip6_protocol_deliver_rcu+0xb84/0x12e0 ip6_input_finish+0x117/0x240 ip6_input+0xc4/0x370 ipv6_rcv+0x420/0x7d0 __netif_receive_skb_one_core+0x118/0x1b0 process_backlog+0xd1/0x5d0 __napi_poll.constprop.0+0xa3/0x440 net_rx_action+0x78a/0xba0 handle_softirqs+0x2d4/0x9c0 do_softirq+0xad/0xe0 </IRQ>
--- drivers/infiniband/hw/irdma/utils.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/infiniband/hw/irdma/utils.c +2 -1
@@ -251,7 +251,7 @@ int irdma_net_event(struct notifier_block *notifier, unsigned long event, void *ptr) {struct neighbour *neigh = ptr; -struct net_device *real_dev, *netdev = (struct net_device *)neigh->dev; +struct net_device *real_dev, *netdev;struct irdma_device *iwdev;struct ib_device *ibdev;__be32 *p;
@@ -260,6 +260,7 @@ int irdma_net_event(struct notifier_block *notifier, unsigned long event,switch (event) {case NETEVENT_NEIGH_UPDATE : + netdev = neigh->dev; real_dev =rdma_vlan_dev_real_dev (netdev);if (!real_dev) real_dev = netdev;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 331/567 RDMA/efa: Remove possible negative shift
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Margolin <[email protected]>
[ Upstream commit 85463eb6a46caf2f1e0e1a6d0731f2f3bab17780 ]
The page size used for device might in some cases be smaller than PAGE_SIZE what results in a negative shift when calculating the number of host pages in PAGE_SIZE for a debug log. Remove the debug line together with the calculation.
--- drivers/infiniband/hw/efa/efa_verbs.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/infiniband/hw/efa/efa_verbs.c +0 -4
@@ -1241,13 +1241,9 @@ static int umem_to_page_list(struct efa_dev *dev, u32 hp_cnt, u8 hp_shift) { -u32 pages_in_hp =BIT (hp_shift -PAGE_SHIFT );struct ib_block_iter biter;unsigned int hp_idx =0 ; -ibdev_dbg (&dev->ibdev,"hp_cnt[%u], pages_in_hp[%u]\n" , - hp_cnt, pages_in_hp); -rdma_umem_for_each_dma_block (umem, &biter,BIT (hp_shift)) page_list[hp_idx++] =rdma_block_iter_dma_address (&biter);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 332/567 RDMA/core: Fix logic error in ib_get_gids_from_rdma_hdr()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jang Ingyu <[email protected]>
[ Upstream commit 8aaa848eaddd9ef8680fc6aafbd3a0646da5df40 ]
Fix missing comparison operator for RDMA_NETWORK_ROCE_V1 in the conditional statement. The constant was used directly instead of being compared with net_type, causing the condition to always evaluate to true.
--- drivers/infiniband/core/verbs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/core/verbs.c +1 -1
@@ -735,7 +735,7 @@ int ib_get_gids_from_rdma_hdr(const union rdma_network_hdr *hdr, (struct in6_addr *)dgid);return 0 ; }else if (net_type ==RDMA_NETWORK_IPV6 || - net_type ==RDMA_NETWORK_IB ||RDMA_NETWORK_ROCE_V1 ) { + net_type ==RDMA_NETWORK_IB || net_type ==RDMA_NETWORK_ROCE_V1 ) { *dgid = hdr->ibgrh.dgid; *sgid = hdr->ibgrh.sgid;return 0 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 333/567 RDMA/bnxt_re: Fix incorrect BAR check in bnxt_qplib_map_creq_db()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alok Tiwari <[email protected]>
[ Upstream commit 145a417a39d7efbc881f52e829817376972b278c ]
RCFW_COMM_CONS_PCI_BAR_REGION is defined as BAR 2, so checking !creq_db->reg.bar_id is incorrect and always false.
pci_resource_start() returns the BAR base address, and a value of 0 indicates that the BAR is unassigned. Update the condition to test bar_base == 0 instead.
This ensures the driver detects and logs an error for an unassigned RCFW communication BAR.
--- drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/bnxt_re/qplib_rcfw.c +1 -1
@@ -1117,7 +1117,7 @@ static int bnxt_qplib_map_creq_db(struct bnxt_qplib_rcfw *rcfw, u32 reg_offt) creq_db->dbinfo.flags =0 ; creq_db->reg.bar_id =RCFW_COMM_CONS_PCI_BAR_REGION ; creq_db->reg.bar_base =pci_resource_start (pdev, creq_db->reg.bar_id); -if (!creq_db->reg.bar_id) +if (!creq_db->reg.bar_base)dev_err (&pdev->dev,"QPLIB: CREQ BAR region %d resc start is 0!" , creq_db->reg.bar_id);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 334/567 RDMA/core: always drop device refcount in ib_del_sub_device_and_put()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <[email protected]>
[ Upstream commit fa3c411d21ebc26ffd175c7256c37cefa35020aa ]
Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add support to add/delete a sub IB device through netlink") grabs a reference using ib_device_get_by_index() before calling ib_del_sub_device_and_put(), we need to drop that reference before returning -EOPNOTSUPP error.
--- drivers/infiniband/core/device.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/infiniband/core/device.c +3 -1
@@ -2823,8 +2823,10 @@ int ib_del_sub_device_and_put(struct ib_device *sub) {struct ib_device *parent = sub->parent; -if (!parent) +if (!parent) { +ib_device_put (sub);return -EOPNOTSUPP ; + }mutex_lock (&parent->subdev_lock);list_del (&sub->subdev_list);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 335/567 RDMA/bnxt_re: Fix IB_SEND_IP_CSUM handling in post_send
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alok Tiwari <[email protected]>
[ Upstream commit f01765a2361323e78e3d91b1cb1d5527a83c5cf7 ]
The bnxt_re SEND path checks wr->send_flags to enable features such as IP checksum offload. However, send_flags is a bitmask and may contain multiple flags (e.g. IB_SEND_SIGNALED | IB_SEND_IP_CSUM), while the existing code uses a switch() statement that only matches when send_flags is exactly IB_SEND_IP_CSUM.
As a result, checksum offload is not enabled when additional SEND flags are present.
Replace the switch() with a bitmask test:
if (wr->send_flags & IB_SEND_IP_CSUM)
This ensures IP checksum offload is enabled correctly when multiple SEND flags are used.
--- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
drivers/infiniband/hw/bnxt_re/ib_verbs.c +1 -6
@@ -2823,14 +2823,9 @@ int bnxt_re_post_send(struct ib_qp *ib_qp, const struct ib_send_wr *wr, wqe.rawqp1.lflags |=SQ_SEND_RAWETH_QP1_LFLAGS_ROCE_CRC ; } -switch (wr->send_flags) { -case IB_SEND_IP_CSUM : +if (wr->send_flags &IB_SEND_IP_CSUM ) wqe.rawqp1.lflags |=SQ_SEND_RAWETH_QP1_LFLAGS_IP_CHKSUM ; -break ; -default : -break ; - } fallthrough;case IB_WR_SEND_WITH_INV : rc =bnxt_re_build_send_wqe (qp, wr, &wqe);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 336/567 RDMA/bnxt_re: Fix to use correct page size for PDE table
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kalesh AP <[email protected]>
[ Upstream commit 3d70e0fb0f289b0c778041c5bb04d099e1aa7c1c ]
In bnxt_qplib_alloc_init_hwq(), while allocating memory for PDE table driver incorrectly is using the "pg_size" value passed to the function. Fixed to use the right value 4K. Also, fixed the allocation size for PBL table.
--- drivers/infiniband/hw/bnxt_re/qplib_res.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/hw/bnxt_re/qplib_res.c +2 -2
@@ -243,7 +243,7 @@ int bnxt_qplib_alloc_init_hwq(struct bnxt_qplib_hwq *hwq,if (npbl %BIT (MAX_PDL_LVL_SHIFT )) npde++;/* Alloc PDE pages */ - sginfo.pgsize = npde * pg_size; + sginfo.pgsize = npde *ROCE_PG_SIZE_4K ; sginfo.npages =1 ; rc =__alloc_pbl (res, &hwq->pbl[PBL_LVL_0 ], &sginfo);if (rc)
@@ -251,7 +251,7 @@ int bnxt_qplib_alloc_init_hwq(struct bnxt_qplib_hwq *hwq,/* Alloc PBL pages */ sginfo.npages = npbl; - sginfo.pgsize =PAGE_SIZE ; + sginfo.pgsize =ROCE_PG_SIZE_4K ; rc =__alloc_pbl (res, &hwq->pbl[PBL_LVL_1 ], &sginfo);if (rc) goto fail;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 337/567 md: Fix static checker warning in analyze_sbs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Nan <[email protected]>
[ Upstream commit 00f6c1b4d15d35fadb7f34768a1831c81aaa8936 ]
The following warn is reported:
drivers/md/md.c:3912 analyze_sbs()
warn: iterator 'i' not incremented
--- drivers/md/md.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/md/md.c +1 -4
@@ -3729,7 +3729,6 @@ static struct md_rdev *md_import_device(dev_t newdev, int super_format, int supestatic int analyze_sbs (struct mddev *mddev) { -int i;struct md_rdev *rdev, *freshest, *tmp; freshest =NULL ;
@@ -3756,11 +3755,9 @@ static int analyze_sbs(struct mddev *mddev) super_types[mddev->major_version].validate_super (mddev,NULL /*freshest*/ , freshest); - i =0 ;rdev_for_each_safe (rdev, tmp, mddev) {if (mddev->max_disks && - (rdev->desc_nr >= mddev->max_disks || - i > mddev->max_disks)) { + rdev->desc_nr >= mddev->max_disks) {pr_warn ("md: %s: %pg: only %d devices permitted\n" ,mdname (mddev), rdev->bdev, mddev->max_disks);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 338/567 md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tuo Li <[email protected]>
[ Upstream commit 7ad6ef91d8745d04aff9cce7bdbc6320d8e05fe9 ]
The variable mddev->private is first assigned to conf and then checked:
conf = mddev->private; if (!conf) ...
If conf is NULL, then mddev->private is also NULL. In this case, null-pointer dereferences can occur when calling raid5_quiesce():
raid5_quiesce(mddev, true); raid5_quiesce(mddev, false);
since mddev->private is assigned to conf again in raid5_quiesce(), and conf is dereferenced in several places, for example:
conf->quiesce = 0; wake_up(&conf->wait_for_quiescent);
To fix this issue, the function should unlock mddev and return before invoking raid5_quiesce() when conf is NULL, following the existing pattern in raid5_change_consistency_policy().
--- drivers/md/raid5.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/md/raid5.c +6 -4
@@ -7181,12 +7181,14 @@ raid5_store_group_thread_cnt(struct mddev *mddev, const char *page, size_t len) err =mddev_suspend_and_lock (mddev);if (err)return err; + conf = mddev->private; +if (!conf) { +mddev_unlock_and_resume (mddev); +return -ENODEV ; + }raid5_quiesce (mddev, true); - conf = mddev->private; -if (!conf) - err = -ENODEV ; -else if (new != conf->worker_cnt_per_group) { +if (new != conf->worker_cnt_per_group) { old_groups = conf->worker_groups;if (old_groups)flush_workqueue (raid5_wq);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 339/567 ksmbd: Fix memory leak in get_file_all_info()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zilin Guan <[email protected]>
[ Upstream commit 0c56693b06a68476ba113db6347e7897475f9e4c ]
In get_file_all_info(), if vfs_getattr() fails, the function returns immediately without freeing the allocated filename, leading to a memory leak.
Fix this by freeing the filename before returning in this error case.
--- fs/smb/server/smb2pdu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/smb/server/smb2pdu.c +3 -1
@@ -4926,8 +4926,10 @@ static int get_file_all_info(struct ksmbd_work *work, ret =vfs_getattr (&fp->filp->f_path, &stat,STATX_BASIC_STATS ,AT_STATX_SYNC_AS_STAT ); -if (ret) +if (ret) { +kfree (filename);return ret; + }ksmbd_debug (SMB ,"filename = %s\n" , filename); delete_pending =ksmbd_inode_pending_delete (fp);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 340/567 RDMA/rtrs: Fix clt_path::max_pages_per_mr calculation
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Honggang LI <[email protected]>
[ Upstream commit 43bd09d5b750f700499ae8ec45fd41a4c48673e6 ]
If device max_mr_size bits in the range [mr_page_shift+31:mr_page_shift] are zero, the min3 function will set clt_path::max_pages_per_mr to zero.
alloc_path_reqs will pass zero, which is invalid, as the third parameter to ib_alloc_mr.
--- drivers/infiniband/ulp/rtrs/rtrs-clt.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/ulp/rtrs/rtrs-clt.c +1 -0
@@ -1464,6 +1464,7 @@ static void query_fast_reg_mode(struct rtrs_clt_path *clt_path) mr_page_shift =max (12 ,ffs (ib_dev->attrs.page_size_cap) -1 ); max_pages_per_mr = ib_dev->attrs.max_mr_size;do_div (max_pages_per_mr, (1ull << mr_page_shift)); + max_pages_per_mr =min_not_zero ((u32 )max_pages_per_mr,U32_MAX ); clt_path->max_pages_per_mr =min3 (clt_path->max_pages_per_mr, (u32 )max_pages_per_mr, ib_dev->attrs.max_fast_reg_page_list_len);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 341/567 RDMA/bnxt_re: fix dma_free_coherent() pointer
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Fourier <[email protected]>
[ Upstream commit fcd431a9627f272b4c0bec445eba365fe2232a94 ]
The dma_alloc_coherent() allocates a dma-mapped buffer, pbl->pg_arr[i]. The dma_free_coherent() should pass the same buffer to dma_free_coherent() and not page-aligned.
--- drivers/infiniband/hw/bnxt_re/qplib_res.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/infiniband/hw/bnxt_re/qplib_res.c +1 -3
@@ -70,9 +70,7 @@ static void __free_pbl(struct bnxt_qplib_res *res, struct bnxt_qplib_pbl *pbl,for (i =0 ; i < pbl->pg_count; i++) {if (pbl->pg_arr[i])dma_free_coherent (&pdev->dev, pbl->pg_size, - (void *)((unsigned long ) - pbl->pg_arr[i] & -PAGE_MASK ), + pbl->pg_arr[i], pbl->pg_map_arr[i]);else dev_warn(&pdev->dev,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 342/567 blk-mq: skip CPU offline notify on unmapped hctx
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cong Zhang <[email protected]>
[ Upstream commit 10845a105bbcb030647a729f1716c2309da71d33 ]
If an hctx has no software ctx mapped, blk_mq_map_swqueue() never allocates tags and leaves hctx->tags NULL. The CPU hotplug offline notifier can still run for that hctx, return early since hctx cannot hold any requests.
--- block/blk-mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
block/blk-mq.c +1 -1
@@ -3658,7 +3658,7 @@ static int blk_mq_hctx_notify_offline(unsigned int cpu, struct hlist_node *node) struct blk_mq_hw_ctx, cpuhp_online);int ret =0 ; -if (blk_mq_hctx_has_online_cpu (hctx, cpu)) +if (!hctx->nr_ctx ||blk_mq_hctx_has_online_cpu (hctx, cpu))return 0 ;/*
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 343/567 selftests/ftrace: traceonoff_triggers: strip off names
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yipeng Zou <[email protected]>
[ Upstream commit b889b4fb4cbea3ca7eb9814075d6a51936394bd9 ]
The func_traceonoff_triggers.tc sometimes goes to fail on my board, Kunpeng-920.
[root@localhost]# ./ftracetest ./test.d/ftrace/func_traceonoff_triggers.tc -l fail.log === Ftrace unit tests === [1] ftrace - test for function traceon/off triggers [FAIL] [2] (instance) ftrace - test for function traceon/off triggers [UNSUPPORTED]
I look up the log, and it shows that the md5sum is different between csum1 and csum2.
++ cnt=611
++ sleep .1
+++ cnt_trace
+++ grep -v '^#' trace
+++ wc -l
++ cnt2=611
++ '[' 611 -ne 611 ']'
+++ cat tracing_on
++ on=0
++ '[' 0 '!=' 0 ']'
+++ md5sum trace
++ csum1='76896aa74362fff66a6a5f3cf8a8a500 trace'
++ sleep .1
+++ md5sum trace
++ csum2='ee8625a21c058818fc26e45c1ed3f6de trace'
++ '[' '76896aa74362fff66a6a5f3cf8a8a500 trace' '!=' 'ee8625a21c058818fc26e45c1ed3f6de trace' ']' ++ fail 'Tracing file is still changing'
++ echo Tracing file is still changing
Tracing file is still changing
++ exit_fail
++ exit 1
So I directly dump the trace file before md5sum, the diff shows that:
[root@localhost]# diff trace_1.log trace_2.log -y --suppress-common-lines dockerd-12285 [036] d.... 18385.510290: sched_stat | <...>-12285 [036] d.... 18385.510290: sched_stat dockerd-12285 [036] d.... 18385.510291: sched_swit | <...>-12285 [036] d.... 18385.510291: sched_swit <...>-740 [044] d.... 18385.602859: sched_stat | kworker/44:1-740 [044] d.... 18385.602859: sched_stat <...>-740 [044] d.... 18385.602860: sched_swit | kworker/44:1-740 [044] d.... 18385.602860: sched_swit
And we can see that <...> filed be filled with names.
We can strip off the names there to fix that.
After strip off the names:
kworker/u257:0-12 [019] d..2. 2528.758910: sched_stat | -12 [019] d..2. 2528.758910: sched_stat_runtime: comm=k kworker/u257:0-12 [019] d..2. 2528.758912: sched_swit | -12 [019] d..2. 2528.758912: sched_switch: prev_comm=kw <idle>-0 [000] d.s5. 2528.762318: sched_waki | -0 [000] d.s5. 2528.762318: sched_waking: comm=sshd pi <idle>-0 [037] dNh2. 2528.762326: sched_wake | -0 [037] dNh2. 2528.762326: sched_wakeup: comm=sshd pi <idle>-0 [037] d..2. 2528.762334: sched_swit | -0 [037] d..2. 2528.762334: sched_switch: prev_comm=sw
--- .../ftrace/test.d/ftrace/func_traceonoff_triggers.tc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc +3 -2
@@ -90,9 +90,10 @@ if [ $on != "0" ]; then fail "Tracing is not off" fi -csum1=`md5sum trace` +# Cannot rely on names being around as they are only cached, strip them +csum1=`cat trace | sed -e 's/^ *[^ ]*\(-[0-9][0-9]*\)/\1/' | md5sum` sleep $SLEEP_TIME -csum2=`md5sum trace` +csum2=`cat trace | sed -e 's/^ *[^ ]*\(-[0-9][0-9]*\)/\1/' | md5sum` if [ "$csum1" != "$csum2" ]; then fail "Tracing file is still changing"
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 344/567 ntfs: Do not overwrite uptodate pages
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Wilcox (Oracle) <[email protected]>
commit 68f6bd128e75a032432eda9d16676ed2969a1096 upstream.
When reading a compressed file, we may read several pages in addition to the one requested. The current code will overwrite pages in the page cache with the data from disc which can definitely result in changes that have been made being lost.
For example if we have four consecutie pages ABCD in the file compressed into a single extent, on first access, we'll bring in ABCD. Then we write to page B. Memory pressure results in the eviction of ACD. When we attempt to write to page C, we will overwrite the data in page B with the data currently on disk.
I haven't investigated the decompression code to check whether it's OK to overwrite a clean page or whether it might be possible to see corrupt data. Out of an abundance of caution, decline to overwrite uptodate pages, not just dirty pages.
--- fs/ntfs3/frecord.c | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-)
fs/ntfs3/frecord.c +29 -6
@@ -2077,6 +2077,29 @@ out:return err; } +static struct page *ntfs_lock_new_page (struct address_space *mapping, +pgoff_t index,gfp_t gfp) +{ +struct folio *folio =__filemap_get_folio (mapping, index, +FGP_LOCK |FGP_ACCESSED |FGP_CREAT , gfp); +struct page *page; + +if (IS_ERR (folio)) +return ERR_CAST (folio); + +if (!folio_test_uptodate (folio)) +return folio_file_page (folio, index); + +/* Use a temporary page to avoid data corruption */ +folio_unlock (folio); +folio_put (folio); + page =alloc_page (gfp); +if (!page) +return ERR_PTR (-ENOMEM ); +__SetPageLocked (page); +return page; +} +/* * ni_readpage_cmpr *
@@ -2131,9 +2154,9 @@ int ni_readpage_cmpr(struct ntfs_inode *if (i == idx)continue ; - pg =find_or_create_page (mapping, index, gfp_mask); -if (!pg) { - err = -ENOMEM ; + pg =ntfs_lock_new_page (mapping, index, gfp_mask); +if (IS_ERR (pg)) { + err =PTR_ERR (pg); goto out1; } pages[i] = pg;
@@ -2232,13 +2255,13 @@ int ni_decompress_file(struct ntfs_inodefor (i =0 ; i < pages_per_frame; i++, index++) {struct page *pg; - pg =find_or_create_page (mapping, index, gfp_mask); -if (!pg) { + pg =ntfs_lock_new_page (mapping, index, gfp_mask); +if (IS_ERR (pg)) {while (i--) {unlock_page (pages[i]);put_page (pages[i]); } - err = -ENOMEM ; + err =PTR_ERR (pg); goto out; } pages[i] = pg;
Greg Kroah-Hartman
maintainerPATCH 345/567 ASoC: codecs: wcd939x: fix regmap leak on probe failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 86dc090f737953f16f8dc60c546ae7854690d4f6 upstream.
The soundwire regmap that may be allocated during probe is not freed on late probe failures.
Add the missing error handling.
--- sound/soc/codecs/wcd939x-sdw.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
sound/soc/codecs/wcd939x-sdw.c +7 -1
@@ -1480,12 +1480,18 @@ static int wcd9390_probe(struct sdw_slav ret =component_add (dev, &wcd939x_sdw_component_ops);if (ret) -return ret; + goto err_free_regmap;/* Set suspended until aggregate device is bind */ pm_runtime_set_suspended (dev);return 0 ; + +err_free_regmap: +if (wcd->regmap) +regmap_exit (wcd->regmap); + +return ret; }static int wcd9390_remove (struct sdw_slave *pdev)
Greg Kroah-Hartman
maintainerPATCH 346/567 ASoC: stm32: sai: fix device leak on probe
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit e26ff429eaf10c4ef1bc3dabd9bf27eb54b7e1f4 upstream.
Make sure to drop the reference taken when looking up the sync provider device and its driver data during DAI probe on probe failures and on unbind.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
--- sound/soc/stm/stm32_sai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/stm/stm32_sai.c +1 -1
@@ -127,6 +127,7 @@ static int stm32_sai_set_sync(struct stm } sai_provider =platform_get_drvdata (pdev); +put_device (&pdev->dev);if (!sai_provider) {dev_err (&sai_client->pdev->dev,"SAI sync provider data not found\n" );
@@ -143,7 +144,6 @@ static int stm32_sai_set_sync(struct stm ret =stm32_sai_sync_conf_provider (sai_provider, synco); error: -put_device (&pdev->dev);of_node_put (np_provider);return ret; }
Greg Kroah-Hartman
maintainerPATCH 347/567 ASoC: stm32: sai: fix clk prepare imbalance on probe failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 312ec2f0d9d1a5656f76d770bbf1d967e9289aa7 upstream.
Make sure to unprepare the parent clock also on probe failures (e.g. probe deferral).
--- sound/soc/stm/stm32_sai_sub.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-)
sound/soc/stm/stm32_sai_sub.c +21 -7
@@ -1501,14 +1501,21 @@ static int stm32_sai_sub_parse_of(structif (of_property_present (np,"#clock-cells" )) { ret =stm32_sai_add_mclk_provider (sai);if (ret <0 ) -return ret; + goto err_unprepare_pclk; }else { sai->sai_mclk =devm_clk_get_optional (&pdev->dev,"MCLK" ); -if (IS_ERR (sai->sai_mclk)) -return PTR_ERR (sai->sai_mclk); +if (IS_ERR (sai->sai_mclk)) { + ret =PTR_ERR (sai->sai_mclk); + goto err_unprepare_pclk; + } }return 0 ; + +err_unprepare_pclk: +clk_unprepare (sai->pdata->pclk); + +return ret; }static int stm32_sai_sub_probe (struct platform_device *pdev)
@@ -1548,26 +1555,33 @@ static int stm32_sai_sub_probe(struct pl IRQF_SHARED, dev_name(&pdev->dev), sai);if (ret) {dev_err (&pdev->dev,"IRQ request returned %d\n" , ret); -return ret; + goto err_unprepare_pclk; }if (STM_SAI_PROTOCOL_IS_SPDIF (sai)) conf = &stm32_sai_pcm_config_spdif; ret =snd_dmaengine_pcm_register (&pdev->dev, conf,0 ); -if (ret) -return dev_err_probe (&pdev->dev, ret,"Could not register pcm dma\n" ); +if (ret) { + ret =dev_err_probe (&pdev->dev, ret,"Could not register pcm dma\n" ); + goto err_unprepare_pclk; + } ret =snd_soc_register_component (&pdev->dev, &stm32_component, &sai->cpu_dai_drv,1 );if (ret) {snd_dmaengine_pcm_unregister (&pdev->dev); -return ret; + goto err_unprepare_pclk; }pm_runtime_enable (&pdev->dev);return 0 ; + +err_unprepare_pclk: +clk_unprepare (sai->pdata->pclk); + +return ret; }static void stm32_sai_sub_remove (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 348/567 ASoC: stm32: sai: fix OF node leak on probe
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 23261f0de09427367e99f39f588e31e2856a690e upstream.
The reference taken to the sync provider OF node when probing the platform device is currently only dropped if the set_sync() callback fails during DAI probe.
Make sure to drop the reference on platform probe failures (e.g. probe deferral) and on driver unbind.
This also avoids a potential use-after-free in case the DAI is ever reprobed without first rebinding the platform driver.
--- sound/soc/stm/stm32_sai.c | 12 +++--------- sound/soc/stm/stm32_sai_sub.c | 23 ++++++++++++++++------- 2 files changed, 19 insertions(+), 16 deletions(-)
sound/soc/stm/stm32_sai.c +3 -9
@@ -122,7 +122,6 @@ static int stm32_sai_set_sync(struct stmif (!pdev) {dev_err (&sai_client->pdev->dev,"Device not found for node %pOFn\n" , np_provider); -of_node_put (np_provider);return -ENODEV ; }
@@ -131,21 +130,16 @@ static int stm32_sai_set_sync(struct stmif (!sai_provider) {dev_err (&sai_client->pdev->dev,"SAI sync provider data not found\n" ); - ret = -EINVAL ; - goto error; +return -EINVAL ; }/* Configure sync client */ ret =stm32_sai_sync_conf_client (sai_client, synci);if (ret <0 ) - goto error; +return ret;/* Configure sync provider */ - ret =stm32_sai_sync_conf_provider (sai_provider, synco); - -error: -of_node_put (np_provider); -return ret; +return stm32_sai_sync_conf_provider (sai_provider, synco); }static int stm32_sai_probe (struct platform_device *pdev)
sound/soc/stm/stm32_sai_sub.c +16 -7
@@ -1453,7 +1453,8 @@ static int stm32_sai_sub_parse_of(structdev_err (&pdev->dev,"External synchro not supported\n" );of_node_put (args.np); -return -EINVAL ; + ret = -EINVAL ; + goto err_put_sync_provider; } sai->sync =SAI_SYNC_EXTERNAL ;
@@ -1462,7 +1463,8 @@ static int stm32_sai_sub_parse_of(struct (sai->synci > (SAI_GCR_SYNCIN_MAX + 1))) {dev_err (&pdev->dev,"Wrong SAI index\n" );of_node_put (args.np); -return -EINVAL ; + ret = -EINVAL ; + goto err_put_sync_provider; } if (of_property_match_string(args.np, "compatible",
@@ -1476,7 +1478,8 @@ static int stm32_sai_sub_parse_of(structif (!sai->synco) {dev_err (&pdev->dev,"Unknown SAI sub-block\n" );of_node_put (args.np); -return -EINVAL ; + ret = -EINVAL ; + goto err_put_sync_provider; } }
@@ -1486,13 +1489,15 @@ static int stm32_sai_sub_parse_of(structof_node_put (args.np); sai->sai_ck =devm_clk_get (&pdev->dev,"sai_ck" ); -if (IS_ERR (sai->sai_ck)) -return dev_err_probe (&pdev->dev,PTR_ERR (sai->sai_ck), -"Missing kernel clock sai_ck\n" ); +if (IS_ERR (sai->sai_ck)) { + ret =dev_err_probe (&pdev->dev,PTR_ERR (sai->sai_ck), +"Missing kernel clock sai_ck\n" ); + goto err_put_sync_provider; + } ret =clk_prepare (sai->pdata->pclk);if (ret <0 ) -return ret; + goto err_put_sync_provider;if (STM_SAI_IS_F4 (sai->pdata))return 0 ;
@@ -1514,6 +1519,8 @@ static int stm32_sai_sub_parse_of(struct err_unprepare_pclk:clk_unprepare (sai->pdata->pclk); +err_put_sync_provider: +of_node_put (sai->np_sync_provider);return ret; }
@@ -1580,6 +1587,7 @@ static int stm32_sai_sub_probe(struct pl err_unprepare_pclk:clk_unprepare (sai->pdata->pclk); +of_node_put (sai->np_sync_provider);return ret; }
@@ -1592,6 +1600,7 @@ static void stm32_sai_sub_remove(structsnd_dmaengine_pcm_unregister (&pdev->dev);snd_soc_unregister_component (&pdev->dev);pm_runtime_disable (&pdev->dev); +of_node_put (sai->np_sync_provider); }#ifdef CONFIG_PM_SLEEP
Greg Kroah-Hartman
maintainerPATCH 349/567 ASoC: codecs: lpass-tx-macro: fix SM6115 support
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
commit 7c63b5a8ed972a2c8c03d984f6a43349007cea93 upstream.
SM6115 does have soundwire controller in tx. For some reason we ended up with this incorrect patch.
Fix this by adding the flag to reflect this in SoC data.
--- sound/soc/codecs/lpass-tx-macro.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/soc/codecs/lpass-tx-macro.c +2 -1
@@ -2474,7 +2474,8 @@ static const struct tx_macro_data lpass_ };static const struct tx_macro_data lpass_ver_10_sm6115 = { - .flags =LPASS_MACRO_FLAG_HAS_NPL_CLOCK , + .flags =LPASS_MACRO_FLAG_HAS_NPL_CLOCK | +LPASS_MACRO_FLAG_RESET_SWR , .ver =LPASS_VER_10_0_0 , .extra_widgets = tx_macro_dapm_widgets_v9_2, .extra_widgets_num =ARRAY_SIZE (tx_macro_dapm_widgets_v9_2),
Greg Kroah-Hartman
maintainerPATCH 350/567 ASoC: qcom: q6apm-dai: set flags to reflect correct operation of appl_ptr
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
commit 950a4e5788fc7dc6e8e93614a7d4d0449c39fb8d upstream.
Driver does not expect the appl_ptr to move backward and requires explict sync. Make sure that the userspace does not do appl_ptr rewinds by specifying the correct flags in pcm_info.
Without this patch, the result could be a forever loop as current logic assumes that appl_ptr can only move forward.
--- sound/soc/qcom/qdsp6/q6apm-dai.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/qcom/qdsp6/q6apm-dai.c +2 -0
@@ -85,6 +85,7 @@ static const struct snd_pcm_hardware q6a .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_BLOCK_TRANSFER |SNDRV_PCM_INFO_MMAP_VALID |SNDRV_PCM_INFO_INTERLEAVED |SNDRV_PCM_INFO_PAUSE |SNDRV_PCM_INFO_RESUME | +SNDRV_PCM_INFO_NO_REWINDS |SNDRV_PCM_INFO_SYNC_APPLPTR | SNDRV_PCM_INFO_BATCH), .formats = (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE), .rates = SNDRV_PCM_RATE_8000_48000,
@@ -104,6 +105,7 @@ static const struct snd_pcm_hardware q6a .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_BLOCK_TRANSFER |SNDRV_PCM_INFO_MMAP_VALID |SNDRV_PCM_INFO_INTERLEAVED |SNDRV_PCM_INFO_PAUSE |SNDRV_PCM_INFO_RESUME | +SNDRV_PCM_INFO_NO_REWINDS |SNDRV_PCM_INFO_SYNC_APPLPTR | SNDRV_PCM_INFO_BATCH), .formats = (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE), .rates = SNDRV_PCM_RATE_8000_192000,
Greg Kroah-Hartman
maintainerPATCH 351/567 ASoC: qcom: q6asm-dai: perform correct state check before closing
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
commit bfbb12dfa144d45575bcfe139a71360b3ce80237 upstream.
Do not stop a q6asm stream if its not started, this can result in unnecessary dsp command which will timeout anyway something like below:
q6asm-dai ab00000.remoteproc:glink-edge:apr:service@7:dais: CMD 10bcd timeout
Fix this by correctly checking the state.
--- sound/soc/qcom/qdsp6/q6asm-dai.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/soc/qcom/qdsp6/q6asm-dai.c +2 -1
@@ -232,13 +232,14 @@ static int q6asm_dai_prepare(struct snd_ prtd->pcm_count =snd_pcm_lib_period_bytes (substream); prtd->pcm_irq_pos =0 ;/* rate and channels are sent to audio driver */ -if (prtd->state) { +if (prtd->state ==Q6ASM_STREAM_RUNNING ) {/* clear the previous setup if any */ q6asm_cmd (prtd->audio_client, prtd->stream_id,CMD_CLOSE );q6asm_unmap_memory_regions (substream->stream, prtd->audio_client);q6routing_stream_close (soc_prtd->dai_link->id, substream->stream); + prtd->state =Q6ASM_STREAM_STOPPED ; } ret = q6asm_map_memory_regions(substream->stream, prtd->audio_client,
Greg Kroah-Hartman
maintainerPATCH 352/567 ASoC: qcom: q6adm: the the copp device only during last instance
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
commit 74cc4f3ea4e99262ba0d619c6a4ee33e2cd47f65 upstream.
A matching Common object post processing instance is normally resused across multiple streams. However currently we close this on DSP even though there is a refcount on this copp object, this can result in below error.
q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: Found Matching Copp 0x0 qcom-q6adm aprsvc:service:4:8: cmd = 0x10325 return error = 0x2 q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: DSP returned error[2] q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: Found Matching Copp 0x0 qcom-q6adm aprsvc:service:4:8: cmd = 0x10325 return error = 0x2 q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: DSP returned error[2] qcom-q6adm aprsvc:service:4:8: cmd = 0x10327 return error = 0x2 qcom-q6adm aprsvc:service:4:8: DSP returned error[2]
qcom-q6adm aprsvc:service:4:8: Failed to close copp -22
qcom-q6adm aprsvc:service:4:8: cmd = 0x10327 return error = 0x2 qcom-q6adm aprsvc:service:4:8: DSP returned error[2]
qcom-q6adm aprsvc:service:4:8: Failed to close copp -22
Fix this by addressing moving the adm_close to copp_kref destructor callback.
--- sound/soc/qcom/qdsp6/q6adm.c | 146 ++++++++++++++++++++----------------------- 1 file changed, 71 insertions(+), 75 deletions(-)
sound/soc/qcom/qdsp6/q6adm.c +71 -75
@@ -109,11 +109,75 @@ static struct q6copp *q6adm_find_copp(st } +static int q6adm_apr_send_copp_pkt (struct q6adm *adm,struct q6copp *copp, +struct apr_pkt *pkt,uint32_t rsp_opcode) +{ +struct device *dev = adm->dev; +uint32_t opcode = pkt->hdr.opcode; +int ret; + +mutex_lock (&adm->lock); + copp->result.opcode =0 ; + copp->result.status =0 ; + ret =apr_send_pkt (adm->apr, pkt); +if (ret <0 ) { +dev_err (dev,"Failed to send APR packet\n" ); + ret = -EINVAL ; + goto err; + } + +/* Wait for the callback with copp id */ +if (rsp_opcode) + ret =wait_event_timeout (copp->wait, + (copp->result.opcode == opcode) || + (copp->result.opcode == rsp_opcode), +msecs_to_jiffies (TIMEOUT_MS )); +else + ret =wait_event_timeout (copp->wait, + (copp->result.opcode == opcode), +msecs_to_jiffies (TIMEOUT_MS )); + +if (!ret) { +dev_err (dev,"ADM copp cmd timedout\n" ); + ret = -ETIMEDOUT ; + }else if (copp->result.status >0 ) { +dev_err (dev,"DSP returned error[%d]\n" , + copp->result.status); + ret = -EINVAL ; + } + +err: +mutex_unlock (&adm->lock); +return ret; +} + +static int q6adm_device_close (struct q6adm *adm,struct q6copp *copp, +int port_id,int copp_idx) +{ +struct apr_pkt close; + + close.hdr.hdr_field =APR_HDR_FIELD (APR_MSG_TYPE_SEQ_CMD , +APR_HDR_LEN (APR_HDR_SIZE ), +APR_PKT_VER ); + close.hdr.pkt_size =sizeof (close); + close.hdr.src_port = port_id; + close.hdr.dest_port = copp->id; + close.hdr.token = port_id <<16 | copp_idx; + close.hdr.opcode =ADM_CMD_DEVICE_CLOSE_V5 ; + +return q6adm_apr_send_copp_pkt (adm, copp, &close,0 ); +} +static void q6adm_free_copp (struct kref *ref) { struct q6copp *c = container_of(ref, struct q6copp, refcount);struct q6adm *adm = c->adm;unsigned long flags; +int ret; + + ret =q6adm_device_close (adm, c, c->afe_port, c->copp_idx); +if (ret <0 ) +dev_err (adm->dev,"Failed to close copp %d\n" , ret);spin_lock_irqsave (&adm->copps_list_lock, flags);clear_bit (c->copp_idx, &adm->copp_bitmap[c->afe_port]);
@@ -155,13 +219,13 @@ static int q6adm_callback(struct apr_devswitch (result->opcode) {case ADM_CMD_DEVICE_OPEN_V5 :case ADM_CMD_DEVICE_CLOSE_V5 : - copp =q6adm_find_copp (adm, port_idx, copp_idx); -if (!copp) -return 0 ; - - copp->result = *result; -wake_up (&copp->wait); -kref_put (&copp->refcount, q6adm_free_copp); +list_for_each_entry (copp, &adm->copps_list, node) { +if ((port_idx == copp->afe_port) && (copp_idx == copp->copp_idx)) { + copp->result = *result; +wake_up (&copp->wait); +break ; + } + }break ;case ADM_CMD_MATRIX_MAP_ROUTINGS_V5 : adm->result = *result;
@@ -234,65 +298,6 @@ static struct q6copp *q6adm_alloc_copp(sreturn c; } -static int q6adm_apr_send_copp_pkt (struct q6adm *adm,struct q6copp *copp, -struct apr_pkt *pkt,uint32_t rsp_opcode) -{ -struct device *dev = adm->dev; -uint32_t opcode = pkt->hdr.opcode; -int ret; - -mutex_lock (&adm->lock); - copp->result.opcode =0 ; - copp->result.status =0 ; - ret =apr_send_pkt (adm->apr, pkt); -if (ret <0 ) { -dev_err (dev,"Failed to send APR packet\n" ); - ret = -EINVAL ; - goto err; - } - -/* Wait for the callback with copp id */ -if (rsp_opcode) - ret =wait_event_timeout (copp->wait, - (copp->result.opcode == opcode) || - (copp->result.opcode == rsp_opcode), -msecs_to_jiffies (TIMEOUT_MS )); -else - ret =wait_event_timeout (copp->wait, - (copp->result.opcode == opcode), -msecs_to_jiffies (TIMEOUT_MS )); - -if (!ret) { -dev_err (dev,"ADM copp cmd timedout\n" ); - ret = -ETIMEDOUT ; - }else if (copp->result.status >0 ) { -dev_err (dev,"DSP returned error[%d]\n" , - copp->result.status); - ret = -EINVAL ; - } - -err: -mutex_unlock (&adm->lock); -return ret; -} - -static int q6adm_device_close (struct q6adm *adm,struct q6copp *copp, -int port_id,int copp_idx) -{ -struct apr_pkt close; - - close.hdr.hdr_field =APR_HDR_FIELD (APR_MSG_TYPE_SEQ_CMD , -APR_HDR_LEN (APR_HDR_SIZE ), -APR_PKT_VER ); - close.hdr.pkt_size =sizeof (close); - close.hdr.src_port = port_id; - close.hdr.dest_port = copp->id; - close.hdr.token = port_id <<16 | copp_idx; - close.hdr.opcode =ADM_CMD_DEVICE_CLOSE_V5 ; - -return q6adm_apr_send_copp_pkt (adm, copp, &close,0 ); -} - static struct q6copp *q6adm_find_matching_copp(struct q6adm *adm, int port_id, int topology, int mode, int rate,
@@ -567,15 +572,6 @@ EXPORT_SYMBOL_GPL(q6adm_matrix_map);*/ int q6adm_close (struct device *dev,struct q6copp *copp) { -struct q6adm *adm =dev_get_drvdata (dev->parent); -int ret =0 ; - - ret =q6adm_device_close (adm, copp, copp->afe_port, copp->copp_idx); -if (ret <0 ) { -dev_err (adm->dev,"Failed to close copp %d\n" , ret); -return ret; - } -kref_put (&copp->refcount, q6adm_free_copp);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 353/567 ASoC: qcom: qdsp6: q6asm-dai: set 10 ms period and buffer alignment.
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
commit 81c53b52de21b8d5a3de55ebd06b6bf188bf7efd upstream.
DSP expects the periods to be aligned to fragment sizes, currently setting up to hw constriants on periods bytes is not going to work correctly as we can endup with periods sizes aligned to 32 bytes however not aligned to fragment size.
Update the constriants to use fragment size, and also set at step of 10ms for period size to accommodate DSP requirements of 10ms latency.
--- sound/soc/qcom/qdsp6/q6asm-dai.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/qcom/qdsp6/q6asm-dai.c +2 -2
@@ -403,13 +403,13 @@ static int q6asm_dai_open(struct snd_soc } ret =snd_pcm_hw_constraint_step (runtime,0 , -SNDRV_PCM_HW_PARAM_PERIOD_BYTES ,32 ); +SNDRV_PCM_HW_PARAM_PERIOD_SIZE ,480 );if (ret <0 ) {dev_err (dev,"constraint for period bytes step ret = %d\n" , ret); } ret =snd_pcm_hw_constraint_step (runtime,0 , -SNDRV_PCM_HW_PARAM_BUFFER_BYTES ,32 ); +SNDRV_PCM_HW_PARAM_BUFFER_SIZE ,480 );if (ret <0 ) {dev_err (dev,"constraint for buffer bytes step ret = %d\n" , ret);
Greg Kroah-Hartman
maintainerPATCH 354/567 iommu/amd: Fix pci_segment memleak in alloc_pci_segment()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinhui Guo <[email protected]>
commit 75ba146c2674ba49ed8a222c67f9abfb4a4f2a4f upstream.
Fix a memory leak of struct amd_iommu_pci_segment in alloc_pci_segment() when system memory (or contiguous memory) is insufficient.
--- drivers/iommu/amd/init.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/iommu/amd/init.c +12 -3
@@ -1602,13 +1602,22 @@ static struct amd_iommu_pci_seg *__initlist_add_tail (&pci_seg->list, &amd_iommu_pci_seg_list);if (alloc_dev_table (pci_seg)) -return NULL ; + goto err_free_pci_seg;if (alloc_alias_table (pci_seg)) -return NULL ; + goto err_free_dev_table;if (alloc_rlookup_table (pci_seg)) -return NULL ; + goto err_free_alias_table;return pci_seg; + +err_free_alias_table: +free_alias_table (pci_seg); +err_free_dev_table: +free_dev_table (pci_seg); +err_free_pci_seg: +list_del (&pci_seg->list); +kfree (pci_seg); +return NULL ; } static struct amd_iommu_pci_seg *__init get_pci_segment(u16 id,
Greg Kroah-Hartman
maintainerPATCH 355/567 iommu/amd: Propagate the error code returned by __modify_irte_ga() in modify_irte_ga()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinhui Guo <[email protected]>
commit 2381a1b40be4b286062fb3cf67dd7f005692aa2a upstream.
The return type of __modify_irte_ga() is int, but modify_irte_ga() treats it as a bool. Casting the int to bool discards the error code.
To fix the issue, change the type of ret to int in modify_irte_ga().
--- drivers/iommu/amd/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/amd/iommu.c +1 -1
@@ -3172,7 +3172,7 @@ static int __modify_irte_ga(struct amd_istatic int modify_irte_ga (struct amd_iommu *iommu,u16 devid,int index,struct irte_ga *irte) { -bool ret; +int ret; ret =__modify_irte_ga (iommu, devid, index, irte);if (ret)
Greg Kroah-Hartman
maintainerPATCH 356/567 iommu/apple-dart: fix device leak on of_xlate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit a6eaa872c52a181ae9a290fd4e40c9df91166d7a upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate().
--- drivers/iommu/apple-dart.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/iommu/apple-dart.c +2 -0
@@ -790,6 +790,8 @@ static int apple_dart_of_xlate(struct destruct apple_dart *cfg_dart;int i, sid; +put_device (&iommu_pdev->dev); +if (args->args_count !=1 )return -EINVAL ; sid = args->args[0 ];
Greg Kroah-Hartman
maintainerPATCH 357/567 iommu/exynos: fix device leak on of_xlate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 05913cc43cb122f9afecdbe775115c058b906e1b upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate().
Note that commit 1a26044954a6 ("iommu/exynos: add missing put_device() call in exynos_iommu_of_xlate()") fixed the leak in a couple of error paths, but the reference is still leaking on success.
--- drivers/iommu/exynos-iommu.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/iommu/exynos-iommu.c +3 -6
@@ -1443,17 +1443,14 @@ static int exynos_iommu_of_xlate(structreturn -ENODEV ; data =platform_get_drvdata (sysmmu); -if (!data) { -put_device (&sysmmu->dev); +put_device (&sysmmu->dev); +if (!data)return -ENODEV ; - }if (!owner) { owner =kzalloc (sizeof (*owner),GFP_KERNEL ); -if (!owner) { -put_device (&sysmmu->dev); +if (!owner)return -ENOMEM ; - }INIT_LIST_HEAD (&owner->controllers);mutex_init (&owner->rpm_lock);
Greg Kroah-Hartman
maintainerPATCH 358/567 iommu/ipmmu-vmsa: fix device leak on of_xlate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 80aa518452c4aceb9459f9a8e3184db657d1b441 upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate().
--- drivers/iommu/ipmmu-vmsa.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/iommu/ipmmu-vmsa.c +2 -0
@@ -719,6 +719,8 @@ static int ipmmu_init_platform_device(stdev_iommu_priv_set (dev,platform_get_drvdata (ipmmu_pdev)); +put_device (&ipmmu_pdev->dev); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 359/567 iommu/mediatek-v1: fix device leak on probe_device()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit c77ad28bfee0df9cbc719eb5adc9864462cfb65b upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during probe_device().
--- drivers/iommu/mtk_iommu_v1.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/iommu/mtk_iommu_v1.c +2 -0
@@ -423,6 +423,8 @@ static int mtk_iommu_v1_create_mapping(sreturn -EINVAL ;dev_iommu_priv_set (dev,platform_get_drvdata (m4updev)); + +put_device (&m4updev->dev); } ret =iommu_fwspec_add_ids (dev, args->args,1 );
Greg Kroah-Hartman
maintainerPATCH 360/567 iommu/mediatek-v1: fix device leaks on probe()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 46207625c9f33da0e43bb4ae1e91f0791b6ed633 upstream.
Make sure to drop the references taken to the larb devices during probe on probe failure (e.g. probe deferral) and on driver unbind.
--- drivers/iommu/mtk_iommu_v1.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)
drivers/iommu/mtk_iommu_v1.c +18 -5
@@ -647,8 +647,10 @@ static int mtk_iommu_v1_probe(struct plastruct platform_device *plarbdev; larbnode =of_parse_phandle (dev->of_node,"mediatek,larbs" , i); -if (!larbnode) -return -EINVAL ; +if (!larbnode) { + ret = -EINVAL ; + goto out_put_larbs; + }if (!of_device_is_available (larbnode)) {of_node_put (larbnode);
@@ -658,11 +660,14 @@ static int mtk_iommu_v1_probe(struct pla plarbdev =of_find_device_by_node (larbnode);if (!plarbdev) {of_node_put (larbnode); -return -ENODEV ; + ret = -ENODEV ; + goto out_put_larbs; }if (!plarbdev->dev.driver) {of_node_put (larbnode); -return -EPROBE_DEFER ; +put_device (&plarbdev->dev); + ret = -EPROBE_DEFER ; + goto out_put_larbs; } data->larb_imu[i].dev = &plarbdev->dev;
@@ -674,7 +679,7 @@ static int mtk_iommu_v1_probe(struct pla ret =mtk_iommu_v1_hw_init (data);if (ret) -return ret; + goto out_put_larbs; ret =iommu_device_sysfs_add (&data->iommu, &pdev->dev,NULL ,dev_name (&pdev->dev));
@@ -696,12 +701,17 @@ out_sysfs_remove:iommu_device_sysfs_remove (&data->iommu); out_clk_unprepare:clk_disable_unprepare (data->bclk); +out_put_larbs: +for (i =0 ; i <MTK_LARB_NR_MAX ; i++) +put_device (data->larb_imu[i].dev); +return ret; }static void mtk_iommu_v1_remove (struct platform_device *pdev) {struct mtk_iommu_v1_data *data =platform_get_drvdata (pdev); +int i;iommu_device_sysfs_remove (&data->iommu);iommu_device_unregister (&data->iommu);
@@ -709,6 +719,9 @@ static void mtk_iommu_v1_remove(struct pclk_disable_unprepare (data->bclk);devm_free_irq (&pdev->dev, data->irq, data);component_master_del (&pdev->dev, &mtk_iommu_v1_com_ops); + +for (i =0 ; i <MTK_LARB_NR_MAX ; i++) +put_device (data->larb_imu[i].dev); }static int __maybe_unused mtk_iommu_v1_suspend (struct device *dev)
Greg Kroah-Hartman
maintainerPATCH 361/567 iommu/mediatek: fix device leak on of_xlate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit b3f1ee18280363ef17f82b564fc379ceba9ec86f upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate().
--- drivers/iommu/mtk_iommu.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/iommu/mtk_iommu.c +2 -0
@@ -975,6 +975,8 @@ static int mtk_iommu_of_xlate(struct devreturn -EINVAL ;dev_iommu_priv_set (dev,platform_get_drvdata (m4updev)); + +put_device (&m4updev->dev); }return iommu_fwspec_add_ids (dev, args->args,1 );
Greg Kroah-Hartman
maintainerPATCH 362/567 iommu/omap: fix device leaks on probe_device()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit b5870691065e6bbe6ba0650c0412636c6a239c5a upstream.
Make sure to drop the references taken to the iommu platform devices when looking up their driver data during probe_device().
Note that the arch data device pointer added by commit 604629bcb505 ("iommu/omap: add support for late attachment of iommu devices") has never been used. Remove it to underline that the references are not needed.
--- drivers/iommu/omap-iommu.c | 2 +- drivers/iommu/omap-iommu.h | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-)
drivers/iommu/omap-iommu.c +1 -1
@@ -1688,6 +1688,7 @@ static struct iommu_device *omap_iommu_p } oiommu =platform_get_drvdata (pdev); +put_device (&pdev->dev);if (!oiommu) {of_node_put (np);kfree (arch_data);
@@ -1695,7 +1696,6 @@ static struct iommu_device *omap_iommu_p } tmp->iommu_dev = oiommu; - tmp->dev = &pdev->dev;of_node_put (np); }
drivers/iommu/omap-iommu.h +0 -2
@@ -88,7 +88,6 @@ struct omap_iommu {/** * struct omap_iommu_arch_data - omap iommu private data * @iommu_dev: handle of the OMAP iommu device -* @dev: handle of the iommu device * * This is an omap iommu private data object, which binds an iommu user * to its iommu device. This object should be placed at the iommu user's
@@ -97,7 +96,6 @@ struct omap_iommu {*/ struct omap_iommu_arch_data {struct omap_iommu *iommu_dev; -struct device *dev; };struct cr_regs {
Greg Kroah-Hartman
maintainerPATCH 363/567 iommu/qcom: fix device leak on of_xlate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 6a3908ce56e6879920b44ef136252b2f0c954194 upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate().
Note that commit e2eae09939a8 ("iommu/qcom: add missing put_device() call in qcom_iommu_of_xlate()") fixed the leak in a couple of error paths, but the reference is still leaking on success and late failures.
--- drivers/iommu/arm/arm-smmu/qcom_iommu.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/iommu/arm/arm-smmu/qcom_iommu.c +4 -6
@@ -566,14 +566,14 @@ static int qcom_iommu_of_xlate(struct de qcom_iommu =platform_get_drvdata (iommu_pdev); +put_device (&iommu_pdev->dev); +/* make sure the asid specified in dt is valid, so we don't have * to sanity check this elsewhere: */ if (WARN_ON (asid > qcom_iommu->max_asid) || -WARN_ON (qcom_iommu->ctxs[asid] ==NULL )) { -put_device (&iommu_pdev->dev); +WARN_ON (qcom_iommu->ctxs[asid] ==NULL ))return -EINVAL ; - }if (!dev_iommu_priv_get (dev)) {dev_iommu_priv_set (dev, qcom_iommu);
@@ -582,10 +582,8 @@ static int qcom_iommu_of_xlate(struct de* multiple different iommu devices. Multiple context * banks are ok, but multiple devices are not: */ -if (WARN_ON (qcom_iommu !=dev_iommu_priv_get (dev))) { -put_device (&iommu_pdev->dev); +if (WARN_ON (qcom_iommu !=dev_iommu_priv_get (dev)))return -EINVAL ; - } }return iommu_fwspec_add_ids (dev, &asid,1 );
Greg Kroah-Hartman
maintainerPATCH 364/567 iommu/sun50i: fix device leak on of_xlate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit f916109bf53864605d10bf6f4215afa023a80406 upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate().
--- drivers/iommu/sun50i-iommu.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/iommu/sun50i-iommu.c +2 -0
@@ -837,6 +837,8 @@ static int sun50i_iommu_of_xlate(structdev_iommu_priv_set (dev,platform_get_drvdata (iommu_pdev)); +put_device (&iommu_pdev->dev); +return iommu_fwspec_add_ids (dev, &id,1 ); }
Greg Kroah-Hartman
maintainerPATCH 365/567 iommu/tegra: fix device leak on probe_device()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit c08934a61201db8f1d1c66fcc63fb2eb526b656d upstream.
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during probe_device().
Note that commit 9826e393e4a8 ("iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find") fixed the leak in an error path, but the reference is still leaking on success.
--- drivers/iommu/tegra-smmu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/iommu/tegra-smmu.c +2 -3
@@ -823,10 +823,9 @@ static struct tegra_smmu *tegra_smmu_finreturn NULL ; mc =platform_get_drvdata (pdev); -if (!mc) { -put_device (&pdev->dev); +put_device (&pdev->dev); +if (!mc)return NULL ; - }return mc->smmu; }
Greg Kroah-Hartman
maintainerPATCH 366/567 iommu: disable SVA when CONFIG_X86 is set
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <[email protected]>
commit 72f98ef9a4be30d2a60136dd6faee376f780d06c upstream.
Patch series "Fix stale IOTLB entries for kernel address space", v7.
This proposes a fix for a security vulnerability related to IOMMU Shared Virtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel page table entries. When a kernel page table page is freed and reallocated for another purpose, the IOMMU might still hold stale, incorrect entries. This can be exploited to cause a use-after-free or write-after-free condition, potentially leading to privilege escalation or data corruption.
This solution introduces a deferred freeing mechanism for kernel page table pages, which provides a safe window to notify the IOMMU to invalidate its caches before the page is reused.
This patch (of 8):
In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. The x86 architecture maps the kernel's virtual address space into the upper portion of every process's page table. Consequently, in an SVA context, the IOMMU hardware can walk and cache kernel page table entries.
The Linux kernel currently lacks a notification mechanism for kernel page table changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual address mappings. This can cause the IOMMU's internal caches to retain stale entries for kernel VA.
Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when kernel page table pages are freed and later reallocated. The IOMMU could misinterpret the new data as valid page table entries. The IOMMU might then walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation. This is also a Write-After-Free issue, as the IOMMU will potentially continue to write Accessed and Dirty bits to the freed memory while attempting to walk the stale page tables.
Currently, SVA contexts are unprivileged and cannot access kernel mappings. However, the IOMMU will still walk kernel-only page tables all the way down to the leaf entries, where it realizes the mapping is for the kernel and errors out. This means the IOMMU still caches these intermediate page table entries, making the described vulnerability a real concern.
Disable SVA on x86 architecture until the IOMMU can receive notification to flush the paging cache before freeing the CPU kernel page table pages.
--- drivers/iommu/iommu-sva.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/iommu/iommu-sva.c +3 -0
@@ -80,6 +80,9 @@ struct iommu_sva *iommu_sva_bind_device(if (!group)return ERR_PTR (-ENODEV ); +if (IS_ENABLED (CONFIG_X86 )) +return ERR_PTR (-EOPNOTSUPP ); +mutex_lock (&iommu_sva_lock);/* Allocate mm->pasid if necessary. */
Greg Kroah-Hartman
maintainerPATCH 367/567 HID: logitech-dj: Remove duplicate error logging
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit ca389a55d8b2d86a817433bf82e0602b68c4d541 upstream.
logi_dj_recv_query_paired_devices() and logi_dj_recv_switch_to_dj_mode() both have 2 callers which all log an error if the function fails. Move the error logging to inside these 2 functions to remove the duplicated error logging in the callers.
While at it also move the logi_dj_recv_send_report() call error handling in logi_dj_recv_switch_to_dj_mode() to directly after the call. That call only fails if the report cannot be found and in that case it does nothing, so the msleep() is not necessary on failures.
--- drivers/hid/hid-logitech-dj.c | 56 +++++++++++++++++------------------------- 1 file changed, 23 insertions(+), 33 deletions(-)
drivers/hid/hid-logitech-dj.c +23 -33
@@ -805,7 +805,6 @@ static void delayedwork_callback(structstruct dj_workitem workitem;unsigned long flags;int count; -int retval;dbg_hid ("%s\n" , __func__);
@@ -842,11 +841,7 @@ static void delayedwork_callback(structlogi_dj_recv_destroy_djhid_device (djrcv_dev, &workitem);break ;case WORKITEM_TYPE_UNKNOWN : - retval =logi_dj_recv_query_paired_devices (djrcv_dev); -if (retval) { -hid_err (djrcv_dev->hidpp,"%s: logi_dj_recv_query_paired_devices error: %d\n" , - __func__, retval); - } +logi_dj_recv_query_paired_devices (djrcv_dev);break ;case WORKITEM_TYPE_EMPTY :dbg_hid ("%s: device list is empty\n" , __func__);
@@ -1239,8 +1234,10 @@ static int logi_dj_recv_query_paired_dev djrcv_dev->last_query = jiffies; -if (djrcv_dev->type != recvr_type_dj) -return logi_dj_recv_query_hidpp_devices (djrcv_dev); +if (djrcv_dev->type != recvr_type_dj) { + retval =logi_dj_recv_query_hidpp_devices (djrcv_dev); + goto out; + } dj_report =kzalloc (sizeof (struct dj_report ),GFP_KERNEL );if (!dj_report)
@@ -1250,6 +1247,10 @@ static int logi_dj_recv_query_paired_dev dj_report->report_type =REPORT_TYPE_CMD_GET_PAIRED_DEVICES ; retval =logi_dj_recv_send_report (djrcv_dev, dj_report);kfree (dj_report); +out: +if (retval <0 ) +hid_err (djrcv_dev->hidpp,"%s error:%d\n" , __func__, retval); +return retval; }
@@ -1275,6 +1276,8 @@ static int logi_dj_recv_switch_to_dj_mod (u8 )timeout; retval =logi_dj_recv_send_report (djrcv_dev, dj_report); +if (retval) + goto out;/* * Ugly sleep to work around a USB 3.0 bug when the receiver is
@@ -1283,11 +1286,6 @@ static int logi_dj_recv_switch_to_dj_mod* 50 msec should gives enough time to the receiver to be ready. */ msleep (50 ); - -if (retval) { -kfree (dj_report); -return retval; - } }/*
@@ -1313,7 +1311,12 @@ static int logi_dj_recv_switch_to_dj_modHIDPP_REPORT_SHORT_LENGTH ,HID_OUTPUT_REPORT , HID_REQ_SET_REPORT); +out:kfree (dj_report); + +if (retval <0 ) +hid_err (hdev,"%s error:%d\n" , __func__, retval); +return retval; }
@@ -1835,11 +1838,8 @@ static int logi_dj_probe(struct hid_deviif (has_hidpp) { retval =logi_dj_recv_switch_to_dj_mode (djrcv_dev,0 ); -if (retval <0 ) { -hid_err (hdev,"%s: logi_dj_recv_switch_to_dj_mode returned error:%d\n" , - __func__, retval); +if (retval <0 ) goto switch_to_dj_mode_fail; - } }/* This is enabling the polling urb on the IN endpoint */
@@ -1857,15 +1857,11 @@ static int logi_dj_probe(struct hid_devispin_lock_irqsave (&djrcv_dev->lock, flags); djrcv_dev->ready = true;spin_unlock_irqrestore (&djrcv_dev->lock, flags); - retval =logi_dj_recv_query_paired_devices (djrcv_dev); -if (retval <0 ) { -hid_err (hdev,"%s: logi_dj_recv_query_paired_devices error:%d\n" , - __func__, retval); -/* -* This can happen with a KVM, let the probe succeed, -* logi_dj_recv_queue_unknown_work will retry later. -*/ - } +/* +* This can fail with a KVM. Ignore errors to let the probe +* succeed, logi_dj_recv_queue_unknown_work will retry later. +*/ +logi_dj_recv_query_paired_devices (djrcv_dev); }return 0 ;
@@ -1882,18 +1878,12 @@ hid_hw_start_fail:#ifdef CONFIG_PM static int logi_dj_reset_resume (struct hid_device *hdev) { -int retval;struct dj_receiver_dev *djrcv_dev =hid_get_drvdata (hdev);if (!djrcv_dev || djrcv_dev->hidpp != hdev)return 0 ; - retval =logi_dj_recv_switch_to_dj_mode (djrcv_dev,0 ); -if (retval <0 ) { -hid_err (hdev,"%s: logi_dj_recv_switch_to_dj_mode returned error:%d\n" , - __func__, retval); - } - +logi_dj_recv_switch_to_dj_mode (djrcv_dev,0 );return 0 ; }#endif
Greg Kroah-Hartman
maintainerPATCH 368/567 fgraph: Initialize ftrace_ops->private for function graph ops
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shengming Hu <[email protected]>
commit b5d6d3f73d0bac4a7e3a061372f6da166fc6ee5c upstream.
The ftrace_pids_enabled(op) check relies on op->private being properly initialized, but fgraph_ops's underlying ftrace_ops->private was left uninitialized. This caused ftrace_pids_enabled() to always return false, effectively disabling PID filtering for function graph tracing.
Fix this by copying src_ops->private to dst_ops->private in fgraph_init_ops(), ensuring PID filter state is correctly propagated.
--- kernel/trace/fgraph.c | 1 + 1 file changed, 1 insertion(+)
kernel/trace/fgraph.c +1 -0
@@ -943,6 +943,7 @@ void fgraph_init_ops(struct ftrace_ops *mutex_init (&dst_ops->local_hash.regex_lock);INIT_LIST_HEAD (&dst_ops->subop_list); dst_ops->flags |=FTRACE_OPS_FL_INITIALIZED ; + dst_ops->private = src_ops->private; }#endif }
Greg Kroah-Hartman
maintainerPATCH 369/567 fgraph: Check ftrace_pids_enabled on registration for early filtering
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shengming Hu <[email protected]>
commit 1650a1b6cb1ae6cb99bb4fce21b30ebdf9fc238e upstream.
When registering ftrace_graph, check if ftrace_pids_enabled is active. If enabled, assign entryfunc to fgraph_pid_func to ensure filtering is performed before executing the saved original entry function.
--- kernel/trace/fgraph.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
kernel/trace/fgraph.c +7 -2
@@ -1286,6 +1286,13 @@ int register_ftrace_graph(struct fgraph_ ftrace_graph_active++; +/* Always save the function, and reset at unregistering */ + gops->saved_func = gops->entryfunc; +#ifdef CONFIG_DYNAMIC_FTRACE +if (ftrace_pids_enabled (&gops->ops)) + gops->entryfunc = fgraph_pid_func; +#endif +if (ftrace_graph_active ==2 )ftrace_graph_disable_direct (true);
@@ -1305,8 +1312,6 @@ int register_ftrace_graph(struct fgraph_ }else {init_task_vars (gops->idx); } -/* Always save the function, and reset at unregistering */ - gops->saved_func = gops->entryfunc; ret =ftrace_startup_subops (&graph_ops, &gops->ops, command);if (!ret)
Greg Kroah-Hartman
maintainerPATCH 370/567 PCI/PM: Reinstate clearing state_saved in legacy and !PM codepaths
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
commit 894f475f88e06c0f352c829849560790dbdedbe5 upstream.
When a PCI device is suspended, it is normally the PCI core's job to save Config Space and put the device into a low power state. However drivers are allowed to assume these responsibilities. When they do, the PCI core can tell by looking at the state_saved flag in struct pci_dev: The flag is cleared before commencing the suspend sequence and it is set when pci_save_state() is called. If the PCI core finds the flag set late in the suspend sequence, it refrains from calling pci_save_state() itself.
But there are two corner cases where the PCI core neglects to clear the flag before commencing the suspend sequence:
* If a driver has legacy PCI PM callbacks, pci_legacy_suspend() neglects to clear the flag. The (stale) flag is subsequently queried by pci_legacy_suspend() itself and pci_legacy_suspend_late().
* If a device has no driver or its driver has no PCI PM callbacks, pci_pm_freeze() neglects to clear the flag. The (stale) flag is subsequently queried by pci_pm_freeze_noirq().
The flag may be set prior to suspend if the device went through error
recovery: Drivers commonly invoke pci_restore_state() + pci_save_state() to restore Config Space after reset.
The flag may also be set if drivers call pci_save_state() on probe to allow for recovery from subsequent errors.
The result is that pci_legacy_suspend_late() and pci_pm_freeze_noirq() don't call pci_save_state() and so the state that will be restored on resume is the one recorded on last error recovery or on probe, not the one that the device had on suspend. If the two states happen to be identical, there's no problem.
Reinstate clearing the flag in pci_legacy_suspend() and pci_pm_freeze(). The two functions used to do that until commit 4b77b0a2ba27 ("PCI: Clear saved_state after the state has been restored") deemed it unnecessary because it assumed that it's sufficient to clear the flag on resume in pci_restore_state(). The commit seemingly did not take into account that pci_save_state() and pci_restore_state() are not only used by power management code, but also for error recovery.
Devices without driver or whose driver has no PCI PM callbacks may be in runtime suspend when pci_pm_freeze() is called. Their state has already been saved, so don't clear the flag to skip a pointless pci_save_state() in pci_pm_freeze_noirq().
None of the drivers with legacy PCI PM callbacks seem to use runtime PM, so clear the flag unconditionally in their case.
--- drivers/pci/pci-driver.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/pci-driver.c +4 -0
@@ -635,6 +635,8 @@ static int pci_legacy_suspend(struct devstruct pci_dev *pci_dev =to_pci_dev (dev);struct pci_driver *drv = pci_dev->driver; + pci_dev->state_saved = false; +if (drv && drv->suspend) {pci_power_t prev = pci_dev->current_state;int error;
@@ -1039,6 +1041,8 @@ static int pci_pm_freeze(struct device *if (!pm) {pci_pm_default_suspend (pci_dev); +if (!pm_runtime_suspended (dev)) + pci_dev->state_saved = false;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 371/567 arm64: dts: ti: k3-j721e-sk: Fix pinmux for pin Y1 used by power regulator
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Siddharth Vadapalli <[email protected]>
commit 51f89c488f2ecc020f82bfedd77482584ce8027a upstream.
The SoC pin Y1 is incorrectly defined in the WKUP Pinmux device-tree node (pinctrl@4301c000) leading to the following silent failure:
pinctrl-single 4301c000.pinctrl: mux offset out of range: 0x1dc (0x178)
According to the datasheet for the J721E SoC [0], the pin Y1 belongs to the MAIN Pinmux device-tree node (pinctrl@11c000). This is confirmed by the address of the pinmux register for it on page 142 of the datasheet which is 0x00011C1DC.
Hence fix it.
[0]: https://www.ti.com/lit/ds/symlink/tda4vm.pdf
--- arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
arch/arm64/boot/dts/ti/k3-j721e-sk.dts +6 -6
@@ -572,6 +572,12 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) EXT_REFCLK1.GPIO1_12 */ >; }; + + vdd_sd_dv_pins_default: vdd-sd-dv-default-pins { + pinctrl-single,pins = < + J721E_IOPAD(0x1dc, PIN_OUTPUT, 7) /* (Y1) SPI1_CLK.GPIO0_118 */ + >; + }; }; &wkup_pmx0 {
@@ -633,12 +639,6 @@ >; }; - vdd_sd_dv_pins_default: vdd-sd-dv-default-pins { - pinctrl-single,pins = < - J721E_IOPAD(0x1dc, PIN_OUTPUT, 7) /* (Y1) SPI1_CLK.GPIO0_118 */ - >; - }; - wkup_uart0_pins_default: wkup-uart0-default-pins { pinctrl-single,pins = < J721E_WKUP_IOPAD(0xa0, PIN_INPUT, 0) /* (J29) WKUP_UART0_RXD */
Greg Kroah-Hartman
maintainerPATCH 372/567 powerpc, mm: Fix mprotect on book3s 32-bit
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Vasilevsky <[email protected]>
commit 78fc63ffa7813e33681839bb33826c24195f0eb7 upstream.
On 32-bit book3s with hash-MMUs, tlb_flush() was a no-op. This was unnoticed because all uses until recently were for unmaps, and thus handled by __tlb_remove_tlb_entry().
After commit 4a18419f71cd ("mm/mprotect: use mmu_gather") in kernel 5.19, tlb_gather_mmu() started being used for mprotect as well. This caused mprotect to simply not work on these machines:
int *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
*ptr = 1; // force HPTE to be created
mprotect(ptr, 4096, PROT_READ);
*ptr = 2; // should segfault, but succeeds
Fixed by making tlb_flush() actually flush TLB pages. This finally agrees with the behaviour of boot3s64's tlb_flush().
--- arch/powerpc/include/asm/book3s/32/tlbflush.h | 5 ++++- arch/powerpc/mm/book3s32/tlb.c | 9 +++++++++ 2 files changed, 13 insertions(+), 1 deletion(-)
arch/powerpc/include/asm/book3s/32/tlbflush.h +4 -1
@@ -11,6 +11,7 @@void hash__flush_tlb_mm (struct mm_struct *mm);void hash__flush_tlb_page (struct vm_area_struct *vma,unsigned long vmaddr);void hash__flush_range (struct mm_struct *mm,unsigned long start,unsigned long end); +void hash__flush_gather (struct mmu_gather *tlb);#ifdef CONFIG_SMP void _tlbie (unsigned long address);
@@ -29,7 +30,9 @@ void _tlbia(void);static inline void tlb_flush (struct mmu_gather *tlb) {/* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ -if (!mmu_has_feature (MMU_FTR_HPTE_TABLE )) +if (mmu_has_feature (MMU_FTR_HPTE_TABLE )) +hash__flush_gather (tlb); +else _tlbia (); }
arch/powerpc/mm/book3s32/tlb.c +9 -0
@@ -105,3 +105,12 @@ void hash__flush_tlb_page(struct vm_areaflush_hash_pages (mm->context.id, vmaddr,pmd_val (*pmd),1 ); }EXPORT_SYMBOL (hash__flush_tlb_page); + +void hash__flush_gather (struct mmu_gather *tlb) +{ +if (tlb->fullmm || tlb->need_flush_all) +hash__flush_tlb_mm (tlb->mm); +else +hash__flush_range (tlb->mm, tlb->start, tlb->end); +} +EXPORT_SYMBOL (hash__flush_gather);
Greg Kroah-Hartman
maintainerPATCH 373/567 powerpc/64s/slb: Fix SLB multihit issue during SLB preload
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Donet Tom <[email protected]>
commit 00312419f0863964625d6dcda8183f96849412c6 upstream.
On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry.
To optimize performance, the kernel skips switch_mmu_context() in switch_mm_irqs_off() when the prev and next mm_struct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache.
If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switch_mmu_context(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error.
The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch.
CPU 0 CPU 1
----- -----
Process P
exec swapper/1
load_elf_binary
begin_new_exc
activate_mm
switch_mm_irqs_off
switch_mmu_context
switch_slb
/*
* This invalidates all
* the entries in the HW
* and setup the new HW
* SLB entries as per the
* preload cache.
*/context_switchsched_migrate_task migrates process P to cpu-1
Process swapper/0 context switch (to process P)
(uses mm_struct of Process P) switch_mm_irqs_off()
switch_slb
load_slb++
/*
* load_slb becomes 0 here
* and we evict an entry from
* the preload cache with
* preload_age(). We still
* keep HW SLB and preload
* cache in sync, that is
* because all HW SLB entries
* anyways gets evicted in
* switch_slb during SLBIA.
* We then only add those
* entries back in HW SLB,
* which are currently
* present in preload_cache
* (after eviction). */
load_elf_binary continues...
setup_new_exec()
slb_setup_new_exec()
sched_switch event sched_migrate_task migrates process P to cpu-0
context_switch from swapper/0 to Process P
switch_mm_irqs_off()
/*
* Since both prev and next mm struct are same we don't call
* switch_mmu_context(). This will cause the HW SLB and SW preload
* cache to go out of sync in preload_new_slb_context. Because there
* was an SLB entry which was evicted from both HW and preload cache
* on cpu-1. Now later in preload_new_slb_context(), when we will try
* to add the same preload entry again, we will add this to the SW
* preload cache and then will add it to the HW SLB. Since on cpu-0
* this entry was never invalidated, hence adding this entry to the HW
* SLB will cause a SLB multi-hit error.
*/load_elf_binary continues...
START_THREAD
start_thread
preload_new_slb_context
/*
* This tries to add a new EA to preload cache which was earlier
* evicted from both cpu-1 HW SLB and preload cache. This caused the
* HW SLB of cpu-0 to go out of sync with the SW preload cache. The
* reason for this was, that when we context switched back on CPU-0,
* we should have ideally called switch_mmu_context() which will
* bring the HW SLB entries on CPU-0 in sync with SW preload cache
* entries by setting up the mmu context properly. But we didn't do
* that since the prev mm_struct running on cpu-0 was same as the
* next mm_struct (which is true for swapper / kernel threads). So
* now when we try to add this new entry into the HW SLB of cpu-0,
* we hit a SLB multi-hit error.
*/
WARNING: CPU: 0 PID: 1810970 at arch/powerpc/mm/book3s64/slb.c:62 assert_slb_presence+0x2c/0x50(48 results) 02:47:29 [20157/42149] Modules linked in: CPU: 0 UID: 0 PID: 1810970 Comm: dd Not tainted 6.16.0-rc3-dirty #12 VOLUNTARY Hardware name: IBM pSeries (emulated by qemu) POWER8 (architected) 0x4d0200 0xf000004 of:SLOF,HEAD hv:linux,kvm pSeries NIP: c00000000015426c LR: c0000000001543b4 CTR: 0000000000000000 REGS: c0000000497c77e0 TRAP: 0700 Not tainted (6.16.0-rc3-dirty) MSR: 8000000002823033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 28888482 XER: 00000000 CFAR: c0000000001543b0 IRQMASK: 3 <...> NIP [c00000000015426c] assert_slb_presence+0x2c/0x50 LR [c0000000001543b4] slb_insert_entry+0x124/0x390 Call Trace: 0x7fffceb5ffff (unreliable) preload_new_slb_context+0x100/0x1a0 start_thread+0x26c/0x420 load_elf_binary+0x1b04/0x1c40 bprm_execve+0x358/0x680 do_execveat_common+0x1f8/0x240 sys_execve+0x58/0x70 system_call_exception+0x114/0x300 system_call_common+0x160/0x2c4
Quoted 1 line
From the above analysis, during early exec the hardware SLB is cleared,
and entries from the software preload cache are reloaded into hardware by switch_slb. However, preload_new_slb_context and slb_setup_new_exec also attempt to load some of the same entries, which can trigger a multi-hit. In most cases, these additional preloads simply hit existing entries and add nothing new. Removing these functions avoids redundant preloads and eliminates the multi-hit issue. This patch removes these two functions.
We tested process switching performance using the context_switch benchmark on POWER9/hash, and observed no regression.
Without this patch: 129041 ops/sec With this patch: 129341 ops/sec
We also measured SLB faults during boot, and the counts are essentially the same with and without this patch.
SLB faults without this patch: 19727 SLB faults with this patch: 19786
--- arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 arch/powerpc/kernel/process.c | 5 - arch/powerpc/mm/book3s64/internal.h | 2 arch/powerpc/mm/book3s64/mmu_context.c | 2 arch/powerpc/mm/book3s64/slb.c | 88 -------------------------- 5 files changed, 98 deletions(-)
arch/powerpc/include/asm/book3s/64/mmu-hash.h +0 -1
@@ -524,7 +524,6 @@ void slb_save_contents(struct slb_entryvoid slb_dump_contents (struct slb_entry *slb_ptr);extern void slb_vmalloc_update (void ); -void preload_new_slb_context (unsigned long start,unsigned long sp);#ifdef CONFIG_PPC_64S_HASH_MMU void slb_set_size (u16 size);
arch/powerpc/kernel/process.c +0 -5
@@ -1897,8 +1897,6 @@ int copy_thread(struct task_struct *p, creturn 0 ; } -void preload_new_slb_context (unsigned long start,unsigned long sp); -/* * Set up a thread for executing a new program */
@@ -1906,9 +1904,6 @@ void start_thread(struct pt_regs *regs, {#ifdef CONFIG_PPC64 unsigned long load_addr = regs->gpr[2 ];/* saved by ELF_PLAT_INIT */ - -if (IS_ENABLED (CONFIG_PPC_BOOK3S_64 ) && !radix_enabled ()) -preload_new_slb_context (start, sp);#endif #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
arch/powerpc/mm/book3s64/internal.h +0 -2
@@ -24,8 +24,6 @@ static inline bool stress_hpt(void)void hpt_do_stress (unsigned long ea,unsigned long hpte_group); -void slb_setup_new_exec (void ); -void exit_lazy_flush_tlb (struct mm_struct *mm,bool always_flush);#endif /* ARCH_POWERPC_MM_BOOK3S64_INTERNAL_H */
arch/powerpc/mm/book3s64/mmu_context.c +0 -2
@@ -150,8 +150,6 @@ static int hash__init_new_context(structvoid hash__setup_new_exec (void ) {slice_setup_new_exec (); - -slb_setup_new_exec (); }#else static inline int hash__init_new_context (struct mm_struct *mm)
arch/powerpc/mm/book3s64/slb.c +0 -88
94 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 374/567 leds: leds-cros_ec: Skip LEDs without color components
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weißschuh <[email protected]>
commit 4dbf066d965cd3299fb396f1375d10423c9c625c upstream.
A user reports that on their Lenovo Corsola Magneton with EC firmware steelix-15194.270.0 the driver probe fails with EINVAL. It turns out that the power LED does not contain any color components as indicated by the following "ectool led power query" output:
Brightness range for LED 1:
red : 0x0
green : 0x0
blue : 0x0
yellow : 0x0
white : 0x0
amber : 0x0The LED also does not react to commands sent manually through ectool and is generally non-functional.
Instead of failing the probe for all LEDs managed by the EC when one without color components is encountered, silently skip those.
--- drivers/leds/leds-cros_ec.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/leds/leds-cros_ec.c +2 -3
@@ -155,9 +155,6 @@ static int cros_ec_led_count_subleds(str } } -if (!num_subleds) -return -EINVAL ; - *max_brightness = common_range;return num_subleds; }
@@ -202,6 +199,8 @@ static int cros_ec_led_probe_one(struct &priv->led_mc_cdev.led_cdev.max_brightness);if (num_subleds <0 )return num_subleds; +if (num_subleds ==0 ) +return 0 ;/* LED without any colors, skip */ priv->cros_ec = cros_ec; priv->led_id = id;
Greg Kroah-Hartman
maintainerPATCH 375/567 leds: leds-lp50xx: Allow LED 0 to be added to module bank
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Hitz <[email protected]>
commit 26fe74d598c32e7bc6f150edfc4aa43e1bee55db upstream.
led_banks contains LED module number(s) that should be grouped into the module bank. led_banks is 0-initialized.
By checking the led_banks entries for 0, un-set entries are detected. But a 0-entry also indicates that LED module 0 should be grouped into the module bank.
By only iterating over the available entries no check for unused entries is required and LED module 0 can be added to bank.
--- drivers/leds/leds-lp50xx.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/leds/leds-lp50xx.c +4 -6
@@ -343,17 +343,15 @@ out:return ret; } -static int lp50xx_set_banks (struct lp50xx *priv,u32 led_banks[]) +static int lp50xx_set_banks (struct lp50xx *priv,u32 led_banks[],int num_leds) {u8 led_config_lo, led_config_hi;u32 bank_enable_mask =0 ;int ret;int i; -for (i =0 ; i < priv->chip_info->max_modules; i++) { -if (led_banks[i]) - bank_enable_mask |= (1 << led_banks[i]); - } +for (i =0 ; i < num_leds; i++) + bank_enable_mask |= (1 << led_banks[i]); led_config_lo = bank_enable_mask; led_config_hi = bank_enable_mask >>8 ;
@@ -407,7 +405,7 @@ static int lp50xx_probe_leds(struct fwnoreturn ret; } - ret =lp50xx_set_banks (priv, led_banks); + ret =lp50xx_set_banks (priv, led_banks, num_leds);if (ret) {dev_err (priv->dev,"Cannot setup banked LEDs\n" );return ret;
Greg Kroah-Hartman
maintainerPATCH 376/567 leds: leds-lp50xx: LP5009 supports 3 modules for a total of 9 LEDs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Hitz <[email protected]>
commit 5246e3673eeeccb4f5bf4f42375dd495d465ac15 upstream.
LP5009 supports 9 LED outputs that are grouped into 3 modules.
--- drivers/leds/leds-lp50xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/leds/leds-lp50xx.c +1 -1
@@ -56,7 +56,7 @@/* There are 3 LED outputs per bank */ #define LP50XX_LEDS_PER_MODULE 3 -#define LP5009_MAX_LED_MODULES 2 +#define LP5009_MAX_LED_MODULES 3#define LP5012_MAX_LED_MODULES 4#define LP5018_MAX_LED_MODULES 6#define LP5024_MAX_LED_MODULES 8
Greg Kroah-Hartman
maintainerPATCH 377/567 leds: leds-lp50xx: Enable chip before any communication
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Hitz <[email protected]>
commit 434959618c47efe9e5f2e20f4a850caac4f6b823 upstream.
If a GPIO is used to control the chip's enable pin, it needs to be pulled high before any i2c communication is attempted.
Currently, the enable GPIO handling is not correct.
Assume the enable GPIO is low when the probe function is entered. In this case the device is in SHUTDOWN mode and does not react to i2c commands.
During probe the following sequence happens:
1. The call to lp50xx_reset() on line 548 has no effect as i2c is not possible yet.
2. Then - on line 552 - lp50xx_enable_disable() is called. As "priv->enable_gpio“ has not yet been initialized, setting the GPIO has no effect. Also the i2c enable command is not executed as the device is still in SHUTDOWN.
3. On line 556 the call to lp50xx_probe_dt() finally parses the rest of
the DT and the configured priv->enable_gpio is set up.
As a result the device is still in SHUTDOWN mode and not ready for operation.
Split lp50xx_enable_disable() into distinct enable and disable functions to enforce correct ordering between enable_gpio manipulations and i2c commands.
Read enable_gpio configuration from DT before attempting to manipulate enable_gpio.
Add delays to observe correct wait timing after manipulating enable_gpio and before any i2c communication.
--- drivers/leds/leds-lp50xx.c | 55 ++++++++++++++++++++++++++++++++------------- 1 file changed, 40 insertions(+), 15 deletions(-)
drivers/leds/leds-lp50xx.c +40 -15
@@ -52,6 +52,12 @@#define LP50XX_SW_RESET 0xff#define LP50XX_CHIP_EN BIT(6) +#define LP50XX_CHIP_DISABLE 0x00 +#define LP50XX_START_TIME_US 500 +#define LP50XX_RESET_TIME_US 3 + +#define LP50XX_EN_GPIO_LOW 0 +#define LP50XX_EN_GPIO_HIGH 1/* There are 3 LED outputs per bank */ #define LP50XX_LEDS_PER_MODULE 3
@@ -371,19 +377,42 @@ static int lp50xx_reset(struct lp50xx *preturn regmap_write (priv->regmap, priv->chip_info->reset_reg,LP50XX_SW_RESET ); } -static int lp50xx_enable_disable (struct lp50xx *priv,int enable_disable) +static int lp50xx_enable (struct lp50xx *priv) {int ret; - ret =gpiod_direction_output (priv->enable_gpio, enable_disable); +if (priv->enable_gpio) { + ret =gpiod_direction_output (priv->enable_gpio,LP50XX_EN_GPIO_HIGH ); +if (ret) +return ret; + +udelay (LP50XX_START_TIME_US ); + } + + ret =lp50xx_reset (priv);if (ret)return ret; -if (enable_disable) -return regmap_write (priv->regmap,LP50XX_DEV_CFG0 ,LP50XX_CHIP_EN ); -else -return regmap_write (priv->regmap,LP50XX_DEV_CFG0 ,0 ); +return regmap_write (priv->regmap,LP50XX_DEV_CFG0 ,LP50XX_CHIP_EN ); +} +static int lp50xx_disable (struct lp50xx *priv) +{ +int ret; + + ret =regmap_write (priv->regmap,LP50XX_DEV_CFG0 ,LP50XX_CHIP_DISABLE ); +if (ret) +return ret; + +if (priv->enable_gpio) { + ret =gpiod_direction_output (priv->enable_gpio,LP50XX_EN_GPIO_LOW ); +if (ret) +return ret; + +udelay (LP50XX_RESET_TIME_US ); + } + +return 0 ; } static int lp50xx_probe_leds(struct fwnode_handle *child, struct lp50xx *priv,
@@ -448,6 +477,10 @@ static int lp50xx_probe_dt(struct lp50xxreturn dev_err_probe (priv->dev,PTR_ERR (priv->enable_gpio),"Failed to get enable GPIO\n" ); + ret =lp50xx_enable (priv); +if (ret) +return ret; + priv->regulator =devm_regulator_get (priv->dev,"vled" );if (IS_ERR (priv->regulator)) priv->regulator =NULL ;
@@ -554,14 +587,6 @@ static int lp50xx_probe(struct i2c_clienreturn ret; } - ret =lp50xx_reset (led); -if (ret) -return ret; - - ret =lp50xx_enable_disable (led,1 ); -if (ret) -return ret; -return lp50xx_probe_dt (led); }
@@ -570,7 +595,7 @@ static void lp50xx_remove(struct i2c_clistruct lp50xx *led =i2c_get_clientdata (client);int ret; - ret =lp50xx_enable_disable (led,0 ); + ret =lp50xx_disable (led);if (ret)dev_err (led->dev,"Failed to disable chip\n" );
Greg Kroah-Hartman
maintainerPATCH 378/567 block: Clear BLK_ZONE_WPLUG_PLUGGED when aborting plugged BIOs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 552c1149af7ac0cffab6fccd13feeaf816dd1f53 upstream.
Commit fe0418eb9bd6 ("block: Prevent potential deadlocks in zone write plug error recovery") added a WARN check in disk_put_zone_wplug() to verify that when the last reference to a zone write plug is dropped, this zone write plug does not have the BLK_ZONE_WPLUG_PLUGGED flag set, that is, that it is not plugged.
However, the function disk_zone_wplug_abort(), which is called for zone reset and zone finish operations, does not clear this flag after emptying a zone write plug BIO list. This can result in the disk_put_zone_wplug() warning to trigger if the user (erroneously as that is bad pratcice) issues zone reset or zone finish operations while the target zone still has plugged BIOs.
Modify disk_put_zone_wplug() to clear the BLK_ZONE_WPLUG_PLUGGED flag. And while at it, also add a lockdep annotation to ensure that this function is called with the zone write plug spinlock held.
--- block/blk-zoned.c | 4 ++++ 1 file changed, 4 insertions(+)
block/blk-zoned.c +4 -0
@@ -621,6 +621,8 @@ static void disk_zone_wplug_abort(struct {struct bio *bio; +lockdep_assert_held (&zwplug->lock); +if (bio_list_empty (&zwplug->bio_list))return ;
@@ -628,6 +630,8 @@ static void disk_zone_wplug_abort(struct zwplug->disk->disk_name, zwplug->zone_no);while ((bio =bio_list_pop (&zwplug->bio_list)))blk_zone_wplug_bio_io_error (zwplug, bio); + + zwplug->flags &= ~BLK_ZONE_WPLUG_PLUGGED ; }/*
Greg Kroah-Hartman
maintainerPATCH 379/567 clk: samsung: exynos-clkout: Assign .num before accessing .hws
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit cf33f0b7df13685234ccea7be7bfe316b60db4db upstream.
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in exynos_clkout_probe() due to .num being assigned after .hws[] has been accessed:
UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18 index 0 is out of range for type 'clk_hw *[*]'
Move the .num initialization to before the first access of .hws[], clearing up the warning.
--- drivers/clk/samsung/clk-exynos-clkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/samsung/clk-exynos-clkout.c +1 -1
@@ -174,6 +174,7 @@ static int exynos_clkout_probe(struct pl clkout->mux.shift =EXYNOS_CLKOUT_MUX_SHIFT ; clkout->mux.lock = &clkout->slock; + clkout->data.num =EXYNOS_CLKOUT_NR_CLKS ; clkout->data.hws[0] = clk_hw_register_composite(NULL, "clkout", parent_names, parent_count, &clkout->mux.hw, &clk_mux_ops, NULL, NULL, &clkout->gate.hw,
@@ -184,7 +185,6 @@ static int exynos_clkout_probe(struct pl goto err_unmap; } - clkout->data.num =EXYNOS_CLKOUT_NR_CLKS ; ret =of_clk_add_hw_provider (clkout->np, of_clk_hw_onecell_get, &clkout->data);if (ret) goto err_clk_unreg;
Greg Kroah-Hartman
maintainerPATCH 380/567 mfd: altera-sysmgr: Fix device leak on sysmgr regmap lookup
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit ccb7cd3218e48665f3c7e19eede0da5f069c323d upstream.
Make sure to drop the reference taken to the sysmgr platform device when retrieving its driver data.
Note that holding a reference to a device does not prevent its driver data from going away.
--- drivers/mfd/altera-sysmgr.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/mfd/altera-sysmgr.c +2 -0
@@ -117,6 +117,8 @@ struct regmap *altr_sysmgr_regmap_lookup sysmgr =dev_get_drvdata (dev); +put_device (dev); +return sysmgr->regmap; }EXPORT_SYMBOL_GPL (altr_sysmgr_regmap_lookup_by_phandle);
Greg Kroah-Hartman
maintainerPATCH 381/567 mfd: max77620: Fix potential IRQ chip conflict when probing two devices
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 2bac49bad1f3553cc3b3bfb22cc194e9bd9e8427 upstream.
MAX77620 is most likely always a single device on the board, however nothing stops board designers to have two of them, thus same device driver could probe twice. Or user could manually try to probing second time.
Device driver is not ready for that case, because it allocates statically 'struct regmap_irq_chip' as non-const and stores during probe in 'irq_drv_data' member a pointer to per-probe state container ('struct max77620_chip'). devm_regmap_add_irq_chip() does not make a copy of 'struct regmap_irq_chip' but store the pointer.
Second probe - either successful or failure - would overwrite the 'irq_drv_data' from previous device probe, so interrupts would be executed in a wrong context.
--- drivers/mfd/max77620.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/mfd/max77620.c +11 -4
@@ -253,7 +253,7 @@ static int max77620_irq_global_unmask(voreturn ret; } -static struct regmap_irq_chip max77620_top_irq_chip = { +static const struct regmap_irq_chip max77620_top_irq_chip = { .name ="max77620-top" , .irqs = max77620_top_irqs, .num_irqs =ARRAY_SIZE (max77620_top_irqs),
@@ -497,6 +497,7 @@ static int max77620_probe(struct i2c_cliconst struct i2c_device_id *id =i2c_client_get_device_id (client);const struct regmap_config *rmap_config;struct max77620_chip *chip; +struct regmap_irq_chip *chip_desc;const struct mfd_cell *mfd_cells;int n_mfd_cells;bool pm_off;
@@ -507,6 +508,14 @@ static int max77620_probe(struct i2c_clireturn -ENOMEM ;i2c_set_clientdata (client, chip); + + chip_desc =devm_kmemdup (&client->dev, &max77620_top_irq_chip, +sizeof (max77620_top_irq_chip), +GFP_KERNEL ); +if (!chip_desc) +return -ENOMEM ; + chip_desc->irq_drv_data = chip; + chip->dev = &client->dev; chip->chip_irq = client->irq; chip->chip_id = (enum max77620_chip_id )id->driver_data;
@@ -543,11 +552,9 @@ static int max77620_probe(struct i2c_cliif (ret <0 )return ret; - max77620_top_irq_chip.irq_drv_data = chip; ret =devm_regmap_add_irq_chip (chip->dev, chip->rmap, client->irq,IRQF_ONESHOT |IRQF_SHARED ,0 , - &max77620_top_irq_chip, - &chip->top_irq_data); + chip_desc, &chip->top_irq_data);if (ret <0 ) {dev_err (chip->dev,"Failed to add regmap irq: %d\n" , ret);return ret;
Greg Kroah-Hartman
maintainerPATCH 382/567 media: rc: st_rc: Fix reset control resource leak
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
commit 1240abf4b71f632f0117b056e22488e4d9808938 upstream.
The driver calls reset_control_get_optional_exclusive() but never calls reset_control_put() in error paths or in the remove function. This causes a resource leak when probe fails after successfully acquiring the reset control, or when the driver is unloaded.
Switch to devm_reset_control_get_optional_exclusive() to automatically manage the reset control resource.
--- drivers/media/rc/st_rc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/rc/st_rc.c +1 -1
@@ -284,7 +284,7 @@ static int st_rc_probe(struct platform_delse rc_dev->rx_base = rc_dev->base; - rc_dev->rstc =reset_control_get_optional_exclusive (dev,NULL ); + rc_dev->rstc =devm_reset_control_get_optional_exclusive (dev,NULL );if (IS_ERR (rc_dev->rstc)) { ret =PTR_ERR (rc_dev->rstc); goto err;
Greg Kroah-Hartman
maintainerPATCH 383/567 media: verisilicon: Fix CPU stalls on G2 bus error
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Dufresne <[email protected]>
commit 19c286b755072a22a063052f530a6b1fac8a1f63 upstream.
In some seek stress tests, we are getting IRQ from the G2 decoder where the dec_bus_int and the dec_e bits are high, meaning the decoder is still running despite the error.
Fix this by reworking the IRQ handler to only finish the job once we have reached completion and move the software reset to when our software watchdog triggers.
This way, we let the hardware continue on errors when it did not self reset and in worse case scenario the hardware timeout will automatically stop it. The actual error will be fixed in a follow up patch.
--- drivers/media/platform/verisilicon/hantro_g2.c | 84 ++++++++++++---- drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c | 2 drivers/media/platform/verisilicon/hantro_g2_regs.h | 13 ++ drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c | 2 drivers/media/platform/verisilicon/hantro_hw.h | 1 drivers/media/platform/verisilicon/imx8m_vpu_hw.c | 2 6 files changed, 83 insertions(+), 21 deletions(-)
drivers/media/platform/verisilicon/hantro_g2.c +67 -17
@@ -5,43 +5,93 @@* Copyright (C) 2021 Collabora Ltd, Andrzej Pietrasiewicz <[email protected]> */ +#include <linux/delay.h> #include "hantro_hw.h" #include "hantro_g2_regs.h" #define G2_ALIGN 16 -void hantro_g2_check_idle (struct hantro_dev *vpu) +static bool hantro_g2_active (struct hantro_ctx *ctx) { -int i; +struct hantro_dev *vpu = ctx->dev; +u32 status; + + status =vdpu_read (vpu,G2_REG_INTERRUPT ); + +return (status &G2_REG_INTERRUPT_DEC_E ); +} -for (i =0 ; i <3 ; i++) { -u32 status; +/** +* hantro_g2_reset: +* @ctx: the hantro context +* +* Emulates a reset using Hantro abort function. Failing this procedure would +* results in programming a running IP which leads to CPU hang. +* +* Using a hard reset procedure instead is prefferred. +*/ +void hantro_g2_reset (struct hantro_ctx *ctx) +{ +struct hantro_dev *vpu = ctx->dev; +u32 status; -/* Make sure the VPU is idle */ - status =vdpu_read (vpu,G2_REG_INTERRUPT ); -if (status &G2_REG_INTERRUPT_DEC_E ) { -dev_warn (vpu->dev,"device still running, aborting" ); - status |=G2_REG_INTERRUPT_DEC_ABORT_E |G2_REG_INTERRUPT_DEC_IRQ_DIS ; -vdpu_write (vpu, status,G2_REG_INTERRUPT ); - } + status =vdpu_read (vpu,G2_REG_INTERRUPT ); +if (status &G2_REG_INTERRUPT_DEC_E ) { +dev_warn_ratelimited (vpu->dev,"device still running, aborting" ); + status |=G2_REG_INTERRUPT_DEC_ABORT_E |G2_REG_INTERRUPT_DEC_IRQ_DIS ; +vdpu_write (vpu, status,G2_REG_INTERRUPT ); + +do { +mdelay (1 ); + }while (hantro_g2_active (ctx)); } }irqreturn_t hantro_g2_irq (int irq,void *dev_id) {struct hantro_dev *vpu = dev_id; -enum vb2_buffer_state state;u32 status; status =vdpu_read (vpu,G2_REG_INTERRUPT ); - state = (status &G2_REG_INTERRUPT_DEC_RDY_INT ) ? -VB2_BUF_STATE_DONE :VB2_BUF_STATE_ERROR ; -vdpu_write (vpu,0 ,G2_REG_INTERRUPT ); -vdpu_write (vpu,G2_REG_CONFIG_DEC_CLK_GATE_E ,G2_REG_CONFIG ); +if (!(status &G2_REG_INTERRUPT_DEC_IRQ )) +return IRQ_NONE ; + +hantro_reg_write (vpu, &g2_dec_irq,0 ); +hantro_reg_write (vpu, &g2_dec_int_stat,0 ); +hantro_reg_write (vpu, &g2_clk_gate_e,1 ); + +if (status &G2_REG_INTERRUPT_DEC_RDY_INT ) { +hantro_irq_done (vpu,VB2_BUF_STATE_DONE ); +return IRQ_HANDLED ; + } + +if (status &G2_REG_INTERRUPT_DEC_ABORT_INT ) { +/* disabled on abort, though lets be safe and handle it */ +dev_warn_ratelimited (vpu->dev,"decode operation aborted." ); +return IRQ_HANDLED ; + } + +if (status &G2_REG_INTERRUPT_DEC_LAST_SLICE_INT ) +dev_warn_ratelimited (vpu->dev,"not all macroblocks were decoded." ); + +if (status &G2_REG_INTERRUPT_DEC_BUS_INT ) +dev_warn_ratelimited (vpu->dev,"bus error detected." ); + +if (status &G2_REG_INTERRUPT_DEC_ERROR_INT ) +dev_warn_ratelimited (vpu->dev,"decode error detected." ); -hantro_irq_done (vpu, state); +if (status &G2_REG_INTERRUPT_DEC_TIMEOUT ) +dev_warn_ratelimited (vpu->dev,"frame decode timed out." ); + +/** +* If the decoding haven't stopped, let it continue. The hardware timeout +* will trigger if it is trully stuck. +*/ +if (status &G2_REG_INTERRUPT_DEC_E ) +return IRQ_HANDLED ; +hantro_irq_done (vpu,VB2_BUF_STATE_ERROR );return IRQ_HANDLED ; }
drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c +0 -2
@@ -582,8 +582,6 @@ int hantro_g2_hevc_dec_run(struct hantrostruct hantro_dev *vpu = ctx->dev;int ret; -hantro_g2_check_idle (vpu); -/* Prepare HEVC decoder context. */ ret =hantro_hevc_dec_prepare_run (ctx);if (ret)
drivers/media/platform/verisilicon/hantro_g2_regs.h +13 -0
@@ -22,7 +22,14 @@#define G2_REG_VERSION G2_SWREG(0)#define G2_REG_INTERRUPT G2_SWREG(1) +#define G2_REG_INTERRUPT_DEC_LAST_SLICE_INT BIT(19) +#define G2_REG_INTERRUPT_DEC_TIMEOUT BIT(18) +#define G2_REG_INTERRUPT_DEC_ERROR_INT BIT(16) +#define G2_REG_INTERRUPT_DEC_BUF_INT BIT(14) +#define G2_REG_INTERRUPT_DEC_BUS_INT BIT(13)#define G2_REG_INTERRUPT_DEC_RDY_INT BIT(12) +#define G2_REG_INTERRUPT_DEC_ABORT_INT BIT(11) +#define G2_REG_INTERRUPT_DEC_IRQ BIT(8)#define G2_REG_INTERRUPT_DEC_ABORT_E BIT(5)#define G2_REG_INTERRUPT_DEC_IRQ_DIS BIT(4)#define G2_REG_INTERRUPT_DEC_E BIT(0)
@@ -35,6 +42,9 @@#define BUS_WIDTH_128 2#define BUS_WIDTH_256 3 +#define g2_dec_int_stat G2_DEC_REG(1, 11, 0xf) +#define g2_dec_irq G2_DEC_REG(1, 8, 0x1) +#define g2_strm_swap G2_DEC_REG(2, 28, 0xf)#define g2_strm_swap_old G2_DEC_REG(2, 27, 0x1f)#define g2_pic_swap G2_DEC_REG(2, 22, 0x1f)
@@ -225,6 +235,9 @@#define vp9_filt_level_seg5 G2_DEC_REG(19, 8, 0x3f)#define vp9_quant_seg5 G2_DEC_REG(19, 0, 0xff) +#define g2_timemout_override_e G2_DEC_REG(45, 31, 0x1) +#define g2_timemout_cycles G2_DEC_REG(45, 0, 0x7fffffff) +#define hevc_cur_poc_00 G2_DEC_REG(46, 24, 0xff)#define hevc_cur_poc_01 G2_DEC_REG(46, 16, 0xff)#define hevc_cur_poc_02 G2_DEC_REG(46, 8, 0xff)
drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c +0 -2
@@ -893,8 +893,6 @@ int hantro_g2_vp9_dec_run(struct hantro_struct vb2_v4l2_buffer *dst;int ret; -hantro_g2_check_idle (ctx->dev); - ret =start_prepare_run (ctx, &decode_params);if (ret) {hantro_end_prepare_run (ctx);
drivers/media/platform/verisilicon/hantro_hw.h +1 -0
@@ -583,6 +583,7 @@ void hantro_g2_vp9_dec_done(struct hantrint hantro_vp9_dec_init (struct hantro_ctx *ctx);void hantro_vp9_dec_exit (struct hantro_ctx *ctx);void hantro_g2_check_idle (struct hantro_dev *vpu); +void hantro_g2_reset (struct hantro_ctx *ctx);irqreturn_t hantro_g2_irq (int irq,void *dev_id);#endif /* HANTRO_HW_H_ */
drivers/media/platform/verisilicon/imx8m_vpu_hw.c +2 -0
@@ -312,11 +312,13 @@ static const struct hantro_codec_ops imxstatic const struct hantro_codec_ops imx8mq_vpu_g2_codec_ops[] = { [HANTRO_MODE_HEVC_DEC ] = { .run = hantro_g2_hevc_dec_run, + .reset = hantro_g2_reset, .init = hantro_hevc_dec_init, .exit = hantro_hevc_dec_exit, }, [HANTRO_MODE_VP9_DEC ] = { .run = hantro_g2_vp9_dec_run, + .reset = hantro_g2_reset, .done = hantro_g2_vp9_dec_done, .init = hantro_vp9_dec_init, .exit = hantro_vp9_dec_exit,
Greg Kroah-Hartman
maintainerPATCH 384/567 mtd: mtdpart: ignore error -ENOENT from parsers on subpartitions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Marangi <[email protected]>
commit 64ef5f454e167bb66cf70104f033c3d71e6ef9c0 upstream.
Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") introduced some kind of regression with parser on subpartitions where if a parser emits an error then the entire parsing process from the upper parser fails and partitions are deleted.
Not checking for error in subpartitions was originally intended as special parser can emit error also in the case of the partition not correctly init (for example a wiped partition) or special case where the partition should be skipped due to some ENV variables externally provided (from bootloader for example)
One example case is the TRX partition where, in the context of a wiped partition, returns a -ENOENT as the trx_magic is not found in the expected TRX header (as the partition is wiped)
To better handle this and still keep some kind of error tracking (for example to catch -ENOMEM errors or -EINVAL errors), permit parser on subpartition to emit -ENOENT error, print a debug log and skip them accordingly.
This results in giving better tracking of the status of the parser (instead of returning just 0, dropping any kind of signal that there is something wrong with the parser) and to some degree restore the original logic of the subpartitions parse.
(worth to notice that some special partition might have all the special header present for the parser and declare 0 partition in it, this is why it would be wrong to simply return 0 in the case of a special partition that is NOT init for the scanning parser)
--- drivers/mtd/mtdpart.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/mtd/mtdpart.c +5 -2
@@ -425,9 +425,12 @@ int add_mtd_partitions(struct mtd_info *mtd_add_partition_attrs (child); -/* Look for subpartitions */ +/* Look for subpartitions (skip if no maching parser found) */ ret =parse_mtd_partitions (child, parts[i].types,NULL ); -if (ret <0 ) { +if (ret <0 && ret == -ENOENT ) { +pr_debug ("Skip parsing subpartitions: %d\n" , ret); +continue ; + }else if (ret <0 ) {pr_err ("Failed to parse subpartitions: %d\n" , ret); goto err_del_partitions; }
Greg Kroah-Hartman
maintainerPATCH 385/567 mtd: spi-nor: winbond: Add support for W25Q01NWxxIQ chips
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
commit aee8c4d9d48d661624d72de670ebe5c6b5687842 upstream.
This chip must be described as none of the block protection information are discoverable. This chip supports 4 bits plus the top/bottom addressing capability to identify the protected blocks.
--- drivers/mtd/spi-nor/winbond.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/mtd/spi-nor/winbond.c +4 -0
@@ -254,6 +254,10 @@ static const struct flash_info winbond_n .id = SNOR_ID(0xef, 0x80, 0x20), .name = "w25q512nwm", .otp = SNOR_OTP(256, 3, 0x1000, 0x1000), + }, { +/* W25Q01NWxxIQ */ + .id = SNOR_ID(0xef, 0x60, 0x21), + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, }, };
Greg Kroah-Hartman
maintainerPATCH 386/567 mtd: spi-nor: winbond: Add support for W25Q01NWxxIM chips
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
commit a607e676c8b9258eabc3fc88f45bcd70ea178b41 upstream.
These chips must be described as none of the block protection information are discoverable. This chip supports 4 bits plus the top/bottom addressing capability to identify the protected blocks.
--- drivers/mtd/spi-nor/winbond.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/mtd/spi-nor/winbond.c +4 -0
@@ -258,6 +258,10 @@ static const struct flash_info winbond_n/* W25Q01NWxxIQ */ .id = SNOR_ID(0xef, 0x60, 0x21), .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, + }, { +/* W25Q01NWxxIM */ + .id = SNOR_ID(0xef, 0x80, 0x21), + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, }, };
Greg Kroah-Hartman
maintainerPATCH 387/567 mtd: spi-nor: winbond: Add support for W25Q02NWxxIM chips
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
commit 71c239348d9fbdb1f0d6f36013f1697cc06c3e9c upstream.
These chips must be described as none of the block protection information are discoverable. This chip supports 4 bits plus the top/bottom addressing capability to identify the protected blocks.
--- drivers/mtd/spi-nor/winbond.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/mtd/spi-nor/winbond.c +4 -0
@@ -262,6 +262,10 @@ static const struct flash_info winbond_n/* W25Q01NWxxIM */ .id = SNOR_ID(0xef, 0x80, 0x21), .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, + }, { +/* W25Q02NWxxIM */ + .id = SNOR_ID(0xef, 0x80, 0x22), + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, }, };
Greg Kroah-Hartman
maintainerPATCH 388/567 mtd: spi-nor: winbond: Add support for W25H512NWxxAM chips
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
commit f21d2c7d37553b24825918f2f61df123e182b712 upstream.
These chips must be described as none of the block protection information are discoverable. This chip supports 4 bits plus the top/bottom addressing capability to identify the protected blocks.
--- drivers/mtd/spi-nor/winbond.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/mtd/spi-nor/winbond.c +4 -0
@@ -266,6 +266,10 @@ static const struct flash_info winbond_n/* W25Q02NWxxIM */ .id = SNOR_ID(0xef, 0x80, 0x22), .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, + }, { +/* W25H512NWxxAM */ + .id = SNOR_ID(0xef, 0xa0, 0x20), + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, }, };
Greg Kroah-Hartman
maintainerPATCH 389/567 mtd: spi-nor: winbond: Add support for W25H01NWxxAM chips
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
commit 1df1fdbc7e63350b2962dc7d87ded124ee26f3ad upstream.
These chips must be described as none of the block protection information are discoverable. This chip supports 4 bits plus the top/bottom addressing capability to identify the protected blocks.
--- drivers/mtd/spi-nor/winbond.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/mtd/spi-nor/winbond.c +4 -0
@@ -270,6 +270,10 @@ static const struct flash_info winbond_n/* W25H512NWxxAM */ .id = SNOR_ID(0xef, 0xa0, 0x20), .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, + }, { +/* W25H01NWxxAM */ + .id = SNOR_ID(0xef, 0xa0, 0x21), + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, }, };
Greg Kroah-Hartman
maintainerPATCH 390/567 mtd: spi-nor: winbond: Add support for W25H02NWxxAM chips
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
commit 604cf6a40157abba4677dea9834de8df9047d798 upstream.
These chips must be described as none of the block protection information are discoverable. This chip supports 4 bits plus the top/bottom addressing capability to identify the protected blocks.
--- drivers/mtd/spi-nor/winbond.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/mtd/spi-nor/winbond.c +4 -0
@@ -274,6 +274,10 @@ static const struct flash_info winbond_n/* W25H01NWxxAM */ .id = SNOR_ID(0xef, 0xa0, 0x21), .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, + }, { +/* W25H02NWxxAM */ + .id = SNOR_ID(0xef, 0xa0, 0x22), + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP, }, };
Greg Kroah-Hartman
maintainerPATCH 391/567 parisc: entry.S: fix space adjustment on interruption for 64-bit userspace
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sven Schnelle <[email protected]>
commit 1aa4524c0c1b54842c4c0a370171d11b12d0709b upstream.
In wide mode, the IASQ contain the upper part of the GVA during interruption. This needs to be reversed before the space is used - otherwise it contains parts of IAOQ. See Page 2-13 "Processing Resources / Interruption Instruction Address Queues" in the Parisc 2.0 Architecture Manual page 2-13 for an explanation.
The IAOQ/IASQ space_adjust was skipped for other interruptions than itlb misses. However, the code in handle_interruption() checks whether iasq[0] contains a valid space. Due to the not masked out bits this match failed and the process was killed.
Also add space_adjust for IAOQ1/IASQ1 so ptregs contains sane values.
--- arch/parisc/kernel/entry.S | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
arch/parisc/kernel/entry.S +8 -3
@@ -1059,8 +1059,6 @@ ENTRY_CFI(intr_save) /* for os_hpmc */ STREG %r17, PT_IOR(%r29) #if defined(CONFIG_64BIT) - b,n intr_save2 - skip_save_ior: /* We have a itlb miss, and when executing code above 4 Gb on ILP64, we * need to adjust iasq/iaoq here in the same way we adjusted isr/ior
@@ -1069,10 +1067,17 @@ skip_save_ior: bb,COND(>=),n %r8,PSW_W_BIT,intr_save2 LDREG PT_IASQ0(%r29), %r16 LDREG PT_IAOQ0(%r29), %r17 - /* adjust iasq/iaoq */ + /* adjust iasq0/iaoq0 */ space_adjust %r16,%r17,%r1 STREG %r16, PT_IASQ0(%r29) STREG %r17, PT_IAOQ0(%r29) + + LDREG PT_IASQ1(%r29), %r16 + LDREG PT_IAOQ1(%r29), %r17 + /* adjust iasq1/iaoq1 */ + space_adjust %r16,%r17,%r1 + STREG %r16, PT_IASQ1(%r29) + STREG %r17, PT_IAOQ1(%r29) #else skip_save_ior: #endif
Greg Kroah-Hartman
maintainerPATCH 392/567 parisc: entry: set W bit for !compat tasks in syscall_restore_rfi()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sven Schnelle <[email protected]>
commit 5fb1d3ce3e74a4530042795e1e065422295f1371 upstream.
When the kernel leaves to userspace via syscall_restore_rfi(), the W bit is not set in the new PSW. This doesn't cause any problems because there's no 64 bit userspace for parisc. Simple static binaries are usually loaded at addresses way below the 32 bit limit so the W bit doesn't matter.
Fix this by setting the W bit when TIF_32BIT is not set.
--- arch/parisc/kernel/asm-offsets.c | 2 ++ arch/parisc/kernel/entry.S | 5 ++++- 2 files changed, 6 insertions(+), 1 deletion(-)
arch/parisc/kernel/asm-offsets.c +2 -0
@@ -258,6 +258,8 @@ int main(void)BLANK ();DEFINE (TIF_BLOCKSTEP_PA_BIT ,31 -TIF_BLOCKSTEP );DEFINE (TIF_SINGLESTEP_PA_BIT ,31 -TIF_SINGLESTEP ); +DEFINE (TIF_32BIT_PA_BIT ,31 -TIF_32BIT ); +BLANK ();DEFINE (ASM_PMD_SHIFT ,PMD_SHIFT );DEFINE (ASM_PGDIR_SHIFT ,PGDIR_SHIFT );
arch/parisc/kernel/entry.S +4 -1
@@ -1846,6 +1846,10 @@ syscall_restore_rfi: extru,= %r19,TIF_BLOCKSTEP_PA_BIT,1,%r0 depi -1,7,1,%r20 /* T bit */ +#ifdef CONFIG_64BIT + extru,<> %r19,TIF_32BIT_PA_BIT,1,%r0 + depi -1,4,1,%r20 /* W bit */ +#endif STREG %r20,TASK_PT_PSW(%r1) /* Always store space registers, since sr3 can be changed (e.g. fork) */
@@ -1859,7 +1863,6 @@ syscall_restore_rfi: STREG %r25,TASK_PT_IASQ0(%r1) STREG %r25,TASK_PT_IASQ1(%r1) - /* XXX W bit??? */ /* Now if old D bit is clear, it means we didn't save all registers * on syscall entry, so do that now. This only happens on TRACEME * calls, or if someone attached to us while we were on a syscall.
Greg Kroah-Hartman
maintainerPATCH 393/567 perf/x86/amd/uncore: Fix the return value of amd_uncore_df_event_init() on error
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sandipan Das <[email protected]>
commit 01439286514ce9d13b8123f8ec3717d7135ff1d6 upstream.
If amd_uncore_event_init() fails, return an error irrespective of the pmu_version. Setting hwc->config should be safe even if there is an error so use this opportunity to simplify the code.
--- arch/x86/events/amd/uncore.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
arch/x86/events/amd/uncore.c +1 -4
@@ -595,14 +595,11 @@ static int amd_uncore_df_event_init(strustruct hw_perf_event *hwc = &event->hw;int ret =amd_uncore_event_init (event); -if (ret || pmu_version <2 ) -return ret; - hwc->config = event->attr.config & (pmu_version >=2 ?AMD64_PERFMON_V2_RAW_EVENT_MASK_NB :AMD64_RAW_EVENT_MASK_NB ); -return 0 ; +return ret; }static int amd_uncore_df_add (struct perf_event *event,int flags)
Greg Kroah-Hartman
maintainerPATCH 394/567 powerpc/pseries/cmm: call balloon_devinfo_init() also without CONFIG_BALLOON_COMPACTION
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
commit fc6bcf9ac4de76f5e7bcd020b3c0a86faff3f2d5 upstream.
Patch series "powerpc/pseries/cmm: two smaller fixes".
Two smaller fixes identified while doing a bigger rework.
This patch (of 2):
We always have to initialize the balloon_dev_info, even when compaction is not configured in: otherwise the containing list and the lock are left uninitialized.
Likely not many such configs exist in practice, but let's CC stable to be sure.
This was found by code inspection.
--- arch/powerpc/platforms/pseries/cmm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/platforms/pseries/cmm.c +1 -1
@@ -550,7 +550,6 @@ static int cmm_migratepage(struct balloostatic void cmm_balloon_compaction_init (void ) { -balloon_devinfo_init (&b_dev_info); b_dev_info.migratepage = cmm_migratepage; }#else /* CONFIG_BALLOON_COMPACTION */
@@ -572,6 +571,7 @@ static int cmm_init(void)if (!firmware_has_feature (FW_FEATURE_CMO ) && !simulate)return -EOPNOTSUPP ; +balloon_devinfo_init (&b_dev_info);cmm_balloon_compaction_init (); rc =register_oom_notifier (&cmm_oom_nb);
Greg Kroah-Hartman
maintainerPATCH 395/567 media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Abramov <[email protected]>
commit 8163419e3e05d71dcfa8fb49c8fdf8d76908fe51 upstream.
It's possible for cp_read() and hdmi_read() to return -EIO. Those values are further used as indexes for accessing arrays.
Fix that by checking return values where it's needed.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/media/i2c/adv7842.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/media/i2c/adv7842.c +5 -2
@@ -2689,6 +2689,7 @@ static int adv7842_cp_log_status(struct/* CP block */ struct adv7842_state *state =to_state (sd);struct v4l2_dv_timings timings; +int temp;u8 reg_io_0x02 =io_read (sd,0x02 );u8 reg_io_0x21 =io_read (sd,0x21 );u8 reg_rep_0x77 =rep_read (sd,0x77 );
@@ -2811,8 +2812,9 @@ static int adv7842_cp_log_status(struct (((reg_io_0x02 >>2 ) &0x01 ) ^ (reg_io_0x02 &0x01 )) ?"(16-235)" :"(0-255)" , (reg_io_0x02 & 0x08) ? "enabled" : "disabled"); + temp =cp_read (sd,0xf4 ) >>4 ;v4l2_info (sd,"Color space conversion: %s\n" , - csc_coeff_sel_rb[cp_read (sd,0xf4 ) >>4 ]); + temp <0 ?"" : csc_coeff_sel_rb[temp]);if (!is_digital_input (sd))return 0 ;
@@ -2842,8 +2844,9 @@ static int adv7842_cp_log_status(struct hdmi_read(sd, 0x5f));v4l2_info (sd,"AV Mute: %s\n" , (hdmi_read (sd,0x04 ) &0x40 ) ?"on" :"off" ); + temp =hdmi_read (sd,0x0b ) >>6 ;v4l2_info (sd,"Deep color mode: %s\n" , - deep_color_mode_txt[hdmi_read (sd,0x0b ) >>6 ]); + temp <0 ?"" : deep_color_mode_txt[temp]);adv7842_log_infoframes (sd);
Greg Kroah-Hartman
maintainerPATCH 396/567 firmware: stratix10-svc: Add mutex in stratix10 memory management
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahesh Rao <[email protected]>
commit 85f96cbbbc67b59652b2c1ec394b8ddc0ddf1b0b upstream.
Add mutex lock to stratix10_svc_allocate_memory and stratix10_svc_free_memory for thread safety. This prevents race conditions and ensures proper synchronization during memory operations. This is required for parallel communication with the Stratix10 service channel.
--- drivers/firmware/stratix10-svc.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/firmware/stratix10-svc.c +11 -0
@@ -1,6 +1,7 @@// SPDX-License-Identifier: GPL-2.0 /* * Copyright (C) 2017-2018, Intel Corporation +* Copyright (C) 2025, Altera Corporation */ #include <linux/completion.h>
@@ -176,6 +177,12 @@ static LIST_HEAD(svc_ctrl);static LIST_HEAD (svc_data_mem);/** +* svc_mem_lock protects access to the svc_data_mem list for +* concurrent multi-client operations +*/ +static DEFINE_MUTEX (svc_mem_lock); + +/** * svc_pa_to_va() - translate physical address to virtual address * @addr: to be translated physical address *
@@ -187,6 +194,7 @@ static void *svc_pa_to_va(unsigned longstruct stratix10_svc_data_mem *pmem;pr_debug ("claim back P-addr=0x%016x\n" , (unsigned int )addr); +guard (mutex)(&svc_mem_lock);list_for_each_entry (pmem, &svc_data_mem, node)if (pmem->paddr == addr)return pmem->vaddr;
@@ -996,6 +1004,7 @@ int stratix10_svc_send(struct stratix10_ p_data->flag = ct->flags; } }else { +guard (mutex)(&svc_mem_lock);list_for_each_entry (p_mem, &svc_data_mem, node)if (p_mem->vaddr == p_msg->payload) { p_data->paddr = p_mem->paddr;
@@ -1078,6 +1087,7 @@ void *stratix10_svc_allocate_memory(struif (!pmem)return ERR_PTR (-ENOMEM ); +guard (mutex)(&svc_mem_lock); va =gen_pool_alloc (genpool, s);if (!va)return ERR_PTR (-ENOMEM );
@@ -1106,6 +1116,7 @@ EXPORT_SYMBOL_GPL(stratix10_svc_allocatevoid stratix10_svc_free_memory (struct stratix10_svc_chan *chan,void *kaddr) {struct stratix10_svc_data_mem *pmem; +guard (mutex)(&svc_mem_lock);list_for_each_entry (pmem, &svc_data_mem, node)if (pmem->vaddr == kaddr) {
Greg Kroah-Hartman
maintainerPATCH 397/567 dm-ebs: Mark full buffer dirty even on partial write
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Uladzislau Rezki (Sony) <[email protected]>
commit 7fa3e7d114abc9cc71cc35d768e116641074ddb4 upstream.
When performing a read-modify-write(RMW) operation, any modification to a buffered block must cause the entire buffer to be marked dirty.
Marking only a subrange as dirty is incorrect because the underlying device block size(ubs) defines the minimum read/write granularity. A lower device can perform I/O only on regions which are fully aligned and sized to ubs.
This change ensures that write-back operations always occur in full ubs-sized chunks, matching the intended emulation semantics of the EBS target.
As for user space visible impact, submitting sub-ubs and misaligned I/O for devices which are tuned to ubs sizes only, will reject such requests, therefore it can lead to losing data. Example:
1) Create a 8K nvme device in qemu by adding
-device nvme,drive=drv0,serial=foo,logical_block_size=8192,physical_block_size=8192
2) Setup dm-ebs to emulate 512B to 8K mapping
urezki@pc638:~/bin$ cat dmsetup.sh
lower=/dev/nvme0n1
len=$(blockdev --getsz "$lower")
echo "0 $len ebs $lower 0 1 16" | dmsetup create nvme-8k urezki@pc638:~/bin$
offset 0, ebs=1 and ubs=16(in sectors).
3) Create an ext4 filesystem(default 4K block size)
urezki@pc638:~/bin$ sudo mkfs.ext4 -F /dev/dm-0
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 2072576 4k blocks and 518144 inodes
Filesystem UUID: bd0b6ca6-0506-4e31-86da-8d22c9d50b63
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system
urezki@pc638:~/bin$ dmesg
<snip>
[ 1618.875449] buffer_io_error: 1028 callbacks suppressed [ 1618.875456] Buffer I/O error on dev dm-0, logical block 0, lost async page write [ 1618.875527] Buffer I/O error on dev dm-0, logical block 1, lost async page write [ 1618.875602] Buffer I/O error on dev dm-0, logical block 2, lost async page write [ 1618.875620] Buffer I/O error on dev dm-0, logical block 3, lost async page write [ 1618.875639] Buffer I/O error on dev dm-0, logical block 4, lost async page write [ 1618.894316] Buffer I/O error on dev dm-0, logical block 5, lost async page write [ 1618.894358] Buffer I/O error on dev dm-0, logical block 6, lost async page write [ 1618.894380] Buffer I/O error on dev dm-0, logical block 7, lost async page write [ 1618.894405] Buffer I/O error on dev dm-0, logical block 8, lost async page write [ 1618.894427] Buffer I/O error on dev dm-0, logical block 9, lost async page write
<snip>
Many I/O errors because the lower 8K device rejects sub-ubs/misaligned requests.
with a patch:
urezki@pc638:~/bin$ sudo mkfs.ext4 -F /dev/dm-0
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 2072576 4k blocks and 518144 inodes
Filesystem UUID: 9b54f44f-ef55-4bd4-9e40-c8b775a616ac
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
urezki@pc638:~/bin$ sudo mount /dev/dm-0 /mnt/ urezki@pc638:~/bin$ ls -al /mnt/ total 24 drwxr-xr-x 3 root root 4096 Oct 17 15:13 . drwxr-xr-x 19 root root 4096 Jul 10 19:42 .. drwx------ 2 root root 16384 Oct 17 15:13 lost+found urezki@pc638:~/bin$
After this change: mkfs completes; mount succeeds.
--- drivers/md/dm-ebs-target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-ebs-target.c +1 -1
@@ -103,7 +103,7 @@ static int __ebs_rw_bvec(struct ebs_c *e }else {flush_dcache_page (bv->bv_page);memcpy (ba, pa, cur_len); -dm_bufio_mark_partial_buffer_dirty (b, buf_off, buf_off + cur_len); +dm_bufio_mark_buffer_dirty (b); }dm_bufio_release (b);
Greg Kroah-Hartman
maintainerPATCH 398/567 dm-bufio: align write boundary on physical block size
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <[email protected]>
commit d0ac06ae53be0cdb61f5fe6b62d25d3317c51657 upstream.
There may be devices with physical block size larger than 4k.
If dm-bufio sends I/O that is not aligned on physical block size, performance is degraded.
The 4k minimum alignment limit is there because some SSDs report logical and physical block size 512 despite having 4k internally - so dm-bufio shouldn't send I/Os not aligned on 4k boundary, because they perform badly (the SSD does read-modify-write for them).
--- drivers/md/dm-bufio.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/md/dm-bufio.c +6 -4
@@ -1375,7 +1375,7 @@ static void submit_io(struct dm_buffer * {unsigned int n_sectors;sector_t sector; -unsigned int offset, end; +unsigned int offset, end, align; b->end_io = end_io;
@@ -1389,9 +1389,11 @@ static void submit_io(struct dm_buffer * b->c->write_callback (b); offset = b->write_start; end = b->write_end; - offset &= -DM_BUFIO_WRITE_ALIGN ; - end +=DM_BUFIO_WRITE_ALIGN -1 ; - end &= -DM_BUFIO_WRITE_ALIGN ; + align =max (DM_BUFIO_WRITE_ALIGN , +bdev_physical_block_size (b->c->bdev)); + offset &= -align; + end += align -1 ; + end &= -align;if (unlikely (end > b->c->block_size)) end = b->c->block_size;
Greg Kroah-Hartman
maintainerPATCH 399/567 fbdev: gbefb: fix to use physical address instead of dma address
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rene Rebe <[email protected]>
commit e3f44742bbb10537fe53d83d20dea2a7c167674d upstream.
While debuggigng why X would not start on mips64 Sgi/O2 I found the phys adress being off. Turns out the gbefb passed the internal dma_addr as phys. May be broken pre git history. Fix by converting dma_to_phys.
--- drivers/video/fbdev/gbefb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/video/fbdev/gbefb.c +3 -2
@@ -12,6 +12,7 @@#include <linux/delay.h> #include <linux/platform_device.h> #include <linux/dma-mapping.h> +#include <linux/dma-direct.h> #include <linux/errno.h> #include <linux/gfp.h> #include <linux/fb.h>
@@ -65,7 +66,7 @@ struct gbefb_par {static unsigned int gbe_mem_size =CONFIG_FB_GBE_MEM *1024 *1024 ;static void *gbe_mem;static dma_addr_t gbe_dma_addr; -static unsigned long gbe_mem_phys; +static phys_addr_t gbe_mem_phys; static struct { uint16_t *cpu;
@@ -1183,7 +1184,7 @@ static int gbefb_probe(struct platform_d goto out_release_mem_region; } - gbe_mem_phys = (unsigned long ) gbe_dma_addr; + gbe_mem_phys =dma_to_phys (&p_dev->dev, gbe_dma_addr); } par = info->par;
Greg Kroah-Hartman
maintainerPATCH 400/567 fbdev: pxafb: Fix multiple clamped values in pxafb_adjust_timing
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thorsten Blum <[email protected]>
commit 0155e868cbc111846cc2809c1546ea53810a56ae upstream.
The variables were never clamped because the return value of clamp_val() was not used. Fix this by assigning the clamped values, and use clamp() instead of clamp_val().
--- drivers/video/fbdev/pxafb.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/video/fbdev/pxafb.c +6 -6
@@ -418,12 +418,12 @@ static int pxafb_adjust_timing(struct px var->yres =max_t (int, var->yres,MIN_YRES );if (!(fbi->lccr0 &LCCR0_LCDT )) { -clamp_val (var->hsync_len,1 ,64 ); -clamp_val (var->vsync_len,1 ,64 ); -clamp_val (var->left_margin,1 ,255 ); -clamp_val (var->right_margin,1 ,255 ); -clamp_val (var->upper_margin,1 ,255 ); -clamp_val (var->lower_margin,1 ,255 ); + var->hsync_len =clamp (var->hsync_len,1 ,64 ); + var->vsync_len =clamp (var->vsync_len,1 ,64 ); + var->left_margin =clamp (var->left_margin,1 ,255 ); + var->right_margin =clamp (var->right_margin,1 ,255 ); + var->upper_margin =clamp (var->upper_margin,1 ,255 ); + var->lower_margin =clamp (var->lower_margin,1 ,255 ); }/* make sure each line is aligned on word boundary */
Greg Kroah-Hartman
maintainerPATCH 401/567 fbdev: tcx.c fix mem_map to correct smem_start offset
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: René Rebe <[email protected]>
commit 35fa2b4bf96415b88d7edaa5cf8af5185d9ce76e upstream.
403ae52ac047 ("sparc: fix drivers/video/tcx.c warning") changed the physbase initializing breaking the user-space mmap, e.g. for Xorg entirely.
Fix fbdev mmap table so the sbus mmap helper work correctly, and not try to map vastly (physbase) offset memory.
--- drivers/video/fbdev/tcx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/fbdev/tcx.c +1 -1
@@ -428,7 +428,7 @@ static int tcx_probe(struct platform_dev j = i;break ; } - par->mmap_map[i].poff = op->resource[j].start; + par->mmap_map[i].poff = op->resource[j].start - info->fix.smem_start; } info->fbops = &tcx_ops;
Greg Kroah-Hartman
maintainerPATCH 402/567 media: cec: Fix debugfs leak on bus_register() failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
commit c43bcd2b2aa3c2ca9d2433c3990ecbc2c47d10eb upstream.
In cec_devnode_init(), the debugfs directory created with debugfs_create_dir() is not removed if bus_register() fails. This leaves a stale "cec" entry in debugfs and prevents proper module reloading.
Fix this by removing the debugfs directory in the error path.
--- drivers/media/cec/core/cec-core.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/cec/core/cec-core.c +1 -0
@@ -420,6 +420,7 @@ static int __init cec_devnode_init(void) ret =bus_register (&cec_bus_type);if (ret <0 ) { +debugfs_remove_recursive (top_cec_dir);unregister_chrdev_region (cec_dev_t,CEC_NUM_DEVICES );pr_warn ("cec: bus_register failed\n" );return -EIO ;
Greg Kroah-Hartman
maintainerPATCH 403/567 media: msp3400: Avoid possible out-of-bounds array accesses in msp3400c_thread()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Abramov <[email protected]>
commit d2bceb2e20e783d57e739c71e4e50b4b9f4a3953 upstream.
It's possible for max1 to remain -1 if msp_read() always fail. This variable is further used as index for accessing arrays.
Fix that by checking max1 prior to array accesses.
It seems that restart is the preferable action in case of out-of-bounds value.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/media/i2c/msp3400-kthreads.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/media/i2c/msp3400-kthreads.c +2 -0
@@ -596,6 +596,8 @@ restart: "carrier2 val: %5d / %s\n", val, cd[i].name); } +if (max1 <0 || max1 >3 ) + goto restart;/* program the msp3400 according to the results */ state->main = msp3400c_carrier_detect_main[max1].cdo;switch (max1) {
Greg Kroah-Hartman
maintainerPATCH 404/567 media: platform: mtk-mdp3: fix device leaks at probe
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 8f6f3aa21517ef34d50808af0c572e69580dca20 upstream.
Make sure to drop the references taken when looking up the subsys devices during probe on probe failure (e.g. probe deferral) and on driver unbind.
Similarly, drop the SCP device reference after retrieving its platform data during probe to avoid leaking it.
Note that holding a reference to a device does not prevent its driver data from going away.
--- drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c +14 -0
@@ -176,10 +176,18 @@ void mdp_video_device_release(struct vidkfree (mdp); } +static void mdp_put_device (void *_dev) +{ +struct device *dev = _dev; + +put_device (dev); +} +static int mdp_mm_subsys_deploy (struct mdp_dev *mdp,enum mdp_infra_id id) {struct platform_device *mm_pdev =NULL ;struct device **dev; +int ret;int i;if (!mdp)
@@ -213,6 +221,11 @@ static int mdp_mm_subsys_deploy(struct mif (WARN_ON (!mm_pdev))return -ENODEV ; + ret =devm_add_action_or_reset (&mdp->pdev->dev, mdp_put_device, + &mm_pdev->dev); +if (ret) +return ret; + *dev = &mm_pdev->dev; }
@@ -298,6 +311,7 @@ static int mdp_probe(struct platform_dev goto err_destroy_clock_wq; } mdp->scp =platform_get_drvdata (mm_pdev); +put_device (&mm_pdev->dev); } mdp->rproc_handle =scp_get_rproc (mdp->scp);
Greg Kroah-Hartman
maintainerPATCH 405/567 media: renesas: rcar_drif: fix device node reference leak in rcar_drif_bond_enabled
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaoqian Lin <[email protected]>
commit 445e1658894fd74eab7e53071fa16233887574ed upstream.
The function calls of_parse_phandle() which returns
a device node with an incremented reference count. When the bonded device is not available, the function
returns NULL without releasing the reference, causing a reference leak.
Add of_node_put(np) to release the device node reference. The of_node_put function handles NULL pointers.
Found through static analysis by reviewing the doc of of_parse_phandle() and cross-checking its usage patterns across the codebase.
--- drivers/media/platform/renesas/rcar_drif.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/platform/renesas/rcar_drif.c +1 -0
@@ -1249,6 +1249,7 @@ static struct device_node *rcar_drif_bonif (np &&of_device_is_available (np))return np; +of_node_put (np);return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 406/567 media: samsung: exynos4-is: fix potential ABBA deadlock on init
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
commit 17dc8ccd6dd5ffe30aa9b0d36e2af1389344ce2b upstream.
v4l2_device_register_subdev_nodes() must called without taking media_dev->graph_mutex to avoid potential AB-BA deadlock on further subdevice driver initialization.
--- drivers/media/platform/samsung/exynos4-is/media-dev.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/media/platform/samsung/exynos4-is/media-dev.c +6 -4
@@ -1410,12 +1410,14 @@ static int subdev_notifier_complete(strumutex_lock (&fmd->media_dev.graph_mutex); ret =fimc_md_create_links (fmd); -if (ret <0 ) - goto unlock; +if (ret <0 ) { +mutex_unlock (&fmd->media_dev.graph_mutex); +return ret; + } - ret =v4l2_device_register_subdev_nodes (&fmd->v4l2_dev); -unlock:mutex_unlock (&fmd->media_dev.graph_mutex); + + ret =v4l2_device_register_subdev_nodes (&fmd->v4l2_dev);if (ret <0 )return ret;
Greg Kroah-Hartman
maintainerPATCH 407/567 media: TDA1997x: Remove redundant cancel_delayed_work in probe
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit 29de195ca39fc2ac0af6fd45522994df9f431f80 upstream.
The delayed_work delayed_work_enable_hpd is initialized with INIT_DELAYED_WORK(), but it is never scheduled in tda1997x_probe().
Calling cancel_delayed_work() on a work that has never been scheduled is redundant and unnecessary, as there is no pending work to cancel.
Remove the redundant cancel_delayed_work() from error handling path in tda1997x_probe() to avoid potential confusion.
--- drivers/media/i2c/tda1997x.c | 1 - 1 file changed, 1 deletion(-)
drivers/media/i2c/tda1997x.c +0 -1
@@ -2798,7 +2798,6 @@ err_free_media: err_free_handler:v4l2_ctrl_handler_free (&state->hdl); err_free_mutex: -cancel_delayed_work (&state->delayed_work_enable_hpd);mutex_destroy (&state->page_lock);mutex_destroy (&state->lock);tda1997x_set_power (state,0 );
Greg Kroah-Hartman
maintainerPATCH 408/567 media: verisilicon: Protect G2 HEVC decoder against invalid DPB index
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Dufresne <[email protected]>
commit 47825b1646a6a9eca0f90baa3d4f98947c2add96 upstream.
Fix the Hantro G2 HEVC decoder so that we use DPB index 0 whenever a ninvalid index is received from user space. This protects the hardware from doing faulty memory access which then leads to bus errors.
To be noted that when a reference is missing, userspace such as GStreamer passes an invalid DPB index of 255. This issue was found by seeking to a CRA picture using GStreamer. The framework is currently missing the code to skip over RASL pictures placed after the CRA. This situation can also occur while doing live streaming over lossy transport.
--- drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c +13 -2
@@ -283,6 +283,15 @@ static void set_params(struct hantro_ctxhantro_reg_write (vpu, &g2_apf_threshold,8 ); } +static u32 get_dpb_index (const struct v4l2_ctrl_hevc_decode_params *decode_params, +const u32 index) +{ +if (index > decode_params->num_active_dpb_entries) +return 0 ; + +return index; +} +static void set_ref_pic_list (struct hantro_ctx *ctx) {const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
@@ -355,8 +364,10 @@ static void set_ref_pic_list(struct hant list1[j++] = list1[i++];for (i =0 ; i <V4L2_HEVC_DPB_ENTRIES_NUM_MAX ; i++) { -hantro_reg_write (vpu, &ref_pic_regs0[i], list0[i]); -hantro_reg_write (vpu, &ref_pic_regs1[i], list1[i]); +hantro_reg_write (vpu, &ref_pic_regs0[i], +get_dpb_index (decode_params, list0[i])); +hantro_reg_write (vpu, &ref_pic_regs1[i], +get_dpb_index (decode_params, list1[i])); } }
Greg Kroah-Hartman
maintainerPATCH 409/567 media: videobuf2: Fix device reference leak in vb2_dc_alloc error path
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
commit 94de23a9aa487d7c1372efb161721d7949a177ae upstream.
In vb2_dc_alloc(), get_device() is called to increment the device reference count. However, if subsequent DMA allocation fails (vb2_dc_alloc_coherent or vb2_dc_alloc_non_coherent returns error), the function returns without calling put_device(), causing a device reference leak.
Add put_device() call in the error path before kfree() to properly release the device reference acquired earlier.
--- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/common/videobuf2/videobuf2-dma-contig.c +1 -0
@@ -258,6 +258,7 @@ static void *vb2_dc_alloc(struct vb2_bufif (ret) {dev_err (dev,"dma alloc of size %lu failed\n" , size); +put_device (buf->dev);kfree (buf);return ERR_PTR (-ENOMEM ); }
Greg Kroah-Hartman
maintainerPATCH 410/567 media: vpif_capture: fix section mismatch
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 0ef841113724166c3c484d0e9ae6db1eb5634fde upstream.
Platform drivers can be probed after their init sections have been discarded (e.g. on probe deferral or manual rebind through sysfs) so the probe function must not live in init.
Note that commit ffa1b391c61b ("V4L/DVB: vpif_cap/disp: Removed section mismatch warning") incorrectly suppressed the modpost warning.
--- drivers/media/platform/ti/davinci/vpif_capture.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/platform/ti/davinci/vpif_capture.c +2 -2
@@ -1602,7 +1602,7 @@ err_cleanup:* This creates device entries by register itself to the V4L2 driver and * initializes fields of each channel objects */ -static __init int vpif_probe (struct platform_device *pdev) +static int vpif_probe (struct platform_device *pdev) {struct vpif_subdev_info *subdevdata;struct i2c_adapter *i2c_adap;
@@ -1809,7 +1809,7 @@ static int vpif_resume(struct device *de static SIMPLE_DEV_PM_OPS(vpif_pm_ops, vpif_suspend, vpif_resume); -static __refdata struct platform_driver vpif_driver = { +static struct platform_driver vpif_driver = { .driver = { .name =VPIF_DRIVER_NAME , .pm = &vpif_pm_ops,
Greg Kroah-Hartman
maintainerPATCH 411/567 media: vpif_display: fix section mismatch
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 59ca64bf98e4209df8ace8057d31ae3c80f948cd upstream.
Platform drivers can be probed after their init sections have been discarded (e.g. on probe deferral or manual rebind through sysfs) so the probe function must not live in init.
Note that commit ffa1b391c61b ("V4L/DVB: vpif_cap/disp: Removed section mismatch warning") incorrectly suppressed the modpost warning.
--- drivers/media/platform/ti/davinci/vpif_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/platform/ti/davinci/vpif_display.c +2 -2
@@ -1216,7 +1216,7 @@ probe_out:* vpif_probe: This function creates device entries by register itself to the * V4L2 driver and initializes fields of each channel objects */ -static __init int vpif_probe (struct platform_device *pdev) +static int vpif_probe (struct platform_device *pdev) {struct vpif_subdev_info *subdevdata;struct i2c_adapter *i2c_adap;
@@ -1392,7 +1392,7 @@ static int vpif_resume(struct device *de static SIMPLE_DEV_PM_OPS(vpif_pm_ops, vpif_suspend, vpif_resume); -static __refdata struct platform_driver vpif_driver = { +static struct platform_driver vpif_driver = { .driver = { .name =VPIF_DRIVER_NAME , .pm = &vpif_pm_ops,
Greg Kroah-Hartman
maintainerPATCH 412/567 media: amphion: Cancel message work before releasing the VPU core
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Qian <[email protected]>
commit ae246b0032146e352c4c06a7bf03cd3d5bcb2ecd upstream.
To avoid accessing the VPU register after release of the VPU core, cancel the message work and destroy the workqueue that handles the VPU message before release of the VPU core.
--- drivers/media/platform/amphion/vpu_v4l2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/media/platform/amphion/vpu_v4l2.c +3 -3
@@ -698,15 +698,15 @@ static int vpu_v4l2_release(struct vpu_i {vpu_trace (inst->vpu->dev,"%p\n" , inst); -vpu_release_core (inst->core); -put_device (inst->dev); -if (inst->workqueue) {cancel_work_sync (&inst->msg_work);destroy_workqueue (inst->workqueue); inst->workqueue =NULL ; } +vpu_release_core (inst->core); +put_device (inst->dev); +v4l2_ctrl_handler_free (&inst->ctrl_handler);mutex_destroy (&inst->lock);
Greg Kroah-Hartman
maintainerPATCH 413/567 media: i2c: ADV7604: Remove redundant cancel_delayed_work in probe
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit 8f34f24355a607b98ecd9924837aab13c676eeca upstream.
The delayed_work delayed_work_enable_hotplug is initialized with INIT_DELAYED_WORK() in adv76xx_probe(), but it is never scheduled anywhere in the probe function.
Calling cancel_delayed_work() on a work that has never been scheduled is redundant and unnecessary, as there is no pending work to cancel.
Remove the redundant cancel_delayed_work() from error handling path and adjust the goto label accordingly to simplify the code and avoid potential confusion.
--- drivers/media/i2c/adv7604.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/media/i2c/adv7604.c +1 -3
@@ -3620,7 +3620,7 @@ static int adv76xx_probe(struct i2c_clie err =media_entity_pads_init (&sd->entity, state->source_pad +1 , state->pads);if (err) - goto err_work_queues; + goto err_i2c;/* Configure regmaps */ err =configure_regmaps (state);
@@ -3661,8 +3661,6 @@ static int adv76xx_probe(struct i2c_clie err_entity:media_entity_cleanup (&sd->entity); -err_work_queues: -cancel_delayed_work (&state->delayed_work_enable_hotplug); err_i2c:adv76xx_unregister_clients (state); err_hdl:
Greg Kroah-Hartman
maintainerPATCH 414/567 media: i2c: adv7842: Remove redundant cancel_delayed_work in probe
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit e66a5cc606c58e72f18f9cdd868a3672e918f9f8 upstream.
The delayed_work delayed_work_enable_hotplug is initialized with INIT_DELAYED_WORK() in adv7842_probe(), but it is never scheduled anywhere in the probe function.
Calling cancel_delayed_work() on a work that has never been scheduled is redundant and unnecessary, as there is no pending work to cancel.
Remove the redundant cancel_delayed_work() from error handling path and adjust the goto label accordingly to simplify the code and avoid potential confusion.
--- drivers/media/i2c/adv7842.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/media/i2c/adv7842.c +1 -3
@@ -3573,7 +3573,7 @@ static int adv7842_probe(struct i2c_clie err =media_entity_pads_init (&sd->entity,ADV7842_PAD_SOURCE +1 , state->pads);if (err) - goto err_work_queues; + goto err_i2c; err =adv7842_core_init (sd);if (err)
@@ -3594,8 +3594,6 @@ static int adv7842_probe(struct i2c_clie err_entity:media_entity_cleanup (&sd->entity); -err_work_queues: -cancel_delayed_work (&state->delayed_work_enable_hotplug); err_i2c:adv7842_unregister_clients (sd); err_hdl:
Greg Kroah-Hartman
maintainerPATCH 415/567 media: mediatek: vcodec: Fix a reference leak in mtk_vcodec_fw_vpu_init()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit cdd0f118ef87db8a664fb5ea366fd1766d2df1cd upstream.
vpu_get_plat_device() increases the reference count of the returned platform device. However, when devm_kzalloc() fails, the reference is not released, causing a reference leak.
Fix this by calling put_device() on fw_pdev->dev before returning on the error path.
--- drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c +3 -1
@@ -117,8 +117,10 @@ struct mtk_vcodec_fw *mtk_vcodec_fw_vpu_vpu_wdt_reg_handler (fw_pdev, mtk_vcodec_vpu_reset_enc_handler, priv, rst_id); fw =devm_kzalloc (&plat_dev->dev,sizeof (*fw),GFP_KERNEL ); -if (!fw) +if (!fw) { +put_device (&fw_pdev->dev);return ERR_PTR (-ENOMEM ); + } fw->type =VPU ; fw->ops = &mtk_vcodec_vpu_msg; fw->pdev = fw_pdev;
Greg Kroah-Hartman
maintainerPATCH 416/567 LoongArch: Add new PCI ID for pci_fixup_vgadev()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit bf3fa8f232a1eec8d7b88dcd9e925e60f04f018d upstream.
Loongson-2K3000 has a new PCI ID (0x7a46) for its display controller, Add it for pci_fixup_vgadev() since we prefer a discrete graphics card as default boot device if present.
--- arch/loongarch/pci/pci.c | 2 ++ 1 file changed, 2 insertions(+)
arch/loongarch/pci/pci.c +2 -0
@@ -15,6 +15,7 @@#define PCI_DEVICE_ID_LOONGSON_HOST 0x7a00#define PCI_DEVICE_ID_LOONGSON_DC1 0x7a06#define PCI_DEVICE_ID_LOONGSON_DC2 0x7a36 +#define PCI_DEVICE_ID_LOONGSON_DC3 0x7a46int raw_pci_read (unsigned int domain,unsigned int bus,unsigned int devfn,int reg,int len,u32 *val)
@@ -98,3 +99,4 @@ static void pci_fixup_vgadev(struct pci_ }DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_LOONGSON ,PCI_DEVICE_ID_LOONGSON_DC1 , pci_fixup_vgadev);DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_LOONGSON ,PCI_DEVICE_ID_LOONGSON_DC2 , pci_fixup_vgadev); +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_LOONGSON ,PCI_DEVICE_ID_LOONGSON_DC3 , pci_fixup_vgadev);
Greg Kroah-Hartman
maintainerPATCH 417/567 LoongArch: Correct the calculation logic of thread_count
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qiang Ma <[email protected]>
commit 1de0ae21f136efa6c5d8a4d3e07b7d1ca39c750f upstream.
For thread_count, the current calculation method has a maximum of 255, which may not be sufficient in the future. Therefore, we are correcting it now.
Reference: SMBIOS Specification, 7.5 Processor Information (Type 4)[1]
[1]: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.9.0.pdf
--- arch/loongarch/kernel/setup.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/loongarch/kernel/setup.c +7 -1
@@ -56,6 +56,7 @@#define SMBIOS_FREQLOW_MASK 0xFF#define SMBIOS_CORE_PACKAGE_OFFSET 0x23#define SMBIOS_THREAD_PACKAGE_OFFSET 0x25 +#define SMBIOS_THREAD_PACKAGE_2_OFFSET 0x2E#define LOONGSON_EFI_ENABLE (1 << 3)unsigned long fw_arg0, fw_arg1, fw_arg2;
@@ -126,7 +127,12 @@ static void __init parse_cpu_table(const cpu_clock_freq = freq_temp *1000000 ; loongson_sysconf.cpuname = (void *)dmi_string_parse (dm, dmi_data[16 ]); - loongson_sysconf.cores_per_package = *(dmi_data +SMBIOS_THREAD_PACKAGE_OFFSET ); + loongson_sysconf.cores_per_package = *(u8 *)(dmi_data +SMBIOS_THREAD_PACKAGE_OFFSET ); +if (dm->length >=0x30 && loongson_sysconf.cores_per_package ==0xff ) { +/* SMBIOS 3.0+ has ThreadCount2 for more than 255 threads */ + loongson_sysconf.cores_per_package = + *(u16 *)(dmi_data +SMBIOS_THREAD_PACKAGE_2_OFFSET ); + }pr_info ("CpuClock = %llu\n" , cpu_clock_freq); }
Greg Kroah-Hartman
maintainerPATCH 418/567 LoongArch: Fix build errors for CONFIG_RANDSTRUCT
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 3c250aecef62da81deb38ac6738ac0a88d91f1fc upstream.
When CONFIG_RANDSTRUCT enabled, members of task_struct are randomized. There is a chance that TASK_STACK_CANARY be out of 12bit immediate's range and causes build errors. TASK_STACK_CANARY is naturally aligned, so fix it by replacing ld.d/st.d with ldptr.d/stptr.d which have 14bit immediates.
--- arch/loongarch/kernel/switch.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/loongarch/kernel/switch.S +2 -2
@@ -25,8 +25,8 @@ SYM_FUNC_START(__switch_to) stptr.d a4, a0, THREAD_SCHED_CFA #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_SMP) la t7, __stack_chk_guard - LONG_L t8, a1, TASK_STACK_CANARY - LONG_S t8, t7, 0 + ldptr.d t8, a1, TASK_STACK_CANARY + stptr.d t8, t7, 0 #endif move tp, a2 cpu_restore_nonscratch a1
Greg Kroah-Hartman
maintainerPATCH 419/567 LoongArch: Use __pmd()/__pte() for swap entry conversions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
commit 4a71df151e703b5e7e85b33369cee59ef2665e61 upstream.
The __pmd() and __pte() helper macros provide the correct initialization syntax and abstraction for the pmd_t and pte_t types.
Use __pmd() to fix follow warning about __swp_entry_to_pmd() with gcc-15 under specific configs [1] :
In file included from ./include/linux/pgtable.h:6,
from ./include/linux/mm.h:31,
from ./include/linux/pagemap.h:8,
from arch/loongarch/mm/init.c:14:
./include/linux/swapops.h: In function ‘swp_entry_to_pmd’:
./arch/loongarch/include/asm/pgtable.h:302:34: error: missing braces around initializer [-Werror=missing-braces]
302 | #define __swp_entry_to_pmd(x) ((pmd_t) { (x).val | _PAGE_HUGE })
| ^
./include/linux/swapops.h:559:16: note: in expansion of macro ‘__swp_entry_to_pmd’
559 | return __swp_entry_to_pmd(arch_entry);
| ^~~~~~~~~~~~~~~~~~cc1: all warnings being treated as errors
Also update __swp_entry_to_pte() to use __pte() for consistency.
[1]. https://download.01.org/0day-ci/archive/20251119/[email protected]/config
--- arch/loongarch/include/asm/pgtable.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/loongarch/include/asm/pgtable.h +2 -2
@@ -295,9 +295,9 @@ static inline pte_t mk_swap_pte(unsigned#define __swp_offset (x) ((x).val >> 24)#define __swp_entry (type, offset) ((swp_entry_t) { pte_val(mk_swap_pte((type), (offset))) })#define __pte_to_swp_entry (pte) ((swp_entry_t) { pte_val(pte) }) -#define __swp_entry_to_pte (x) ((pte_t) { (x).val }) +#define __swp_entry_to_pte (x) __pte((x).val)#define __pmd_to_swp_entry (pmd) ((swp_entry_t) { pmd_val(pmd) }) -#define __swp_entry_to_pmd (x) ((pmd_t) { (x).val | _PAGE_HUGE }) +#define __swp_entry_to_pmd (x) __pmd((x).val | _PAGE_HUGE)static inline int pte_swp_exclusive (pte_t pte) {
Greg Kroah-Hartman
maintainerPATCH 420/567 LoongArch: Use unsigned long for _end and _text
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tiezhu Yang <[email protected]>
commit a258a3cb1895e3acf5f2fe245d17426e894bc935 upstream.
It is better to use unsigned long rather than long for _end and _text to calculate the kernel length.
--- arch/loongarch/kernel/relocate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/loongarch/kernel/relocate.c +2 -2
@@ -183,7 +183,7 @@ static inline void __init *determine_relif (kaslr_disabled ())return destination; - kernel_length = (long )_end - (long )_text; + kernel_length = (unsigned long )_end - (unsigned long )_text; random_offset =get_random_boot () <<16 ; random_offset &= (CONFIG_RANDOMIZE_BASE_MAX_OFFSET -1 );
@@ -232,7 +232,7 @@ unsigned long __init relocate_kernel(voiearly_memunmap (cmdline,COMMAND_LINE_SIZE );if (random_offset) { - kernel_length = (long )(_end) - (long )(_text); + kernel_length = (unsigned long )(_end) - (unsigned long )(_text);/* Copy the kernel to it's new location */ memcpy (location_new, _text, kernel_length);
Greg Kroah-Hartman
maintainerPATCH 421/567 mm/damon/tests/sysfs-kunit: handle alloc failures on damon_sysfs_test_add_targets()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 7d808bf13943f4c6a6142400bffe14267f6dc997 upstream.
damon_sysfs_test_add_targets() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/sysfs-kunit.h | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
mm/damon/tests/sysfs-kunit.h +25 -0
@@ -45,16 +45,41 @@ static void damon_sysfs_test_add_targets(struct kunit *test)struct damon_ctx *ctx; sysfs_targets =damon_sysfs_targets_alloc (); +if (!sysfs_targets) +kunit_skip (test,"sysfs_targets alloc fail" ); sysfs_targets->nr =1 ; sysfs_targets->targets_arr =kmalloc_array (1 ,sizeof (*sysfs_targets->targets_arr),GFP_KERNEL ); +if (!sysfs_targets->targets_arr) { +kfree (sysfs_targets); +kunit_skip (test,"targets_arr alloc fail" ); + } sysfs_target =damon_sysfs_target_alloc (); +if (!sysfs_target) { +kfree (sysfs_targets->targets_arr); +kfree (sysfs_targets); +kunit_skip (test,"sysfs_target alloc fail" ); + } sysfs_target->pid =__damon_sysfs_test_get_any_pid (12 ,100 ); sysfs_target->regions =damon_sysfs_regions_alloc (); +if (!sysfs_target->regions) { +kfree (sysfs_targets->targets_arr); +kfree (sysfs_targets); +kfree (sysfs_target); +kunit_skip (test,"sysfs_regions alloc fail" ); + } + sysfs_targets->targets_arr[0 ] = sysfs_target; ctx =damon_new_ctx (); +if (!ctx) { +kfree (sysfs_targets->targets_arr); +kfree (sysfs_targets); +kfree (sysfs_target); +kfree (sysfs_target->regions); +kunit_skip (test,"ctx alloc fail" ); + }damon_sysfs_add_targets (ctx, sysfs_targets);KUNIT_EXPECT_EQ (test,1u ,nr_damon_targets (ctx));
Signature · 1 line
2.52.0
Greg Kroah-Hartman
maintainerPATCH 422/567 mm/damon/tests/vaddr-kunit: handle alloc failures in damon_test_split_evenly_fail()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 7890e5b5bb6e386155c6e755fe70e0cdcc77f18e upstream.
damon_test_split_evenly_fail() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/vaddr-kunit.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
mm/damon/tests/vaddr-kunit.h +10 -1
@@ -250,7 +250,16 @@ static void damon_test_split_evenly_fail unsigned long start, unsigned long end, unsigned int nr_pieces) { struct damon_target *t = damon_new_target(); -struct damon_region *r =damon_new_region (start, end); +struct damon_region *r; + +if (!t) +kunit_skip (test,"target alloc fail" ); + + r =damon_new_region (start, end); +if (!r) { +damon_free_target (t); +kunit_skip (test,"region alloc fail" ); + }damon_add_region (r, t); KUNIT_EXPECT_EQ(test,
Greg Kroah-Hartman
maintainerPATCH 423/567 mm/damon/tests/vaddr-kunit: handle alloc failures on damon_test_split_evenly_succ()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 0a63a0e7570b9b2631dfb8d836dc572709dce39e upstream.
damon_test_split_evenly_succ() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/vaddr-kunit.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
mm/damon/tests/vaddr-kunit.h +8 -1
@@ -278,10 +278,17 @@ static void damon_test_split_evenly_succ unsigned long start, unsigned long end, unsigned int nr_pieces) { struct damon_target *t = damon_new_target(); -struct damon_region *r =damon_new_region (start, end); +struct damon_region *r;unsigned long expected_width = (end - start) / nr_pieces;unsigned long i =0 ; +if (!t) +kunit_skip (test,"target alloc fail" ); + r =damon_new_region (start, end); +if (!r) { +damon_free_target (t); +kunit_skip (test,"region alloc fail" ); + }damon_add_region (r, t);KUNIT_EXPECT_EQ (test,damon_va_evenly_split_region (t, r, nr_pieces),0 );
Greg Kroah-Hartman
maintainerPATCH 424/567 mm/damon/tests/core-kunit: handle alloc failures on damon_test_split_at()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 5e80d73f22043c59c8ad36452a3253937ed77955 upstream.
damon_test_split_at() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
mm/damon/tests/core-kunit.h +11 -0
@@ -124,8 +124,19 @@ static void damon_test_split_at(struct kstruct damon_target *t;struct damon_region *r, *r_new; +if (!c) +kunit_skip (test,"ctx alloc fail" ); t =damon_new_target (); +if (!t) { +damon_destroy_ctx (c); +kunit_skip (test,"target alloc fail" ); + } r =damon_new_region (0 ,100 ); +if (!r) { +damon_destroy_ctx (c); +damon_free_target (t); +kunit_skip (test,"region alloc fail" ); + } r->nr_accesses_bp =420000 ; r->nr_accesses =42 ; r->last_nr_accesses =15 ;
Greg Kroah-Hartman
maintainerPATCH 425/567 mm/damon/tests/core-kunit: handle allocation failures in damon_test_regions()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit e16fdd4f754048d6e23c56bd8d920b71e41e3777 upstream.
damon_test_regions() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 6 ++++++ 1 file changed, 6 insertions(+)
mm/damon/tests/core-kunit.h +6 -0
@@ -20,11 +20,17 @@ static void damon_test_regions(struct kustruct damon_target *t; r =damon_new_region (1 ,2 ); +if (!r) +kunit_skip (test,"region alloc fail" );KUNIT_EXPECT_EQ (test,1ul , r->ar.start);KUNIT_EXPECT_EQ (test,2ul , r->ar.end);KUNIT_EXPECT_EQ (test,0u , r->nr_accesses); t =damon_new_target (); +if (!t) { +damon_free_region (r); +kunit_skip (test,"target alloc fail" ); + }KUNIT_EXPECT_EQ (test,0u ,damon_nr_regions (t));damon_add_region (r, t);
Greg Kroah-Hartman
maintainerPATCH 426/567 mm/damon/tests/core-kunit: handle memory failure from damon_test_target()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit fafe953de2c661907c94055a2497c6b8dbfd26f3 upstream.
damon_test_target() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 7 +++++++ 1 file changed, 7 insertions(+)
mm/damon/tests/core-kunit.h +7 -0
@@ -58,7 +58,14 @@ static void damon_test_target(struct kunstruct damon_ctx *c =damon_new_ctx ();struct damon_target *t; +if (!c) +kunit_skip (test,"ctx alloc fail" ); + t =damon_new_target (); +if (!t) { +damon_destroy_ctx (c); +kunit_skip (test,"target alloc fail" ); + }KUNIT_EXPECT_EQ (test,0u ,nr_damon_targets (c));damon_add_target (c, t);
Greg Kroah-Hartman
maintainerPATCH 427/567 mm/damon/tests/core-kunit: handle memory alloc failure from damon_test_aggregate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit f79f2fc44ebd0ed655239046be3e80e8804b5545 upstream.
damon_test_aggregate() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
mm/damon/tests/core-kunit.h +11 -0
@@ -97,8 +97,15 @@ static void damon_test_aggregate(structstruct damon_region *r;int it, ir; +if (!ctx) +kunit_skip (test,"ctx alloc fail" ); +for (it =0 ; it <3 ; it++) { t =damon_new_target (); +if (!t) { +damon_destroy_ctx (ctx); +kunit_skip (test,"target alloc fail" ); + }damon_add_target (ctx, t); }
@@ -106,6 +113,10 @@ static void damon_test_aggregate(structdamon_for_each_target (t, ctx) {for (ir =0 ; ir <3 ; ir++) { r =damon_new_region (saddr[it][ir], eaddr[it][ir]); +if (!r) { +damon_destroy_ctx (ctx); +kunit_skip (test,"region alloc fail" ); + } r->nr_accesses = accesses[it][ir]; r->nr_accesses_bp = accesses[it][ir] *10000 ;damon_add_region (r, t);
Greg Kroah-Hartman
maintainerPATCH 428/567 mm/damon/tests/core-kunit: handle alloc failures on dasmon_test_merge_regions_of()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 0998d2757218771c59d5ca59ccf13d1542a38f17 upstream.
damon_test_merge_regions_of() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 6 ++++++ 1 file changed, 6 insertions(+)
mm/damon/tests/core-kunit.h +6 -0
@@ -238,8 +238,14 @@ static void damon_test_merge_regions_of(int i; t =damon_new_target (); +if (!t) +kunit_skip (test,"target alloc fail" );for (i =0 ; i <ARRAY_SIZE (sa); i++) { r =damon_new_region (sa[i], ea[i]); +if (!r) { +damon_free_target (t); +kunit_skip (test,"region alloc fail" ); + } r->nr_accesses = nrs[i]; r->nr_accesses_bp = nrs[i] *10000 ;damon_add_region (r, t);
Greg Kroah-Hartman
maintainerPATCH 429/567 mm/damon/tests/core-kunit: handle alloc failures on damon_test_merge_two()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 3d443dd29a1db7efa587a4bb0c06a497e13ca9e4 upstream.
damon_test_merge_two() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
mm/damon/tests/core-kunit.h +10 -0
@@ -188,11 +188,21 @@ static void damon_test_merge_two(structint i; t =damon_new_target (); +if (!t) +kunit_skip (test,"target alloc fail" ); r =damon_new_region (0 ,100 ); +if (!r) { +damon_free_target (t); +kunit_skip (test,"region alloc fail" ); + } r->nr_accesses =10 ; r->nr_accesses_bp =100000 ;damon_add_region (r, t); r2 =damon_new_region (100 ,300 ); +if (!r2) { +damon_free_target (t); +kunit_skip (test,"second region alloc fail" ); + } r2->nr_accesses =20 ; r2->nr_accesses_bp =200000 ;damon_add_region (r2, t);
Greg Kroah-Hartman
maintainerPATCH 430/567 mm/damon/tests/core-kunit: handle alloc failures in damon_test_set_regions()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 74d5969995d129fd59dd93b9c7daa6669cb6810f upstream.
damon_test_set_regions() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
mm/damon/tests/core-kunit.h +15 -2
@@ -345,13 +345,26 @@ static void damon_test_ops_registration(static void damon_test_set_regions (struct kunit *test) {struct damon_target *t =damon_new_target (); -struct damon_region *r1 =damon_new_region (4 ,16 ); -struct damon_region *r2 =damon_new_region (24 ,32 ); +struct damon_region *r1, *r2;struct damon_addr_range range = {.start =8 , .end =28 };unsigned long expects[] = {8 ,16 ,16 ,24 ,24 ,28 };int expect_idx =0 ;struct damon_region *r; +if (!t) +kunit_skip (test,"target alloc fail" ); + r1 =damon_new_region (4 ,16 ); +if (!r1) { +damon_free_target (t); +kunit_skip (test,"region alloc fail" ); + } + r2 =damon_new_region (24 ,32 ); +if (!r2) { +damon_free_target (t); +damon_free_region (r1); +kunit_skip (test,"second region alloc fail" ); + } +damon_add_region (r1, t);damon_add_region (r2, t);damon_set_regions (t, &range,1 );
Greg Kroah-Hartman
maintainerPATCH 431/567 mm/damon/tests/core-kunit: handle alloc failures in damon_test_update_monitoring_result()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 8cf298c01b7fdb08eef5b6b26d0fe98d48134d72 upstream.
damon_test_update_monitoring_result() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 3 +++ 1 file changed, 3 insertions(+)
mm/damon/tests/core-kunit.h +3 -0
@@ -406,6 +406,9 @@ static void damon_test_update_monitoringstruct damon_attrs new_attrs;struct damon_region *r =damon_new_region (3 ,7 ); +if (!r) +kunit_skip (test,"region alloc fail" ); + r->nr_accesses =15 ; r->nr_accesses_bp =150000 ; r->age =20 ;
Greg Kroah-Hartman
maintainerPATCH 432/567 mm/damon/tests/core-kunit: handle alloc failures in damon_test_ops_registration()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 4f835f4e8c863985f15abd69db033c2f66546094 upstream.
damon_test_ops_registration() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 3 +++ 1 file changed, 3 insertions(+)
mm/damon/tests/core-kunit.h +3 -0
@@ -300,6 +300,9 @@ static void damon_test_ops_registration(struct damon_operations ops = {.id =DAMON_OPS_VADDR }, bak;bool need_cleanup = false; +if (!c) +kunit_skip (test,"ctx alloc fail" ); +/* DAMON_OPS_VADDR is registered only if CONFIG_DAMON_VADDR is set */ if (!damon_is_registered_ops (DAMON_OPS_VADDR )) { bak.id =DAMON_OPS_VADDR ;
Greg Kroah-Hartman
maintainerPATCH 433/567 mm/damon/tests/core-kunit: handle alloc failure on damon_test_set_attrs()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 915a2453d824a9b6bf724e3f970d86ae1d092a61 upstream.
damon_test_set_attrs() is assuming all dynamic memory allocation in it will succeed. Those are indeed likely in the real use cases since those allocations are too small to fail, but theoretically those could fail. In the case, inappropriate memory access can happen. Fix it by appropriately cleanup pre-allocated memory and skip the execution of the remaining tests in the failure cases.
--- mm/damon/tests/core-kunit.h | 3 +++ 1 file changed, 3 insertions(+)
mm/damon/tests/core-kunit.h +3 -0
@@ -445,6 +445,9 @@ static void damon_test_set_attrs(struct .sample_interval = 5000, .aggr_interval = 100000,};struct damon_attrs invalid_attrs; +if (!c) +kunit_skip (test,"ctx alloc fail" ); +KUNIT_EXPECT_EQ (test,damon_set_attrs (c, &valid_attrs),0 ); invalid_attrs = valid_attrs;
Greg Kroah-Hartman
maintainerPATCH 434/567 pmdomain: imx: Fix reference count leak in imx_gpc_probe()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wentao Liang <[email protected]>
commit 73cb5f6eafb0ac7aea8cdeb8ff12981aa741d8fb upstream.
of_get_child_by_name() returns a node pointer with refcount incremented. Use the __free() attribute to manage the pgc_node reference, ensuring automatic of_node_put() cleanup when pgc_node goes out of scope.
This eliminates the need for explicit error handling paths and avoids reference count leaks.
--- drivers/pmdomain/imx/gpc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/pmdomain/imx/gpc.c +2 -3
@@ -403,13 +403,12 @@ clk_err:static int imx_gpc_probe (struct platform_device *pdev) {const struct imx_gpc_dt_data *of_id_data =device_get_match_data (&pdev->dev); -struct device_node *pgc_node; + struct device_node *pgc_node __free(device_node) + =of_get_child_by_name (pdev->dev.of_node,"pgc" );struct regmap *regmap;void __iomem *base;int ret; - pgc_node =of_get_child_by_name (pdev->dev.of_node,"pgc" ); -/* bail out if DT too old and doesn't provide the necessary info */ if (!of_property_read_bool (pdev->dev.of_node,"#power-domain-cells" ) && !pgc_node)
Greg Kroah-Hartman
maintainerPATCH 435/567 compiler_types.h: add "auto" as a macro for "__auto_type"
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: H. Peter Anvin <[email protected]>
commit 2fb6915fa22dc5524d704afba58a13305dd9f533 upstream.
"auto" was defined as a keyword back in the K&R days, but as a storage type specifier. No one ever used it, since it was and is the default storage type for local variables.
C++11 recycled the keyword to allow a type to be declared based on the type of an initializer. This was finally adopted into standard C in C23.
gcc and clang provide the "__auto_type" alias keyword as an extension for pre-C23, however, there is no reason to pollute the bulk of the source base with this temporary keyword; instead define "auto" as a macro unless the compiler is running in C23+ mode.
This macro is added in <linux/compiler_types.h> because that header is included in some of the tools headers, wheres <linux/compiler.h> is not as it has a bunch of very kernel-specific things in it.
[ Cc: stable to reduce potential backporting burden. ]
--- include/linux/compiler_types.h | 13 +++++++++++++ 1 file changed, 13 insertions(+)
include/linux/compiler_types.h +13 -0
@@ -14,6 +14,19 @@#ifndef __ASSEMBLY__/* +* C23 introduces "auto" as a standard way to define type-inferred +* variables, but "auto" has been a (useless) keyword even since K&R C, +* so it has always been "namespace reserved." +* +* Until at some future time we require C23 support, we need the gcc +* extension __auto_type, but there is no reason to put that elsewhere +* in the source code. +*/ +#if __STDC_VERSION__ <202311L +# define auto __auto_type +#endif + +/* * Skipped when running bindgen due to a libclang issue; * see https://github.com/rust-lang/rust-bindgen/issues/2244. */
Greg Kroah-Hartman
maintainerPATCH 436/567 mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiayuan Chen <[email protected]>
commit 007f5da43b3d0ecff972e2616062b8da1f862f5e upstream.
Patch series "kasan: vmalloc: Fixes for the percpu allocator and vrealloc", v3.
Patches fix two issues related to KASAN and vmalloc.
The first one, a KASAN tag mismatch, possibly resulting in a kernel panic, can be observed on systems with a tag-based KASAN enabled and with multiple NUMA nodes. Initially it was only noticed on x86 [1] but later a similar issue was also reported on arm64 [2].
Specifically the problem is related to how vm_structs interact with pcpu_chunks - both when they are allocated, assigned and when pcpu_chunk addresses are derived.
When vm_structs are allocated they are unpoisoned, each with a different random tag, if vmalloc support is enabled along the KASAN mode. Later when first pcpu chunk is allocated it gets its 'base_addr' field set to the first allocated vm_struct. With that it inherits that vm_struct's tag.
When pcpu_chunk addresses are later derived (by pcpu_chunk_addr(), for example in pcpu_alloc_noprof()) the base_addr field is used and offsets are added to it. If the initial conditions are satisfied then some of the offsets will point into memory allocated with a different vm_struct. So while the lower bits will get accurately derived the tag bits in the top of the pointer won't match the shadow memory contents.
The solution (proposed at v2 of the x86 KASAN series [3]) is to unpoison the vm_structs with the same tag when allocating them for the per cpu allocator (in pcpu_get_vm_areas()).
The second one reported by syzkaller [4] is related to vrealloc and happens because of random tag generation when unpoisoning memory without allocating new pages. This breaks shadow memory tracking and needs to reuse the existing tag instead of generating a new one. At the same time an inconsistency in used flags is corrected.
This patch (of 3):
Syzkaller reported a memory out-of-bounds bug [4]. This patch fixes two issues:
1. In vrealloc the KASAN_VMALLOC_VM_ALLOC flag is missing when unpoisoning the extended region. This flag is required to correctly associate the allocation with KASAN's vmalloc tracking.
Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it. vrealloc must behave consistently -- especially when reusing existing vmalloc regions -- to ensure KASAN can track allocations correctly.
2. When vrealloc reuses an existing vmalloc region (without allocating new pages) KASAN generates a new tag, which breaks tag-based memory access tracking.
Introduce KASAN_VMALLOC_KEEP_TAG, a new KASAN flag that allows reusing the tag already attached to the pointer, ensuring consistent tag behavior during reallocation.
Pass KASAN_VMALLOC_KEEP_TAG and KASAN_VMALLOC_VM_ALLOC to the kasan_unpoison_vmalloc inside vrealloc_node_align_noprof().
--- include/linux/kasan.h | 1 + mm/kasan/hw_tags.c | 2 +- mm/kasan/shadow.c | 4 +++- mm/vmalloc.c | 4 +++- 4 files changed, 8 insertions(+), 3 deletions(-)
include/linux/kasan.h +1 -0
@@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vma#define KASAN_VMALLOC_INIT ((__force kasan_vmalloc_flags_t)0x01u)#define KASAN_VMALLOC_VM_ALLOC ((__force kasan_vmalloc_flags_t)0x02u)#define KASAN_VMALLOC_PROT_NORMAL ((__force kasan_vmalloc_flags_t)0x04u) +#define KASAN_VMALLOC_KEEP_TAG ((__force kasan_vmalloc_flags_t)0x08u)#define KASAN_VMALLOC_PAGE_RANGE 0x1/* Apply exsiting page range */ #define KASAN_VMALLOC_TLB_FLUSH 0x2/* TLB flush */
mm/kasan/hw_tags.c +1 -1
@@ -345,7 +345,7 @@ void *__kasan_unpoison_vmalloc(const voireturn (void *)start; } - tag =kasan_random_tag (); + tag = (flags &KASAN_VMALLOC_KEEP_TAG ) ?get_tag (start) :kasan_random_tag (); start =set_tag (start, tag);/* Unpoison and initialize memory up to size. */
mm/kasan/shadow.c +3 -1
@@ -561,7 +561,9 @@ void *__kasan_unpoison_vmalloc(const voi !(flags & KASAN_VMALLOC_PROT_NORMAL))return (void *)start; - start =set_tag (start,kasan_random_tag ()); +if (unlikely (!(flags &KASAN_VMALLOC_KEEP_TAG ))) + start =set_tag (start,kasan_random_tag ()); +kasan_unpoison (start, size, false);return (void *)start; }
mm/vmalloc.c +3 -1
@@ -4118,7 +4118,9 @@ void *vrealloc_noprof(const void *p, siz*/ if (size <= alloced_size) {kasan_unpoison_vmalloc (p + old_size, size - old_size, -KASAN_VMALLOC_PROT_NORMAL ); +KASAN_VMALLOC_PROT_NORMAL | +KASAN_VMALLOC_VM_ALLOC | +KASAN_VMALLOC_KEEP_TAG );/* * No need to zero memory here, as unused memory will have * already been zeroed at initial allocation time or during
Greg Kroah-Hartman
maintainerPATCH 437/567 kasan: refactor pcpu kasan vmalloc unpoison
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej Wieczor-Retman <[email protected]>
commit 6f13db031e27e88213381039032a9cc061578ea6 upstream.
A KASAN tag mismatch, possibly causing a kernel panic, can be observed on systems with a tag-based KASAN enabled and with multiple NUMA nodes. It was reported on arm64 and reproduced on x86. It can be explained in the following points:
1. There can be more than one virtual memory chunk.
2. Chunk's base address has a tag.
3. The base address points at the first chunk and thus inherits the tag of the first chunk.
4. The subsequent chunks will be accessed with the tag from the first chunk.
5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk.
Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in preparation for the actual fix.
--- include/linux/kasan.h | 15 +++++++++++++++ mm/kasan/common.c | 17 +++++++++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 33 insertions(+), 3 deletions(-)
include/linux/kasan.h +15 -0
@@ -608,6 +608,16 @@ static __always_inline void kasan_poison__kasan_poison_vmalloc (start, size); } +void __kasan_unpoison_vmap_areas (struct vm_struct **vms,int nr_vms, +kasan_vmalloc_flags_t flags); +static __always_inline void +kasan_unpoison_vmap_areas (struct vm_struct **vms,int nr_vms, +kasan_vmalloc_flags_t flags) +{ +if (kasan_enabled ()) +__kasan_unpoison_vmap_areas (vms, nr_vms, flags); +} +#else /* CONFIG_KASAN_VMALLOC */ static inline void kasan_populate_early_vm_area_shadow(void *start,
@@ -632,6 +642,11 @@ static inline void *kasan_unpoison_vmallstatic inline void kasan_poison_vmalloc (const void *start,unsigned long size) { } +static __always_inline void +kasan_unpoison_vmap_areas (struct vm_struct **vms,int nr_vms, +kasan_vmalloc_flags_t flags) +{ } +#endif /* CONFIG_KASAN_VMALLOC */ #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
mm/kasan/common.c +17 -0
@@ -28,6 +28,7 @@#include <linux/string.h> #include <linux/types.h> #include <linux/bug.h> +#include <linux/vmalloc.h> #include "kasan.h" #include "../slab.h"
@@ -559,3 +560,19 @@ bool __kasan_check_byte(const void *addr }return true; } + +#ifdef CONFIG_KASAN_VMALLOC +void __kasan_unpoison_vmap_areas (struct vm_struct **vms,int nr_vms, +kasan_vmalloc_flags_t flags) +{ +unsigned long size; +void *addr; +int area; + +for (area =0 ; area < nr_vms ; area++) { + size = vms[area]->size; + addr = vms[area]->addr; + vms[area]->addr =__kasan_unpoison_vmalloc (addr, size, flags); + } +} +#endif
mm/vmalloc.c +1 -3
@@ -4812,9 +4812,7 @@ retry:* With hardware tag-based KASAN, marking is skipped for * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc(). */ -for (area =0 ; area < nr_vms; area++) - vms[area]->addr =kasan_unpoison_vmalloc (vms[area]->addr, - vms[area]->size,KASAN_VMALLOC_PROT_NORMAL ); +kasan_unpoison_vmap_areas (vms, nr_vms,KASAN_VMALLOC_PROT_NORMAL );kfree (vas);return vms;
Greg Kroah-Hartman
maintainerPATCH 438/567 kasan: unpoison vms[area] addresses with a common tag
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej Wieczor-Retman <[email protected]>
commit 6a0e5b333842cf65d6f4e4f0a2a4386504802515 upstream.
A KASAN tag mismatch, possibly causing a kernel panic, can be observed on systems with a tag-based KASAN enabled and with multiple NUMA nodes. It was reported on arm64 and reproduced on x86. It can be explained in the following points:
1. There can be more than one virtual memory chunk.
2. Chunk's base address has a tag.
3. The base address points at the first chunk and thus inherits the tag of the first chunk.
4. The subsequent chunks will be accessed with the tag from the first chunk.
5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk.
Use the new vmalloc flag that disables random tag assignment in __kasan_unpoison_vmalloc() - pass the same random tag to all the vm_structs by tagging the pointers before they go inside __kasan_unpoison_vmalloc(). Assigning a common tag resolves the pcpu chunk address mismatch.
--- mm/kasan/common.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
mm/kasan/common.c +18 -3
@@ -568,11 +568,26 @@ void __kasan_unpoison_vmap_areas(structunsigned long size;void *addr;int area; +u8 tag; -for (area =0 ; area < nr_vms ; area++) { +/* +* If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers +* would be unpoisoned with the KASAN_TAG_KERNEL which would disable +* KASAN checks down the line. +*/ +if (WARN_ON_ONCE (flags &KASAN_VMALLOC_KEEP_TAG )) +return ; + + size = vms[0 ]->size; + addr = vms[0 ]->addr; + vms[0 ]->addr =__kasan_unpoison_vmalloc (addr, size, flags); + tag =get_tag (vms[0 ]->addr); + +for (area =1 ; area < nr_vms ; area++) { size = vms[area]->size; - addr = vms[area]->addr; - vms[area]->addr =__kasan_unpoison_vmalloc (addr, size, flags); + addr =set_tag (vms[area]->addr, tag); + vms[area]->addr = +__kasan_unpoison_vmalloc (addr, size, flags |KASAN_VMALLOC_KEEP_TAG ); } }#endif
Greg Kroah-Hartman
maintainerPATCH 439/567 lockd: fix vfs_test_lock() calls
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit a49a2a1baa0c553c3548a1c414b6a3c005a8deba upstream.
Usage of vfs_test_lock() is somewhat confused. Documentation suggests it is given a "lock" but this is not the case. It is given a struct file_lock which contains some details of the sort of lock it should be looking for.
In particular passing a "file_lock" containing fl_lmops or fl_ops is meaningless and possibly confusing.
This is particularly problematic in lockd. nlmsvc_testlock() receives an initialised "file_lock" from xdr-decode, including manager ops and an owner. It then mistakenly passes this to vfs_test_lock() which might replace the owner and the ops. This can lead to confusion when freeing the lock.
The primary role of the 'struct file_lock' passed to vfs_test_lock() is to report a conflicting lock that was found, so it makes more sense for nlmsvc_testlock() to pass "conflock", which it uses for returning the conflicting lock.
With this change, freeing of the lock is not confused and code in __nlm4svc_proc_test() and __nlmsvc_proc_test() can be simplified.
Documentation for vfs_test_lock() is improved to reflect its real purpose, and a WARN_ON_ONCE() is added to avoid a similar problem in the future.
--- fs/lockd/svc4proc.c | 4 +--- fs/lockd/svclock.c | 21 ++++++++++++--------- fs/lockd/svcproc.c | 5 +---- fs/locks.c | 12 ++++++++++-- 4 files changed, 24 insertions(+), 18 deletions(-)
fs/lockd/svc4proc.c +1 -3
@@ -96,7 +96,6 @@ __nlm4svc_proc_test(struct svc_rqst *rqsstruct nlm_args *argp = rqstp->rq_argp;struct nlm_host *host;struct nlm_file *file; -struct nlm_lockowner *test_owner;__be32 rc = rpc_success;dprintk ("lockd: TEST4 called\n" );
@@ -106,7 +105,6 @@ __nlm4svc_proc_test(struct svc_rqst *rqsif ((resp->status =nlm4svc_retrieve_args (rqstp, argp, &host, &file)))return resp->status == nlm_drop_reply ? rpc_drop_reply :rpc_success; - test_owner = argp->lock.fl.c.flc_owner;/* Now check for conflicting locks */ resp->status =nlmsvc_testlock (rqstp, file, host, &argp->lock, &resp->lock, &resp->cookie);if (resp->status == nlm_drop_reply)
@@ -114,7 +112,7 @@ __nlm4svc_proc_test(struct svc_rqst *rqselse dprintk ("lockd: TEST4 status %d\n" ,ntohl (resp->status)); -nlmsvc_put_lockowner (test_owner); +nlmsvc_release_lockowner (&argp->lock);nlmsvc_release_host (host);nlm_release_file (file);return rc;
fs/lockd/svclock.c +12 -9
@@ -628,7 +628,13 @@ nlmsvc_testlock(struct svc_rqst *rqstp, } mode =lock_to_openmode (&lock->fl); - error =vfs_test_lock (file->f_file[mode], &lock->fl); +locks_init_lock (&conflock->fl); +/* vfs_test_lock only uses start, end, and owner, but tests flc_file */ + conflock->fl.c.flc_file = lock->fl.c.flc_file; + conflock->fl.fl_start = lock->fl.fl_start; + conflock->fl.fl_end = lock->fl.fl_end; + conflock->fl.c.flc_owner = lock->fl.c.flc_owner; + error =vfs_test_lock (file->f_file[mode], &conflock->fl);if (error) {/* We can't currently deal with deferred test requests */ if (error ==FILE_LOCK_DEFERRED )
@@ -638,22 +644,19 @@ nlmsvc_testlock(struct svc_rqst *rqstp, goto out; } -if (lock->fl.c.flc_type ==F_UNLCK ) { +if (conflock->fl.c.flc_type ==F_UNLCK ) { ret = nlm_granted; goto out; }dprintk ("lockd: conflicting lock(ty=%d, %Ld-%Ld)\n" , - lock->fl.c.flc_type, (long long )lock->fl.fl_start, - (long long )lock->fl.fl_end); + conflock->fl.c.flc_type, (long long )conflock->fl.fl_start, + (long long )conflock->fl.fl_end); conflock->caller ="somehost" ;/* FIXME */ conflock->len =strlen (conflock->caller); conflock->oh.len =0 ;/* don't return OH info */ - conflock->svid = lock->fl.c.flc_pid; - conflock->fl.c.flc_type = lock->fl.c.flc_type; - conflock->fl.fl_start = lock->fl.fl_start; - conflock->fl.fl_end = lock->fl.fl_end; -locks_release_private (&lock->fl); + conflock->svid = conflock->fl.c.flc_pid; +locks_release_private (&conflock->fl); ret = nlm_lck_denied; out:
fs/lockd/svcproc.c +1 -4
@@ -117,7 +117,6 @@ __nlmsvc_proc_test(struct svc_rqst *rqststruct nlm_args *argp = rqstp->rq_argp;struct nlm_host *host;struct nlm_file *file; -struct nlm_lockowner *test_owner;__be32 rc = rpc_success;dprintk ("lockd: TEST called\n" );
@@ -127,8 +126,6 @@ __nlmsvc_proc_test(struct svc_rqst *rqstif ((resp->status =nlmsvc_retrieve_args (rqstp, argp, &host, &file)))return resp->status == nlm_drop_reply ? rpc_drop_reply :rpc_success; - test_owner = argp->lock.fl.c.flc_owner; -/* Now check for conflicting locks */ resp->status =cast_status (nlmsvc_testlock (rqstp, file, host, &argp->lock, &resp->lock, &resp->cookie));if (resp->status == nlm_drop_reply)
@@ -137,7 +134,7 @@ __nlmsvc_proc_test(struct svc_rqst *rqstdprintk ("lockd: TEST status %d vers %d\n" ,ntohl (resp->status), rqstp->rq_vers); -nlmsvc_put_lockowner (test_owner); +nlmsvc_release_lockowner (&argp->lock);nlmsvc_release_host (host);nlm_release_file (file);return rc;
fs/locks.c +10 -2
@@ -2190,13 +2190,21 @@ SYSCALL_DEFINE2(flock, unsigned int, fd,/** * vfs_test_lock - test file byte range lock * @filp: The file to test lock for -* @fl: The lock to test; also used to hold result +* @fl: The byte-range in the file to test; also used to hold result * +* On entry, @fl does not contain a lock, but identifies a range (fl_start, fl_end) +* in the file (c.flc_file), and an owner (c.flc_owner) for whom existing locks +* should be ignored. c.flc_type and c.flc_flags are ignored. +* Both fl_lmops and fl_ops in @fl must be NULL. * Returns -ERRNO on failure. Indicates presence of conflicting lock by -* setting conf->fl_type to something other than F_UNLCK. +* setting fl->fl_type to something other than F_UNLCK. +* +* If vfs_test_lock() does find a lock and return it, the caller must +* use locks_free_lock() or locks_release_private() on the returned lock. */ int vfs_test_lock (struct file *filp,struct file_lock *fl) { +WARN_ON_ONCE (fl->fl_ops || fl->fl_lmops);WARN_ON_ONCE (filp != fl->c.flc_file);if (filp->f_op->lock)return filp->f_op->lock (filp,F_GETLK , fl);
Greg Kroah-Hartman
maintainerPATCH 440/567 idr: fix idr_alloc() returning an ID out of range
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Wilcox (Oracle) <[email protected]>
commit c6e8e595a0798ad67da0f7bebaf69c31ef70dfff upstream.
If you use an IDR with a non-zero base, and specify a range that lies entirely below the base, 'max - base' becomes very large and idr_get_free() can return an ID that lies outside of the requested range.
--- lib/idr.c | 2 ++ tools/testing/radix-tree/idr-test.c | 21 +++++++++++++++++++++ 2 files changed, 23 insertions(+)
lib/idr.c +2 -0
@@ -40,6 +40,8 @@ int idr_alloc_u32(struct idr *idr, voidif (WARN_ON_ONCE (!(idr->idr_rt.xa_flags &ROOT_IS_IDR ))) idr->idr_rt.xa_flags |=IDR_RT_MARKER ; +if (max < base) +return -ENOSPC ; id = (id < base) ?0 : id - base;radix_tree_iter_init (&iter, id);
tools/testing/radix-tree/idr-test.c +21 -0
@@ -57,6 +57,26 @@ void idr_alloc_test(void)idr_destroy (&idr); } +void idr_alloc2_test (void ) +{ +int id; +struct idr idr =IDR_INIT_BASE (idr,1 ); + + id =idr_alloc (&idr, idr_alloc2_test,0 ,1 ,GFP_KERNEL ); +assert (id == -ENOSPC ); + + id =idr_alloc (&idr, idr_alloc2_test,1 ,2 ,GFP_KERNEL ); +assert (id ==1 ); + + id =idr_alloc (&idr, idr_alloc2_test,0 ,1 ,GFP_KERNEL ); +assert (id == -ENOSPC ); + + id =idr_alloc (&idr, idr_alloc2_test,0 ,2 ,GFP_KERNEL ); +assert (id == -ENOSPC ); + +idr_destroy (&idr); +} +void idr_replace_test (void ) {DEFINE_IDR (idr);
@@ -409,6 +429,7 @@ void idr_checks(void)idr_replace_test ();idr_alloc_test (); +idr_alloc2_test ();idr_null_test ();idr_nowait_test ();idr_get_next_test (0 );
Greg Kroah-Hartman
maintainerPATCH 441/567 mm/page_owner: fix memory leak in page_owner_stack_fops->release()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ran Xiaokai <[email protected]>
commit a76a5ae2c6c645005672c2caf2d49361c6f2500f upstream.
The page_owner_stack_fops->open() callback invokes seq_open_private(), therefore its corresponding ->release() callback must call seq_release_private(). Otherwise it will cause a memory leak of struct stack_print_ctx.
--- mm/page_owner.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/page_owner.c +1 -1
@@ -933,7 +933,7 @@ static const struct file_operations page .open = page_owner_stack_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release, + .release = seq_release_private, };static int page_owner_threshold_get (void *data,u64 *val)
Greg Kroah-Hartman
maintainerPATCH 442/567 x86/microcode/AMD: Fix Entrysign revision check for Zen5/Strix Halo
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rong Zhang <[email protected]>
commit 150b1b97e27513535dcd3795d5ecd28e61b6cb8c upstream.
Zen5 also contains family 1Ah, models 70h-7Fh, which are mistakenly missing from cpu_has_entrysign(). Add the missing range.
--- arch/x86/kernel/cpu/microcode/amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/microcode/amd.c +1 -1
@@ -235,7 +235,7 @@ static bool cpu_has_entrysign(void)if (fam ==0x1a ) {if (model <=0x2f || (0x40 <= model && model <=0x4f ) || - (0x60 <= model && model <=0x6f )) + (0x60 <= model && model <=0x7f ))return true; }
Greg Kroah-Hartman
maintainerPATCH 443/567 tools/mm/page_owner_sort: fix timestamp comparison for stable sorting
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kaushlendra Kumar <[email protected]>
commit 7013803444dd3bbbe28fd3360c084cec3057c554 upstream.
The ternary operator in compare_ts() returns 1 when timestamps are equal, causing unstable sorting behavior. Replace with explicit three-way comparison that returns 0 for equal timestamps, ensuring stable qsort ordering and consistent output.
--- tools/mm/page_owner_sort.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
tools/mm/page_owner_sort.c +5 -1
@@ -183,7 +183,11 @@ static int compare_ts(const void *p1, co {const struct block_list *l1 = p1, *l2 = p2; -return l1->ts_nsec < l2->ts_nsec ?-1 :1 ; +if (l1->ts_nsec < l2->ts_nsec) +return -1 ; +if (l1->ts_nsec > l2->ts_nsec) +return 1 ; +return 0 ; }static int compare_cull_condition (const void *p1,const void *p2)
Greg Kroah-Hartman
maintainerPATCH 444/567 samples/ftrace: Adjust LoongArch register restore order in direct calls
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chenghao Duan <[email protected]>
commit bb85d206be208bbf834883e948125a35ac59993a upstream.
Ensure that in the ftrace direct call logic, the CPU register state (with ra = parent return address) is restored to the correct state after the execution of the custom trampoline function and before returning to the traced function. Additionally, guarantee the correctness of the jump logic for jr t0 (traced function address).
--- samples/ftrace/ftrace-direct-modify.c | 8 ++++---- samples/ftrace/ftrace-direct-multi-modify.c | 8 ++++---- samples/ftrace/ftrace-direct-multi.c | 4 ++-- samples/ftrace/ftrace-direct-too.c | 4 ++-- samples/ftrace/ftrace-direct.c | 4 ++-- 5 files changed, 14 insertions(+), 14 deletions(-)
samples/ftrace/ftrace-direct-modify.c +4 -4
@@ -176,8 +176,8 @@ asm (" st.d $t0, $sp, 0\n" " st.d $ra, $sp, 8\n" " bl my_direct_func1\n" -" ld.d $t0, $sp, 0\n" -" ld.d $ra, $sp, 8\n" +" ld.d $ra, $sp, 0\n" +" ld.d $t0, $sp, 8\n" " addi.d $sp, $sp, 16\n" " jr $t0\n" " .size my_tramp1, .-my_tramp1\n"
@@ -189,8 +189,8 @@ asm (" st.d $t0, $sp, 0\n" " st.d $ra, $sp, 8\n" " bl my_direct_func2\n" -" ld.d $t0, $sp, 0\n" -" ld.d $ra, $sp, 8\n" +" ld.d $ra, $sp, 0\n" +" ld.d $t0, $sp, 8\n" " addi.d $sp, $sp, 16\n" " jr $t0\n" " .size my_tramp2, .-my_tramp2\n"
samples/ftrace/ftrace-direct-multi-modify.c +4 -4
@@ -199,8 +199,8 @@ asm (" move $a0, $t0\n" " bl my_direct_func1\n" " ld.d $a0, $sp, 0\n" -" ld.d $t0, $sp, 8\n" -" ld.d $ra, $sp, 16\n" +" ld.d $ra, $sp, 8\n" +" ld.d $t0, $sp, 16\n" " addi.d $sp, $sp, 32\n" " jr $t0\n" " .size my_tramp1, .-my_tramp1\n"
@@ -215,8 +215,8 @@ asm (" move $a0, $t0\n" " bl my_direct_func2\n" " ld.d $a0, $sp, 0\n" -" ld.d $t0, $sp, 8\n" -" ld.d $ra, $sp, 16\n" +" ld.d $ra, $sp, 8\n" +" ld.d $t0, $sp, 16\n" " addi.d $sp, $sp, 32\n" " jr $t0\n" " .size my_tramp2, .-my_tramp2\n"
samples/ftrace/ftrace-direct-multi.c +2 -2
@@ -131,8 +131,8 @@ asm (" move $a0, $t0\n" " bl my_direct_func\n" " ld.d $a0, $sp, 0\n" -" ld.d $t0, $sp, 8\n" -" ld.d $ra, $sp, 16\n" +" ld.d $ra, $sp, 8\n" +" ld.d $t0, $sp, 16\n" " addi.d $sp, $sp, 32\n" " jr $t0\n" " .size my_tramp, .-my_tramp\n"
samples/ftrace/ftrace-direct-too.c +2 -2
@@ -143,8 +143,8 @@ asm (" ld.d $a0, $sp, 0\n" " ld.d $a1, $sp, 8\n" " ld.d $a2, $sp, 16\n" -" ld.d $t0, $sp, 24\n" -" ld.d $ra, $sp, 32\n" +" ld.d $ra, $sp, 24\n" +" ld.d $t0, $sp, 32\n" " addi.d $sp, $sp, 48\n" " jr $t0\n" " .size my_tramp, .-my_tramp\n"
samples/ftrace/ftrace-direct.c +2 -2
@@ -124,8 +124,8 @@ asm (" st.d $ra, $sp, 16\n" " bl my_direct_func\n" " ld.d $a0, $sp, 0\n" -" ld.d $t0, $sp, 8\n" -" ld.d $ra, $sp, 16\n" +" ld.d $ra, $sp, 8\n" +" ld.d $t0, $sp, 16\n" " addi.d $sp, $sp, 32\n" " jr $t0\n" " .size my_tramp, .-my_tramp\n"
Greg Kroah-Hartman
maintainerPATCH 445/567 RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gunthorpe <[email protected]>
commit a7b8e876e0ef0232b8076972c57ce9a7286b47ca upstream.
The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a LS_NLA_TYPE_DGID attribute, it is invalid if it does not.
Use the nl parsing logic properly and call nla_parse_deprecated() to fill the nlattrs array and then directly index that array to get the data for the DGID. Just fail if it is NULL.
Remove the for loop searching for the nla, and squash the validation and parsing into one function.
Fixes an uninitialized read from the stack triggered by userspace if it does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE query.
BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]
BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
hex_byte_pack include/linux/hex.h:13 [inline]
ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509
ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633
pointer+0xc09/0x1bd0 lib/vsprintf.c:2542
vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930
vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279
vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426
vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465
vprintk+0x36/0x50 kernel/printk/printk_safe.c:82
_printk+0x17e/0x1b0 kernel/printk/printk.c:2475
ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]
ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141
rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]
rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:714 [inline]
__sock_sendmsg+0x333/0x3d0 net/socket.c:729
____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617
___sys_sendmsg+0x271/0x3b0 net/socket.c:2671
__sys_sendmsg+0x1aa/0x300 net/socket.c:2703
__compat_sys_sendmsg net/compat.c:346 [inline]
__do_compat_sys_sendmsg net/compat.c:353 [inline]
__se_compat_sys_sendmsg net/compat.c:350 [inline]
__ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350
ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371
do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
__do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306
do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3--- drivers/infiniband/core/addr.c | 33 ++++++++++----------------------- 1 file changed, 10 insertions(+), 23 deletions(-)
drivers/infiniband/core/addr.c +10 -23
@@ -80,37 +80,25 @@ static const struct nla_policy ib_nl_add .min = sizeof(struct rdma_nla_ls_gid)}, }; -static inline bool ib_nl_is_good_ip_resp (const struct nlmsghdr *nlh) +static void ib_nl_process_ip_rsep (const struct nlmsghdr *nlh) {struct nlattr *tb[LS_NLA_TYPE_MAX ] = {}; +union ib_gid gid; +struct addr_req *req; +int found =0 ;int ret;if (nlh->nlmsg_flags &RDMA_NL_LS_F_ERR ) -return false; +return ; ret =nla_parse_deprecated (tb,LS_NLA_TYPE_MAX -1 ,nlmsg_data (nlh),nlmsg_len (nlh), ib_nl_addr_policy,NULL );if (ret) -return false; - -return true; -} - -static void ib_nl_process_good_ip_rsep (const struct nlmsghdr *nlh) -{ -const struct nlattr *head, *curr; -union ib_gid gid; -struct addr_req *req; -int len, rem; -int found =0 ; - - head = (const struct nlattr *)nlmsg_data (nlh); - len =nlmsg_len (nlh); +return ; -nla_for_each_attr (curr, head, len, rem) { -if (curr->nla_type ==LS_NLA_TYPE_DGID ) -memcpy (&gid,nla_data (curr),nla_len (curr)); - } +if (!tb[LS_NLA_TYPE_DGID ]) +return ; +memcpy (&gid,nla_data (tb[LS_NLA_TYPE_DGID ]),sizeof (gid));spin_lock_bh (&lock);list_for_each_entry (req, &req_list, list) {
@@ -137,8 +125,7 @@ int ib_nl_handle_ip_res_resp(struct sk_b !(NETLINK_CB(skb).sk))return -EPERM ; -if (ib_nl_is_good_ip_resp (nlh)) -ib_nl_process_good_ip_rsep (nlh); +ib_nl_process_ip_rsep (nlh);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 446/567 RDMA/cm: Fix leaking the multicast GID table reference
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gunthorpe <[email protected]>
commit 57f3cb6c84159d12ba343574df2115fb18dd83ca upstream.
If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573
WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ah_attr after canceling the work, it is safe to call this twice.
--- drivers/infiniband/core/cma.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/infiniband/core/cma.c +3 -0
@@ -2009,6 +2009,7 @@ static void destroy_mc(struct rdma_id_prib_sa_free_multicast (mc->sa_mc);if (rdma_protocol_roce (id_priv->id.device, id_priv->id.port_num)) { +struct rdma_cm_event *event = &mc->iboe_join.event;struct rdma_dev_addr *dev_addr = &id_priv->id.route.addr.dev_addr;struct net_device *ndev =NULL ;
@@ -2031,6 +2032,8 @@ static void destroy_mc(struct rdma_id_prdev_put (ndev);cancel_work_sync (&mc->iboe_join.work); +if (event->event ==RDMA_CM_EVENT_MULTICAST_JOIN ) +rdma_destroy_ah_attr (&event->param.ud.ah_attr); }kfree (mc); }
Greg Kroah-Hartman
maintainerPATCH 447/567 e1000: fix OOB in e1000_tbi_should_accept()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
commit 9c72a5182ed92904d01057f208c390a303f00a0f upstream.
In e1000_tbi_should_accept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq):
==================================================================
BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363 CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 </IRQ> <TASK> __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected ==================================================================
This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:
u8 last_byte = *(data + length - 1);
Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rx_buffer_len. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.
--- drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/e1000/e1000_main.c +9 -1
@@ -4088,7 +4088,15 @@ static bool e1000_tbi_should_accept(stru u32 length, const u8 *data) { struct e1000_hw *hw = &adapter->hw; -u8 last_byte = *(data + length -1 ); +u8 last_byte; + +/* Guard against OOB on data[length - 1] */ +if (unlikely (!length)) +return false; +/* Upper bound: length must not exceed rx_buffer_len */ +if (unlikely (length > adapter->rx_buffer_len)) +return false; + last_byte = *(data + length -1 );if (TBI_ACCEPT (hw, status, errors, length, last_byte)) {unsigned long irq_flags;