On Mon, Jun 4, 2018 at 4:34 PM, Dmitry Vyukov wrote:
> On Tue, May 29, 2018 at 7:45 PM, Xin Long wrote:
>> On Wed, May 30, 2018 at 1:06 AM, Marcelo Ricardo Leitner
>> wrote:
>>> On Tue, May 29, 2018 at 12:03:46PM -0400, Neal Cardwell wrote:
On Tue, May 29, 2018 at 11:45 AM Marcelo Ricardo L
On Tue, May 29, 2018 at 7:45 PM, Xin Long wrote:
> On Wed, May 30, 2018 at 1:06 AM, Marcelo Ricardo Leitner
> wrote:
>> On Tue, May 29, 2018 at 12:03:46PM -0400, Neal Cardwell wrote:
>>> On Tue, May 29, 2018 at 11:45 AM Marcelo Ricardo Leitner <
>>> marcelo.leit...@gmail.com> wrote:
>>> > - patch
On Wed, May 30, 2018 at 01:45:08AM +0800, Xin Long wrote:
> If we're counting on max_t to fix this CPU stuck. It should not that
> matter if min rto < the value causing that stuck.
Yes but putting a floor to rto_{min,max} now is to protect the rtx
timer now, not the heartbeat one.
>
> >
> > Anyw
On Wed, May 30, 2018 at 1:06 AM, Marcelo Ricardo Leitner
wrote:
> On Tue, May 29, 2018 at 12:03:46PM -0400, Neal Cardwell wrote:
>> On Tue, May 29, 2018 at 11:45 AM Marcelo Ricardo Leitner <
>> marcelo.leit...@gmail.com> wrote:
>> > - patch2 - fix rtx attack vector
>> >- Add the floor value to
On Tue, May 29, 2018 at 12:03:46PM -0400, Neal Cardwell wrote:
> On Tue, May 29, 2018 at 11:45 AM Marcelo Ricardo Leitner <
> marcelo.leit...@gmail.com> wrote:
> > - patch2 - fix rtx attack vector
> >- Add the floor value to rto_min to HZ/20 (which fits the values
> > that Michael shared o
On Tue, May 29, 2018 at 11:45 AM Marcelo Ricardo Leitner <
marcelo.leit...@gmail.com> wrote:
> - patch2 - fix rtx attack vector
>- Add the floor value to rto_min to HZ/20 (which fits the values
> that Michael shared on the other email)
I would encourage allowing minimum RTO values down to
On Tue, May 29, 2018 at 03:06:06PM +0200, Michael Tuexen wrote:
> > On 29. May 2018, at 13:41, Neil Horman wrote:
> >
> > On Mon, May 28, 2018 at 04:43:15PM -0300, Marcelo Ricardo Leitner wrote:
> >> On Sat, May 26, 2018 at 09:01:00PM -0400, Neil Horman wrote:
> >>> On Sat, May 26, 2018 at 05:50:
> On 29. May 2018, at 13:41, Neil Horman wrote:
>
> On Mon, May 28, 2018 at 04:43:15PM -0300, Marcelo Ricardo Leitner wrote:
>> On Sat, May 26, 2018 at 09:01:00PM -0400, Neil Horman wrote:
>>> On Sat, May 26, 2018 at 05:50:39PM +0200, Dmitry Vyukov wrote:
On Sat, May 26, 2018 at 5:42 PM, Mic
On Mon, May 28, 2018 at 04:43:15PM -0300, Marcelo Ricardo Leitner wrote:
> On Sat, May 26, 2018 at 09:01:00PM -0400, Neil Horman wrote:
> > On Sat, May 26, 2018 at 05:50:39PM +0200, Dmitry Vyukov wrote:
> > > On Sat, May 26, 2018 at 5:42 PM, Michael Tuexen
> > > wrote:
> > > >> On 25. May 2018, at
On Sat, May 26, 2018 at 09:01:00PM -0400, Neil Horman wrote:
> On Sat, May 26, 2018 at 05:50:39PM +0200, Dmitry Vyukov wrote:
> > On Sat, May 26, 2018 at 5:42 PM, Michael Tuexen
> > wrote:
> > >> On 25. May 2018, at 21:13, Neil Horman wrote:
> > >>
> > >> On Sat, May 26, 2018 at 01:41:02AM +0800,
On Sun, May 27, 2018 at 10:58:35AM +0200, Michael Tuexen wrote:
...
> >>> Patch looks fine, you probably want to note this hard minimum in man(7)
> >>> sctp as
> >>> well
> >>>
> >> I'm aware of some signalling networks which use RTO.min of smaller values
> >> than 200ms.
> >> So could this be r
> On 26. May 2018, at 17:50, Dmitry Vyukov wrote:
>
> On Sat, May 26, 2018 at 5:42 PM, Michael Tuexen
> wrote:
>>> On 25. May 2018, at 21:13, Neil Horman wrote:
>>>
>>> On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
syzbot reported a rcu_sched self-detected stall on CPU which i
On Sat, May 26, 2018 at 05:50:39PM +0200, Dmitry Vyukov wrote:
> On Sat, May 26, 2018 at 5:42 PM, Michael Tuexen
> wrote:
> >> On 25. May 2018, at 21:13, Neil Horman wrote:
> >>
> >> On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
> >>> syzbot reported a rcu_sched self-detected stall on
On Sat, May 26, 2018 at 5:42 PM, Michael Tuexen
wrote:
>> On 25. May 2018, at 21:13, Neil Horman wrote:
>>
>> On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
>>> syzbot reported a rcu_sched self-detected stall on CPU which is caused
>>> by too small value set on rto_min with SCTP_RTOINF
> On 25. May 2018, at 21:13, Neil Horman wrote:
>
> On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
>> syzbot reported a rcu_sched self-detected stall on CPU which is caused
>> by too small value set on rto_min with SCTP_RTOINFO sockopt. With this
>> value, hb_timer will get stuck there
On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
> syzbot reported a rcu_sched self-detected stall on CPU which is caused
> by too small value set on rto_min with SCTP_RTOINFO sockopt. With this
> value, hb_timer will get stuck there, as in its timer handler it starts
> this timer again wi
syzbot reported a rcu_sched self-detected stall on CPU which is caused
by too small value set on rto_min with SCTP_RTOINFO sockopt. With this
value, hb_timer will get stuck there, as in its timer handler it starts
this timer again with this value, then goes to the timer handler again.
This problem
17 matches
Mail list logo
