Message-ID: <516106abdf5c922ee19dffd9eb69ea3f9e20e54a.camel@linux.ibm.com>
Date: Mon, 23 Sep 2024 20:26:32 +0530
From: Aboorva Devarajan <aboorvad@...ux.ibm.com>
To: Tejun Heo <tj@...nel.org>
Cc: void@...ifault.com, linux-kernel@...r.kernel.org
Subject: Re: [sched_ext/for-6.11]: Issue with BPF Scheduler during CPU
 Hotplug

On Tue, 2024-09-17 at 14:48 +0200, Tejun Heo wrote:
> Hello, Aboorva.
> 
> On Mon, Aug 26, 2024 at 08:32:03AM -1000, Tejun Heo wrote:
> > On Fri, Aug 23, 2024 at 02:50:01PM +0530, Aboorva Devarajan wrote:
> > ...
> > > I applied this patch to the almost latest sched-ext (for-6.12) branch upto
> > > commit 89909296a51e792 ("sched_ext: Don't use double locking to migrate
> > > tasks across CPUs") and let the test run for over 20 hours, and it completed
> > > without any hangs on both x86 and PowerPC.
> > > 
> > > So, indeed, making sure that both scx_fork_rwsem and cpu_hotplug_lock (read)
> > > are only held together simulataneously when they can both be acquired seems
> > > to be resolving the deadlock.
> > 
> > Thanks a lot for confirming. Let me think it over a bit re. what should be
> > applied.
> 
> Sorry about the delay. It ended up a bit invasive and took longer. Can you
> please verify the following branch fixes the problem?
> 
>  https://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git scx-enable-locking-fix
> 
> Thanks.
> 

Hi Tejun,

I've run CPU hotplug tests and verified that with the above specified branch on both
Power10 and x86 the originally reported hang is no longer seen.

------------------------------------------------------------------------------------------
On x86: 

https://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git scx-enable-locking-fix

Upto - a3b4678ca086 ("sched_ext: Decouple locks in scx_ops_enable()")

I kept the tests running for over 48 hours, and I didn't encounter any hangs or lockups.
------------------------------------------------------------------------------------------

On Power10:

https://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git scx-enable-locking-fix

Upto - a3b4678ca086 ("sched_ext: Decouple locks in scx_ops_enable()") +
Patches to support struct_ops on PowerPC

After running the tests for over 4 hours, I didn’t observe the original issue, but I hit
another crash, which seems specific to PowerPC which is related to instruction patching.
However, the originally reported hang appears to be resolved.
------------------------------------------------------------------------------------------

Sharing the crash logs observed in PowerPC here for general reference, FYI:


[ 8638.891964] Kernel attempted to read user page (a8) - exploit attempt? (uid: 0)
[ 8638.892002] BUG: Kernel NULL pointer dereference on read at 0x000000a8
[ 8638.892019] Faulting instruction address: 0xc0000000004e7cc0
[ 8638.892038] Oops: Kernel access of bad area, sig: 11 [#1]
[ 8638.892060] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
[ 8638.892080] Modules linked in: nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype
br_netfilter xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp
 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 ebtable_filter ebtables vhost_vsock vmw_vsock_virtio_transport_common ip6tabl
e_filter ip6_tables vhost vhost_iotlb iptable_filter vsock bridge stp llc kvm_hv kvm joydev
input_leds mac_hid at24 ofpart cmdlinepart uio_pdrv_genirq ibmpowernv opal_prd ipmi_powernv 
powernv_flash uio binfmt_misc sch_fq_codel nfsd mtd ipmi_devintf ipmi_msghandler auth_rpcgss
jc42 ramoops reed_solomon ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async
_memcpy async_pq async_xor async_tx raid1 raid0 dm_mirror dm_region_hash dm_log mlx5_ib ib_uverbs
ib_core mlx5_core hid_generic usbhid hid ast i2c_algo_bit drm_shmem_helper drm_kms_hel
per vmx_crypto drm mlxfw crct10dif_vpmsum crc32c_vpmsum psample tls tg3 ahci libahci
drm_panel_orientation_quirks
[ 8638.892621] CPU: 62 UID: 0 PID: 5591 Comm: kworker/62:2 Not tainted 6.11.0-rc4+ #2
[ 8638.892663] Hardware name: 8335-GTW POWER9 0x4e1203 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
[ 8638.892693] Workqueue: events bpf_prog_free_deferred
[ 8638.892735] NIP:  c0000000004e7cc0 LR: c0000000004e7bbc CTR: c0000000003a9b30
[ 8638.892798] REGS: c000000ea4cbf7f0 TRAP: 0300   Not tainted  (6.11.0-rc4+)
[ 8638.892862] MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 42a00284  XER: 00000000
[ 8638.892915] CFAR: c0000000004e7bb8 DAR: 00000000000000a8 DSISR: 40000000 IRQMASK: 1 
[ 8638.892915] GPR00: c0000000004e7bbc c000000ea4cbfa90 c000000002837f00 0000000000000005 
[ 8638.892915] GPR04: 0000000000000015 0000000000000009 0000000000000009 c000000004840b00 
[ 8638.892915] GPR08: ffffffffffffffff 00000000ffffe000 ffffffffffffffff 000001937b55db50 
[ 8638.892915] GPR12: 0000000000200000 c000007ffdfac300 c0000000031b1fc8 0000000000010000 
[ 8638.892915] GPR16: c00000000000018e 000000007fffffff 0000000000000000 000000000000e1c0 
[ 8638.892915] GPR20: 61c8864680b583eb 0000000000000000 0000000000000000 00000000000de1d5 
[ 8638.892915] GPR24: 0000000000000000 c000000003da4408 c000000003da4400 c000000003da43f8 
[ 8638.892915] GPR24: 0000000000000000 c000000003da4408 c000000003da4400 c000000003da43f8 
[ 8638.892915] GPR28: 0000000000000000 0000000000000000 0000000000000000 c000000ea4cbfa90 
[ 8638.893350] NIP [c0000000004e7cc0] walk_to_pmd+0x80/0x240
[ 8638.893380] LR [c0000000004e7bbc] __get_locked_pte+0x4c/0xd0
[ 8638.893398] Call Trace:
[ 8638.893407] [c000000ea4cbfa90] [c000000ea4cbfb20] 0xc000000ea4cbfb20 (unreliable)
[ 8638.893429] [c000000ea4cbfaf0] [c0000000004e7bbc] __get_locked_pte+0x4c/0xd0
[ 8638.893457] [c000000ea4cbfb40] [c0000000000b1dd0] patch_instructions+0x130/0x630
[ 8638.893500] [c000000ea4cbfc10] [c000000000123180] bpf_arch_text_invalidate+0x80/0xd0
[ 8638.893552] [c000000ea4cbfc60] [c0000000003a7508] bpf_prog_pack_free+0x138/0x2f0
[ 8638.893584] [c000000ea4cbfd10] [c0000000003a7e38] bpf_jit_binary_pack_free+0x48/0xa0
[ 8638.893617] [c000000ea4cbfd50] [c000000000123258] bpf_jit_free+0x88/0x100
[ 8638.893667] [c000000ea4cbfd90] [c0000000003a9d70] bpf_prog_free_deferred+0x240/0x280
[ 8638.893725] [c000000ea4cbfde0] [c0000000001a6828] process_scheduled_works+0x268/0x520
[ 8638.893767] [c000000ea4cbfee0] [c0000000001a9ed0] worker_thread+0x3f0/0x590
[ 8638.893809] [c000000ea4cbff80] [c0000000001b37b0] kthread+0x1a0/0x1c0
[ 8638.893862] [c000000ea4cbffe0] [c00000000000d030] start_kernel_thread+0x14/0x18
[ 8638.893913] Code: 3cc20157 3b63c4f8 3b45c500 3929c510 3b26c508 3940ffff e87b0000 e8ba0000
81290000 e8d90000 38830010 7d494830 <e87d00a8> 7ce42a14 7d2948f8 7d073214 
[ 8638.894003] ---[ end trace 0000000000000000 ]---
[ 8639.098185] pstore: backend (nvram) writing error (-1)
[ 8639.098205] 
[ 8639.098215] note: kworker/62:2[5591] exited with irqs disabled
[ 8798.806603] ------------[ cut here ]------------
[ 8798.806631] WARNING: CPU: 62 PID: 3769 at kernel/kthread.c:76 kthread_set_per_cpu+0x40/0xd0
[ 8798.806653] Modules linked in: nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype
br_netfilter xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle
ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv
------------------------------------------------------------------------------------------

We will look at this issue as it is specific to PowerPC.

But I can confirm that the originally reported hang (deadlock) is no longer present.

Thanks much,
Aboorva

Powered by blists - more mailing lists