On 13 Mar 2015, at 13:03, Christos Zoulas <[email protected]> wrote:
> On Mar 13, 1:00pm, [email protected] ("J. Hannken-Illjes") wrote: > -- Subject: Re: DoS attack against TCP services > > | This would be simple, changing dev/ic/ciss.c like: > | > | sc->sc_sme->sme_name =3D device_xname(sc->sc_dev); > | sc->sc_sme->sme_cookie =3D sc; > | sc->sc_sme->sme_refresh =3D ciss_sensor_refresh; > | + sc->sc_sme->sme_events_timeout =3D 60; > | > | should do the job. Unfortunately I have no hardware to test. > > Yes, but is 60 enough? Leaving the calculation to each driver > is potentially dangerous. Could we make it self adjusting? This was just an idea ... Maybe ...xs..timeout * sc->maxunits + 10 and set xs timeout to 1 .. 5 seconds? I don't think it is possible to make it self adjusting as the sysmon framework doesn't know the drivers timeouts. > | > Nevertheless, I think that the big problem with ciss is now > | > fixed (i.e. it will not hang forever anymore)... > | > | It may still wait longer than 30 seconds with the sme_mutex held > | leading to deadlock. > | > | We should use a suitable xs timeout vs. events timeout to make it safe, > | either increase the event timeout or decrease the xs timeout. > > It would be nice if it was safe by default, and it should spam the > kernel if it was late so that we know about it... Unfortunately it may deadlock BEFORE it finds a non-empty workqueue. -- J. Hannken-Illjes - [email protected] - TU Braunschweig (Germany)
