Re: [PATCH[] netfilter: use per-cpu reader-writer lock (v0.7)

Linus Torvalds
2009-04-16T21:12:26Z

On Thu, 16 Apr 2009, Stephen Hemminger wrote:
>
> This version of x_tables (ip/ip6/arp) locking uses a per-cpu
> rwlock that can be nested. It is sort of like earlier brwlock
> (fast reader, slow writer). The locking is isolated so future improvements
> can concentrate on measuring/optimizing xt_table_info_lock. I tried
> other versions based on recursive spin locks and sequence counters and
> for me, the risk of inventing own locking primitives not worth it at this time.

This is stil scary.

Do we guarantee that read-locks nest in the presense of a waiting writer
on another CPU? Now, I know we used to (ie readers always nested happily
with readers even if there were pending writers), and then we broke it. I
don't know that we ever unbroke it.

IOW, at least at some point we deadlocked on this (due to trying to be
fair, and not lettign in readers while earlier writers were waiting):

CPU#1 CPU#2

read_lock

write_lock
.. spins with write bit set, waiting for
readers to go away ..

recursive read_lock
.. spins due to the write bit
being. BOOM: deadlock ..

Now, I _think_ we avoid this, but somebody should double-check.

Also, I have still yet to hear the answer to why we care about stale
counters of dead rules so much that we couldn't just free them later with
RCU.

Linus