linux-kernel - Re: [git pull] drm fixes for 5.19-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgcECb3cwnB=7Zgf8CBfEYaTWcSzAjfQpTM75_Q5aO7dA@mail.gmail.com>
Date:   Sat, 16 Jul 2022 15:08:39 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nathan Chancellor <nathan@...nel.org>,
        Matthew Auld <matthew.auld@...el.com>,
        Nirmoy Das <nirmoy.das@...el.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Thomas Hellström 
        <thomas.hellstrom@...ux.intel.com>
Cc:     Dave Airlie <airlied@...il.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm fixes for 5.19-rc7

On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> That said, even those type simplifications do not fix the fundamental
> issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> although now it's at least a "64-by-32" bit divide.

Hmm. The "DIV_ROUND_UP()" issue could be solved by just making the
rule be that the max_segment size is always a power of two.

Then you don't need the (expensive!) DIV_ROUND_UP(), and can just use
the regular "round_up()" that works on powers-of-two.

And the simplest way to do that is to just make "max_segments" be 2GB.

The whole "round_down(UINT_MAX, page_alignment)" seems entirely
pointless. Do you really want segments that are some odd number just
under the 4GB mark, and force expensive divides?

For consistency, I used the same value in
i915_rsgt_from_buddy_resource(). I have no idea if that makes sense.

Anyway, the attached patch is COMPLETELY UNTESTED. But it at least
seems to compile. Maybe.

                  Linus

View attachment "patch.diff" of type "text/x-patch" (1631 bytes)