Re: Possible race in cpia.c?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



videodev.c holds the Big Kernel Lock while calling the drivers' open() callbacks. So, this race cannot happen.

Note that with Gerd's V4L redesign, I'm fairly sure that this race *can* happen if the driver doesn't replace this check with video_exclusive_open(), or protect it with a semaphore. This is because the V4L layer doesn't have the open() wrapper function that it used to have.

Gerd, can you make sure that your cpia patch fixes this?

Joe Burks wrote:

I noticed the following code in cpia.c:

static int cpia_open(struct video_device *dev, int flags)
{
   int i;
   struct cam_data *cam = dev->priv;

   if (!cam) {
       DBG("Internal error, cam_data not found!\n");
       return -EBUSY;
   }

   if (cam->open_count > 0) {
       DBG("Camera already open\n");
       return -EBUSY;
   }

Is it possible (although extremely unlikely) that two processes could try and open a device at the same time and both of them believe that cam->open_count == 0 ? If so, given the unlikely nature of this possibility, should it be a concern?



--
Mark McClelland
mmcclell@xxxxxxxxxxx







[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux