linux-kernel - Re: Warnings in DRM code when removing/unbinding a driver

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 19 Dec 2019 10:03:33 +0000
From:   John Garry <john.garry@...wei.com>
To:     Daniel Vetter <daniel@...ll.ch>
CC:     Ezequiel Garcia <ezequiel@...labora.com>,
        "kongxinwei (A)" <kong.kongxinwei@...ilicon.com>,
        "Chenfeng (puck)" <puck.chen@...ilicon.com>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Linuxarm <linuxarm@...wei.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Gerd Hoffmann <kraxel@...hat.com>, <dbueso@...e.de>
Subject: Re: Warnings in DRM code when removing/unbinding a driver

On 19/12/2019 09:54, Daniel Vetter wrote:
> On Wed, Dec 18, 2019 at 7:08 PM John Garry <john.garry@...wei.com> wrote:
>>
>> +
>>
>> So the v5.4 kernel does not have this issue.
>>
>> I have bisected the initial occurrence to:
>>
>> commit 37a48adfba6cf6e87df9ba8b75ab85d514ed86d8
>> Author: Thomas Zimmermann <tzimmermann@...e.de>
>> Date:   Fri Sep 6 14:20:53 2019 +0200
>>
>>       drm/vram: Add kmap ref-counting to GEM VRAM objects
>>
>>       The kmap and kunmap operations of GEM VRAM buffers can now be called
>>       in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
>>       buffer's memory to kernel address space and the final call to
>>       drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these
>>       functions increment or decrement a reference counter.
>>
>> So this either exposes or creates the issue.
> 
> Yeah that's just shooting the messenger.

OK, so it exposes it.

  Like I said, for most drivers
> you can pretty much assume that their unload sequence has been broken
> since forever. It's not often tested, and especially the hotunbind
> from a device (as opposed to driver unload) stuff wasn't even possible
> to get right until just recently.

Do you think it's worth trying to fix this for 5.5 and earlier, or just 
switch to the device-managed interface for 5.6 and forget about 5.5 and 
earlier?

Thanks,
John