6.2.8-rc1 review
Greg Kroah-Hartman
maintainerPATCH 159/211 Revert "riscv: mm: notify remote harts about mmu cache updates"
In reply to Greg Kroah-HartmanFrom: Sergey Matyukevich <[email protected]>
commit e921050022f1f12d5029d1487a7dfc46cde15523 upstream.
This reverts the remaining bits of commit 4bd1d80efb5a ("riscv: mm:
notify remote harts harts about mmu cache updates").
According to bug reports, suggested approach to fix stale TLB entries is not sufficient. It needs to be replaced by a more robust solution.
--- arch/riscv/include/asm/mmu.h | 2 -- arch/riscv/include/asm/tlbflush.h | 18 ------------------ arch/riscv/mm/context.c | 10 ---------- arch/riscv/mm/tlbflush.c | 28 +++++++++++++++++----------- 4 files changed, 17 insertions(+), 41 deletions(-)
arch/riscv/include/asm/mmu.h +0 -2
@@ -19,8 +19,6 @@ typedef struct {#ifdef CONFIG_SMP /* A local icache flush is needed before user execution can resume. */ cpumask_t icache_stale_mask; -/* A local tlb flush is needed before user execution can resume. */ -cpumask_t tlb_stale_mask;#endif } mm_context_t;
arch/riscv/include/asm/tlbflush.h +0 -18
@@ -22,24 +22,6 @@ static inline void local_flush_tlb_page( {ALT_FLUSH_TLB_PAGE (__asm__ __volatile__ ("sfence.vma %0" : :"r" (addr) :"memory" )); } - -static inline void local_flush_tlb_all_asid (unsigned long asid) -{ - __asm__ __volatile__ ("sfence.vma x0, %0" - : - :"r" (asid) - :"memory" ); -} - -static inline void local_flush_tlb_page_asid (unsigned long addr, -unsigned long asid) -{ - __asm__ __volatile__ ("sfence.vma %0, %1" - : - :"r" (addr),"r" (asid) - :"memory" ); -} -#else /* CONFIG_MMU */ #define local_flush_tlb_all () do { } while (0)#define local_flush_tlb_page (addr) do { } while (0)
arch/riscv/mm/context.c +0 -10
@@ -196,16 +196,6 @@ switch_mm_fast:if (need_flush_tlb)local_flush_tlb_all (); -#ifdef CONFIG_SMP - else { -cpumask_t *mask = &mm->context.tlb_stale_mask; - -if (cpumask_test_cpu (cpu, mask)) { -cpumask_clear_cpu (cpu, mask); -local_flush_tlb_all_asid (cntx & asid_mask); - } - } -#endif }static void set_mm_noasid (struct mm_struct *mm)
arch/riscv/mm/tlbflush.c +17 -11
@@ -5,7 +5,23 @@#include <linux/sched.h> #include <asm/sbi.h> #include <asm/mmu_context.h> -#include <asm/tlbflush.h> + +static inline void local_flush_tlb_all_asid (unsigned long asid) +{ + __asm__ __volatile__ ("sfence.vma x0, %0" + : + :"r" (asid) + :"memory" ); +} + +static inline void local_flush_tlb_page_asid (unsigned long addr, +unsigned long asid) +{ + __asm__ __volatile__ ("sfence.vma %0, %1" + : + :"r" (addr),"r" (asid) + :"memory" ); +}void flush_tlb_all (void ) {
@@ -15,7 +31,6 @@ void flush_tlb_all(void)static void __sbi_tlb_flush_range (struct mm_struct *mm,unsigned long start,unsigned long size,unsigned long stride) { -struct cpumask *pmask = &mm->context.tlb_stale_mask;struct cpumask *cmask =mm_cpumask (mm);unsigned int cpuid;bool broadcast;
@@ -29,15 +44,6 @@ static void __sbi_tlb_flush_range(structif (static_branch_unlikely (&use_asid_allocator)) {unsigned long asid =atomic_long_read (&mm->context.id); -/* -* TLB will be immediately flushed on harts concurrently -* executing this MM context. TLB flush on other harts -* is deferred until this MM context migrates there. -*/ -cpumask_setall (pmask); -cpumask_clear_cpu (cpuid, pmask); -cpumask_andnot (pmask, pmask, cmask); -if (broadcast) {sbi_remote_sfence_vma_asid (cmask, start, size, asid); }else if (size <= stride) {
Greg Kroah-Hartman
maintainerPATCH 160/211 riscv: asid: Fixup stale TLB entry cause application crash
In reply to Greg Kroah-HartmanFrom: Guo Ren <[email protected]>
commit 82dd33fde0268cc622d3d1ac64971f3f61634142 upstream.
After use_asid_allocator is enabled, the userspace application will crash by stale TLB entries. Because only using cpumask_clear_cpu without local_flush_tlb_all couldn't guarantee CPU's TLB entries were fresh. Then set_mm_asid would cause the user space application to get a stale value by stale TLB entry, but set_mm_noasid is okay.
Here is the symptom of the bug:
unhandled signal 11 code 0x1 (coredump)
0x0000003fd6d22524 <+4>: auipc s0,0x70 0x0000003fd6d22528 <+8>: ld s0,-148(s0) # 0x3fd6d92490 => 0x0000003fd6d2252c <+12>: ld a5,0(s0)
(gdb) i r s0
s0 0x8082ed1cc3198b21 0x8082ed1cc3198b21
(gdb) x /2x 0x3fd6d924900x3fd6d92490: 0xd80ac8a8 0x0000003f
The core dump file shows that register s0 is wrong, but the value in memory is correct. Because 'ld s0, -148(s0)' used a stale mapping entry in TLB and got a wrong result from an incorrect physical address.
When the task ran on CPU0, which loaded/speculative-loaded the value of address(0x3fd6d92490), then the first version of the mapping entry was PTWed into CPU0's TLB.
When the task switched from CPU0 to CPU1 (No local_tlb_flush_all here by asid), it happened to write a value on the address (0x3fd6d92490). It caused do_page_fault -> wp_page_copy -> ptep_clear_flush -> ptep_get_and_clear & flush_tlb_page.
The flush_tlb_page used mm_cpumask(mm) to determine which CPUs need TLB flush, but CPU0 had cleared the CPU0's mm_cpumask in the previous switch_mm. So we only flushed the CPU1 TLB and set the second version mapping of the PTE. When the task switched from CPU1 to CPU0 again, CPU0 still used a stale TLB mapping entry which contained a wrong target physical address. It raised a bug when the task happened to read that value.
CPU0 CPU1
- switch 'task' in
- read addr (Fill stale mapping
entry into TLB)
- switch 'task' out (no tlb_flush)
- switch 'task' in (no tlb_flush)
- write addr cause pagefault do_page_fault() (change to new addr mapping) wp_page_copy() ptep_clear_flush() ptep_get_and_clear() & flush_tlb_page() write new value into addr
- switch 'task' out (no tlb_flush)
- switch 'task' in (no tlb_flush)
- read addr again (Use stale
mapping entry in TLB)
get wrong value from old phyical
addr, BUG!
The solution is to keep all CPUs' footmarks of cpumask(mm) in switch_mm, which could guarantee to invalidate all stale TLB entries during TLB flush.
--- arch/riscv/mm/context.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-)
arch/riscv/mm/context.c +20 -10
@@ -205,12 +205,24 @@ static void set_mm_noasid(struct mm_strulocal_flush_tlb_all (); } -static inline void set_mm (struct mm_struct *mm,unsigned int cpu) +static inline void set_mm (struct mm_struct *prev, +struct mm_struct *next,unsigned int cpu) { -if (static_branch_unlikely (&use_asid_allocator)) -set_mm_asid (mm, cpu); -else -set_mm_noasid (mm); +/* +* The mm_cpumask indicates which harts' TLBs contain the virtual +* address mapping of the mm. Compared to noasid, using asid +* can't guarantee that stale TLB entries are invalidated because +* the asid mechanism wouldn't flush TLB for every switch_mm for +* performance. So when using asid, keep all CPUs footmarks in +* cpumask() until mm reset. +*/ +cpumask_set_cpu (cpu,mm_cpumask (next)); +if (static_branch_unlikely (&use_asid_allocator)) { +set_mm_asid (next, cpu); + }else { +cpumask_clear_cpu (cpu,mm_cpumask (prev)); +set_mm_noasid (next); + } }static int __init asids_init (void )
@@ -264,7 +276,8 @@ static int __init asids_init(void) }early_initcall (asids_init);#else -static inline void set_mm (struct mm_struct *mm,unsigned int cpu) +static inline void set_mm (struct mm_struct *prev, +struct mm_struct *next,unsigned int cpu) {/* Nothing to do here when there is no MMU */ }
@@ -317,10 +330,7 @@ void switch_mm(struct mm_struct *prev, s*/ cpu =smp_processor_id (); -cpumask_clear_cpu (cpu,mm_cpumask (prev)); -cpumask_set_cpu (cpu,mm_cpumask (next)); - -set_mm (next, cpu); +set_mm (prev, next, cpu);flush_icache_deferred (next, cpu); }
Greg Kroah-Hartman
maintainerPATCH 161/211 drm/edid: fix info leak when failing to get panel id
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 4d8457fe0eb9c80ff7795cf8a30962128b71d853 upstream.
Make sure to clear the transfer buffer before fetching the EDID to avoid leaking slab data to the logs on errors that leave the buffer unchanged.
--- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/drm_edid.c +1 -1
@@ -2797,7 +2797,7 @@ u32 drm_edid_get_panel_id(struct i2c_adapter *adapter)* the EDID then we'll just return 0. */ - base_block =kmalloc (EDID_LENGTH ,GFP_KERNEL ); + base_block =kzalloc (EDID_LENGTH ,GFP_KERNEL );if (!base_block)return 0 ;
Signature · 1 line
2.40.0
Greg Kroah-Hartman
maintainerPATCH 162/211 drm/shmem-helper: Remove another errant put in error path
In reply to Greg Kroah-HartmanFrom: Dmitry Osipenko <[email protected]>
commit ee9adb7a45516cfa536ca92253d7ae59d56db9e4 upstream.
drm_gem_shmem_mmap() doesn't own reference in error code path, resulting in the dma-buf shmem GEM object getting prematurely freed leading to a later use-after-free.
--- drivers/gpu/drm/drm_gem_shmem_helper.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/gpu/drm/drm_gem_shmem_helper.c +6 -3
@@ -622,11 +622,14 @@ int drm_gem_shmem_mmap(struct drm_gem_shint ret;if (obj->import_attach) { -/* Drop the reference drm_gem_mmap_obj() acquired.*/ -drm_gem_object_put (obj); vma->vm_private_data =NULL ; + ret =dma_buf_mmap (obj->dma_buf, vma,0 ); + +/* Drop the reference drm_gem_mmap_obj() acquired.*/ +if (!ret) +drm_gem_object_put (obj); -return dma_buf_mmap (obj->dma_buf, vma,0 ); +return ret; } ret =drm_gem_shmem_get_pages (shmem);
Greg Kroah-Hartman
maintainerPATCH 163/211 drm/sun4i: fix missing component unbind on bind errors
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit c22f2ff8724b49dce2ae797e9fbf4bc0fa91112f upstream.
Make sure to unbind all subcomponents when binding the aggregate device fails.
--- drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/sun4i/sun4i_drv.c +4 -2
@@ -95,12 +95,12 @@ static int sun4i_drv_bind(struct device/* drm_vblank_init calls kcalloc, which can fail */ ret =drm_vblank_init (drm, drm->mode_config.num_crtc);if (ret) - goto cleanup_mode_config; + goto unbind_all;/* Remove early framebuffers (ie. simplefb) */ ret =drm_aperture_remove_framebuffers (false, &sun4i_drv_driver);if (ret) - goto cleanup_mode_config; + goto unbind_all;sun4i_framebuffer_init (drm);
@@ -119,6 +119,8 @@ static int sun4i_drv_bind(struct device finish_poll:drm_kms_helper_poll_fini (drm); +unbind_all: +component_unbind_all (dev,NULL ); cleanup_mode_config:drm_mode_config_cleanup (drm);of_reserved_mem_device_release (dev);
Greg Kroah-Hartman
maintainerPATCH 164/211 drm/i915/active: Fix misuse of non-idle barriers as fence trackers
In reply to Greg Kroah-HartmanFrom: Janusz Krzysztofik <[email protected]>
commit e0e6b416b25ee14716f3549e0cbec1011b193809 upstream.
Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin.
When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier.
If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur.
Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty.
Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
Schedule request retirement when timeline idles"), introduced in v5.5.
Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one.
v3: use unlikely() to document what outcome we expect (Andi),
- fix bad grammar in commit description.
v2: no code changes,
- blame commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4,
- reword commit description.
--- drivers/gpu/drm/i915/i915_active.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-)
drivers/gpu/drm/i915/i915_active.c +15 -12
@@ -422,12 +422,12 @@ replace_barrier(struct i915_active *ref,* we can use it to substitute for the pending idle-barrer * request that we want to emit on the kernel_context. */ -__active_del_barrier (ref,node_from_active (active)); -return true; +return __active_del_barrier (ref,node_from_active (active)); }int i915_active_add_request (struct i915_active *ref,struct i915_request *rq) { +u64 idx =i915_request_timeline (rq)->fence_context;struct dma_fence *fence = &rq->fence;struct i915_active_fence *active;int err;
@@ -437,16 +437,19 @@ int i915_active_add_request(struct i915_if (err)return err; - active =active_instance (ref,i915_request_timeline (rq)->fence_context); -if (!active) { - err = -ENOMEM ; - goto out; - } - -if (replace_barrier (ref, active)) { -RCU_INIT_POINTER (active->fence,NULL ); -atomic_dec (&ref->count); - } +do { + active =active_instance (ref, idx); +if (!active) { + err = -ENOMEM ; + goto out; + } + +if (replace_barrier (ref, active)) { +RCU_INIT_POINTER (active->fence,NULL ); +atomic_dec (&ref->count); + } + }while (unlikely (is_barrier (active))); +if (!__i915_active_fence_set (active, fence))__i915_active_acquire (ref);
Greg Kroah-Hartman
maintainerPATCH 165/211 drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz
In reply to Greg Kroah-HartmanFrom: Ankit Nautiyal <[email protected]>
commit 46bc23dcd94569270d02c4c1f7e62ae01ebd53bb upstream.
Add snps phy table values for HDMI pixel clocks 267.30 MHz and 319.89 MHz. Values are based on the Bspec algorithm for PLL programming for HDMI.
--- drivers/gpu/drm/i915/display/intel_snps_phy.c | 62 ++++++++++++++++++++++++++ 1 file changed, 62 insertions(+)
drivers/gpu/drm/i915/display/intel_snps_phy.c +62 -0
@@ -1419,6 +1419,36 @@ static const struct intel_mpllb_state dg REG_FIELD_PREP(SNPS_PHY_MPLLB_SSC_UP_SPREAD, 1), }; +static const struct intel_mpllb_state dg2_hdmi_267300 = { + .clock =267300 , + .ref_control = +REG_FIELD_PREP (SNPS_PHY_REF_CONTROL_REF_RANGE ,3 ), + .mpllb_cp = +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_INT ,7 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_PROP ,14 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_INT_GS ,64 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_PROP_GS ,124 ), + .mpllb_div = +REG_FIELD_PREP (SNPS_PHY_MPLLB_DIV5_CLK_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_TX_CLK_DIV ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_PMIX_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_V2I ,2 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FREQ_VCO ,3 ), + .mpllb_div2 = +REG_FIELD_PREP (SNPS_PHY_MPLLB_REF_CLK_DIV ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_MULTIPLIER ,74 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_HDMI_DIV ,1 ), + .mpllb_fracn1 = +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_DEN ,65535 ), + .mpllb_fracn2 = +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_QUOT ,30146 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_REM ,36699 ), + .mpllb_sscen = +REG_FIELD_PREP (SNPS_PHY_MPLLB_SSC_UP_SPREAD ,1 ), +}; +static const struct intel_mpllb_state dg2_hdmi_268500 = { .clock =268500 , .ref_control =
@@ -1509,6 +1539,36 @@ static const struct intel_mpllb_state dg REG_FIELD_PREP(SNPS_PHY_MPLLB_SSC_UP_SPREAD, 1), }; +static const struct intel_mpllb_state dg2_hdmi_319890 = { + .clock =319890 , + .ref_control = +REG_FIELD_PREP (SNPS_PHY_REF_CONTROL_REF_RANGE ,3 ), + .mpllb_cp = +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_INT ,6 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_PROP ,14 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_INT_GS ,64 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_CP_PROP_GS ,124 ), + .mpllb_div = +REG_FIELD_PREP (SNPS_PHY_MPLLB_DIV5_CLK_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_TX_CLK_DIV ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_PMIX_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_V2I ,2 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FREQ_VCO ,2 ), + .mpllb_div2 = +REG_FIELD_PREP (SNPS_PHY_MPLLB_REF_CLK_DIV ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_MULTIPLIER ,94 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_HDMI_DIV ,1 ), + .mpllb_fracn1 = +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_EN ,1 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_DEN ,65535 ), + .mpllb_fracn2 = +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_QUOT ,64094 ) | +REG_FIELD_PREP (SNPS_PHY_MPLLB_FRACN_REM ,13631 ), + .mpllb_sscen = +REG_FIELD_PREP (SNPS_PHY_MPLLB_SSC_UP_SPREAD ,1 ), +}; +static const struct intel_mpllb_state dg2_hdmi_497750 = { .clock =497750 , .ref_control =
@@ -1696,8 +1756,10 @@ static const struct intel_mpllb_state * &dg2_hdmi_209800, &dg2_hdmi_241500, &dg2_hdmi_262750, + &dg2_hdmi_267300, &dg2_hdmi_268500, &dg2_hdmi_296703, + &dg2_hdmi_319890, &dg2_hdmi_497750, &dg2_hdmi_592000, &dg2_hdmi_593407,
Greg Kroah-Hartman
maintainerPATCH 166/211 drm/amdgpu: Dont resume IOMMU after incomplete init
In reply to Greg Kroah-HartmanFrom: Felix Kuehling <[email protected]>
commit f3921a9a641483784448fb982b2eb738b383d9b9 upstream.
Check kfd->init_complete in kgd2kfd_iommu_resume, consistent with other kgd2kfd calls. This should fix IOMMU errors on resume from suspend when KFD IOMMU initialization failed.
--- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdkfd/kfd_device.c +10 -1
@@ -59,6 +59,7 @@ static int kfd_gtt_sa_init(struct kfd_de unsigned int chunk_size);static void kfd_gtt_sa_fini (struct kfd_dev *kfd); +static int kfd_resume_iommu (struct kfd_dev *kfd);static int kfd_resume (struct kfd_dev *kfd);static void kfd_device_info_set_sdma_info (struct kfd_dev *kfd)
@@ -635,7 +636,7 @@ bool kgd2kfd_device_init(struct kfd_devsvm_migrate_init (kfd->adev); -if (kgd2kfd_resume_iommu (kfd)) +if (kfd_resume_iommu (kfd)) goto device_iommu_error;if (kfd_resume (kfd))
@@ -784,6 +785,14 @@ int kgd2kfd_resume(struct kfd_dev *kfd,int kgd2kfd_resume_iommu (struct kfd_dev *kfd) { +if (!kfd->init_complete) +return 0 ; + +return kfd_resume_iommu (kfd); +} + +static int kfd_resume_iommu (struct kfd_dev *kfd) +{int err =0 ; err =kfd_iommu_resume (kfd);
Greg Kroah-Hartman
maintainerPATCH 167/211 drm/amd/pm: Fix sienna cichlid incorrect OD volage after resume
In reply to Greg Kroah-HartmanFrom: Błażej Szczygieł <[email protected]>
commit a9386ee9681585794dbab95d4ce6826f73d19af6 upstream.
Always setup overdrive tables after resume. Preserve only some user-defined settings in user_overdrive_table if they're set.
Copy restored user_overdrive_table into od_table to get correct values.
On cold boot, BTC was triggered and GfxVfCurve was calibrated. We got VfCurve settings (a). On resuming back, BTC will be triggered again and GfxVfCurve will be recalibrated. VfCurve settings (b) got may be different from those of cold boot. So if we reuse those VfCurve settings (a) got on cold boot on suspend, we can run into discrepencies.
--- drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 43 ++++++++++++---- 1 file changed, 33 insertions(+), 10 deletions(-)
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +33 -10
@@ -2143,16 +2143,9 @@ static int sienna_cichlid_set_default_od (OverDriveTable_t *)smu->smu_table.boot_overdrive_table;OverDriveTable_t *user_od_table = (OverDriveTable_t *)smu->smu_table.user_overdrive_table; +OverDriveTable_t user_od_table_bak;int ret =0 ; -/* -* For S3/S4/Runpm resume, no need to setup those overdrive tables again as -* - either they already have the default OD settings got during cold bootup -* - or they have some user customized OD settings which cannot be overwritten -*/ -if (smu->adev->in_suspend) -return 0 ; - ret =smu_cmn_update_table (smu,SMU_TABLE_OVERDRIVE ,0 , (void *)boot_od_table, false);if (ret) {
@@ -2163,7 +2156,23 @@ static int sienna_cichlid_set_default_odsienna_cichlid_dump_od_table (smu, boot_od_table);memcpy (od_table, boot_od_table,sizeof (OverDriveTable_t)); -memcpy (user_od_table, boot_od_table,sizeof (OverDriveTable_t)); + +/* +* For S3/S4/Runpm resume, we need to setup those overdrive tables again, +* but we have to preserve user defined values in "user_od_table". +*/ +if (!smu->adev->in_suspend) { +memcpy (user_od_table, boot_od_table,sizeof (OverDriveTable_t)); + smu->user_dpm_profile.user_od = false; + }else if (smu->user_dpm_profile.user_od) { +memcpy (&user_od_table_bak, user_od_table,sizeof (OverDriveTable_t)); +memcpy (user_od_table, boot_od_table,sizeof (OverDriveTable_t)); + user_od_table->GfxclkFmin = user_od_table_bak.GfxclkFmin; + user_od_table->GfxclkFmax = user_od_table_bak.GfxclkFmax; + user_od_table->UclkFmin = user_od_table_bak.UclkFmin; + user_od_table->UclkFmax = user_od_table_bak.UclkFmax; + user_od_table->VddGfxOffset = user_od_table_bak.VddGfxOffset; + }return 0 ; }
@@ -2373,6 +2382,20 @@ static int sienna_cichlid_od_edit_dpm_tareturn ret; } +static int sienna_cichlid_restore_user_od_settings (struct smu_context *smu) +{ +struct smu_table_context *table_context = &smu->smu_table; +OverDriveTable_t *od_table = table_context->overdrive_table; +OverDriveTable_t *user_od_table = table_context->user_overdrive_table; +int res; + + res =smu_v11_0_restore_user_od_settings (smu); +if (res ==0 ) +memcpy (od_table, user_od_table,sizeof (OverDriveTable_t)); + +return res; +} +static int sienna_cichlid_run_btc (struct smu_context *smu) {int res;
@@ -4400,7 +4423,7 @@ static const struct pptable_funcs sienna .set_soft_freq_limited_range = smu_v11_0_set_soft_freq_limited_range, .set_default_od_settings = sienna_cichlid_set_default_od_settings, .od_edit_dpm_table = sienna_cichlid_od_edit_dpm_table, - .restore_user_od_settings = smu_v11_0_restore_user_od_settings, + .restore_user_od_settings = sienna_cichlid_restore_user_od_settings, .run_btc = sienna_cichlid_run_btc, .set_power_source = smu_v11_0_set_power_source, .get_pp_feature_mask = smu_cmn_get_pp_feature_mask,
Greg Kroah-Hartman
maintainerPATCH 168/211 drm/amdgpu/vcn: Disable indirect SRAM on Vangogh broken BIOSes
In reply to Greg Kroah-HartmanFrom: Guilherme G. Piccoli <[email protected]>
commit 542a56e8eb4467ae654eefab31ff194569db39cd upstream.
The VCN firmware loading path enables the indirect SRAM mode if it's advertised as supported. We might have some cases of FW issues that prevents this mode to working properly though, ending-up in a failed probe. An example below, observed in the Steam Deck:
[...]
[drm] failed to load ucode VCN0_RAM(0x3A)
[drm] psp gfx command LOAD_IP_FW(0x6) failed and response status is (0xFFFF0000) amdgpu 0000:04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vcn_dec_0 test failed (-110) [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* hw_init of IP block <vcn_v3_0> failed -110 amdgpu 0000:04:00.0: amdgpu: amdgpu_device_ip_init failed
amdgpu 0000:04:00.0: amdgpu: Fatal error during GPU init
[...]
Disabling the VCN block circumvents this, but it's a very invasive workaround that turns off the entire feature. So, let's add a quirk on VCN loading that checks for known problematic BIOSes on Vangogh, so we can proactively disable the indirect SRAM mode and allow the HW proper probe and VCN IP block to work fine.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c +19 -0
@@ -26,6 +26,7 @@#include <linux/firmware.h> #include <linux/module.h> +#include <linux/dmi.h> #include <linux/pci.h> #include <linux/debugfs.h> #include <drm/drm_drv.h>
@@ -222,6 +223,24 @@ int amdgpu_vcn_sw_init(struct amdgpu_devreturn r; } +/* +* Some Steam Deck's BIOS versions are incompatible with the +* indirect SRAM mode, leading to amdgpu being unable to get +* properly probed (and even potentially crashing the kernel). +* Hence, check for these versions here - notice this is +* restricted to Vangogh (Deck's APU). +*/ +if (adev->ip_versions[UVD_HWIP ][0 ] ==IP_VERSION (3 ,0 ,2 )) { +const char *bios_ver =dmi_get_system_info (DMI_BIOS_VERSION ); + +if (bios_ver && (!strncmp ("F7A0113" , bios_ver,7 ) || + !strncmp ("F7A0114" , bios_ver,7 ))) { + adev->vcn.indirect_sram = false; +dev_info (adev->dev, +"Steam Deck quirk: indirect SRAM disabled on BIOS %s\n" , bios_ver); + } + } + hdr = (const struct common_firmware_header *)adev->vcn.fw->data; adev->vcn.fw_version =le32_to_cpu (hdr->ucode_version);
Greg Kroah-Hartman
maintainerPATCH 169/211 drm/amd/pm: bump SMU 13.0.4 driver_if header version
In reply to Greg Kroah-HartmanFrom: Tim Huang <[email protected]>
commit ab9bdb1213b4b40942af6a383f555d0c14874c1b upstream.
Align the SMU driver interface version with PMFW to suppress the version mismatch message on driver loading.
--- drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h | 4 ++-- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h +2 -2
@@ -27,7 +27,7 @@// *** IMPORTANT *** // SMU TEAM: Always increment the interface version if // any structure is changed in this file -#define PMFW_DRIVER_IF_VERSION 7 +#define PMFW_DRIVER_IF_VERSION 8 typedef struct { int32_t value;
@@ -198,7 +198,7 @@ typedef struct {uint16_t SkinTemp;uint16_t DeviceState;uint16_t CurTemp;//[centi-Celsius] -uint16_t spare2; +uint16_t FilterAlphaValue;uint16_t AverageGfxclkFrequency;uint16_t AverageFclkFrequency;
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h +1 -1
@@ -29,7 +29,7 @@#define SMU13_DRIVER_IF_VERSION_YELLOW_CARP 0x04#define SMU13_DRIVER_IF_VERSION_ALDE 0x08#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_0_0 0x37 -#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_4 0x07 +#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_4 0x08#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_5 0x04#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_0_10 0x32#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_7 0x37
Greg Kroah-Hartman
maintainerPATCH 170/211 drm/amd/display: Do not set DRR on pipe Commit
In reply to Greg Kroah-HartmanFrom: Wesley Chalmers <[email protected]>
commit 56574f89dbd84004c3fd6485bcaafb5aa9b8be14 upstream.
[WHY]
Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a pipe commit can cause underflow.
--- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 3 --- 1 file changed, 3 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c +0 -3
@@ -992,8 +992,5 @@ void dcn30_prepare_bandwidth(struct dc * dc->clk_mgr->funcs->set_max_memclk (dc->clk_mgr, dc->clk_mgr->bw_params->clk_table.entries[dc->clk_mgr->bw_params->clk_table.num_entries -1 ].memclk_mhz);dcn20_prepare_bandwidth (dc, context); - -dc_dmub_srv_p_state_delegate (dc, - context->bw_ctx.bw.dcn.clk.fw_based_mclk_switching, context); }
Greg Kroah-Hartman
maintainerPATCH 171/211 drm/amd/display: disconnect MPCC only on OTG change
In reply to Greg Kroah-HartmanFrom: Ayush Gupta <[email protected]>
commit 7304ee979b6b6422f41a1312391a5e505fc29ccd upstream.
[Why]
Framedrops are observed while playing Vp9 and Av1 10 bit video on 8k resolution using VSR while playback controls are disappeared/appeared
[How]
Now ODM 2 to 1 is disabled for 5k or greater resolutions on VSR.
--- drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c +5 -1
@@ -1915,6 +1915,7 @@ int dcn32_populate_dml_pipes_from_contexbool subvp_in_use = false;uint8_t is_pipe_split_expected[MAX_PIPES ] = {0 };struct dc_crtc_timing *timing; +bool vsr_odm_support = false;dcn20_populate_dml_pipes_from_context (dc, context, pipes, fast_validate);
@@ -1932,12 +1933,15 @@ int dcn32_populate_dml_pipes_from_contex timing = &pipe->stream->timing; pipes[pipe_cnt].pipe.dest.odm_combine_policy = dm_odm_combine_policy_dal; + vsr_odm_support = (res_ctx->pipe_ctx[i].stream->src.width >=5120 && + res_ctx->pipe_ctx[i].stream->src.width > res_ctx->pipe_ctx[i].stream->dst.width);if (context->stream_count ==1 && context->stream_status[0 ].plane_count ==1 && !dc_is_hdmi_signal (res_ctx->pipe_ctx[i].stream->signal) &&is_h_timing_divisible_by_2 (res_ctx->pipe_ctx[i].stream) && pipe->stream->timing.pix_clk_100hz *100 >DCN3_2_VMIN_DISPCLK_HZ && - dc->debug.enable_single_display_2to1_odm_policy) { + dc->debug.enable_single_display_2to1_odm_policy && + !vsr_odm_support) {//excluding 2to1 ODM combine on >= 5k vsr pipes[pipe_cnt].pipe.dest.odm_combine_policy = dm_odm_combine_policy_2to1; } pipe_cnt++;
Greg Kroah-Hartman
maintainerPATCH 172/211 drm/amd/display: Write to correct dirty_rect
In reply to Greg Kroah-HartmanFrom: Benjamin Cheng <[email protected]>
commit 751281c55579f0cb0e56c9797d4663f689909681 upstream.
When FB_DAMAGE_CLIPS are provided in a non-MPO scenario, the loop does not use the counter i. This causes the fill_dc_dity_rect() to always fill dirty_rects[0], causing graphical artifacts when a damage clip aware DRM client sends more than 1 damage clip.
Instead, use the flip_addrs->dirty_rect_count which is incremented by fill_dc_dirty_rect() on a successful fill.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +3 -3
@@ -4985,9 +4985,9 @@ static void fill_dc_dirty_rects(struct dfor (; flip_addrs->dirty_rect_count < num_clips; clips++)fill_dc_dirty_rect (new_plane_state->plane, - &dirty_rects[i], clips->x1, - clips->y1, clips->x2 - clips->x1, - clips->y2 - clips->y1, + &dirty_rects[flip_addrs->dirty_rect_count], + clips->x1, clips->y1, + clips->x2 - clips->x1, clips->y2 - clips->y1, &flip_addrs->dirty_rect_count, false);return ;
Greg Kroah-Hartman
maintainerPATCH 173/211 mptcp: fix possible deadlock in subflow_error_report
In reply to Greg Kroah-HartmanFrom: Paolo Abeni <[email protected]>
commit b7a679ba7c652587b85294f4953f33ac0b756d40 upstream.
Christoph reported a possible deadlock while the TCP stack destroys an unaccepted subflow due to an incoming reset: the MPTCP socket error path tries to acquire the msk-level socket lock while TCP still owns the listener socket accept queue spinlock, and the reverse dependency already exists in the TCP stack.
Note that the above is actually a lockdep false positive, as the chain involves two separate sockets. A different per-socket lockdep key will address the issue, but such a change will be quite invasive.
Instead, we can simply stop earlier the socket error handling for orphaned or unaccepted subflows, breaking the critical lockdep chain. Error handling in such a scenario is a no-op.
--- net/mptcp/subflow.c | 7 +++++++ 1 file changed, 7 insertions(+)
net/mptcp/subflow.c +7 -0
@@ -1431,6 +1431,13 @@ static void subflow_error_report(struct {struct sock *sk =mptcp_subflow_ctx (ssk)->conn; +/* bail early if this is a no-op, so that we avoid introducing a +* problematic lockdep dependency between TCP accept queue lock +* and msk socket spinlock +*/ +if (!sk->sk_socket) +return ; +mptcp_data_lock (sk);if (!sock_owned_by_user (sk))__mptcp_error_report (sk);
Greg Kroah-Hartman
maintainerPATCH 174/211 mptcp: refactor passive socket initialization
In reply to Greg Kroah-HartmanFrom: Paolo Abeni <[email protected]>
commit 3a236aef280ed5122b2d47087eb514d0921ae033 upstream.
After commit 30e51b923e43 ("mptcp: fix unreleased socket in accept queue") unaccepted msk sockets go throu complete shutdown, we don't need anymore to delay inserting the first subflow into the subflow lists.
The reference counting deserve some extra care, as __mptcp_close() is unaware of the request socket linkage to the first subflow.
Please note that this is more a refactoring than a fix but because this modification is needed to include other corrections, see the following commits. Then a Fixes tag has been added here to help the stable team.
--- net/mptcp/protocol.c | 17 ----------------- net/mptcp/subflow.c | 27 +++++++++++++++++++++------ 2 files changed, 21 insertions(+), 23 deletions(-)
net/mptcp/protocol.c +0 -17
@@ -825,7 +825,6 @@ static bool __mptcp_finish_join(struct mif (sk->sk_socket && !ssk->sk_socket)mptcp_sock_graft (ssk, sk->sk_socket); -mptcp_propagate_sndbuf ((struct sock *)msk, ssk);mptcp_sockopt_sync_locked (msk, ssk);return true; }
@@ -3699,22 +3698,6 @@ static int mptcp_stream_accept(struct solock_sock (newsk); -/* PM/worker can now acquire the first subflow socket -* lock without racing with listener queue cleanup, -* we can notify it, if needed. -* -* Even if remote has reset the initial subflow by now -* the refcnt is still at least one. -*/ - subflow =mptcp_subflow_ctx (msk->first); -list_add (&subflow->node, &msk->conn_list); -sock_hold (msk->first); -if (mptcp_is_fully_established (newsk)) -mptcp_pm_fully_established (msk, msk->first,GFP_KERNEL ); - -mptcp_rcv_space_init (msk, msk->first); -mptcp_propagate_sndbuf (newsk, msk->first); -/* set ssk->sk_socket of accept()ed flows to mptcp socket. * This is needed so NOSPACE flag can be set from tcp stack. */
net/mptcp/subflow.c +21 -6
@@ -396,6 +396,12 @@ void mptcp_subflow_reset(struct sock *ssstruct mptcp_subflow_context *subflow =mptcp_subflow_ctx (ssk);struct sock *sk = subflow->conn; +/* mptcp_mp_fail_no_response() can reach here on an already closed +* socket +*/ +if (ssk->sk_state ==TCP_CLOSE ) +return ; +/* must hold: tcp_done() could drop last reference on parent */ sock_hold (sk);
@@ -749,6 +755,7 @@ static struct sock *subflow_syn_recv_socstruct mptcp_options_received mp_opt;bool fallback, fallback_is_fatal;struct sock *new_msk =NULL ; +struct mptcp_sock *owner;struct sock *child;pr_debug ("listener=%p, req=%p, conn=%p" , listener, req, listener->conn);
@@ -823,6 +830,8 @@ create_child: ctx->setsockopt_seq = listener->setsockopt_seq;if (ctx->mp_capable) { + owner =mptcp_sk (new_msk); +/* this can't race with mptcp_close(), as the msk is * not yet exposted to user-space */
@@ -831,14 +840,14 @@ create_child:/* record the newly created socket as the first msk * subflow, but don't link it yet into conn_list */ -WRITE_ONCE (mptcp_sk (new_msk)->first, child); +WRITE_ONCE (owner->first, child);/* new mpc subflow takes ownership of the newly * created mptcp socket */ mptcp_sk (new_msk)->setsockopt_seq = ctx->setsockopt_seq; -mptcp_pm_new_connection (mptcp_sk (new_msk), child,1 ); -mptcp_token_accept (subflow_req,mptcp_sk (new_msk)); +mptcp_pm_new_connection (owner, child,1 ); +mptcp_token_accept (subflow_req, owner); ctx->conn = new_msk; new_msk =NULL ;
@@ -846,15 +855,21 @@ create_child:* uses the correct data */ mptcp_copy_inaddrs (ctx->conn, child); +mptcp_propagate_sndbuf (ctx->conn, child); + +mptcp_rcv_space_init (owner, child); +list_add (&ctx->node, &owner->conn_list); +sock_hold (child);/* with OoO packets we can reach here without ingress * mpc option */ -if (mp_opt.suboptions &OPTION_MPTCP_MPC_ACK ) +if (mp_opt.suboptions &OPTION_MPTCP_MPC_ACK ) {mptcp_subflow_fully_established (ctx, &mp_opt); +mptcp_pm_fully_established (owner, child,GFP_ATOMIC ); + ctx->pm_notified =1 ; + } }else if (ctx->mp_join) { -struct mptcp_sock *owner; - owner = subflow_req->msk;if (!owner) {subflow_add_reset_reason (skb,MPTCP_RST_EPROHIBIT );
Greg Kroah-Hartman
maintainerPATCH 175/211 mptcp: use the workqueue to destroy unaccepted sockets
In reply to Greg Kroah-HartmanFrom: Paolo Abeni <[email protected]>
commit b6985b9b82954caa53f862d6059d06c0526254f0 upstream.
Christoph reported a UaF at token lookup time after having refactored the passive socket initialization part:
BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc
We need to properly clean-up all the paired MPTCP-level resources and be sure to release the msk last, even when the unaccepted subflow is destroyed by the TCP internals via inet_child_forget().
We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra, explicitly checking that for the critical scenario: the closed subflow is the MPC one, the msk is not accepted and eventually going through full cleanup.
With such change, __mptcp_destroy_sock() is always called on msk sockets, even on accepted ones. We don't need anymore to transiently drop one sk reference at msk clone time.
Please note this commit depends on the parent one:
mptcp: refactor passive socket initialization
--- net/mptcp/protocol.c | 40 ++++++++++++++++++++++++++++++---------- net/mptcp/protocol.h | 5 ++++- net/mptcp/subflow.c | 17 ++++++++++++----- 3 files changed, 46 insertions(+), 16 deletions(-)
net/mptcp/protocol.c +30 -10
@@ -2343,7 +2343,6 @@ static void __mptcp_close_ssk(struct soc goto out; } -sock_orphan (ssk); subflow->disposable =1 ;/* if ssk hit tcp_done(), tcp_cleanup_ulp() cleared the related ops
@@ -2351,7 +2350,20 @@ static void __mptcp_close_ssk(struct soc* reference owned by msk; */ if (!inet_csk (ssk)->icsk_ulp_ops) { +WARN_ON_ONCE (!sock_flag (ssk,SOCK_DEAD ));kfree_rcu (subflow, rcu); + }else if (msk->in_accept_queue && msk->first == ssk) { +/* if the first subflow moved to a close state, e.g. due to +* incoming reset and we reach here before inet_child_forget() +* the TCP stack could later try to close it via +* inet_csk_listen_stop(), or deliver it to the user space via +* accept(). +* We can't delete the subflow - or risk a double free - nor let +* the msk survive - or will be leaked in the non accept scenario: +* fallback and let TCP cope with the subflow cleanup. +*/ +WARN_ON_ONCE (sock_flag (ssk,SOCK_DEAD )); +mptcp_subflow_drop_ctx (ssk); }else {/* otherwise tcp will dispose of the ssk and subflow ctx */ if (ssk->sk_state ==TCP_LISTEN ) {
@@ -2399,9 +2411,10 @@ static unsigned int mptcp_sync_mss(strucreturn 0 ; } -static void __mptcp_close_subflow (struct mptcp_sock *msk) +static void __mptcp_close_subflow (struct sock *sk) {struct mptcp_subflow_context *subflow, *tmp; +struct mptcp_sock *msk =mptcp_sk (sk);might_sleep ();
@@ -2415,7 +2428,15 @@ static void __mptcp_close_subflow(structif (!skb_queue_empty_lockless (&ssk->sk_receive_queue))continue ; -mptcp_close_ssk ((struct sock *)msk, ssk, subflow); +mptcp_close_ssk (sk, ssk, subflow); + } + +/* if the MPC subflow has been closed before the msk is accepted, +* msk will never be accept-ed, close it now +*/ +if (!msk->first && msk->in_accept_queue) { +sock_set_flag (sk,SOCK_DEAD ); +inet_sk_state_store (sk,TCP_CLOSE ); } }
@@ -2624,6 +2645,9 @@ static void mptcp_worker(struct work_str__mptcp_check_send_data_fin (sk);mptcp_check_data_fin (sk); +if (test_and_clear_bit (MPTCP_WORK_CLOSE_SUBFLOW , &msk->flags)) +__mptcp_close_subflow (sk); +/* There is no point in keeping around an orphaned sk timedout or * closed, but we need the msk around to reply to incoming DATA_FIN, * even if it is orphaned and in FIN_WAIT2 state
@@ -2639,9 +2663,6 @@ static void mptcp_worker(struct work_str } } -if (test_and_clear_bit (MPTCP_WORK_CLOSE_SUBFLOW , &msk->flags)) -__mptcp_close_subflow (msk); -if (test_and_clear_bit (MPTCP_WORK_RTX , &msk->flags))__mptcp_retrans (sk);
@@ -3072,6 +3093,7 @@ struct sock *mptcp_sk_clone(const struct msk->local_key = subflow_req->local_key; msk->token = subflow_req->token; msk->subflow =NULL ; + msk->in_accept_queue =1 ;WRITE_ONCE (msk->fully_established, false);if (mp_opt->suboptions &OPTION_MPTCP_CSUMREQD )WRITE_ONCE (msk->csum_enabled, true);
@@ -3089,8 +3111,7 @@ struct sock *mptcp_sk_clone(const structsecurity_inet_csk_clone (nsk, req);bh_unlock_sock (nsk); -/* keep a single reference */ -__sock_put (nsk); +/* note: the newly allocated socket refcount is 2 now */ return nsk; }
@@ -3146,8 +3167,6 @@ static struct sock *mptcp_accept(struct goto out; } -/* acquire the 2nd reference for the owning socket */ -sock_hold (new_mptcp_sock); newsk = new_mptcp_sock;MPTCP_INC_STATS (sock_net (sk),MPTCP_MIB_MPCAPABLEPASSIVEACK ); }else {
@@ -3695,6 +3714,7 @@ static int mptcp_stream_accept(struct sostruct sock *newsk = newsock->sk;set_bit (SOCK_CUSTOM_SOCKOPT , &newsock->flags); + msk->in_accept_queue =0 ;lock_sock (newsk);
net/mptcp/protocol.h +4 -1
@@ -295,7 +295,8 @@ struct mptcp_sock { u8 recvmsg_inq:1, cork:1, nodelay:1, - fastopening:1; + fastopening:1, + in_accept_queue:1;int connect_flags;struct work_struct work;struct sk_buff *ooo_last_skb;
@@ -666,6 +667,8 @@ void mptcp_subflow_set_active(struct mptbool mptcp_subflow_active (struct mptcp_subflow_context *subflow); +void mptcp_subflow_drop_ctx (struct sock *ssk); +static inline void mptcp_subflow_tcp_fallback (struct sock *sk,struct mptcp_subflow_context *ctx) {
net/mptcp/subflow.c +12 -5
@@ -698,9 +698,10 @@ static bool subflow_hmac_valid(const strstatic void mptcp_force_close (struct sock *sk) { -/* the msk is not yet exposed to user-space */ +/* the msk is not yet exposed to user-space, and refcount is 2 */ inet_sk_state_store (sk,TCP_CLOSE );sk_common_release (sk); +sock_put (sk); } static void subflow_ulp_fallback(struct sock *sk,
@@ -716,7 +717,7 @@ static void subflow_ulp_fallback(structmptcp_subflow_ops_undo_override (sk); } -static void subflow_drop_ctx (struct sock *ssk) +void mptcp_subflow_drop_ctx (struct sock *ssk) {struct mptcp_subflow_context *ctx =mptcp_subflow_ctx (ssk);
@@ -822,7 +823,7 @@ create_child:if (new_msk)mptcp_copy_inaddrs (new_msk, child); -subflow_drop_ctx (child); +mptcp_subflow_drop_ctx (child); goto out; }
@@ -913,7 +914,7 @@ out:return child; dispose_child: -subflow_drop_ctx (child); +mptcp_subflow_drop_ctx (child);tcp_rsk (req)->drop_req = true;inet_csk_prepare_for_destroy_sock (child);tcp_done (child);
@@ -1863,7 +1864,6 @@ void mptcp_subflow_queue_clean(struct sostruct sock *sk = (struct sock *)msk;bool do_cancel_work; -sock_hold (sk);lock_sock_nested (sk,SINGLE_DEPTH_NESTING ); next = msk->dl_next; msk->first =NULL ;
@@ -1951,6 +1951,13 @@ static void subflow_ulp_release(struct s* when the subflow is still unaccepted */ release = ctx->disposable ||list_empty (&ctx->node); + +/* inet_child_forget() does not call sk_state_change(), +* explicitly trigger the socket close machinery +*/ +if (!release && !test_and_set_bit (MPTCP_WORK_CLOSE_SUBFLOW , + &mptcp_sk (sk)->flags)) +mptcp_schedule_work (sk);sock_put (sk); }
Greg Kroah-Hartman
maintainerPATCH 176/211 mptcp: fix UaF in listener shutdown
In reply to Greg Kroah-HartmanFrom: Paolo Abeni <[email protected]>
commit 0a3f4f1f9c27215e4ddcd312558342e57b93e518 upstream.
As reported by Christoph after having refactored the passive socket initialization, the mptcp listener shutdown path is prone to an UaF issue.
BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0 Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266 CPU: 1 PID: 1266 Comm: syz-executor731 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 kasan_check_range+0x14a/0x1a0 _raw_spin_lock_bh+0x73/0xe0 subflow_error_report+0x6d/0x110 sk_error_report+0x3b/0x190 tcp_disconnect+0x138c/0x1aa0 inet_child_forget+0x6f/0x2e0 inet_csk_listen_stop+0x209/0x1060 __mptcp_close_ssk+0x52d/0x610 mptcp_destroy_common+0x165/0x640 mptcp_destroy+0x13/0x80 __mptcp_destroy_sock+0xe7/0x270 __mptcp_close+0x70e/0x9b0 mptcp_close+0x2b/0x150 inet_release+0xe9/0x1f0 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc
The msk grace period can legitly expire in between the last reference count dropped in mptcp_subflow_queue_clean() and the later eventual access in inet_csk_listen_stop()
After the previous patch we don't need anymore special-casing msk listener socket cleanup: the mptcp worker will process each of the unaccepted msk sockets.
Just drop the now unnecessary code.
Please note this commit depends on the two parent ones:
mptcp: refactor passive socket initialization
mptcp: use the workqueue to destroy unaccepted sockets
--- net/mptcp/protocol.c | 7 +--- net/mptcp/protocol.h | 1 net/mptcp/subflow.c | 72 --------------------------------------------------- 3 files changed, 2 insertions(+), 78 deletions(-)
net/mptcp/protocol.c +2 -5
@@ -2366,12 +2366,9 @@ static void __mptcp_close_ssk(struct socmptcp_subflow_drop_ctx (ssk); }else {/* otherwise tcp will dispose of the ssk and subflow ctx */ -if (ssk->sk_state ==TCP_LISTEN ) { -tcp_set_state (ssk,TCP_CLOSE ); -mptcp_subflow_queue_clean (sk, ssk); -inet_csk_listen_stop (ssk); +if (ssk->sk_state ==TCP_LISTEN )mptcp_event_pm_listener (ssk,MPTCP_EVENT_LISTENER_CLOSED ); - } +__tcp_close (ssk,0 );/* close acquired an extra ref */
net/mptcp/protocol.h +0 -1
@@ -629,7 +629,6 @@ void mptcp_close_ssk(struct sock *sk, st struct mptcp_subflow_context *subflow);void __mptcp_subflow_send_ack (struct sock *ssk);void mptcp_subflow_reset (struct sock *ssk); -void mptcp_subflow_queue_clean (struct sock *sk,struct sock *ssk);void mptcp_sock_graft (struct sock *sk,struct socket *parent);struct socket *__mptcp_nmpc_socket (const struct mptcp_sock *msk);bool __mptcp_close (struct sock *sk,long timeout);
net/mptcp/subflow.c +0 -72
78 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 177/211 mptcp: add ro_after_init for tcp{,v6}_prot_override
In reply to Greg Kroah-HartmanFrom: Geliang Tang <[email protected]>
commit 822467a48e938e661965d09df5fcac66f7291050 upstream.
Add __ro_after_init labels for the variables tcp_prot_override and tcpv6_prot_override, just like other variables adjacent to them, to indicate that they are initialised from the init hooks and no writes occur afterwards.
--- net/mptcp/subflow.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/mptcp/subflow.c +2 -2
@@ -627,7 +627,7 @@ static struct request_sock_ops mptcp_substatic struct tcp_request_sock_ops subflow_request_sock_ipv6_ops__ro_after_init ;static struct inet_connection_sock_af_ops subflow_v6_specific__ro_after_init ;static struct inet_connection_sock_af_ops subflow_v6m_specific__ro_after_init ; -static struct proto tcpv6_prot_override; +static struct proto tcpv6_prot_override__ro_after_init ;static int subflow_v6_conn_request (struct sock *sk,struct sk_buff *skb) {
@@ -925,7 +925,7 @@ dispose_child: }static struct inet_connection_sock_af_ops subflow_specific__ro_after_init ; -static struct proto tcp_prot_override; +static struct proto tcp_prot_override__ro_after_init ;enum mapping_status {MAPPING_OK ,
Greg Kroah-Hartman
maintainerPATCH 178/211 mptcp: avoid setting TCP_CLOSE state twice
In reply to Greg Kroah-HartmanFrom: Matthieu Baerts <[email protected]>
commit 3ba14528684f528566fb7d956bfbfb958b591d86 upstream.
tcp_set_state() is called from tcp_done() already.
There is then no need to first set the state to TCP_CLOSE, then call tcp_done().
--- net/mptcp/subflow.c | 1 - 1 file changed, 1 deletion(-)
net/mptcp/subflow.c +0 -1
@@ -405,7 +405,6 @@ void mptcp_subflow_reset(struct sock *ss/* must hold: tcp_done() could drop last reference on parent */ sock_hold (sk); -tcp_set_state (ssk,TCP_CLOSE );tcp_send_active_reset (ssk,GFP_ATOMIC );tcp_done (ssk); if (!test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &mptcp_sk(sk)->flags) &&
Greg Kroah-Hartman
maintainerPATCH 179/211 mptcp: fix lockdep false positive in mptcp_pm_nl_create_listen_socket()
In reply to Greg Kroah-HartmanFrom: Paolo Abeni <[email protected]>
commit cee4034a3db1d30c3243dd51506a9d4ab1a849fa upstream.
Christoph reports a lockdep splat in the mptcp_subflow_create_socket() error path, when such function is invoked by mptcp_pm_nl_create_listen_socket().
Such code path acquires two separates, nested socket lock, with the internal lock operation lacking the "nested" annotation. Adding that in sock_release() for mptcp's sake only could be confusing.
Instead just add a new lockclass to the in-kernel msk socket, re-initializing the lockdep infra after the socket creation.
--- net/mptcp/pm_netlink.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
net/mptcp/pm_netlink.c +16 -0
@@ -993,9 +993,13 @@ out:return ret; } +static struct lock_class_key mptcp_slock_keys[2 ]; +static struct lock_class_key mptcp_keys[2 ]; +static int mptcp_pm_nl_create_listen_socket (struct sock *sk,struct mptcp_pm_addr_entry *entry) { +bool is_ipv6 = sk->sk_family ==AF_INET6 ;int addrlen =sizeof (struct sockaddr_in );struct sockaddr_storage addr;struct socket *ssock;
@@ -1012,6 +1016,18 @@ static int mptcp_pm_nl_create_listen_socif (!newsk)return -EINVAL ; +/* The subflow socket lock is acquired in a nested to the msk one +* in several places, even by the TCP stack, and this msk is a kernel +* socket: lockdep complains. Instead of propagating the _nested +* modifiers in several places, re-init the lock class for the msk +* socket to an mptcp specific one. +*/ +sock_lock_init_class_and_name (newsk, + is_ipv6 ?"mlock-AF_INET6" :"mlock-AF_INET" , + &mptcp_slock_keys[is_ipv6], + is_ipv6 ?"msk_lock-AF_INET6" :"msk_lock-AF_INET" , + &mptcp_keys[is_ipv6]); +lock_sock (newsk); ssock =__mptcp_nmpc_socket (mptcp_sk (newsk));release_sock (newsk);
Greg Kroah-Hartman
maintainerPATCH 180/211 ftrace: Fix invalid address access in lookup_rec() when index is 0
In reply to Greg Kroah-HartmanFrom: Chen Zhongjin <[email protected]>
commit ee92fa443358f4fc0017c1d0d325c27b37802504 upstream.
KASAN reported follow problem:
BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe
When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start in ftrace_process_locs(). Before the first pg->index++, index is 0 and accessing pg->records[-1].ip will cause this problem.
Don't check the ip when pg->index is 0.
--- kernel/trace/ftrace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/trace/ftrace.c +2 -1
@@ -1537,7 +1537,8 @@ static struct dyn_ftrace *lookup_rec(uns key.flags = end;/* overload flags, as it is unsigned long */ for (pg = ftrace_pages_start; pg; pg = pg->next) { -if (end < pg->records[0 ].ip || +if (pg->index ==0 || + end < pg->records[0 ].ip || start >= (pg->records[pg->index -1 ].ip +MCOUNT_INSN_SIZE ))continue ; rec = bsearch(&key, pg->records, pg->index,
Greg Kroah-Hartman
maintainerPATCH 181/211 ocfs2: fix data corruption after failed write
In reply to Greg Kroah-HartmanFrom: Jan Kara via Ocfs2-devel <[email protected]>
commit 90410bcf873cf05f54a32183afff0161f44f9715 upstream.
When buffered write fails to copy data into underlying page cache page, ocfs2_write_end_nolock() just zeroes out and dirties the page. This can leave dirty page beyond EOF and if page writeback tries to write this page before write succeeds and expands i_size, page gets into inconsistent state where page dirty bit is clear but buffer dirty bits stay set resulting in page data never getting written and so data copied to the page is lost. Fix the problem by invalidating page beyond EOF after failed write.
--- fs/ocfs2/aops.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)
fs/ocfs2/aops.c +17 -2
@@ -1977,11 +1977,26 @@ int ocfs2_write_end_nolock(struct addres }if (unlikely (copied < len) && wc->w_target_page) { +loff_t new_isize; +if (!PageUptodate (wc->w_target_page)) copied =0 ; -ocfs2_zero_new_buffers (wc->w_target_page, start+copied, - start+len); + new_isize =max_t (loff_t,i_size_read (inode), pos + copied); +if (new_isize >page_offset (wc->w_target_page)) +ocfs2_zero_new_buffers (wc->w_target_page, start+copied, + start+len); +else { +/* +* When page is fully beyond new isize (data copy +* failed), do not bother zeroing the page. Invalidate +* it instead so that writeback does not get confused +* put page & buffer dirty bits into inconsistent +* state. +*/ +block_invalidate_folio (page_folio (wc->w_target_page), +0 ,PAGE_SIZE ); + } }if (wc->w_target_page)flush_dcache_page (wc->w_target_page);
Greg Kroah-Hartman
maintainerPATCH 182/211 nvme-pci: add NVME_QUIRK_BOGUS_NID for Netac NV3000
In reply to Greg Kroah-HartmanFrom: Elmer Miroslav Mosher Golovin <[email protected]>
commit 9630d80655bfe7e62e4aff2889dc4eae7ceeb887 upstream.
Added a quirk to fix the Netac NV3000 SSD reporting duplicate NGUIDs.
--- drivers/nvme/host/pci.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/nvme/host/pci.c +2 -0
@@ -3468,6 +3468,8 @@ static const struct pci_device_id nvme_i .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, { PCI_DEVICE(0x2646, 0x501E), /* KINGSTON OM3PGP4xxxxQ OS21011 NVMe SSD */ .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, + { PCI_DEVICE(0x1f40, 0x1202), /* Netac Technologies Co. NV3000 NVMe SSD */ + .driver_data = NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(0x1f40, 0x5236), /* Netac Technologies Co. NV7000 NVMe SSD */ .driver_data = NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(0x1e4B, 0x1001), /* MAXIO MAP1001 */
Greg Kroah-Hartman
maintainerPATCH 183/211 ice: avoid bonding causing auxiliary plug/unplug under RTNL lock
In reply to Greg Kroah-HartmanFrom: Dave Ertman <[email protected]>
commit 248401cb2c4612d83eb0c352ee8103b78b8eb365 upstream.
RDMA is not supported in ice on a PF that has been added to a bonded interface. To enforce this, when an interface enters a bond, we unplug the auxiliary device that supports RDMA functionality. This unplug currently happens in the context of handling the netdev bonding event. This event is sent to the ice driver under RTNL context. This is causing a deadlock where the RDMA driver is waiting for the RTNL lock to complete the removal.
Defer the unplugging/re-plugging of the auxiliary device to the service task so that it is not performed under the RTNL lock context.
--- drivers/net/ethernet/intel/ice/ice.h | 14 +++++--------- drivers/net/ethernet/intel/ice/ice_main.c | 19 ++++++++----------- 2 files changed, 13 insertions(+), 20 deletions(-)
drivers/net/ethernet/intel/ice/ice.h +5 -9
@@ -506,6 +506,7 @@ enum ice_pf_flags {ICE_FLAG_VF_VLAN_PRUNING ,ICE_FLAG_LINK_LENIENT_MODE_ENA ,ICE_FLAG_PLUG_AUX_DEV , +ICE_FLAG_UNPLUG_AUX_DEV ,ICE_FLAG_MTU_CHANGED ,ICE_FLAG_GNSS ,/* GNSS successfully initialized */ ICE_PF_FLAGS_NBITS /* must be last */
@@ -950,16 +951,11 @@ static inline void ice_set_rdma_cap(stru*/ static inline void ice_clear_rdma_cap (struct ice_pf *pf) { -/* We can directly unplug aux device here only if the flag bit -* ICE_FLAG_PLUG_AUX_DEV is not set because ice_unplug_aux_dev() -* could race with ice_plug_aux_dev() called from -* ice_service_task(). In this case we only clear that bit now and -* aux device will be unplugged later once ice_plug_aux_device() -* called from ice_service_task() finishes (see ice_service_task()). +/* defer unplug to service task to avoid RTNL lock and +* clear PLUG bit so that pending plugs don't interfere */ -if (!test_and_clear_bit (ICE_FLAG_PLUG_AUX_DEV , pf->flags)) -ice_unplug_aux_dev (pf); - +clear_bit (ICE_FLAG_PLUG_AUX_DEV , pf->flags); +set_bit (ICE_FLAG_UNPLUG_AUX_DEV , pf->flags);clear_bit (ICE_FLAG_RDMA_ENA , pf->flags); }#endif /* _ICE_H_ */
drivers/net/ethernet/intel/ice/ice_main.c +8 -11
@@ -2316,18 +2316,15 @@ static void ice_service_task(struct work } } -if (test_bit (ICE_FLAG_PLUG_AUX_DEV , pf->flags)) { -/* Plug aux device per request */ -ice_plug_aux_dev (pf); +/* unplug aux dev per request, if an unplug request came in +* while processing a plug request, this will handle it +*/ +if (test_and_clear_bit (ICE_FLAG_UNPLUG_AUX_DEV , pf->flags)) +ice_unplug_aux_dev (pf); -/* Mark plugging as done but check whether unplug was -* requested during ice_plug_aux_dev() call -* (e.g. from ice_clear_rdma_cap()) and if so then -* plug aux device. -*/ -if (!test_and_clear_bit (ICE_FLAG_PLUG_AUX_DEV , pf->flags)) -ice_unplug_aux_dev (pf); - } +/* Plug aux device per request */ +if (test_and_clear_bit (ICE_FLAG_PLUG_AUX_DEV , pf->flags)) +ice_plug_aux_dev (pf);if (test_and_clear_bit (ICE_FLAG_MTU_CHANGED , pf->flags)) {struct iidc_event *event;
Greg Kroah-Hartman
maintainerPATCH 184/211 vp_vdpa: fix the crash in hot unplug with vp_vdpa
In reply to Greg Kroah-HartmanFrom: Cindy Lu <[email protected]>
commit aed8efddd39b3434c96718d39009285c52b1cafc upstream.
While unplugging the vp_vdpa device, it triggers a kernel panic The root cause is: vdpa_mgmtdev_unregister() will accesses modern devices which will cause a use after free.
So need to change the sequence in vp_vdpa_remove
[ 195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014 [ 195.004012] #PF: supervisor read access in kernel mode [ 195.004486] #PF: error_code(0x0000) - not-present page [ 195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0 [ 195.005578] Oops: 0000 1 PREEMPT SMP PTI [ 195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1 [ 195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown [ 195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 195.008059] RIP: 0010:ioread8+0x31/0x80 [ 195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc <8a> 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7 [ 195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292 [ 195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0 [ 195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014 [ 195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68 [ 195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120 [ 195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805 [ 195.013826] FS: 0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000 [ 195.014564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0 [ 195.015741] PKRU: 55555554 [ 195.016001] Call Trace: [ 195.016233] <TASK> [ 195.016434] vp_modern_get_status+0x12/0x20 [ 195.016823] vp_vdpa_reset+0x1b/0x50 [vp_vdpa] [ 195.017238] virtio_vdpa_reset+0x3c/0x48 [virtio_vdpa] [ 195.017709] remove_vq_common+0x1f/0x3a0 [virtio_net] [ 195.018178] virtnet_remove+0x5d/0x70 [virtio_net] [ 195.018618] virtio_dev_remove+0x3d/0x90 [ 195.018986] device_release_driver_internal+0x1aa/0x230 [ 195.019466] bus_remove_device+0xd8/0x150 [ 195.019841] device_del+0x18b/0x3f0 [ 195.020167] ? kernfs_find_ns+0x35/0xd0 [ 195.020526] device_unregister+0x13/0x60 [ 195.020894] unregister_virtio_device+0x11/0x20 [ 195.021311] device_release_driver_internal+0x1aa/0x230 [ 195.021790] bus_remove_device+0xd8/0x150 [ 195.022162] device_del+0x18b/0x3f0 [ 195.022487] device_unregister+0x13/0x60 [ 195.022852] ? vdpa_dev_remove+0x30/0x30 [vdpa] [ 195.023270] vp_vdpa_dev_del+0x12/0x20 [vp_vdpa] [ 195.023694] vdpa_match_remove+0x2b/0x40 [vdpa] [ 195.024115] bus_for_each_dev+0x78/0xc0 [ 195.024471] vdpa_mgmtdev_unregister+0x65/0x80 [vdpa] [ 195.024937] vp_vdpa_remove+0x23/0x40 [vp_vdpa] [ 195.025353] pci_device_remove+0x36/0xa0 [ 195.025719] device_release_driver_internal+0x1aa/0x230 [ 195.026201] pci_stop_bus_device+0x6c/0x90 [ 195.026580] pci_stop_and_remove_bus_device+0xe/0x20 [ 195.027039] disable_slot+0x49/0x90 [ 195.027366] acpiphp_disable_and_eject_slot+0x15/0x90 [ 195.027832] hotplug_event+0xea/0x210 [ 195.028171] ? hotplug_event+0x210/0x210 [ 195.028535] acpiphp_hotplug_notify+0x22/0x80 [ 195.028942] ? hotplug_event+0x210/0x210 [ 195.029303] acpi_device_hotplug+0x8a/0x1d0 [ 195.029690] acpi_hotplug_work_fn+0x1a/0x30 [ 195.030077] process_one_work+0x1e8/0x3c0 [ 195.030451] worker_thread+0x50/0x3b0 [ 195.030791] ? rescuer_thread+0x3a0/0x3a0 [ 195.031165] kthread+0xd9/0x100 [ 195.031459] ? kthread_complete_and_exit+0x20/0x20 [ 195.031899] ret_from_fork+0x22/0x30 [ 195.032233] </TASK>
Message-Id: <[email protected]>
--- drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/vdpa/virtio_pci/vp_vdpa.c +1 -1
@@ -645,8 +645,8 @@ static void vp_vdpa_remove(struct pci_destruct virtio_pci_modern_device *mdev =NULL ; mdev = vp_vdpa_mgtdev->mdev; -vp_modern_remove (mdev);vdpa_mgmtdev_unregister (&vp_vdpa_mgtdev->mgtdev); +vp_modern_remove (mdev);kfree (vp_vdpa_mgtdev->mgtdev.id_table);kfree (mdev);kfree (vp_vdpa_mgtdev);
Greg Kroah-Hartman
maintainerPATCH 185/211 mm/userfaultfd: propagate uffd-wp bit when PTE-mapping the huge zeropage
In reply to Greg Kroah-HartmanFrom: David Hildenbrand <[email protected]>
commit 42b2af2c9b7eede8ef21d0943f84d135e21a32a3 upstream.
Currently, we'd lose the userfaultfd-wp marker when PTE-mapping a huge zeropage, resulting in the next write faults in the PMD range not triggering uffd-wp events.
Various actions (partial MADV_DONTNEED, partial mremap, partial munmap, partial mprotect) could trigger this. However, most importantly, un-protecting a single sub-page from the userfaultfd-wp handler when processing a uffd-wp event will PTE-map the shared huge zeropage and lose the uffd-wp bit for the remainder of the PMD.
Let's properly propagate the uffd-wp bit to the PMDs.
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <inttypes.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <poll.h>
#include <pthread.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <sys/ioctl.h>
#include <linux/userfaultfd.h>
static size_t pagesize;
static int uffd;
static volatile bool uffd_triggered;
#define barrier() __asm__ __volatile__("": : :"memory")
static void uffd_wp_range(char *start, size_t size, bool wp) {
struct uffdio_writeprotect uffd_writeprotect;
uffd_writeprotect.range.start = (unsigned long) start; uffd_writeprotect.range.len = size;
if (wp) {
uffd_writeprotect.mode = UFFDIO_WRITEPROTECT_MODE_WP;
} else {
uffd_writeprotect.mode = 0;
}
if (ioctl(uffd, UFFDIO_WRITEPROTECT, &uffd_writeprotect)) {
fprintf(stderr, "UFFDIO_WRITEPROTECT failed: %d\n", errno); exit(1);
}
}
static void *uffd_thread_fn(void *arg)
{
static struct uffd_msg msg;
ssize_t nread;
while (1) {
struct pollfd pollfd;
int nready;
pollfd.fd = uffd;
pollfd.events = POLLIN;
nready = poll(&pollfd, 1, -1);
if (nready == -1) {
fprintf(stderr, "poll() failed: %d\n", errno); exit(1);
}
nread = read(uffd, &msg, sizeof(msg)); if (nread <= 0)
continue;
if (msg.event != UFFD_EVENT_PAGEFAULT ||
!(msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP)) {
printf("FAIL: wrong uffd-wp event fired\n"); exit(1);
}
/* un-protect the single page. */ uffd_triggered = true;
uffd_wp_range((char *)(uintptr_t)msg.arg.pagefault.address,
pagesize, false);
}
return arg;
}
static int setup_uffd(char *map, size_t size)
{
struct uffdio_api uffdio_api;
struct uffdio_register uffdio_register;
pthread_t thread;
uffd = syscall(__NR_userfaultfd,
O_CLOEXEC | O_NONBLOCK | UFFD_USER_MODE_ONLY);
if (uffd < 0) {
fprintf(stderr, "syscall() failed: %d\n", errno); return -errno;
}
uffdio_api.api = UFFD_API;
uffdio_api.features = UFFD_FEATURE_PAGEFAULT_FLAG_WP; if (ioctl(uffd, UFFDIO_API, &uffdio_api) < 0) {
fprintf(stderr, "UFFDIO_API failed: %d\n", errno); return -errno;
}
if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP)) {
fprintf(stderr, "UFFD_FEATURE_WRITEPROTECT missing\n"); return -ENOSYS;
}
uffdio_register.range.start = (unsigned long) map; uffdio_register.range.len = size; uffdio_register.mode = UFFDIO_REGISTER_MODE_WP;
if (ioctl(uffd, UFFDIO_REGISTER, &uffdio_register) < 0) {
fprintf(stderr, "UFFDIO_REGISTER failed: %d\n", errno); return -errno;
}
pthread_create(&thread, NULL, uffd_thread_fn, NULL);
return 0;
}
int main(void)
{
const size_t size = 4 * 1024 * 1024ull;
char *map, *cur;
pagesize = getpagesize();
map = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0); if (map == MAP_FAILED) {
fprintf(stderr, "mmap() failed\n");
return -errno;
}
if (madvise(map, size, MADV_HUGEPAGE)) {
fprintf(stderr, "MADV_HUGEPAGE failed\n"); return -errno;
}
if (setup_uffd(map, size))
return 1;
/* Read the whole range, populating zeropages. */ madvise(map, size, MADV_POPULATE_READ);
/* Write-protect the whole range. */
uffd_wp_range(map, size, true);
/* Make sure uffd-wp triggers on each page. */ for (cur = map; cur < map + size; cur += pagesize) {
uffd_triggered = false;
barrier();
/* Trigger a write fault. */
*cur = 1;
barrier();
if (!uffd_triggered) {
printf("FAIL: uffd-wp did not trigger\n"); return 1;
}
}
printf("PASS: uffd-wp triggered\n");
return 0;
}
--- mm/huge_memory.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
mm/huge_memory.c +4 -2
@@ -2046,7 +2046,7 @@ static void __split_huge_zero_page_pmd(s {struct mm_struct *mm = vma->vm_mm;pgtable_t pgtable; -pmd_t _pmd; +pmd_t _pmd, old_pmd;int i;/*
@@ -2057,7 +2057,7 @@ static void __split_huge_zero_page_pmd(s* * See Documentation/mm/mmu_notifier.rst */ -pmdp_huge_clear_flush (vma, haddr, pmd); + old_pmd =pmdp_huge_clear_flush (vma, haddr, pmd); pgtable =pgtable_trans_huge_withdraw (mm, pmd);pmd_populate (mm, &_pmd, pgtable);
@@ -2066,6 +2066,8 @@ static void __split_huge_zero_page_pmd(spte_t *pte, entry; entry =pfn_pte (my_zero_pfn (haddr), vma->vm_page_prot); entry =pte_mkspecial (entry); +if (pmd_uffd_wp (old_pmd)) + entry =pte_mkuffd_wp (entry); pte =pte_offset_map (&_pmd, haddr);VM_BUG_ON (!pte_none (*pte));set_pte_at (mm, haddr, pte, entry);
Greg Kroah-Hartman
maintainerPATCH 186/211 mm: teach mincore_hugetlb about pte markers
In reply to Greg Kroah-HartmanFrom: James Houghton <[email protected]>
commit 63cf584203f3367c8b073d417c8e5cbbfc450506 upstream.
By checking huge_pte_none(), we incorrectly classify PTE markers as "present". Instead, check huge_pte_none_mostly(), classifying PTE markers the same as if the PTE were completely blank.
PTE markers, unlike other kinds of swap entries, don't reference any physical page and don't indicate that a physical page was mapped previously. As such, treat them as non-present for the sake of mincore().
--- mm/mincore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/mincore.c +1 -1
@@ -33,7 +33,7 @@ static int mincore_hugetlb(pte_t *pte, u* Hugepages under user process are always in RAM and never * swapped out, but theoretically it needs to be checked. */ - present = pte && !huge_pte_none (huge_ptep_get (pte)); + present = pte && !huge_pte_none_mostly (huge_ptep_get (pte));for (; addr != end; vec++, addr +=PAGE_SIZE ) *vec = present; walk->private = vec;
Greg Kroah-Hartman
maintainerPATCH 187/211 powerpc/64: Set default CPU in Kconfig
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit 45f7091aac3546ef8112bf62836650ca0bbf0b79 upstream.
Since commit 0069f3d14e7a ("powerpc/64e: Tie PPC_BOOK3E_64 to PPC_E500MC"), the only possible BOOK3E/64 are E500, so no need of a default CPU over the E5500.
When the user selects book3e, they must have an e500 compatible compiler, and it won't work anymore with the default -mcpu=power64, see commit d6b551b8f90c ("powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')").
For book3s/64, replace GENERIC_CPU by POWERPC64_CPU to match the PPC32 POWERPC_CPU, and set a default mpcu value in Kconfig directly.
When a user selects a particular CPU, they must ensure the compiler has the requested capability. Therefore, remove hidden fallback, instead offer user the possibility to say they want to use the toolchain default.
--- arch/powerpc/Makefile | 22 +++++----------------- arch/powerpc/platforms/Kconfig.cputype | 12 +++++++----- 2 files changed, 12 insertions(+), 22 deletions(-)
arch/powerpc/Makefile +5 -17
@@ -146,19 +146,6 @@ CFLAGS-$(CONFIG_PPC32) += $(call cc-opti CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata) -ifdef CONFIG_PPC_BOOK3S_64 -ifdef CONFIG_CPU_LITTLE_ENDIAN -CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8 -else -CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power4 -endif -CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power10, \ - $(call cc-option,-mtune=power9, \ - $(call cc-option,-mtune=power8))) -else ifdef CONFIG_PPC_BOOK3E_64 -CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64 -endif - ifdef CONFIG_FUNCTION_TRACER CC_FLAGS_FTRACE := -pg ifdef CONFIG_MPROFILE_KERNEL
@@ -166,11 +153,12 @@ CC_FLAGS_FTRACE += -mprofile-kernel endif endif -CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += $(call cc-option,-mcpu=$(CONFIG_TARGET_CPU)) -AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += $(call cc-option,-mcpu=$(CONFIG_TARGET_CPU)) +CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU) +AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU) -CFLAGS-$(CONFIG_E5500_CPU) += $(call cc-option,-mcpu=e500mc64,-mcpu=powerpc64) -CFLAGS-$(CONFIG_E6500_CPU) += $(call cc-option,-mcpu=e6500,$(E5500_CPU)) +CFLAGS-$(CONFIG_POWERPC64_CPU) += $(call cc-option,-mtune=power10, \ + $(call cc-option,-mtune=power9, \ + $(call cc-option,-mtune=power8))) asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
arch/powerpc/platforms/Kconfig.cputype +7 -5
@@ -118,19 +118,18 @@ endchoice choice prompt "CPU selection" - default GENERIC_CPU help This will create a kernel which is optimised for a particular CPU. The resulting kernel may not run on other CPUs, so use this with care. If unsure, select Generic. -config GENERIC_CPU +config POWERPC64_CPU bool "Generic (POWER5 and PowerPC 970 and above)" depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU -config GENERIC_CPU +config POWERPC64_CPU bool "Generic (POWER8 and above)" depends on PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN select ARCH_HAS_FAST_MULTIPLIER
@@ -233,13 +232,12 @@ config E500MC_CPU config TOOLCHAIN_DEFAULT_CPU bool "Rely on the toolchain's implicit default CPU" - depends on PPC32 endchoice config TARGET_CPU_BOOL bool - default !GENERIC_CPU && !TOOLCHAIN_DEFAULT_CPU + default !TOOLCHAIN_DEFAULT_CPU config TARGET_CPU string
@@ -251,6 +249,10 @@ config TARGET_CPU default "power8" if POWER8_CPU default "power9" if POWER9_CPU default "power10" if POWER10_CPU + default "e500mc64" if E5500_CPU + default "e6500" if E6500_CPU + default "power4" if POWERPC64_CPU && !CPU_LITTLE_ENDIAN + default "power8" if POWERPC64_CPU && CPU_LITTLE_ENDIAN default "405" if 405_CPU default "440" if 440_CPU default "464" if 464_CPU
Greg Kroah-Hartman
maintainerPATCH 188/211 powerpc/boot: Dont always pass -mcpu=powerpc when building 32-bit uImage
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit ff7c76f66d8bad4e694c264c789249e1d3a8205d upstream.
When CONFIG_TARGET_CPU is specified then pass its value to the compiler -mcpu option. This fixes following build error when building kernel with powerpc e500 SPE capable cross compilers:
BOOTAS arch/powerpc/boot/crt0.o
powerpc-linux-gnuspe-gcc: error: unrecognized argument in option ‘-mcpu=powerpc’
powerpc-linux-gnuspe-gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548 native make[1]: *** [arch/powerpc/boot/Makefile:231: arch/powerpc/boot/crt0.o] Error 1
Similar change was already introduced for the main powerpc Makefile in commit 446cda1b21d9 ("powerpc/32: Don't always pass -mcpu=powerpc to the compiler").
--- arch/powerpc/boot/Makefile | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
arch/powerpc/boot/Makefile +10 -4
@@ -39,13 +39,19 @@ BOOTCFLAGS := -Wall -Wundef -Wstrict- $(LINUXINCLUDE) ifdef CONFIG_PPC64_BOOT_WRAPPER -ifdef CONFIG_CPU_LITTLE_ENDIAN -BOOTCFLAGS += -m64 -mcpu=powerpc64le +BOOTCFLAGS += -m64 else -BOOTCFLAGS += -m64 -mcpu=powerpc64 +BOOTCFLAGS += -m32 endif + +ifdef CONFIG_TARGET_CPU_BOOL +BOOTCFLAGS += -mcpu=$(CONFIG_TARGET_CPU) +else ifdef CONFIG_PPC64_BOOT_WRAPPER +ifdef CONFIG_CPU_LITTLE_ENDIAN +BOOTCFLAGS += -mcpu=powerpc64le else -BOOTCFLAGS += -m32 -mcpu=powerpc +BOOTCFLAGS += -mcpu=powerpc64 +endif endif BOOTCFLAGS += -isystem $(shell $(BOOTCC) -print-file-name=include)
Greg Kroah-Hartman
maintainerPATCH 189/211 mmc: sdhci_am654: lower power-on failed message severity
In reply to Greg Kroah-HartmanFrom: Francesco Dolcini <[email protected]>
commit 11440da77d6020831ee6f9ce4551b545dea789ee upstream.
Lower the power-on failed message severity from warn to info when the controller does not power-up. It's normal to have this situation when the SD card slot is empty, therefore we should not warn the user about it.
--- drivers/mmc/host/sdhci_am654.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/sdhci_am654.c +1 -1
@@ -369,7 +369,7 @@ static void sdhci_am654_write_b(struct sMAX_POWER_ON_TIMEOUT , false, host, val, reg);if (ret) -dev_warn (mmc_dev (host->mmc),"Power on failed\n" ); +dev_info (mmc_dev (host->mmc),"Power on failed\n" ); } }
Greg Kroah-Hartman
maintainerPATCH 190/211 fbdev: stifb: Provide valid pixelclock and add fb_check_var() checks
In reply to Greg Kroah-HartmanFrom: Helge Deller <[email protected]>
commit 203873a535d627c668f293be0cb73e26c30f9cc7 upstream.
Find a valid modeline depending on the machine graphic card configuration and add the fb_check_var() function to validate Xorg provided graphics settings.
--- drivers/video/fbdev/stifb.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
drivers/video/fbdev/stifb.c +27 -0
@@ -922,6 +922,28 @@ SETUP_HCRX(struct stifb_info *fb)/* ------------------- driver specific functions --------------------------- */ static int +stifb_check_var (struct fb_var_screeninfo *var,struct fb_info *info) +{ + struct stifb_info *fb = container_of(info, struct stifb_info, info); + +if (var->xres != fb->info.var.xres || + var->yres != fb->info.var.yres || + var->bits_per_pixel != fb->info.var.bits_per_pixel) +return -EINVAL ; + + var->xres_virtual = var->xres; + var->yres_virtual = var->yres; + var->xoffset =0 ; + var->yoffset =0 ; + var->grayscale = fb->info.var.grayscale; + var->red.length = fb->info.var.red.length; + var->green.length = fb->info.var.green.length; + var->blue.length = fb->info.var.blue.length; + +return 0 ; +} + +static int stifb_setcolreg (u_int regno,u_int red,u_int green,u_int blue,u_int transp,struct fb_info *info) {
@@ -1145,6 +1167,7 @@ stifb_init_display(struct stifb_info *fbstatic const struct fb_ops stifb_ops = { .owner =THIS_MODULE , + .fb_check_var = stifb_check_var, .fb_setcolreg = stifb_setcolreg, .fb_blank = stifb_blank, .fb_fillrect = stifb_fillrect,
@@ -1164,6 +1187,7 @@ static int __init stifb_init_fb(struct sstruct stifb_info *fb;struct fb_info *info;unsigned long sti_rom_address; +char modestr[32 ];char *dev_name;int bpp, xres, yres;
@@ -1342,6 +1366,9 @@ static int __init stifb_init_fb(struct s info->flags =FBINFO_HWACCEL_COPYAREA |FBINFO_HWACCEL_FILLRECT ; info->pseudo_palette = &fb->pseudo_palette; +scnprintf (modestr,sizeof (modestr),"%dx%d-%d" , xres, yres, bpp); +fb_find_mode (&info->var, info, modestr,NULL ,0 ,NULL , bpp); +/* This has to be done !!! */ if (fb_alloc_cmap (&info->cmap,NR_PALETTE ,0 )) goto out_err1;
Greg Kroah-Hartman
maintainerPATCH 191/211 trace/hwlat: Do not wipe the contents of per-cpu thread data
In reply to Greg Kroah-HartmanFrom: Tero Kristo <[email protected]>
commit 4c42f5f0d1dd20bddd9f940beb1e6ccad60c4498 upstream.
Do not wipe the contents of the per-cpu kthread data when starting the tracer, as this will completely forget about already running instances and can later start new additional per-cpu threads.
--- kernel/trace/trace_hwlat.c | 3 --- 1 file changed, 3 deletions(-)
kernel/trace/trace_hwlat.c +0 -3
@@ -584,9 +584,6 @@ static int start_per_cpu_kthreads(struct*/ cpumask_and (current_mask, cpu_online_mask, tr->tracing_cpumask); -for_each_online_cpu (cpu) -per_cpu (hwlat_per_cpu_data, cpu).kthread =NULL ; -for_each_cpu (cpu, current_mask) { retval =start_cpu_kthread (cpu);if (retval)
Greg Kroah-Hartman
maintainerPATCH 192/211 trace/hwlat: Do not start per-cpu thread if it is already running
In reply to Greg Kroah-HartmanFrom: Tero Kristo <[email protected]>
commit 08697bca9bbba15f2058fdbd9f970bd5f6a8a2e8 upstream.
The hwlatd tracer will end up starting multiple per-cpu threads with the following script:
#!/bin/sh
cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo hwlat > current_tracer
echo per-cpu > hwlat_detector/mode
echo 100000 > hwlat_detector/width
echo 200000 > hwlat_detector/window
echo 1 > tracing_on
To fix the issue, check if the hwlatd thread for the cpu is already running, before starting a new one. Along with the previous patch, this avoids running multiple instances of the same CPU thread on the system.
--- kernel/trace/trace_hwlat.c | 4 ++++ 1 file changed, 4 insertions(+)
kernel/trace/trace_hwlat.c +4 -0
@@ -492,6 +492,10 @@ static int start_cpu_kthread(unsigned in {struct task_struct *kthread; +/* Do not start a new hwlatd thread if it is already running */ +if (per_cpu (hwlat_per_cpu_data, cpu).kthread) +return 0 ; + kthread =kthread_run_on_cpu (kthread_fn,NULL , cpu,"hwlatd/%u" );if (IS_ERR (kthread)) {pr_err (BANNER "could not start sampling thread\n" );
Greg Kroah-Hartman
maintainerPATCH 193/211 ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent
In reply to Greg Kroah-HartmanFrom: Sudeep Holla <[email protected]>
commit 91d7b60a65d9f71230ea09b86d2058a884a3c2af upstream.
Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") enabled to map PPTT once on the first invocation of acpi_get_pptt() and never unmapped the same allowing it to be used at runtime with out the hassle of mapping and unmapping the table. This was needed to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the atomic context as the acpi_get_table() might sleep waiting for a mutex.
However it missed to handle the case when there is no PPTT on the system which results in acpi_get_pptt() being called from all the secondary CPUs attempting to fetch the LLC information in the atomic context without knowing the absence of PPTT resulting in the splat like below:
| BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 0 | hardirqs last enabled at (0): 0x0 | hardirqs last disabled at (0): copy_process+0x61c/0x1b40 | softirqs last enabled at (0): copy_process+0x61c/0x1b40 | softirqs last disabled at (0): 0x0 | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1 | Call trace: | dump_backtrace+0xac/0x138 | show_stack+0x30/0x48 | dump_stack_lvl+0x60/0xb0 | dump_stack+0x18/0x28 | __might_resched+0x160/0x270 | __might_sleep+0x58/0xb0 | down_timeout+0x34/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0x48/0xa0 | acpi_get_cache_info+0x38/0x140 | init_cache_level+0xf4/0x118 | detect_cache_attributes+0x2e4/0x640 | update_siblings_masks+0x3c/0x330 | store_cpu_topology+0x88/0xf0 | secondary_start_kernel+0xd0/0x168 | __secondary_switched+0xb8/0xc0
Update acpi_get_pptt() to consider the fact that PPTT is once checked and is not available on the system and return NULL avoiding any attempts to fetch PPTT and thereby avoiding any possible sleep waiting for a mutex in the atomic context.
--- drivers/acpi/pptt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/acpi/pptt.c +4 -1
@@ -537,16 +537,19 @@ static int topology_get_acpi_cpu_tag(strstatic struct acpi_table_header *acpi_get_pptt (void ) {static struct acpi_table_header *pptt; +static bool is_pptt_checked;acpi_status status;/* * PPTT will be used at runtime on every CPU hotplug in path, so we * don't need to call acpi_put_table() to release the table mapping. */ -if (!pptt) { +if (!pptt && !is_pptt_checked) { status =acpi_get_table (ACPI_SIG_PPTT ,0 , &pptt);if (ACPI_FAILURE (status))acpi_pptt_warn_missing (); + + is_pptt_checked = true; }return pptt;
Greg Kroah-Hartman
maintainerPATCH 194/211 net: phy: nxp-c45-tja11xx: fix MII_BASIC_CONFIG_REV bit
In reply to Greg Kroah-HartmanFrom: Radu Pirea (OSS) <[email protected]>
commit 8ba572052a4b8fe5b205854d27e54e3486049b71 upstream.
According to the TJA1103 user manual, the bit for the reversed role in MII or RMII modes is bit 4.
--- drivers/net/phy/nxp-c45-tja11xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/phy/nxp-c45-tja11xx.c +1 -1
@@ -79,7 +79,7 @@#define SGMII_ABILITY BIT(0)#define VEND1_MII_BASIC_CONFIG 0xAFC6 -#define MII_BASIC_CONFIG_REV BIT(8) +#define MII_BASIC_CONFIG_REV BIT(4)#define MII_BASIC_CONFIG_SGMII 0x9#define MII_BASIC_CONFIG_RGMII 0x7#define MII_BASIC_CONFIG_RMII 0x5
Greg Kroah-Hartman
maintainerPATCH 195/211 fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release()
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit fe9ae05cfbe587dda724fcf537c00bc2f287da62 upstream.
The recent fix for the deferred I/O by the commit
3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices")
caused a regression when the same fb device is opened/closed while it's being used. It resulted in a frozen screen even if something
is redrawn there after the close. The breakage is because the patch was made under a wrong assumption of a single open; in the current code, fb_deferred_io_release() cleans up the page mapping of the pageref list and it calls cancel_delayed_work_sync() unconditionally, where both are no correct behavior for multiple opens.
This patch adds a refcount for the opens of the device, and applies the cleanup only when all files get closed.
As both fb_deferred_io_open() and _close() are called always in the fb_info lock (mutex), it's safe to use the normal int for the refcounting.
Also, a useless BUG_ON() is dropped.
--- drivers/video/fbdev/core/fb_defio.c | 17 +++++++++++++---- include/linux/fb.h | 1 + 2 files changed, 14 insertions(+), 4 deletions(-)
drivers/video/fbdev/core/fb_defio.c +13 -4
@@ -309,17 +309,18 @@ void fb_deferred_io_open(struct fb_infostruct inode *inode, struct file *file) { + struct fb_deferred_io *fbdefio = info->fbdefio; + file->f_mapping->a_ops = &fb_deferred_io_aops; + fbdefio->open_count++; }EXPORT_SYMBOL_GPL (fb_deferred_io_open); -void fb_deferred_io_release (struct fb_info *info) +static void fb_deferred_io_lastclose (struct fb_info *info) { -struct fb_deferred_io *fbdefio = info->fbdefio;struct page *page;int i; -BUG_ON (!fbdefio);cancel_delayed_work_sync (&info->deferred_work);/* clear out the mapping that we setup */
@@ -328,13 +329,21 @@ void fb_deferred_io_release(struct fb_in page->mapping =NULL ; } } + +void fb_deferred_io_release (struct fb_info *info) +{ +struct fb_deferred_io *fbdefio = info->fbdefio; + +if (!--fbdefio->open_count) +fb_deferred_io_lastclose (info); +}EXPORT_SYMBOL_GPL (fb_deferred_io_release);void fb_deferred_io_cleanup (struct fb_info *info) {struct fb_deferred_io *fbdefio = info->fbdefio; -fb_deferred_io_release (info); +fb_deferred_io_lastclose (info);kvfree (info->pagerefs);mutex_destroy (&fbdefio->lock);
include/linux/fb.h +1 -0
@@ -212,6 +212,7 @@ struct fb_deferred_io {/* delay between mkwrite and deferred handler */ unsigned long delay;bool sort_pagereflist;/* sort pagelist by offset */ +int open_count;/* number of opened files; protected by fb_info lock */ struct mutex lock;/* mutex that protects the pageref list */ struct list_head pagereflist;/* list of pagerefs for touched pages */ /* callback */
Greg Kroah-Hartman
maintainerPATCH 196/211 RISC-V: mm: Support huge page in vmalloc_fault()
In reply to Greg Kroah-HartmanFrom: Dylan Jhong <[email protected]>
commit 47dd902aaee9b9341808a3a994793199e7eddb88 upstream.
Since RISC-V supports ioremap() with huge page (pud/pmd) mapping, However, vmalloc_fault() assumes that the vmalloc range is limited to pte mappings. To complete the vmalloc_fault() function by adding huge page support.
--- arch/riscv/mm/fault.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/riscv/mm/fault.c +5 -0
@@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long ano_context (regs, addr);return ; } +if (pud_leaf (*pud_k)) + goto flush_tlb;/* * Since the vmalloc area is global, it is unnecessary
@@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long ano_context (regs, addr);return ; } +if (pmd_leaf (*pmd_k)) + goto flush_tlb;/* * Make sure the actual PTE exists as well to
@@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a* ordering constraint, not a cache flush; it is * necessary even after writing invalid entries. */ +flush_tlb:local_flush_tlb_page (addr); }
Signature · 1 line
2.40.0
Greg Kroah-Hartman
maintainerPATCH 197/211 io_uring/msg_ring: let target know allocated index
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
commit 5da28edd7bd5518f97175ecea77615bb729a7a28 upstream.
msg_ring requests transferring files support auto index selection via IORING_FILE_INDEX_ALLOC, however they don't return the selected index to the target ring and there is no other good way for the userspace to know where is the receieved file.
Return the index for allocated slots and 0 otherwise, which is consistent with other fixed file installing requests.
--- io_uring/msg_ring.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
io_uring/msg_ring.c +3 -1
@@ -183,7 +183,7 @@ static int io_msg_install_complete(struc* completes with -EOVERFLOW, then the sender must ensure that a * later IORING_OP_MSG_RING delivers the message. */ -if (!io_post_aux_cqe (target_ctx, msg->user_data, msg->len,0 )) +if (!io_post_aux_cqe (target_ctx, msg->user_data, ret,0 )) ret = -EOVERFLOW ; out_unlock:io_double_unlock_ctx (target_ctx);
@@ -210,6 +210,8 @@ static int io_msg_send_fd(struct io_kiocstruct io_ring_ctx *ctx = req->ctx;struct file *src_file = msg->src_file; +if (msg->len) +return -EINVAL ;if (target_ctx == ctx)return -EINVAL ;if (target_ctx->flags &IORING_SETUP_R_DISABLED )
Greg Kroah-Hartman
maintainerPATCH 198/211 cpuidle: psci: Iterate backwards over list in psci_pd_remove()
In reply to Greg Kroah-HartmanFrom: Shawn Guo <[email protected]>
commit 6b0313c2fa3d2cf991c9ffef6fae6e7ef592ce6d upstream.
In case that psci_pd_init_topology() fails for some reason, psci_pd_remove() will be responsible for deleting provider and removing genpd from psci_pd_providers list. There will be a failure when removing the cluster PD, because the cpu (child) PDs haven't been removed.
[ 0.050232] CPUidle PSCI: init PM domain cpu0 [ 0.050278] CPUidle PSCI: init PM domain cpu1 [ 0.050329] CPUidle PSCI: init PM domain cpu2 [ 0.050370] CPUidle PSCI: init PM domain cpu3 [ 0.050422] CPUidle PSCI: init PM domain cpu-cluster0 [ 0.050475] PM: genpd_remove: unable to remove cpu-cluster0 [ 0.051412] PM: genpd_remove: removed cpu3 [ 0.051449] PM: genpd_remove: removed cpu2 [ 0.051499] PM: genpd_remove: removed cpu1 [ 0.051546] PM: genpd_remove: removed cpu0
Fix the problem by iterating the provider list reversely, so that parent PD gets removed after child's PDs like below.
[ 0.029052] CPUidle PSCI: init PM domain cpu0 [ 0.029076] CPUidle PSCI: init PM domain cpu1 [ 0.029103] CPUidle PSCI: init PM domain cpu2 [ 0.029124] CPUidle PSCI: init PM domain cpu3 [ 0.029151] CPUidle PSCI: init PM domain cpu-cluster0 [ 0.029647] PM: genpd_remove: removed cpu0 [ 0.029666] PM: genpd_remove: removed cpu1 [ 0.029690] PM: genpd_remove: removed cpu2 [ 0.029714] PM: genpd_remove: removed cpu3 [ 0.029738] PM: genpd_remove: removed cpu-cluster0
--- drivers/cpuidle/cpuidle-psci-domain.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/cpuidle/cpuidle-psci-domain.c +2 -1
@@ -103,7 +103,8 @@ static void psci_pd_remove(void)struct psci_pd_provider *pd_provider, *it;struct generic_pm_domain *genpd; -list_for_each_entry_safe (pd_provider, it, &psci_pd_providers, link) { +list_for_each_entry_safe_reverse (pd_provider, it, + &psci_pd_providers, link) {of_genpd_del_provider (pd_provider->node); genpd =of_genpd_remove_last (pd_provider->node);
Greg Kroah-Hartman
maintainerPATCH 199/211 ASoC: Intel: soc-acpi: fix copy-paste issue in topology names
In reply to Greg Kroah-HartmanFrom: Pierre-Louis Bossart <[email protected]>
commit 858a438a6cf919e5727d2a0f5f3f0e68b2d5354e upstream.
For some reason the convention for topology names was not followed and the name inspired by another unrelated hardware configuration. As a result, the kernel will request a non-existent topology file.
--- sound/soc/intel/common/soc-acpi-intel-adl-match.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/intel/common/soc-acpi-intel-adl-match.c +1 -1
@@ -559,7 +559,7 @@ struct snd_soc_acpi_mach snd_soc_acpi_in { .comp_ids = &essx_83x6, .drv_name = "sof-essx8336", - .sof_tplg_filename = "sof-adl-es83x6", /* the tplg suffix is added at run time */ + .sof_tplg_filename = "sof-adl-es8336", /* the tplg suffix is added at run time */ .tplg_quirk_mask =SND_SOC_ACPI_TPLG_INTEL_SSP_NUMBER |SND_SOC_ACPI_TPLG_INTEL_SSP_MSB | SND_SOC_ACPI_TPLG_INTEL_DMIC_NUMBER,
Greg Kroah-Hartman
maintainerPATCH 200/211 ASoC: qcom: q6prm: fix incorrect clk_root passed to ADSP
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
commit 65882134bc622a1e57bd5928ac588855ea2e3ddd upstream.
The second to last argument is clk_root (root of the clock), however the code called q6prm_request_lpass_clock() with clk_attr instead (copy-paste error). This effectively was passing value of 1 as root clock which worked on some of the SoCs (e.g. SM8450) but fails on others, depending on the ADSP. For example on SM8550 this "1" as root clock is not accepted and results in errors coming from ADSP.
--- sound/soc/qcom/qdsp6/q6prm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/qcom/qdsp6/q6prm.c +2 -2
@@ -183,9 +183,9 @@ int q6prm_set_lpass_clock(struct device unsigned int freq) {if (freq) -return q6prm_request_lpass_clock (dev, clk_id, clk_attr, clk_attr, freq); +return q6prm_request_lpass_clock (dev, clk_id, clk_attr, clk_root, freq); -return q6prm_release_lpass_clock (dev, clk_id, clk_attr, clk_attr, freq); +return q6prm_release_lpass_clock (dev, clk_id, clk_attr, clk_root, freq); }EXPORT_SYMBOL_GPL (q6prm_set_lpass_clock);
Greg Kroah-Hartman
maintainerPATCH 201/211 x86/mce: Make sure logged MCEs are processed after sysfs update
In reply to Greg Kroah-HartmanFrom: Yazen Ghannam <[email protected]>
commit 4783b9cb374af02d49740e00e2da19fd4ed6dec4 upstream.
A recent change introduced a flag to queue up errors found during boot-time polling. These errors will be processed during late init once the MCE subsystem is fully set up.
A number of sysfs updates call mce_restart() which goes through a subset of the CPU init flow. This includes polling MCA banks and logging any errors found. Since the same function is used as boot-time polling, errors will be queued. However, the system is now past late init, so the errors will remain queued until another error is found and the workqueue is triggered.
Call mce_schedule_work() at the end of mce_restart() so that queued errors are processed.
--- arch/x86/kernel/cpu/mce/core.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/kernel/cpu/mce/core.c +1 -0
@@ -2365,6 +2365,7 @@ static void mce_restart(void) {mce_timer_delete_all ();on_each_cpu (mce_cpu_restart,NULL ,1 ); +mce_schedule_work (); }/* Toggle features for corrected errors */
Greg Kroah-Hartman
maintainerPATCH 202/211 x86/mm: Fix use of uninitialized buffer in sme_enable()
In reply to Greg Kroah-HartmanFrom: Nikita Zhandarovich <[email protected]>
commit cbebd68f59f03633469f3ecf9bea99cd6cce3854 upstream.
cmdline_find_option() may fail before doing any initialization of the buffer array. This may lead to unpredictable results when the same buffer is used later in calls to strncmp() function. Fix the issue by returning early if cmdline_find_option() returns an error.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
--- arch/x86/mm/mem_encrypt_identity.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/mm/mem_encrypt_identity.c +2 -1
@@ -600,7 +600,8 @@ void __init sme_enable(struct boot_param cmdline_ptr = (const char *)((u64 )bp->hdr.cmd_line_ptr | ((u64 )bp->ext_cmd_line_ptr <<32 )); -cmdline_find_option (cmdline_ptr, cmdline_arg, buffer,sizeof (buffer)); +if (cmdline_find_option (cmdline_ptr, cmdline_arg, buffer,sizeof (buffer)) <0 ) +return ;if (!strncmp (buffer, cmdline_on,sizeof (buffer))) sme_me_mask = me_mask;
Greg Kroah-Hartman
maintainerPATCH 203/211 x86/resctrl: Clear staged_config[] before and after it is used
In reply to Greg Kroah-HartmanFrom: Shawn Wang <[email protected]>
commit 0424a7dfe9129b93f29b277511a60e87f052ac6b upstream.
As a temporary storage, staged_config[] in rdt_domain should be cleared before and after it is used. The stale value in staged_config[] could cause an MSR access error.
Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3 Cache (MBA should be disabled if the number of CLOSIDs for MB is less than 16.) :
mount -t resctrl resctrl -o cdp /sys/fs/resctrl
mkdir /sys/fs/resctrl/p{1..7}
umount /sys/fs/resctrl/
mount -t resctrl resctrl /sys/fs/resctrl
mkdir /sys/fs/resctrl/p{1..8}An error occurs when creating resource group named p8:
unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)
Call Trace:
<IRQ>
__flush_smp_call_function_queue+0x11d/0x170
__sysvec_call_function+0x24/0xd0
sysvec_call_function+0x89/0xc0
</IRQ>
<TASK>
asm_sysvec_call_function+0x16/0x20When creating a new resource control group, hardware will be configured by the following process:
rdtgroup_mkdir()
rdtgroup_mkdir_ctrl_mon()
rdtgroup_init_alloc()
resctrl_arch_update_domains()
resctrl_arch_update_domains() iterates and updates all resctrl_conf_type whose have_new_ctrl is true. Since staged_config[] holds the same values as when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA configurations. When group p8 is created, get_config_index() called in resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for CDP_CODE and CDP_DATA, which will be translated to an invalid register - 0xca0 in this scenario.
Fix it by clearing staged_config[] before and after it is used.
[reinette: re-order commit tags]
--- arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 7 ++----- arch/x86/kernel/cpu/resctrl/internal.h | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 25 +++++++++++++++++++++---- 3 files changed, 24 insertions(+), 9 deletions(-)
arch/x86/kernel/cpu/resctrl/ctrlmondata.c +2 -5
@@ -373,7 +373,6 @@ ssize_t rdtgroup_schemata_write(struct k {struct resctrl_schema *s;struct rdtgroup *rdtgrp; -struct rdt_domain *dom;struct rdt_resource *r;char *tok, *resname;int ret =0 ;
@@ -402,10 +401,7 @@ ssize_t rdtgroup_schemata_write(struct k goto out; } -list_for_each_entry (s, &resctrl_schema_all, list) { -list_for_each_entry (dom, &s->res->domains, list) -memset (dom->staged_config,0 ,sizeof (dom->staged_config)); - } +rdt_staged_configs_clear ();while ((tok =strsep (&buf,"\n" )) !=NULL ) { resname =strim (strsep (&tok,":" ));
@@ -450,6 +446,7 @@ ssize_t rdtgroup_schemata_write(struct k } out: +rdt_staged_configs_clear ();rdtgroup_kn_unlock (of->kn);cpus_read_unlock ();return ret ?: nbytes;
arch/x86/kernel/cpu/resctrl/internal.h +1 -0
@@ -527,5 +527,6 @@ bool has_busy_rmid(struct rdt_resource *void __check_limbo (struct rdt_domain *d,bool force_free);void rdt_domain_reconfigure_cdp (struct rdt_resource *r);void __init thread_throttle_mode_init (void ); +void rdt_staged_configs_clear (void );#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
arch/x86/kernel/cpu/resctrl/rdtgroup.c +21 -4
@@ -78,6 +78,19 @@ void rdt_last_cmd_printf(const char *fmtva_end (ap); } +void rdt_staged_configs_clear (void ) +{ +struct rdt_resource *r; +struct rdt_domain *dom; + +lockdep_assert_held (&rdtgroup_mutex); + +for_each_alloc_capable_rdt_resource (r) { +list_for_each_entry (dom, &r->domains, list) +memset (dom->staged_config,0 ,sizeof (dom->staged_config)); + } +} +/* * Trivial allocator for CLOSIDs. Since h/w only supports a small number, * we can keep a bitmap of free CLOSIDs in a single integer.
@@ -2851,7 +2864,9 @@ static int rdtgroup_init_alloc(struct rd {struct resctrl_schema *s;struct rdt_resource *r; -int ret; +int ret =0 ; + +rdt_staged_configs_clear ();list_for_each_entry (s, &resctrl_schema_all, list) { r = s->res;
@@ -2862,20 +2877,22 @@ static int rdtgroup_init_alloc(struct rd }else { ret =rdtgroup_init_cat (s, rdtgrp->closid);if (ret <0 ) -return ret; + goto out; } ret =resctrl_arch_update_domains (r, rdtgrp->closid);if (ret <0 ) {rdt_last_cmd_puts ("Failed to initialize allocations\n" ); -return ret; + goto out; } } rdtgrp->mode =RDT_MODE_SHAREABLE ; -return 0 ; +out: +rdt_staged_configs_clear (); +return ret; } static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
Greg Kroah-Hartman
maintainerPATCH 204/211 powerpc: Pass correct CPU reference to assembler
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit bfb03af71a3798b5a88a945a9c19ad67e1c4986d upstream.
Jan-Benedict reported issue with building ppc64e_defconfig with mainline GCC work:
powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -Wa,-me500 -Wa,-me500mc -mabi=elfv1 -mbig-endian -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S
arch/powerpc/kernel/vdso/gettimeofday.S: Assembler messages:
arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: stdu' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: stdu' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: std' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: std' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: ld' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: ld'
...
make[1]: *** [arch/powerpc/kernel/vdso/Makefile:76: arch/powerpc/kernel/vdso/gettimeofday-64.o] Error 1
make: *** [arch/powerpc/Makefile:387: vdso_prepare] Error 2
This is due to assembler being called with -me500mc which is a 32 bits target.
The problem comes from the fact that CONFIG_PPC_E500MC is selected for both the e500mc (32 bits) and the e5500 (64 bits), and therefore the following makefile rule is wrong:
cpu-as-$(CONFIG_PPC_E500MC) += $(call as-option,-Wa$(comma)-me500mc)
Today we have CONFIG_TARGET_CPU which provides the identification of the expected CPU, it is used for GCC. Once GCC knows the target CPU, it adds the correct CPU option to assembler, no need to add it explicitly.
With that change (And also commit 45f7091aac35 ("powerpc/64: Set default CPU in Kconfig")), it now is:
powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -mcpu=e500mc64 -mabi=elfv1 -mbig-endian -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S
--- arch/powerpc/Makefile | 4 ---- 1 file changed, 4 deletions(-)
arch/powerpc/Makefile +0 -4
@@ -201,10 +201,7 @@ KBUILD_CFLAGS += -fno-asynchronous-unwin # often slow when they are implemented at all KBUILD_CFLAGS += $(call cc-option,-mno-string) -cpu-as-$(CONFIG_40x) += -Wa,-m405 -cpu-as-$(CONFIG_44x) += -Wa,-m440 cpu-as-$(CONFIG_ALTIVEC) += $(call as-option,-Wa$(comma)-maltivec) -cpu-as-$(CONFIG_PPC_E500) += -Wa,-me500 # When using '-many -mpower4' gas will first try and find a matching power4 # mnemonic and failing that it will allow any valid mnemonic that GAS knows
@@ -212,7 +209,6 @@ cpu-as-$(CONFIG_PPC_E500) += -Wa,-me500 # LLVM IAS doesn't understand either flag: https://github.com/ClangBuiltLinux/linux/issues/675 # but LLVM IAS only supports ISA >= 2.06 for Book3S 64 anyway... cpu-as-$(CONFIG_PPC_BOOK3S_64) += $(call as-option,-Wa$(comma)-mpower4) $(call as-option,-Wa$(comma)-many) -cpu-as-$(CONFIG_PPC_E500MC) += $(call as-option,-Wa$(comma)-me500mc) KBUILD_AFLAGS += $(cpu-as-y) KBUILD_CFLAGS += $(cpu-as-y)
Greg Kroah-Hartman
maintainerPATCH 205/211 virt/coco/sev-guest: Check SEV_SNP attribute at probe time
In reply to Greg Kroah-HartmanFrom: Borislav Petkov (AMD) <[email protected]>
commit d6fd48eff7506bb866a54e40369df8899f2078a9 upstream.
No need to check it on every ioctl. And yes, this is a common SEV driver but it does only SNP-specific operations currently. This can be revisited later, when more use cases appear.
No functional changes.
--- arch/x86/kernel/sev.c | 3 --- drivers/virt/coco/sev-guest/sev-guest.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-)
arch/x86/kernel/sev.c +0 -3
@@ -2183,9 +2183,6 @@ int snp_issue_guest_request(u64 exit_codstruct ghcb *ghcb;int ret; -if (!cc_platform_has (CC_ATTR_GUEST_SEV_SNP )) -return -ENODEV ; -if (!fw_err)return -EINVAL ;
drivers/virt/coco/sev-guest/sev-guest.c +3 -0
@@ -703,6 +703,9 @@ static int __init sev_guest_probe(structvoid __iomem *mapping;int ret; +if (!cc_platform_has (CC_ATTR_GUEST_SEV_SNP )) +return -ENODEV ; +if (!dev->platform_data)return -ENODEV ;
Greg Kroah-Hartman
maintainerPATCH 206/211 virt/coco/sev-guest: Simplify extended guest request handling
In reply to Greg Kroah-HartmanFrom: Borislav Petkov (AMD) <[email protected]>
commit 970ab823743fb54b42002ec76c51481f67436444 upstream.
Return a specific error code - -ENOSPC - to signal the too small cert data buffer instead of checking exit code and exitinfo2.
While at it, hoist the *fw_err assignment in snp_issue_guest_request() so that a proper error value is returned to the callers.
[ Tom: check override_err instead of err. ]
--- arch/x86/kernel/sev.c | 11 ++++--- drivers/virt/coco/sev-guest/sev-guest.c | 48 +++++++++++++++++--------------- 2 files changed, 32 insertions(+), 27 deletions(-)
arch/x86/kernel/sev.c +6 -5
@@ -2209,15 +2209,16 @@ int snp_issue_guest_request(u64 exit_codif (ret) goto e_put; + *fw_err = ghcb->save.sw_exit_info_2;if (ghcb->save.sw_exit_info_2) {/* Number of expected pages are returned in RBX */ if (exit_code ==SVM_VMGEXIT_EXT_GUEST_REQUEST && - ghcb->save.sw_exit_info_2 ==SNP_GUEST_REQ_INVALID_LEN ) + ghcb->save.sw_exit_info_2 ==SNP_GUEST_REQ_INVALID_LEN ) { input->data_npages =ghcb_get_rbx (ghcb); - - *fw_err = ghcb->save.sw_exit_info_2; - - ret = -EIO ; + ret = -ENOSPC ; + }else { + ret = -EIO ; + } } e_put:
drivers/virt/coco/sev-guest/sev-guest.c +26 -22
85 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 207/211 virt/coco/sev-guest: Remove the disable_vmpck label in handle_guest_request()
In reply to Greg Kroah-HartmanFrom: Borislav Petkov (AMD) <[email protected]>
commit c5a338274bdb894f088767bea856be344d0ccaef upstream.
Call the function directly instead.
No functional changes.
--- drivers/virt/coco/sev-guest/sev-guest.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/virt/coco/sev-guest/sev-guest.c +4 -6
@@ -405,7 +405,8 @@ retry_request:dev_alert (snp_dev->dev,"Detected error from ASP request. rc: %d, fw_err: %llu\n" , rc, *fw_err); - goto disable_vmpck; +snp_disable_vmpck (snp_dev); +return rc; } rc =verify_and_dec_payload (snp_dev, resp_buf, resp_sz);
@@ -413,14 +414,11 @@ retry_request:dev_alert (snp_dev->dev,"Detected unexpected decode failure from ASP. rc: %d\n" , rc); - goto disable_vmpck; +snp_disable_vmpck (snp_dev); +return rc; }return 0 ; - -disable_vmpck: -snp_disable_vmpck (snp_dev); -return rc; }static int get_report (struct snp_guest_dev *snp_dev,struct snp_guest_request_ioctl *arg)
Greg Kroah-Hartman
maintainerPATCH 208/211 virt/coco/sev-guest: Carve out the request issuing logic into a helper
In reply to Greg Kroah-HartmanFrom: Borislav Petkov (AMD) <[email protected]>
commit 0fdb6cc7c89cb5e0cbc45dbdbafb8e3fb92ddc95 upstream.
This makes the code flow a lot easier to follow.
No functional changes.
[ Tom: touchups. ]
--- drivers/virt/coco/sev-guest/sev-guest.c | 44 +++++++++++++++++++------------- 1 file changed, 27 insertions(+), 17 deletions(-)
drivers/virt/coco/sev-guest/sev-guest.c +27 -17
@@ -318,27 +318,12 @@ static int enc_payload(struct snp_guest_return __enc_payload (snp_dev, req, payload, sz); } -static int handle_guest_request (struct snp_guest_dev *snp_dev,u64 exit_code,int msg_ver, -u8 type,void *req_buf,size_t req_sz,void *resp_buf, -u32 resp_sz,__u64 *fw_err) +static int __handle_guest_request (struct snp_guest_dev *snp_dev,u64 exit_code,__u64 *fw_err) {unsigned long err, override_err =0 ;unsigned int override_npages =0 ; -u64 seqno;int rc; -/* Get message sequence and verify that its a non-zero */ - seqno =snp_get_msg_seqno (snp_dev); -if (!seqno) -return -EIO ; - -memset (snp_dev->response,0 ,sizeof (struct snp_guest_msg )); - -/* Encrypt the userspace provided payload */ - rc =enc_payload (snp_dev, seqno, msg_ver, type, req_buf, req_sz); -if (rc) -return rc; - retry_request:/* * Call firmware to process the request. In this function the encrypted
@@ -347,7 +332,6 @@ retry_request:* prevent reuse of the IV. */ rc =snp_issue_guest_request (exit_code, &snp_dev->input, &err); -switch (rc) {case -ENOSPC :/*
@@ -401,7 +385,33 @@ retry_request:if (!rc && override_err ==SNP_GUEST_REQ_INVALID_LEN )return -EIO ; +return rc; +} + +static int handle_guest_request (struct snp_guest_dev *snp_dev,u64 exit_code,int msg_ver, +u8 type,void *req_buf,size_t req_sz,void *resp_buf, +u32 resp_sz,__u64 *fw_err) +{ +u64 seqno; +int rc; + +/* Get message sequence and verify that its a non-zero */ + seqno =snp_get_msg_seqno (snp_dev); +if (!seqno) +return -EIO ; + +memset (snp_dev->response,0 ,sizeof (struct snp_guest_msg )); + +/* Encrypt the userspace provided payload */ + rc =enc_payload (snp_dev, seqno, msg_ver, type, req_buf, req_sz); +if (rc) +return rc; + + rc =__handle_guest_request (snp_dev, exit_code, fw_err);if (rc) { +if (rc == -EIO && *fw_err ==SNP_GUEST_REQ_INVALID_LEN ) +return rc; +dev_alert (snp_dev->dev,"Detected error from ASP request. rc: %d, fw_err: %llu\n" , rc, *fw_err);
Greg Kroah-Hartman
maintainerPATCH 209/211 virt/coco/sev-guest: Do some code style cleanups
In reply to Greg Kroah-HartmanFrom: Borislav Petkov (AMD) <[email protected]>
commit d25bae7dc7b0668cb2a1325c64eb32d5fea4e5a9 upstream.
Remove unnecessary linebreaks, make the code more compact.
No functional changes.
--- drivers/virt/coco/sev-guest/sev-guest.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/virt/coco/sev-guest/sev-guest.c +2 -6
@@ -412,18 +412,14 @@ static int handle_guest_request(struct sif (rc == -EIO && *fw_err ==SNP_GUEST_REQ_INVALID_LEN )return rc; -dev_alert (snp_dev->dev, -"Detected error from ASP request. rc: %d, fw_err: %llu\n" , - rc, *fw_err); +dev_alert (snp_dev->dev,"Detected error from ASP request. rc: %d, fw_err: %llu\n" , rc, *fw_err);snp_disable_vmpck (snp_dev);return rc; } rc =verify_and_dec_payload (snp_dev, resp_buf, resp_sz);if (rc) { -dev_alert (snp_dev->dev, -"Detected unexpected decode failure from ASP. rc: %d\n" , - rc); +dev_alert (snp_dev->dev,"Detected unexpected decode failure from ASP. rc: %d\n" , rc);snp_disable_vmpck (snp_dev);return rc; }
Greg Kroah-Hartman
maintainerPATCH 210/211 virt/coco/sev-guest: Convert the sw_exit_info_2 checking to a switch-case
In reply to Greg Kroah-HartmanFrom: Borislav Petkov (AMD) <[email protected]>
commit fa4ae42cc60a7dea30e8f2db444b808d80862345 upstream.
snp_issue_guest_request() checks the value returned by the hypervisor in sw_exit_info_2 and returns a different error depending on it.
Convert those checks into a switch-case to make it more readable when more error values are going to be checked in the future.
No functional changes.
--- arch/x86/kernel/sev.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
arch/x86/kernel/sev.c +11 -5
@@ -2210,15 +2210,21 @@ int snp_issue_guest_request(u64 exit_cod goto e_put; *fw_err = ghcb->save.sw_exit_info_2; -if (ghcb->save.sw_exit_info_2) { +switch (*fw_err) { +case 0 : +break ; + +case SNP_GUEST_REQ_INVALID_LEN :/* Number of expected pages are returned in RBX */ -if (exit_code ==SVM_VMGEXIT_EXT_GUEST_REQUEST && - ghcb->save.sw_exit_info_2 ==SNP_GUEST_REQ_INVALID_LEN ) { +if (exit_code ==SVM_VMGEXIT_EXT_GUEST_REQUEST ) { input->data_npages =ghcb_get_rbx (ghcb); ret = -ENOSPC ; - }else { - ret = -EIO ; +break ; } + fallthrough; +default : + ret = -EIO ; +break ; } e_put:
Greg Kroah-Hartman
maintainerPATCH 211/211 virt/coco/sev-guest: Add throttling awareness
In reply to Greg Kroah-HartmanFrom: Dionna Glaze <[email protected]>
commit 72f7754dcf31c87c92c0c353dcf747814cc5ce10 upstream.
A potentially malicious SEV guest can constantly hammer the hypervisor using this driver to send down requests and thus prevent or at least considerably hinder other guests from issuing requests to the secure processor which is a shared platform resource.
Therefore, the host is permitted and encouraged to throttle such guest requests.
Add the capability to handle the case when the hypervisor throttles excessive numbers of requests issued by the guest. Otherwise, the VM platform communication key will be disabled, preventing the guest from attesting itself.
Realistically speaking, a well-behaved guest should not even care about throttling. During its lifetime, it would end up issuing a handful of requests which the hardware can easily handle.
This is more to address the case of a malicious guest. Such guest should get throttled and if its VMPCK gets disabled, then that's its own wrongdoing and perhaps that guest even deserves it.
To the implementation: the hypervisor signals with SNP_GUEST_REQ_ERR_BUSY that the guest requests should be throttled. That error code is returned in the upper 32-bit half of exitinfo2 and this is part of the GHCB spec v2.
So the guest is given a throttling period of 1 minute in which it retries the request every 2 seconds. This is a good default but if it turns out to not pan out in practice, it can be tweaked later.
For safety, since the encryption algorithm in GHCBv2 is AES_GCM, control must remain in the kernel to complete the request with the current sequence number. Returning without finishing the request allows the guest to make another request but with different message contents. This is IV reuse, and breaks cryptographic protections.
[ bp:
- Rewrite commit message and do a simplified version.
- The stable tags are supposed to denote that a cleanup should go upfront before backporting this so that any future fixes to this can preserve the sanity of the backporter(s). ]
--- arch/x86/include/asm/sev-common.h | 3 ++- arch/x86/kernel/sev.c | 4 ++++ drivers/virt/coco/sev-guest/sev-guest.c | 19 ++++++++++++++++++- 3 files changed, 24 insertions(+), 2 deletions(-)
arch/x86/include/asm/sev-common.h +2 -1
@@ -128,8 +128,9 @@ struct snp_psc_desc {struct psc_entry entries[VMGEXIT_PSC_MAX_ENTRY ]; } __packed; -/* Guest message request error code */ +/* Guest message request error codes */ #define SNP_GUEST_REQ_INVALID_LEN BIT_ULL(32) +#define SNP_GUEST_REQ_ERR_BUSY BIT_ULL(33)#define GHCB_MSR_TERM_REQ 0x100#define GHCB_MSR_TERM_REASON_SET_POS 12
arch/x86/kernel/sev.c +4 -0
@@ -2214,6 +2214,10 @@ int snp_issue_guest_request(u64 exit_codcase 0 :break ; +case SNP_GUEST_REQ_ERR_BUSY : + ret = -EAGAIN ; +break ; +case SNP_GUEST_REQ_INVALID_LEN :/* Number of expected pages are returned in RBX */ if (exit_code ==SVM_VMGEXIT_EXT_GUEST_REQUEST ) {
drivers/virt/coco/sev-guest/sev-guest.c +18 -1
@@ -31,6 +31,9 @@#define AAD_LEN 48#define MSG_HDR_VER 1 +#define SNP_REQ_MAX_RETRY_DURATION (60*HZ) +#define SNP_REQ_RETRY_DELAY (2*HZ) +struct snp_guest_crypto {struct crypto_aead *tfm;u8 *iv, *authtag;
@@ -320,7 +323,8 @@ static int enc_payload(struct snp_guest_static int __handle_guest_request (struct snp_guest_dev *snp_dev,u64 exit_code,__u64 *fw_err) { -unsigned long err, override_err =0 ; +unsigned long err =0xff , override_err =0 ; +unsigned long req_start = jiffies;unsigned int override_npages =0 ;int rc;
@@ -360,6 +364,19 @@ retry_request:* user as an ioctl() return code. */ goto retry_request; + +/* +* The host may return SNP_GUEST_REQ_ERR_EBUSY if the request has been +* throttled. Retry in the driver to avoid returning and reusing the +* message sequence number on a different message. +*/ +case -EAGAIN : +if (jiffies - req_start >SNP_REQ_MAX_RETRY_DURATION ) { + rc = -ETIMEDOUT ; +break ; + } +schedule_timeout_killable (SNP_REQ_RETRY_DELAY ); + goto retry_request; }/*
Hello Greg,
Quoted 10 lines
From: Greg Kroah-Hartman <[email protected]>
Sent: 20 March 2023 14:52This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
CIP configurations built and booted with Linux 6.2.8-rc1 (c536f48650a8):
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/812172270
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/commits/linux-6.2.y
Kind regards, Chris
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.2.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.2.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions on PowerPC build failures.
Quoted 2 lines
Christophe Leroy <[email protected]>
powerpc/64: Set default CPU inKconfig
We see PowerPC build failures with Clang 16 and nightly on the following configurations:
* cell_defconfig
* ppc64e_defconfig
* tqm8xx_defconfig
Error messages respectively:
-----8<-----
error: unknown target CPU 'cell'
note: valid target CPU values are: generic, 440, 450, 601, 602, 603, 603e, 603ev, 604, 604e, 620, 630, g3, 7400, g4, 7450, g4+, 750, 8548, 970, g5, a2, e500, e500mc, e5500, power3, pwr3, power4, pwr4, power5, pwr5, power5x, pwr5x, power6, pwr6, power6x, pwr6x, power7, pwr7, power8, pwr8, power9, pwr9, power10, pwr10, powerpc, ppc, ppc32, powerpc64, ppc64, powerpc64le, ppc64le, future ----->8-----
-----8<-----
error: unknown target CPU 'e500mc64'
note: valid target CPU values are: generic, 440, 450, 601, 602, 603, 603e, 603ev, 604, 604e, 620, 630, g3, 7400, g4, 7450, g4+, 750, 8548, 970, g5, a2, e500, e500mc, e5500, power3, pwr3, power4, pwr4, power5, pwr5, power5x, pwr5x, power6, pwr6, power6x, pwr6x, power7, pwr7, power8, pwr8, power9, pwr9, power10, pwr10, powerpc, ppc, ppc32, powerpc64, ppc64, powerpc64le, ppc64le, future ----->8-----
-----8<-----
error: unknown target CPU '860'
note: valid target CPU values are: generic, 440, 450, 601, 602, 603, 603e, 603ev, 604, 604e, 620, 630, g3, 7400, g4, 7450, g4+, 750, 8548, 970, g5, a2, e500, e500mc, e5500, power3, pwr3, power4, pwr4, power5, pwr5, power5x, pwr5x, power6, pwr6, power6x, pwr6x, power7, pwr7, power8, pwr8, power9, pwr9, power10, pwr10, powerpc, ppc, ppc32, powerpc64, ppc64, powerpc64le, ppc64le, future ----->8-----
The bisection pointed to this commit,
45f7091aac35 ("powerpc/64: Set default CPU in Kconfig")
Follow up fix patch is here as per Christophe Leroy comments,
powerpc: Disable CPU unknown by CLANG when CC_IS_CLANG
--
Linaro LKFT
https://lkft.linaro.org
On Mon, Mar 20, 2023 at 11:40 AM Naresh Kamboju
<[email protected]> wrote:
Thanks for the report!
Quoted 6 lines
The bisection pointed to this commit,
45f7091aac35("powerpc/64: Set default CPU inKconfig")Follow up fix patch is here as per Christophe Leroy comments,
powerpc: Disable CPU unknown by CLANG whenCC_IS_CLANG
Greg, Sasha,
Can you please also pick up
commit 4b10306e9845 ("powerpc: Disable CPU unknown by CLANG when CC_IS_CLANG")
4b10306e9845 is missing a fixes tag. I've filed
https://github.com/ClangBuiltLinux/linux/issues/1820 to track getting these -mcpu= values for ppc added to clang.
Signature · 2 lines
Thanks, ~Nick Desaulniers
Greg Kroah-Hartman
maintainerQuoted 12 lines · Nick Desaulniers
On Mon, Mar 20, 2023 at 11:40 AM Naresh Kamboju
<[email protected]> wrote:Thanks for the report!
Quoted 6 lines
The bisection pointed to this commit,
45f7091aac35("powerpc/64: Set default CPU inKconfig")Follow up fix patch is here as per Christophe Leroy comments,
powerpc: Disable CPU unknown by CLANG whenCC_IS_CLANG
Quoted 7 lines
Greg, Sasha,
Can you please also pick up
commit4b10306e9845("powerpc: Disable CPU unknown by CLANG whenCC_IS_CLANG")
4b10306e9845is missing a fixes tag. I've filed
https://github.com/ClangBuiltLinux/linux/issues/1820 to track getting these -mcpu= values for ppc added to clang.
Now queued up, thanks.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.2.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.2.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.2.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.2.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.2.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.2.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.2.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.2.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my x86_64 and ARM64 test systems. No errors or regressions.
Thanks.
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and powerpc (ps3_defconfig, GCC 12.2.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.2.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.2.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Thanks,
Conor.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.2.8 release. There are 211 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Mar 2023 14:54:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.2.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.2.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra.
Due to infrastructure issues, no test report available, but all tests are passing.
Jon
Signature · 1 line
nvpublic