Laurent Pinchart wrote: >> One typical problem that I see is that some drivers register too soon: they >> first register, then initialize some things. I've seen (and fixed) some >> race conditions due to that. Just moving the register to the end solves >> this issue. > > That's right, devices should not be registered until they are ready to be > opened by userspace. However, I don't see how that's related to the BKL. Before the BKL changes, open were allowed only after the full module loading. >> One (far from perfect) solution, would be to add a mutex protecting the >> entire ioctl loop inside the drivers, and the open/close methods. This can >> later be optimized by a mutex that will just protect the operations that >> can actually cause problems if happening in parallel. > > The BKL protects both open() and ioctl(), but the ioctl operation can't be > called before open succeeds anyway, so I'm not sure we have a problem there. You may have, as one file handler may be doing an ioctl, while another application opens or closes another file handler. Depending on what the driver have on the open handler, it might interfere on the ioctl. > The real problem is that most drivers rely on ioctls being serialized by the > BKL. The drivers need to be fixed on a case by case basis, but we could > already drop the BKL there by using a V4L-specific lock to serialize ioctl > calls. Yes, that's my point. It is not hard to write such patch, moving from BKL to an ioctl/open/close mutex, and it should be safe, provided that it doesn't introduce any dead lock with some existing mutexes. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
