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
Date: Thu, 31 Mar 2022 08:11:55 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.21.2203301406450.22465@angie.orcam.me.uk> (raw)
In-Reply-To: <CAHk-=wg_Kyh4zVmBSc4H79jH+yv9wN7dMsf-5x=EDrORbL3fuQ@mail.gmail.com>
On Mon, 21 Mar 2022, Linus Torvalds wrote:
> > - Handle the IRT routing table format in AMI BIOSes correctly
>
> *Very* minor nit here in the hope of future cleanups: the other x86
> irq routing table structions (Christ, that's a sentence that shouldn't
> exist in a sane world) use "__attribute__((packed))" and this one uses
> "__packed".
I have reviewed and reverified the code for resubmission now and frankly
I don't know where this "__packed" artefact has come from. I certainly
have "__attribute__((packed))" in all my copies of the change including
one I have submitted (though `checkpatch.pl' does want it indeed to be
`__packed' instead).
Also accessing memory beyond __va(0x100000) does not appear to crash on
my 32-bit x86 machine, so it must be something specific to x86-64. Not an
excuse for a range overrun of course, but still odd (and as I previously
mentioned I find it odd too that this code is ever run for x86-64 in the
first place).
Finally, following your suggestion I have added verification for a range
overrun for the whole table for both the existing $PIR format and the new
$IRT format. It isn't a big deal and we shouldn't trust external sources
of data.
Maciej
next prev parent reply other threads:[~2022-03-31 7:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 11:02 [GIT pull] core/core for v5.18-rc1 Thomas Gleixner
2022-03-21 11:02 ` [GIT pull] irq/core " Thomas Gleixner
2022-03-21 20:12 ` pr-tracker-bot
2022-03-21 11:02 ` [GIT pull] timers/core " Thomas Gleixner
2022-03-21 20:12 ` pr-tracker-bot
2022-03-21 11:02 ` [GIT pull] x86/irq " Thomas Gleixner
2022-03-21 19:17 ` Linus Torvalds
2022-03-21 19:27 ` Linus Torvalds
2022-03-21 21:37 ` Thomas Gleixner
2022-03-23 21:23 ` Maciej W. Rozycki
2022-03-31 7:11 ` Maciej W. Rozycki [this message]
2022-03-21 11:02 ` [GIT pull] x86/pasid " Thomas Gleixner
2022-03-21 20:12 ` pr-tracker-bot
2022-03-21 19:47 ` [GIT pull] core/core " Linus Torvalds
2022-03-21 20:12 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.2203301406450.22465@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=dmitry.osipenko@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.