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

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.1811140925270.371@nippy.intranet>
Date:   Wed, 14 Nov 2018 09:33:42 +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 APIy

On Tue, 13 Nov 2018, Thomas Gleixner wrote:

> On Wed, 14 Nov 2018, Finn Thain wrote:
> > 
> > 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.
> 
> Urgh. Then you have more serious trouble. If the interrupting handler 
> calls any of the time accessor functions then you can actually live lock 
> when the interrupt happens in the middle of the write locked section of 
> the core timekeeping update.

Does this apply to arch_gettimeoffset also? If so, that would mean another 
bug fix patch for -stable...

> So you really want to disable interrupts across the whole timer 
> interrupt function or make sure that the timer interrupt is the highest 
> priority one on the system.
> 

The timer interrupt priority isn't always what one would hope. 

But I can certainly disable interrupts for timer_interrupt() execution 
(that is, xtime_update() etc.)

-- 

> Thanks,
> 
> 	tglx
>