linux-stable.git/drivers/gpu/drm/drm_fops.c, branch linux-3.8.y

drm: correctly restore mappings if drm_open fails

2013-04-12T16:52:04+00:00

commit a8ec3a662921220fc058ed6f7f3674697876d218 upstream.

If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.

Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850
(thanks to Michal Hocko for investigating investigating and
finding the root cause of the bug)

Reference:
http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html

v2: Use one variable to store file and inode mapping
    since they are the same at the function entry.
    Fix spelling mistakes in commit message.

v3: Add reference to the original bug report.

Reported-by: Marco Munderloh 
Tested-by: Marco Munderloh 
Signed-off-by: Ilija Hadzic 
Cc: Michal Hocko 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm: set dev_mapping before calling drm_open_helper

2012-11-07T00:51:15+00:00

Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have to set dev->dev_mapping
earlier in the process.

Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-October/029420.html

Signed-off-by: Ilija Hadzic 
Reported-by: Thomas Hellstrom 
Cc: stable@vger.kernel.org
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Dave Airlie

drm: restore open_count if drm_setup fails

2012-11-07T00:51:08+00:00

If drm_setup (called at first open) fails, the whole
open call has failed, so we should not keep the
open_count incremented.

Signed-off-by: Ilija Hadzic 
Cc: stable@vger.kernel.org
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Dave Airlie

Merge tag 'uapi-prep-20121002' of git://git.infradead.org/users/dhowells/linux-headers

2012-10-03T20:45:43+00:00

Pull preparatory patches for user API disintegration from David Howells:
 "The patches herein prepare for the extraction of the Userspace API
  bits from the various header files named in the Kbuild files.

  New subdirectories are created under either include/uapi/ or
  arch/x/include/uapi/ that correspond to the subdirectory containing
  that file under include/ or arch/x/include/.

  The new subdirs under the uapi/ directory are populated with Kbuild
  files that mostly do nothing at this time.  Further patches will
  disintegrate the headers in each original directory and fill in the
  Kbuild files as they do it.

  These patches also:

   (1) fix up #inclusions of "foo.h" rather than .

   (2) Remove some redundant #includes from the DRM code.

   (3) Make the kernel build infrastructure handle Kbuild files both in
       the old places and the new UAPI place that both specify headers
       to be exported.

   (4) Fix some kernel tools that #include kernel headers during their
       build.

  I have compile tested this with allyesconfig against x86_64,
  allmodconfig against i386 and a scattering of additional defconfigs of
  other arches.  Prepared for main script

  Signed-off-by: David Howells 
  Acked-by: Arnd Bergmann 
  Acked-by: Thomas Gleixner 
  Acked-by: Michael Kerrisk 
  Acked-by: Paul E. McKenney 
  Acked-by: Dave Jones 
  Acked-by: H. Peter Anvin "

* tag 'uapi-prep-20121002' of git://git.infradead.org/users/dhowells/linux-headers:
  UAPI: Plumb the UAPI Kbuilds into the user header installation and checking
  UAPI: x86: Differentiate the generated UAPI and internal headers
  UAPI: Remove the objhdr-y export list
  UAPI: Move linux/version.h
  UAPI: Set up uapi/asm/Kbuild.asm
  UAPI: x86: Fix insn_sanity build failure after UAPI split
  UAPI: x86: Fix the test_get_len tool
  UAPI: (Scripted) Set up UAPI Kbuild files
  UAPI: Partition the header include path sets and add uapi/ header directories
  UAPI: (Scripted) Convert #include "..." to #include  in kernel system headers
  UAPI: (Scripted) Convert #include "..." to #include  in drivers/gpu/
  UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.
  UAPI: Refer to the DRM UAPI headers with <...> and from certain headers only

UAPI: (Scripted) Convert #include "..." to #include in drivers/gpu/

2012-10-02T17:01:07+00:00

Convert #include "..." to #include  in drivers/gpu/.

Signed-off-by: David Howells 
Acked-by: Dave Airlie 
Acked-by: Arnd Bergmann 
Acked-by: Thomas Gleixner 
Acked-by: Paul E. McKenney 
Acked-by: Dave Jones

userns: Convert drm to use kuid and kgid and struct pid where appropriate

2012-09-13T21:32:24+00:00

Blink Blink this had not been converted to use struct pid ages ago?

- On drm open capture the openers kuid and struct pid.
- On drm close release the kuid and struct pid
- When reporting the uid and pid convert the kuid and struct pid
  into values in the appropriate namespace.

Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman

drm: track dev_mapping in more robust and flexible way

2012-07-25T04:09:30+00:00

Setting dev_mapping (pointer to the address_space structure
used for memory mappings) to the address_space of the first
opener's inode and then failing if other openers come in
through a different inode has a few restrictions that are
eliminated by this patch.

If we already have valid dev_mapping and we spot an opener
with different i_node, we force its i_mapping pointer to the
already established address_space structure (first opener's
inode). This will make all mappings from drm device hang off
the same address_space object.

Some benefits (things that now work and didn't work
before) of this patch are:

 * user space can mknod and use any number of device
   nodes and they will all work fine as long as the major
   device number is that of the drm module.
 * user space can even remove the first opener's device
   nodes and mknod the new one and the applications and
   windowing system will still work.
 * GPU drivers can safely assume that dev->dev_mapping is
   correct address_space and just blindly copy it
   into their (private) bdev.dev_mapping

For reference, some discussion that lead to this patch can
be found here:

http://lists.freedesktop.org/archives/dri-devel/2012-April/022283.html

Signed-off-by: Ilija Hadzic 
Signed-off-by: Dave Airlie

drm: unconditionally clean up dma buffers of closing clients

2012-07-20T02:51:04+00:00

With the last patch to ditch DMA_QUEUE support, we should be able
to call the dma cleanup uncoditionally, even when the master has
disappeared.

Do so because it just makes more sense.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: kill dma queue support

2012-07-20T02:50:55+00:00

Absolutely unused. All the values are only ever initialized and
then used at most in some debug printout functions.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: kill reclaim_buffers callback

2012-07-20T02:50:28+00:00

All leftover users either haven't set DRIVER_HAVE_DMA, in which
case this will never be called, or use the drm_core implementation.

Call that directly in the only callsite.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie