1. 15 Apr, 2016 4 commits
    • Stefan Haberland's avatar
      s390/dasd: add query host access to volume support · 5a3b7b11
      Stefan Haberland authored
      With this feature, applications can query if a DASD volume is online
      to another operating system instances by checking the online status of
      all attached hosts from the storage server.
      Reviewed-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarStefan Haberland <stefan.haberland@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      5a3b7b11
    • Heiko Carstens's avatar
      s390: add CPU_BIG_ENDIAN config option · 2fd92273
      Heiko Carstens authored
      Make sure that s390 appears to be a big endian machine by defining
      this config option.
      
      Without this s390 appears to be little endian as seen by e.g. the
      recordmount script: "perl ./scripts/recordmcount.pl "s390" "little"
      "64""
      This has no practical impact within the script since the endian
      variable is only evaluated for mips. However there are already a
      couple of common code places which evaluate this config option. None
      of them is relevant for s390 currently though.
      
      To avoid any issues in the future (and fix the recordmcount oddity)
      add the new config option.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      2fd92273
    • Heiko Carstens's avatar
      s390/spinlock: avoid yield to non existent cpu · 84976952
      Heiko Carstens authored
      arch_spin_lock_wait_flags() checks if a spinlock is not held before
      trying a compare and swap instruction. If the lock is unlocked it
      tries the compare and swap instruction, however if a different cpu
      grabbed the lock in the meantime the instruction will fail as
      expected.
      
      Subsequently the arch_spin_lock_wait_flags() incorrectly tries to
      figure out if the cpu that holds the lock is running. However it is
      using the wrong cpu number for this (-1) and then will also yield the
      current cpu to the wrong cpu.
      
      Fix this by adding a missing continue statement.
      
      Fixes: 470ada6b ("s390/spinlock: refactor arch_spin_lock_wait[_flags]")
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      84976952
    • Gerald Schaefer's avatar
      s390/dcssblk: fix possible deadlock in remove vs. per-device attributes · 1378a683
      Gerald Schaefer authored
      dcssblk_remove_store() holds the dcssblk_devices_sem semaphore while
      calling device_unregister(), which in turn tries to acquire the kernfs
      kn->dev_map rwsem for the device sysfs subtree. The same rwsem is also
      acquired when using the per-device sysfs attributes in the device sub-tree,
      and the attribute handlers then also acquire the dcssblk_devices_sem.
      
      This can lead to a deadlock when removing a DCSS while concurrently
      reading from / writing to one of its sysfs attributes. The following
      lockdep warning hinted towards the issue (CPU0 = dcssblk_remove_store,
      CPU1 = dcssblk_shared_store):
      
      [   76.496047]  Possible unsafe locking scenario:
      
      [   76.496054]        CPU0                    CPU1
      [   76.496059]        ----                    ----
      [   76.496087]   lock(&dcssblk_devices_sem);
      [   76.496090]                                lock(s_active#175);
      [   76.496106]                                lock(&dcssblk_devices_sem);
      [   76.496110]   lock(s_active#175);
      [   76.496115]
       *** DEADLOCK ***
      
      Fix this by releasing the dcssblk_devices_sem semaphore, which only
      protects internal DCSS data, before calling device_unregister().
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      1378a683
  2. 01 Apr, 2016 13 commits
  3. 31 Mar, 2016 9 commits
  4. 30 Mar, 2016 5 commits
  5. 29 Mar, 2016 6 commits
  6. 28 Mar, 2016 3 commits