On Mar 13, 11:19am, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote: -- Subject: Re: DoS attack against TCP services
| The mutex involved is the sme_mtx protecting the struct sysmon_envsys, so | our problem doesn't come from missing POLL. That's what I thought. | We already have it. If I understand sysmon right, it is already based on | workqueues (the ciss0 thread here): | | The workqueue updates sensors every sme->sme_events_timeout seconds, defaul= | t | is 30 seconds. Workqueue items get enqueued from a callout. | | Both running a workqueue item and processing the callout locks the | same mutex sme->sme_mtx. | | For this to work the workqueue must complete before the callout fires: | | sme->sme_nsensors * ccb->ccb_xs->timeout < sme->sme_events_timeout | | In our ciss case we could set: | | sc->sc_sme->sme_events_timeout =3D 30 | | ccb->ccb_xs->timeout=3D 20 / sc->maxunits | | to become safe. | | Hope I got this right so far ... Yes, you do. We could decrease the timeout for probing, but that might lead to unsuccessful sensor reads. Even then perhaps there is a place to have a special mode for sysmon to use a separate thread for reading the sensors of a particular driver, or a way to change the sysmon period to be longer. Nevertheless, I think that the big problem with ciss is now fixed (i.e. it will not hang forever anymore)... christos