public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vasily Gorbik <gor@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Heiko Carstens <hca@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [GIT PULL] s390 fixes for 6.6-rc7
Date: Mon, 23 Oct 2023 18:09:04 +0200	[thread overview]
Message-ID: <your-ad-here.call-01698077344-ext-9104@work.hours> (raw)
In-Reply-To: <CAHk-=wgTUz1bdY6zvsN4ED0arCLE8Sb==1GH8d0sjm5bu7zesQ@mail.gmail.com>

On Sat, Oct 21, 2023 at 10:56:29AM -0700, Linus Torvalds wrote:
> On Sat, 21 Oct 2023 at 02:44, Vasily Gorbik <gor@linux.ibm.com> wrote:
> > - Fix IOMMU bitmap allocation in s390 PCI to avoid out of bounds access
> >   when IOMMU pages aren't a multiple of 64.

> But that code is wrong, because the overflow is simply not an issue.
> Adding overflow handling code is literally only actively misleading,
> making the code harder to read, for no reason, and making people
> *think* it's being careful when it is anything *but* careful.

Right, I should have done a better job reviewing this patch when picking
it up.

Please consider a follow-up patch (in reply) that cleans up unnecessary
and misleading overflow handling. There is no real benefit in getting
it into linux-next because the upcoming conversion to use the common
code DMA API on s390
Link: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231020&id=c76c067e488c
eliminates arch/s390/pci/pci_dma.c entirely and, therefore, addresses the
original problem in another way. That's why this fix is only relevant for
the current v6.6 and stable backports and is kept as simple as possible.

Let me know if you prefer the regular way, and I should include this
follow-up patch in my pull request later this week.

> If you *do* want to add proper overflow handling, you'd need to either
> fix BITS_TO_LONGS() some way (which is actually non-trivial since it
> needs to be able to stay a constant and only use the argument once),

Looking into that. Let's see if handling overflow in __KERNEL_DIV_ROUND_UP
turns out to be doable.

  parent reply	other threads:[~2023-10-23 16:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-21  9:44 [GIT PULL] s390 fixes for 6.6-rc7 Vasily Gorbik
2023-10-21 17:56 ` Linus Torvalds
2023-10-21 18:08   ` Linus Torvalds
2023-10-22 13:17     ` Vasily Gorbik
2023-10-22 14:54       ` Linus Torvalds
2023-10-23 16:09   ` Vasily Gorbik [this message]
2023-10-23 16:11     ` [PATCH] s390/pci: remove custom and misleading bitmap_vzalloc Vasily Gorbik
2023-10-23 16:31       ` Niklas Schnelle
2023-10-21 17:57 ` [GIT PULL] s390 fixes for 6.6-rc7 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=your-ad-here.call-01698077344-ext-9104@work.hours \
    --to=gor@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=schnelle@linux.ibm.com \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox