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:	Tue, 27 May 2008 22:37:01 -0400
From:	Andy Walls <awalls@...ix.net>
To:	Devin Heitmueller <devin.heitmueller@...il.com>
Cc:	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Alan Cox <alan@...hat.com>, video4linux-list@...hat.com,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] video4linux: Push down the BKL

On Tue, 2008-05-27 at 20:46 -0400, Devin Heitmueller wrote:
> Hello Andy,
> 
> On Tue, May 27, 2008 at 7:48 PM, Andy Walls <awalls@...ix.net> wrote:
> > MythTV's mythbackend can open both sides of the card at the same time
> > and the cx18 driver supports it.  On my HVR-1600, MythTV may have the
> > digital side of the card open pulling EPG data off of the ATSC
> > broadcasts, when I open up the MythTV frontend and start watching live
> > TV on the analog side of the card.  MythTV also supports
> > Picture-in-Picture using both the analog and digital parts of the
> > HVR-1600.
> 
> In this case, what you see as a 'feature' in MythTV is actually a
> problem in our case.  While the HVR-1600 can support this scenario,
> the HVR-950 can only use one or the other (the em28xx chip uses GPIOs
> to enable the demodulator and presumably you should never have both
> demodulators enabled at the same time).  Because of this we need a
> lock.  If MythTV only opened one device or the other at a time, we
> could put the lock on the open() call, but since MythTV opens both
> simultaneously even though it may only be using one, we would need a
> much more granular lock.

I don't think a lock would be good for MythTV or any other app that
open()s multiple nodes at once.  How can an app know that it's
dead-locking or barring itself via the kernel driver?

Maybe return an EBUSY or E-something else for these cases when Myth
tries to open() the second device node, when there's an underlying
factor that requires things to be mutually exclusive.  Allowing things
like read() to allow hardware mode switching between analog and digital
seems like it could result in really weird behaviors at the application.

I'll cite a precedent:
ivtv returns EBUSY on open() when there's a conflict with it's various
analog devices nodes that depend on the same underlying hardware: MPG,
YUV, FM Radio, etc.

I note the man page for open() doesn't list EBUSY as a valid errno.
However, the V4L2 API Spec does list EBUSY as a valid errno for V4L2
open().

> Certainly I'm not blaming MythTV for this behavior, but it will make
> the locking much more complicated in some hybrid devices.

I like to blame MythTV for a lot of things. ;)

But in this case I can't.  The driver probably shouldn't hold a lock and
suspend an open() indefinitely (IMO).  It should say the device is BUSY
as that is the truth: an underlying hardware device or resource is busy.

Regards,
Andy

--
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/