From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org
Subject: Re: V4L-DVB drivers and BKL
Date: Thu, 01 Apr 2010 11:44:43 -0300 [thread overview]
Message-ID: <4BB4B15B.2040302@redhat.com> (raw)
In-Reply-To: <201004011630.06159.laurent.pinchart@ideasonboard.com>
Laurent Pinchart wrote:
>> One typical problem that I see is that some drivers register too soon: they
>> first register, then initialize some things. I've seen (and fixed) some
>> race conditions due to that. Just moving the register to the end solves
>> this issue.
>
> That's right, devices should not be registered until they are ready to be
> opened by userspace. However, I don't see how that's related to the BKL.
Before the BKL changes, open were allowed only after the full module loading.
>> One (far from perfect) solution, would be to add a mutex protecting the
>> entire ioctl loop inside the drivers, and the open/close methods. This can
>> later be optimized by a mutex that will just protect the operations that
>> can actually cause problems if happening in parallel.
>
> The BKL protects both open() and ioctl(), but the ioctl operation can't be
> called before open succeeds anyway, so I'm not sure we have a problem there.
You may have, as one file handler may be doing an ioctl, while another application
opens or closes another file handler. Depending on what the driver have on the open
handler, it might interfere on the ioctl.
> The real problem is that most drivers rely on ioctls being serialized by the
> BKL. The drivers need to be fixed on a case by case basis, but we could
> already drop the BKL there by using a V4L-specific lock to serialize ioctl
> calls.
Yes, that's my point. It is not hard to write such patch, moving from BKL to an
ioctl/open/close mutex, and it should be safe, provided that it doesn't introduce
any dead lock with some existing mutexes.
--
Cheers,
Mauro
next prev parent reply other threads:[~2010-04-01 16:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-01 8:01 V4L-DVB drivers and BKL Hans Verkuil
2010-04-01 9:23 ` Laurent Pinchart
2010-04-01 11:11 ` Hans Verkuil
2010-04-01 12:11 ` Laurent Pinchart
2010-04-01 14:12 ` Mauro Carvalho Chehab
2010-04-01 14:30 ` Laurent Pinchart
2010-04-01 14:44 ` Mauro Carvalho Chehab [this message]
2010-04-01 14:42 ` Hans Verkuil
2010-04-01 15:02 ` Mauro Carvalho Chehab
2010-04-01 15:27 ` Hans Verkuil
2010-04-01 16:58 ` Devin Heitmueller
2010-04-01 17:36 ` Mauro Carvalho Chehab
2010-04-01 18:29 ` Devin Heitmueller
2010-04-01 18:42 ` Mauro Carvalho Chehab
2010-04-01 18:56 ` Devin Heitmueller
2010-04-01 21:07 ` Mauro Carvalho Chehab
2010-04-01 21:40 ` Devin Heitmueller
2010-04-01 23:10 ` Mauro Carvalho Chehab
2010-04-01 21:11 ` Hans Verkuil
2010-04-01 21:06 ` Hans Verkuil
2010-04-01 21:16 ` Mauro Carvalho Chehab
2010-04-01 21:29 ` Devin Heitmueller
2010-04-03 0:23 ` Andy Walls
2010-04-07 20:07 ` [PATCH] em28xx: fix locks during dvb init sequence - was: " Mauro Carvalho Chehab
2010-04-07 20:15 ` Devin Heitmueller
2010-04-07 20:23 ` Mauro Carvalho Chehab
2010-04-01 11:57 ` Stefan Richter
2010-04-01 12:11 ` Hans Verkuil
2010-04-01 12:08 ` Stefan Richter
2010-04-01 12:12 ` Stefan Richter
2010-04-01 14:03 ` Mauro Carvalho Chehab
2010-04-03 14:19 ` Stefan Richter
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=4BB4B15B.2040302@redhat.com \
--to=mchehab@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/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