linux-kernel - Re: [git pull] drm for 5.7-rc1

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: <CAKMK7uH+vX=eh17-m9mL17QQ1uxjfDEcdj-tno-fAYA4Z1+Jag@mail.gmail.com>
Date:   Fri, 3 Apr 2020 10:12:15 +0200
From:   Daniel Vetter <daniel.vetter@...ll.ch>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Nathan Chancellor <natechancellor@...il.com>,
        Dave Airlie <airlied@...il.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: [git pull] drm for 5.7-rc1

On Thu, Apr 2, 2020 at 10:43 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Thu, Apr 2, 2020 at 1:33 PM Nathan Chancellor
> <natechancellor@...il.com> wrote:
> >
> > This fixes it but I am not sure if it is proper or not (could be
> > problematic if CONFIG_PHYS_ADDR_T_64BIT is set but
> > CONFIG_ARCH_DMA_ADDR_T_64BIT is not, not sure if that is possible) so I
> > figured I'd report it and let you guys deal with it.
>
> Yeah, no, that patch can't be right.
>
> From your build failure, your configuration has dma_addr_t being a
> 'long long unsigned int', and map->offset being a resource_size_t is
> for just a 'unsigned int'. Casting 'unsigned int *' to 'unsigned long
> long *' is not valid.
>
> You'd have to do something like
>
>         dma_addr_t temp;
>
> and pass the address of *that* in, and then assign that to map->offset
> (and verify that it fits), I think.
>
> That's kind of what the old code did.
>
> Or alternatively, the 'offset' field should just be of type
> 'dma_addr_t' instead (see include/drm/drm_legacy.h). But I didn't
> check if something else wants it to be a resource_size_t.

This is all exclusive in legacy code back from the days when drm
drivers where shared with *bsd. None of that code ever learned that
there's maybe a difference between dma/phys/virtual address sizes, and
that's about the least of the problems it has.

Revert seems to be clean, I'd vote for that. And maybe we instead try
to push these horrors more under the CONFIG_DRM_LEGACY. I'll try to
remember to do that, afaics the only thing outside are the
drm_pci_alloc/free multi-layered wrappers in drm_pci.c.

Linus, can you pls push the revert yourself, to avoid build bot
breakage for longer than necessary?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch