linux-kernel - Re: [RFC v3 2/3] kernel/time/clockevents: make setting of ->mult and ->mult

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] [day] [month] [year] [list]

Date:	Thu, 21 Jul 2016 12:31:08 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Nicolai Stange <nicstange@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v3 2/3] kernel/time/clockevents: make setting of ->mult and
 ->mult_mono atomic

On Thu, Jul 21, 2016 at 12:24 PM, Nicolai Stange <nicstange@...il.com> wrote:
> John Stultz <john.stultz@...aro.org> writes:
>
>> On Wed, Jul 13, 2016 at 6:00 AM, Nicolai Stange <nicstange@...il.com> wrote:
>>> In order to avoid races between setting a struct clock_event_device's
>>> ->mult_mono in clockevents_update_freq() and yet to be implemented updates
>>> triggered from the timekeeping core, the setting of ->mult and ->mult_mono
>>> should be made atomic.
>>>
>>> Protect the update in clockevents_update_freq() by locking the
>>> clockevents_lock spinlock. Frequency updates are expected to be done
>>> seldomly and thus, taking this subsystem lock should not have any impact
>>> on performance.
>>>
>>> Use a raw_spin_lock_irq_save()/raw_spin_unlock_irq_restore() pair for
>>> locking/unlocking the clockevents_lock spinlock.
>>> Purge the now redundant local_irq_save()/local_irq_restore() pair from
>>> clockevents_update_freq(). Since the call to tick_broadcast_update_freq()
>>> isn't done with interrupts disabled anymore,  its
>>> raw_spin_lock()/raw_spin_unlock() pair must be converted to
>>> raw_spin_lock_irq_save()/raw_spin_unlock_irq_restore().
>>>
>>> Signed-off-by: Nicolai Stange <nicstange@...il.com>
>>> ---
>>>  kernel/time/clockevents.c    | 7 ++++---
>>>  kernel/time/tick-broadcast.c | 5 +++--
>>>  2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
>>> index ba7fea4..ec01375 100644
>>> --- a/kernel/time/clockevents.c
>>> +++ b/kernel/time/clockevents.c
>>> @@ -589,11 +589,12 @@ int clockevents_update_freq(struct clock_event_device *dev, u32 freq)
>>>         unsigned long flags;
>>>         int ret;
>>>
>>> -       local_irq_save(flags);
>>>         ret = tick_broadcast_update_freq(dev, freq);
>>> -       if (ret == -ENODEV)
>>> +       if (ret == -ENODEV) {
>>> +               raw_spin_lock_irqsave(&clockevents_lock, flags);
>>>                 ret = __clockevents_update_freq(dev, freq);
>>> -       local_irq_restore(flags);
>>> +               raw_spin_unlock_irqrestore(&clockevents_lock, flags);
>>> +       }
>>>         return ret;
>>>  }
>>>
>>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
>>> index f6aae79..9c94c41 100644
>>> --- a/kernel/time/tick-broadcast.c
>>> +++ b/kernel/time/tick-broadcast.c
>>> @@ -125,11 +125,12 @@ int tick_is_broadcast_device(struct clock_event_device *dev)
>>>  int tick_broadcast_update_freq(struct clock_event_device *dev, u32 freq)
>>>  {
>>>         int ret = -ENODEV;
>>> +       unsigned long flags;
>>>
>>>         if (tick_is_broadcast_device(dev)) {
>>> -               raw_spin_lock(&tick_broadcast_lock);
>>> +               raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
>>>                 ret = __clockevents_update_freq(dev, freq);
>>> -               raw_spin_unlock(&tick_broadcast_lock);
>>> +               raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
>>>         }
>>
>>
>> So not necessarily part of your change, but this makes using
>> tick_broadcast_update_freq() seem strange.
>>
>> We call it and if dev is a broadcast_device we call
>> __clockevents_update_freq(), and if not, it fails and we then just
>> call __clockevents_update_freq() again?
>
> Yes, but the first call is made under a different lock than the second
> one.

Ah. Thanks, that bit didn't stick out to me.

-john