Skip to content
  1. Jan 18, 2020
  2. Jun 20, 2018
  3. Jun 11, 2018
  4. Jun 10, 2018
  5. May 18, 2018
  6. May 11, 2018
  7. Apr 19, 2018
    • Greg Kroah-Hartman's avatar
    • Amir Goldstein's avatar
      ovl: set lower layer st_dev only if setting lower st_ino · c4f45cf3
      Amir Goldstein authored
      
      
      commit 9f99e50d upstream.
      
      For broken hardlinks, we do not return lower st_ino, so we should
      also not return lower pseudo st_dev.
      
      Fixes: a0c5ad30 ("ovl: relax same fs constraint for constant st_ino")
      Cc: <stable@vger.kernel.org> #v4.15
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4f45cf3
    • Sudhir Sreedharan's avatar
      rtl8187: Fix NULL pointer dereference in priv->conf_mutex · 9def916c
      Sudhir Sreedharan authored
      
      
      commit 7972326a upstream.
      
      This can be reproduced by bind/unbind the driver multiple times
      in AM3517 board.
      
      Analysis revealed that rtl8187_start() was invoked before probe
      finishes(ie. before the mutex is initialized).
      
       INFO: trying to register non-static key.
       the code is fine but needs lockdep annotation.
       turning off the locking correctness validator.
       CPU: 0 PID: 821 Comm: wpa_supplicant Not tainted 4.9.80-dirty #250
       Hardware name: Generic AM3517 (Flattened Device Tree)
       [<c010e0d8>] (unwind_backtrace) from [<c010beac>] (show_stack+0x10/0x14)
       [<c010beac>] (show_stack) from [<c017401c>] (register_lock_class+0x4f4/0x55c)
       [<c017401c>] (register_lock_class) from [<c0176fe0>] (__lock_acquire+0x74/0x1938)
       [<c0176fe0>] (__lock_acquire) from [<c0178cfc>] (lock_acquire+0xfc/0x23c)
       [<c0178cfc>] (lock_acquire) from [<c08aa2f8>] (mutex_lock_nested+0x50/0x3b0)
       [<c08aa2f8>] (mutex_lock_nested) from [<c05f5bf8>] (rtl8187_start+0x2c/0xd54)
       [<c05f5bf8>] (rtl8187_start) from [<c082dea0>] (drv_start+0xa8/0x320)
       [<c082dea0>] (drv_start) from [<c084d1d4>] (ieee80211_do_open+0x2bc/0x8e4)
       [<c084d1d4>] (ieee80211_do_open) from [<c069be94>] (__dev_open+0xb8/0x120)
       [<c069be94>] (__dev_open) from [<c069c11c>] (__dev_change_flags+0x88/0x14c)
       [<c069c11c>] (__dev_change_flags) from [<c069c1f8>] (dev_change_flags+0x18/0x48)
       [<c069c1f8>] (dev_change_flags) from [<c0710b08>] (devinet_ioctl+0x738/0x840)
       [<c0710b08>] (devinet_ioctl) from [<c067925c>] (sock_ioctl+0x164/0x2f4)
       [<c067925c>] (sock_ioctl) from [<c02883f8>] (do_vfs_ioctl+0x8c/0x9d0)
       [<c02883f8>] (do_vfs_ioctl) from [<c0288da8>] (SyS_ioctl+0x6c/0x7c)
       [<c0288da8>] (SyS_ioctl) from [<c0107760>] (ret_fast_syscall+0x0/0x1c)
       Unable to handle kernel NULL pointer dereference at virtual address 00000000
       pgd = cd1ec000
       [00000000] *pgd=8d1de831, *pte=00000000, *ppte=00000000
       Internal error: Oops: 817 [#1] PREEMPT ARM
       Modules linked in:
       CPU: 0 PID: 821 Comm: wpa_supplicant Not tainted 4.9.80-dirty #250
       Hardware name: Generic AM3517 (Flattened Device Tree)
       task: ce73eec0 task.stack: cd1ea000
       PC is at mutex_lock_nested+0xe8/0x3b0
       LR is at mutex_lock_nested+0xd0/0x3b0
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSudhir Sreedharan <ssreedharan@mvista.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9def916c
    • Hans de Goede's avatar
      Bluetooth: hci_bcm: Treat Interrupt ACPI resources as always being active-low · 7a2a6d71
      Hans de Goede authored
      commit bb5208b3 upstream.
      
      Older devices with a serdev attached bcm bt hci, use an Interrupt ACPI
      resource to describe the IRQ (rather then a GpioInt resource).
      
      These device seem to all claim the IRQ is active-high and seem to all need
      a DMI quirk to treat it as active-low. Instead simply always assume that
      Interrupt resource specified IRQs are always active-low.
      
      This fixes the bt device not being able to wake the host from runtime-
      suspend on the: Asus T100TAM, Asus T200TA, Lenovo Yoga2 and the Toshiba
      Encore, without the need to add 4 new DMI quirks for these models.
      
      This also allows us to remove 2 DMI quirks for the Asus T100TA and Asus
      T100CHI series. Likely the 2 remaining quirks can also be removed but I
      could not find a DSDT of these devices to verify this.
      
      Cc: stable@vger.kernel.org
      Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=198953
      Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835
      
      
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a2a6d71
    • Szymon Janc's avatar
      Bluetooth: Fix connection if directed advertising and privacy is used · 154b354f
      Szymon Janc authored
      
      
      commit 082f2300 upstream.
      
      Local random address needs to be updated before creating connection if
      RPA from LE Direct Advertising Report was resolved in host. Otherwise
      remote device might ignore connection request due to address mismatch.
      
      This was affecting following qualification test cases:
      GAP/CONN/SCEP/BV-03-C, GAP/CONN/GCEP/BV-05-C, GAP/CONN/DCEP/BV-05-C
      
      Before patch:
      < HCI Command: LE Set Random Address (0x08|0x0005) plen 6          #11350 [hci0] 84680.231216
              Address: 56:BC:E8:24:11:68 (Resolvable)
                Identity type: Random (0x01)
                Identity: F2:F1:06:3D:9C:42 (Static)
      > HCI Event: Command Complete (0x0e) plen 4                        #11351 [hci0] 84680.246022
            LE Set Random Address (0x08|0x0005) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7         #11352 [hci0] 84680.246417
              Type: Passive (0x00)
              Interval: 60.000 msec (0x0060)
              Window: 30.000 msec (0x0030)
              Own address type: Random (0x01)
              Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02)
      > HCI Event: Command Complete (0x0e) plen 4                        #11353 [hci0] 84680.248854
            LE Set Scan Parameters (0x08|0x000b) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2             #11354 [hci0] 84680.249466
              Scanning: Enabled (0x01)
              Filter duplicates: Enabled (0x01)
      > HCI Event: Command Complete (0x0e) plen 4                        #11355 [hci0] 84680.253222
            LE Set Scan Enable (0x08|0x000c) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 18                          #11356 [hci0] 84680.458387
            LE Direct Advertising Report (0x0b)
              Num reports: 1
              Event type: Connectable directed - ADV_DIRECT_IND (0x01)
              Address type: Random (0x01)
              Address: 53:38:DA:46:8C:45 (Resolvable)
                Identity type: Public (0x00)
                Identity: 11:22:33:44:55:66 (OUI 11-22-33)
              Direct address type: Random (0x01)
              Direct address: 7C:D6:76:8C:DF:82 (Resolvable)
                Identity type: Random (0x01)
                Identity: F2:F1:06:3D:9C:42 (Static)
              RSSI: -74 dBm (0xb6)
      < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2             #11357 [hci0] 84680.458737
              Scanning: Disabled (0x00)
              Filter duplicates: Disabled (0x00)
      > HCI Event: Command Complete (0x0e) plen 4                        #11358 [hci0] 84680.469982
            LE Set Scan Enable (0x08|0x000c) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Create Connection (0x08|0x000d) plen 25          #11359 [hci0] 84680.470444
              Scan interval: 60.000 msec (0x0060)
              Scan window: 60.000 msec (0x0060)
              Filter policy: White list is not used (0x00)
              Peer address type: Random (0x01)
              Peer address: 53:38:DA:46:8C:45 (Resolvable)
                Identity type: Public (0x00)
                Identity: 11:22:33:44:55:66 (OUI 11-22-33)
              Own address type: Random (0x01)
              Min connection interval: 30.00 msec (0x0018)
              Max connection interval: 50.00 msec (0x0028)
              Connection latency: 0 (0x0000)
              Supervision timeout: 420 msec (0x002a)
              Min connection length: 0.000 msec (0x0000)
              Max connection length: 0.000 msec (0x0000)
      > HCI Event: Command Status (0x0f) plen 4                          #11360 [hci0] 84680.474971
            LE Create Connection (0x08|0x000d) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0    #11361 [hci0] 84682.545385
      > HCI Event: Command Complete (0x0e) plen 4                        #11362 [hci0] 84682.551014
            LE Create Connection Cancel (0x08|0x000e) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 19                          #11363 [hci0] 84682.551074
            LE Connection Complete (0x01)
              Status: Unknown Connection Identifier (0x02)
              Handle: 0
              Role: Master (0x00)
              Peer address type: Public (0x00)
              Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
              Connection interval: 0.00 msec (0x0000)
              Connection latency: 0 (0x0000)
              Supervision timeout: 0 msec (0x0000)
              Master clock accuracy: 0x00
      
      After patch:
      < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7    #210 [hci0] 667.152459
              Type: Passive (0x00)
              Interval: 60.000 msec (0x0060)
              Window: 30.000 msec (0x0030)
              Own address type: Random (0x01)
              Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02)
      > HCI Event: Command Complete (0x0e) plen 4                   #211 [hci0] 667.153613
            LE Set Scan Parameters (0x08|0x000b) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2        #212 [hci0] 667.153704
              Scanning: Enabled (0x01)
              Filter duplicates: Enabled (0x01)
      > HCI Event: Command Complete (0x0e) plen 4                   #213 [hci0] 667.154584
            LE Set Scan Enable (0x08|0x000c) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 18                     #214 [hci0] 667.182619
            LE Direct Advertising Report (0x0b)
              Num reports: 1
              Event type: Connectable directed - ADV_DIRECT_IND (0x01)
              Address type: Random (0x01)
              Address: 50:52:D9:A6:48:A0 (Resolvable)
                Identity type: Public (0x00)
                Identity: 11:22:33:44:55:66 (OUI 11-22-33)
              Direct address type: Random (0x01)
              Direct address: 7C:C1:57:A5:B7:A8 (Resolvable)
                Identity type: Random (0x01)
                Identity: F4:28:73:5D:38:B0 (Static)
              RSSI: -70 dBm (0xba)
      < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2       #215 [hci0] 667.182704
              Scanning: Disabled (0x00)
              Filter duplicates: Disabled (0x00)
      > HCI Event: Command Complete (0x0e) plen 4                  #216 [hci0] 667.183599
            LE Set Scan Enable (0x08|0x000c) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Random Address (0x08|0x0005) plen 6    #217 [hci0] 667.183645
              Address: 7C:C1:57:A5:B7:A8 (Resolvable)
                Identity type: Random (0x01)
                Identity: F4:28:73:5D:38:B0 (Static)
      > HCI Event: Command Complete (0x0e) plen 4                  #218 [hci0] 667.184590
            LE Set Random Address (0x08|0x0005) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Create Connection (0x08|0x000d) plen 25    #219 [hci0] 667.184613
              Scan interval: 60.000 msec (0x0060)
              Scan window: 60.000 msec (0x0060)
              Filter policy: White list is not used (0x00)
              Peer address type: Random (0x01)
              Peer address: 50:52:D9:A6:48:A0 (Resolvable)
                Identity type: Public (0x00)
                Identity: 11:22:33:44:55:66 (OUI 11-22-33)
              Own address type: Random (0x01)
              Min connection interval: 30.00 msec (0x0018)
              Max connection interval: 50.00 msec (0x0028)
              Connection latency: 0 (0x0000)
              Supervision timeout: 420 msec (0x002a)
              Min connection length: 0.000 msec (0x0000)
              Max connection length: 0.000 msec (0x0000)
      > HCI Event: Command Status (0x0f) plen 4                    #220 [hci0] 667.186558
            LE Create Connection (0x08|0x000d) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 19                    #221 [hci0] 667.485824
            LE Connection Complete (0x01)
              Status: Success (0x00)
              Handle: 0
              Role: Master (0x00)
              Peer address type: Random (0x01)
              Peer address: 50:52:D9:A6:48:A0 (Resolvable)
                Identity type: Public (0x00)
                Identity: 11:22:33:44:55:66 (OUI 11-22-33)
              Connection interval: 50.00 msec (0x0028)
              Connection latency: 0 (0x0000)
              Supervision timeout: 420 msec (0x002a)
              Master clock accuracy: 0x07
      @ MGMT Event: Device Connected (0x000b) plen 13          {0x0002} [hci0] 667.485996
              LE Address: 11:22:33:44:55:66 (OUI 11-22-33)
              Flags: 0x00000000
              Data length: 0
      
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      154b354f
    • Al Viro's avatar
      getname_kernel() needs to make sure that ->name != ->iname in long case · 4eb2f392
      Al Viro authored
      
      
      commit 30ce4d19 upstream.
      
      missed it in "kill struct filename.separate" several years ago.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4eb2f392
    • Michael S. Tsirkin's avatar
      mm/gup_benchmark: handle gup failures · 84f086ee
      Michael S. Tsirkin authored
      commit 09e35a4a upstream.
      
      Patch series "mm/get_user_pages_fast fixes, cleanups", v2.
      
      Turns out get_user_pages_fast and __get_user_pages_fast return different
      values on error when given a single page: __get_user_pages_fast returns
      0.  get_user_pages_fast returns either 0 or an error.
      
      Callers of get_user_pages_fast expect an error so fix it up to return an
      error consistently.
      
      Stress the difference between get_user_pages_fast and
      __get_user_pages_fast to make sure callers aren't confused.
      
      This patch (of 3):
      
      __gup_benchmark_ioctl does not handle the case where get_user_pages_fast
      fails:
      
       - a negative return code will cause a buffer overrun
      
       - returning with partial success will cause use of uninitialized
         memory.
      
      [akpm@linux-foundation.org: simplification]
      Link: http://lkml.kernel.org/r/1522962072-182137-3-git-send-email-mst@redhat.com
      
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thorsten Leemhuis <regressions@leemhuis.info>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84f086ee
    • Michael S. Tsirkin's avatar
      get_user_pages_fast(): return -EFAULT on access_ok failure · 7e255357
      Michael S. Tsirkin authored
      commit c61611f7 upstream.
      
      get_user_pages_fast is supposed to be a faster drop-in equivalent of
      get_user_pages.  As such, callers expect it to return a negative return
      code when passed an invalid address, and never expect it to return 0
      when passed a positive number of pages, since its documentation says:
      
       * Returns number of pages pinned. This may be fewer than the number
       * requested. If nr_pages is 0 or negative, returns 0. If no pages
       * were pinned, returns -errno.
      
      When get_user_pages_fast fall back on get_user_pages this is exactly
      what happens.  Unfortunately the implementation is inconsistent: it
      returns 0 if passed a kernel address, confusing callers: for example,
      the following is pretty common but does not appear to do the right thing
      with a kernel address:
      
              ret = get_user_pages_fast(addr, 1, writeable, &page);
              if (ret < 0)
                      return ret;
      
      Change get_user_pages_fast to return -EFAULT when supplied a kernel
      address to make it match expectations.
      
      All callers have been audited for consistency with the documented
      semantics.
      
      Link: http://lkml.kernel.org/r/1522962072-182137-4-git-send-email-mst@redhat.com
      
      
      Fixes: 5b65c467 ("mm, x86/mm: Fix performance regression in get_user_pages_fast()")
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reported-by: default avatar <syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thorsten Leemhuis <regressions@leemhuis.info>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e255357
    • Heiko Carstens's avatar
      s390/compat: fix setup_frame32 · 4d03a2e6
      Heiko Carstens authored
      
      
      commit 8b09ca74 upstream.
      
      Git commit c60a03fe ("s390: switch to {get,put}_compat_sigset()")
      contains a typo and now copies the wrong pointer to user space.
      Use the correct pointer instead.
      
      Reported-and-tested-by: default avatarStefan Liebler <stli@linux.vnet.ibm.com>
      Fixes: c60a03fe ("s390: switch to {get,put}_compat_sigset()")
      Cc: <stable@vger.kernel.org> # v4.15+
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      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>
      4d03a2e6
    • Vasily Gorbik's avatar
      s390/ipl: ensure loadparm valid flag is set · e025da42
      Vasily Gorbik authored
      
      
      commit 15deb080 upstream.
      
      When loadparm is set in reipl parm block, the kernel should also set
      DIAG308_FLAGS_LP_VALID flag.
      
      This fixes loadparm ignoring during z/VM fcp -> ccw reipl and kvm direct
      boot -> ccw reipl.
      
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e025da42
    • Julian Wiedmann's avatar
      s390/qdio: don't merge ERROR output buffers · 0d4e77fe
      Julian Wiedmann authored
      
      
      commit 0cf1e051 upstream.
      
      On an Output queue, both EMPTY and PENDING buffer states imply that the
      buffer is ready for completion-processing by the upper-layer drivers.
      
      So for a non-QEBSM Output queue, get_buf_states() merges mixed
      batches of PENDING and EMPTY buffers into one large batch of EMPTY
      buffers. The upper-layer driver (ie. qeth) later distuingishes PENDING
      from EMPTY by inspecting the slsb_state for
      QDIO_OUTBUF_STATE_FLAG_PENDING.
      
      But the merge logic in get_buf_states() contains a bug that causes us to
      erronously also merge ERROR buffers into such a batch of EMPTY buffers
      (ERROR is 0xaf, EMPTY is 0xa1; so ERROR & EMPTY == EMPTY).
      Effectively, most outbound ERROR buffers are currently discarded
      silently and processed as if they had succeeded.
      
      Note that this affects _all_ non-QEBSM device types, not just IQD with CQ.
      
      Fix it by explicitly spelling out the exact conditions for merging.
      
      For extracting the "get initial state" part out of the loop, this relies
      on the fact that get_buf_states() is never called with a count of 0. The
      QEBSM path already strictly requires this, and the two callers with
      variable 'count' make sure of it.
      
      Fixes: 104ea556 ("qdio: support asynchronous delivery of storage blocks")
      Cc: <stable@vger.kernel.org> #v3.2+
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.vnet.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d4e77fe
    • Julian Wiedmann's avatar
      s390/qdio: don't retry EQBS after CCQ 96 · f3eae287
      Julian Wiedmann authored
      
      
      commit dae55b6f upstream.
      
      Immediate retry of EQBS after CCQ 96 means that we potentially misreport
      the state of buffers inspected during the first EQBS call.
      
      This occurs when
      1. the first EQBS finds all inspected buffers still in the initial state
         set by the driver (ie INPUT EMPTY or OUTPUT PRIMED),
      2. the EQBS terminates early with CCQ 96, and
      3. by the time that the second EQBS comes around, the state of those
         previously inspected buffers has changed.
      
      If the state reported by the second EQBS is 'driver-owned', all we know
      is that the previous buffers are driver-owned now as well. But we can't
      tell if they all have the same state. So for instance
      - the second EQBS reports OUTPUT EMPTY, but any number of the previous
        buffers could be OUTPUT ERROR by now,
      - the second EQBS reports OUTPUT ERROR, but any number of the previous
        buffers could be OUTPUT EMPTY by now.
      
      Effectively, this can result in both over- and underreporting of errors.
      
      If the state reported by the second EQBS is 'HW-owned', that doesn't
      guarantee that the previous buffers have not been switched to
      driver-owned in the mean time. So for instance
      - the second EQBS reports INPUT EMPTY, but any number of the previous
        buffers could be INPUT PRIMED (or INPUT ERROR) by now.
      
      This would result in failure to process pending work on the queue. If
      it's the final check before yielding initiative, this can cause
      a (temporary) queue stall due to IRQ avoidance.
      
      Fixes: 25f269f1 ("[S390] qdio: EQBS retry after CCQ 96")
      Cc: <stable@vger.kernel.org> #v3.2+
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3eae287
    • Dan Williams's avatar
      nfit: fix region registration vs block-data-window ranges · 4f2217cb
      Dan Williams authored
      
      
      commit 8d0d8ed3 upstream.
      
      Commit 1cf03c00 "nfit: scrub and register regions in a workqueue"
      mistakenly attempts to register a region per BLK aperture. There is
      nothing to register for individual apertures as they belong as a set to
      a BLK aperture group that are registered with a corresponding
      DIMM-control-region. Filter them for registration to prevent some
      needless devm_kzalloc() allocations.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 1cf03c00 ("nfit: scrub and register regions in a workqueue")
      Reviewed-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f2217cb
    • Tetsuo Handa's avatar
      block/loop: fix deadlock after loop_set_status · 3adc1354
      Tetsuo Handa authored
      commit 1e047eaa upstream.
      
      syzbot is reporting deadlocks at __blkdev_get() [1].
      
      ----------------------------------------
      [   92.493919] systemd-udevd   D12696   525      1 0x00000000
      [   92.495891] Call Trace:
      [   92.501560]  schedule+0x23/0x80
      [   92.502923]  schedule_preempt_disabled+0x5/0x10
      [   92.504645]  __mutex_lock+0x416/0x9e0
      [   92.510760]  __blkdev_get+0x73/0x4f0
      [   92.512220]  blkdev_get+0x12e/0x390
      [   92.518151]  do_dentry_open+0x1c3/0x2f0
      [   92.519815]  path_openat+0x5d9/0xdc0
      [   92.521437]  do_filp_open+0x7d/0xf0
      [   92.527365]  do_sys_open+0x1b8/0x250
      [   92.528831]  do_syscall_64+0x6e/0x270
      [   92.530341]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      [   92.931922] 1 lock held by systemd-udevd/525:
      [   92.933642]  #0: 00000000a2849e25 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x73/0x4f0
      ----------------------------------------
      
      The reason of deadlock turned out that wait_event_interruptible() in
      blk_queue_enter() got stuck with bdev->bd_mutex held at __blkdev_put()
      due to q->mq_freeze_depth == 1.
      
      ----------------------------------------
      [   92.787172] a.out           S12584   634    633 0x80000002
      [   92.789120] Call Trace:
      [   92.796693]  schedule+0x23/0x80
      [   92.797994]  blk_queue_enter+0x3cb/0x540
      [   92.803272]  generic_make_request+0xf0/0x3d0
      [   92.807970]  submit_bio+0x67/0x130
      [   92.810928]  submit_bh_wbc+0x15e/0x190
      [   92.812461]  __block_write_full_page+0x218/0x460
      [   92.815792]  __writepage+0x11/0x50
      [   92.817209]  write_cache_pages+0x1ae/0x3d0
      [   92.825585]  generic_writepages+0x5a/0x90
      [   92.831865]  do_writepages+0x43/0xd0
      [   92.836972]  __filemap_fdatawrite_range+0xc1/0x100
      [   92.838788]  filemap_write_and_wait+0x24/0x70
      [   92.840491]  __blkdev_put+0x69/0x1e0
      [   92.841949]  blkdev_close+0x16/0x20
      [   92.843418]  __fput+0xda/0x1f0
      [   92.844740]  task_work_run+0x87/0xb0
      [   92.846215]  do_exit+0x2f5/0xba0
      [   92.850528]  do_group_exit+0x34/0xb0
      [   92.852018]  SyS_exit_group+0xb/0x10
      [   92.853449]  do_syscall_64+0x6e/0x270
      [   92.854944]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      [   92.943530] 1 lock held by a.out/634:
      [   92.945105]  #0: 00000000a2849e25 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x3c/0x1e0
      ----------------------------------------
      
      The reason of q->mq_freeze_depth == 1 turned out that loop_set_status()
      forgot to call blk_mq_unfreeze_queue() at error paths for
      info->lo_encrypt_type != NULL case.
      
      ----------------------------------------
      [   37.509497] CPU: 2 PID: 634 Comm: a.out Tainted: G        W        4.16.0+ #457
      [   37.513608] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
      [   37.518832] RIP: 0010:blk_freeze_queue_start+0x17/0x40
      [   37.521778] RSP: 0018:ffffb0c2013e7c60 EFLAGS: 00010246
      [   37.524078] RAX: 0000000000000000 RBX: ffff8b07b1519798 RCX: 0000000000000000
      [   37.527015] RDX: 0000000000000002 RSI: ffffb0c2013e7cc0 RDI: ffff8b07b1519798
      [   37.529934] RBP: ffffb0c2013e7cc0 R08: 0000000000000008 R09: 47a189966239b898
      [   37.532684] R10: dad78b99b278552f R11: 9332dca72259d5ef R12: ffff8b07acd73678
      [   37.535452] R13: 0000000000004c04 R14: 0000000000000000 R15: ffff8b07b841e940
      [   37.538186] FS:  00007fede33b9740(0000) GS:ffff8b07b8e80000(0000) knlGS:0000000000000000
      [   37.541168] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   37.543590] CR2: 00000000206fdf18 CR3: 0000000130b30006 CR4: 00000000000606e0
      [   37.546410] Call Trace:
      [   37.547902]  blk_freeze_queue+0x9/0x30
      [   37.549968]  loop_set_status+0x67/0x3c0 [loop]
      [   37.549975]  loop_set_status64+0x3b/0x70 [loop]
      [   37.549986]  lo_ioctl+0x223/0x810 [loop]
      [   37.549995]  blkdev_ioctl+0x572/0x980
      [   37.550003]  block_ioctl+0x34/0x40
      [   37.550006]  do_vfs_ioctl+0xa7/0x6d0
      [   37.550017]  ksys_ioctl+0x6b/0x80
      [   37.573076]  SyS_ioctl+0x5/0x10
      [   37.574831]  do_syscall_64+0x6e/0x270
      [   37.576769]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      ----------------------------------------
      
      [1] https://syzkaller.appspot.com/bug?id=cd662bc3f6022c0979d01a262c318fab2ee9b56f
      
      
      
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: default avatarsyzbot <bot+48594378e9851eab70bcd6f99327c7db58c5a28a@syzkaller.appspotmail.com>
      Fixes: ecdd0959 ("block/loop: fix race between I/O and set_status")
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: Jens Axboe <axboe@fb.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3adc1354
    • John Johansen's avatar
      apparmor: fix resource audit messages when auditing peer · 9d8a3dc9
      John Johansen authored
      
      
      commit b5beb07a upstream.
      
      Resource auditing is using the peer field which is not available
      when the rlim data struct is used, because it is a different element
      of the same union. Accessing peer during resource auditing could
      cause garbage log entries or even oops the kernel.
      
      Move the rlim data block into the same struct as the peer field
      so they can be used together.
      
      CC: <stable@vger.kernel.org>
      Fixes: 86b92cb7 ("apparmor: move resource checks to using labels")
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d8a3dc9
Loading