linux-kernel - Re: [RFC PATCH 13/13] m68k: mvme16x: Convert to clocksource API

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: <alpine.LNX.2.21.1811132137180.371@nippy.intranet>
Date:   Wed, 14 Nov 2018 09:04:36 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Thomas Gleixner <tglx@...utronix.de>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        Stephen N Chivers <schivers@....com.au>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 13/13] m68k: mvme16x: Convert to clocksource API

On Tue, 13 Nov 2018, I wrote:

> On Mon, 12 Nov 2018, Thomas Gleixner wrote:
> 
> > > +static u32 clk_total;
> > > +
> > > +#define PCC_TIMER_CLOCK_FREQ 1000000
> > > +#define PCC_TIMER_CYCLES     (PCC_TIMER_CLOCK_FREQ / HZ)
> > > +
> > >  static irqreturn_t mvme16x_timer_int (int irq, void *dev_id)
> > >  {
> > > +    irq_handler_t tick_handler = dev_id;
> > > +    unsigned long flags;
> > > +
> > > +    local_irq_save(flags);
> > 
> > No need for local_irq_save() here. Interrupt handlers are guaranteed to be
> > called with interrupts disabled.
> > 
> 
> That's not the case on m68k, as I understand it. However, the CPU 
> interrupt level does prevent interrupt handlers from nesting.
> 

What I mean by that is, the interrupt level (IPL) prevents interrupt 
handlers from being re-entered. But a handler can still get interrupted by 
a higher priority interrupt request. In the past I've had to add defensive 
locking because of this.

In these patches I've assumed it was possible for some higher priority 
interrupt handler to perform a clocksource read after the timer handler 
started executing. Hence the use of local_irq_save/restore.

To be sure, I've just run a quick test and confirmed that the timer 
handler can indeed get interrupted by the ethernet interrupt handler.

--