Skip to contentSkip to conversation

Kernel v4.19-rc4 KASAN complaint

DISCUSSION Byungchul Park 2 participants 2 messages Oct 8, 2018 2 messages not in the archive NVMe

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

Byungchul Park

author
#2 lore raw
Quoted 11 lines · Paul E. McKenney
Quoted 10 lines

I would expect something like this if someone did a double call_srcu() or passed something to call_srcu() but then kept using it (for an example of the latter, failed to make it inaccessible to readers before invoking call_srcu() on it). Yet another way to get here is to have unioned the rcu_head structure with something used by the SRCU readers.

The double call_srcu() can be located by building your kernel with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y and rerunning your tests. The other two usually require inspection or bisection.

Quoted 5 lines
Quoted 1 line

So, the eternal question: Is bisection feasible?

Looks like I misread the lines pointed to by gdb, and it indeed seems like a premature free of the nvme_ns_head structure, but I fail to see where.

I'm sorry for making a noise if I'm telling something wrong. I'm not familiar with nvme stuff though, I'm just curious about..

Is it ok to call nvme_mpath_clear_current_path(ns) without holding any lock in nvme_failover_req(req)? No possible to race with other rcu_assign_pointer(ns->head->current_path, some_value)?

In other words, has the namespace been serialized when calling nvme_failover_req(req) so as to guarantee that there's no one doing rcu_assign_pointer(ns->head->current_path, some_value) somewhere or so?

Sorry again if I miss something but hope it's helpful. Ignore if so.

Thanks,
Byungchul

Quoted 13 lines

I've tried to bring up Barts testcase but failed so far.

Bart, can you help out a bit?

The last commit of the original merge 4.19 nvme merge is:

b369b30cf510fe94d8884837039362e2ec223cec

Can you check if that shows the problem (I suspect it does) and if so bisect between that and 9b89bc3857a6c0dfda18ddae2a42c114ecc32753, which as the first commit for the merge?

Quoted 1 line

Thanx, Paul

#3 lore raw
Quoted 3 lines · Byungchul Park

Is it ok to call nvme_mpath_clear_current_path(ns) without holding any lock in nvme_failover_req(req)? No possible to race with other rcu_assign_pointer(ns->head->current_path, some_value)?

We can race with an assignment, but it should be harmless, as that call is just an optimization to get everyone to stop using the path ASAP. If we actually free the namespace we always go through nvme_ns_remove, which calls nvme_mpath_clear_current_path under subsys->lock.