On Fri, 2011-03-25 at 20:49 +0100, Bart Van Assche wrote: > On Fri, Mar 25, 2011 at 8:34 PM, James Bottomley > <James.Bottomley@xxxxxxx> wrote: > > On Fri, 2011-03-25 at 19:44 +0100, Bart Van Assche wrote: > >> On Fri, Mar 25, 2011 at 4:06 PM, James Bottomley > >> <James.Bottomley@xxxxxxx> wrote: > >> > Explain first what lock inversion problems you see ... those usually > >> > only happen if you have the in the kernel upcall thread waiting for > >> > completion. > >> > >> In this context asynchronous upcalls have their problems too: the > >> in-kernel and the user space visible state may become inconsistent. > >> What will happen if processing of such notifications is delayed and > >> concurrently attempts are made from user space to act on these objects > >> ? I'm afraid that could result in horrible race conditions. > > > > What race conditions? The current exemplar is udev which uses the > > uevent mechanism. The usual way of coping with use before init is to > > key visibility off completion ... at least that's the way we do it in > > sysfs. > > A storage target subsystem is more demanding than e.g. udev. As an > example, for the session reassignment logic in SCST it is necessary to > remove and create user space visible objects synchronously and under > lock. Both are necessary - the locking and the synchronous > manipulation of user space objects. I'm not sure it is possible to > convert such an approach to something based on asynchronous userspace > upcalls. Really, no ... this is an example of an a-priori design fault. What it implies is that the user and kernel share locks for state access, which always leads to deadlocks. A correctly separated event driven model shouldn't need state locks across event subsystems. Just because SCST couldn't get it right, doesn't mean that no-one else can. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
