[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180605.102339.1043965092278555314.davem@davemloft.net>
Date: Tue, 05 Jun 2018 10:23:39 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: lucien.xin@...il.com
Cc: netdev@...r.kernel.org, linux-sctp@...r.kernel.org,
edumazet@...gle.com, marcelo.leitner@...il.com,
nhorman@...driver.com, dvyukov@...gle.com,
syzkaller@...glegroups.com
Subject: Re: [PATCH net] sctp: not allow transport timeout value less than
HZ/5 for hb_timer
From: Xin Long <lucien.xin@...il.com>
Date: Tue, 5 Jun 2018 12:16:58 +0800
> 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 is there since very beginning, and thanks to Eric for the
> reproducer shared from a syzbot mail.
>
> This patch fixes it by not allowing sctp_transport_timeout to return a
> smaller value than HZ/5 for hb_timer, which is based on TCP's min rto.
>
> Note that it doesn't fix this issue by limiting rto_min, as some users
> are still using small rto and no proper value was found for it yet.
>
> Reported-by: syzbot+3dcd59a1f907245f891f@...kaller.appspotmail.com
> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
> Signed-off-by: Xin Long <lucien.xin@...il.com>
Applied and queued up for -stable, thanks Xin.
Powered by blists - more mailing lists