On Wed, Oct 18, 2006 at 05:39:52PM +0100, Alan Cox wrote: > > The current user is limited to a two-second delay and the one I'm > > proposing introducing is a delay measued in milli- or microseconds. > > An extra two-second delay while you BIST your IPR device and change > > modes in X at the same time (does X really scan all devices when it's > > changing mode settings? That's odd) doesn't strike me as a huge failure. > > X scans all the devices when it sets up so only a video device one would > hang mid mode set. OK. So the only possible X interaction currently is a D-state transition. > > You fail the operation if it returns busy. Or you loop. It's really up > > to you, the driver author. You know what operation you're trying to do, > > you know what makes more sense. > > But I've no idea who, what or why and that makes it hard to handle. If > the thing refcounts then if there are two reasons to be blocked we are > fine and the last reason goes away we resume - it does make it more easy > to make mistakes. If it isnt ref counting I'd prefer block repeated is a > BUG() not a "driver figure this out" Thinking about this a bit more, we only *need* to block userspace from accessing a device while it's going to cause lockups if we access the device. And we'll cause the lockup ourselves if we try to do more than one of these operations at a time. So BUG_ON is clearly the right approach. Of course, the backtrace might well finger the wrong culprit -- if someone forgot to release the block earlier, it'll catch the second attempt rather than the missed (or infinitely delayed) unblock. I don't think it matters too much, and I don't see a nice way to capture the other task (do a backtrace to a buffer somewhere in a special debug mode ...?)
