[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJfuBxw-JUpnENT9zNgTq2wdHqH-77pAjNuthoZYbtiCud4T=g@mail.gmail.com>
Date: Tue, 22 Jun 2021 14:15:52 -0600
From: jim.cromie@...il.com
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: kasan-dev@...glegroups.com, v9fs-developer@...ts.sourceforge.net,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [V9fs-developer] KCSAN BUG report on p9_client_cb / p9_client_rpc
>
> > I had assumed the p9_req_put() in p9_client_cb would protect the tag,
> > but that doesn't appear to be true -- could you try this patch if this
> > is reproductible to you?
> >
>
> I applied your patch on top of my triggering case, it fixes the report !
> you have my tested-by
I seem to have gotten ahead of my skis,
Im seeing another now, similar to 1st, differing in 2nd block
[ 8.730061] Run /bin/sh as init process
[ 9.027218] ==================================================================
[ 9.028237] BUG: KCSAN: data-race in p9_client_cb / p9_client_rpc
[ 9.029073]
[ 9.029282] write to 0xffff888005e45ea0 of 4 bytes by interrupt on cpu 0:
[ 9.030214] p9_client_cb+0x1a/0x100
[ 9.030735] req_done+0xd3/0x130
[ 9.031171] vring_interrupt+0xac/0x130
[ 9.031752] __handle_irq_event_percpu+0x64/0x260
[ 9.032381] handle_irq_event+0x93/0x120
[ 9.032950] handle_edge_irq+0x123/0x400
[ 9.033502] __common_interrupt+0x3e/0xa0
[ 9.034051] common_interrupt+0x7e/0xa0
[ 9.034608] asm_common_interrupt+0x1e/0x40
[ 9.035173] native_safe_halt+0xe/0x10
[ 9.035826] default_idle+0xa/0x10
[ 9.036299] default_idle_call+0x38/0xc0
[ 9.036845] do_idle+0x1e7/0x270
[ 9.037294] cpu_startup_entry+0x19/0x20
[ 9.037905] rest_init+0xd0/0xd2
[ 9.038354] arch_call_rest_init+0xa/0x11
[ 9.038922] start_kernel+0xacb/0xadd
[ 9.039444] secondary_startup_64_no_verify+0xc2/0xcb
[ 9.040140]
[ 9.040369] read to 0xffff888005e45ea0 of 4 bytes by task 1 on cpu 1:
[ 9.041283] p9_client_rpc+0x185/0x860
[ 9.041837] p9_client_getattr_dotl+0x71/0x160
[ 9.042645] v9fs_inode_from_fid_dotl+0x21/0x160
[ 9.043418] v9fs_vfs_lookup.part.0+0x139/0x180
[ 9.044059] v9fs_vfs_lookup+0x32/0x40
[ 9.044584] __lookup_slow+0xc3/0x190
[ 9.045095] walk_component+0x1b8/0x270
[ 9.045626] link_path_walk.part.0.constprop.0+0x336/0x550
[ 9.046425] path_lookupat+0x59/0x340
[ 9.046935] filename_lookup+0x134/0x2a0
[ 9.047484] user_path_at_empty+0x6d/0x90
[ 9.048145] vfs_statx+0x79/0x1a0
[ 9.048610] __do_sys_newfstatat+0x1e/0x40
[ 9.049173] __x64_sys_newfstatat+0x4e/0x60
[ 9.049755] do_syscall_64+0x42/0x80
[ 9.050233] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 9.050940]
[ 9.051148] Reported by Kernel Concurrency Sanitizer on:
[ 9.051893] CPU: 1 PID: 1 Comm: virtme-init Not tainted
5.13.0-rc7-dd7i-00038-g4e27591489f1-dirty #126
[ 9.053185] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-3.fc34 04/01/2014
[ 9.054358] ==================================================================
>
> > The tag is actually reclaimed in the woken up p9_client_rpc thread so
> > that would be a good match (reset in the other thread vs. read here),
> > caching the value is good enough but that is definitely not obvious...
> >
> > --
> > Dominique
Powered by blists - more mailing lists