All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>, Alan Cox <alan@redhat.com>,
	video4linux-list@redhat.com, linux-kernel@vger.kernel.org,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] video4linux: Push down the BKL
Date: Tue, 27 May 2008 17:24:46 -0300	[thread overview]
Message-ID: <20080527172446.6f856f21@gaivota> (raw)
In-Reply-To: <20080527125041.0fc28fd4@infradead.org>

On Tue, 27 May 2008 12:50:41 -0700
Arjan van de Ven <arjan@infradead.org> wrote:

> On Tue, 27 May 2008 15:59:42 -0300
> Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> 
> > On Tue, 27 May 2008 10:37:55 -0600
> > Jonathan Corbet <corbet@lwn.net> wrote:
> > 
> > > On Tue, 27 May 2008 13:31:00 -0300
> > > Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> > > 
> > > > Since the other methods don't explicitly call BKL (and, AFAIK,
> > > > kernel open handler don't call it neither), if a program 1 is
> > > > opening a device and initializing some data, and a program 2
> > > > starts doing ioctl, interrupting program 1 execution in the
> > > > middle of a data initialization procedure, you may have a race
> > > > condition, since some devices initialize some device global data
> > > > during open [1].
> > > 
> > > In fact, 2.6.26 and prior kernels *do* acquire the BKL on open (for
> > > char devices) - that's the behavior that the bkl-removal tree is
> > > there to do away with.  So, for example, I've pushed that
> > > acquisition down into video_open() instead. 
> > > 
> > > So, for now, open() is serialized against ioctl() in video
> > > drivers.  As soon as you take the BKL out of ioctl(), though, that
> > > won't happen, unless the mutex you use is also acquired in the open
> > > path.
> > 
> > Ok.
> > 
> > A few drivers seem to be almost read to work without BKL. 
> > 
> > For example, em28xx has already a lock at the operations that change
> > values at "dev" struct, including open() method. However, since the
> > lock is not called at get operations, it needs to be fixed. I would
> > also change it from mutex to a read/write semaphore, since two (or
> > more) get operations can safely happen in parallel.
> > 
> \
> 
> please don't use rw/sems just because there MIGHT be parallel.
> THey're more expensive than mutexes by quite a bit and you get a lot
> less checking from lockdep. They make sense for very specific, very
> read biased, contended cases. But please don't use them "just
> because"...
> 
Good point. The nature of get operations on V4L are not worthy enough to justify
the loss of lockdep checking.

Cheers,
Mauro

WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Alan Cox <alan@redhat.com>,
	video4linux-list@redhat.com, linux-kernel@vger.kernel.org,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH] video4linux: Push down the BKL
Date: Tue, 27 May 2008 17:24:46 -0300	[thread overview]
Message-ID: <20080527172446.6f856f21@gaivota> (raw)
In-Reply-To: <20080527125041.0fc28fd4@infradead.org>

On Tue, 27 May 2008 12:50:41 -0700
Arjan van de Ven <arjan@infradead.org> wrote:

