linux-kernel - Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

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: <20161216161644.GA2018@ulmo.ba.sec>
Date:   Fri, 16 Dec 2016 17:16:44 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Matthew Wilcox <willy@...ux.intel.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Alexandre Courbot <acourbot@...dia.com>,
        linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

On Wed, Dec 14, 2016 at 11:08:20PM +0900, Alexandre Courbot wrote:
> Forgot to add the most relevant list for this issue (linux-next).
> 
> Stephen, maybe you will want to temporarily revert this patch until this
> is cleared? This probably affects other users than DRM.
> 
> On 12/13/2016 04:14 PM, Alexandre Courbot wrote:
> > Hi Matthew,
> > 
> > Trying the latest -next on the Jetson TK1 board (with two different DRM
> > devices and display and render), I noticed that the GPU device probe
> > always failed with error -ENOSPC. After investigating I figured out that
> > this was due to the minor device allocation failing when a second DRM
> > device is added.
> > 
> > More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY
> > (0) as argument for a second time, the call to idr_alloc() (which has a
> > requested range of 0..64) fails instead of returning 1 as expected. Note
> > that the first call is successful.
> > 
> > Reverting "reimplement IDR and IDA using the radix tree" on 20161213's
> > next fixes the issue for me, suggesting a bug may have slipped in there.
> > 
> > Not sure how this could be fixed, so reporting the issue for now in case
> > it is not known yet.

I can confirm Alex' findings, though the symptoms seem to be slightly
different, which may be related to me testing on next-20161216 rather
than next-20161213.

What I'm seeing is that all drivers get probed correctly, but when an
application tries to open the DRM device files (/dev/dri/card0 in this
case), then all devices of a given minor type disappear. So in my case
upon boot I get this:

	# ls -l /dev/dri/
	total 0
	crw-rw---- 1 root video 226,   0 Dec 16 15:59 card0
	crw-rw---- 1 root video 226,   1 Dec 16 15:59 card1
	crw-rw---- 1 root video 226, 128 Dec 16 15:59 renderD128

The modetest program from libdrm is then unable to open any devices:

	# modetest
	trying to open device 'i915'...failed
	trying to open device 'amdgpu'...failed
	trying to open device 'radeon'...failed
	trying to open device 'nouveau'...failed
	trying to open device 'vmwgfx'...failed
	trying to open device 'omapdrm'...failed
	trying to open device 'exynos'...failed
	trying to open device 'tilcdc'...failed
	trying to open device 'msm'...failed
	trying to open device 'sti'...failed
	trying to open device 'tegra'...failed
	trying to open device 'imx-drm'...failed
	trying to open device 'rockchip'...failed
	trying to open device 'atmel-hlcdc'...failed
	trying to open device 'fsl-dcu-drm'...failed
	trying to open device 'vc4'...failed
	trying to open device 'virtio_gpu'...failed
	trying to open device 'mediatek'...failed
	no device found

And after that all of the primary minors are gone:

	# ls -l /dev/dri/
	total 0
	crw-rw---- 1 root video 226, 128 Dec 16 15:59 renderD128

Strangely this can't be reproduced for renderD128. So explicitly passing
the renderD128 node to modetest:

	# modetest -D /dev/dri/renderD128 
	trying to open device 'i915'...failed
	trying to open device 'amdgpu'...failed
	trying to open device 'radeon'...failed
	trying to open device 'nouveau'...failed
	trying to open device 'vmwgfx'...failed
	trying to open device 'omapdrm'...failed
	trying to open device 'exynos'...failed
	trying to open device 'tilcdc'...failed
	trying to open device 'msm'...failed
	trying to open device 'sti'...failed
	trying to open device 'tegra'...failed
	trying to open device 'imx-drm'...failed
	trying to open device 'rockchip'...failed
	trying to open device 'atmel-hlcdc'...failed
	trying to open device 'fsl-dcu-drm'...failed
	trying to open device 'vc4'...failed
	trying to open device 'virtio_gpu'...failed
	trying to open device 'mediatek'...failed
	no device found

It isn't finding anything either, but the renderD128 node at least
doesn't disappear like the card* nodes:

	# ls -l /dev/dri/
	total 0
	crw-rw---- 1 root video 226, 128 Dec 16 15:59 renderD128

Oddly enough, though:

	# cat /dev/dri/renderD128
	cat: /dev/dri/renderD128: No such device

Something's really weird.

Reverting b05bbe3ea2db ("Reimplement IDR and IDA using the radix tree"),
which is the version in today's linux-next of the patch that Alex had
pinpointed, restores everything to normal.

Andrew, Stephen, can we drop this patch for now?

Matthew, since I have an easy and reliable way of reproducing this, feel
free to enlist me for testing any new revisions of your patch.

Thanks,
Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)