1. 15 Mar, 2017 25 commits
    • Peter Zijlstra's avatar
      orangefs: Use RCU for destroy_inode · b2b0f6ff
      Peter Zijlstra authored
      commit 0695d7dc upstream.
      
      freeing of inodes must be RCU-delayed on all filesystems
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2b0f6ff
    • Eric W. Biederman's avatar
      fs: Better permission checking for submounts · d3381fab
      Eric W. Biederman authored
      commit 93faccbb upstream.
      
      To support unprivileged users mounting filesystems two permission
      checks have to be performed: a test to see if the user allowed to
      create a mount in the mount namespace, and a test to see if
      the user is allowed to access the specified filesystem.
      
      The automount case is special in that mounting the original filesystem
      grants permission to mount the sub-filesystems, to any user who
      happens to stumble across the their mountpoint and satisfies the
      ordinary filesystem permission checks.
      
      Attempting to handle the automount case by using override_creds
      almost works.  It preserves the idea that permission to mount
      the original filesystem is permission to mount the sub-filesystem.
      Unfortunately using override_creds messes up the filesystems
      ordinary permission checks.
      
      Solve this by being explicit that a mount is a submount by introducing
      vfs_submount, and using it where appropriate.
      
      vfs_submount uses a new mount internal mount flags MS_SUBMOUNT, to let
      sget and friends know that a mount is a submount so they can take appropriate
      action.
      
      sget and sget_userns are modified to not perform any permission checks
      on submounts.
      
      follow_automount is modified to stop using override_creds as that
      has proven problemantic.
      
      do_mount is modified to always remove the new MS_SUBMOUNT flag so
      that we know userspace will never by able to specify it.
      
      autofs4 is modified to stop using current_real_cred that was put in
      there to handle the previous version of submount permission checking.
      
      cifs is modified to pass the mountpoint all of the way down to vfs_submount.
      
      debugfs is modified to pass the mountpoint all of the way down to
      trace_automount by adding a new parameter.  To make this change easier
      a new typedef debugfs_automount_t is introduced to capture the type of
      the debugfs automount function.
      
      Fixes: 069d5ac9 ("autofs:  Fix automounts by using current_real_cred()->uid")
      Fixes: aeaa4a79 ("fs: Call d_automount with the filesystems creds")
      Reviewed-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Reviewed-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3381fab
    • Bart Van Assche's avatar
      IB/srp: Fix race conditions related to task management · 48e2181b
      Bart Van Assche authored
      commit 0a6fdbde upstream.
      
      Avoid that srp_process_rsp() overwrites the status information
      in ch if the SRP target response timed out and processing of
      another task management function has already started. Avoid that
      issuing multiple task management functions concurrently triggers
      list corruption. This patch prevents that the following stack
      trace appears in the system log:
      
      WARNING: CPU: 8 PID: 9269 at lib/list_debug.c:52 __list_del_entry_valid+0xbc/0xc0
      list_del corruption. prev->next should be ffffc90004bb7b00, but was ffff8804052ecc68
      CPU: 8 PID: 9269 Comm: sg_reset Tainted: G        W       4.10.0-rc7-dbg+ #3
      Call Trace:
       dump_stack+0x68/0x93
       __warn+0xc6/0xe0
       warn_slowpath_fmt+0x4a/0x50
       __list_del_entry_valid+0xbc/0xc0
       wait_for_completion_timeout+0x12e/0x170
       srp_send_tsk_mgmt+0x1ef/0x2d0 [ib_srp]
       srp_reset_device+0x5b/0x110 [ib_srp]
       scsi_ioctl_reset+0x1c7/0x290
       scsi_ioctl+0x12a/0x420
       sd_ioctl+0x9d/0x100
       blkdev_ioctl+0x51e/0x9f0
       block_ioctl+0x38/0x40
       do_vfs_ioctl+0x8f/0x700
       SyS_ioctl+0x3c/0x70
       entry_SYSCALL_64_fastpath+0x18/0xad
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Israel Rukshin <israelr@mellanox.com>
      Cc: Max Gurtovoy <maxg@mellanox.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Cc: Steve Feeley <Steve.Feeley@sandisk.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48e2181b
    • Bart Van Assche's avatar
      IB/srp: Avoid that duplicate responses trigger a kernel bug · d5d1d2cc
      Bart Van Assche authored
      commit 6cb72bc1 upstream.
      
      After srp_process_rsp() returns there is a short time during which
      the scsi_host_find_tag() call will return a pointer to the SCSI
      command that is being completed. If during that time a duplicate
      response is received, avoid that the following call stack appears:
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: srp_recv_done+0x450/0x6b0 [ib_srp]
      Oops: 0000 [#1] SMP
      CPU: 10 PID: 0 Comm: swapper/10 Not tainted 4.10.0-rc7-dbg+ #1
      Call Trace:
       <IRQ>
       __ib_process_cq+0x4b/0xd0 [ib_core]
       ib_poll_handler+0x1d/0x70 [ib_core]
       irq_poll_softirq+0xba/0x120
       __do_softirq+0xba/0x4c0
       irq_exit+0xbe/0xd0
       smp_apic_timer_interrupt+0x38/0x50
       apic_timer_interrupt+0x90/0xa0
       </IRQ>
      RIP: srp_recv_done+0x450/0x6b0 [ib_srp] RSP: ffff88046f483e20
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Israel Rukshin <israelr@mellanox.com>
      Cc: Max Gurtovoy <maxg@mellanox.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Cc: Steve Feeley <Steve.Feeley@sandisk.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5d1d2cc
    • Bart Van Assche's avatar
      IB/SRP: Avoid using IB_MR_TYPE_SG_GAPS · 516a12ab
      Bart Van Assche authored
      commit d6c58dc4 upstream.
      
      Tests have shown that the following error message is reported when
      using SG-GAPS registration with an mlx5 adapter:
      
      scsi host1: ib_srp: failed RECV status WR flushed (5) for CQE ffff880bd4270eb0
      00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000
      00000000 0f007806 2500002a ad9fafd1
      scsi host1: ib_srp: reconnect succeeded
      mlx5_0:dump_cqe:262:(pid 7369): dump error cqe
      00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000
      00000000 0f007806 25000032 00105dd0
      scsi host1: ib_srp: failed FAST REG status memory management operation error (6) for CQE ffff880b92860138
      
      Hence avoid using SG-GAPS memory registrations. Additionally,
      always configure the blk_queue_virt_boundary() to avoid to trigger
      a mapping failure when using adapters that support SG-GAPS (e.g.
      mlx5).
      
      Fixes: commit ad8e66b4 ("IB/srp: fix mr allocation when the device supports sg gaps")
      Fixes: commit 509c5f33 ("IB/srp: Prevent mapping failures")
      Reported-by: default avatarLaurence Oberman <loberman@redhat.com>
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Israel Rukshin <israelr@mellanox.com>
      Cc: Max Gurtovoy <maxg@mellanox.com>
      Cc: Leon Romanovsky <leonro@mellanox.com>
      Cc: Mark Bloch <markb@mellanox.com>
      Cc: Yuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      516a12ab
    • Leon Romanovsky's avatar
      IB/mlx5: Fix out-of-bound access · 04f16db0
      Leon Romanovsky authored
      commit 0fd27a88 upstream.
      
      When we initialize buffer to create SRQ in kernel,
      the number of pages was less than actually used in
      following mlx5_fill_page_array().
      
      Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters")
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarEli Cohen <eli@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04f16db0
    • Erez Shitrit's avatar
      IB/IPoIB: Add destination address when re-queue packet · 2e539fa4
      Erez Shitrit authored
      commit 2b084176 upstream.
      
      When sending packet to destination that was not resolved yet
      via path query, the driver keeps the skb and tries to re-send it
      again when the path is resolved.
      
      But when re-sending via dev_queue_xmit the kernel doesn't call
      to dev_hard_header, so IPoIB needs to keep 20 bytes in the skb
      and to put the destination address inside them.
      
      In that way the dev_start_xmit will have the correct destination,
      and the driver won't take the destination from the skb->data, while
      nothing exists there, which causes to packet be be dropped.
      
      The test flow is:
      1. Run the SM on remote node,
      2. Restart the driver.
      4. Ping some destination,
      3. Observe that first ICMP request will be dropped.
      
      Fixes: fc791b63 ("IB/ipoib: move back IB LL address into the hard header")
      Signed-off-by: default avatarErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: default avatarNoa Osherovich <noaos@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Tested-by: default avatarYuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e539fa4
    • Feras Daoud's avatar
      IB/ipoib: Fix deadlock between rmmod and set_mode · 1626076b
      Feras Daoud authored
      commit 0a0007f2 upstream.
      
      When calling set_mode from sys/fs, the call flow locks the sys/fs lock
      first and then tries to lock rtnl_lock (when calling ipoib_set_mod).
      On the other hand, the rmmod call flow takes the rtnl_lock first
      (when calling unregister_netdev) and then tries to take the sys/fs
      lock. Deadlock a->b, b->a.
      
      The problem starts when ipoib_set_mod frees it's rtnl_lck and tries
      to get it after that.
      
          set_mod:
          [<ffffffff8104f2bd>] ? check_preempt_curr+0x6d/0x90
          [<ffffffff814fee8e>] __mutex_lock_slowpath+0x13e/0x180
          [<ffffffff81448655>] ? __rtnl_unlock+0x15/0x20
          [<ffffffff814fed2b>] mutex_lock+0x2b/0x50
          [<ffffffff81448675>] rtnl_lock+0x15/0x20
          [<ffffffffa02ad807>] ipoib_set_mode+0x97/0x160 [ib_ipoib]
          [<ffffffffa02b5f5b>] set_mode+0x3b/0x80 [ib_ipoib]
          [<ffffffff8134b840>] dev_attr_store+0x20/0x30
          [<ffffffff811f0fe5>] sysfs_write_file+0xe5/0x170
          [<ffffffff8117b068>] vfs_write+0xb8/0x1a0
          [<ffffffff8117ba81>] sys_write+0x51/0x90
          [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
      
          rmmod:
          [<ffffffff81279ffc>] ? put_dec+0x10c/0x110
          [<ffffffff8127a2ee>] ? number+0x2ee/0x320
          [<ffffffff814fe6a5>] schedule_timeout+0x215/0x2e0
          [<ffffffff8127cc04>] ? vsnprintf+0x484/0x5f0
          [<ffffffff8127b550>] ? string+0x40/0x100
          [<ffffffff814fe323>] wait_for_common+0x123/0x180
          [<ffffffff81060250>] ? default_wake_function+0x0/0x20
          [<ffffffff8119661e>] ? ifind_fast+0x5e/0xb0
          [<ffffffff814fe43d>] wait_for_completion+0x1d/0x20
          [<ffffffff811f2e68>] sysfs_addrm_finish+0x228/0x270
          [<ffffffff811f2fb3>] sysfs_remove_dir+0xa3/0xf0
          [<ffffffff81273f66>] kobject_del+0x16/0x40
          [<ffffffff8134cd14>] device_del+0x184/0x1e0
          [<ffffffff8144e59b>] netdev_unregister_kobject+0xab/0xc0
          [<ffffffff8143c05e>] rollback_registered+0xae/0x130
          [<ffffffff8143c102>] unregister_netdevice+0x22/0x70
          [<ffffffff8143c16e>] unregister_netdev+0x1e/0x30
          [<ffffffffa02a91b0>] ipoib_remove_one+0xe0/0x120 [ib_ipoib]
          [<ffffffffa01ed95f>] ib_unregister_device+0x4f/0x100 [ib_core]
          [<ffffffffa021f5e1>] mlx4_ib_remove+0x41/0x180 [mlx4_ib]
          [<ffffffffa01ab771>] mlx4_remove_device+0x71/0x90 [mlx4_core]
      
      Fixes: 862096a8 ("IB/ipoib: Add more rtnl_link_ops callbacks")
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarFeras Daoud <ferasda@mellanox.com>
      Signed-off-by: default avatarErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1626076b
    • Eric W. Biederman's avatar
      mnt: Tuck mounts under others instead of creating shadow/side mounts. · 808e83e5
      Eric W. Biederman authored
      commit 1064f874 upstream.
      
      Ever since mount propagation was introduced in cases where a mount in
      propagated to parent mount mountpoint pair that is already in use the
      code has placed the new mount behind the old mount in the mount hash
      table.
      
      This implementation detail is problematic as it allows creating
      arbitrary length mount hash chains.
      
      Furthermore it invalidates the constraint maintained elsewhere in the
      mount code that a parent mount and a mountpoint pair will have exactly
      one mount upon them.  Making it hard to deal with and to talk about
      this special case in the mount code.
      
      Modify mount propagation to notice when there is already a mount at
      the parent mount and mountpoint where a new mount is propagating to
      and place that preexisting mount on top of the new mount.
      
      Modify unmount propagation to notice when a mount that is being
      unmounted has another mount on top of it (and no other children), and
      to replace the unmounted mount with the mount on top of it.
      
      Move the MNT_UMUONT test from __lookup_mnt_last into
      __propagate_umount as that is the only call of __lookup_mnt_last where
      MNT_UMOUNT may be set on any mount visible in the mount hash table.
      
      These modifications allow:
       - __lookup_mnt_last to be removed.
       - attach_shadows to be renamed __attach_mnt and its shadow
         handling to be removed.
       - commit_tree to be simplified
       - copy_tree to be simplified
      
      The result is an easier to understand tree of mounts that does not
      allow creation of arbitrary length hash chains in the mount hash table.
      
      The result is also a very slight userspace visible difference in semantics.
      The following two cases now behave identically, where before order
      mattered:
      
      case 1: (explicit user action)
      	B is a slave of A
      	mount something on A/a , it will propagate to B/a
      	and than mount something on B/a
      
      case 2: (tucked mount)
      	B is a slave of A
      	mount something on B/a
      	and than mount something on A/a
      
      Histroically umount A/a would fail in case 1 and succeed in case 2.
      Now umount A/a succeeds in both configurations.
      
      This very small change in semantics appears if anything to be a bug
      fix to me and my survey of userspace leads me to believe that no programs
      will notice or care of this subtle semantic change.
      
      v2: Updated to mnt_change_mountpoint to not call dput or mntput
      and instead to decrement the counts directly.  It is guaranteed
      that there will be other references when mnt_change_mountpoint is
      called so this is safe.
      
      v3: Moved put_mountpoint under mount_lock in attach_recursive_mnt
          As the locking in fs/namespace.c changed between v2 and v3.
      
      v4: Reworked the logic in propagate_mount_busy and __propagate_umount
          that detects when a mount completely covers another mount.
      
      v5: Removed unnecessary tests whose result is alwasy true in
          find_topper and attach_recursive_mnt.
      
      v6: Document the user space visible semantic difference.
      
      Fixes: b90fa9ae ("[PATCH] shared mount handling: bind and rbind")
      Tested-by: default avatarAndrei Vagin <avagin@virtuozzo.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      808e83e5
    • Gavin Li's avatar
      brcmfmac: fix incorrect event channel deduction · c9b3f317
      Gavin Li authored
      commit 8e290cec upstream.
      
      brcmf_sdio_fromevntchan() was being called on the the data frame
      rather than the software header, causing some frames to be
      mischaracterized as on the event channel rather than the data channel.
      
      This fixes a major performance regression (due to dropped packets). With
      this patch the download speed jumped from 1Mbit/s back up to 40MBit/s due
      to the sheer amount of packets being incorrectly processed.
      
      Fixes: c56caa9d ("brcmfmac: screening firmware event packet")
      Signed-off-by: default avatarGavin Li <git@thegavinli.com>
      Acked-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      [kvalo@codeaurora.org: improve commit logs based on email discussion]
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9b3f317
    • Andrew Donnellan's avatar
      cxl: fix nested locking hang during EEH hotplug · 53d43706
      Andrew Donnellan authored
      commit 171ed0fc upstream.
      
      Commit 14a3ae34 ("cxl: Prevent read/write to AFU config space while AFU
      not configured") introduced a rwsem to fix an invalid memory access that
      occurred when someone attempts to access the config space of an AFU on a
      vPHB whilst the AFU is deconfigured, such as during EEH recovery.
      
      It turns out that it's possible to run into a nested locking issue when EEH
      recovery fails and a full device hotplug is required.
      cxl_pci_error_detected() deconfigures the AFU, taking a writer lock on
      configured_rwsem. When EEH recovery fails, the EEH code calls
      pci_hp_remove_devices() to remove the device, which in turn calls
      cxl_remove() -> cxl_pci_remove_afu() -> pci_deconfigure_afu(), which tries
      to grab the writer lock that's already held.
      
      Standard rwsem semantics don't express what we really want to do here and
      don't allow for nested locking. Fix this by replacing the rwsem with an
      atomic_t which we can control more finely. Allow the AFU to be locked
      multiple times so long as there are no readers.
      
      Fixes: 14a3ae34 ("cxl: Prevent read/write to AFU config space while AFU not configured")
      Signed-off-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53d43706
    • Andrew Donnellan's avatar
      cxl: Prevent read/write to AFU config space while AFU not configured · 411d0b0c
      Andrew Donnellan authored
      commit 14a3ae34 upstream.
      
      During EEH recovery, we deconfigure all AFUs whilst leaving the
      corresponding vPHB and virtual PCI device in place.
      
      If something attempts to interact with the AFU's PCI config space (e.g.
      running lspci) after the AFU has been deconfigured and before it's
      reconfigured, cxl_pcie_{read,write}_config() will read invalid values from
      the deconfigured struct cxl_afu and proceed to Oops when they try to
      dereference pointers that have been set to NULL during deconfiguration.
      
      Add a rwsem to struct cxl_afu so we can prevent interaction with config
      space while the AFU is deconfigured.
      Reported-by: default avatarPradipta Ghosh <pradghos@in.ibm.com>
      Suggested-by: default avatarFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      411d0b0c
    • Thomas Petazzoni's avatar
      net: mvpp2: fix DMA address calculation in mvpp2_txq_inc_put() · 60037aa6
      Thomas Petazzoni authored
      commit 239a3b66 upstream.
      
      When TX descriptors are filled in, the buffer DMA address is split
      between the tx_desc->buf_phys_addr field (high-order bits) and
      tx_desc->packet_offset field (5 low-order bits).
      
      However, when we re-calculate the DMA address from the TX descriptor in
      mvpp2_txq_inc_put(), we do not take tx_desc->packet_offset into
      account. This means that when the DMA address is not aligned on a 32
      bytes boundary, we end up calling dma_unmap_single() with a DMA address
      that was not the one returned by dma_map_single().
      
      This inconsistency is detected by the kernel when DMA_API_DEBUG is
      enabled. We fix this problem by properly calculating the DMA address in
      mvpp2_txq_inc_put().
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60037aa6
    • Heiko Carstens's avatar
      s390: use correct input data address for setup_randomness · e067f68d
      Heiko Carstens authored
      commit 4920e3cf upstream.
      
      The current implementation of setup_randomness uses the stack address
      and therefore the pointer to the SYSIB 3.2.2 block as input data
      address. Furthermore the length of the input data is the number of
      virtual-machine description blocks which is typically one.
      
      This means that typically a single zero byte is fed to
      add_device_randomness.
      
      Fix both of these and use the address of the first virtual machine
      description block as input data address and also use the correct
      length.
      
      Fixes: bcfcbb6b ("s390: add system information as device randomness")
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e067f68d
    • Heiko Carstens's avatar
      s390: make setup_randomness work · 321081d5
      Heiko Carstens authored
      commit da8fd820 upstream.
      
      Commit bcfcbb6b ("s390: add system information as device
      randomness") intended to add some virtual machine specific information
      to the randomness pool.
      
      Unfortunately it uses the page allocator before it is ready to use. In
      result the page allocator always returns NULL and the setup_randomness
      function never adds anything to the randomness pool.
      
      To fix this use memblock_alloc and memblock_free instead.
      
      Fixes: bcfcbb6b ("s390: add system information as device randomness")
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      321081d5
    • Martin Schwidefsky's avatar
      s390: TASK_SIZE for kernel threads · 9d38fd6a
      Martin Schwidefsky authored
      commit fb94a687 upstream.
      
      Return a sensible value if TASK_SIZE if called from a kernel thread.
      
      This gets us around an issue with copy_mount_options that does a magic
      size calculation "TASK_SIZE - (unsigned long)data" while in a kernel
      thread and data pointing to kernel space.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d38fd6a
    • Peter Oberparleiter's avatar
      s390/chsc: Add exception handler for CHSC instruction · dc31841f
      Peter Oberparleiter authored
      commit 77759137 upstream.
      
      Prevent kernel crashes due to unhandled exceptions raised by the CHSC
      instruction which may for example be triggered by invalid ioctl data.
      
      Fixes: 64150adf ("s390/cio: Introduce generic synchronous CHSC IOCTL")
      Signed-off-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Reviewed-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc31841f
    • Michael Holzheu's avatar
      s390/kdump: Use "LINUX" ELF note name instead of "CORE" · 91cfcaa6
      Michael Holzheu authored
      commit a4a81d8e upstream.
      
      In binutils/libbfd (bfd/elf.c) it is enforced that all s390 specific ELF
      notes like e.g. NT_S390_PREFIX or NT_S390_CTRS have "LINUX" specified
      as note name. Otherwise the notes are ignored.
      
      For /proc/vmcore we currently use "CORE" for these notes.
      
      Up to now this has not been a real problem because the dump analysis tool
      "crash" does not check the note name. But it will break all programs that
      use libbfd for processing ELF notes.
      
      So fix this and use "LINUX" for all s390 specific notes to comply with
      libbfd.
      Reported-by: default avatarPhilipp Rudo <prudo@linux.vnet.ibm.com>
      Reviewed-by: default avatarPhilipp Rudo <prudo@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91cfcaa6
    • Gerald Schaefer's avatar
      s390/dcssblk: fix device size calculation in dcssblk_direct_access() · b8481025
      Gerald Schaefer authored
      commit a63f53e3 upstream.
      
      Since commit dd22f551 "block: Change direct_access calling convention",
      the device size calculation in dcssblk_direct_access() is off-by-one.
      This results in bdev_direct_access() always returning -ENXIO because the
      returned value is not page aligned.
      
      Fix this by adding 1 to the dev_sz calculation.
      
      Fixes: dd22f551 ("block: Change direct_access calling convention")
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8481025
    • Julian Wiedmann's avatar
      s390/qdio: clear DSCI prior to scanning multiple input queues · 5cec5e32
      Julian Wiedmann authored
      commit 1e4a382f upstream.
      
      For devices with multiple input queues, tiqdio_call_inq_handlers()
      iterates over all input queues and clears the device's DSCI
      during each iteration. If the DSCI is re-armed during one
      of the later iterations, we therefore do not scan the previous
      queues again.
      The re-arming also raises a new adapter interrupt. But its
      handler does not trigger a rescan for the device, as the DSCI
      has already been erroneously cleared.
      This can result in queue stalls on devices with multiple
      input queues.
      
      Fix it by clearing the DSCI just once, prior to scanning the queues.
      
      As the code is moved in front of the loop, we also need to access
      the DSCI directly (ie irq->dsci) instead of going via each queue's
      parent pointer to the same irq. This is not a functional change,
      and a follow-up patch will clean up the other users.
      
      In practice, this bug only affects CQ-enabled HiperSockets devices,
      ie. devices with sysfs-attribute "hsuid" set. Setting a hsuid is
      needed for AF_IUCV socket applications that use HiperSockets
      communication.
      
      Fixes: 104ea556 ("qdio: support asynchronous delivery of storage blocks")
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5cec5e32
    • Dmitry Tunin's avatar
      Bluetooth: Add another AR3012 04ca:3018 device · 519b6cea
      Dmitry Tunin authored
      commit 441ad62d upstream.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#=  5 Spd=12  MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=04ca ProdID=3018 Rev=00.01
      C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      519b6cea
    • Chao Peng's avatar
      KVM: VMX: use correct vmcs_read/write for guest segment selector/base · 7c3bab18
      Chao Peng authored
      commit 96794e4e upstream.
      
      Guest segment selector is 16 bit field and guest segment base is natural
      width field. Fix two incorrect invocations accordingly.
      
      Without this patch, build fails when aggressive inlining is used with ICC.
      Signed-off-by: default avatarChao Peng <chao.p.peng@linux.intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c3bab18
    • Janosch Frank's avatar
      KVM: s390: Disable dirty log retrieval for UCONTROL guests · 035dcc8e
      Janosch Frank authored
      commit e1e8a962 upstream.
      
      User controlled KVM guests do not support the dirty log, as they have
      no single gmap that we can check for changes.
      
      As they have no single gmap, kvm->arch.gmap is NULL and all further
      referencing to it for dirty checking will result in a NULL
      dereference.
      
      Let's return -EINVAL if a caller tries to sync dirty logs for a
      UCONTROL guest.
      
      Fixes: 15f36ebd ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
      Signed-off-by: default avatarJanosch Frank <frankja@linux.vnet.ibm.com>
      Reported-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      035dcc8e
    • Ian Abbott's avatar
      serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cards · c4c590be
      Ian Abbott authored
      commit 1c9c858e upstream.
      
      The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta
      Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports,
      respectively.  The first 4 ports are implemented by an OX16PCI954 chip,
      and the second 4 ports are implemented by an OX16C954 chip on a local
      bus, bridged by the second PCI function of the OX16PCI954.  The ports
      are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a
      non-standard oscillator frequency of 20 MHz (base_baud = 1250000).
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4c590be
    • Alexander Popov's avatar
      tty: n_hdlc: get rid of racy n_hdlc.tbuf · e5b97787
      Alexander Popov authored
      commit 82f2341c upstream.
      
      Currently N_HDLC line discipline uses a self-made singly linked list for
      data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
      an error.
      
      The commit be10eb75
      ("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
      After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
      one data buffer to tx_free_buf_list twice. That causes double free in
      n_hdlc_release().
      
      Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
      in case of tx error put current data buffer after the head of tx_buf_list.
      Signed-off-by: default avatarAlexander Popov <alex.popov@linux.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5b97787
  2. 12 Mar, 2017 15 commits