[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1904051926350.1802@nanos.tec.linutronix.de>
Date: Fri, 5 Apr 2019 19:47:14 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Josh Poimboeuf <jpoimboe@...hat.com>
cc: Sean Christopherson <sean.j.christopherson@...el.com>,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [patch V2 03/29] x86/irq/64: Remove a hardcoded irq_stack_union
access
On Fri, 5 Apr 2019, Josh Poimboeuf wrote:
> On Fri, Apr 05, 2019 at 09:37:27AM -0700, Sean Christopherson wrote:
> > On Fri, Apr 05, 2019 at 05:07:01PM +0200, Thomas Gleixner wrote:
> > > - irq_stack_top = (u64)this_cpu_ptr(irq_stack_union.irq_stack) +
> > > - STACK_TOP_MARGIN;
> > > irq_stack_bottom = (u64)__this_cpu_read(irq_stack_ptr);
> > > + irq_stack_top = irq_stack_bottom - IRQ_STACK_SIZE + STACK_TOP_MARGIN;
> >
> > Not introduced in this patch, but the names for top and bottom are flipped,
> > both for irq_stack and estack. STACK_TOP_MARGIN should also be
> > STACK_BOTTOM_MARGIN. The actual checks are functionally correct, but holy
> > hell does it make reading the code confusing, and the WARN prints backwards
> > information.
>
> I agree, but... one man's top is another man's bottom. Especially when
> stacks grow physically down (as defined by Intel) but conceptually up
> (as defined by every CS algorithms class ever).
That's where they explain that stack concept with stacking of porcelain
plates, which causes the association of shards when the stack is turned
around. Right?
Thankfully I got never exposed to that.
/me runs
Powered by blists - more mailing lists