On 2020/11/5 14:16, Cong Wang wrote:
> On Wed, Nov 4, 2020 at 10:04 PM Cong Wang wrote:
>>
>> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
> From my understanding, we can do anything about the old qdisc (including
> destorying the old qdisc) after some_qdisc_is_busy() return
On 2020/11/5 14:04, Cong Wang wrote:
> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
From my understanding, we can do anything about the old qdisc (including
destorying the old qdisc) after some_qdisc_is_busy() return false.
>>>
>>> But the current code does the reset _before_
On Wed, Nov 4, 2020 at 10:04 PM Cong Wang wrote:
>
> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
> > >> From my understanding, we can do anything about the old qdisc (including
> > >> destorying the old qdisc) after some_qdisc_is_busy() return false.
> > >
> > > But the current code does
On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
> >> From my understanding, we can do anything about the old qdisc (including
> >> destorying the old qdisc) after some_qdisc_is_busy() return false.
> >
> > But the current code does the reset _before_ some_qdisc_is_busy(). ;)
>
> If lock is
On 2020/11/3 0:55, Cong Wang wrote:
> On Fri, Oct 30, 2020 at 12:38 AM Yunsheng Lin wrote:
>>
>> On 2020/10/30 3:05, Cong Wang wrote:
>>>
>>> I do not see how and why it should. synchronize_net() is merely an optimized
>>> version of synchronize_rcu(), it should wait for RCU readers, softirqs are
On 11/2/20 4:08 AM, Yunsheng Lin wrote:
> On 2020/10/30 1:20, Vishwanath Pai wrote:
>> On 10/29/20 6:24 AM, Yunsheng Lin wrote:
>>> On 2020/10/29 12:50, Vishwanath Pai wrote:
On 10/28/20 10:37 PM, Yunsheng Lin wrote:
> On 2020/10/29 4:04, Vishwanath Pai wrote:
>> On 10/28/20 1:47 PM,
On Fri, Oct 30, 2020 at 12:38 AM Yunsheng Lin wrote:
>
> On 2020/10/30 3:05, Cong Wang wrote:
> >
> > I do not see how and why it should. synchronize_net() is merely an optimized
> > version of synchronize_rcu(), it should wait for RCU readers, softirqs are
> > not
> > necessarily RCU readers,
On 2020/10/30 1:20, Vishwanath Pai wrote:
> On 10/29/20 6:24 AM, Yunsheng Lin wrote:
>> On 2020/10/29 12:50, Vishwanath Pai wrote:
>>> On 10/28/20 10:37 PM, Yunsheng Lin wrote:
On 2020/10/29 4:04, Vishwanath Pai wrote:
> On 10/28/20 1:47 PM, Cong Wang wrote:
>> On Wed, Oct 28, 2020 at
On 2020/10/30 3:05, Cong Wang wrote:
> On Wed, Oct 28, 2020 at 7:54 PM Yunsheng Lin wrote:
>>
>> On 2020/9/18 3:26, Cong Wang wrote:
>>> On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
On 2020/9/11 4:07, Cong Wang wrote:
> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin
>
On Wed, Oct 28, 2020 at 7:54 PM Yunsheng Lin wrote:
>
> On 2020/9/18 3:26, Cong Wang wrote:
> > On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
> >>
> >> On 2020/9/11 4:07, Cong Wang wrote:
> >>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin
> >>> wrote:
>
> Currently there is
On 10/29/20 6:24 AM, Yunsheng Lin wrote:
> On 2020/10/29 12:50, Vishwanath Pai wrote:
>> On 10/28/20 10:37 PM, Yunsheng Lin wrote:
>>> On 2020/10/29 4:04, Vishwanath Pai wrote:
On 10/28/20 1:47 PM, Cong Wang wrote:
> On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath
wrote:
>> Hi,
On 2020/10/29 12:50, Vishwanath Pai wrote:
> On 10/28/20 10:37 PM, Yunsheng Lin wrote:
>> On 2020/10/29 4:04, Vishwanath Pai wrote:
>>> On 10/28/20 1:47 PM, Cong Wang wrote:
On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
> Hi,
>
> We noticed some problems when testing the
On 2020/9/18 3:26, Cong Wang wrote:
> On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
>>
>> On 2020/9/11 4:07, Cong Wang wrote:
>>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
Currently there is concurrent reset and enqueue operation for the
same lockless qdisc when
On 10/28/20 10:37 PM, Yunsheng Lin wrote:
> On 2020/10/29 4:04, Vishwanath Pai wrote:
>> On 10/28/20 1:47 PM, Cong Wang wrote:
>>> On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath
wrote:
Hi,
We noticed some problems when testing the latest 5.4 LTS kernel
and traced it
back
On 2020/10/29 4:04, Vishwanath Pai wrote:
> On 10/28/20 1:47 PM, Cong Wang wrote:
>> On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
>>> Hi,
>>>
>>> We noticed some problems when testing the latest 5.4 LTS kernel and traced
>>> it
>>> back to this commit using git bisect. When running our
On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
> Hi,
>
> We noticed some problems when testing the latest 5.4 LTS kernel and traced it
> back to this commit using git bisect. When running our tests the machine stops
> responding to all traffic and the only way to recover is a reboot. I do
On 10/28/20 1:47 PM, Cong Wang wrote:
> On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
>> Hi,
>>
>> We noticed some problems when testing the latest 5.4 LTS kernel and
traced it
>> back to this commit using git bisect. When running our tests the
machine stops
>> responding to all
On 10/28/20, 10:51 AM, "Vishwanath Pai" wrote:
On Thu, Sep 17, 2020 at 4:26 PM Cong Wang wrote:
>
> On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
> >
> > On 2020/9/11 4:07, Cong Wang wrote:
> > > On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin
> > > wrote:
> > >>
> > >> Currently there is
On 9/17/20 3:26 PM, Cong Wang wrote:
> On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin
wrote:
>>
>> On 2020/9/11 4:07, Cong Wang wrote:
>>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin
wrote:
Currently there is concurrent reset and enqueue operation for the
same lockless qdisc
On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
>
> On 2020/9/11 4:07, Cong Wang wrote:
> > On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
> >>
> >> Currently there is concurrent reset and enqueue operation for the
> >> same lockless qdisc when there is no lock to synchronize the
> >>
On 2020/9/11 16:13, Yunsheng Lin wrote:
> On 2020/9/11 4:07, Cong Wang wrote:
>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>>>
>>> Currently there is concurrent reset and enqueue operation for the
>>> same lockless qdisc when there is no lock to synchronize the
>>> q->enqueue() in
On 2020/9/11 4:07, Cong Wang wrote:
> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>>
>> Currently there is concurrent reset and enqueue operation for the
>> same lockless qdisc when there is no lock to synchronize the
>> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
>>
On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by
From: Yunsheng Lin
Date: Tue, 8 Sep 2020 19:02:34 +0800
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by
Currently there is concurrent reset and enqueue operation for the
same lockless qdisc when there is no lock to synchronize the
q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
qdisc_deactivate() called by dev_deactivate_queue(), which may cause
out-of-bounds access for
25 matches
Mail list logo
