1. 27 Jul, 2017 40 commits
    • Jaegeuk Kim's avatar
      f2fs: Don't clear SGID when inheriting ACLs · f97f9e94
      Jaegeuk Kim authored
      commit c925dc16 upstream.
      
      This patch copies commit b7f8a09f:
      "btrfs: Don't clear SGID when inheriting ACLs" written by Jan.
      
      Fixes: 07393101Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f97f9e94
    • Jin Qian's avatar
      f2fs: sanity check size of nat and sit cache · 19e117a5
      Jin Qian authored
      commit 21d3f8e1 upstream.
      
      Make sure number of entires doesn't exceed max journal size.
      Signed-off-by: default avatarJin Qian <jinqian@android.com>
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19e117a5
    • Jan Kara's avatar
      xfs: Don't clear SGID when inheriting ACLs · 58d2eacd
      Jan Kara authored
      commit 8ba35875 upstream.
      
      When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
      set, DIR1 is expected to have SGID bit set (and owning group equal to
      the owning group of 'DIR0'). However when 'DIR0' also has some default
      ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
      'DIR1' to get cleared if user is not member of the owning group.
      
      Fix the problem by calling __xfs_set_acl() instead of xfs_set_acl() when
      setting up inode in xfs_generic_create(). That prevents SGID bit
      clearing and mode is properly set by posix_acl_create() anyway. We also
      reorder arguments of __xfs_set_acl() to match the ordering of
      xfs_set_acl() to make things consistent.
      
      Fixes: 07393101
      CC: Darrick J. Wong <darrick.wong@oracle.com>
      CC: linux-xfs@vger.kernel.org
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58d2eacd
    • Corey Minyard's avatar
      ipmi:ssif: Add missing unlock in error branch · 1b9008cd
      Corey Minyard authored
      commit 4495ec6d upstream.
      
      When getting flags, a response to a different message would
      result in a deadlock because of a missing unlock.  Add that
      unlock and a comment.  Found by static analysis.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b9008cd
    • Tony Camuso's avatar
      ipmi: use rcu lock around call to intf->handlers->sender() · 685e124e
      Tony Camuso authored
      commit cdea4656 upstream.
      
      A vendor with a system having more than 128 CPUs occasionally encounters
      the following crash during shutdown. This is not an easily reproduceable
      event, but the vendor was able to provide the following analysis of the
      crash, which exhibits the same footprint each time.
      
      crash> bt
      PID: 0      TASK: ffff88017c70ce70  CPU: 5   COMMAND: "swapper/5"
       #0 [ffff88085c143ac8] machine_kexec at ffffffff81059c8b
       #1 [ffff88085c143b28] __crash_kexec at ffffffff811052e2
       #2 [ffff88085c143bf8] crash_kexec at ffffffff811053d0
       #3 [ffff88085c143c10] oops_end at ffffffff8168ef88
       #4 [ffff88085c143c38] no_context at ffffffff8167ebb3
       #5 [ffff88085c143c88] __bad_area_nosemaphore at ffffffff8167ec49
       #6 [ffff88085c143cd0] bad_area_nosemaphore at ffffffff8167edb3
       #7 [ffff88085c143ce0] __do_page_fault at ffffffff81691d1e
       #8 [ffff88085c143d40] do_page_fault at ffffffff81691ec5
       #9 [ffff88085c143d70] page_fault at ffffffff8168e188
          [exception RIP: unknown or invalid address]
          RIP: ffffffffa053c800  RSP: ffff88085c143e28  RFLAGS: 00010206
          RAX: ffff88017c72bfd8  RBX: ffff88017a8dc000  RCX: ffff8810588b5ac8
          RDX: ffff8810588b5a00  RSI: ffffffffa053c800  RDI: ffff8810588b5a00
          RBP: ffff88085c143e58   R8: ffff88017c70d408   R9: ffff88017a8dc000
          R10: 0000000000000002  R11: ffff88085c143da0  R12: ffff8810588b5ac8
          R13: 0000000000000100  R14: ffffffffa053c800  R15: ffff8810588b5a00
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
          <IRQ stack>
          [exception RIP: cpuidle_enter_state+82]
          RIP: ffffffff81514192  RSP: ffff88017c72be50  RFLAGS: 00000202
          RAX: 0000001e4c3c6f16  RBX: 000000000000f8a0  RCX: 0000000000000018
          RDX: 0000000225c17d03  RSI: ffff88017c72bfd8  RDI: 0000001e4c3c6f16
          RBP: ffff88017c72be78   R8: 000000000000237e   R9: 0000000000000018
          R10: 0000000000002494  R11: 0000000000000001  R12: ffff88017c72be20
          R13: ffff88085c14f8e0  R14: 0000000000000082  R15: 0000001e4c3bb400
          ORIG_RAX: ffffffffffffff10  CS: 0010  SS: 0018
      
      This is the corresponding stack trace
      
      It has crashed because the area pointed with RIP extracted from timer
      element is already removed during a shutdown process.
      
      The function is smi_timeout().
      
      And we think ffff8810588b5a00 in RDX is a parameter struct smi_info
      
      crash> rd ffff8810588b5a00 20
      ffff8810588b5a00:  ffff8810588b6000 0000000000000000   .`.X............
      ffff8810588b5a10:  ffff880853264400 ffffffffa05417e0   .D&S......T.....
      ffff8810588b5a20:  24a024a000000000 0000000000000000   .....$.$........
      ffff8810588b5a30:  0000000000000000 0000000000000000   ................
      ffff8810588b5a30:  0000000000000000 0000000000000000   ................
      ffff8810588b5a40:  ffffffffa053a040 ffffffffa053a060   @.S.....`.S.....
      ffff8810588b5a50:  0000000000000000 0000000100000001   ................
      ffff8810588b5a60:  0000000000000000 0000000000000e00   ................
      ffff8810588b5a70:  ffffffffa053a580 ffffffffa053a6e0   ..S.......S.....
      ffff8810588b5a80:  ffffffffa053a4a0 ffffffffa053a250   ..S.....P.S.....
      ffff8810588b5a90:  0000000500000002 0000000000000000   ................
      
      Unfortunately the top of this area is already detroyed by someone.
      But because of two reasonns we think this is struct smi_info
       1) The address included in between  ffff8810588b5a70 and ffff8810588b5a80:
        are inside of ipmi_si_intf.c  see crash> module ffff88085779d2c0
      
       2) We've found the area which point this.
        It is offset 0x68 of  ffff880859df4000
      
      crash> rd  ffff880859df4000 100
      ffff880859df4000:  0000000000000000 0000000000000001   ................
      ffff880859df4010:  ffffffffa0535290 dead000000000200   .RS.............
      ffff880859df4020:  ffff880859df4020 ffff880859df4020    @.Y.... @.Y....
      ffff880859df4030:  0000000000000002 0000000000100010   ................
      ffff880859df4040:  ffff880859df4040 ffff880859df4040   @@.Y....@@.Y....
      ffff880859df4050:  0000000000000000 0000000000000000   ................
      ffff880859df4060:  0000000000000000 ffff8810588b5a00   .........Z.X....
      ffff880859df4070:  0000000000000001 ffff880859df4078   ........x@.Y....
      
       If we regards it as struct ipmi_smi in shutdown process
       it looks consistent.
      
      The remedy for this apparent race is affixed below.
      Signed-off-by: default avatarTony Camuso <tcamuso@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      This was first introduced in 7ea0ed2b ipmi: Make the
      message handler easier to use for SMI interfaces
      where some code was moved outside of the rcu_read_lock()
      and the lock was not added.
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      685e124e
    • Mario Kleiner's avatar
      drm/radeon: Fix eDP for single-display iMac10,1 (v2) · 6e7b1eff
      Mario Kleiner authored
      commit 564d8a2c upstream.
      
      The late 2009, 27 inch Apple iMac10,1 has an
      internal eDP display and an external Mini-
      Displayport output, driven by a DCE-3.2, RV730
      Radeon Mobility HD-4670.
      
      The machine worked fine in a dual-display setup
      with eDP panel + externally connected HDMI
      or DVI-D digital display sink, connected via
      MiniDP to DVI or HDMI adapter.
      
      However, booting the machine single-display with
      only eDP panel results in a completely black
      display - even backlight powering off, as soon as
      the radeon modesetting driver loads.
      
      This patch fixes the single dispay eDP case by
      assigning encoders based on dig->linkb, similar
      to DCE-4+. While this should not be generally
      necessary (Alex: "...atom on normal boards
      should be able to handle any mapping."), Apple
      seems to use some special routing here.
      
      One remaining problem not solved by this patch
      is that an external Minidisplayport->DP sink
      does still not work on iMac10,1, whereas external
      DVI and HDMI sinks continue to work.
      
      The problem affects at least all tested kernels
      since Linux 3.13 - didn't test earlier kernels, so
      backporting to stable probably makes sense.
      
      v2: With the original patch from 2016, Alex was worried it
          will break other DCE3.2 systems. Use dmi_match() to
          apply this special encoder assignment only for the
          Apple iMac 10,1 from late 2009.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Michel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e7b1eff
    • Alex Deucher's avatar
      drm/radeon/ci: disable mclk switching for high refresh rates (v2) · a844f8d2
      Alex Deucher authored
      commit ab03d9fe upstream.
      
      Even if the vblank period would allow it, it still seems to
      be problematic on some cards.
      
      v2: fix logic inversion (Nils)
      
      bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a844f8d2
    • Tom St Denis's avatar
      drm/amd/amdgpu: Return error if initiating read out of range on vram · b85007c9
      Tom St Denis authored
      commit 9156e723 upstream.
      
      If you initiate a read that is out of the VRAM address space return
      ENXIO instead of 0.
      
      Reads that begin below that point will read upto the VRAM limit as
      before.
      Signed-off-by: default avatarTom St Denis <tom.stdenis@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b85007c9
    • Jiri Olsa's avatar
      s390/syscalls: Fix out of bounds arguments access · 8302e9d2
      Jiri Olsa authored
      commit c46fc042 upstream.
      
      Zorro reported following crash while having enabled
      syscall tracing (CONFIG_FTRACE_SYSCALLS):
      
        Unable to handle kernel pointer dereference at virtual ...
        Oops: 0011 [#1] SMP DEBUG_PAGEALLOC
      
        SNIP
      
        Call Trace:
        ([<000000000024d79c>] ftrace_syscall_enter+0xec/0x1d8)
         [<00000000001099c6>] do_syscall_trace_enter+0x236/0x2f8
         [<0000000000730f1c>] sysc_tracesys+0x1a/0x32
         [<000003fffcf946a2>] 0x3fffcf946a2
        INFO: lockdep is turned off.
        Last Breaking-Event-Address:
         [<000000000022dd44>] rb_event_data+0x34/0x40
        ---[ end trace 8c795f86b1b3f7b9 ]---
      
      The crash happens in syscall_get_arguments function for
      syscalls with zero arguments, that will try to access
      first argument (args[0]) in event entry, but it's not
      allocated.
      
      Bail out of there are no arguments.
      Reported-by: default avatarZorro Lang <zlang@redhat.com>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8302e9d2
    • Xiao Ni's avatar
      Raid5 should update rdev->sectors after reshape · 1e951485
      Xiao Ni authored
      commit b5d27718 upstream.
      
      The raid5 md device is created by the disks which we don't use the total size. For example,
      the size of the device is 5G and it just uses 3G of the devices to create one raid5 device.
      Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid
      and assemble it again. It fails.
      mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean
      mdadm /dev/md0 --grow --chunk=64
      wait reshape to finish
      mdadm -S /dev/md0
      mdadm -As
      The error messages:
      [197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing!
      [197519.821686] md: md_import_device returned -22
      
      After reshape the data offset is changed. It selects backwards direction in this condition.
      In function super_1_load it compares the available space of the underlying device with
      sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL.
      rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based
      on rdev->sectors. So add md_finish_reshape in end_reshape.
      Signed-off-by: default avatarXiao Ni <xni@redhat.com>
      Acked-by: default avatarGuoqing Jiang <gqjiang@suse.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e951485
    • Jan Kara's avatar
      ext2: Don't clear SGID when inheriting ACLs · 4d1f97eb
      Jan Kara authored
      commit a992f2d3 upstream.
      
      When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
      set, DIR1 is expected to have SGID bit set (and owning group equal to
      the owning group of 'DIR0'). However when 'DIR0' also has some default
      ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
      'DIR1' to get cleared if user is not member of the owning group.
      
      Fix the problem by creating __ext2_set_acl() function that does not call
      posix_acl_update_mode() and use it when inheriting ACLs. That prevents
      SGID bit clearing and the mode has been properly set by
      posix_acl_create() anyway.
      
      Fixes: 07393101
      CC: linux-ext4@vger.kernel.org
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d1f97eb
    • Toshi Kani's avatar
      libnvdimm: fix badblock range handling of ARS range · 0fa705dc
      Toshi Kani authored
      commit 4e3f0701 upstream.
      
      __add_badblock_range() does not account sector alignment when
      it sets 'num_sectors'.  Therefore, an ARS error record range
      spanning across two sectors is set to a single sector length,
      which leaves the 2nd sector unprotected.
      
      Change __add_badblock_range() to set 'num_sectors' properly.
      
      Fixes: 0caeef63 ("libnvdimm: Add a poison list and export badblocks")
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Reviewed-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0fa705dc
    • Vishal Verma's avatar
      libnvdimm, btt: fix btt_rw_page not returning errors · 891c31e1
      Vishal Verma authored
      commit c13c43d5 upstream.
      
      btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any
      IO errors via the rw_page path going unnoticed. the pmem driver recently
      fixed this in e10624f8 pmem: fail io-requests to known bad blocks
      but same problem in BTT went neglected.
      
      Fixes: 5212e11f ("nd_btt: atomic sector updates")
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      891c31e1
    • Devin Heitmueller's avatar
      cx88: Fix regression in initial video standard setting · e82672f4
      Devin Heitmueller authored
      commit 4e0973a9 upstream.
      
      Setting initial standard at the top of cx8800_initdev would cause the
      first call to cx88_set_tvnorm() to return without programming any
      registers (leaving the driver saying it's set to NTSC but the hardware
      isn't programmed).  Even worse, any subsequent attempt to explicitly
      set it to NTSC-M will return success but actually fail to program the
      underlying registers unless first changing the standard to something
      other than NTSC-M.
      
      Set the initial standard later in the process, and make sure the field
      is zero at the beginning to ensure that the call always goes through.
      
      This regression was introduced in the following commit:
      
      commit ccd6f1d4 ("[media] cx88: move width, height and field to core
      struct")
      
      Author: Hans Verkuil <hans.verkuil@cisco.com>
      
      [media] cx88: move width, height and field to core struct
      Signed-off-by: default avatarDevin Heitmueller <dheitmueller@kernellabs.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e82672f4
    • Marek Marczykowski-Górecki's avatar
      x86/xen: allow userspace access during hypercalls · 4d3d3a16
      Marek Marczykowski-Górecki authored
      commit c54590ca upstream.
      
      Userspace application can do a hypercall through /dev/xen/privcmd, and
      some for some hypercalls argument is a pointers to user-provided
      structure. When SMAP is supported and enabled, hypervisor can't access.
      So, lets allow it.
      
      The same applies to HYPERVISOR_dm_op, where additionally privcmd driver
      carefully verify buffer addresses.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      [HYPERVISOR_dm_op dropped - not present until 4.11]
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d3d3a16
    • Mikulas Patocka's avatar
      md: don't use flush_signals in userspace processes · 03c1d9d4
      Mikulas Patocka authored
      commit f9c79bc0 upstream.
      
      The function flush_signals clears all pending signals for the process. It
      may be used by kernel threads when we need to prepare a kernel thread for
      responding to signals. However using this function for an userspaces
      processes is incorrect - clearing signals without the program expecting it
      can cause misbehavior.
      
      The raid1 and raid5 code uses flush_signals in its request routine because
      it wants to prepare for an interruptible wait. This patch drops
      flush_signals and uses sigprocmask instead to block all signals (including
      SIGKILL) around the schedule() call. The signals are not lost, but the
      schedule() call won't respond to them.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Acked-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03c1d9d4
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: gadget: disable all eps when the driver stops · dbc969ca
      Yoshihiro Shimoda authored
      commit b8b9c974 upstream.
      
      A gadget driver will not disable eps immediately when ->disconnect()
      is called. But, since this driver assumes all eps stop after
      the ->disconnect(), unexpected behavior happens (especially in system
      suspend).
      So, this patch disables all eps in usbhsg_try_stop(). After disabling
      eps by renesas_usbhs driver, since some functions will be called by
      both a gadget and renesas_usbhs driver, renesas_usbhs driver should
      protect uep->pipe. To protect uep->pipe easily, this patch adds a new
      lock in struct usbhsg_uep.
      
      Fixes: 2f98382d ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbc969ca
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: fix usbhsc_resume() for !USBHSF_RUNTIME_PWCTRL · 5433bfcc
      Yoshihiro Shimoda authored
      commit 59a0879a upstream.
      
      This patch fixes an issue that some registers may be not initialized
      after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise,
      if a cable is not connected, the driver will not enable INTENB0.VBSE
      after resume. And then, the driver cannot detect the VBUS.
      
      Fixes: ca8a282a ("usb: gadget: renesas_usbhs: add suspend/resume support")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5433bfcc
    • Johan Hovold's avatar
      USB: cdc-acm: add device-id for quirky printer · a74779d8
      Johan Hovold authored
      commit fe855789 upstream.
      
      Add device-id entry for DATECS FP-2000 fiscal printer needing the
      NO_UNION_NORMAL quirk.
      Reported-by: default avatarAnton Avramov <lukav@lukav.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a74779d8
    • Colin Ian King's avatar
      usb: storage: return on error to avoid a null pointer dereference · 8665f40a
      Colin Ian King authored
      commit 446230f5 upstream.
      
      When us->extra is null the driver is not initialized, however, a
      later call to osd200_scsi_to_ata is made that dereferences
      us->extra, causing a null pointer dereference.  The code
      currently detects and reports that the driver is not initialized;
      add a return to avoid the subsequent dereference issue in this
      check.
      
      Thanks to Alan Stern for pointing out that srb->result needs setting
      to DID_ERROR << 16
      
      Detected by CoverityScan, CID#100308 ("Dereference after null check")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8665f40a
    • Devin Heitmueller's avatar
      mxl111sf: Fix driver to use heap allocate buffers for USB messages · 8bc51b4f
      Devin Heitmueller authored
      commit d90b336f upstream.
      
      The recent changes in 4.9 to mandate USB buffers be heap allocated
      broke this driver, which was allocating the buffers on the stack.
      This resulted in the device failing at initialization.
      
      Introduce dedicated send/receive buffers as part of the state
      structure, and add a mutex to protect access to them.
      
      Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass
      the pointer to the state struct rather than the device, since
      we need it inside the function to access the buffers and the
      mutex.  This patch adjusts the callers to match the API change.
      Signed-off-by: default avatarDevin Heitmueller <dheitmueller@kernellabs.com>
      Reported-by: default avatarDoug Lung <dlung0@gmail.com>
      Cc: Michael Ira Krufky <mkrufky@linuxtv.org>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8bc51b4f
    • Jiahau Chang's avatar
      xhci: Bad Ethernet performance plugged in ASM1042A host · 24a950e1
      Jiahau Chang authored
      commit 9da5a109 upstream.
      
      When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
      performance was manifesting in Web browser use (like download
      large file such as ISO image). It is known limitation of
      ASM1042A that is not compatible with driver scheduling,
      As a workaround we can modify flow control handling of ASM1042A.
      The register we modify is changes the behavior
      
      [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias]
      Signed-off-by: default avatarJiahau Chang <Lars_chang@asmedia.com.tw>
      Signed-off-by: default avatarIan Pilcher <arequipeno@gmail.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24a950e1
    • Mathias Nyman's avatar
      xhci: Fix NULL pointer dereference when cleaning up streams for removed host · 01845a83
      Mathias Nyman authored
      commit 4b895868 upstream.
      
      This off by one in stream_id indexing caused NULL pointer dereference and
      soft lockup on machines with USB attached SCSI devices connected to a
      hotpluggable xhci controller.
      
      The code that cleans up pending URBs for dead hosts tried to dereference
      a stream ring at the invalid stream_id 0.
      ep->stream_info->stream_rings[0] doesn't point to a ring.
      
      Start looping stream_id from 1 like in all the other places in the driver,
      and check that the ring exists before trying to kill URBs on it.
      Reported-by: default avatarrocko r <rockorequin@gmail.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01845a83
    • Mathias Nyman's avatar
      xhci: fix 20000ms port resume timeout · bf044088
      Mathias Nyman authored
      commit a54408d0 upstream.
      
      A uncleared PLC (port link change) bit will prevent furuther port event
      interrupts for that port. Leaving it uncleared caused get_port_status()
      to timeout after 20000ms while waiting to get the final port event
      interrupt for resume -> U0 state change.
      
      This is a targeted fix for a specific case where we get a port resume event
      racing with xhci resume. The port event interrupt handler notices xHC is
      not yet running and bails out early, leaving PLC uncleared.
      
      The whole xhci port resuming needs more attention, but while working on it
      it anyways makes sense to always ensure PLC is cleared in get_port_status
      before setting a new link state and waiting for its completion.
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf044088
    • Julian Anastasov's avatar
      ipvs: SNAT packet replies only for NATed connections · 445ea109
      Julian Anastasov authored
      commit 3c5ab3f3 upstream.
      
      We do not check if packet from real server is for NAT
      connection before performing SNAT. This causes problems
      for setups that use DR/TUN and allow local clients to
      access the real server directly, for example:
      
      - local client in director creates IPVS-DR/TUN connection
      CIP->VIP and the request packets are routed to RIP.
      Talks are finished but IPVS connection is not expired yet.
      
      - second local client creates non-IPVS connection CIP->RIP
      with same reply tuple RIP->CIP and when replies are received
      on LOCAL_IN we wrongly assign them for the first client
      connection because RIP->CIP matches the reply direction.
      As result, IPVS SNATs replies for non-IPVS connections.
      
      The problem is more visible to local UDP clients but in rare
      cases it can happen also for TCP or remote clients when the
      real server sends the reply traffic via the director.
      
      So, better to be more precise for the reply traffic.
      As replies are not expected for DR/TUN connections, better
      to not touch them.
      Reported-by: default avatarNick Moriarty <nick.moriarty@york.ac.uk>
      Tested-by: default avatarNick Moriarty <nick.moriarty@york.ac.uk>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      445ea109
    • Chen Yu's avatar
      PCI/PM: Restore the status of PCI devices across hibernation · 33780512
      Chen Yu authored
      commit e60514bd upstream.
      
      Currently we saw a lot of "No irq handler" errors during hibernation, which
      caused the system hang finally:
      
        ata4.00: qc timeout (cmd 0xec)
        ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
        ata4.00: revalidation failed (errno=-5)
        ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
        do_IRQ: 31.151 No irq handler for vector
      
      According to above logs, there is an interrupt triggered and it is
      dispatched to CPU31 with a vector number 151, but there is no handler for
      it, thus this IRQ will not get acked and will cause an IRQ flood which
      kills the system.  To be more specific, the 31.151 is an interrupt from the
      AHCI host controller.
      
      After some investigation, the reason why this issue is triggered is because
      the thaw_noirq() function does not restore the MSI/MSI-X settings across
      hibernation.
      
      The scenario is illustrated below:
      
        1. Before hibernation, IRQ 34 is the handler for the AHCI device, which
           is bound to CPU31.
      
        2. Hibernation starts, the AHCI device is put into low power state.
      
        3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to
           the last alive one - CPU0.
      
        4. After the snapshot has been created, all the nonboot CPUs are brought
           up again; IRQ 34 remains bound to CPU0.
      
        5. AHCI devices are put into D0.
      
        6. The snapshot is written to the disk.
      
      The issue is triggered in step 6.  The AHCI interrupt should be delivered
      to CPU0, however it is delivered to the original CPU31 instead, which
      causes the "No irq handler" issue.
      
      Ying Huang has provided a clue that, in step 3 it is possible that writing
      to the register might not take effect as the PCI devices have been
      suspended.
      
      In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but
      in fact it is not.  In __pci_write_msi_msg(), if the device is already in
      low power state, the low level MSI message entry will not be updated but
      cached.  During the device restore process after a normal suspend/resume,
      pci_restore_msi_state() writes the cached MSI back to the hardware.
      
      But this is not the case for hibernation.  pci_restore_msi_state() is not
      currently called in pci_pm_thaw_noirq(), although pci_save_state() has
      saved the necessary PCI cached information in pci_pm_freeze_noirq().
      
      Restore the PCI status for the device during hibernation.  Otherwise the
      status might be lost across hibernation (for example, settings for MSI,
      MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation.
      Suggested-by: default avatarYing Huang <ying.huang@intel.com>
      Suggested-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarChen Yu <yu.c.chen@intel.com>
      [bhelgaas: changelog]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: Ying Huang <ying.huang@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33780512
    • Shawn Lin's avatar
      PCI: rockchip: Use normal register bank for config accessors · f257f4bf
      Shawn Lin authored
      commit dc8cca5e upstream.
      
      Rockchip's RC has two banks of registers for the root port: a normal bank
      that is strictly compatible with the PCIe spec, and a privileged bank that
      can be used to change RO bits of root port registers.
      
      When probing the RC driver, we use the privileged bank to do some basic
      setup work as some RO bits are hw-inited to wrong value.  But we didn't
      change to the normal bank after probing the driver.
      
      This leads to a serious problem when the PME code tries to clear the PME
      status by writing PCI_EXP_RTSTA_PME to the register of PCI_EXP_RTSTA.  Per
      PCIe 3.0 spec, section 7.8.14, the PME status bit is RW1C.  So the PME code
      is doing the right thing to clear the PME status but we find the RC doesn't
      clear it but actually setting it to one.  So finally the system trap in
      pcie_pme_work_fn() as PCI_EXP_RTSTA_PME is true now forever.  This issue
      can be reproduced by booting kernel with pci=nomsi.
      
      Use the normal register bank for the PCI config accessors.  The privileged
      bank is used only internally by this driver.
      
      Fixes: e77f847d ("PCI: rockchip: Add Rockchip PCIe controller support")
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
      Cc: Brian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f257f4bf
    • Bjorn Helgaas's avatar
      PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11 · 13b2f9f9
      Bjorn Helgaas authored
      commit 13cfc732 upstream.
      
      Neither soft poweroff (transition to ACPI power state S5) nor
      suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and
      11,5.
      
      The problem is related to the [mem 0x7fa00000-0x7fbfffff] space.  When we
      use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI
      Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work
      anymore.
      
      Linux does a soft poweroff (transition to S5) by writing to PM1_CNT.  The
      theory about why this doesn't work is:
      
        - The write to PM1_CNT causes an SMI
        - The BIOS SMI handler depends on something in
          [mem 0x7fa00000-0x7fbfffff]
        - When Linux assigns [mem 0x7fa00000-0x7fbfffff] to the 00:1c.0 Port, it
          covers up whatever the SMI handler uses, so the SMI handler no longer
          works correctly
      
      Reserve the [mem 0x7fa00000-0x7fbfffff] space so we don't assign it to
      anything.
      
      This is voodoo programming, since we don't know what the real conflict is,
      but we've failed to find the root cause.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
      Tested-by: thejoe@gmail.com
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Chen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13b2f9f9
    • Herbert Xu's avatar
      af_key: Fix sadb_x_ipsecrequest parsing · 3c17d418
      Herbert Xu authored
      commit 096f41d3 upstream.
      
      The parsing of sadb_x_ipsecrequest is broken in a number of ways.
      First of all we're not verifying sadb_x_ipsecrequest_len.  This
      is needed when the structure carries addresses at the end.  Worse
      we don't even look at the length when we parse those optional
      addresses.
      
      The migration code had similar parsing code that's better but
      it also has some deficiencies.  The length is overcounted first
      of all as it includes the header itself.  It also fails to check
      the length before dereferencing the sa_family field.
      
      This patch fixes those problems in parse_sockaddr_pair and then
      uses it in parse_ipsecrequest.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c17d418
    • Benjamin Herrenschmidt's avatar
      powerpc/mm/radix: Properly clear process table entry · 3b7babc6
      Benjamin Herrenschmidt authored
      commit c6bb0b8d upstream.
      
      On radix, the process table entry we want to clear when destroying a
      context is entry 0, not entry 1. This has no *immediate* consequence
      on Power9, but it can cause other bugs to become worse.
      
      Fixes: 7e381c0f ("powerpc/mm/radix: Add mmu context handling callback for radix")
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b7babc6
    • Oliver O'Halloran's avatar
      powerpc/asm: Mark cr0 as clobbered in mftb() · 88481a2c
      Oliver O'Halloran authored
      commit 2400fd82 upstream.
      
      The workaround for the CELL timebase bug does not correctly mark cr0 as
      being clobbered. This means GCC doesn't know that the asm block changes cr0 and
      might leave the result of an unrelated comparison in cr0 across the block, which
      we then trash, leading to basically random behaviour.
      
      Fixes: 859deea9 ("[POWERPC] Cell timebase bug workaround")
      Signed-off-by: default avatarOliver O'Halloran <oohall@gmail.com>
      [mpe: Tweak change log and flag for stable]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88481a2c
    • Anton Blanchard's avatar
      powerpc: Fix emulation of mfocrf in emulate_step() · 5e35ee24
      Anton Blanchard authored
      commit 64e756c5 upstream.
      
      From POWER4 onwards, mfocrf() only places the specified CR field into
      the destination GPR, and the rest of it is set to 0. The PowerPC AS
      from version 3.0 now requires this behaviour.
      
      The emulation code currently puts the entire CR into the destination GPR.
      Fix it.
      
      Fixes: 6888199f ("[POWERPC] Emulate more instructions in software")
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e35ee24
    • Anton Blanchard's avatar
      powerpc: Fix emulation of mcrf in emulate_step() · 53a28216
      Anton Blanchard authored
      commit 87c4b83e upstream.
      
      The mcrf emulation code was using the CR field number directly as the shift
      value, without taking into account that CR fields are numbered from 0-7 starting
      at the high bits. That meant it was looking at the CR fields in the reverse
      order.
      
      Fixes: cf87c3f6 ("powerpc: Emulate icbi, mcrf and conditional-trap instructions")
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53a28216
    • Michael Ellerman's avatar
      powerpc/64: Fix atomic64_inc_not_zero() to return an int · 99fc5a22
      Michael Ellerman authored
      commit 01e6a61a upstream.
      
      Although it's not documented anywhere, there is an expectation that
      atomic64_inc_not_zero() returns a result which fits in an int. This is
      the behaviour implemented on all arches except powerpc.
      
      This has caused at least one bug in practice, in the percpu-refcount
      code, where the long result from our atomic64_inc_not_zero() was
      truncated to an int leading to lost references and stuck systems. That
      was worked around in that code in commit 966d2b04 ("percpu-refcount:
      fix reference leak during percpu-atomic transition").
      
      To the best of my grepping abilities there are no other callers
      in-tree which truncate the value, but we should fix it anyway. Because
      the breakage is subtle and potentially very harmful I'm also tagging
      it for stable.
      
      Code generation is largely unaffected because in most cases the
      callers are just using the result for a test anyway. In particular the
      case of fget() that was mentioned in commit a6cf7ed5
      ("powerpc/atomic: Implement atomic*_inc_not_zero") generates exactly
      the same code.
      
      Fixes: a6cf7ed5 ("powerpc/atomic: Implement atomic*_inc_not_zero")
      Noticed-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99fc5a22
    • Balbir Singh's avatar
      powerpc/pseries: Fix passing of pp0 in updatepp() and updateboltedpp() · d638c858
      Balbir Singh authored
      commit e71ff982 upstream.
      
      Once upon a time there were only two PP (page protection) bits. In ISA
      2.03 an additional PP bit was added, but because of the layout of the
      HPTE it could not be made contiguous with the existing PP bits.
      
      The result is that we now have three PP bits, named pp0, pp1, pp2,
      where pp0 occupies bit 63 of dword 1 of the HPTE and pp1 and pp2
      occupy bits 1 and 0 respectively. Until recently Linux hasn't used
      pp0, however with the addition of _PAGE_KERNEL_RO we started using it.
      
      The problem arises in the LPAR code, where we need to translate the PP
      bits into the argument for the H_PROTECT hypercall. Currently the code
      only passes bits 0-2 of newpp, which covers pp1, pp2 and N (no
      execute), meaning pp0 is not passed to the hypervisor at all.
      
      We can't simply pass it through in bit 63, as that would collide with a
      different field in the flags argument, as defined in PAPR. Instead we
      have to shift it down to bit 8 (IBM bit 55).
      
      Fixes: e58e87ad ("powerpc/mm: Update _PAGE_KERNEL_RO")
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      [mpe: Simplify the test, rework change log]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d638c858
    • Bart Van Assche's avatar
      xen/scsiback: Fix a TMR related use-after-free · 71b1caea
      Bart Van Assche authored
      commit 9f4ab18a upstream.
      
      scsiback_release_cmd() must not dereference se_cmd->se_tmr_req
      because that memory is freed by target_free_cmd_mem() before
      scsiback_release_cmd() is called. Fix this use-after-free by
      inlining struct scsiback_tmr into struct vscsibk_pend.
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: David Disseldorp <ddiss@suse.de>
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71b1caea
    • Nicholas Bellinger's avatar
      iscsi-target: Add login_keys_workaround attribute for non RFC initiators · 732e3c76
      Nicholas Bellinger authored
      commit 138d351e upstream.
      
      This patch re-introduces part of a long standing login workaround that
      was recently dropped by:
      
        commit 1c99de98
        Author: Nicholas Bellinger <nab@linux-iscsi.org>
        Date:   Sun Apr 2 13:36:44 2017 -0700
      
            iscsi-target: Drop work-around for legacy GlobalSAN initiator
      
      Namely, the workaround for FirstBurstLength ended up being required by
      Mellanox Flexboot PXE boot ROMs as reported by Robert.
      
      So this patch re-adds the work-around for FirstBurstLength within
      iscsi_check_proposer_for_optional_reply(), and makes the key optional
      to respond when the initiator does not propose, nor respond to it.
      
      Also as requested by Arun, this patch introduces a new TPG attribute
      named 'login_keys_workaround' that controls the use of both the
      FirstBurstLength workaround, as well as the two other existing
      workarounds for gPXE iSCSI boot client.
      
      By default, the workaround is enabled with login_keys_workaround=1,
      since Mellanox FlexBoot requires it, and Arun has verified the Qlogic
      MSFT initiator already proposes FirstBurstLength, so it's uneffected
      by this re-adding this part of the original work-around.
      Reported-by: default avatarRobert LeBlanc <robert@leblancnet.us>
      Cc: Robert LeBlanc <robert@leblancnet.us>
      Reviewed-by: default avatarArun Easi <arun.easi@cavium.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      732e3c76
    • Ewan D. Milne's avatar
      scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state · fc866b29
      Ewan D. Milne authored
      commit f9279c96 upstream.
      
      The addition of the STARGET_REMOVE state had the side effect of
      introducing a race condition that can cause a crash.
      
      scsi_target_reap_ref_release() checks the starget->state to
      see if it still in STARGET_CREATED, and if so, skips calling
      transport_remove_device() and device_del(), because the starget->state
      is only set to STARGET_RUNNING after scsi_target_add() has called
      device_add() and transport_add_device().
      
      However, if an rport loss occurs while a target is being scanned,
      it can happen that scsi_remove_target() will be called while the
      starget is still in the STARGET_CREATED state.  In this case, the
      starget->state will be set to STARGET_REMOVE, and as a result,
      scsi_target_reap_ref_release() will take the wrong path.  The end
      result is a panic:
      
      [ 1255.356653] Oops: 0000 [#1] SMP
      [ 1255.360154] Modules linked in: x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel ghash_clmulni_i
      [ 1255.393234] CPU: 5 PID: 149 Comm: kworker/u96:4 Tainted: G        W       4.11.0+ #8
      [ 1255.401879] Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013
      [ 1255.410327] Workqueue: scsi_wq_6 fc_scsi_scan_rport [scsi_transport_fc]
      [ 1255.417720] task: ffff88060ca8c8c0 task.stack: ffffc900048a8000
      [ 1255.424331] RIP: 0010:kernfs_find_ns+0x13/0xc0
      [ 1255.429287] RSP: 0018:ffffc900048abbf0 EFLAGS: 00010246
      [ 1255.435123] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [ 1255.443083] RDX: 0000000000000000 RSI: ffffffff8188d659 RDI: 0000000000000000
      [ 1255.451043] RBP: ffffc900048abc10 R08: 0000000000000000 R09: 0000012433fe0025
      [ 1255.459005] R10: 0000000025e5a4b5 R11: 0000000025e5a4b5 R12: ffffffff8188d659
      [ 1255.466972] R13: 0000000000000000 R14: ffff8805f55e5088 R15: 0000000000000000
      [ 1255.474931] FS:  0000000000000000(0000) GS:ffff880616b40000(0000) knlGS:0000000000000000
      [ 1255.483959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1255.490370] CR2: 0000000000000068 CR3: 0000000001c09000 CR4: 00000000000406e0
      [ 1255.498332] Call Trace:
      [ 1255.501058]  kernfs_find_and_get_ns+0x31/0x60
      [ 1255.505916]  sysfs_unmerge_group+0x1d/0x60
      [ 1255.510498]  dpm_sysfs_remove+0x22/0x60
      [ 1255.514783]  device_del+0xf4/0x2e0
      [ 1255.518577]  ? device_remove_file+0x19/0x20
      [ 1255.523241]  attribute_container_class_device_del+0x1a/0x20
      [ 1255.529457]  transport_remove_classdev+0x4e/0x60
      [ 1255.534607]  ? transport_add_class_device+0x40/0x40
      [ 1255.540046]  attribute_container_device_trigger+0xb0/0xc0
      [ 1255.546069]  transport_remove_device+0x15/0x20
      [ 1255.551025]  scsi_target_reap_ref_release+0x25/0x40
      [ 1255.556467]  scsi_target_reap+0x2e/0x40
      [ 1255.560744]  __scsi_scan_target+0xaa/0x5b0
      [ 1255.565312]  scsi_scan_target+0xec/0x100
      [ 1255.569689]  fc_scsi_scan_rport+0xb1/0xc0 [scsi_transport_fc]
      [ 1255.576099]  process_one_work+0x14b/0x390
      [ 1255.580569]  worker_thread+0x4b/0x390
      [ 1255.584651]  kthread+0x109/0x140
      [ 1255.588251]  ? rescuer_thread+0x330/0x330
      [ 1255.592730]  ? kthread_park+0x60/0x60
      [ 1255.596815]  ret_from_fork+0x29/0x40
      [ 1255.600801] Code: 24 08 48 83 42 40 01 5b 41 5c 5d c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90
      [ 1255.621876] RIP: kernfs_find_ns+0x13/0xc0 RSP: ffffc900048abbf0
      [ 1255.628479] CR2: 0000000000000068
      [ 1255.632756] ---[ end trace 34a69ba0477d036f ]---
      
      Fix this by adding another scsi_target state STARGET_CREATED_REMOVE
      to distinguish this case.
      
      Fixes: f05795d3 ("scsi: Add intermediate STARGET_REMOVE state to scsi_target_state")
      Reported-by: default avatarDavid Jeffery <djeffery@redhat.com>
      Signed-off-by: default avatarEwan D. Milne <emilne@redhat.com>
      Reviewed-by: default avatarLaurence Oberman <loberman@redhat.com>
      Tested-by: default avatarLaurence Oberman <loberman@redhat.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc866b29
    • Maurizio Lombardi's avatar
      scsi: ses: do not add a device to an enclosure if enclosure_add_links() fails. · 542c097f
      Maurizio Lombardi authored
      commit 62e62ffd upstream.
      
      The enclosure_add_device() function should fail if it can't create the
      relevant sysfs links.
      Signed-off-by: default avatarMaurizio Lombardi <mlombard@redhat.com>
      Tested-by: default avatarDouglas Miller <dougmill@linux.vnet.ibm.com>
      Acked-by: default avatarJames Bottomley <jejb@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      542c097f
    • Krzysztof Kozlowski's avatar
      PM / Domains: Fix unsafe iteration over modified list of domains · d2bb0af4
      Krzysztof Kozlowski authored
      commit a7e2d1bc upstream.
      
      of_genpd_remove_last() iterates over list of domains and removes
      matching element thus it has to use safe version of list iteration.
      
      Fixes: 17926551 (PM / Domains: Add support for removing nested PM domains by provider)
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Acked-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2bb0af4