1. 01 Apr, 2017 1 commit
  2. 09 Mar, 2017 1 commit
  3. 07 Mar, 2017 1 commit
    • Matthew Wilcox's avatar
      ida: Free correct IDA bitmap · 4ecd9542
      Matthew Wilcox authored
      There's a relatively rare race where we look at the per-cpu preallocated
      IDA bitmap, see it's NULL, allocate a new one, and atomically update it.
      If the kmalloc() happened to sleep and we were rescheduled to a different
      CPU, or an interrupt came in at the exact right time, another task
      might have successfully allocated a bitmap and already deposited it.
      I forgot what the semantics of cmpxchg() were and ended up freeing the
      wrong bitmap leading to KASAN reporting a use-after-free.
      
      Dmitry found the bug with syzkaller & wrote the patch.  I wrote the test
      case that will reproduce the bug without his patch being applied.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarMatthew Wilcox <mawilcox@microsoft.com>
      4ecd9542
  4. 02 Mar, 2017 12 commits
  5. 01 Mar, 2017 2 commits
    • David Howells's avatar
      KEYS: Differentiate uses of rcu_dereference_key() and user_key_payload() · 0837e49a
      David Howells authored
      rcu_dereference_key() and user_key_payload() are currently being used in
      two different, incompatible ways:
      
       (1) As a wrapper to rcu_dereference() - when only the RCU read lock used
           to protect the key.
      
       (2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
           used to protect the key and the may be being modified.
      
      Fix this by splitting both of the key wrappers to produce:
      
       (1) RCU accessors for keys when caller has the key semaphore locked:
      
      	dereference_key_locked()
      	user_key_payload_locked()
      
       (2) RCU accessors for keys when caller holds the RCU read lock:
      
      	dereference_key_rcu()
      	user_key_payload_rcu()
      
      This should fix following warning in the NFS idmapper
      
        ===============================
        [ INFO: suspicious RCU usage. ]
        4.10.0 #1 Tainted: G        W
        -------------------------------
        ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
        other info that might help us debug this:
        rcu_scheduler_active = 2, debug_locks = 0
        1 lock held by mount.nfs/5987:
          #0:  (rcu_read_lock){......}, at: [<d000000002527abc>] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
        stack backtrace:
        CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G        W       4.10.0 #1
        Call Trace:
          dump_stack+0xe8/0x154 (unreliable)
          lockdep_rcu_suspicious+0x140/0x190
          nfs_idmap_get_key+0x380/0x420 [nfsv4]
          nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
          decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
          decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
          nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
          rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
          call_decode+0x29c/0x910 [sunrpc]
          __rpc_execute+0x140/0x8f0 [sunrpc]
          rpc_run_task+0x170/0x200 [sunrpc]
          nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
          _nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
          nfs4_lookup_root+0xe0/0x350 [nfsv4]
          nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
          nfs4_find_root_sec+0xc4/0x100 [nfsv4]
          nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
          nfs4_get_rootfh+0x6c/0x190 [nfsv4]
          nfs4_server_common_setup+0xc4/0x260 [nfsv4]
          nfs4_create_server+0x278/0x3c0 [nfsv4]
          nfs4_remote_mount+0x50/0xb0 [nfsv4]
          mount_fs+0x74/0x210
          vfs_kern_mount+0x78/0x220
          nfs_do_root_mount+0xb0/0x140 [nfsv4]
          nfs4_try_mount+0x60/0x100 [nfsv4]
          nfs_fs_mount+0x5ec/0xda0 [nfs]
          mount_fs+0x74/0x210
          vfs_kern_mount+0x78/0x220
          do_mount+0x254/0xf70
          SyS_mount+0x94/0x100
          system_call+0x38/0xe0
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      0837e49a
    • Ingo Molnar's avatar
      locking/refcounts: Change WARN() to WARN_ONCE() · 9dcfe2c7
      Ingo Molnar authored
      Linus noticed that the new refcount.h APIs used WARN(), which would turn
      into a dmesg DoS if it triggers frequently on some buggy driver.
      
      So make sure we only warn once. These warnings are never supposed to happen,
      so it's typically not a problem to lose subsequent warnings.
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Elena Reshetova <elena.reshetova@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/CA+55aFzbYUTZ=oqZ2YgDjY0C2_n6ODhTfqj6V+m5xWmDxsuB0w@mail.gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      9dcfe2c7
  6. 28 Feb, 2017 4 commits
  7. 27 Feb, 2017 3 commits
  8. 26 Feb, 2017 1 commit
  9. 25 Feb, 2017 12 commits
  10. 24 Feb, 2017 2 commits
  11. 23 Feb, 2017 1 commit