> On Tue, 27 May 2008 15:59:42 -0300
> Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> 
> > On Tue, 27 May 2008 10:37:55 -0600
> > Jonathan Corbet <corbet@lwn.net> wrote:
> > 
> > > On Tue, 27 May 2008 13:31:00 -0300
> > > Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> > > 
> > > > Since the other methods don't explicitly call BKL (and, AFAIK,
> > > > kernel open handler don't call it neither), if a program 1 is
> > > > opening a device and initializing some data, and a program 2
> > > > starts doing ioctl, interrupting program 1 execution in the
> > > > middle of a data initialization procedure, you may have a race
> > > > condition, since some devices initialize some device global data
> > > > during open [1].
> > > 
> > > In fact, 2.6.26 and prior kernels *do* acquire the BKL on open (for
> > > char devices) - that's the behavior that the bkl-removal tree is
> > > there to do away with.  So, for example, I've pushed that
> > > acquisition down into video_open() instead. 
> > > 
> > > So, for now, open() is serialized against ioctl() in video
> > > drivers.  As soon as you take the BKL out of ioctl(), though, that
> > > won't happen, unless the mutex you use is also acquired in the open
> > > path.
> > 
> > Ok.
> > 
> > A few drivers seem to be almost read to work without BKL. 
> > 
> > For example, em28xx has already a lock at the operations that change
> > values at "dev" struct, including open() method. However, since the
> > lock is not called at get operations, it needs to be fixed. I would
> > also change it from mutex to a read/write semaphore, since two (or
> > more) get operations can safely happen in parallel.
> > 
> \
> 
> please don't use rw/sems just because there MIGHT be parallel.
> THey're more expensive than mutexes by quite a bit and you get a lot
> less checking from lockdep. They make sense for very specific, very
> read biased, contended cases. But please don't use them "just
> because"...
> 
Good point. The nature of get operations on V4L are not worthy enough to justify
the loss of lockdep checking.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

  reply	other threads:[~2008-05-27 20:25 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-22 21:37 [PATCH] video4linux: Push down the BKL Alan Cox
2008-05-22 21:37 ` Alan Cox
2008-05-23  2:08 ` Andy Walls
2008-05-23  2:08   ` Andy Walls
2008-05-23  6:16   ` Hans Verkuil
2008-05-23  6:16     ` Hans Verkuil
2008-05-23  6:28     ` Hans Verkuil
2008-05-23  6:28       ` Hans Verkuil
2008-05-26 16:39     ` Mauro Carvalho Chehab
2008-05-26 16:39       ` Mauro Carvalho Chehab
2008-05-23  9:09   ` Alan Cox
2008-05-23  9:09     ` Alan Cox
2008-05-26 16:34     ` Mauro Carvalho Chehab
2008-05-26 16:34       ` Mauro Carvalho Chehab
2008-05-26 16:46       ` Hans Verkuil
2008-05-26 16:46         ` Hans Verkuil
2008-05-26 21:14         ` Mauro Carvalho Chehab
2008-05-26 21:14           ` Mauro Carvalho Chehab
2008-06-01  2:34         ` [PATCH] cx18: convert driver to video_ioctl2() (Re: [PATCH] video4linux: Push down the BKL) Andy Walls
2008-06-01 10:15           ` Hans Verkuil
2008-06-01 19:01             ` Andy Walls
2008-06-03 21:20               ` Mauro Carvalho Chehab
2008-06-03 22:08                 ` [ivtv-devel] " Alan Cox
2008-06-04  0:44                   ` Andy Walls
2008-06-04 10:02                     ` Alan Cox
2008-05-23 13:56 ` [PATCH] video4linux: Push down the BKL Jonathan Corbet
2008-05-23 15:39   ` Alan Cox
2008-05-23 15:39     ` Alan Cox
2008-05-23 16:09     ` Jonathan Corbet
2008-05-23 18:58       ` Alan Cox
2008-05-23 18:58         ` Alan Cox
2008-05-23 19:05 ` Hans Verkuil
2008-05-23 19:05   ` Hans Verkuil
2008-05-25 23:46 ` Mike Isely
2008-05-25 23:46   ` Mike Isely
2008-05-26 16:59 ` Mauro Carvalho Chehab
2008-05-26 16:59   ` Mauro Carvalho Chehab
2008-05-26 20:23   ` Alan Cox
2008-05-26 20:23     ` Alan Cox
2008-05-26 21:10     ` Mauro Carvalho Chehab
2008-05-26 21:10       ` Mauro Carvalho Chehab
2008-05-26 22:01       ` Alan Cox
2008-05-26 22:01         ` Alan Cox
2008-05-27 13:10         ` Mauro Carvalho Chehab
2008-05-27 13:10           ` Mauro Carvalho Chehab
2008-05-27 15:41           ` Jonathan Corbet
2008-05-27 16:31             ` Mauro Carvalho Chehab
2008-05-27 16:31               ` Mauro Carvalho Chehab
2008-05-27 16:37               ` Jonathan Corbet
2008-05-27 18:59                 ` Mauro Carvalho Chehab
2008-05-27 18:59                   ` Mauro Carvalho Chehab
2008-05-27 19:26                   ` Devin Heitmueller
2008-05-27 19:26                     ` Devin Heitmueller
2008-05-27 21:00                     ` Mauro Carvalho Chehab
2008-05-27 21:00                       ` Mauro Carvalho Chehab
2008-05-27 21:22                       ` Devin Heitmueller
2008-05-27 21:22                         ` Devin Heitmueller
2008-05-27 23:48                       ` Andy Walls
2008-05-27 23:48                         ` Andy Walls
2008-05-28  0:46                         ` Devin Heitmueller
2008-05-28  0:46                           ` Devin Heitmueller
2008-05-28  2:37                           ` Andy Walls
2008-05-28  2:37                             ` Andy Walls
2008-05-28  2:47                             ` Devin Heitmueller
2008-05-28  2:47                               ` Devin Heitmueller
2008-05-28 23:30                               ` Andy Walls
2008-05-28  8:34                             ` Alan Cox
2008-05-28  8:34                               ` Alan Cox
2008-05-28  6:13                           ` Hans Verkuil
2008-05-28  6:13                             ` Hans Verkuil
2008-05-27 19:50                   ` Arjan van de Ven
2008-05-27 20:24                     ` Mauro Carvalho Chehab [this message]
2008-05-27 20:24                       ` Mauro Carvalho Chehab
2008-05-27 18:14               ` Alan Cox
2008-05-27 18:14                 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080527172446.6f856f21@gaivota \
    --to=mchehab@infradead.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=alan@redhat.com \
    --cc=arjan@infradead.org \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.