linux-kernel - Re: [PATCH] video4linux: Push down the BKL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 May 2008 05:09:19 -0400
From:	Alan Cox <alan@...hat.com>
To:	Andy Walls <awalls@...ix.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, video4linux-list@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] video4linux: Push down the BKL

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/