1. 26 Apr, 2016 1 commit
    • Linus Torvalds's avatar
      devpts: more pty driver interface cleanups · 8ead9dd5
      Linus Torvalds authored
      This is more prep-work for the upcoming pty changes.  Still just code
      cleanup with no actual semantic changes.
      
      This removes a bunch pointless complexity by just having the slave pty
      side remember the dentry associated with the devpts slave rather than
      the inode.  That allows us to remove all the "look up the dentry" code
      for when we want to remove it again.
      
      Together with moving the tty pointer from "inode->i_private" to
      "dentry->d_fsdata" and getting rid of pointless inode locking, this
      removes about 30 lines of code.  Not only is the end result smaller,
      it's simpler and easier to understand.
      
      The old code, for example, depended on the d_find_alias() to not just
      find the dentry, but also to check that it is still hashed, which in
      turn validated the tty pointer in the inode.
      
      That is a _very_ roundabout way to say "invalidate the cached tty
      pointer when the dentry is removed".
      
      The new code just does
      
      	dentry->d_fsdata = NULL;
      
      in devpts_pty_kill() instead, invalidating the tty pointer rather more
      directly and obviously.  Don't do something complex and subtle when the
      obvious straightforward approach will do.
      
      The rest of the patch (ie apart from code deletion and the above tty
      pointer clearing) is just switching the calling convention to pass the
      dentry or file pointer around instead of the inode.
      
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
      Cc: Jann Horn <jann@thejh.net>
      Cc: Greg KH <greg@kroah.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8ead9dd5
  2. 25 Apr, 2016 1 commit
  3. 24 Apr, 2016 2 commits
  4. 23 Apr, 2016 10 commits
  5. 22 Apr, 2016 24 commits
  6. 21 Apr, 2016 2 commits
    • cpaul@redhat.com's avatar
      drm/dp/mst: Validate port in drm_dp_payload_send_msg() · deba0a2a
      cpaul@redhat.com authored
      With the joys of things running concurrently, there's always a chance
      that the port we get passed in drm_dp_payload_send_msg() isn't actually
      valid anymore. Because of this, we need to make sure we validate the
      reference to the port before we use it otherwise we risk running into
      various race conditions. For instance, on the Dell MST monitor I have
      here for testing, hotplugging it enough times causes us to kernel panic:
      
      [drm:intel_mst_enable_dp] 1
      [drm:drm_dp_update_payload_part2] payload 0 1
      [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020
      [drm:intel_hpd_irq_handler] digital hpd port B - short
      [drm:intel_dp_hpd_pulse] got hpd irq on port B - short
      [drm:intel_dp_check_mst_status] got esi 00 10 00
      [drm:drm_dp_update_payload_part2] payload 1 1
      general protection fault: 0000 [#1] SMP
      …
      Call Trace:
       [<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper]
       [<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915]
       [<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915]
       [<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915]
       [<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm]
       [<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm]
       [<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper]
       [<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm]
       [<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm]
       [<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm]
       [<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
       [<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0
       [<ffffffff81212962>] do_vfs_ioctl+0x92/0x570
       [<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80
       [<ffffffff81212eb9>] SyS_ioctl+0x79/0x90
       [<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      RIP  [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper]
      
      Which occurs because of the hotplug event shown in the log, which ends
      up causing DRM's dp helpers to drop the port we're updating the payload
      on and panic.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Reviewed-by: default avatarDavid Airlie <airlied@linux.ie>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      deba0a2a
    • Dave Airlie's avatar
      Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-fixes · 3addc4e3
      Dave Airlie authored
      Single nouveau regression fix
      * 'linux-4.6' of git://github.com/skeggsb/linux:
        drm/nouveau/kms: fix setting of default values for dithering properties
      3addc4e3