netdev - RE: Get rid of RCU callbacks in TC filters?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 23 Oct 2017 11:10:27 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Cong Wang' <xiyou.wangcong@...il.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
CC:     Jamal Hadi Salim <jhs@...atatu.com>,
        Chris Mi <chrism@...lanox.com>,
        "Linux Kernel Network Developers" <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Eric Dumazet <edumazet@...gle.com>,
        David Miller <davem@...emloft.net>,
        Jiri Pirko <jiri@...nulli.us>
Subject: RE: Get rid of RCU callbacks in TC filters?

From: Cong Wang
> Sent: 20 October 2017 21:52
> To: Paul E. McKenney
> Cc: Jamal Hadi Salim; Chris Mi; Linux Kernel Network Developers; Daniel Borkmann; Eric Dumazet; David
> Miller; Jiri Pirko
> Subject: Re: Get rid of RCU callbacks in TC filters?
> 
> On Fri, Oct 20, 2017 at 1:31 PM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> > Actually, I just tried this approach, this way makes the core tc filter
> > code harder to wait for flying callbacks, currently rcu_barrier() is
> > enough, with one more schedule_work() added we probably
> > need flush_workqueue()... Huh, this also means I can't use the
> > global workqueue so should add a new workqueue for tc filters.
> >
> > Good news is I seem to make it work without adding much code.
> > Stay tuned. ;)
> 
> Hmm, lockdep already complains I have a deadlock when flushing
> workqueue while hodling RTNL lock, because callbacks need RTNL
> too... See the rcu_barrier() in tcf_block_put().
> 
> So this approach seems to be a dead end. Is there any way out?
> 
> Probably we have to convert call_rcu() to synchronize_rcu(),
> but with batching of course.

Locking for callbacks is always a PITA.
You also need to sort out how to 'unhook' the callbacks.

If you require the caller hold the rntl_lock prior to adding
or removing callbacks, and guarantee that the functions will
be called with the rntl_lock held you might be ok.

Otherwise the one side can't do its 'expected' locking without
a potential deadlock or use-after-free.

The only way I know to avoid the issues removing the callbacks
is to get the callback function called from its normal scheduling
point with an argument (probably NULL) that indicates it will
never be called again.

	David