[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230612143523.2408056-1-renmingshuai@huawei.com>
Date: Mon, 12 Jun 2023 22:35:23 +0800
From: renmingshuai <renmingshuai@...wei.com>
To: <vladbu@...dia.com>
CC: <caowangbao@...wei.com>, <davem@...emloft.net>, <edumazet@...gle.com>,
<jhs@...atatu.com>, <jiri@...nulli.us>, <kuba@...nel.org>,
<liaichun@...wei.com>, <linux-kernel@...r.kernel.org>, <liubo335@...wei.com>,
<netdev@...r.kernel.org>, <pabeni@...hat.com>, <renmingshuai@...wei.com>,
<xiyou.wangcong@...il.com>, <yanan@...wei.com>
Subject: Re: [PATCH net] net/sched: cls_api: Fix lockup on flushing explicitly created chain
>On Mon 12 Jun 2023 at 10:59, Pedro Tammela <pctammela@...atatu.com> wrote:
>> On 12/06/2023 06:34, Vlad Buslov wrote:
>>> Mingshuai Ren reports:
>>> When a new chain is added by using tc, one soft lockup alarm will be
>>> generated after delete the prio 0 filter of the chain. To reproduce
>>> the problem, perform the following steps:
>>> (1) tc qdisc add dev eth0 root handle 1: htb default 1
>>> (2) tc chain add dev eth0
>>> (3) tc filter del dev eth0 chain 0 parent 1: prio 0
>>> (4) tc filter add dev eth0 chain 0 parent 1:
>>> Fix the issue by accounting for additional reference to chains that are
>>> explicitly created by RTM_NEWCHAIN message as opposed to implicitly by
>>> RTM_NEWTFILTER message.
>>> Fixes: 726d061286ce ("net: sched: prevent insertion of new classifiers during
>>> chain flush")
>>> Reported-by: Mingshuai Ren <renmingshuai@...wei.com>
>>> Closes: https://lore.kernel.org/lkml/87legswvi3.fsf@nvidia.com/T/
>>> Signed-off-by: Vlad Buslov <vladbu@...dia.com>
>>> ---
>>> net/sched/cls_api.c | 12 +++++++-----
>>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>>
>> Hi Vlad,
>>
>> Thanks for taking a look.
>> Could you also carry over the tdc test or ask Ren to post in a separate patch?
>
>Sure. I was planning to ask Mingshuai Ren to submit the new test as
>standalone patch after my fix has been accepted since including his code
>with my fix would require explicit approval of the whole patch and his
>Signed-off-by clause AFAIK.
OK. I will submit the new test as standalone patch after your fix is been accepted.
Powered by blists - more mailing lists