[linux-dvb] [PATCH] dvb-core: Fix several locking related problems.

Markus Rechberger mrechberger at gmail.com
Sat Mar 10 11:12:42 CET 2007


On 3/5/07, Simon Arlott <simon at fire.lp0.eu> wrote:
> On Mon, March 5, 2007 11:19, Johannes Stezenbach wrote:
> > On Mon, Mar 05, 2007 at 01:58:14AM +0100, Oliver Endriss wrote:
> >> Simon Arlott wrote:
> >> > Is any part of the patch going to be applied? I mentioned this
> >> > problem in September last year and it looks like it's existed for
> >> > years (the semaphore locking did the same thing).
> >>
> >> Well, I hoped that someone more familiar with the demuxer stuff would
> >> comment on the patch. I am not very happy about using non-interruptible
> >> lock operations...
>
> Why? If there are deadlocks these should be fixed, not ignored.
>
> >> Anyway, I'll apply the patch to HG master if you submit an updated patch:
> >> - Please add a line of comment to each mutex_lock() stating _why_ the
> >>   non-interruptible lock has to be used at this place.
>
> What's the point of doing that?
>
> > IMHO using mutex_lock_interruptible() is almost always wrong.
> >
> > The only use it has in dvb-core is to recover from locking bugs --
> > if it deadlocks you can Ctrl-C out of it
> > (instead of being left with a non-killable program -> reboot).
>
> This is what lockdep is for.
>

just as a small note here, lockdep doesn't support mutex/semaphore
based lockups. I figured out such a bug in the pcmcia subsystem when
ejecting a device with pccardctl eject;

[process1 semaphore got locked] - in the pcmcia framework
[process2 mutex got locked] - in the sysfs framework
[process1 trying to lock mutex]
[process2 trying to lock semaphore]

so I wouldn't always rely on lockdep at the moment.

> > But with mutex_lock_interruptible() it's easy to introduce
> > signal handling bugs, which Simon confirmed to exist.
>
> It's also easy to find examples of people needing to rmmod/modprobe because
> dvr0 started returning -EBUSY on
> open() after they closed something.
>
> > Fixing those up without reverting to mutex_lock() way might
> > be possible, but is more difficult.
>
> It'd introduce lot of unneccessary -ERESTARTSYS, just to avoid the
> possiblity of waiting on mutex_lock for a
> few msecs.
>
> --
> Simon Arlott
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>


-- 
Markus Rechberger



More information about the linux-dvb mailing list