From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit d2139dfca361a1f5bfc4d4a23455b1a409a69cd4 ]
The byte at offset 6 represents length. Don't take it and drop it
immediately by using proper accessor, i.e. get_unaligned_be24().
[JD: Change the subject to something less frightening]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jean Delvare <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/firmware/dmi_scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Tony Battersby <redacted>
[ Upstream commit 53661ded2460b414644532de6b99bd87f71987e9 ]
This partially reverts commit d2b292c3f6fd ("scsi: qla2xxx: Enable ATIO
interrupt handshake for ISP27XX")
For some workloads where the host sends a batch of commands and then
pauses, ATIO interrupt coalesce can cause some incoming ATIO entries to be
ignored for extended periods of time, resulting in slow performance,
timeouts, and aborted commands.
Disable interrupt coalesce and re-enable the dedicated ATIO MSI-X
interrupt.
Link: https://lore.kernel.org/r/97dcf365-89ff-014d-a3e5-1404c6af511c@cybernetics.com
Reviewed-by: Himanshu Madhani <redacted>
Reviewed-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Tony Battersby <redacted>
Signed-off-by: Martin K. Petersen <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/qla2xxx/qla_target.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
From: Brian Bunker <redacted>
[ Upstream commit 54249306e2776774ccb827969e62d34570f991db ]
The error path for the SCSI check condition of not ready, target in ALUA
state transition, will result in the failure of that path after the retries
are exhausted. In most cases that is well ahead of the transition timeout
established in the SCSI ALUA device handler.
Instead, reprep the command and re-add it to the queue after a 1 second
delay. This will allow the handler to take care of the timeout and only
fail the path if the target has exceeded the transition expiry timeout
(default 60 seconds). If the expiry timeout is exceeded, the handler will
change the path state from transitioning to standby leading to a path
failure eliminating the potential of this re-prep to continue endlessly. In
most cases the target will exit the transitioning state well before the
expiry timeout but after the retries are exhausted as mentioned.
Additionally remove the scsi_io_completion_reprep() function which provides
little value.
Link: https://lore.kernel.org/r/20220729214110.58576-1-brian@purestorage.com
Reviewed-by: Martin Wilck <redacted>
Acked-by: Krishna Kant <redacted>
Acked-by: Seamus Connor <redacted>
Signed-off-by: Brian Bunker <redacted>
Signed-off-by: Martin K. Petersen <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/scsi_lib.c | 44 +++++++++++++++++++++++------------------
1 file changed, 25 insertions(+), 19 deletions(-)
@@ -658,14 +663,6 @@ static unsigned int scsi_rq_err_bytes(const struct request *rq)returnbytes;}-/* Helper for scsi_io_completion() when "reprep" action required. */-staticvoidscsi_io_completion_reprep(structscsi_cmnd*cmd,-structrequest_queue*q)-{-/* A new command will be prepared and issued. */-scsi_mq_requeue_cmd(cmd);-}-staticboolscsi_cmd_runtime_exceeced(structscsi_cmnd*cmd){structrequest*req=scsi_cmd_to_rq(cmd);
@@ -683,14 +680,21 @@ static bool scsi_cmd_runtime_exceeced(struct scsi_cmnd *cmd)returnfalse;}+/*+*WhenALUAtransitionstateisreturned,reprepthecmdto+*usetheALUAhandler'stransitiontimeout.Delaythereprep+*1sectoavoidaggressiveretriesofthetargetinthat+*state.+*/+#define ALUA_TRANSITION_REPREP_DELAY 1000+/* Helper for scsi_io_completion() when special action required. */staticvoidscsi_io_completion_action(structscsi_cmnd*cmd,intresult){-structrequest_queue*q=cmd->device->request_queue;structrequest*req=scsi_cmd_to_rq(cmd);intlevel=0;-enum{ACTION_FAIL,ACTION_REPREP,ACTION_RETRY,-ACTION_DELAYED_RETRY}action;+enum{ACTION_FAIL,ACTION_REPREP,ACTION_DELAYED_REPREP,+ACTION_RETRY,ACTION_DELAYED_RETRY}action;structscsi_sense_hdrsshdr;boolsense_valid;boolsense_current=true;/* false implies "deferred sense" */
@@ -779,8 +783,8 @@ static void scsi_io_completion_action(struct scsi_cmnd *cmd, int result)action=ACTION_DELAYED_RETRY;break;case0x0a:/* ALUA state transition */-blk_stat=BLK_STS_TRANSPORT;-fallthrough;+action=ACTION_DELAYED_REPREP;+break;default:action=ACTION_FAIL;break;
@@ -839,7 +843,10 @@ static void scsi_io_completion_action(struct scsi_cmnd *cmd, int result)return;fallthrough;caseACTION_REPREP:-scsi_io_completion_reprep(cmd,q);+scsi_mq_requeue_cmd(cmd,0);+break;+caseACTION_DELAYED_REPREP:+scsi_mq_requeue_cmd(cmd,ALUA_TRANSITION_REPREP_DELAY);break;caseACTION_RETRY:/* Retry the same command immediately */
@@ -933,7 +940,7 @@ static int scsi_io_completion_nz_result(struct scsi_cmnd *cmd, int result,*commandblockwillbereleasedandthequeuefunctionwillbegoosed.Ifwe*arenotdonethenwehavetofigureoutwhattodonext:*-*a)Wecancallscsi_io_completion_reprep().Therequestwillbe+*a)Wecancallscsi_mq_requeue_cmd().Therequestwillbe*unpreparedandputbackonthequeue.Thenanewcommandwill*becreatedforit.Thisshouldbeusedifwemadeforward*progress,orifwewanttoswitchfromREAD(10)toREAD(6)for
@@ -949,7 +956,6 @@ static int scsi_io_completion_nz_result(struct scsi_cmnd *cmd, int result,voidscsi_io_completion(structscsi_cmnd*cmd,unsignedintgood_bytes){intresult=cmd->result;-structrequest_queue*q=cmd->device->request_queue;structrequest*req=scsi_cmd_to_rq(cmd);blk_status_tblk_stat=BLK_STS_OK;
From: Maxime Ripard <redacted>
[ Upstream commit 72e2329e7c9bbe15e7a813670497ec9c6f919af3 ]
We already depend on runtime PM to get the power domains and clocks for
most of the devices supported by the vc4 driver, so let's just select it
to make sure it's there.
Link: https://lore.kernel.org/r/20220629123510.1915022-38-maxime@cerno.tech
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Stefan Wahren <redacted>
Signed-off-by: Maxime Ripard <redacted>
(cherry picked from commit f1bc386b319e93e56453ae27e9e83817bb1f6f95)
Signed-off-by: Maxime Ripard <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/vc4/Kconfig | 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
From: Jeffy Chen <redacted>
[ Upstream commit ea2aa97ca37a9044ade001aef71dbc06318e8d44 ]
Currently we are assuming a one to one mapping between dmabuf and
GEM handle when releasing GEM handles.
But that is not always true, since we would create extra handles for the
GEM obj in cases like gem_open() and getfb{,2}().
A similar issue was reported at:
https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/
Another problem is that the imported dmabuf might not always have
gem_obj->dma_buf set, which would cause leaks in
drm_gem_remove_prime_handles().
Let's fix these for now by using handle to find the exact map to remove.
Signed-off-by: Jeffy Chen <redacted>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220819072834.17888-1-jeffy.chen@rock-chips.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/drm_gem.c | 17 +----------------
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 20 ++++++++++++--------
3 files changed, 15 insertions(+), 26 deletions(-)
From: Maxime Ripard <redacted>
[ Upstream commit 258e483a4d5e97a6a8caa74381ddc1f395ac1c71 ]
The current code tries to handle the case where CONFIG_PM isn't selected
by first calling our runtime_resume implementation and then properly
report the power state to the runtime_pm core.
This allows to have a functionning device even if pm_runtime_get_*
functions are nops.
However, the device power state if CONFIG_PM is enabled is
RPM_SUSPENDED, and thus our vc4_hdmi_write() and vc4_hdmi_read() calls
in the runtime_pm hooks will now report a warning since the device might
not be properly powered.
Even more so, we need CONFIG_PM enabled since the previous RaspberryPi
have a power domain that needs to be powered up for the HDMI controller
to be usable.
The previous patch has created a dependency on CONFIG_PM, now we can
just assume it's there and only call pm_runtime_resume_and_get() to make
sure our device is powered in bind.
Link: https://lore.kernel.org/r/20220629123510.1915022-39-maxime@cerno.tech
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Stefan Wahren <redacted>
Signed-off-by: Maxime Ripard <redacted>
(cherry picked from commit 53565c28e6af2cef6bbf438c34250135e3564459)
Signed-off-by: Maxime Ripard <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
From: Peter Zijlstra <peterz@infradead.org>
[ Upstream commit 7d3598868aaee05eb738d1c3115616b867e7530a ]
The SDM explicitly states that PEBS Baseline implies Extended PEBS.
For cpu model forward compatibility (e.g. on ICX, SPR, ADL), it's
safe to stop doing FMS table thing such as setting pebs_capable and
PMU_FL_PEBS_ALL since it's already set in the intel_ds_init().
The Goldmont Plus is the only platform which supports extended PEBS
but doesn't have Baseline. Keep the status quo.
Reported-by: Like Xu <redacted>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Kan Liang <redacted>
Link: https://lkml.kernel.org/r/20220816114057.51307-1-likexu@tencent.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/events/intel/core.c | 2 --
arch/x86/events/intel/ds.c | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
From: YiPeng Chai <redacted>
[ Upstream commit 9d705d7741ae70764f3d6d87e67fad3b5c30ffd0 ]
V1:
The amdgpu_xgmi_remove_device function will send unload command
to psp through psp ring to terminate xgmi, but psp ring has been
destroyed in psp_hw_fini.
V2:
1. Change the commit title.
2. Restore amdgpu_xgmi_remove_device to its original calling location.
Move psp_xgmi_terminate call from amdgpu_xgmi_remove_device to
psp_hw_fini.
Signed-off-by: YiPeng Chai <redacted>
Reviewed-by: Hawking Zhang <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
@@ -2482,12 +2482,14 @@ static int amdgpu_device_ip_init(struct amdgpu_device *adev)if(!hive->reset_domain||!amdgpu_reset_get_reset_domain(hive->reset_domain)){r=-ENOENT;+amdgpu_put_xgmi_hive(hive);gotoinit_failed;}/* Drop the early temporary reset domain we created for device */amdgpu_reset_put_reset_domain(adev->reset_domain);adev->reset_domain=hive->reset_domain;+amdgpu_put_xgmi_hive(hive);}}
From: Candice Li <redacted>
[ Upstream commit c351938350ab9b5e978dede2c321da43de7eb70c ]
No need to set up rb when no gfx rings.
Signed-off-by: Candice Li <redacted>
Reviewed-by: Hawking Zhang <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Zhenneng Li <redacted>
[ Upstream commit f461950fdc374a3ada5a63c669d997de4600dffe ]
Although radeon card fence and wait for gpu to finish processing current batch rings,
there is still a corner case that radeon lockup work queue may not be fully flushed,
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
Configuration and Message requests are the only TLPs accepted by a Function in
the D3hot state. All other received Requests must be handled as Unsupported Requests,
and all received Completions may optionally be handled as Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address 00008800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000
t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258
t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000
s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018
s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000
s6 = fff00007ef07bd98
a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008
a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338
t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800
t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000
gp = ffffffff81d89690 sp = 00000000aa814126
Disabling lock debugging due to kernel taint
Trace:
[<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0
[<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290
[<ffffffff80977010>] process_one_work+0x280/0x550
[<ffffffff80977350>] worker_thread+0x70/0x7c0
[<ffffffff80977410>] worker_thread+0x130/0x7c0
[<ffffffff80982040>] kthread+0x200/0x210
[<ffffffff809772e0>] worker_thread+0x0/0x7c0
[<ffffffff80981f8c>] kthread+0x14c/0x210
[<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20
[<ffffffff80981e40>] kthread+0x0/0x210
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
<88210000> 4821ed21
So force lockup work queue flush to fix this problem.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Zhenneng Li <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
1 file changed, 3 insertions(+)
From: Bart Van Assche <bvanassche@acm.org>
[ Upstream commit 8f2c96420c6ec3dcb18c8be923e24c6feaa5ccf6 ]
The current power mode change timeout (180 s) is so large that it can cause
a watchdog timer to fire. Reduce the power mode change timeout to 10
seconds.
Link: https://lore.kernel.org/r/20220811234401.1957911-1-bvanassche@acm.org
Reviewed-by: Stanley Chu <redacted>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ufs/core/ufshcd.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
From: Helge Deller <deller@gmx.de>
[ Upstream commit 591d2108f3abc4db9f9073cae37cf3591fd250d6 ]
If a 32-bit kernel was compiled for PA2.0 CPUs, it won't be able to run
on machines with PA1.x CPUs. Add a check and bail out early if a PA1.x
machine is detected.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/parisc/kernel/head.S | 43 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
@@ -70,6 +70,47 @@ $bss_loop:stw,ma%arg2,4(%r1)stw,ma%arg3,4(%r1)+#if !defined(CONFIG_64BIT) && defined(CONFIG_PA20)+/*This32-bitkernelwascompiledforPA2.0CPUs.CheckcurrentCPU+*andhaltkernelifwedetectaPA1.xCPU.*/+ldi32,%r10+mtctl%r10,%cr11+.level2.0+mfctl,w%cr11,%r10+.level1.1+comib,<>,n0,%r10,$cpu_ok++load32PA(msg1),%arg0+ldimsg1_end-msg1,%arg1+$iodc_panic:+copy%arg0, %r10+copy%arg1, %r11+load32PA(init_stack),%sp+#define MEM_CONS 0x3A0+ldwMEM_CONS+32(%r0),%arg0//HPA+ldiENTRY_IO_COUT,%arg1+ldwMEM_CONS+36(%r0),%arg2//SPA+ldwMEM_CONS+8(%r0),%arg3//layers+load32PA(__bss_start),%r1+stw%r1,-52(%sp)//arg4+stw%r0,-56(%sp)//arg5+stw%r10,-60(%sp)//arg6=ptrtotext+stw%r11,-64(%sp)//arg7=len+stw%r0,-68(%sp)//arg8+load32PA(.iodc_panic_ret),%rp+ldwMEM_CONS+40(%r0),%r1//ENTRY_IODC+bv,n (%r1)+.iodc_panic_ret:+b./*waitendlesswith...*/+or%r10,%r10,%r10/*qemuidlesleep*/+msg1:.ascii"Can't boot kernel which was built for PA8x00 CPUs on this machine.\r\n"+msg1_end:++$cpu_ok:+#endif++.levelPA_ASM_LEVEL+/*InitializestartupVM.Justmapfirst16/32MBofmemory*/load32PA(swapper_pg_dir),%r4mtctl%r4,%cr24/*Initializekernelrootpointer*/
From: Helge Deller <deller@gmx.de>
[ Upstream commit b4b18f47f4f9682fbf5827682645da7c8dde8f80 ]
This reverts commit b160628e9ebcdc85d0db9d7f423c26b3c7c179d0.
There is no need any longer to have this sanity check, because the
previous commit ("parisc: Make CONFIG_64BIT available for ARCH=parisc64
only") prevents that CONFIG_64BIT is set if ARCH==parisc.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/parisc/include/asm/bitops.h | 8 --------
1 file changed, 8 deletions(-)
@@ -12,14 +12,6 @@#include<asm/barrier.h>#include<linux/atomic.h>-/* compiler build environment sanity checks: */-#if !defined(CONFIG_64BIT) && defined(__LP64__)-#error "Please use 'ARCH=parisc' to build the 32-bit kernel."-#endif-#if defined(CONFIG_64BIT) && !defined(__LP64__)-#error "Please use 'ARCH=parisc64' to build the 64-bit kernel."-#endif-/* See http://marc.theaimsgroup.com/?t=108826637900003 for discussion*onuseofvolatileand__*_bit()(set/clear/change):**_bit()wantuseofvolatile.
From: Li Qiong <redacted>
[ Upstream commit d46c742f827fa2326ab1f4faa1cccadb56912341 ]
As the possible failure of the kmalloc(), it should be better
to fix this error path, check and return '-ENOMEM' error code.
Signed-off-by: Li Qiong <redacted>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/parisc/ccio-dma.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
From: Ionela Voinescu <redacted>
[ Upstream commit e89d120c4b720e232cc6a94f0fcbd59c15d41489 ]
The AMU counter AMEVCNTR01 (constant counter) should increment at the same
rate as the system counter. On affected Cortex-A510 cores, AMEVCNTR01
increments incorrectly giving a significantly higher output value. This
results in inaccurate task scheduler utilization tracking and incorrect
feedback on CPU frequency.
Work around this problem by returning 0 when reading the affected counter
in key locations that results in disabling all users of this counter from
using it either for frequency invariance or as FFH reference counter. This
effect is the same to firmware disabling affected counters.
Details on how the two features are affected by this erratum:
- AMU counters will not be used for frequency invariance for affected
CPUs and CPUs in the same cpufreq policy. AMUs can still be used for
frequency invariance for unaffected CPUs in the system. Although
unlikely, if no alternative method can be found to support frequency
invariance for affected CPUs (cpufreq based or solution based on
platform counters) frequency invariance will be disabled. Please check
the chapter on frequency invariance at
Documentation/scheduler/sched-capacity.rst for details of its effect.
- Given that FFH can be used to fetch either the core or constant counter
values, restrictions are lifted regarding any of these counters
returning a valid (!0) value. Therefore FFH is considered supported
if there is a least one CPU that support AMUs, independent of any
counters being disabled or affected by this erratum. Clarifying
comments are now added to the cpc_ffh_supported(), cpu_read_constcnt()
and cpu_read_corecnt() functions.
The above is achieved through adding a new erratum: ARM64_ERRATUM_2457168.
Signed-off-by: Ionela Voinescu <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20220819103050.24211-1-ionela.voinescu@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/arm64/silicon-errata.rst | 2 ++
arch/arm64/Kconfig | 17 ++++++++++++++
arch/arm64/kernel/cpu_errata.c | 10 ++++++++
arch/arm64/kernel/cpufeature.c | 5 +++-
arch/arm64/kernel/topology.c | 32 ++++++++++++++++++++++++--
arch/arm64/tools/cpucaps | 1 +
6 files changed, 64 insertions(+), 3 deletions(-)
From: Sudeep Holla <redacted>
[ Upstream commit e75d18cecbb3805895d8ed64da4f78575ec96043 ]
Though acpi_find_last_cache_level() always returned signed value and the
document states it will return any errors caused by lack of a PPTT table,
it never returned negative values before.
Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
however changed it by returning -ENOENT if no PPTT was found. The value
returned from acpi_find_last_cache_level() is then assigned to unsigned
fw_level.
It will result in the number of cache leaves calculated incorrectly as
a huge value which will then cause the following warning from __alloc_pages
as the order would be great than MAX_ORDER because of incorrect and huge
cache leaves value.
| WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314
| Modules linked in:
| CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73
| pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : __alloc_pages+0x74/0x314
| lr : alloc_pages+0xe8/0x318
| Call trace:
| __alloc_pages+0x74/0x314
| alloc_pages+0xe8/0x318
| kmalloc_order_trace+0x68/0x1dc
| __kmalloc+0x240/0x338
| detect_cache_attributes+0xe0/0x56c
| update_siblings_masks+0x38/0x284
| store_cpu_topology+0x78/0x84
| smp_prepare_cpus+0x48/0x134
| kernel_init_freeable+0xc4/0x14c
| kernel_init+0x2c/0x1b4
| ret_from_fork+0x10/0x20
Fix the same by changing fw_level to be signed integer and return the
error from init_cache_level() early in case of error.
Reported-and-Tested-by: Bruno Goncalves <redacted>
Signed-off-by: Sudeep Holla <redacted>
Link: https://lore.kernel.org/r/20220808084640.3165368-1-sudeep.holla@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/kernel/cacheinfo.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
@@ -63,6 +64,9 @@ int init_cache_level(unsigned int cpu)elsefw_level=acpi_find_last_cache_level(cpu);+if(fw_level<0)+returnfw_level;+if(level<fw_level){/**someexternalcachesnotspecifiedinCLIDR_EL1
From: Mark Brown <broonie@kernel.org>
[ Upstream commit 7ddcaf78e93c9282b4d92184f511b4d5bee75355 ]
The signal code has a limit of 64K on the size of a stack frame that it
will generate, if this limit is exceeded then a process will be killed if
it receives a signal. Unfortunately with the advent of SME this limit is
too small - the maximum possible size of the ZA register alone is 64K. This
is not an issue for practical systems at present but is easily seen using
virtual platforms.
Raise the limit to 256K, this is substantially more than could be used by
any current architecture extension.
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220817182324.638214-2-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Florian Westphal <fw@strlen.de>
[ Upstream commit cf97769c761abfeac8931b35fe0e1a8d5fabc9d8 ]
When a TCP sends more bytes than allowed by the receive window, all future
packets can be marked as invalid.
This can clog up the conntrack table because of 5-day default timeout.
Sequence of packets:
01 initiator > responder: [S], seq 171, win 5840, options [mss 1330,sackOK,TS val 63 ecr 0,nop,wscale 1]
02 responder > initiator: [S.], seq 33211, ack 172, win 65535, options [mss 1460,sackOK,TS val 010 ecr 63,nop,wscale 8]
03 initiator > responder: [.], ack 33212, win 2920, options [nop,nop,TS val 068 ecr 010], length 0
04 initiator > responder: [P.], seq 172:240, ack 33212, win 2920, options [nop,nop,TS val 279 ecr 010], length 68
Window is 5840 starting from 33212 -> 39052.
05 responder > initiator: [.], ack 240, win 256, options [nop,nop,TS val 872 ecr 279], length 0
06 responder > initiator: [.], seq 33212:34530, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
This is fine, conntrack will flag the connection as having outstanding
data (UNACKED), which lowers the conntrack timeout to 300s.
07 responder > initiator: [.], seq 34530:35848, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
08 responder > initiator: [.], seq 35848:37166, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
09 responder > initiator: [.], seq 37166:38484, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
10 responder > initiator: [.], seq 38484:39802, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
Packet 10 is already sending more than permitted, but conntrack doesn't
validate this (only seq is tested vs. maxend, not 'seq+len').
38484 is acceptable, but only up to 39052, so this packet should
not have been sent (or only 568 bytes, not 1318).
At this point, connection is still in '300s' mode.
Next packet however will get flagged:
11 responder > initiator: [P.], seq 39802:40128, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 326
nf_ct_proto_6: SEQ is over the upper bound (over the window of the receiver) .. LEN=378 .. SEQ=39802 ACK=240 ACK PSH ..
Now, a couple of replies/acks comes in:
12 initiator > responder: [.], ack 34530, win 4368,
[.. irrelevant acks removed ]
16 initiator > responder: [.], ack 39802, win 8712, options [nop,nop,TS val 296201291 ecr 2982371892], length 0
This ack is significant -- this acks the last packet send by the
responder that conntrack considered valid.
This means that ack == td_end. This will withdraw the
'unacked data' flag, the connection moves back to the 5-day timeout
of established conntracks.
17 initiator > responder: ack 40128, win 10030, ...
This packet is also flagged as invalid.
Because conntrack only updates state based on packets that are
considered valid, packet 11 'did not exist' and that gets us:
nf_ct_proto_6: ACK is over upper bound 39803 (ACKed data not seen yet) .. SEQ=240 ACK=40128 WINDOW=10030 RES=0x00 ACK URG
Because this received and processed by the endpoints, the conntrack entry
remains in a bad state, no packets will ever be considered valid again:
30 responder > initiator: [F.], seq 40432, ack 2045, win 391, ..
31 initiator > responder: [.], ack 40433, win 11348, ..
32 initiator > responder: [F.], seq 2045, ack 40433, win 11348 ..
... all trigger 'ACK is over bound' test and we end up with
non-early-evictable 5-day default timeout.
NB: This patch triggers a bunch of checkpatch warnings because of silly
indent. I will resend the cleanup series linked below to reduce the
indent level once this change has propagated to net-next.
I could route the cleanup via nf but that causes extra backport work for
stable maintainers.
Link: https://lore.kernel.org/netfilter-devel/20220720175228.17880-1-fw@strlen.de/T/#mb1d7147d36294573cc4f81d00f9f8dadfdd06cd8
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/netfilter/nf_conntrack_proto_tcp.c | 31 ++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
@@ -655,6 +655,37 @@ static bool tcp_in_window(struct nf_conn *ct,tn->tcp_be_liberal)res=true;if(!res){+boolseq_ok=before(seq,sender->td_maxend+1);++if(!seq_ok){+u32overshot=end-sender->td_maxend+1;+boolack_ok;++ack_ok=after(sack,receiver->td_end-MAXACKWINDOW(sender)-1);++if(in_recv_win&&+ack_ok&&+overshot<=receiver->td_maxwin&&+before(sack,receiver->td_end+1)){+/* Work around TCPs that send more bytes than allowed by+*thereceivewindow.+*+*Ifthe(markedasinvalid)packetisallowedtopassby+*therulesetandthepeeracksthisdata,thenitspossible+*allfuturepacketswilltrigger'ACKisoverupperbound'check.+*+*Thusifonlythesequencecheckfailsthendoupdatetd_endso+*possibleACKforthisdatacanupdateinternalstate.+*/+sender->td_end=end;+sender->flags|=IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED;++nf_ct_l4proto_log_invalid(skb,ct,hook_state,+"%u bytes more than expected",overshot);+returnres;+}+}+nf_ct_l4proto_log_invalid(skb,ct,hook_state,"%s",before(seq,sender->td_maxend+1)?
From: "Lee, Chun-Yi" <redacted>
[ Upstream commit 7931e28098a4c1a2a6802510b0cbe57546d2049d ]
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.
[ 71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault.
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Rafael J. Wysocki <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
From: Lukasz Luba <lukasz.luba@arm.com>
[ Upstream commit 6ca7076fbfaeccce173aeab832d76b9e49e1034b ]
There is no need to check if the cpufreq driver implements callback
cpufreq_driver::target_index. The logic in the __resolve_freq uses
the frequency table available in the policy. It doesn't matter if the
driver provides 'target_index' or 'target' callback. It just has to
populate the 'policy->freq_table'.
Thus, check only frequency table during the frequency resolving call.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Csókás Bence <redacted>
[ Upstream commit f79959220fa5fbda939592bf91c7a9ea90419040 ]
On link state change, the controller gets reset,
causing PPS to drop out and the PHC to lose its
time and calibration. So we restart it if needed,
restoring calibration and time registers.
Changes since v2:
* Add `fec_ptp_save_state()`/`fec_ptp_restore_state()`
* Use `ktime_get_real_ns()`
* Use `BIT()` macro
Changes since v1:
* More ECR #define's
* Stop PPS in `fec_ptp_stop()`
Signed-off-by: Csókás Bence <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/fec.h | 10 ++++++
drivers/net/ethernet/freescale/fec_main.c | 42 ++++++++++++++++++++---
drivers/net/ethernet/freescale/fec_ptp.c | 29 ++++++++++++++++
3 files changed, 77 insertions(+), 4 deletions(-)
@@ -982,6 +985,9 @@ fec_restart(struct net_device *ndev)u32temp_mac[2];u32rcntl=OPT_FRAME_SIZE|0x04;u32ecntl=0x2;/* ETHEREN */+structptp_clock_requestptp_rq={.type=PTP_CLK_REQ_PPS};++fec_ptp_save_state(fep);/* Whack a reset. We should wait for this.*Fori.MX6SXSOC,enetuseAXIbus,weusedisableMAC
@@ -1156,6 +1162,14 @@ fec_restart(struct net_device *ndev)if(fep->bufdesc_ex)fec_ptp_start_cyclecounter(ndev);+/* Restart PPS if needed */+if(fep->pps_enable){+/* Clear flag so fec_ptp_enable_pps() doesn't return immediately */+fep->pps_enable=0;+fec_ptp_restore_state(fep);+fep->ptp_caps.enable(&fep->ptp_caps,&ptp_rq,1);+}+/* Enable interrupts we wish to service */if(fep->link)writel(FEC_DEFAULT_IMASK,fep->hwp+FEC_IMASK);
@@ -1206,6 +1220,8 @@ fec_stop(struct net_device *ndev)structfec_enet_private*fep=netdev_priv(ndev);u32rmii_mode=readl(fep->hwp+FEC_R_CNTRL)&(1<<8);u32val;+structptp_clock_requestptp_rq={.type=PTP_CLK_REQ_PPS};+u32ecntl=0;/* We cannot expect a graceful transmit stop without link !!! */if(fep->link){
@@ -1215,6 +1231,8 @@ fec_stop(struct net_device *ndev)netdev_err(ndev,"Graceful transmit stop did not complete!\n");}+fec_ptp_save_state(fep);+/* Whack a reset. We should wait for this.*Fori.MX6SXSOC,enetuseAXIbus,weusedisableMAC*insteadofresetMACitself.
@@ -1234,12 +1252,28 @@ fec_stop(struct net_device *ndev)writel(fep->phy_speed,fep->hwp+FEC_MII_SPEED);writel(FEC_DEFAULT_IMASK,fep->hwp+FEC_IMASK);+if(fep->bufdesc_ex)+ecntl|=FEC_ECR_EN1588;+/* We have to keep ENET enabled to have MII interrupt stay working */if(fep->quirks&FEC_QUIRK_ENET_MAC&&!(fep->wol_flag&FEC_WOL_FLAG_SLEEP_ON)){-writel(2,fep->hwp+FEC_ECNTRL);+ecntl|=FEC_ECR_ETHEREN;writel(rmii_mode,fep->hwp+FEC_R_CNTRL);}++writel(ecntl,fep->hwp+FEC_ECNTRL);++if(fep->bufdesc_ex)+fec_ptp_start_cyclecounter(ndev);++/* Restart PPS if needed */+if(fep->pps_enable){+/* Clear flag so fec_ptp_enable_pps() doesn't return immediately */+fep->pps_enable=0;+fec_ptp_restore_state(fep);+fep->ptp_caps.enable(&fep->ptp_caps,&ptp_rq,1);+}}
From: lily <redacted>
[ Upstream commit c624c58e08b15105662b9ab9be23d14a6b945a49 ]
skb_copy_bits() could fail, which requires a check on the return
value.
Signed-off-by: Li Zhong <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/skbuff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: David Sloan <redacted>
[ Upstream commit 5e8daf906f890560df430d30617c692a794acb73 ]
A race condition still exists when removing and re-creating md devices
in test cases. However, it is only seen on some setups.
The race condition was tracked down to a reference still being held
to the kobject by the rdev in the md_rdev_misc_wq which will be released
in rdev_delayed_delete().
md_alloc() waits for previous deletions by waiting on the md_misc_wq,
but the md_rdev_misc_wq may still be holding a reference to a recently
removed device.
To fix this, also flush the md_rdev_misc_wq in md_alloc().
Signed-off-by: David Sloan <redacted>
[logang@deltatee.com: rewrote commit message]
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Song Liu <song@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/md.c | 1 +
1 file changed, 1 insertion(+)
@@ -1643,14 +1643,14 @@ static int omapfb_do_probe(struct platform_device *pdev,gotocleanup;}fbdev->int_irq=platform_get_irq(pdev,0);-if(!fbdev->int_irq){+if(fbdev->int_irq<0){dev_err(&pdev->dev,"unable to get irq\n");r=ENXIO;gotocleanup;}fbdev->ext_irq=platform_get_irq(pdev,1);-if(!fbdev->ext_irq){+if(fbdev->ext_irq<0){dev_err(&pdev->dev,"unable to get irq\n");r=ENXIO;gotocleanup;
From: Letu Ren <redacted>
[ Upstream commit 19f953e7435644b81332dd632ba1b2d80b1e37af ]
In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be
copied from user, then go through `fb_set_var()` and
`info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`.
Along the path, `var->pixclock` won't be modified. This function checks
whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is
zero, there will be a divide by zero error. So, it is necessary to check
whether denominator is zero to avoid crash. As this bug is found by
Syzkaller, logs are listed below.
divide error in pm2fb_check_var
Call Trace:
<TASK>
fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015
do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
Reported-by: Zheyu Ma <redacted>
Signed-off-by: Letu Ren <redacted>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/pm2fb.c | 5 +++++
1 file changed, 5 insertions(+)
@@ -617,6 +617,11 @@ static int pm2fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)return-EINVAL;}+if(!var->pixclock){+DPRINTK("pixclock is zero\n");+return-EINVAL;+}+if(PICOS2KHZ(var->pixclock)>PM2_MAX_PIXCLOCK){DPRINTK("pixclock too high (%ldKHz)\n",PICOS2KHZ(var->pixclock));
From: Shigeru Yoshida <redacted>
[ Upstream commit 58559dfc1ebba2ae0c7627dc8f8991ae1984c6e3 ]
It's needed to destroy bl_curve_mutex on freeing struct fb_info since
the mutex is embedded in the structure and initialized when it's
allocated.
Signed-off-by: Shigeru Yoshida <redacted>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/core/fbsysfs.c | 4 ++++
1 file changed, 4 insertions(+)
From: Borislav Petkov <redacted>
[ Upstream commit c93c296fff6b369a7115916145047c8a3db6e27f ]
Mark both the function prototype and definition as noreturn in order to
prevent the compiler from doing transformations which confuse objtool
like so:
vmlinux.o: warning: objtool: sme_enable+0x71: unreachable instruction
This triggers with gcc-12.
Add it and sev_es_terminate() to the objtool noreturn tracking array
too. Sort it while at it.
Suggested-by: Michael Matz <redacted>
Signed-off-by: Borislav Petkov <redacted>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220824152420.20547-1-bp@alien8.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/include/asm/sev.h | 2 +-
arch/x86/kernel/sev.c | 2 +-
tools/objtool/check.c | 34 ++++++++++++++++++----------------
3 files changed, 20 insertions(+), 18 deletions(-)
From: Tim Huang <redacted>
[ Upstream commit 00047c3d967d7ef8adf8bac3c3579294a3bc0bb1 ]
For some ASICs, like GFX IP v11.0.1, only have one SDMA instance,
so not need to configure SDMA1_RLC_CGCG_CTRL for this case.
Signed-off-by: Tim Huang <redacted>
Reviewed-by: Yifan Zhang <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -5090,9 +5090,12 @@ static void gfx_v11_0_update_coarse_grain_clock_gating(struct amdgpu_device *adedata=REG_SET_FIELD(data,SDMA0_RLC_CGCG_CTRL,CGCG_INT_ENABLE,1);WREG32_SOC15(GC,0,regSDMA0_RLC_CGCG_CTRL,data);-data=RREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL);-data=REG_SET_FIELD(data,SDMA1_RLC_CGCG_CTRL,CGCG_INT_ENABLE,1);-WREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL,data);+/* Some ASICs only have one SDMA instance, not need to configure SDMA1 */+if(adev->sdma.num_instances>1){+data=RREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL);+data=REG_SET_FIELD(data,SDMA1_RLC_CGCG_CTRL,CGCG_INT_ENABLE,1);+WREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL,data);+}}else{/* Program RLC_CGCG_CGLS_CTRL */def=data=RREG32_SOC15(GC,0,regRLC_CGCG_CGLS_CTRL);
@@ -5121,9 +5124,12 @@ static void gfx_v11_0_update_coarse_grain_clock_gating(struct amdgpu_device *adedata&=~SDMA0_RLC_CGCG_CTRL__CGCG_INT_ENABLE_MASK;WREG32_SOC15(GC,0,regSDMA0_RLC_CGCG_CTRL,data);-data=RREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL);-data&=~SDMA1_RLC_CGCG_CTRL__CGCG_INT_ENABLE_MASK;-WREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL,data);+/* Some ASICs only have one SDMA instance, not need to configure SDMA1 */+if(adev->sdma.num_instances>1){+data=RREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL);+data&=~SDMA1_RLC_CGCG_CTRL__CGCG_INT_ENABLE_MASK;+WREG32_SOC15(GC,0,regSDMA1_RLC_CGCG_CTRL,data);+}}}
From: Jean Delvare <hidden> Date: 2022-08-30 21:32:48
Hi Sasha,
On Tue, 30 Aug 2022 13:17:52 -0400, Sasha Levin wrote:
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit d2139dfca361a1f5bfc4d4a23455b1a409a69cd4 ]
The byte at offset 6 represents length. Don't take it and drop it
immediately by using proper accessor, i.e. get_unaligned_be24().
[JD: Change the subject to something less frightening]
Nack. This is NOT a bug fix, there's simply no reason to backport
this to stable kernel trees.
Thanks,
--
Jean Delvare
SUSE L3 Support
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2022-08-31 11:50:38
On Tue, Aug 30, 2022 at 11:32:37PM +0200, Jean Delvare wrote:
On Tue, 30 Aug 2022 13:17:52 -0400, Sasha Levin wrote:
quoted
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit d2139dfca361a1f5bfc4d4a23455b1a409a69cd4 ]
The byte at offset 6 represents length. Don't take it and drop it
immediately by using proper accessor, i.e. get_unaligned_be24().
[JD: Change the subject to something less frightening]
Nack. This is NOT a bug fix, there's simply no reason to backport
this to stable kernel trees.
From: Csókás Bence <redacted>
[ Upstream commit f79959220fa5fbda939592bf91c7a9ea90419040 ]
On link state change, the controller gets reset,
causing PPS to drop out and the PHC to lose its
time and calibration. So we restart it if needed,
restoring calibration and time registers.
There is an ongoing investigation on netdev@ about a potential kernel panic on kernels newer than 5.12 with this patch applied. Please hold off on backporting to 5.19 until the bugfix is applied to upstream.
On Wed, Aug 31, 2022 at 03:02:46PM +0200, Csókás Bence wrote:
On 2022. 08. 30. 19:18, Sasha Levin wrote:
quoted
From: Csókás Bence <redacted>
[ Upstream commit f79959220fa5fbda939592bf91c7a9ea90419040 ]
On link state change, the controller gets reset,
causing PPS to drop out and the PHC to lose its
time and calibration. So we restart it if needed,
restoring calibration and time registers.
There is an ongoing investigation on netdev@ about a potential kernel panic on kernels newer than 5.12 with this patch applied. Please hold off on backporting to 5.19 until the bugfix is applied to upstream.
On Wed, Aug 31, 2022 at 02:50:25PM +0300, Andy Shevchenko wrote:
On Tue, Aug 30, 2022 at 11:32:37PM +0200, Jean Delvare wrote:
quoted
On Tue, 30 Aug 2022 13:17:52 -0400, Sasha Levin wrote:
quoted
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit d2139dfca361a1f5bfc4d4a23455b1a409a69cd4 ]
The byte at offset 6 represents length. Don't take it and drop it
immediately by using proper accessor, i.e. get_unaligned_be24().
[JD: Change the subject to something less frightening]
Nack. This is NOT a bug fix, there's simply no reason to backport
this to stable kernel trees.