Re: Process Hang in __read_seqcount_begin

From: Thomas Gleixner
Date: Fri Oct 26 2012 - 16:53:04 EST


On Fri, 26 Oct 2012, Peter LaDow wrote:
> (I've added netfilter and linux-rt-users to try to pull in more help).
>
> On Fri, Oct 26, 2012 at 9:48 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
> > Upstream kernel is fine, there is no race, as long as :
> >
> > local_bh_disable() disables BH and preemption.
>
> Looking at the unpatched code in net/ipv4/netfilter/ip_tables.c, it
> doesn't appear that any of the code checks the return value for
> xt_write_receq_begin to determine if it is safe to write. And neither
> does the newly patched code. How did the mainline code prevent
> corruption of the tables it is updating?
>
> Why isn't there something like:
>
> while ( (addend = xt_write_recseq_begin()) == 0 );
>
> To make sure that only one person has write access to the tables?
> Better yet, why not use a seqlock_t instead?
>
> > Apparently RT changes this, so RT needs to change the code.
>
> The RT patch only touches local_bh_disable/enable, not the code in
> ip_tables.c. Does the local_bh_disable/enable in the mainline code
> protect against multiple writers?
>
> > cmpxchg() has strong guarantees (and is also slower than upstream code),
> > and seems a reasonable way to fix RT/iptables
>
> I see this now. And I agree that your patch would prevent corruption
> of the sequence counter.

Thanks for the reminder. I'll have a look.

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/