1. 06 Jan, 2017 40 commits
    • Dan Carpenter's avatar
      ext4: return -ENOMEM instead of success · acf3efd6
      Dan Carpenter authored
      commit 578620f4 upstream.
      
      We should set the error code if kzalloc() fails.
      
      Fixes: 67cf5b09 ("ext4: add the basic function for inline data support")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acf3efd6
    • Darrick J. Wong's avatar
      ext4: reject inodes with negative size · 3e4f8da9
      Darrick J. Wong authored
      commit 7e6e1ef4 upstream.
      
      Don't load an inode with a negative size; this causes integer overflow
      problems in the VFS.
      
      [ Added EXT4_ERROR_INODE() to mark file system as corrupted. -TYT]
      
      Fixes: a48380f7 (ext4: rename i_dir_acl to i_size_high)
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e4f8da9
    • Theodore Ts'o's avatar
      ext4: add sanity checking to count_overhead() · 8084f57b
      Theodore Ts'o authored
      commit c48ae41b upstream.
      
      The commit "ext4: sanity check the block and cluster size at mount
      time" should prevent any problems, but in case the superblock is
      modified while the file system is mounted, add an extra safety check
      to make sure we won't overrun the allocated buffer.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8084f57b
    • Theodore Ts'o's avatar
      ext4: fix in-superblock mount options processing · 956e2a0e
      Theodore Ts'o authored
      commit 5aee0f8a upstream.
      
      Fix a large number of problems with how we handle mount options in the
      superblock.  For one, if the string in the superblock is long enough
      that it is not null terminated, we could run off the end of the string
      and try to interpret superblocks fields as characters.  It's unlikely
      this will cause a security problem, but it could result in an invalid
      parse.  Also, parse_options is destructive to the string, so in some
      cases if there is a comma-separated string, it would be modified in
      the superblock.  (Fortunately it only happens on file systems with a
      1k block size.)
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      956e2a0e
    • Theodore Ts'o's avatar
      ext4: use more strict checks for inodes_per_block on mount · 01772f46
      Theodore Ts'o authored
      commit cd6bb35b upstream.
      
      Centralize the checks for inodes_per_block and be more strict to make
      sure the inodes_per_block_group can't end up being zero.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01772f46
    • Chandan Rajendra's avatar
      ext4: fix stack memory corruption with 64k block size · b493c715
      Chandan Rajendra authored
      commit 30a9d7af upstream.
      
      The number of 'counters' elements needed in 'struct sg' is
      super_block->s_blocksize_bits + 2. Presently we have 16 'counters'
      elements in the array. This is insufficient for block sizes >= 32k. In
      such cases the memcpy operation performed in ext4_mb_seq_groups_show()
      would cause stack memory corruption.
      
      Fixes: c9de560dSigned-off-by: default avatarChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b493c715
    • Chandan Rajendra's avatar
      ext4: fix mballoc breakage with 64k block size · c3881aba
      Chandan Rajendra authored
      commit 69e43e8c upstream.
      
      'border' variable is set to a value of 2 times the block size of the
      underlying filesystem. With 64k block size, the resulting value won't
      fit into a 16-bit variable. Hence this commit changes the data type of
      'border' to 'unsigned int'.
      
      Fixes: c9de560dSigned-off-by: default avatarChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3881aba
    • Theodore Ts'o's avatar
      ext4: don't lock buffer in ext4_commit_super if holding spinlock · 24d1251a
      Theodore Ts'o authored
      commit 1566a48a upstream.
      
      If there is an error reported in mballoc via ext4_grp_locked_error(),
      the code is holding a spinlock, so ext4_commit_super() must not try to
      lock the buffer head, or else it will trigger a BUG:
      
        BUG: sleeping function called from invalid context at ./include/linux/buffer_head.h:358
        in_atomic(): 1, irqs_disabled(): 0, pid: 993, name: mount
        CPU: 0 PID: 993 Comm: mount Not tainted 4.9.0-rc1-clouder1 #62
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
         ffff880006423548 ffffffff81318c89 ffffffff819ecdd0 0000000000000166
         ffff880006423558 ffffffff810810b0 ffff880006423580 ffffffff81081153
         ffff880006e5a1a0 ffff88000690e400 0000000000000000 ffff8800064235c0
        Call Trace:
          [<ffffffff81318c89>] dump_stack+0x67/0x9e
          [<ffffffff810810b0>] ___might_sleep+0xf0/0x140
          [<ffffffff81081153>] __might_sleep+0x53/0xb0
          [<ffffffff8126c1dc>] ext4_commit_super+0x19c/0x290
          [<ffffffff8126e61a>] __ext4_grp_locked_error+0x14a/0x230
          [<ffffffff81081153>] ? __might_sleep+0x53/0xb0
          [<ffffffff812822be>] ext4_mb_generate_buddy+0x1de/0x320
      
      Since ext4_grp_locked_error() calls ext4_commit_super with sync == 0
      (and it is the only caller which does so), avoid locking and unlocking
      the buffer in this case.
      
      This can result in races with ext4_commit_super() if there are other
      problems (which is what commit 4743f839 was trying to address),
      but a Warning is better than BUG.
      
      Fixes: 4743f839Reported-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24d1251a
    • Alex Porosanu's avatar
      crypto: caam - fix AEAD givenc descriptors · 21cc9155
      Alex Porosanu authored
      commit d128af17 upstream.
      
      The AEAD givenc descriptor relies on moving the IV through the
      output FIFO and then back to the CTX2 for authentication. The
      SEQ FIFO STORE could be scheduled before the data can be
      read from OFIFO, especially since the SEQ FIFO LOAD needs
      to wait for the SEQ FIFO LOAD SKIP to finish first. The
      SKIP takes more time when the input is SG than when it's
      a contiguous buffer. If the SEQ FIFO LOAD is not scheduled
      before the STORE, the DECO will hang waiting for data
      to be available in the OFIFO so it can be transferred to C2.
      In order to overcome this, first force transfer of IV to C2
      by starting the "cryptlen" transfer first and then starting to
      store data from OFIFO to the output buffer.
      
      Fixes: 1acebad3 ("crypto: caam - faster aead implementation")
      Signed-off-by: default avatarAlex Porosanu <alexandru.porosanu@nxp.com>
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21cc9155
    • Eric W. Biederman's avatar
      ptrace: Don't allow accessing an undumpable mm · e71b4e06
      Eric W. Biederman authored
      commit 84d77d3f upstream.
      
      It is the reasonable expectation that if an executable file is not
      readable there will be no way for a user without special privileges to
      read the file.  This is enforced in ptrace_attach but if ptrace
      is already attached before exec there is no enforcement for read-only
      executables.
      
      As the only way to read such an mm is through access_process_vm
      spin a variant called ptrace_access_vm that will fail if the
      target process is not being ptraced by the current process, or
      the current process did not have sufficient privileges when ptracing
      began to read the target processes mm.
      
      In the ptrace implementations replace access_process_vm by
      ptrace_access_vm.  There remain several ptrace sites that still use
      access_process_vm as they are reading the target executables
      instructions (for kernel consumption) or register stacks.  As such it
      does not appear necessary to add a permission check to those calls.
      
      This bug has always existed in Linux.
      
      Fixes: v1.0
      Reported-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e71b4e06
    • Eric W. Biederman's avatar
      ptrace: Capture the ptracer's creds not PT_PTRACE_CAP · e747b4ae
      Eric W. Biederman authored
      commit 64b875f7 upstream.
      
      When the flag PT_PTRACE_CAP was added the PTRACE_TRACEME path was
      overlooked.  This can result in incorrect behavior when an application
      like strace traces an exec of a setuid executable.
      
      Further PT_PTRACE_CAP does not have enough information for making good
      security decisions as it does not report which user namespace the
      capability is in.  This has already allowed one mistake through
      insufficient granulariy.
      
      I found this issue when I was testing another corner case of exec and
      discovered that I could not get strace to set PT_PTRACE_CAP even when
      running strace as root with a full set of caps.
      
      This change fixes the above issue with strace allowing stracing as
      root a setuid executable without disabling setuid.  More fundamentaly
      this change allows what is allowable at all times, by using the correct
      information in it's decision.
      
      Fixes: 4214e42f96d4 ("v2.4.9.11 -> v2.4.9.12")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e747b4ae
    • Linus Torvalds's avatar
      vfs,mm: fix return value of read() at s_maxbytes · 48466c47
      Linus Torvalds authored
      commit d05c5f7b upstream.
      
      We truncated the possible read iterator to s_maxbytes in commit
      c2a9737f ("vfs,mm: fix a dead loop in truncate_inode_pages_range()"),
      but our end condition handling was wrong: it's not an error to try to
      read at the end of the file.
      
      Reading past the end should return EOF (0), not EINVAL.
      
      See for example
      
        https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1649342
        http://lists.gnu.org/archive/html/bug-coreutils/2016-12/msg00008.html
      
      where a md5sum of a maximally sized file fails because the final read is
      exactly at s_maxbytes.
      
      Fixes: c2a9737f ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
      Reported-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      Cc: Wei Fang <fangwei1@huawei.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew 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>
      48466c47
    • Eric W. Biederman's avatar
      mm: Add a user_ns owner to mm_struct and fix ptrace permission checks · 694a95fa
      Eric W. Biederman authored
      commit bfedb589 upstream.
      
      During exec dumpable is cleared if the file that is being executed is
      not readable by the user executing the file.  A bug in
      ptrace_may_access allows reading the file if the executable happens to
      enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
      unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).
      
      This problem is fixed with only necessary userspace breakage by adding
      a user namespace owner to mm_struct, captured at the time of exec, so
      it is clear in which user namespace CAP_SYS_PTRACE must be present in
      to be able to safely give read permission to the executable.
      
      The function ptrace_may_access is modified to verify that the ptracer
      has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns.
      This ensures that if the task changes it's cred into a subordinate
      user namespace it does not become ptraceable.
      
      The function ptrace_attach is modified to only set PT_PTRACE_CAP when
      CAP_SYS_PTRACE is held over task->mm->user_ns.  The intent of
      PT_PTRACE_CAP is to be a flag to note that whatever permission changes
      the task might go through the tracer has sufficient permissions for
      it not to be an issue.  task->cred->user_ns is always the same
      as or descendent of mm->user_ns.  Which guarantees that having
      CAP_SYS_PTRACE over mm->user_ns is the worst case for the tasks
      credentials.
      
      To prevent regressions mm->dumpable and mm->user_ns are not considered
      when a task has no mm.  As simply failing ptrace_may_attach causes
      regressions in privileged applications attempting to read things
      such as /proc/<pid>/stat
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Fixes: 8409cca7 ("userns: allow ptrace from non-init user namespaces")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      694a95fa
    • NeilBrown's avatar
      block_dev: don't test bdev->bd_contains when it is not stable · cfa2d65b
      NeilBrown authored
      commit bcc7f5b4 upstream.
      
      bdev->bd_contains is not stable before calling __blkdev_get().
      When __blkdev_get() is called on a parition with ->bd_openers == 0
      it sets
        bdev->bd_contains = bdev;
      which is not correct for a partition.
      After a call to __blkdev_get() succeeds, ->bd_openers will be > 0
      and then ->bd_contains is stable.
      
      When FMODE_EXCL is used, blkdev_get() calls
         bd_start_claiming() ->  bd_prepare_to_claim() -> bd_may_claim()
      
      This call happens before __blkdev_get() is called, so ->bd_contains
      is not stable.  So bd_may_claim() cannot safely use ->bd_contains.
      It currently tries to use it, and this can lead to a BUG_ON().
      
      This happens when a whole device is already open with a bd_holder (in
      use by dm in my particular example) and two threads race to open a
      partition of that device for the first time, one opening with O_EXCL and
      one without.
      
      The thread that doesn't use O_EXCL gets through blkdev_get() to
      __blkdev_get(), gains the ->bd_mutex, and sets bdev->bd_contains = bdev;
      
      Immediately thereafter the other thread, using FMODE_EXCL, calls
      bd_start_claiming() from blkdev_get().  This should fail because the
      whole device has a holder, but because bdev->bd_contains == bdev
      bd_may_claim() incorrectly reports success.
      This thread continues and blocks on bd_mutex.
      
      The first thread then sets bdev->bd_contains correctly and drops the mutex.
      The thread using FMODE_EXCL then continues and when it calls bd_may_claim()
      again in:
      			BUG_ON(!bd_may_claim(bdev, whole, holder));
      The BUG_ON fires.
      
      Fix this by removing the dependency on ->bd_contains in
      bd_may_claim().  As bd_may_claim() has direct access to the whole
      device, it can simply test if the target bdev is the whole device.
      
      Fixes: 6b4517a7 ("block: implement bd_claiming and claiming block")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfa2d65b
    • Linus Torvalds's avatar
      splice: reinstate SIGPIPE/EPIPE handling · b6cce9b8
      Linus Torvalds authored
      commit 52bce911 upstream.
      
      Commit 8924feff ("splice: lift pipe_lock out of splice_to_pipe()")
      caused a regression when there were no more readers left on a pipe that
      was being spliced into: rather than the expected SIGPIPE and -EPIPE
      return value, the writer would end up waiting forever for space to free
      up (which obviously was not going to happen with no readers around).
      
      Fixes: 8924feff ("splice: lift pipe_lock out of splice_to_pipe()")
      Reported-and-tested-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      Debugged-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6cce9b8
    • Aleksa Sarai's avatar
      fs: exec: apply CLOEXEC before changing dumpable task flags · c1df5a63
      Aleksa Sarai authored
      commit 613cc2b6 upstream.
      
      If you have a process that has set itself to be non-dumpable, and it
      then undergoes exec(2), any CLOEXEC file descriptors it has open are
      "exposed" during a race window between the dumpable flags of the process
      being reset for exec(2) and CLOEXEC being applied to the file
      descriptors. This can be exploited by a process by attempting to access
      /proc/<pid>/fd/... during this window, without requiring CAP_SYS_PTRACE.
      
      The race in question is after set_dumpable has been (for get_link,
      though the trace is basically the same for readlink):
      
      [vfs]
      -> proc_pid_link_inode_operations.get_link
         -> proc_pid_get_link
            -> proc_fd_access_allowed
               -> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
      
      Which will return 0, during the race window and CLOEXEC file descriptors
      will still be open during this window because do_close_on_exec has not
      been called yet. As a result, the ordering of these calls should be
      reversed to avoid this race window.
      
      This is of particular concern to container runtimes, where joining a
      PID namespace with file descriptors referring to the host filesystem
      can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect
      against access of CLOEXEC file descriptors -- file descriptors which may
      reference filesystem objects the container shouldn't have access to).
      
      Cc: dev@opencontainers.org
      Reported-by: default avatarMichael Crosby <crosbymichael@gmail.com>
      Signed-off-by: default avatarAleksa Sarai <asarai@suse.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1df5a63
    • Eric W. Biederman's avatar
      exec: Ensure mm->user_ns contains the execed files · 21245b86
      Eric W. Biederman authored
      commit f84df2a6 upstream.
      
      When the user namespace support was merged the need to prevent
      ptrace from revealing the contents of an unreadable executable
      was overlooked.
      
      Correct this oversight by ensuring that the executed file
      or files are in mm->user_ns, by adjusting mm->user_ns.
      
      Use the new function privileged_wrt_inode_uidgid to see if
      the executable is a member of the user namespace, and as such
      if having CAP_SYS_PTRACE in the user namespace should allow
      tracing the executable.  If not update mm->user_ns to
      the parent user namespace until an appropriate parent is found.
      Reported-by: default avatarJann Horn <jann@thejh.net>
      Fixes: 9e4a36ec ("userns: Fail exec for suid and sgid binaries with ids outside our user namespace.")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21245b86
    • Richard Watts's avatar
      clk: ti: omap36xx: Work around sprz319 advisory 2.1 · 0de98eef
      Richard Watts authored
      commit 035cd485 upstream.
      
      The OMAP36xx DPLL5, driving EHCI USB, can be subject to a long-term
      frequency drift. The frequency drift magnitude depends on the VCO update
      rate, which is inversely proportional to the PLL divider. The kernel
      DPLL configuration code results in a high value for the divider, leading
      to a long term drift high enough to cause USB transmission errors. In
      the worst case the USB PHY's ULPI interface can stop responding,
      breaking USB operation completely. This manifests itself on the
      Beagleboard xM by the LAN9514 reporting 'Cannot enable port 2. Maybe the
      cable is bad?' in the kernel log.
      
      Errata sprz319 advisory 2.1 documents PLL values that minimize the
      drift. Use them automatically when DPLL5 is used for USB operation,
      which we detect based on the requested clock rate. The clock framework
      will still compute the PLL parameters and resulting rate as usual, but
      the PLL M and N values will then be overridden. This can result in the
      effective clock rate being slightly different than the rate cached by
      the clock framework, but won't cause any adverse effect to USB
      operation.
      Signed-off-by: default avatarRichard Watts <rrw@kynesim.co.uk>
      [Upported from v3.2 to v4.9]
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Tested-by: default avatarLadislav Michl <ladis@linux-mips.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Cc: Adam Ford <aford173@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0de98eef
    • Kai-Heng Feng's avatar
      ALSA: hda: when comparing pin configurations, ignore assoc in addition to seq · 0ce4f000
      Kai-Heng Feng authored
      commit 5e0ad0d8 upstream.
      
      Commit [64047d7f ALSA: hda - ignore the assoc and seq when comparing
      pin configurations] intented to ignore both seq and assoc at pin
      comparing, but it only ignored seq. So that commit may still fail to
      match pins on some machines.
      Change the bitmask to also ignore assoc.
      
      v2: Use macro to do bit masking.
      
      Thanks to Hui Wang for the analysis.
      
      Fixes: 64047d7f ("ALSA: hda - ignore the assoc and seq when comparing...")
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ce4f000
    • Takashi Iwai's avatar
      ALSA: hda - Gate the mic jack on HP Z1 Gen3 AiO · e029ef3a
      Takashi Iwai authored
      commit f73cd43a upstream.
      
      HP Z1 Gen3 AiO with Conexant codec doesn't give an unsolicited event
      to the headset mic pin upon the jack plugging, it reports only to the
      headphone pin.  It results in the missing mic switching.  Let's fix up
      by simply gating the jack event.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e029ef3a
    • Hui Wang's avatar
      ALSA: hda - fix headset-mic problem on a Dell laptop · 0119d5d4
      Hui Wang authored
      commit 989dbe4a upstream.
      
      This group of new pins is not in the pin quirk table yet, adding
      them to the pin quirk table to fix the headset-mic problem.
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0119d5d4
    • Hui Wang's avatar
      ALSA: hda - ignore the assoc and seq when comparing pin configurations · 37b7c5db
      Hui Wang authored
      commit 64047d7f upstream.
      
      More and more pin configurations have been adding to the pin quirk
      table, lots of them are only different from assoc and seq, but they
      all apply to the same QUIRK_FIXUP, if we don't compare assoc and seq
      when matching pin configurations, it will greatly reduce the pin
      quirk table size.
      
      We have tested this change on a couple of Dell laptops, it worked
      well.
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37b7c5db
    • Sven Hahne's avatar
      ALSA: hda/ca0132 - Add quirk for Alienware 15 R2 2016 · 0f1047be
      Sven Hahne authored
      commit b5337cfe upstream.
      
      I'm using an Alienware 15 R2 and had to use the alienware quirks to
      get my headphone output working.
      
      I fixed it by adding, SND_PCI_QUIRK(0x1028, 0x0708, "Alienware 15 R2
      2016", QUIRK_ALIENWARE) to the patch.
      Signed-off-by: default avatarSven Hahne <hahne@zeitkunst.eu>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f1047be
    • Jussi Laako's avatar
      ALSA: hiface: Fix M2Tech hiFace driver sampling rate change · fa2e770f
      Jussi Laako authored
      commit 995c6a7f upstream.
      
      Sampling rate changes after first set one are not reflected to the
      hardware, while driver and ALSA think the rate has been changed.
      
      Fix the problem by properly stopping the interface at the beginning of
      prepare call, allowing new rate to be set to the hardware. This keeps
      the hardware in sync with the driver.
      Signed-off-by: default avatarJussi Laako <jussi@sonarnerd.net>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa2e770f
    • Con Kolivas's avatar
      ALSA: usb-audio: Add QuickCam Communicate Deluxe/S7500 to volume_control_quirks · 205d3de9
      Con Kolivas authored
      commit 82ffb6fc upstream.
      
      The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the
      following warning.
      
      [    6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072),
      cval->res is probably wrong.
      [    6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val =
      4608/7680/1
      
      Adding it to the list of devices in volume_control_quirks makes it work
      properly, fixing related typo.
      Signed-off-by: default avatarCon Kolivas <kernel@kolivas.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      205d3de9
    • Krzysztof Opasiak's avatar
      usbip: vudc: fix: Clear already_seen flag also for ep0 · 77bd73ce
      Krzysztof Opasiak authored
      commit 3e448e13 upstream.
      
      ep_list inside gadget structure doesn't contain ep0.
      It is stored separately in ep0 field.
      
      This causes an urb hang if gadget driver decides to
      delay setup handling. On host side this is visible as
      timeout error when setting configuration.
      
      This bug can be reproduced using for example any gadget
      with mass storage function.
      
      Fixes: abdb2957 ("usbip: vudc: Add vudc_transfer")
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Acked-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      77bd73ce
    • Alan Stern's avatar
      USB: UHCI: report non-PME wakeup signalling for Intel hardware · 420f170c
      Alan Stern authored
      commit ccdb6be9 upstream.
      
      The UHCI controllers in Intel chipsets rely on a platform-specific non-PME
      mechanism for wakeup signalling.  They can generate wakeup signals even
      though they don't support PME.
      
      We need to let the USB core know this so that it will enable runtime
      suspend for UHCI controllers.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      420f170c
    • Felipe Balbi's avatar
      usb: gadget: composite: correctly initialize ep->maxpacket · e0aa5ec4
      Felipe Balbi authored
      commit e8f29bb7 upstream.
      
      usb_endpoint_maxp() returns wMaxPacketSize in its
      raw form. Without taking into consideration that it
      also contains other bits reserved for isochronous
      endpoints.
      
      This patch fixes one occasion where this is a
      problem by making sure that we initialize
      ep->maxpacket only with lower 10 bits of the value
      returned by usb_endpoint_maxp(). Note that seperate
      patches will be necessary to audit all call sites of
      usb_endpoint_maxp() and make sure that
      usb_endpoint_maxp() only returns lower 10 bits of
      wMaxPacketSize.
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0aa5ec4
    • Peter Chen's avatar
      usb: gadget: f_uac2: fix error handling at afunc_bind · 5180169d
      Peter Chen authored
      commit f1d3861d upstream.
      
      The current error handling flow uses incorrect goto label, fix it
      
      Fixes: d12a8727 ("usb: gadget: function: Remove redundant usb_free_all_descriptors")
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5180169d
    • Rafał Miłecki's avatar
      usb: core: usbport: Use proper LED API to fix potential crash · eab16939
      Rafał Miłecki authored
      commit 89778ba3 upstream.
      
      Calling brightness_set manually isn't safe as some LED drivers don't
      implement this callback. The best idea is to just use a proper helper
      which will fallback to the brightness_set_blocking callback if needed.
      
      This fixes:
      [ 1461.761528] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      (...)
      [ 1462.117049] Backtrace:
      [ 1462.119521] [<bf228164>] (usbport_trig_port_store [ledtrig_usbport]) from [<c023f758>] (dev_attr_store+0x20/0x2c)
      [ 1462.129826]  r7:dcabc7c0 r6:dee0ff80 r5:00000002 r4:bf228164
      [ 1462.135511] [<c023f738>] (dev_attr_store) from [<c0169310>] (sysfs_kf_write+0x48/0x4c)
      [ 1462.143459]  r5:00000002 r4:c023f738
      [ 1462.147049] [<c01692c8>] (sysfs_kf_write) from [<c0168ab8>] (kernfs_fop_write+0xf8/0x1f8)
      [ 1462.155258]  r5:00000002 r4:df4a1000
      [ 1462.158850] [<c01689c0>] (kernfs_fop_write) from [<c0100c78>] (__vfs_write+0x34/0x120)
      [ 1462.166800]  r10:00000000 r9:dee0e000 r8:c000fc24 r7:00000002 r6:dee0ff80 r5:c01689c0
      [ 1462.174660]  r4:df727a80
      [ 1462.177204] [<c0100c44>] (__vfs_write) from [<c0101ae4>] (vfs_write+0xac/0x170)
      [ 1462.184543]  r9:dee0e000 r8:c000fc24 r7:dee0ff80 r6:b6f092d0 r5:df727a80 r4:00000002
      [ 1462.192319] [<c0101a38>] (vfs_write) from [<c01028dc>] (SyS_write+0x4c/0xa8)
      [ 1462.199396]  r9:dee0e000 r8:c000fc24 r7:00000002 r6:b6f092d0 r5:df727a80 r4:df727a80
      [ 1462.207174] [<c0102890>] (SyS_write) from [<c000fa60>] (ret_fast_syscall+0x0/0x3c)
      [ 1462.214774]  r7:00000004 r6:ffffffff r5:00000000 r4:00000000
      [ 1462.220456] Code: bad PC value
      [ 1462.223560] ---[ end trace 676638a3a12c7a56 ]---
      Reported-by: default avatarRalph Sennhauser <ralph.sennhauser@gmail.com>
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      Fixes: 0f247626 ("usb: core: Introduce a USB port LED trigger")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eab16939
    • Mathias Nyman's avatar
      usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices · 32a35351
      Mathias Nyman authored
      commit 37be6676 upstream.
      
      USB-3 does not have any link state that will avoid negotiating a connection
      with a plugged-in cable but will signal the host when the cable is
      unplugged.
      
      For USB-3 we used to first set the link to Disabled, then to RxDdetect to
      be able to detect cable connects or disconnects. But in RxDetect the
      connected device is detected again and eventually enabled.
      
      Instead set the link into U3 and disable remote wakeups for the device.
      This is what Windows does, and what Alan Stern suggested.
      
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32a35351
    • Felipe Balbi's avatar
      usb: dwc3: gadget: set PCM1 field of isochronous-first TRBs · 3666b628
      Felipe Balbi authored
      commit 6b9018d4 upstream.
      
      In case of High-Speed, High-Bandwidth endpoints, we
      need to tell DWC3 that we have more than one packet
      per interval. We do that by setting PCM1 field of
      Isochronous-First TRB.
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3666b628
    • Nathaniel Quillin's avatar
      USB: cdc-acm: add device id for GW Instek AFG-125 · 20d7c1a6
      Nathaniel Quillin authored
      commit 30121604 upstream.
      
      Add device-id entry for GW Instek AFG-125, which has a byte swapped
      bInterfaceSubClass (0x20).
      Signed-off-by: default avatarNathaniel Quillin <ndq@google.com>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20d7c1a6
    • Johan Hovold's avatar
      USB: serial: kl5kusb105: fix open error path · c094cd32
      Johan Hovold authored
      commit 6774d5f5 upstream.
      
      Kill urbs and disable read before returning from open on failure to
      retrieve the line state.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c094cd32
    • Giuseppe Lippolis's avatar
      USB: serial: option: add dlink dwm-158 · 5e7c90bd
      Giuseppe Lippolis authored
      commit d8a12b71 upstream.
      
      Adding registration for 3G modem DWM-158 in usb-serial-option
      Signed-off-by: default avatarGiuseppe Lippolis <giu.lippolis@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e7c90bd
    • Daniele Palmas's avatar
      USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041 · 142513d6
      Daniele Palmas authored
      commit 5b09eff0 upstream.
      
      This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A.
      
      Since the interface positions are the same than the ones used
      for other Telit compositions, previous defined blacklists are used.
      Signed-off-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      142513d6
    • Filipe Manana's avatar
      Btrfs: fix qgroup rescan worker initialization · 1a5ec7dd
      Filipe Manana authored
      commit 8d9eddad upstream.
      
      We were setting the qgroup_rescan_running flag to true only after the
      rescan worker started (which is a task run by a queue). So if a user
      space task starts a rescan and immediately after asks to wait for the
      rescan worker to finish, this second call might happen before the rescan
      worker task starts running, in which case the rescan wait ioctl returns
      immediatley, not waiting for the rescan worker to finish.
      
      This was making the fstest btrfs/022 fail very often.
      
      Fixes: d2c609b8 (btrfs: properly track when rescan worker is running)
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a5ec7dd
    • Filipe Manana's avatar
      Btrfs: fix emptiness check for dirtied extent buffers at check_leaf() · a1e0e047
      Filipe Manana authored
      commit f177d739 upstream.
      
      We can not simply use the owner field from an extent buffer's header to
      get the id of the respective tree when the extent buffer is from a
      relocation tree. When we create the root for a relocation tree we leave
      (on purpose) the owner field with the same value as the subvolume's tree
      root (we do this at ctree.c:btrfs_copy_root()). So we must ignore extent
      buffers from relocation trees, which have the BTRFS_HEADER_FLAG_RELOC
      flag set, because otherwise we will always consider the extent buffer
      as not being the root of the tree (the root of original subvolume tree
      is always different from the root of the respective relocation tree).
      
      This lead to assertion failures when running with the integrity checker
      enabled (CONFIG_BTRFS_FS_CHECK_INTEGRITY=y) such as the following:
      
      [  643.393409] BTRFS critical (device sdg): corrupt leaf, non-root leaf's nritems is 0: block=38506496, root=260, slot=0
      [  643.397609] BTRFS info (device sdg): leaf 38506496 total ptrs 0 free space 3995
      [  643.407075] assertion failed: 0, file: fs/btrfs/disk-io.c, line: 4078
      [  643.408425] ------------[ cut here ]------------
      [  643.409112] kernel BUG at fs/btrfs/ctree.h:3419!
      [  643.409773] invalid opcode: 0000 [#1] PREEMPT SMP
      [  643.410447] Modules linked in: dm_flakey dm_mod crc32c_generic btrfs xor raid6_pq ppdev psmouse acpi_cpufreq parport_pc evdev parport tpm_tis tpm_tis_core pcspkr serio_raw i2c_piix4 sg tpm i2c_core button processor loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring scsi_mod virtio e1000 floppy
      [  643.414356] CPU: 11 PID: 32726 Comm: btrfs Not tainted 4.8.0-rc8-btrfs-next-35+ #1
      [  643.414356] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
      [  643.414356] task: ffff880145e95b00 task.stack: ffff88014826c000
      [  643.414356] RIP: 0010:[<ffffffffa0352759>]  [<ffffffffa0352759>] assfail.constprop.41+0x1c/0x1e [btrfs]
      [  643.414356] RSP: 0018:ffff88014826fa28  EFLAGS: 00010292
      [  643.414356] RAX: 0000000000000039 RBX: ffff88014e2d7c38 RCX: 0000000000000001
      [  643.414356] RDX: ffff88023f4d2f58 RSI: ffffffff81806c63 RDI: 00000000ffffffff
      [  643.414356] RBP: ffff88014826fa28 R08: 0000000000000001 R09: 0000000000000000
      [  643.414356] R10: ffff88014826f918 R11: ffffffff82f3c5ed R12: ffff880172910000
      [  643.414356] R13: ffff880233992230 R14: ffff8801a68a3310 R15: fffffffffffffff8
      [  643.414356] FS:  00007f9ca305e8c0(0000) GS:ffff88023f4c0000(0000) knlGS:0000000000000000
      [  643.414356] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  643.414356] CR2: 00007f9ca3071000 CR3: 000000015d01b000 CR4: 00000000000006e0
      [  643.414356] Stack:
      [  643.414356]  ffff88014826fa50 ffffffffa02d655a 000000000000000a ffff88014e2d7c38
      [  643.414356]  0000000000000000 ffff88014826faa8 ffffffffa02b72f3 ffff88014826fab8
      [  643.414356]  00ffffffa03228e4 0000000000000000 0000000000000000 ffff8801bbd4e000
      [  643.414356] Call Trace:
      [  643.414356]  [<ffffffffa02d655a>] btrfs_mark_buffer_dirty+0xdf/0xe5 [btrfs]
      [  643.414356]  [<ffffffffa02b72f3>] btrfs_copy_root+0x18a/0x1d1 [btrfs]
      [  643.414356]  [<ffffffffa0322921>] create_reloc_root+0x72/0x1ba [btrfs]
      [  643.414356]  [<ffffffffa03267c2>] btrfs_init_reloc_root+0x7b/0xa7 [btrfs]
      [  643.414356]  [<ffffffffa02d9e44>] record_root_in_trans+0xdf/0xed [btrfs]
      [  643.414356]  [<ffffffffa02db04e>] btrfs_record_root_in_trans+0x50/0x6a [btrfs]
      [  643.414356]  [<ffffffffa030ad2b>] create_subvol+0x472/0x773 [btrfs]
      [  643.414356]  [<ffffffffa030b406>] btrfs_mksubvol+0x3da/0x463 [btrfs]
      [  643.414356]  [<ffffffffa030b406>] ? btrfs_mksubvol+0x3da/0x463 [btrfs]
      [  643.414356]  [<ffffffff810781ac>] ? preempt_count_add+0x65/0x68
      [  643.414356]  [<ffffffff811a6e97>] ? __mnt_want_write+0x62/0x77
      [  643.414356]  [<ffffffffa030b55d>] btrfs_ioctl_snap_create_transid+0xce/0x187 [btrfs]
      [  643.414356]  [<ffffffffa030b67d>] btrfs_ioctl_snap_create+0x67/0x81 [btrfs]
      [  643.414356]  [<ffffffffa030ecfd>] btrfs_ioctl+0x508/0x20dd [btrfs]
      [  643.414356]  [<ffffffff81293e39>] ? __this_cpu_preempt_check+0x13/0x15
      [  643.414356]  [<ffffffff81155eca>] ? handle_mm_fault+0x976/0x9ab
      [  643.414356]  [<ffffffff81091300>] ? arch_local_irq_save+0x9/0xc
      [  643.414356]  [<ffffffff8119a2b0>] vfs_ioctl+0x18/0x34
      [  643.414356]  [<ffffffff8119a8e8>] do_vfs_ioctl+0x581/0x600
      [  643.414356]  [<ffffffff814b9552>] ? entry_SYSCALL_64_fastpath+0x5/0xa8
      [  643.414356]  [<ffffffff81093fe9>] ? trace_hardirqs_on_caller+0x17b/0x197
      [  643.414356]  [<ffffffff8119a9be>] SyS_ioctl+0x57/0x79
      [  643.414356]  [<ffffffff814b9565>] entry_SYSCALL_64_fastpath+0x18/0xa8
      [  643.414356]  [<ffffffff81091b08>] ? trace_hardirqs_off_caller+0x3f/0xaa
      [  643.414356] Code: 89 83 88 00 00 00 31 c0 5b 41 5c 41 5d 5d c3 55 89 f1 48 c7 c2 98 bc 35 a0 48 89 fe 48 c7 c7 05 be 35 a0 48 89 e5 e8 13 46 dd e0 <0f> 0b 55 89 f1 48 c7 c2 9f d3 35 a0 48 89 fe 48 c7 c7 7a d5 35
      [  643.414356] RIP  [<ffffffffa0352759>] assfail.constprop.41+0x1c/0x1e [btrfs]
      [  643.414356]  RSP <ffff88014826fa28>
      [  643.468267] ---[ end trace 6a1b3fb1a9d7d6e3 ]---
      
      This can be easily reproduced by running xfstests with the integrity
      checker enabled.
      
      Fixes: 1ba98d08 (Btrfs: detect corruption when non-root leaf has zero item)
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1e0e047
    • David Sterba's avatar
      btrfs: store and load values of stripes_min/stripes_max in balance status item · c01ea880
      David Sterba authored
      commit ed0df618 upstream.
      
      The balance status item contains currently known filter values, but the
      stripes filter was unintentionally not among them. This would mean, that
      interrupted and automatically restarted balance does not apply the
      stripe filters.
      
      Fixes: dee32d0aSigned-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c01ea880
    • Filipe Manana's avatar
      Btrfs: fix relocation incorrectly dropping data references · 01f285fe
      Filipe Manana authored
      commit 054570a1 upstream.
      
      During relocation of a data block group we create a relocation tree
      for each fs/subvol tree by making a snapshot of each tree using
      btrfs_copy_root() and the tree's commit root, and then setting the last
      snapshot field for the fs/subvol tree's root to the value of the current
      transaction id minus 1. However this can lead to relocation later
      dropping references that it did not create if we have qgroups enabled,
      leaving the filesystem in an inconsistent state that keeps aborting
      transactions.
      
      Lets consider the following example to explain the problem, which requires
      qgroups to be enabled.
      
      We are relocating data block group Y, we have a subvolume with id 258 that
      has a root at level 1, that subvolume is used to store directory entries
      for snapshots and we are currently at transaction 3404.
      
      When committing transaction 3404, we have a pending snapshot and therefore
      we call btrfs_run_delayed_items() at transaction.c:create_pending_snapshot()
      in order to create its dentry at subvolume 258. This results in COWing
      leaf A from root 258 in order to add the dentry. Note that leaf A
      also contains file extent items referring to extents from some other
      block group X (we are currently relocating block group Y). Later on, still
      at create_pending_snapshot() we call qgroup_account_snapshot(), which
      switches the commit root for root 258 when it calls switch_commit_roots(),
      so now the COWed version of leaf A, lets call it leaf A', is accessible
      from the commit root of tree 258. At the end of qgroup_account_snapshot(),
      we call record_root_in_trans() with 258 as its argument, which results
      in btrfs_init_reloc_root() being called, which in turn calls
      relocation.c:create_reloc_root() in order to create a relocation tree
      associated to root 258, which results in assigning the value of 3403
      (which is the current transaction id minus 1 = 3404 - 1) to the
      last_snapshot field of root 258. When creating the relocation tree root
      at ctree.c:btrfs_copy_root() we add a shared reference for leaf A',
      corresponding to the relocation tree's root, when we call btrfs_inc_ref()
      against the COWed root (a copy of the commit root from tree 258), which
      is at level 1. So at this point leaf A' has 2 references, one normal
      reference corresponding to root 258 and one shared reference corresponding
      to the root of the relocation tree.
      
      Transaction 3404 finishes its commit and transaction 3405 is started by
      relocation when calling merge_reloc_root() for the relocation tree
      associated to root 258. In the meanwhile leaf A' is COWed again, in
      response to some filesystem operation, when we are still at transaction
      3405. However when we COW leaf A', at ctree.c:update_ref_for_cow(), we
      call btrfs_block_can_be_shared() in order to figure out if other trees
      refer to the leaf and if any such trees exists, add a full back reference
      to leaf A' - but btrfs_block_can_be_shared() incorrectly returns false
      because the following condition is false:
      
        btrfs_header_generation(buf) <= btrfs_root_last_snapshot(&root->root_item)
      
      which evaluates to 3404 <= 3403. So after leaf A' is COWed, it stays with
      only one reference, corresponding to the shared reference we created when
      we called btrfs_copy_root() to create the relocation tree's root and
      btrfs_inc_ref() ends up not being called for leaf A' nor we end up setting
      the flag BTRFS_BLOCK_FLAG_FULL_BACKREF in leaf A'. This results in not
      adding shared references for the extents from block group X that leaf A'
      refers to with its file extent items.
      
      Later, after merging the relocation root we do a call to to
      btrfs_drop_snapshot() in order to delete the relocation tree. This ends
      up calling do_walk_down() when path->slots[1] points to leaf A', which
      results in calling btrfs_lookup_extent_info() to get the number of
      references for leaf A', which is 1 at this time (only the shared reference
      exists) and this value is stored at wc->refs[0]. After this walk_up_proc()
      is called when wc->level is 0 and path->nodes[0] corresponds to leaf A'.
      Because the current level is 0 and wc->refs[0] is 1, it does call
      btrfs_dec_ref() against leaf A', which results in removing the single
      references that the extents from block group X have which are associated
      to root 258 - the expectation was to have each of these extents with 2
      references - one reference for root 258 and one shared reference related
      to the root of the relocation tree, and so we would drop only the shared
      reference (because leaf A' was supposed to have the flag
      BTRFS_BLOCK_FLAG_FULL_BACKREF set).
      
      This leaves the filesystem in an inconsistent state as we now have file
      extent items in a subvolume tree that point to extents from block group X
      without references in the extent tree. So later on when we try to decrement
      the references for these extents, for example due to a file unlink operation,
      truncate operation or overwriting ranges of a file, we fail because the
      expected references do not exist in the extent tree.
      
      This leads to warnings and transaction aborts like the following:
      
      [  588.965795] ------------[ cut here ]------------
      [  588.965815] WARNING: CPU: 2 PID: 2479 at fs/btrfs/extent-tree.c:1625 lookup_inline_extent_backref+0x432/0x5b0 [btrfs]
      [  588.965816] Modules linked in: af_packet iscsi_ibft iscsi_boot_sysfs xfs libcrc32c ppdev acpi_cpufreq button tpm_tis e1000 i2c_piix4 pcspkr parport_pc
      parport tpm qemu_fw_cfg joydev btrfs xor raid6_pq sr_mod cdrom ata_generic virtio_scsi ata_piix virtio_pci bochs_drm virtio_ring drm_kms_helper syscopyarea
      sysfillrect sysimgblt fb_sys_fops virtio ttm serio_raw drm floppy sg
      [  588.965831] CPU: 2 PID: 2479 Comm: kworker/u8:7 Not tainted 4.7.3-3-default-fdm+ #1
      [  588.965832] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
      [  588.965844] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
      [  588.965845]  0000000000000000 ffff8802263bfa28 ffffffff813af542 0000000000000000
      [  588.965847]  0000000000000000 ffff8802263bfa68 ffffffff81081e8b 0000065900000000
      [  588.965848]  ffff8801db2af000 000000012bbe2000 0000000000000000 ffff880215703b48
      [  588.965849] Call Trace:
      [  588.965852]  [<ffffffff813af542>] dump_stack+0x63/0x81
      [  588.965854]  [<ffffffff81081e8b>] __warn+0xcb/0xf0
      [  588.965855]  [<ffffffff81081f7d>] warn_slowpath_null+0x1d/0x20
      [  588.965863]  [<ffffffffa0175042>] lookup_inline_extent_backref+0x432/0x5b0 [btrfs]
      [  588.965865]  [<ffffffff81143220>] ? trace_clock_local+0x10/0x30
      [  588.965867]  [<ffffffff8114c5df>] ? rb_reserve_next_event+0x6f/0x460
      [  588.965875]  [<ffffffffa0175215>] insert_inline_extent_backref+0x55/0xd0 [btrfs]
      [  588.965882]  [<ffffffffa017531f>] __btrfs_inc_extent_ref.isra.55+0x8f/0x240 [btrfs]
      [  588.965890]  [<ffffffffa017acea>] __btrfs_run_delayed_refs+0x74a/0x1260 [btrfs]
      [  588.965892]  [<ffffffff810cb046>] ? cpuacct_charge+0x86/0xa0
      [  588.965900]  [<ffffffffa017e74f>] btrfs_run_delayed_refs+0x9f/0x2c0 [btrfs]
      [  588.965908]  [<ffffffffa017ea04>] delayed_ref_async_start+0x94/0xb0 [btrfs]
      [  588.965918]  [<ffffffffa01c799a>] btrfs_scrubparity_helper+0xca/0x350 [btrfs]
      [  588.965928]  [<ffffffffa01c7c5e>] btrfs_extent_refs_helper+0xe/0x10 [btrfs]
      [  588.965930]  [<ffffffff8109b323>] process_one_work+0x1f3/0x4e0
      [  588.965931]  [<ffffffff8109b658>] worker_thread+0x48/0x4e0
      [  588.965932]  [<ffffffff8109b610>] ? process_one_work+0x4e0/0x4e0
      [  588.965934]  [<ffffffff810a1659>] kthread+0xc9/0xe0
      [  588.965936]  [<ffffffff816f2f1f>] ret_from_fork+0x1f/0x40
      [  588.965937]  [<ffffffff810a1590>] ? kthread_worker_fn+0x170/0x170
      [  588.965938] ---[ end trace 34e5232c933a1749 ]---
      [  588.966187] ------------[ cut here ]------------
      [  588.966196] WARNING: CPU: 2 PID: 2479 at fs/btrfs/extent-tree.c:2966 btrfs_run_delayed_refs+0x28c/0x2c0 [btrfs]
      [  588.966196] BTRFS: Transaction aborted (error -5)
      [  588.966197] Modules linked in: af_packet iscsi_ibft iscsi_boot_sysfs xfs libcrc32c ppdev acpi_cpufreq button tpm_tis e1000 i2c_piix4 pcspkr parport_pc
      parport tpm qemu_fw_cfg joydev btrfs xor raid6_pq sr_mod cdrom ata_generic virtio_scsi ata_piix virtio_pci bochs_drm virtio_ring drm_kms_helper syscopyarea
      sysfillrect sysimgblt fb_sys_fops virtio ttm serio_raw drm floppy sg
      [  588.966206] CPU: 2 PID: 2479 Comm: kworker/u8:7 Tainted: G        W       4.7.3-3-default-fdm+ #1
      [  588.966207] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
      [  588.966217] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
      [  588.966217]  0000000000000000 ffff8802263bfc98 ffffffff813af542 ffff8802263bfce8
      [  588.966219]  0000000000000000 ffff8802263bfcd8 ffffffff81081e8b 00000b96345ee000
      [  588.966220]  ffffffffa021ae1c ffff880215703b48 00000000000005fe ffff8802345ee000
      [  588.966221] Call Trace:
      [  588.966223]  [<ffffffff813af542>] dump_stack+0x63/0x81
      [  588.966224]  [<ffffffff81081e8b>] __warn+0xcb/0xf0
      [  588.966225]  [<ffffffff81081eff>] warn_slowpath_fmt+0x4f/0x60
      [  588.966233]  [<ffffffffa017e93c>] btrfs_run_delayed_refs+0x28c/0x2c0 [btrfs]
      [  588.966241]  [<ffffffffa017ea04>] delayed_ref_async_start+0x94/0xb0 [btrfs]
      [  588.966250]  [<ffffffffa01c799a>] btrfs_scrubparity_helper+0xca/0x350 [btrfs]
      [  588.966259]  [<ffffffffa01c7c5e>] btrfs_extent_refs_helper+0xe/0x10 [btrfs]
      [  588.966260]  [<ffffffff8109b323>] process_one_work+0x1f3/0x4e0
      [  588.966261]  [<ffffffff8109b658>] worker_thread+0x48/0x4e0
      [  588.966263]  [<ffffffff8109b610>] ? process_one_work+0x4e0/0x4e0
      [  588.966264]  [<ffffffff810a1659>] kthread+0xc9/0xe0
      [  588.966265]  [<ffffffff816f2f1f>] ret_from_fork+0x1f/0x40
      [  588.966267]  [<ffffffff810a1590>] ? kthread_worker_fn+0x170/0x170
      [  588.966268] ---[ end trace 34e5232c933a174a ]---
      [  588.966269] BTRFS: error (device sda2) in btrfs_run_delayed_refs:2966: errno=-5 IO failure
      [  588.966270] BTRFS info (device sda2): forced readonly
      
      This was happening often on openSUSE and SLE systems using btrfs as the
      root filesystem (with its default layout where multiple subvolumes are
      used) where balance happens in the background triggered by a cron job and
      snapshots are automatically created before/after package installations,
      upgrades and removals. The issue could be triggered simply by running the
      following loop on the first system boot post installation:
      
        while true; do
           zypper -n in nfs-kernel-server
           zypper -n rm nfs-kernel-server
        done
      
      (If we were fast enough and made that loop before the cron job triggered
      a balance operation and the balance finished)
      
      So fix by setting the last_snapshot field of the root to the value of the
      generation of its commit root. Like this btrfs_block_can_be_shared()
      behaves correctly for the case where the relocation root is created during
      a transaction commit and for the case where it's created before a
      transaction commit.
      
      Fixes: 6426c7ad (btrfs: qgroup: Fix qgroup accounting when creating snapshot)
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01f285fe