1. 16 Feb, 2017 8 commits
  2. 15 Feb, 2017 22 commits
  3. 06 Feb, 2017 1 commit
  4. 30 Jan, 2017 2 commits
  5. 27 Jan, 2017 7 commits
    • Jiri Slaby's avatar
      Linux 3.12.70 · d7f41d3b
      Jiri Slaby authored
      d7f41d3b
    • Gu Zheng's avatar
      tmpfs: clear S_ISGID when setting posix ACLs · b0369e53
      Gu Zheng authored
      commit 497de07d upstream.
      
      This change was missed the tmpfs modification in In CVE-2016-7097
      commit 07393101 ("posix_acl: Clear SGID bit when setting
      file permissions")
      It can test by xfstest generic/375, which failed to clear
      setgid bit in the following test case on tmpfs:
      
        touch $testfile
        chown 100:100 $testfile
        chmod 2755 $testfile
        _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile
      Signed-off-by: default avatarGu Zheng <guzheng1@huawei.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b0369e53
    • Tariq Saeed's avatar
      ocfs2: fix BUG_ON() in ocfs2_ci_checkpointed() · ded56d6d
      Tariq Saeed authored
      commit 3d46a44a upstream.
      
      PID: 614    TASK: ffff882a739da580  CPU: 3   COMMAND: "ocfs2dc"
        #0 [ffff882ecc3759b0] machine_kexec at ffffffff8103b35d
        #1 [ffff882ecc375a20] crash_kexec at ffffffff810b95b5
        #2 [ffff882ecc375af0] oops_end at ffffffff815091d8
        #3 [ffff882ecc375b20] die at ffffffff8101868b
        #4 [ffff882ecc375b50] do_trap at ffffffff81508bb0
        #5 [ffff882ecc375ba0] do_invalid_op at ffffffff810165e5
        #6 [ffff882ecc375c40] invalid_op at ffffffff815116fb
           [exception RIP: ocfs2_ci_checkpointed+208]
           RIP: ffffffffa0a7e940  RSP: ffff882ecc375cf0  RFLAGS: 00010002
           RAX: 0000000000000001  RBX: 000000000000654b  RCX: ffff8812dc83f1f8
           RDX: 00000000000017d9  RSI: ffff8812dc83f1f8  RDI: ffffffffa0b2c318
           RBP: ffff882ecc375d20   R8: ffff882ef6ecfa60   R9: ffff88301f272200
           R10: 0000000000000000  R11: 0000000000000000  R12: ffffffffffffffff
           R13: ffff8812dc83f4f0  R14: 0000000000000000  R15: ffff8812dc83f1f8
           ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
        #7 [ffff882ecc375d28] ocfs2_check_meta_downconvert at ffffffffa0a7edbd [ocfs2]
        #8 [ffff882ecc375d38] ocfs2_unblock_lock at ffffffffa0a84af8 [ocfs2]
        #9 [ffff882ecc375dc8] ocfs2_process_blocked_lock at ffffffffa0a85285 [ocfs2]
      assert is tripped because the tran is not checkpointed and the lock level is PR.
      
      Some time ago, chmod command had been executed. As result, the following call
      chain left the inode cluster lock in PR state, latter on causing the assert.
      system_call_fastpath
        -> my_chmod
         -> sys_chmod
          -> sys_fchmodat
           -> notify_change
            -> ocfs2_setattr
             -> posix_acl_chmod
              -> ocfs2_iop_set_acl
               -> ocfs2_set_acl
                -> ocfs2_acl_set_mode
      Here is how.
      1119 int ocfs2_setattr(struct dentry *dentry, struct iattr *attr)
      1120 {
      1247         ocfs2_inode_unlock(inode, 1); <<< WRONG thing to do.
      ..
      1258         if (!status && attr->ia_valid & ATTR_MODE) {
      1259                 status =  posix_acl_chmod(inode, inode->i_mode);
      
      519 posix_acl_chmod(struct inode *inode, umode_t mode)
      520 {
      ..
      539         ret = inode->i_op->set_acl(inode, acl, ACL_TYPE_ACCESS);
      
      287 int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, ...
      288 {
      289         return ocfs2_set_acl(NULL, inode, NULL, type, acl, NULL, NULL);
      
      224 int ocfs2_set_acl(handle_t *handle,
      225                          struct inode *inode, ...
      231 {
      ..
      252                                 ret = ocfs2_acl_set_mode(inode, di_bh,
      253                                                          handle, mode);
      
      168 static int ocfs2_acl_set_mode(struct inode *inode, struct buffer_head ...
      170 {
      183         if (handle == NULL) {
                          >>> BUG: inode lock not held in ex at this point <<<
      184                 handle = ocfs2_start_trans(OCFS2_SB(inode->i_sb),
      185                                            OCFS2_INODE_UPDATE_CREDITS);
      
      ocfs2_setattr.#1247 we unlock and at #1259 call posix_acl_chmod. When we reach
      ocfs2_acl_set_mode.#181 and do trans, the inode cluster lock is not held in EX
      mode (it should be). How this could have happended?
      
      We are the lock master, were holding lock EX and have released it in
      ocfs2_setattr.#1247.  Note that there are no holders of this lock at
      this point.  Another node needs the lock in PR, and we downconvert from
      EX to PR.  So the inode lock is PR when do the trans in
      ocfs2_acl_set_mode.#184.  The trans stays in core (not flushed to disc).
      Now another node want the lock in EX, downconvert thread gets kicked
      (the one that tripped assert abovt), finds an unflushed trans but the
      lock is not EX (it is PR).  If the lock was at EX, it would have flushed
      the trans ocfs2_ci_checkpointed -> ocfs2_start_checkpoint before
      downconverting (to NULL) for the request.
      
      ocfs2_setattr must not drop inode lock ex in this code path.  If it
      does, takes it again before the trans, say in ocfs2_set_acl, another
      cluster node can get in between, execute another setattr, overwriting
      the one in progress on this node, resulting in a mode acl size combo
      that is a mix of the two.
      
      Orabug: 20189959
      Signed-off-by: default avatarTariq Saeed <tariq.x.saeed@oracle.com>
      Reviewed-by: default avatarMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ded56d6d
    • Mintz, Yuval's avatar
      bnx2x: Correct ringparam estimate when DOWN · 05dc5c8f
      Mintz, Yuval authored
      commit 65870fa7 upstream.
      
      Until interface is up [and assuming ringparams weren't explicitly
      configured] when queried for the size of its rings bnx2x would
      claim they're the maximal size by default.
      That is incorrect as by default the maximal number of buffers would
      be equally divided between the various rx rings.
      
      This prevents the user from actually setting the number of elements
      on each rx ring to be of maximal size prior to transitioning the
      interface into up state.
      
      To fix this, make a rough estimation about the number of buffers.
      It wouldn't always be accurate, but it would be much better than
      current estimation and would allow users to increase number of
      buffers during early initialization of the interface.
      Reported-by: default avatarSeymour, Shane <shane.seymour@hpe.com>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      05dc5c8f
    • Gabriel Krisman Bertazi's avatar
      serial: 8250_pci: Detach low-level driver during PCI error recovery · b6580bd9
      Gabriel Krisman Bertazi authored
      commit f209fa03 upstream.
      
      During a PCI error recovery, like the ones provoked by EEH in the ppc64
      platform, all IO to the device must be blocked while the recovery is
      completed.  Current 8250_pci implementation only suspends the port
      instead of detaching it, which doesn't prevent incoming accesses like
      TIOCMGET and TIOCMSET calls from reaching the device.  Those end up
      racing with the EEH recovery, crashing it.  Similar races were also
      observed when opening the device and when shutting it down during
      recovery.
      
      This patch implements a more robust IO blockage for the 8250_pci
      recovery by unregistering the port at the beginning of the procedure and
      re-adding it afterwards.  Since the port is detached from the uart
      layer, we can be sure that no request will make through to the device
      during recovery.  This is similar to the solution used by the JSM serial
      driver.
      
      I thank Peter Hurley <peter@hurleysoftware.com> for valuable input on
      this one over one year ago.
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b6580bd9
    • Wanpeng Li's avatar
      x86/apic: Order irq_enter/exit() calls correctly vs. ack_APIC_irq() · a2b17a74
      Wanpeng Li authored
      commit b0f48706 upstream.
      
      ===============================
      [ INFO: suspicious RCU usage. ]
      4.8.0-rc6+ #5 Not tainted
      -------------------------------
      ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      RCU used illegally from idle CPU!
      rcu_scheduler_active = 1, debug_locks = 0
      RCU used illegally from extended quiescent state!
      no locks held by swapper/2/0.
      
      stack backtrace:
      CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.8.0-rc6+ #5
      Hardware name: Dell Inc. OptiPlex 7020/0F5C5X, BIOS A03 01/08/2015
       0000000000000000 ffff8d1bd6003f10 ffffffff94446949 ffff8d1bd4a68000
       0000000000000001 ffff8d1bd6003f40 ffffffff940e9247 ffff8d1bbdfcf3d0
       000000000000080b 0000000000000000 0000000000000000 ffff8d1bd6003f70
      Call Trace:
       <IRQ>  [<ffffffff94446949>] dump_stack+0x99/0xd0
       [<ffffffff940e9247>] lockdep_rcu_suspicious+0xe7/0x120
       [<ffffffff9448e0d5>] do_trace_write_msr+0x135/0x140
       [<ffffffff9406e750>] native_write_msr+0x20/0x30
       [<ffffffff9406503d>] native_apic_msr_eoi_write+0x1d/0x30
       [<ffffffff9405b17e>] smp_trace_call_function_interrupt+0x1e/0x270
       [<ffffffff948cb1d6>] trace_call_function_interrupt+0x96/0xa0
       <EOI>  [<ffffffff947200f4>] ? cpuidle_enter_state+0xe4/0x360
       [<ffffffff947200df>] ? cpuidle_enter_state+0xcf/0x360
       [<ffffffff947203a7>] cpuidle_enter+0x17/0x20
       [<ffffffff940df008>] cpu_startup_entry+0x338/0x4d0
       [<ffffffff9405bfc4>] start_secondary+0x154/0x180
      
      This can be reproduced readily by running ftrace test case of kselftest.
      
      Move the irq_enter() call before ack_APIC_irq(), because irq_enter() tells
      the RCU susbstems to end the extended quiescent state, so that the
      following trace call in ack_APIC_irq() works correctly. The same applies to
      exiting_ack_irq() which calls ack_APIC_irq() after irq_exit().
      
      [ tglx: Massaged changelog ]
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Wanpeng Li <wanpeng.li@hotmail.com>
      Link: http://lkml.kernel.org/r/1474198491-3738-1-git-send-email-wanpeng.li@hotmail.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a2b17a74
    • Al Viro's avatar
      move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon) · 75e8aab4
      Al Viro authored
      commit 6f18493e upstream.
      
      and lock the right list there
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      75e8aab4