On 13 Mar 2015, at 14:57, Christos Zoulas <[email protected]> wrote:
> On Mar 13, 1:08pm, [email protected] ("J. Hannken-Illjes") wrote: > -- Subject: Re: DoS attack against TCP services > > | 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. > > I guess I can clamp the ccb timeout to 60 seconds... Good. > | > | > 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. > > Can't it just try to acquire the lock and if it fails it spams, and > does not deadlock? Or even better, finds the driver that blocks it, > and bumps its timeout? It is annoying to have a monitoring service > DoS the whole machine... Suppose sysmon should use a second mutex for workqueue management only. This way it should be possible to detect a non-empty workqueue, print a message and stop adding new work. -- J. Hannken-Illjes - [email protected] - TU Braunschweig (Germany)
