Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Mon, 23 Oct 2023 18:09:04 +0200
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
Message-ID: <your-ad-here.call-01698077344-ext-9104@work.hours>
References: <your-ad-here.call-01697881440-ext-2458@work.hours>
 <CAHk-=wgTUz1bdY6zvsN4ED0arCLE8Sb==1GH8d0sjm5bu7zesQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wgTUz1bdY6zvsN4ED0arCLE8Sb==1GH8d0sjm5bu7zesQ@mail.gmail.com>
MIME-Version: 1.0
Precedence: bulk

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.