From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Date: Tue, 29 May 2018 18:02:57 +0000 Subject: Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs Message-Id: <20180529180257.GE3788@localhost.localdomain> List-Id: References: <71FD541D-25FE-4100-980B-C3A0CEAF6CD4@lurchi.franken.de> <20180527010059.GA15798@neilslaptop.think-freely.org> <20180528194315.GB3788@localhost.localdomain> <20180529114111.GA24144@hmswarspite.think-freely.org> <559FFFDD-E508-4936-9544-CACE606AF40F@lurchi.franken.de> <20180529154514.GC3788@localhost.localdomain> <20180529170604.GD3788@localhost.localdomain> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Xin Long Cc: Neal Cardwell , Michael Tuexen , Neil Horman , Dmitry Vyukov , Netdev , linux-sctp@vger.kernel.org, David Miller , David Ahern , Eric Dumazet , syzkaller 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. > > > > > Anyway, what about we add a floor to rto_max too, so that RTO can > > actually grow into something bigger that don't hog the CPU? Like: > > rto_min floor = 5ms > > rto_max floor = 50ms > > > > Marcelo > -- > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >