race condition in char driver

It's contention possible, but only a race condition if there is actually a "race". Two readers probably don't cause contention or race, but two writers probabaly do, and simultaneous read/write might.

Do you want this gadget to be a shared resource? Do you care? Will your application code ever try to do two things at once?

If it is sufficient to just prevent two processes/applications from opening the device at tha same time, use an exclusive open flat. Set it on open, clear it on release, and if a process calls open when it is already set, return an error. That handles contention.

Proctect the exclusive open flag with some kind of locking mechanism, like a semaphore, for instance. That handles the race.

You can do this separately for open for read and for write if that's useful.

I do it thusly in one of my drivers:

(init code)

spin_lock_init(&unit_p->open_lock);

(open)

/* * Only allow a single open */

spin_lock(&unit_p->open_lock); if (unit_p->unit_open != 0) { DPRINTI("open called when already open!"); spin_unlock(&unit_p->open_lock); return -EBUSY; }

unit_p->unit_open = 1; spin_unlock(&unit_p->open_lock);

(close)

unit_p->unit_open = 0;

Is that what you had in mind?

Bill

On Fri, 09 Apr 2010 06:45:58 -0700, Bill Waddington

It's contention possibly, but only a race condition if there is actually a "race". Two readers probably don't cause contention or race, but two writers probabaly do, and simultaneous read/write might.

Do you want this gadget to be a shared resource? Do you care? Will your application code ever try to do two things at once?

If it is sufficient to just prevent two processes/applications from opening the device at the same time, use an exclusive open flag. Set it on open, clear it on release, and if a process calls open when it is already set, return an error. That handles contention.

Protect the exclusive open flag with some kind of locking mechanism, like a semaphore, for instance. That handles the race for the open flag.

You can do this separately for open for read and for write if that's useful.

I do it thusly in one of my drivers:

(init code)

spin_lock_init(&unit_p->open_lock);

(open)

/* * Only allow a single open */

spin_lock(&unit_p->open_lock); if (unit_p->unit_open != 0) { DPRINTI("open called when already open!"); spin_unlock(&unit_p->open_lock); return -EBUSY; }

unit_p->unit_open = 1; spin_unlock(&unit_p->open_lock);

(close)

unit_p->unit_open = 0;

Is that what you had in mind?

Bill

Not really. File descriptors can be cloned with dup, dup2 and fcntl, sent to other processes utilizing AF_UNIX sockets and inherited by random applications via fork/exec. Arbitrating access to a particular device is a policy descision and because of this, making the descision in user space, for instance, with the help of fcntl-style locks, might be a better idea.

Hmmm. Thanks for that. I've got to contemplate what that means for my drivers. Probably nothing in my particular environment, but it's something to think about.

Bill

It will if you don't use proper locking when your driver when it is performing multi-cycle operations that need to be atomic.

That's when it _may_ happen. You can prevent it with proper locking.

How would we know what the internals of your driver look like?

Presumably the GPIO pins are "shared" (there isn't one copy of the pins for each process that opens the device), so any operations that need to be atomic (e.g. read/modify/write) need to properly serialized.

Bill Waddington wrote: [skip]

So if I understand you right, with this approach, when a user application tries to open the device which is already locked, it will receive EBUSY errno or the like.

Rainer's suggestion to move arbitration entirely on the user level is good too: lock files or similar would work well too.

Thank you very much for the ideas.

Yep.

No clue there. I wonder about _enforcement_ at the user level. Since I don't have any control over the apps that use my drivers, I do what I can at the driver level.

Kind of seems to me that the user space chosing to dup a file descriptor is a choice to allow multiple processes to access the device.

Use whatever suits your driver and application. I'm going to go contemplate Rainer's comments. Old, but not too old to learn. I hope.

Bill

Arguably, the decision is made in user-space in both cases. With the open flag method, a server specifically for this purpose can open the device and then hand over file descriptors to it to any combination of processes it wants to using whatever policy it is coded to use.

Which method is better depends on what you want your user-space code to look like.

DS

The point I was trying to make is that you cannot enforce a usage policy at the driver level and that you shouldn't be trying to, because all you can realistically achieve is to inconvenience people trying to use your driver in ways you didn't foresee.