1. 13 10月, 2016 10 次提交
  2. 08 10月, 2016 1 次提交
  3. 28 9月, 2016 4 次提交
  4. 27 9月, 2016 1 次提交
  5. 22 9月, 2016 1 次提交
  6. 16 9月, 2016 1 次提交
  7. 10 9月, 2016 3 次提交
  8. 01 8月, 2016 1 次提交
  9. 30 7月, 2016 1 次提交
  10. 28 7月, 2016 2 次提交
  11. 27 7月, 2016 1 次提交
    • M
      mm, memcg: use consistent gfp flags during readahead · 8a5c743e
      Michal Hocko 提交于
      Vladimir has noticed that we might declare memcg oom even during
      readahead because read_pages only uses GFP_KERNEL (with mapping_gfp
      restriction) while __do_page_cache_readahead uses
      page_cache_alloc_readahead which adds __GFP_NORETRY to prevent from
      OOMs.  This gfp mask discrepancy is really unfortunate and easily
      fixable.  Drop page_cache_alloc_readahead() which only has one user and
      outsource the gfp_mask logic into readahead_gfp_mask and propagate this
      mask from __do_page_cache_readahead down to read_pages.
      
      This alone would have only very limited impact as most filesystems are
      implementing ->readpages and the common implementation mpage_readpages
      does GFP_KERNEL (with mapping_gfp restriction) again.  We can tell it to
      use readahead_gfp_mask instead as this function is called only during
      readahead as well.  The same applies to read_cache_pages.
      
      ext4 has its own ext4_mpage_readpages but the path which has pages !=
      NULL can use the same gfp mask.  Btrfs, cifs, f2fs and orangefs are
      doing a very similar pattern to mpage_readpages so the same can be
      applied to them as well.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [mhocko@suse.com: restrict gfp mask in mpage_alloc]
        Link: http://lkml.kernel.org/r/20160610074223.GC32285@dhcp22.suse.cz
      Link: http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Cc: Vladimir Davydov <vdavydov@parallels.com>
      Cc: Chris Mason <clm@fb.com>
      Cc: Steve French <sfrench@samba.org>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Mike Marshall <hubcap@omnibond.com>
      Cc: Jaegeuk Kim <jaegeuk@kernel.org>
      Cc: Changman Lee <cm224.lee@samsung.com>
      Cc: Chao Yu <yuchao0@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a5c743e
  12. 20 7月, 2016 2 次提交
    • R
      cifs: fix crash due to race in hmac(md5) handling · bd975d1e
      Rabin Vincent 提交于
      The secmech hmac(md5) structures are present in the TCP_Server_Info
      struct and can be shared among multiple CIFS sessions.  However, the
      server mutex is not currently held when these structures are allocated
      and used, which can lead to a kernel crashes, as in the scenario below:
      
      mount.cifs(8) #1				mount.cifs(8) #2
      
      Is secmech.sdeschmaccmd5 allocated?
      // false
      
      						Is secmech.sdeschmaccmd5 allocated?
      						// false
      
      secmech.hmacmd = crypto_alloc_shash..
      secmech.sdeschmaccmd5 = kzalloc..
      sdeschmaccmd5->shash.tfm = &secmec.hmacmd;
      
      						secmech.sdeschmaccmd5 = kzalloc
      						// sdeschmaccmd5->shash.tfm
      						// not yet assigned
      
      crypto_shash_update()
       deref NULL sdeschmaccmd5->shash.tfm
      
       Unable to handle kernel paging request at virtual address 00000030
       epc   : 8027ba34 crypto_shash_update+0x38/0x158
       ra    : 8020f2e8 setup_ntlmv2_rsp+0x4bc/0xa84
       Call Trace:
        crypto_shash_update+0x38/0x158
        setup_ntlmv2_rsp+0x4bc/0xa84
        build_ntlmssp_auth_blob+0xbc/0x34c
        sess_auth_rawntlmssp_authenticate+0xac/0x248
        CIFS_SessSetup+0xf0/0x178
        cifs_setup_session+0x4c/0x84
        cifs_get_smb_ses+0x2c8/0x314
        cifs_mount+0x38c/0x76c
        cifs_do_mount+0x98/0x440
        mount_fs+0x20/0xc0
        vfs_kern_mount+0x58/0x138
        do_mount+0x1e8/0xccc
        SyS_mount+0x88/0xd4
        syscall_common+0x30/0x54
      
      Fix this by locking the srv_mutex around the code which uses these
      hmac(md5) structures.  All the other secmech algos already have similar
      locking.
      
      Fixes: 95dc8dd1 ("Limit allocation of crypto mechanisms to dialect which requires")
      Signed-off-by: NRabin Vincent <rabinv@axis.com>
      Acked-by: NSachin Prabhu <sprabhu@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      bd975d1e
    • R
      cifs: unbreak TCP session reuse · b782fcc1
      Rabin Vincent 提交于
      adfeb3e0 ("cifs: Make echo interval tunable") added a comparison of
      vol->echo_interval to server->echo_interval as a criterium to
      match_server(), but:
      
       (1) A default value is set for server->echo_interval but not for
       vol->echo_interval, meaning these can never match if the echo_interval
       option is not specified.
      
       (2) vol->echo_interval is in seconds but server->echo_interval is in
       jiffies, meaning these can never match even if the echo_interval option
       is specified.
      
      This broke TCP session reuse since match_server() can never return 1.
      Fix it.
      
      Fixes: adfeb3e0 ("cifs: Make echo interval tunable")
      Signed-off-by: NRabin Vincent <rabinv@axis.com>
      Acked-by: NSachin Prabhu <sprabhu@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      b782fcc1
  13. 13 7月, 2016 1 次提交
  14. 12 7月, 2016 1 次提交
  15. 06 7月, 2016 1 次提交
  16. 25 6月, 2016 2 次提交
  17. 24 6月, 2016 4 次提交
  18. 11 6月, 2016 1 次提交
    • L
      vfs: make the string hashes salt the hash · 8387ff25
      Linus Torvalds 提交于
      We always mixed in the parent pointer into the dentry name hash, but we
      did it late at lookup time.  It turns out that we can simplify that
      lookup-time action by salting the hash with the parent pointer early
      instead of late.
      
      A few other users of our string hashes also wanted to mix in their own
      pointers into the hash, and those are updated to use the same mechanism.
      
      Hash users that don't have any particular initial salt can just use the
      NULL pointer as a no-salt.
      
      Cc: Vegard Nossum <vegard.nossum@oracle.com>
      Cc: George Spelvin <linux@sciencehorizons.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8387ff25
  19. 30 5月, 2016 1 次提交
  20. 28 5月, 2016 1 次提交