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]

Message-ID: <412bdbff0805271947h23f71911vb8f13c76ffb7c6d2@mail.gmail.com>
Date:	Tue, 27 May 2008 22:47:42 -0400
From:	"Devin Heitmueller" <devin.heitmueller@...il.com>
To:	"Andy Walls" <awalls@...ix.net>
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

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

Pardon me for not being clear.  I wasn't suggesting having a mutex for
on the open call itself.  The mutex we have in the em28xx driver is
only in place when we are *switching* between modes.  The thinking was
to have open return EBUSY if the device is already in use in the other
mode, but we weren't sure if that would cause problems with MythTV
(since the open call would fail)  If MythTV can gracefully handle that
scenario, then that would be the ideal solution from a driver
perspective.

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

Yeah, this was just me not being clear.

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
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/