Hi,
I attached the vmcore with vmlinux symbol for further analysis and will share
it at the following link.
Link:
https://drive.google.com/file/d/1_RFdpdWNuLdO-Yx6d7vIX-WAFX4X_msH/view?usp=drive_link
On 5/6/25 9:30 오전, Yunseong Kim wrote:
> Hi Colin,
>
>>> The crash seems to originate from rc
bot-assets/541828a1cf09/bzImage-3b9dfd9e.xz
mounted in repro:
https://storage.googleapis.com/syzbot-assets/cc6a8f9d7bd9/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+14d9438422f594f85...@syzkaller.appspotmail.com
Kernel panic - not sync
NIC has EFX_MAX_CHANNELS channels:
struct efx_nic {
[...]
struct efx_channel *channel[EFX_MAX_CHANNELS];
[...]
}
Each channel has EFX_MAX_TXQ_PER_CHANNEL TX queues; There a reverse
mapping from type to TX queue, holding at most EFX_TXQ_TYPES
entries. This mapping is a bitse
On Wed, 14 Apr 2021 at 11:48, Christian König
wrote:
>
> >> commit f63da9ae7584280582cbc834b20cc18bfb203b14
> >> Author: Philip Yang
> >> Date: Thu Apr 1 00:22:23 2021 -0400
> >>
> >> drm/amdgpu: reserve fence slot to update page table
> >>
>
> That is expected behavior, the application i
From: Vinay Kumar Yadav
commit 1a73e427b824133940c2dd95ebe26b6dce1cbf10 upstream.
Taking page refcount is not ideal and causes kernel panic
sometimes. It's better to take tx_ctx lock for the complete
skb transmit, to avoid page cleanup if ACK received in middle.
Fixes: 5a4b9fe7fece (&
From: Vinay Kumar Yadav
commit 1a73e427b824133940c2dd95ebe26b6dce1cbf10 upstream.
Taking page refcount is not ideal and causes kernel panic
sometimes. It's better to take tx_ctx lock for the complete
skb transmit, to avoid page cleanup if ACK received in middle.
Fixes: 5a4b9fe7fece (&
On 2021-02-26 15:00:23, Jeffrey Mitchell wrote:
> When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount()
> causes a kernel panic if the parsed options are valid. The easiest way to
> reproduce this is to call mount() from userspace with an existing
> eCryptfs
Am 13.04.21 um 23:19 schrieb Mikhail Gavrilov:
On Tue, 13 Apr 2021 at 12:29, Christian König wrote:
Hi Mikhail,
the crash is a known issue and should be fixed by:
commit f63da9ae7584280582cbc834b20cc18bfb203b14
Author: Philip Yang
Date: Thu Apr 1 00:22:23 2021 -0400
drm/amdgpu: r
On Tue, 13 Apr 2021 at 12:29, Christian König wrote:
>
> Hi Mikhail,
>
> the crash is a known issue and should be fixed by:
>
> commit f63da9ae7584280582cbc834b20cc18bfb203b14
> Author: Philip Yang
> Date: Thu Apr 1 00:22:23 2021 -0400
>
> drm/amdgpu: reserve fence slot to update page tabl
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J6PQR%2FDssvup2W5CTFLN7wsr79M2AZJDz1uT%2FfmxH1U%3D&reserved=0
It curious why ffmpeg does not cause such issues.
For example such command not cause kernel panic:
$ ffmpeg -f x11grab -framerate 60 -video_size 3840x2160 -i :0.0 -vf
'format=nv12,hwupload' -vaap
much more dangerous and, as a rule, leads to system freezing.
Full traces uploaded here:
[1] https://pastebin.com/aAeazCP8
[2] https://pastebin.com/ZLUP8Xvs
It curious why ffmpeg does not cause such issues.
For example such command not cause kernel panic:
$ ffmpeg -f x11grab -framerate 60 -video_si
On Fri, 9 Apr 2021 12:16:26 +0800
"liaochang (A)" wrote:
>
>
> 在 2021/4/8 19:20, Jisheng Zhang 写道:
> > On Tue, 30 Mar 2021 16:18:48 +0800
> > Liao Chang wrote:
> >
> >
> >>
> >> The execution of sys_read end up hitting a BUG_ON() in __find_get_block
> >> after installing kprobe at sys_read,
From: Kamal Heib
[ Upstream commit e1ad897b9c738d5550be6762bf3a6ef1672259a4 ]
As INI QP does not require a recv_cq, avoid the following null pointer
dereference by checking if the qp_type is not INI before trying to extract
the recv_cq.
BUG: kernel NULL pointer dereference, address: 000
From: Kamal Heib
[ Upstream commit e1ad897b9c738d5550be6762bf3a6ef1672259a4 ]
As INI QP does not require a recv_cq, avoid the following null pointer
dereference by checking if the qp_type is not INI before trying to extract
the recv_cq.
BUG: kernel NULL pointer dereference, address: 000
在 2021/4/8 19:20, Jisheng Zhang 写道:
> On Tue, 30 Mar 2021 16:18:48 +0800
> Liao Chang wrote:
>
>
>>
>> The execution of sys_read end up hitting a BUG_ON() in __find_get_block
>> after installing kprobe at sys_read, the BUG message like the following:
>>
>> [ 65.708663] [ cut here
On Tue, 30 Mar 2021 16:18:48 +0800
Liao Chang wrote:
>
> The execution of sys_read end up hitting a BUG_ON() in __find_get_block
> after installing kprobe at sys_read, the BUG message like the following:
>
> [ 65.708663] [ cut here ]
> [ 65.709987] kernel BUG at fs/
The execution of sys_read end up hitting a BUG_ON() in __find_get_block
after installing kprobe at sys_read, the BUG message like the following:
[ 65.708663] [ cut here ]
[ 65.709987] kernel BUG at fs/buffer.c:1251!
[ 65.711283] Kernel BUG [#1]
[ 65.712032] Modules
ldn`t be "devm_kzalloc"ed if
> dma_cap->frpsel is 0 (Flexible Rx Parser is not supported in SoC) in
> tc_init(). So, fpe_cfg will be remain as NULL and accessing it will cause
> kernel panic.
>
> [...]
Here is the summary with links:
- [net-next] net: stmmac: Fix
is 0 (Flexible Rx Parser is not supported in SoC) in
> tc_init(). So, fpe_cfg will be remain as NULL and accessing it will cause
> kernel panic.
>
> To fix this, move the "devm_kzalloc"ing of priv->plat->fpe_cfg before
> dma_cap->frpsel checking in tc_in
main as NULL and accessing it will cause
kernel panic.
To fix this, move the "devm_kzalloc"ing of priv->plat->fpe_cfg before
dma_cap->frpsel checking in tc_init(). Additionally, checking of
priv->dma_cap.fpesel is added before calling stmmac_fpe_link_state_handle()
as onl
On the x86 platform, we encountered the following problems. The kernel version
we are using is 3.10. The following is our analysis process, hoping to get your
help.
kernel panic at timerqueue_add+32.The stack information is as follows.
crash> bt -c 3
PID: 27797 TASK: 9f9e28805f40 CPU
On Wed, Mar 17, 2021 at 9:32 AM Arnd Bergmann wrote:
> > > > > wrote:
> > > > > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov
> > > > > > > wrote:
> > > > > > > > The compiler is gcc version 10.2.1 20210110 (Debian
On Wed, Mar 17, 2021 at 8:52 AM Dmitry Vyukov wrote:
> On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov wrote:
> > > On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann wrote:
> > > > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann wrote:
>
> On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov wrote:
> >
> > On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann wrote:
> > >
> > > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > > wrote:
> > > > On Tue, Mar 16, 2021 at 04:4
On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov wrote:
>
> On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann wrote:
> >
> > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > On Tue, Mar 16, 2021 at 11:
On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann wrote:
>
> On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> wrote:
> > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov wrote:
> > > > The compiler is gcc version 10.2
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
wrote:
> On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov wrote:
> > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> >
> > Ok, building with Ubuntu 10.
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
wrote:
>
> On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov wrote:
> > > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann wrote:
> > > > > On Tue, Mar 16, 2021 at 8:18 AM
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov wrote:
> > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann wrote:
> > > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> >
> > > > > [<8073772c>] (integrity_kernel_read) from [<8073a904>]
> >
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov wrote:
> On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann wrote:
> > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
>
> > > > [<8073772c>] (integrity_kernel_read) from [<8073a904>]
> > > > (ima_calc_file_hash_tfm+0x178/0x228
> > > > security/integrity/ima/
On Tue, 16 Mar 2021 at 11:04, Arnd Bergmann wrote:
>
> On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov wrote:
> >
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:1e28eed1 Linux 5.12-rc3
> > > git
On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:1e28eed1 Linux 5.12-rc3
> > > git tree: upstream
> > > console output: https://syzkalle
On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov wrote:
>
> On Tue, Mar 16, 2021 at 8:18 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:1e28eed1 Linux 5.12-rc3
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log
On Tue, Mar 16, 2021 at 10:24 AM Russell King - ARM Linux admin
wrote:
>
> On Tue, Mar 16, 2021 at 08:59:17AM +0100, Dmitry Vyukov wrote:
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:1e28eed1
On Tue, Mar 16, 2021 at 08:59:17AM +0100, Dmitry Vyukov wrote:
> On Tue, Mar 16, 2021 at 8:18 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:1e28eed1 Linux 5.12-rc3
> > git tree: upstream
> > console output: https://syzkaller.appspot.co
following tag to the commit:
> Reported-by: syzbot+0b06ef9b44d00d600...@syzkaller.appspotmail.com
+arm32 maintainer
I think this is a real stack overflow on arm32, the stack is indeed deep.
> Kernel panic - not syncing: corrupted stack end detected inside scheduler
> CPU: 0 PID: 3263 Comm: syz
://syzkaller.appspot.com/bug?extid=0b06ef9b44d00d600183
userspace arch: arm
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0b06ef9b44d00d600...@syzkaller.appspotmail.com
Kernel panic - not sy
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
> The kernel stack is not very useful in this case, it's a common faulting
> stack.
> Maybe it will shed some light if you install gdb in the image, attach
> it to the systemd process, then trigger the segfault and then unwind
> stack in the systemd process at the time of fault, dump registers,
>
d(0, buffer, 1);
> return 0;
>
> root@sandbox:~# gcc -pthread repro.c -o repro
> root@sandbox:~# ./repro
> [ 450.676798] got to 221
> [ 450.676881] got to 183
> [ 450.677655] got to 201
> [ 450.678042] got to 208
> [ 450.678349] got to 210
> [ 450.681404] g
98] got to 221
[ 450.676881] got to 183
[ 450.677655] got to 201
[ 450.678042] got to 208
[ 450.678349] got to 210
[ 450.681404] got to 270
[ 450.707100] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[ 450.708393] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
b079466 sp 7ffe972adfc0 error 6 in
systemd[5560fafcd000+ed000]
[ 115.546554] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0 f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[ 115.548575] Kernel panic - n
00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
>> 48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
>> 00 31 c0 f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
>> [9.492637] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x
54 55 53 89 fd
> > 48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
> > 00 31 c0 f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
> > [9.492637] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x000b
>
> Lovely. So somet
8b 04 25 28 00 00 00 48 89 84 24 38 01 00
> 00 31 c0 f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
> [9.492637] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
Lovely. So something in that sequence of syscalls manages to trigger
segfault in unrelat
le_handle __user *ufh,
int open_flag)
{
+ printk(KERN_ERR "got to %d", __LINE__);
long retval = 0;
struct path path;
struct file *file
root@sandbox:~# ./repro
[8.325247] got to 221
[8.325270] got to 183
[ 8.326433] got
On Mon, Mar 08, 2021 at 10:06:10PM +0530, Palash Oswal wrote:
> I was running syzkaller and I found the following issue :
> Head Commit : 27e543cca13fab05689b2d0d61d200a83cfb00b6 ( v5.11.2 )
> Git Tree : stable
>
> Console Logs:
> Kernel panic - not syncing: Attempted to k
I was running syzkaller and I found the following issue :
Head Commit : 27e543cca13fab05689b2d0d61d200a83cfb00b6 ( v5.11.2 )
Git Tree : stable
Console Logs:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2 #13
Hardware name
From: Frank Li
commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.
Fix the problem by adding a pm_runtime_get_sync(), bef
From: Muchun Song
commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream.
printk_safe_flush_on_panic() caused the following deadlock on our
server:
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
From: Muchun Song
commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream.
printk_safe_flush_on_panic() caused the following deadlock on our
server:
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
From: Frank Li
commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.
Fix the problem by adding a pm_runtime_get_sync(), bef
From: Frank Li
commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.
Fix the problem by adding a pm_runtime_get_sync(), bef
From: Muchun Song
commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream.
printk_safe_flush_on_panic() caused the following deadlock on our
server:
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
From: Frank Li
commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.
Fix the problem by adding a pm_runtime_get_sync(), bef
From: Muchun Song
commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream.
printk_safe_flush_on_panic() caused the following deadlock on our
server:
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
From: Frank Li
commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.
Fix the problem by adding a pm_runtime_get_sync(), bef
From: Muchun Song
commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream.
printk_safe_flush_on_panic() caused the following deadlock on our
server:
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
From: Frank Li
commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.
Fix the problem by adding a pm_runtime_get_sync(), bef
From: Muchun Song
commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream.
printk_safe_flush_on_panic() caused the following deadlock on our
server:
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
From: Frank Li
commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.
Fix the problem by adding a pm_runtime_get_sync(), bef
When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount()
causes a kernel panic if the parsed options are valid. The easiest way to
reproduce this is to call mount() from userspace with an existing
eCryptfs mount's options and a "source" argument of 0.
Error
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
On Sun, 21 Feb 2021 21:05:50 -0800 Florian Fainelli wrote:
> On 2/21/2021 17:35, Sieng Piaw Liew wrote:
> > In ndo_stop functions, netdev_completed_queue() is called during forced
> > tx reclaim, after netdev_reset_queue(). This may trigger kernel panic if
> > the
On 2/21/2021 17:35, Sieng Piaw Liew wrote:
In ndo_stop functions, netdev_completed_queue() is called during forced
tx reclaim, after netdev_reset_queue(). This may trigger kernel panic if
there is any tx skb left.
This patch moves netdev_reset_queue() to after tx reclaim, so BQL can
complete
In ndo_stop functions, netdev_completed_queue() is called during forced
tx reclaim, after netdev_reset_queue(). This may trigger kernel panic if
there is any tx skb left.
This patch moves netdev_reset_queue() to after tx reclaim, so BQL can
complete successfully then reset.
Signed-off-by: Sieng
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
On 2/10/2021 8:55 AM, Nicolas Saenz Julienne wrote:
> Hi Robin,
>
> On Wed, 2021-02-10 at 16:25 +, Robin Murphy wrote:
>> On 2021-02-10 13:15, Nicolas Saenz Julienne wrote:
>>> [ Add Robin, Catalin and Florian in case they want to chime in ]
>>>
>>> Hi Juerg, thanks for the report!
>>>
>>>
On Wed 2021-02-10 11:48:23, Muchun Song wrote:
> printk_safe_flush_on_panic() caused the following deadlock on our
> server:
>
> CPU0: CPU1:
> panic rcu_dump_cpu_stacks
> kdump_nmi_shootdown_cpus
Hi Robin,
On Wed, 2021-02-10 at 16:25 +, Robin Murphy wrote:
> On 2021-02-10 13:15, Nicolas Saenz Julienne wrote:
> > [ Add Robin, Catalin and Florian in case they want to chime in ]
> >
> > Hi Juerg, thanks for the report!
> >
> > On Wed, 2021-02-10 at 11:48 +0100, Juerg Haefliger wrote:
>
x11: d2ea1c8765e0 x10:
[ 62.857741] x9 : d2ea1b9495a0 x8 : 4e34429ef980
[ 62.857746] x7 : 000f x6 : 4e34422a004b
[ 62.857751] x5 : fff9 x4 : 00000000
[ 62.857757] x3 : d2ea1b949550 x2 : d2ea1b949330
[ 62.857761] x1 :
000105c3d3c x20: 0014
> > [ 62.857715] x19: 4e344037a900 x18: 0020
> > [ 62.857720] x17: x16:
> > [ 62.857725] x15: 4e3447ac40f0 x14: 0003
> > [ 62.857730] x13: ffff4e34422c0000 x12: 4e
e34422a004b
> [ 62.857751] x5 : 0000fff9 x4 :
> [ 62.857757] x3 : d2ea1b949550 x2 : d2ea1b949330
> [ 62.857761] x1 : 0014 x0 :
> [ 62.857767] Kernel panic - not syncing: Asynchronous SError Interrupt
> [ 62.857770
:
[ 62.857767] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 62.857770] CPU: 1 PID: 478 Comm: cat Not tainted 5.11.0-rc7 #4
[ 62.857773] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[ 62.857775] Call trace:
[ 62.85] dump_backtrace+0x0/0x1e0
[ 62.857778
On (21/02/10 11:48), Muchun Song wrote:
> printk_safe_flush_on_panic() caused the following deadlock on our
> server:
>
> CPU0: CPU1:
> panic rcu_dump_cpu_stacks
> kdump_nmi_shootdown_cpus nmi_tr
printk_safe_flush_on_panic() caused the following deadlock on our
server:
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus nmi_trigger_cpumask_backtrace
register_nmi_handler(cra
On (21/02/09 10:19), Petr Mladek wrote:
> On Sat 2021-02-06 13:41:24, Muchun Song wrote:
[..]
> What about the following commit message? It uses imperative language
> and explains that the patch just prevents the deadlock. It removes
> some details. The diagram is better than many words.
>
>
>
On (21/02/09 09:39), Petr Mladek wrote:
> > > So then this never re-inits the safe_read_lock?
>
> Yes, but it will also not cause the deadlock.
Right.
> I prefer this approach. It is straightforward because it handles
> read_lock the same way as logbuf_lock.
I'm fine with that approach, but thi
On Tue, Feb 9, 2021 at 5:19 PM Petr Mladek wrote:
>
> On Sat 2021-02-06 13:41:24, Muchun Song wrote:
> > We found a deadlock bug on our server when the kernel panic. It can be
> > described in the following diagram.
> >
> > CPU0:
On Sat 2021-02-06 13:41:24, Muchun Song wrote:
> We found a deadlock bug on our server when the kernel panic. It can be
> described in the following diagram.
>
> CPU0: CPU1:
> panic rcu_
t; > On (21/02/06 13:41), Muchun Song wrote:
> > > > > We found a deadlock bug on our server when the kernel panic. It can be
> > > > > described in the following diagram.
> > > > >
> > > > > CPU0:
(driver?)
>> 0109 4096 ram9
>> (driver?)
>> 010a4096 ram10
>> (driver?)
>> 010b4096 ram11
>> (driver?)
>> 010c4096 ram12
>> (driver?)
>> 010d4096 ram13
>> (driver?)
>>
On Mon, Feb 8, 2021 at 9:12 PM Sergey Senozhatsky
wrote:
>
> On (21/02/08 16:49), Muchun Song wrote:
> > On Mon, Feb 8, 2021 at 2:38 PM Sergey Senozhatsky
> > wrote:
> > >
> > > On (21/02/06 13:41), Muchun Song wrote:
> > > > We found a deadlock bu
t; 010b4096 ram11
> (driver?)
> 010c 4096 ram12
> (driver?)
> 010d4096 ram13
> (driver?)
> 010e4096 ram14
> (driver?)
> 010f4096 ram15
> (driver?)
> 1f00 128 mtdblock0
> (driver?)
> Kern
er?)
1f00 128 mtdblock0
(driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc6-next-20210208-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Tr
On (21/02/08 16:49), Muchun Song wrote:
> On Mon, Feb 8, 2021 at 2:38 PM Sergey Senozhatsky
> wrote:
> >
> > On (21/02/06 13:41), Muchun Song wrote:
> > > We found a deadlock bug on our server when the kernel panic. It can be
> > > described in the
On Mon, Feb 8, 2021 at 2:38 PM Sergey Senozhatsky
wrote:
>
> On (21/02/06 13:41), Muchun Song wrote:
> > We found a deadlock bug on our server when the kernel panic. It can be
> > described in the following diagram.
> >
> > CPU0:
On (21/02/06 13:41), Muchun Song wrote:
> We found a deadlock bug on our server when the kernel panic. It can be
> described in the following diagram.
>
> CPU0: CPU1:
> panic rcu_
We found a deadlock bug on our server when the kernel panic. It can be
described in the following diagram.
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
On Fri, Feb 5, 2021 at 7:09 PM Petr Mladek wrote:
>
> Hi,
>
> first, I am sorry for the late reply. I have been somehow distracted
> this week.
>
> On Mon 2021-02-01 18:26:01, Muchun Song wrote:
> > We found a deadlock bug on our server when the kernel panic. It
Hi,
first, I am sorry for the late reply. I have been somehow distracted
this week.
On Mon 2021-02-01 18:26:01, Muchun Song wrote:
> We found a deadlock bug on our server when the kernel panic. It can be
> described in the following diagram.
>
We found a deadlock bug on our server when the kernel panic. It can be
described in the following diagram.
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus
repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.
Detect and avoid this endless loop.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
Signed-off-by: Kalle Valo
Link:
https://lore.kernel.org/r/iwlwifi.20201107104557
repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.
Detect and avoid this endless loop.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
Signed-off-by: Kalle Valo
Link:
https://lore.kernel.org/r/iwlwifi.20201107104557
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
2.524218] FS: () GS:96fe37b0()
knlGS:
[2.525591] CS: 0010 DS: ES: CR0: 80050033
[2.528401] CR2: 7f0508d7c000 CR3: 800232ff8000 CR4: 00340ee0
[ 2.530155] Kernel panic - not syncing: Fatal exception
[
7b0()
knlGS:
[2.525591] CS: 0010 DS: ES: CR0: 80050033
[2.528401] CR2: 7f0508d7c000 CR3: 800232ff8000 CR4: 00340ee0
[ 2.530155] Kernel panic - not syncing: Fatal exception
[2.531145] Kernel Offset: 0x1900 from 0x
repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.
Detect and avoid this endless loop.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
Signed-off-by: Kalle Valo
Link:
https://lore.kernel.org/r/iwlwifi.20201107104557
repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.
Detect and avoid this endless loop.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
Signed-off-by: Kalle Valo
Link:
https://lore.kernel.org/r/iwlwifi.20201107104557
1 - 100 of 1539 matches
Mail list logo
