Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 23 Mar 2022 21:23:44 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Linus Torvalds <torvalds@linux-foundation.org>
cc:     Thomas Gleixner <tglx@linutronix.de>,
        Dmitry Osipenko <dmitry.osipenko@collabora.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [GIT pull] x86/irq for v5.18-rc1
In-Reply-To: <CAHk-=wg_Kyh4zVmBSc4H79jH+yv9wN7dMsf-5x=EDrORbL3fuQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2203232114180.52439@angie.orcam.me.uk>
References: <164786042536.122591.4459156564791679956.tglx@xen13> <164786043041.122591.4693682080153649212.tglx@xen13> <CAHk-=wg_Kyh4zVmBSc4H79jH+yv9wN7dMsf-5x=EDrORbL3fuQ@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Mon, 21 Mar 2022, Linus Torvalds wrote:

> Because that stupid IRT routing table code already been reported to cause bugs:
> 
>     https://lore.kernel.org/all/a2791312-2957-27e6-43af-c805bbb90266@collabora.com/
> 
> which seems to be because the $IRT signature check is complete garbage:
> 
> > +       for (addr = (u8 *)__va(0xf0000); addr < (u8 *)__va(0x100000); addr++) {
> > +               rt = pirq_convert_irt_table(addr);
> > +               if (rt)
> > +                       return rt;
> 
> The above doesn't seem like it could really ever have been tested
> properly, since it will walk off the end of that __va(0x100000)
> address: it will walk every byte up to the 1MB physical address, and
> it will try to find that $IRT signature there, but if it never finds
> it, IT WILL CHECK THE SIGNATURE PAST THE 1MB mark!

 Drat!  I did verify this code in a simulated environment that does supply 
a $IRT table (for a reporter who has an actual system; I'm not lucky 
enough to have one), however somehow I didn't think of verifying it with a 
setup that has neither a $PIR nor a $IRT table.  Therefore this issue has 
slipped ($PIR scanner works in 16-byte intervals, so it escapes the range
overrun), and then of course things started moving only while I am away 
enjoying Italian mountains.  Oh well, nobody's perfect.

 Thanks for narrowing this down, I'll post a fixed version on or shortly 
after this coming weekend.  And sorry for the mess-up!

  Maciej