summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_auth.c
AgeCommit message (Collapse)Author
2016-08-08drm: Used DRM_LEGACY for all legacy functionsDaniel Vetter
Except for nouveau, only legacy drivers need this really. And nouveau is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special case. I've tried to be careful to leave everything related to modeset still using the DRIVER_MODESET flag. Otherwise it's a direct replacement of !DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability since fewer negative checks overall. Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch
2016-06-21drm: document drm_auth.cDaniel Vetter
Also extract drm_auth.h for nicer grouping. v2: Nuke the other comments since they don't really explain a lot, and within the drm core we generally only document functions exported to drivers: The main audience for these docs are driver writers. v3: Limit the exposure of drm_master internals by only including drm_auth.h where it is neede (Chris). v4: Spelling polish (Emil). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-06-21drm: Clear up master tracking booleansDaniel Vetter
- is_master can be removed, we can compute this by checking allowed_master (which really just tracks whether a master struct has been allocated for this fpriv in either open or set_master), and whether the fpriv is the current master on the device. - that frees up is_master as a good replacement name for allowed_master. With that it's clear that it tracks whether the fpriv is a master (with possibly clients attached to it and authenticated against it), and that one of those fprivs with is_master set is the current master. v2: Fix kerneldoc for is_master (Emil). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-10-git-send-email-daniel.vetter@ffwll.ch
2016-06-21drm: Extract drm_is_current_masterDaniel Vetter
Just rolling out a bit of abstraction to be able to clean up the master logic in the next step. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-06-21drm: Refactor drop/set master code a bitDaniel Vetter
File open/set_maseter ioctl and file close/drop_master ioctl share the same master handling code. Extract it. Note that vmwgfx's master_set callback needs to know whether the master is a new one or has been used already, so thread this through. On the close/drop side a similar parameter existed, but wasnt used. Drop it to simplify the flow. v2: Try to make it not leak so much (Emil). v3: Send out the right version ... Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466511638-9885-1-git-send-email-daniel.vetter@ffwll.ch
2016-06-21drm: Move master pointer from drm_minor to drm_deviceDaniel Vetter
There can only be one current master, and it's for the overall device. Render/control minors don't support master-based auth at all. This simplifies the master logic a lot, at least in my eyes: All these additional pointer chases are just confusing. While doing the conversion I spotted some locking fail: - drm_lock/drm_auth check dev->master without holding the master_mutex. This is fallout from commit c996fd0b956450563454e7ccc97a82ca31f9d043 Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Tue Feb 25 19:57:44 2014 +0100 drm: Protect the master management with a drm_device::master_mutex v3 but I honestly don't care one bit about those old legacy drivers using this. - debugfs name info should just grab master_mutex. - And the fbdev helper looked at it to figure out whether someone is using KMS. We just need a consistent value, so READ_ONCE. Aside: We should probably check if anyone has opened a control node too, but I guess current userspace doesn't really do that yet. v2: Balance locking, reported by Julia. v3: Rebase on top of Chris' oops fixes. Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-1-git-send-email-daniel.vetter@ffwll.ch
2016-06-20drm: Protect authmagic with master_mutexDaniel Vetter
Simplifies cleanup, and there's no reason drivers should ever care about authmagic at all - it's all handled in the core. And with that, Ladies and Gentlemen, it's time to pop the champagen and celebrate: dev->struct_mutex is now officially gone from modern drivers, and if a driver is using gem_free_object_unlocked and doesn't do anything else silly it's positively impossible to ever touch dev->struct_mutex at runtime, anywhere. Well except for the mutex_init on driver load ;-) v2: Rebased. Cc: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-4-git-send-email-daniel.vetter@ffwll.ch
2016-06-20drm: Move authmagic cleanup into drm_master_releaseDaniel Vetter
It's related, and soon authmagic will also use the master_mutex. There is an ever-so-slightly semantic change here: - authmagic will only be cleaned up for primary_client drm_minors. But it's impossible to create authmagic on render/control nodes, so this is fine. - The cleanup is moved down a bit in the release processing. Doesn't matter at all since authmagic is purely internal logic used by the core ioctl access checks, and when we're in a file's release callback no one can do ioctls any more. v2: Rebased. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-3-git-send-email-daniel.vetter@ffwll.ch
2016-06-20drm: Only do the hw.lock cleanup in master_relase for !MODESETDaniel Vetter
Another place gone where modern drivers could have hit dev->struct_mutex. To avoid too deeply nesting control flow rework it a bit. v2: Review from Chris: - remove spurious newline. - fix file_priv->master like for the !file_priv->is_master case. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-2-git-send-email-daniel.vetter@ffwll.ch
2016-06-16drm: Extract drm_master_relaseDaniel Vetter
Like with drm_master_open protect it with a check for primary_client to make it clear that this can't happen on render/control nodes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465930269-7883-7-git-send-email-daniel.vetter@ffwll.ch
2016-06-16drm: Extract drm_master_openDaniel Vetter
And pull out the primary_client check to make it really obvious that this can't happen on control/render nodes. Bonus that we can avoid the master lock in this case. v2: Don't leak locks on error path (and simplify control flow while at it), reported by Julia. Cc: Julia Lawall <julia.lawall@lip6.fr> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465930269-7883-6-git-send-email-daniel.vetter@ffwll.ch
2016-06-16drm: Move master functions into drm_auth.cDaniel Vetter
For modern drivers pretty much the only thing drm_master does is handling authentication for the primary/legacy drm_minor node. Instead of having it all over drm files, move it all together into drm_auth.c. This patch just does code-motion, follow up patches will also extract the master logic from file open&release paths. Reviewed-by: Chris Wilson Mchris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465930269-7883-5-git-send-email-daniel.vetter@ffwll.ch
2015-05-05drm: simplify authentication managementDavid Herrmann
The magic auth tokens we have are a simple map from cyclic IDs to drm_file objects. Remove all the old bulk of code and replace it with a simple, direct IDR. The previous behavior is kept. Especially calling authmagic multiple times on the same magic results in EINVAL except on the first call. The only difference in behavior is that we never allocate IDs multiple times as long as a client has its FD open. v2: - Fix return code of GetMagic() - Use non-cyclic IDR allocator - fix off-by-one in "magic > INT_MAX" sanity check v3: - drop redundant "magic > INT_MAX" check Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-05drm: drop unused 'magicfree' listDavid Herrmann
This list is write-only. It's never used for read-access, so no reason to keep it around. Drop it! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-12drm: Move piles of functions from drmP.h to drm_internal.hDaniel Vetter
This way drivers can't grow crazy ideas any more, and it also helps a bit in reviewing EXPORT_SYMBOLS. v2: Even more stuff. Unfortunately we can't move drm_vm_open_locked because exynos does some horrible stuff with it. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-10drm: move "struct drm_magic_entry" to drm_auth.cDavid Herrmann
In drm_release(), we currently call drm_remove_magic() if the drm_file has a drm-magic attached. Therefore, once drm_master_release() is called, the magic-list _must_ be empty. By dropping the no-op cleanup, we can move "struct drm_magic_entry" to drm_auth.c and avoid exposing it to all of DRM. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2012-01-25drm: Fix authentication kernel crashThomas Hellstrom
If the master tries to authenticate a client using drm_authmagic and that client has already closed its drm file descriptor, either wilfully or because it was terminated, the call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory and corrupt it. Typically this results in a hard system hang. This patch fixes that problem by removing any authentication tokens (struct drm_magic_entry) open for a file descriptor when that file descriptor is closed. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-05-18drivers/gpu/drm: Use kzallocJulia Lawall
Use kzalloc rather than the combination of kmalloc and memset. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,size,flags; statement S; @@ -x = kmalloc(size,flags); +x = kzalloc(size,flags); if (x == NULL) S -memset(x, 0, size); // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Reviewed-by: Corbin Simpson <MostAwesomeDude@gmail.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-18drm: Remove memory debugging infrastructure.Eric Anholt
It hasn't been used in ages, and having the user tell your how much memory is being freed at free time is a recipe for disaster even if it was ever used. Signed-off-by: Eric Anholt <eric@anholt.net>
2008-12-29drm: move to kref per-master structures.Dave Airlie
This is step one towards having multiple masters sharing a drm device in order to get fast-user-switching to work. It splits out the information associated with the drm master into a separate kref counted structure, and allocates this when a master opens the device node. It also allows the current master to abdicate (say while VT switched), and a new master to take over the hardware. It moves the Intel and radeon drivers to using the sarea from within the new master structures. Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-07-14drm: reorganise drm tree to be more future proof.Dave Airlie
With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: Dave Airlie <airlied@redhat.com>