CODEWITHSUNDEEP
linux-kernelsynchronizationnetfilterrcuconntrack
ManE
ManE

Reputation: 21

is possble protecting _____nf_conntrack_find() return value by RCU?

I wonder nf_conntrack_find_get() that really protect ct pointer by RCU in linux kernel.

Read-Copy-Update(RCU) can protect to access(read) node rcu_read_side critical section when node is updating. But, it is not mean protect node.

nf_conntrack_find_get() call ___nf_conntrack_find. __nf_conntrack_find returned h (rcu potioner).

But another process can access same h and free(h).

In this time, eventually I think ct is not protected.

h is used calculate to offset and get ct pointer.

Could we think h or ct is safe?

Below is the code..

/net/netfilter/nf_conntrack_core.c: 

__nf_conntrack_find_get() {

    rcu_read_lock();

    h = ____nf_conntrack_find(net, zone, tuple, hash);
    if (h) {
        // RCU can't protect free h. only ensures to read old copy.
        // If another processor free same h, h is freed.
        // is really h available next line?

        ct = nf_ct_tuplehash_to_ctrack(h);

        ....
    } 
}
rcu_read_unlock();

I think that if want to protect node(h), have to use call_rcu() instead of directly free in destroy_conntrack().

Upvotes: 1

Views: 244

Answers (1)

ManE
ManE

Reputation: 21

My question is that h could be freed another process then "is h safe?", "if h is safe, how did it works?"

here are answers.

Note that h is same meaning ct in all of context(ct is just calculated by h).

Q. Is h safe?

First, have to define what is meaning "is h safe?"

Generally, "pointer is safe" is meaning that pointer referenced address is accessible and not freed. So if use the pointer or pointer members, can access them without violations.

watch in this context code,

The answer is "h could be freed but not occurred violations!" (wow :O).

If use call_rcu() in destroy_conntrack(), h cannot free util grace-period. but ct is freed directly in destroy_conntrack().

how to protect ct without call_rcu().(even not occurred violation).

The trick is using hlist_nulls(SLAB_TYPESAFE_BY_RCU).

the ct nodes are located SLAB_TYPESAFE_BY_RCU. that memory location is free to be reused at any time.

So, node are consistently have same offset. we can access them even be freed.

Of course, Must be protect few restrictions.(memory barriers, atomic operations, use reference count, check reused nodes...)

more detail information and restrictions you read below link

https://github.com/westerndigitalcorporation/RISC-V-Linux/blob/master/linux/Documentation/RCU/rculist_nulls.txt

Upvotes: 1

Related Questions