Hi, On 8/31/2022 8:47 AM, Martin KaFai Lau wrote: > On Tue, Aug 30, 2022 at 10:37:17AM +0800, Hou Tao wrote: >> Hi, >> >> On 8/30/2022 9:13 AM, Martin KaFai Lau wrote: >>> On Mon, Aug 29, 2022 at 10:27:52PM +0800, Hou Tao wrote: >>>> From: Hou Tao <houtao1@xxxxxxxxxx> >>>> >>>> When there are concurrent task local storage lookup operations, >>>> if updates on per-cpu bpf_task_storage_busy is not preemption-safe, >>>> some updates will be lost due to interleave, the final value of >>>> bpf_task_storage_busy will not be zero and bpf_task_storage_trylock() >>>> on specific cpu will fail forever. >>>> >>>> So add a test case to ensure the update of per-cpu bpf_task_storage_busy >>>> is preemption-safe. >>> This test took my setup 1.5 minute to run >>> and cannot reproduce after running the test in a loop. >>> >>> Can it be reproduced in a much shorter time ? >>> If not, test_maps is probably a better place to do the test. >> I think the answer is No. I have think about adding the test in test_maps, but >> the test case needs running a bpf program to check whether the value of >> bpf_task_storage_busy is OK, so for simplicity I add it in test_progs. >> If the running time is the problem, I can move it into test_maps. >>> I assume it can be reproduced in arm with this test? Or it can >>> also be reproduced in other platforms with different kconfig. >>> Please paste the test failure message and the platform/kconfig >>> to reproduce it in the commit message. >> On arm64 it can be reproduced probabilistically when CONFIG_PREEMPT is enabled >> on 2-cpus VM as show below. You can try to increase the value of nr and loop if >> it still can not be reproduced. > I don't have arm64 environment now, so cannot try it out. For arm raw_cpu_add_4 is also not preemption safe, so I think it is also possible. > Please move the test to test_maps. > If it is CONFIG_PREEMPT only, you can also check if CONFIG_PREEMPT > is set or not and skip the test. Take a look at __kconfig usage > under bpf/progs. Will do. > .
