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.DEB.2.21.1901161550460.1749@nanos.tec.linutronix.de>
Date:   Wed, 16 Jan 2019 15:57:28 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     Valentin Schneider <valentin.schneider@....com>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Mark Rutland <mark.rutland@....com>,
        Julien Thierry <julien.thierry@....com>
Subject: Re: preempt_schedule_irq() loop question

On Wed, 16 Jan 2019, Peter Zijlstra wrote:
> On Wed, Jan 16, 2019 at 12:50:42PM +0000, Valentin Schneider wrote:
> > Hi,
> > 
> > I've been wandering around preempt_schedule_irq() in sched/core.c, and
> > got curious regarding how the arch code calls it.
> > 
> > The main part of preempt_schedule_irq() is:
> > 
> >     do {
> > 	    preempt_disable();
> > 	    local_irq_enable();
> > 	    __schedule(true);
> > 	    local_irq_disable();
> > 	    sched_preempt_enable_no_resched();
> >     } while (need_resched());
> > 
> > Yet all the arch entry.S I looked at (I stopped after arm64, arm, x86_32,
> > MIPS, powerpc) wrap the call to preempt_schedule_irq() in another
> > 
> >     do { ... } while (need_resched())
> > 
> > For instance, this is what's done in arm64:
> > 
> >     1:	bl	preempt_schedule_irq		// irq en/disable is done inside
> > 	ldr	x0, [tsk, #TSK_TI_FLAGS]	// get new tasks TI_FLAGS
> > 	tbnz	x0, #TIF_NEED_RESCHED, 1b	// needs rescheduling?
> > 
> > 
> > I naively thought this could be attributed to something like
> > preempt_schedule_irq() historically not having an inner loop, but it seems
> > to have been there since the beginning of time (or at least up to the point
> > where the git history stops).
> > 
> > I don't see why we need to have these nested loops - AFAICT the one in
> > preempt_schedule_irq() would suffice. What am I missing?
> 
> I think you're quite right; but I wasn't doing kernel work back when rml
> added the preemptible bits. Ingo, do you have any recollections that far
> back?

I just went back in the history tree and had to figure out that it's my
fault :)

preempt_schedule_irq() was introduced to plug a stupid race, but I did not
notice (and obviously nobody else) that this made the extra loop in the
entry code pointless. So it's just histerical raisins without any value.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