1. 17 Sep, 2014 40 commits
    • Chris Mason's avatar
      xfs: don't zero partial page cache pages during O_DIRECT writes · 2f3219f6
      Chris Mason authored
      commit 85e584da upstream.
      
      xfs is using truncate_pagecache_range to invalidate the page cache
      during DIO reads.  This is different from the other filesystems who
      only invalidate pages during DIO writes.
      
      truncate_pagecache_range is meant to be used when we are freeing the
      underlying data structs from disk, so it will zero any partial
      ranges in the page.  This means a DIO read can zero out part of the
      page cache page, and it is possible the page will stay in cache.
      
      buffered reads will find an up to date page with zeros instead of
      the data actually on disk.
      
      This patch fixes things by using invalidate_inode_pages2_range
      instead.  It preserves the page cache invalidation, but won't zero
      any pages.
      
      [dchinner: catch error and warn if it fails. Comment.]
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f3219f6
    • Dave Chinner's avatar
      xfs: don't zero partial page cache pages during O_DIRECT writes · d2f8462e
      Dave Chinner authored
      commit 834ffca6 upstream.
      
      Similar to direct IO reads, direct IO writes are using
      truncate_pagecache_range to invalidate the page cache. This is
      incorrect due to the sub-block zeroing in the page cache that
      truncate_pagecache_range() triggers.
      
      This patch fixes things by using invalidate_inode_pages2_range
      instead.  It preserves the page cache invalidation, but won't zero
      any pages.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2f8462e
    • Dave Chinner's avatar
      xfs: don't dirty buffers beyond EOF · 4fa1c311
      Dave Chinner authored
      commit 22e757a4 upstream.
      
      generic/263 is failing fsx at this point with a page spanning
      EOF that cannot be invalidated. The operations are:
      
      1190 mapwrite   0x52c00 thru    0x5e569 (0xb96a bytes)
      1191 mapread    0x5c000 thru    0x5d636 (0x1637 bytes)
      1192 write      0x5b600 thru    0x771ff (0x1bc00 bytes)
      
      where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO
      write attempts to invalidate the cached page over this range, it
      fails with -EBUSY and so any attempt to do page invalidation fails.
      
      The real question is this: Why can't that page be invalidated after
      it has been written to disk and cleaned?
      
      Well, there's data on the first two buffers in the page (1k block
      size, 4k page), but the third buffer on the page (i.e. beyond EOF)
      is failing drop_buffers because it's bh->b_state == 0x3, which is
      BH_Uptodate | BH_Dirty.  IOWs, there's dirty buffers beyond EOF. Say
      what?
      
      OK, set_buffer_dirty() is called on all buffers from
      __set_page_buffers_dirty(), regardless of whether the buffer is
      beyond EOF or not, which means that when we get to ->writepage,
      we have buffers marked dirty beyond EOF that we need to clean.
      So, we need to implement our own .set_page_dirty method that
      doesn't dirty buffers beyond EOF.
      
      This is messy because the buffer code is not meant to be shared
      and it has interesting locking issues on the buffer dirty bits.
      So just copy and paste it and then modify it to suit what we need.
      
      Note: the solutions the other filesystems and generic block code use
      of marking the buffers clean in ->writepage does not work for XFS.
      It still leaves dirty buffers beyond EOF and invalidations still
      fail. Hence rather than play whack-a-mole, this patch simply
      prevents those buffers from being dirtied in the first place.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fa1c311
    • Dave Chinner's avatar
      xfs: quotacheck leaves dquot buffers without verifiers · 4dbaf782
      Dave Chinner authored
      commit 5fd364fe upstream.
      
      When running xfs/305, I noticed that quotacheck was flushing dquot
      buffers that did not have the xfs_dquot_buf_ops verifiers attached:
      
      XFS (vdb): _xfs_buf_ioapply: no ops on block 0x1dc8/0x1dc8
      ffff880052489000: 44 51 01 04 00 00 65 b8 00 00 00 00 00 00 00 00  DQ....e.........
      ffff880052489010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      ffff880052489020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      ffff880052489030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      CPU: 1 PID: 2376 Comm: mount Not tainted 3.16.0-rc2-dgc+ #306
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffff88006fe38000 ffff88004a0ffae8 ffffffff81cf1cca 0000000000000001
       ffff88004a0ffb88 ffffffff814d50ca 000010004a0ffc70 0000000000000000
       ffff88006be56dc4 0000000000000021 0000000000001dc8 ffff88007c773d80
      Call Trace:
       [<ffffffff81cf1cca>] dump_stack+0x45/0x56
       [<ffffffff814d50ca>] _xfs_buf_ioapply+0x3ca/0x3d0
       [<ffffffff810db520>] ? wake_up_state+0x20/0x20
       [<ffffffff814d51f5>] ? xfs_bdstrat_cb+0x55/0xb0
       [<ffffffff814d513b>] xfs_buf_iorequest+0x6b/0xd0
       [<ffffffff814d51f5>] xfs_bdstrat_cb+0x55/0xb0
       [<ffffffff814d53ab>] __xfs_buf_delwri_submit+0x15b/0x220
       [<ffffffff814d6040>] ? xfs_buf_delwri_submit+0x30/0x90
       [<ffffffff814d6040>] xfs_buf_delwri_submit+0x30/0x90
       [<ffffffff8150f89d>] xfs_qm_quotacheck+0x17d/0x3c0
       [<ffffffff81510591>] xfs_qm_mount_quotas+0x151/0x1e0
       [<ffffffff814ed01c>] xfs_mountfs+0x56c/0x7d0
       [<ffffffff814f0f12>] xfs_fs_fill_super+0x2c2/0x340
       [<ffffffff811c9fe4>] mount_bdev+0x194/0x1d0
       [<ffffffff814f0c50>] ? xfs_finish_flags+0x170/0x170
       [<ffffffff814ef0f5>] xfs_fs_mount+0x15/0x20
       [<ffffffff811ca8c9>] mount_fs+0x39/0x1b0
       [<ffffffff811e4d67>] vfs_kern_mount+0x67/0x120
       [<ffffffff811e757e>] do_mount+0x23e/0xad0
       [<ffffffff8117abde>] ? __get_free_pages+0xe/0x50
       [<ffffffff811e71e6>] ? copy_mount_options+0x36/0x150
       [<ffffffff811e8103>] SyS_mount+0x83/0xc0
       [<ffffffff81cfd40b>] tracesys+0xdd/0xe2
      
      This was caused by dquot buffer readahead not attaching a verifier
      structure to the buffer when readahead was issued, resulting in the
      followup read of the buffer finding a valid buffer and so not
      attaching new verifiers to the buffer as part of the read.
      
      Also, when a verifier failure occurs, we then read the buffer
      without verifiers. Attach the verifiers manually after this read so
      that if the buffer is then written it will be verified that the
      corruption has been repaired.
      
      Further, when flushing a dquot we don't ask for a verifier when
      reading in the dquot buffer the dquot belongs to. Most of the time
      this isn't an issue because the buffer is still cached, but when it
      is not cached it will result in writing the dquot buffer without
      having the verfier attached.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dbaf782
    • Dave Chinner's avatar
      xfs: ensure verifiers are attached to recovered buffers · 13c22aa3
      Dave Chinner authored
      commit 67dc288c upstream.
      
      Crash testing of CRC enabled filesystems has resulted in a number of
      reports of bad CRCs being detected after the filesystem was mounted.
      Errors such as the following were being seen:
      
      XFS (sdb3): Mounting V5 Filesystem
      XFS (sdb3): Starting recovery (logdev: internal)
      XFS (sdb3): Metadata CRC error detected at xfs_agf_read_verify+0x5a/0x100 [xfs], block 0x1
      XFS (sdb3): Unmount and run xfs_repair
      XFS (sdb3): First 64 bytes of corrupted metadata buffer:
      ffff880136ffd600: 58 41 47 46 00 00 00 01 00 00 00 00 00 0f aa 40  XAGF...........@
      ffff880136ffd610: 00 02 6d 53 00 02 77 f8 00 00 00 00 00 00 00 01  ..mS..w.........
      ffff880136ffd620: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03  ................
      ffff880136ffd630: 00 00 00 04 00 08 81 d0 00 08 81 a7 00 00 00 00  ................
      XFS (sdb3): metadata I/O error: block 0x1 ("xfs_trans_read_buf_map") error 74 numblks 1
      
      The errors were typically being seen in AGF, AGI and their related
      btree block buffers some time after log recovery had run. Often it
      wasn't until later subsequent mounts that the problem was
      discovered. The common symptom was a buffer with the correct
      contents, but a CRC and an LSN that matched an older version of the
      contents.
      
      Some debug added to _xfs_buf_ioapply() indicated that buffers were
      being written without verifiers attached to them from log recovery,
      and Jan Kara isolated the cause to log recovery readahead an dit's
      interactions with buffers that had a more recent LSN on disk than
      the transaction being recovered. In this case, the buffer did not
      get a verifier attached, and os when the second phase of log
      recovery ran and recovered EFIs and unlinked inodes, the buffers
      were modified and written without the verifier running. Hence they
      had up to date contents, but stale LSNs and CRCs.
      
      Fix it by attaching verifiers to buffers we skip due to future LSN
      values so they don't escape into the buffer cache without the
      correct verifier attached.
      
      This patch is based on analysis and a patch from Jan Kara.
      Reported-by: default avatarJan Kara <jack@suse.cz>
      Reported-by: default avatarFanael Linithien <fanael4@gmail.com>
      Reported-by: default avatarGrozdan <neutrino8@gmail.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13c22aa3
    • Doug Ledford's avatar
      RDMA/uapi: Include socket.h in rdma_user_cm.h · 5126045d
      Doug Ledford authored
      commit db1044d4 upstream.
      
      added struct sockaddr_storage to rdma_user_cm.h without also adding an
      include for linux/socket.h to make sure it is defined.  Systemtap
      needs the header files to build standalone and cannot rely on other
      files to pre-include other headers, so add linux/socket.h to the list
      of includes in this file.
      
      Fixes: ee7aed45 ("RDMA/ucma: Support querying for AF_IB addresses")
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5126045d
    • Steve Wise's avatar
      RDMA/iwcm: Use a default listen backlog if needed · c06a9fa5
      Steve Wise authored
      commit 2f0304d2 upstream.
      
      If the user creates a listening cm_id with backlog of 0 the IWCM ends
      up not allowing any connection requests at all.  The correct behavior
      is for the IWCM to pick a default value if the user backlog parameter
      is zero.
      
      Lustre from version 1.8.8 onward uses a backlog of 0, which breaks
      iwarp support without this fix.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c06a9fa5
    • NeilBrown's avatar
      md/raid10: Fix memory leak when raid10 reshape completes. · ad70570f
      NeilBrown authored
      commit b3968552 upstream.
      
      When a raid10 commences a resync/recovery/reshape it allocates
      some buffer space.
      When a resync/recovery completes the buffer space is freed.  But not
      when the reshape completes.
      This can result in a small memory leak.
      
      There is a subtle side-effect of this bug.  When a RAID10 is reshaped
      to a larger array (more devices), the reshape is immediately followed
      by a "resync" of the new space.  This "resync" will use the buffer
      space which was allocated for "reshape".  This can cause problems
      including a "BUG" in the SCSI layer.  So this is suitable for -stable.
      
      Fixes: 3ea7daa5Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad70570f
    • NeilBrown's avatar
      md/raid10: fix memory leak when reshaping a RAID10. · 62906bc6
      NeilBrown authored
      commit ce0b0a46 upstream.
      
      raid10 reshape clears unwanted bits from a bio->bi_flags using
      a method which, while clumsy, worked until 3.10 when BIO_OWNS_VEC
      was added.
      Since then it clears that bit but shouldn't.  This results in a
      memory leak.
      
      So change to used the approved method of clearing unwanted bits.
      
      As this causes a memory leak which can consume all of memory
      the fix is suitable for -stable.
      
      Fixes: a38352e0
      Reported-by: mdraid.pkoch@dfgh.net (Peter Koch)
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62906bc6
    • NeilBrown's avatar
      md/raid6: avoid data corruption during recovery of double-degraded RAID6 · ba1f6592
      NeilBrown authored
      commit 9c4bdf69 upstream.
      
      During recovery of a double-degraded RAID6 it is possible for
      some blocks not to be recovered properly, leading to corruption.
      
      If a write happens to one block in a stripe that would be written to a
      missing device, and at the same time that stripe is recovering data
      to the other missing device, then that recovered data may not be written.
      
      This patch skips, in the double-degraded case, an optimisation that is
      only safe for single-degraded arrays.
      
      Bug was introduced in 2.6.32 and fix is suitable for any kernel since
      then.  In an older kernel with separate handle_stripe5() and
      handle_stripe6() functions the patch must change handle_stripe6().
      
      Fixes: 6c0069c0
      Cc: Yuri Tikhonov <yur@emcraft.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Reported-by: default avatar"Manibalan P" <pmanibalan@amiindia.co.in>
      Tested-by: default avatar"Manibalan P" <pmanibalan@amiindia.co.in>
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba1f6592
    • NeilBrown's avatar
      md/raid5: avoid livelock caused by non-aligned writes. · 706d9164
      NeilBrown authored
      commit a40687ff upstream.
      
      If a stripe in a raid6 array received a write to each data block while
      the array is degraded, and if any of these writes to a missing device
      are not page-aligned, then a live-lock happens.
      
      In this case the P and Q blocks need to be read so that the part of
      the missing block which is *not* being updated by the write can be
      constructed.  Due to a logic error, these blocks are not loaded, so
      the update cannot proceed and the stripe is 'handled' repeatedly in an
      infinite loop.
      
      This bug is unlikely as most writes are page aligned.  However as it
      can lead to a livelock it is suitable for -stable.  It was introduced
      in 3.16.
      
      Fixed: 67f45548Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      706d9164
    • NeilBrown's avatar
      md/raid1,raid10: always abort recover on write error. · ae2a0244
      NeilBrown authored
      commit 2446dba0 upstream.
      
      Currently we don't abort recovery on a write error if the write error
      to the recovering device was triggerd by normal IO (as opposed to
      recovery IO).
      
      This means that for one bitmap region, the recovery might write to the
      recovering device for a few sectors, then not bother for subsequent
      sectors (as it never writes to failed devices).  In this case
      the bitmap bit will be cleared, but it really shouldn't.
      
      The result is that if the recovering device fails and is then re-added
      (after fixing whatever hardware problem triggerred the failure),
      the second recovery won't redo the region it was in the middle of,
      so some of the device will not be recovered properly.
      
      If we abort the recovery, the region being processes will be cancelled
      (bit not cleared) and the whole region will be retried.
      
      As the bug can result in data corruption the patch is suitable for
      -stable.  For kernels prior to 3.11 there is a conflict in raid10.c
      which will require care.
      
      Original-from: jiao hui <jiaohui@bwstor.com.cn>
      Reported-and-tested-by: default avatarjiao hui <jiaohui@bwstor.com.cn>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae2a0244
    • Al Viro's avatar
      fix copy_tree() regression · 3fd72a0e
      Al Viro authored
      commit 12a5b529 upstream.
      
      Since 3.14 we had copy_tree() get the shadowing wrong - if we had one
      vfsmount shadowing another (i.e. if A is a slave of B, C is mounted
      on A/foo, then D got mounted on B/foo creating D' on A/foo shadowed
      by C), copy_tree() of A would make a copy of D' shadow the the copy of
      C, not the other way around.
      
      It's easy to fix, fortunately - just make sure that mount follows
      the one that shadows it in mnt_child as well as in mnt_hash, and when
      copy_tree() decides to attach a new mount, check if the last child
      it has added to the same parent should be shadowing the new one.
      And if it should, just use the same logics commit_tree() has - put the
      new mount into the hash and children lists right after the one that
      should shadow it.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fd72a0e
    • Ilya Dryomov's avatar
      rbd: rework rbd_request_fn() · 0fe6ae39
      Ilya Dryomov authored
      commit bc1ecc65 upstream.
      
      While it was never a good idea to sleep in request_fn(), commit
      34c6bc2c ("locking/mutexes: Add extra reschedule point") made it
      a *bad* idea.  mutex_lock() since 3.15 may reschedule *before* putting
      task on the mutex wait queue, which for tasks in !TASK_RUNNING state
      means block forever.  request_fn() may be called with !TASK_RUNNING on
      the way to schedule() in io_schedule().
      
      Offload request handling to a workqueue, one per rbd device, to avoid
      calling blocking primitives from rbd_request_fn().
      
      Fixes: http://tracker.ceph.com/issues/8818Signed-off-by: default avatarIlya Dryomov <ilya.dryomov@inktank.com>
      Tested-by: default avatarEric Eastman <eric0e@aol.com>
      Tested-by: default avatarGreg Wilson <greg.wilson@keepertech.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0fe6ae39
    • Al Viro's avatar
      __generic_file_write_iter(): fix handling of sync error after DIO · 3fecf9a2
      Al Viro authored
      commit 60bb4529 upstream.
      
      If DIO results in short write and sync write fails, we want to bugger off
      whether the DIO part has written anything or not; the logics on the return
      will take care of the right return value.
      Reported-by: default avatarAnton Altaparmakov <aia21@cam.ac.uk>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fecf9a2
    • Vignesh Raman's avatar
      Bluetooth: Avoid use of session socket after the session gets freed · 4156d121
      Vignesh Raman authored
      commit 32333edb upstream.
      
      The commits 08c30aca "Bluetooth: Remove
      RFCOMM session refcnt" and 8ff52f7d
      "Bluetooth: Return RFCOMM session ptrs to avoid freed session"
      allow rfcomm_recv_ua and rfcomm_session_close to delete the session
      (and free the corresponding socket) and propagate NULL session pointer
      to the upper callers.
      
      Additional fix is required to terminate the loop in rfcomm_process_rx
      function to avoid use of freed 'sk' memory.
      
      The issue is only reproducible with kernel option CONFIG_PAGE_POISONING
      enabled making freed memory being changed and filled up with fixed char
      value used to unmask use-after-free issues.
      Signed-off-by: default avatarVignesh Raman <Vignesh_Raman@mentor.com>
      Signed-off-by: default avatarVitaly Kuzmichev <Vitaly_Kuzmichev@mentor.com>
      Acked-by: default avatarDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4156d121
    • Johan Hedberg's avatar
      Bluetooth: Fix using uninitialized variable when pairing · 075d3370
      Johan Hedberg authored
      commit 9f743d74 upstream.
      
      Commit 6c53823a reshuffled the way the
      authentication requirement gets set in the hci_io_capa_request_evt()
      function, but at the same time it failed to update an if-statement where
      cp.authentication is used before it has been initialized. The correct
      value the code should be looking for in this if-statement is
      conn->auth_type.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      075d3370
    • Vladimir Davydov's avatar
      Bluetooth: never linger on process exit · e6b64634
      Vladimir Davydov authored
      commit 093facf3 upstream.
      
      If the current process is exiting, lingering on socket close will make
      it unkillable, so we should avoid it.
      
      Reproducer:
      
        #include <sys/types.h>
        #include <sys/socket.h>
      
        #define BTPROTO_L2CAP   0
        #define BTPROTO_SCO     2
        #define BTPROTO_RFCOMM  3
      
        int main()
        {
                int fd;
                struct linger ling;
      
                fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
                //or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP);
                //or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO);
      
                ling.l_onoff = 1;
                ling.l_linger = 1000000000;
                setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));
      
                return 0;
        }
      Signed-off-by: default avatarVladimir Davydov <vdavydov@parallels.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6b64634
    • Johan Hedberg's avatar
      Bluetooth: Fix tracking local SSP authentication requirement · c8383cb6
      Johan Hedberg authored
      commit 6c53823a upstream.
      
      When we need to make the decision whether to perform just-works or real
      user confirmation we need to know the exact local authentication
      requirement that was passed to the controller. So far conn->auth_type
      (the local requirement) wasn't in one case updated appropriately in fear
      of the user confirmation being rejected later.
      
      The real problem however was not really that conn->auth_type couldn't
      represent the true value but that we were checking the local MITM
      requirement in an incorrect way. It's perfectly fine to let auth_type
      follow what we tell the controller since we're still tracking the target
      security level with conn->pending_sec_level.
      
      This patch updates the check for local MITM requirement in the
      hci_user_confirm_request_evt function to use the locally requested
      security level and ensures that auth_type always represents what we tell
      the controller. All other code in hci_user_confirm_request_evt still
      uses the auth_type instead of pending_sec_level for determining whether
      to do just-works or not, since that's the only value that's in sync with
      what the remote device knows.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Tested-by: default avatarSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8383cb6
    • Marcel Holtmann's avatar
      Bluetooth: Fix merge of advertising data and scan response data · 41466215
      Marcel Holtmann authored
      commit 42bd6a56 upstream.
      
      The advertising data and scan response data are merged in the wrong
      order. It should be advertsing data first and then scan response data
      and not the other way around.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      41466215
    • Chin-Ran Lo's avatar
      Bluetooth: btmrvl: wait for HOST_SLEEP_ENABLE event in suspend · ec0c2b9c
      Chin-Ran Lo authored
      commit 396e04f4 upstream.
      
      After BT_CMD_HOST_SLEEP_ENABLE command finishes, driver should
      wait until getting BT_EVENT_HOST_SLEEP_ENABLE event to complete
      suspend procedure.
      Without this patch the suspend handler would return success
      earlier. By the time when the BT_EVENT_HOST_SLEEP_ENABLE event
      comes in the controller driver could have already turned off the
      bus clock. This causes kernel crash or system reboot eventually.
      Signed-off-by: default avatarChin-Ran Lo <crlo@marvell.com>
      Signed-off-by: default avatarJeff CF Chen <jeffc@marvell.com>
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec0c2b9c
    • Al Viro's avatar
      fix EBUSY on umount() from MNT_SHRINKABLE · cee789ed
      Al Viro authored
      commit 81b6b061 upstream.
      
      We need the parents of victims alive until namespace_unlock() gets to
      dput() of the (ex-)mountpoints.  However, that screws up the "is it
      busy" checks in case when we have shrinkable mounts that need to be
      killed.  Solution: go ahead and decrement refcounts of parents right
      in umount_tree(), increment them again just before dropping rwsem in
      namespace_unlock() (and let the loop in the end of namespace_unlock()
      finally drop those references for good, as we do now).  Parents can't
      get freed until we drop rwsem - at least one reference is kept until
      then, both in case when parent is among the victims and when it is
      not.  So they'll still be around when we get to namespace_unlock().
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cee789ed
    • Al Viro's avatar
      get rid of propagate_umount() mistakenly treating slaves as busy. · a14b6606
      Al Viro authored
      commit 88b368f2 upstream.
      
      The check in __propagate_umount() ("has somebody explicitly mounted
      something on that slave?") is done *before* taking the already doomed
      victims out of the child lists.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a14b6606
    • Eric W. Biederman's avatar
      mnt: Add tests for unprivileged remount cases that have found to be faulty · 27d2379a
      Eric W. Biederman authored
      commit db181ce0 upstream.
      
      Kenton Varda <kenton@sandstorm.io> discovered that by remounting a
      read-only bind mount read-only in a user namespace the
      MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user
      to the remount a read-only mount read-write.
      
      Upon review of the code in remount it was discovered that the code allowed
      nosuid, noexec, and nodev to be cleared.  It was also discovered that
      the code was allowing the per mount atime flags to be changed.
      
      The first naive patch to fix these issues contained the flaw that using
      default atime settings when remounting a filesystem could be disallowed.
      
      To avoid this problems in the future add tests to ensure unprivileged
      remounts are succeeding and failing at the appropriate times.
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27d2379a
    • Eric W. Biederman's avatar
      mnt: Change the default remount atime from relatime to the existing value · 72e946e2
      Eric W. Biederman authored
      commit ffbc6f0e upstream.
      
      Since March 2009 the kernel has treated the state that if no
      MS_..ATIME flags are passed then the kernel defaults to relatime.
      
      Defaulting to relatime instead of the existing atime state during a
      remount is silly, and causes problems in practice for people who don't
      specify any MS_...ATIME flags and to get the default filesystem atime
      setting.  Those users may encounter a permission error because the
      default atime setting does not work.
      
      A default that does not work and causes permission problems is
      ridiculous, so preserve the existing value to have a default
      atime setting that is always guaranteed to work.
      
      Using the default atime setting in this way is particularly
      interesting for applications built to run in restricted userspace
      environments without /proc mounted, as the existing atime mount
      options of a filesystem can not be read from /proc/mounts.
      
      In practice this fixes user space that uses the default atime
      setting on remount that are broken by the permission checks
      keeping less privileged users from changing more privileged users
      atime settings.
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72e946e2
    • Eric W. Biederman's avatar
      mnt: Correct permission checks in do_remount · 3ed889bb
      Eric W. Biederman authored
      commit 9566d674 upstream.
      
      While invesgiating the issue where in "mount --bind -oremount,ro ..."
      would result in later "mount --bind -oremount,rw" succeeding even if
      the mount started off locked I realized that there are several
      additional mount flags that should be locked and are not.
      
      In particular MNT_NOSUID, MNT_NODEV, MNT_NOEXEC, and the atime
      flags in addition to MNT_READONLY should all be locked.  These
      flags are all per superblock, can all be changed with MS_BIND,
      and should not be changable if set by a more privileged user.
      
      The following additions to the current logic are added in this patch.
      - nosuid may not be clearable by a less privileged user.
      - nodev  may not be clearable by a less privielged user.
      - noexec may not be clearable by a less privileged user.
      - atime flags may not be changeable by a less privileged user.
      
      The logic with atime is that always setting atime on access is a
      global policy and backup software and auditing software could break if
      atime bits are not updated (when they are configured to be updated),
      and serious performance degradation could result (DOS attack) if atime
      updates happen when they have been explicitly disabled.  Therefore an
      unprivileged user should not be able to mess with the atime bits set
      by a more privileged user.
      
      The additional restrictions are implemented with the addition of
      MNT_LOCK_NOSUID, MNT_LOCK_NODEV, MNT_LOCK_NOEXEC, and MNT_LOCK_ATIME
      mnt flags.
      
      Taken together these changes and the fixes for MNT_LOCK_READONLY
      should make it safe for an unprivileged user to create a user
      namespace and to call "mount --bind -o remount,... ..." without
      the danger of mount flags being changed maliciously.
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ed889bb
    • Eric W. Biederman's avatar
      mnt: Move the test for MNT_LOCK_READONLY from change_mount_flags into do_remount · daa4314a
      Eric W. Biederman authored
      commit 07b64558 upstream.
      
      There are no races as locked mount flags are guaranteed to never change.
      
      Moving the test into do_remount makes it more visible, and ensures all
      filesystem remounts pass the MNT_LOCK_READONLY permission check.  This
      second case is not an issue today as filesystem remounts are guarded
      by capable(CAP_DAC_ADMIN) and thus will always fail in less privileged
      mount namespaces, but it could become an issue in the future.
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      daa4314a
    • Eric W. Biederman's avatar
      mnt: Only change user settable mount flags in remount · 3995f446
      Eric W. Biederman authored
      commit a6138db8 upstream.
      
      Kenton Varda <kenton@sandstorm.io> discovered that by remounting a
      read-only bind mount read-only in a user namespace the
      MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user
      to the remount a read-only mount read-write.
      
      Correct this by replacing the mask of mount flags to preserve
      with a mask of mount flags that may be changed, and preserve
      all others.   This ensures that any future bugs with this mask and
      remount will fail in an easy to detect way where new mount flags
      simply won't change.
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3995f446
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Up rb_iter_peek() loop count to 3 · 39ed6dfc
      Steven Rostedt (Red Hat) authored
      commit 021de3d9 upstream.
      
      After writting a test to try to trigger the bug that caused the
      ring buffer iterator to become corrupted, I hit another bug:
      
       WARNING: CPU: 1 PID: 5281 at kernel/trace/ring_buffer.c:3766 rb_iter_peek+0x113/0x238()
       Modules linked in: ipt_MASQUERADE sunrpc [...]
       CPU: 1 PID: 5281 Comm: grep Tainted: G        W     3.16.0-rc3-test+ #143
       Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
        0000000000000000 ffffffff81809a80 ffffffff81503fb0 0000000000000000
        ffffffff81040ca1 ffff8800796d6010 ffffffff810c138d ffff8800796d6010
        ffff880077438c80 ffff8800796d6010 ffff88007abbe600 0000000000000003
       Call Trace:
        [<ffffffff81503fb0>] ? dump_stack+0x4a/0x75
        [<ffffffff81040ca1>] ? warn_slowpath_common+0x7e/0x97
        [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238
        [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238
        [<ffffffff810c14df>] ? ring_buffer_iter_peek+0x2d/0x5c
        [<ffffffff810c6f73>] ? tracing_iter_reset+0x6e/0x96
        [<ffffffff810c74a3>] ? s_start+0xd7/0x17b
        [<ffffffff8112b13e>] ? kmem_cache_alloc_trace+0xda/0xea
        [<ffffffff8114cf94>] ? seq_read+0x148/0x361
        [<ffffffff81132d98>] ? vfs_read+0x93/0xf1
        [<ffffffff81132f1b>] ? SyS_read+0x60/0x8e
        [<ffffffff8150bf9f>] ? tracesys+0xdd/0xe2
      
      Debugging this bug, which triggers when the rb_iter_peek() loops too
      many times (more than 2 times), I discovered there's a case that can
      cause that function to legitimately loop 3 times!
      
      rb_iter_peek() is different than rb_buffer_peek() as the rb_buffer_peek()
      only deals with the reader page (it's for consuming reads). The
      rb_iter_peek() is for traversing the buffer without consuming it, and as
      such, it can loop for one more reason. That is, if we hit the end of
      the reader page or any page, it will go to the next page and try again.
      
      That is, we have this:
      
       1. iter->head > iter->head_page->page->commit
          (rb_inc_iter() which moves the iter to the next page)
          try again
      
       2. event = rb_iter_head_event()
          event->type_len == RINGBUF_TYPE_TIME_EXTEND
          rb_advance_iter()
          try again
      
       3. read the event.
      
      But we never get to 3, because the count is greater than 2 and we
      cause the WARNING and return NULL.
      
      Up the counter to 3.
      
      Fixes: 69d1b839 "ring-buffer: Bind time extend and data events together"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39ed6dfc
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Always reset iterator to reader page · 1cfa896d
      Steven Rostedt (Red Hat) authored
      commit 651e22f2 upstream.
      
      When performing a consuming read, the ring buffer swaps out a
      page from the ring buffer with a empty page and this page that
      was swapped out becomes the new reader page. The reader page
      is owned by the reader and since it was swapped out of the ring
      buffer, writers do not have access to it (there's an exception
      to that rule, but it's out of scope for this commit).
      
      When reading the "trace" file, it is a non consuming read, which
      means that the data in the ring buffer will not be modified.
      When the trace file is opened, a ring buffer iterator is allocated
      and writes to the ring buffer are disabled, such that the iterator
      will not have issues iterating over the data.
      
      Although the ring buffer disabled writes, it does not disable other
      reads, or even consuming reads. If a consuming read happens, then
      the iterator is reset and starts reading from the beginning again.
      
      My tests would sometimes trigger this bug on my i386 box:
      
      WARNING: CPU: 0 PID: 5175 at kernel/trace/trace.c:1527 __trace_find_cmdline+0x66/0xaa()
      Modules linked in:
      CPU: 0 PID: 5175 Comm: grep Not tainted 3.16.0-rc3-test+ #8
      Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
       00000000 00000000 f09c9e1c c18796b3 c1b5d74c f09c9e4c c103a0e3 c1b5154b
       f09c9e78 00001437 c1b5d74c 000005f7 c10bd85a c10bd85a c1cac57c f09c9eb0
       ed0e0000 f09c9e64 c103a185 00000009 f09c9e5c c1b5154b f09c9e78 f09c9e80^M
      Call Trace:
       [<c18796b3>] dump_stack+0x4b/0x75
       [<c103a0e3>] warn_slowpath_common+0x7e/0x95
       [<c10bd85a>] ? __trace_find_cmdline+0x66/0xaa
       [<c10bd85a>] ? __trace_find_cmdline+0x66/0xaa
       [<c103a185>] warn_slowpath_fmt+0x33/0x35
       [<c10bd85a>] __trace_find_cmdline+0x66/0xaa^M
       [<c10bed04>] trace_find_cmdline+0x40/0x64
       [<c10c3c16>] trace_print_context+0x27/0xec
       [<c10c4360>] ? trace_seq_printf+0x37/0x5b
       [<c10c0b15>] print_trace_line+0x319/0x39b
       [<c10ba3fb>] ? ring_buffer_read+0x47/0x50
       [<c10c13b1>] s_show+0x192/0x1ab
       [<c10bfd9a>] ? s_next+0x5a/0x7c
       [<c112e76e>] seq_read+0x267/0x34c
       [<c1115a25>] vfs_read+0x8c/0xef
       [<c112e507>] ? seq_lseek+0x154/0x154
       [<c1115ba2>] SyS_read+0x54/0x7f
       [<c188488e>] syscall_call+0x7/0xb
      ---[ end trace 3f507febd6b4cc83 ]---
      >>>> ##### CPU 1 buffer started ####
      
      Which was the __trace_find_cmdline() function complaining about the pid
      in the event record being negative.
      
      After adding more test cases, this would trigger more often. Strangely
      enough, it would never trigger on a single test, but instead would trigger
      only when running all the tests. I believe that was the case because it
      required one of the tests to be shutting down via delayed instances while
      a new test started up.
      
      After spending several days debugging this, I found that it was caused by
      the iterator becoming corrupted. Debugging further, I found out why
      the iterator became corrupted. It happened with the rb_iter_reset().
      
      As consuming reads may not read the full reader page, and only part
      of it, there's a "read" field to know where the last read took place.
      The iterator, must also start at the read position. In the rb_iter_reset()
      code, if the reader page was disconnected from the ring buffer, the iterator
      would start at the head page within the ring buffer (where writes still
      happen). But the mistake there was that it still used the "read" field
      to start the iterator on the head page, where it should always start
      at zero because readers never read from within the ring buffer where
      writes occur.
      
      I originally wrote a patch to have it set the iter->head to 0 instead
      of iter->head_page->read, but then I questioned why it wasn't always
      setting the iter to point to the reader page, as the reader page is
      still valid.  The list_empty(reader_page->list) just means that it was
      successful in swapping out. But the reader_page may still have data.
      
      There was a bug report a long time ago that was not reproducible that
      had something about trace_pipe (consuming read) not matching trace
      (iterator read). This may explain why that happened.
      
      Anyway, the correct answer to this bug is to always use the reader page
      an not reset the iterator to inside the writable ring buffer.
      
      Fixes: d769041f "ring_buffer: implement new locking"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cfa896d
    • David Vrabel's avatar
      xen/events/fifo: reset control block and local HEADs on resume · d52143d8
      David Vrabel authored
      commit c12784c3 upstream.
      
      When using the FIFO-based event channel ABI, if the control block or
      the local HEADs are not reset after resuming the guest may see stale
      HEAD values and will fail to traverse the FIFO correctly.
      
      This may prevent one or more VCPUs from receiving any events following
      a resume.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d52143d8
    • Hans de Goede's avatar
    • Hans de Goede's avatar
      ACPI / video: Add a disable_native_backlight quirk · 710ea3f5
      Hans de Goede authored
      commit 5f24079b upstream.
      
      Some laptops have a working acpi_video backlight control, and using native
      backlight on these causes a regression where backlight control does not work
      when userspace is not handling brightness key events. Disable native_backlight
      on these to fix this.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691Reported-and-tested-by: default avatarAndre Müller <andre.muller@web.de>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      710ea3f5
    • Hans de Goede's avatar
      ACPI / video: Fix use_native_backlight selection logic · 651dd54f
      Hans de Goede authored
      commit 25294e9f upstream.
      
      Commit 751109aa ("ACPI / video: Change the default for
      video.use_native_backlight to 1") has changed the default for
      use_native_backlight from 0 to 1, but instead of changing
      use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1,
      it has changed use_native_backlight_param to 1.
      
      This causes acpi_video_use_native_backlight() to always think that a value was
      specified through the param, making it impossible to add a dmi based quirk
      to force 0 now that the default is 1.
      
      This fixes this by restoring the use_native_backlight_param default to -1, and
      instead setting the use_native_backlight_dmi default to true.
      
      Fixes: 751109aa (ACPI / video: Change the default for video.use_native_backlight to 1)
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      651dd54f
    • Jiri Kosina's avatar
      ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock · d1c06203
      Jiri Kosina authored
      commit 6726655d upstream.
      
      There is a following AB-BA dependency between cpu_hotplug.lock and
      cpuidle_lock:
      
      1) cpu_hotplug.lock -> cpuidle_lock
      enable_nonboot_cpus()
       _cpu_up()
        cpu_hotplug_begin()
         LOCK(cpu_hotplug.lock)
       cpu_notify()
        ...
        acpi_processor_hotplug()
         cpuidle_pause_and_lock()
          LOCK(cpuidle_lock)
      
      2) cpuidle_lock -> cpu_hotplug.lock
      acpi_os_execute_deferred() workqueue
       ...
       acpi_processor_cst_has_changed()
        cpuidle_pause_and_lock()
         LOCK(cpuidle_lock)
        get_online_cpus()
         LOCK(cpu_hotplug.lock)
      
      Fix this by reversing the order acpi_processor_cst_has_changed() does
      thigs -- let it first execute the protection against CPU hotplug by
      calling get_online_cpus() and obtain the cpuidle lock only after that (and
      perform the symmentric change when allowing CPUs hotplug again and
      dropping cpuidle lock).
      
      Spotted by lockdep.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1c06203
    • Yasuaki Ishimatsu's avatar
      ACPI / scan: not cache _SUN value in struct acpi_device_pnp · ca16ec3a
      Yasuaki Ishimatsu authored
      commit a383b68d upstream.
      
      The _SUN device indentification object is not guaranteed to return
      the same value every time it is executed, so we should not cache its
      return value, but rather execute it every time as needed.  If it is
      cached, an incorrect stale value may be used in some situations.
      
      This issue was exposed by commit 202317a5 (ACPI / scan: Add
      acpi_device objects for all device nodes in the namespace).  Fix it
      by avoiding to cache the return value of _SUN.
      
      Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
      Signed-off-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      [ rjw: Changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca16ec3a
    • Lv Zheng's avatar
      ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC · 37da49c1
      Lv Zheng authored
      commit 558e4736 upstream.
      
      There is platform refusing to respond QR_EC when SCI_EVT isn't set
      which is Acer Aspire V5-573G.
      
      By disallowing QR_EC to be issued before the previous one has been
      completed we are able to reduce the possibilities to trigger issues on
      such platforms.
      
      Note that this fix can only reduce the occurrence rate of this issue, but
      this issue may still occur when such a platform doesn't clear SCI_EVT
      before or immediately after completing the previous QR_EC transaction.
      This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
      the assumption that the platforms are able to respond even when SCI_EVT
      isn't set.
      
      But this patch is still useful as it can help to reduce the number of
      scheduled QR_EC work items.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611Reported-and-tested-by: default avatarAlexander Mezin <mezin.alexander@gmail.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37da49c1
    • Lv Zheng's avatar
      ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set · 692749e8
      Lv Zheng authored
      commit 3afcf2ec upstream.
      
      There is a platform refusing to respond QR_EC when SCI_EVT isn't set
      (Acer Aspire V5-573G).
      
      Currently, we rely on the behaviour that the EC firmware can respond
      something (for example, 0x00 to indicate "no outstanding events") to
      QR_EC even when SCI_EVT is not set, but the reporter has complained
      about AC/battery pluging/unpluging and video brightness change delay
      on that platform.
      
      This is because the work item that has issued QR_EC has to wait until
      timeout in this case, and the _Qxx method evaluation work item queued
      after QR_EC one is delayed.
      
      It sounds reasonable to fix this issue by:
       1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC
          driver's main state machine.
       2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation
          to a seperate IRQ handling thread.
      
      This patch fixes this issue using solution 1.
      
      By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to
      handle such platform in the EC driver's main state machine. This patch
      enhances the state machine in this way to survive with such malfunctioning
      EC firmware.
      
      Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies
      on the assumption that the platforms are able to respond even when SCI_EVT
      isn't set.
      
      Fixes: c0d65341 ACPI / EC: Fix race condition in ec_transaction_completed()
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611Reported-and-tested-by: default avatarAlexander Mezin <mezin.alexander@gmail.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      692749e8
    • Rafael J. Wysocki's avatar
      ACPI / scan: Allow ACPI drivers to bind to PNP device objects · afdd3bcc
      Rafael J. Wysocki authored
      commit fc2e0a83 upstream.
      
      We generally don't allow ACPI drivers to bind to ACPI device objects
      that companion "physical" device objects are created for to avoid
      situations in which two different drivers may attempt to handle one
      device at the same time.  Recent ACPI device enumeration rework
      extended that approach to ACPI PNP devices by starting to use a scan
      handler for enumerating them.  However, we previously allowed ACPI
      drivers to bind to ACPI device objects with existing PNP device
      companions and changing that led to functional regressions on some
      systems.
      
      For this reason, add a special check for PNP devices in
      acpi_device_probe() so that ACPI drivers can bind to ACPI device
      objects having existing PNP device companions as before.
      
      Fixes: eec15edb (ACPI / PNP: use device ID list for PNPACPI device enumeration)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971Reported-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Reported-by: default avatarDirk Griesbach <spamthis@freenet.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afdd3bcc
    • Lan Tianyu's avatar
      ACPI: Run fixed event device notifications in process context · baf705af
      Lan Tianyu authored
      commit 236105db upstream.
      
      Currently, notify callbacks for fixed button events are run from
      interrupt context.  That is not necessary and after commit 0bf6368e
      (ACPI / button: Add ACPI Button event via netlink routine) it causes
      netlink routines to be called from interrupt context which is not
      correct.
      
      Also, that is different from non-fixed device events (including
      non-fixed button events) whose notify callbacks are all executed from
      process context.
      
      For the above reasons, make fixed button device notify callbacks run
      in process context which will avoid the deadlock when using netlink
      to report button events to user space.
      
      Fixes: 0bf6368e (ACPI / button: Add ACPI Button event via netlink routine)
      Link: https://lkml.org/lkml/2014/8/21/606Reported-by: default avatarBenjamin Block <bebl@mageta.org>
      Reported-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Signed-off-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      [rjw: Function names, subject and changelog.]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      baf705af