Edgar Fuß <[email protected]> wrote: > > If not, calls are serialised under kernel lock and it may not necessary > > have to be reetrant (terms and conditions apply). > I'm sorry to say that I know rather little about these T&Cs. > > > Keep in mind that multi-thread safety and reentrancy are not the same. > I'm afraid I don't get that. > > My application is a scsipi(9) timeout callback. Normally, the same > timeout handler is installed for all requests, and, if I'm extremly > unlucky, two different requests may time out at the same time. > So, if someone enters the timeout handler (which is going to reset the > hardware and loop through all requests, stopping their callouts and > asking scsipi to re-schedule the requests), is it safe to assume that the > timeout handler will not be entered again (on a different CPU, by a > different thread or whatever) until whoever entered it first returns? > If that's not safe to assume, what's the suggested way to guard against > it?
Currently, scsipi(9) is still under the kernel lock, so you do not need to worry about it. When this subsytem will be refactored to be MP-safe, the handler will need to be synchronised using a mutex(9). -- Mindaugas
