netdev - Re: [PATCH net 0/3] Fix Qdisc destroy issues caused by adding fine-grained locking to filter API

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Sep 2019 08:53:23 +0000
From:   Vlad Buslov <vladbu@...lanox.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
CC:     Vlad Buslov <vladbu@...lanox.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH net 0/3] Fix Qdisc destroy issues caused by adding
 fine-grained locking to filter API

On Thu 19 Sep 2019 at 01:50, Cong Wang <xiyou.wangcong@...il.com> wrote:
> On Wed, Sep 18, 2019 at 12:32 AM Vlad Buslov <vladbu@...lanox.com> wrote:
>>
>> TC filter API unlocking introduced several new fine-grained locks. The
>> change caused sleeping-while-atomic BUGs in several Qdiscs that call cls
>> APIs which need to obtain new mutex while holding sch tree spinlock. This
>> series fixes affected Qdiscs by ensuring that cls API that became sleeping
>> is only called outside of sch tree lock critical section.
>
> Sorry I just took a deeper look. It seems harder than just moving it
> out of the critical section.
>
> qdisc_destroy() calls ops->reset() which usually purges queues,
> I don't see how it is safe to move it out of tree spinlock without
> respecting fast path.
>
> What do you think?

Hmm, maybe we can split qdisc destruction in two stage process for
affected qdiscs? Rough sketch:

1. Call qdisc_reset() (or qdisc_purge_queue()) on qdisc that are being
   deleted under sch tree lock protection.

2. Call new qdisc_put_empty() function after releasing the lock. This
   function would implement same functionality as a regular qdisc_put()
   besides resetting the Qdisc and freeing skb in its queues (already
   done by qdisc_reset())

In fact, affected queues already do the same or something similar:

- htb_change_class() calls qdisc_purge_queue() that calls qdisc_reset(),
  which makes reset inside qdisc_destroy() redundant.

- multiq_tune() calls qdisc_tree_flush_backlog() that has the same
  implementation as qdisc_purge_queue() minus actually resetting the
  Qdisc. Can we substitute first function with the second one here?

- sfb_change() - same as multiq_tune().

Do you think that would work?

Also, I'm kind of surprised that it worked before. Even though syzbot
complains about mutex that I added, cls API never honored expectation by
such Qdiscs that tcf_block_put doesn't sleep. From the top of my head
there are several places in the cls code where it has never been the
case: chain head change for ingress/clsact Qdiscs calls
mini_qdisc_pair_swap() which is a sleeping function,
tcf_block_flush_all_chains() eventually calls driver callbacks for any
offloaded filters which may sleep.