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. Bart. -- 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
