RE: [PATCH 1/3] alarmtimer: Replace the spinlock rtcdev_lock withmutex

[Thomas Gleixner]

On Thu, 1 Nov 2012, Liu, Chuansheng wrote:
> > From: Oliver Neukum [mailto:oneukum@xxxxxxx]
> > On Thursday 01 November 2012 00:20:55 Chuansheng Liu wrote:
> > > When do code reviewing, found no special requirement to
> > > use spin_lock_irqsave/spin_unlock_irqrestore, because
> > > alarmtimer_get_rtcdev() is called by posix clock interface.
> > > So would like to use mutex to replace it.
> > 
> > What is gained thereby?
> spin_lock_irqsave will disable the preempt and local irq, it is expensive than
> mutex. Thanks.

Let's have a look at how expensive that is. The function which is
relevant is alarmtimer_get_rtcdev(), which does:

        spin_lock_irqsave(&rtcdev_lock, flags);
        ret = rtcdev;
        spin_unlock_irqrestore(&rtcdev_lock, flags);
        return ret;

So now you make rtcdev_lock a mutex, which means that for a single
protected instruction i.e "ret = rtcdev" you want to use a
serialization mechanism which is way more expensive when it actually
comes to a contention.

Now we could debate this back and forth, but this is pointless as your
code review missed the real issue:

 "Protecting" the dereferencing of rtcdev with any kind of lock does
 not provide any useful protection at all.

Lets look at the code which manipulates rtcdev.

The only function which does that is alarmtimer_rtc_add_device(). This
function only can set the pointer ONCE. Now that function needs a
serialization and again we can debate whether this needs to be a
spinlock or a mutex. So now that we know that a device which has been
registered with that function can never go away and is never going to
change, it's completely pointless to have a lock in
alarmtimer_get_rtcdev() at all.

It's safe to do in any code path which wants to use rtcdev:

     if (!rtcdev)
     	return -ENODEV:
     do_something(rtcdev);

Thanks,

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