linux-kernel - [PATCH 0/4] drm: Add mode resource leasing

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-next>] [day] [month] [year] [list]

Message-Id: <20170401170841.2643-1-keithp@keithp.com>
Date:   Sat,  1 Apr 2017 10:08:37 -0700
From:   Keith Packard <keithp@...thp.com>
To:     linux-kernel@...r.kernel.org, Dave Airlie <airlied@...hat.com>
Cc:     Keith Packard <keithp@...thp.com>, dri-devel@...ts.freedesktop.org
Subject: [PATCH 0/4] drm: Add mode resource leasing

Here's a first cut of the proposed mode resource leasing code. What
this does is allow an application to create a new drm_master which
"leases" resources from an existing drm_master. This new drm_master
can do whatever it likes with the resources it was granted, including
setting modes, performing page_flip operations etc.

This can be used to run multiple compositors on the same GPU, each
driving its own set of outputs. Examples of this include multi-user
setups and virtual reality environments.

Because setting modes can consume 'hidden' resources within the GPU,
it isn't entirely clear that letting multiple processes perform mode
setting is a good idea or not. A process doing the usual
test/render/commit sequence may find that the commit fails because
some other process consumed necessary resources after the test was
invoked. Daniel Vetter suggested that perhaps some kind of locking
mechanism across this sequence might help, but that can lead to
problems when a process fails to unlock. If someone wants to come up
with a reasonable scheme here, that'd be great.

For now, I'll be working on the assumption that the lease holder will
not set any modes, which will avoid the problematic case described above.

The series is broken into four patches in an attempt to make review a
bit easier.

The trickiest bit of the code was in creating the new drm_master,
which involved allocating a new file and fd and getting those
initialized with the right reference counts on all of the related data
structures. It "seems" to work, but it would be nice if someone with
more experience in that part of the kernel could take a look at
it. That's in the fourth patch.

The third patch hooks the lease checks into the other ioctls; that
could use some review to make sure I didn't miss any needed checks.

-keith