public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@redhat.com>
To: Andy Walls <awalls@radix.net>
Cc: 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: Fri, 23 May 2008 05:09:19 -0400	[thread overview]
Message-ID: <20080523090919.GA31575@devserv.devel.redhat.com> (raw)
In-Reply-To: <1211508484.3273.86.camel@palomino.walls.org>

On Thu, May 22, 2008 at 10:08:04PM -0400, Andy Walls wrote:
> Could someone give me a brief education as to what elements of
> cx18/ivtv_v4l2_do_ioctl() would be forcing the use of the BKL for these
> drivers' ioctls?   I'm assuming it's not the
> mutex_un/lock(&....->serialize_lock) and that the answer's not in the
> diff.

As it stood previous for historical reasons the kernel called the driver
ioctl method already holding the big kernel lock. That lock effectively
serialized a lot of ioctl processing and also serializes against module
loading and registration/open for the most part. If all the resources you
are working on within the ioctl handler are driver owned as is likely with
a video capture driver, and you have sufficient locking of your own you can
drop the lock.

video_usercopy currently also uses the BKL so you might want to copy a
version to video_usercopy_unlocked() without that.

A small number of other things still depend on the BKL but probably don't
affect a capture driver: Setting file flags and using the deprecated
sleep_on and interruptible_sleep_on. Other things like memory allocators
wait_event, wake_up and the like all do their own locking internally and
that is a model we want to end up at - whether everything has "proper" locking.

You may also find a driver depends on other things (eg video on i2c and you
can't yet prove the i2c (or don't know) is locked entirely privately in
which cases I've ended up leaving the drivers I worked on with

	lock_kernel();
	ret = subsys_some_foo(bar);
	unlock_kernel();

which makes it clear what the remaining problem points are so they can be
revisited.

For a lot of ioctl conversions the big issue is "two ioctls at once in parallel"
which can happen even on a single opener device. The other tends be stuff like
"ioctl versus unplug" although for PCI and many other subsystems the resources
are ref-counted so a pci_dev won't vanish on you without warning.

Alan

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

  parent reply	other threads:[~2008-05-23  9:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-22 21:37 [PATCH] video4linux: Push down the BKL Alan Cox
2008-05-23  2:08 ` Andy Walls
2008-05-23  6:16   ` Hans Verkuil
2008-05-23  6:28     ` Hans Verkuil
2008-05-26 16:39     ` Mauro Carvalho Chehab
2008-05-23  9:09   ` Alan Cox [this message]
2008-05-26 16:34     ` Mauro Carvalho Chehab
2008-05-26 16:46       ` Hans Verkuil
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
     [not found] ` <9027.1211551014@vena.lwn.net>
2008-05-23 15:39   ` [PATCH] video4linux: Push down the BKL Alan Cox
     [not found]     ` <15168.1211558968@vena.lwn.net>
2008-05-23 18:58       ` Alan Cox
2008-05-23 19:05 ` Hans Verkuil
2008-05-25 23:46 ` Mike Isely
2008-05-26 16:59 ` Mauro Carvalho Chehab
2008-05-26 20:23   ` Alan Cox
2008-05-26 21:10     ` Mauro Carvalho Chehab
2008-05-26 22:01       ` Alan Cox
2008-05-27 13:10         ` Mauro Carvalho Chehab
     [not found]           ` <20080527094144.1189826a@bike.lwn.net>
2008-05-27 16:31             ` Mauro Carvalho Chehab
2008-05-27 18:14               ` Alan Cox
     [not found]               ` <20080527103755.1fd67ec1@bike.lwn.net>
2008-05-27 18:59                 ` Mauro Carvalho Chehab
2008-05-27 19:26                   ` Devin Heitmueller
2008-05-27 21:00                     ` Mauro Carvalho Chehab
2008-05-27 21:22                       ` Devin Heitmueller
2008-05-27 23:48                       ` Andy Walls
2008-05-28  0:46                         ` Devin Heitmueller
2008-05-28  2:37                           ` Andy Walls
2008-05-28  2:47                             ` Devin Heitmueller
2008-05-28 23:30                               ` Andy Walls
2008-05-28  8:34                             ` Alan Cox
2008-05-28  6:13                           ` Hans Verkuil
     [not found]                   ` <20080527125041.0fc28fd4@infradead.org>
2008-05-27 20:24                     ` Mauro Carvalho Chehab

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=20080523090919.GA31575@devserv.devel.redhat.com \
    --to=alan@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=awalls@radix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox