Messages in this thread | | | Date | Wed, 20 Jul 2022 16:13:45 +0100 | From | Will Deacon <> | Subject | Re: [PATCH V2] arm64: fix oops in concurrently setting insn_emulation sysctls |
| |
On Wed, Jul 20, 2022 at 01:23:24PM +0100, Lee Jones wrote: > On Sat, 02 Jul 2022, haibinzhang(张海斌) wrote: > > > How to reproduce: > > launch two shell executions: > > #!/bin/bash > > while [ 1 ]; > > do > > echo 1 > /proc/sys/abi/swp > > done > > > > Oops info: > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 > > Internal error: Oops: 96000006 [#1] SMP > > Call trace: > > update_insn_emulation_mode+0xc0/0x148 > > emulation_proc_handler+0x64/0xb8 > > proc_sys_call_handler+0x9c/0xf8 > > proc_sys_write+0x18/0x20 > > __vfs_write+0x20/0x48 > > vfs_write+0xe4/0x1d0 > > ksys_write+0x70/0xf8 > > __arm64_sys_write+0x20/0x28 > > el0_svc_common.constprop.0+0x7c/0x1c0 > > el0_svc_handler+0x2c/0xa0 > > el0_svc+0x8/0x200 > > > > emulation_proc_handler changes table->data for proc_dointvec_minmax > > and so it isn't allowed to reenter before restoring table->data, > > which isn't right now. > > To fix this issue, keep the table->data as &insn->current_mode and > > use container_of() to retrieve the insn pointer. Another mutex is > > used to protect against the current_mode update but not for retrieving > > insn_emulation as table->data is no longer changing. > > Looks as though this lost its Fixes tag during the rework. > > Fixes: 587064b610c7 ("arm64: Add framework for legacy instruction emulation") > > Will, are you able to add this retroactively?
Sadly, this is now buried under some other patches so I'd have to rebase the branch if I were to add this and I don't think it's worth it just to add a tag. On the plus side, the patch has a Link: tag to this thread, so the Fixes tag is retrievable if you're determined enough.
If somebody wants this for stable, then I suppose they'll have to send a backport to make sure it doesn't get missed.
Will
| |