Re: [PATCH] Block on access to temporarily unavailable pci device

Matthew Wilcox
2006-10-18T17:14:21Z

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
...?)