1. 21 7月, 2017 2 次提交
    • C
      gfs2: add flag REQ_PRIO for metadata I/O · e477b24b
      Coly Li 提交于
      When gfs2 does metadata I/O, only REQ_META is used as a metadata hint of
      the bio. But flag REQ_META is just a hint for block trace, not for block
      layer code to handle a bio as metadata request.
      
      For some of metadata I/Os of gfs2, A REQ_PRIO flag on the metadata bio
      would be very informative to block layer code. For example, if bcache is
      used as a I/O cache for gfs2, it will be possible for bcache code to get
      the hint and cache the pre-fetched metadata blocks on cache device. This
      behavior may be helpful to improve metadata I/O performance if the
      following requests hit the cache.
      
      Here are the locations in gfs2 code where a REQ_PRIO flag should be added,
      - All places where REQ_READAHEAD is used, gfs2 code uses this flag for
        metadata read ahead.
      - In gfs2_meta_rq() where the first metadata block is read in.
      - In gfs2_write_buf_to_page(), read in quota metadata blocks to have them
        up to date.
      These metadata blocks are probably to be accessed again in future, adding
      a REQ_PRIO flag may have bcache to keep such metadata in fast cache
      device. For system without a cache layer, REQ_PRIO can still provide hint
      to block layer to handle metadata requests more properly.
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      e477b24b
    • W
      GFS2: fix code parameter error in inode_go_lock · e7cb550d
      Wang Xibo 提交于
      In inode_go_lock() function, the parameter order of list_add() is error.
      According to the define of list_add(), the first parameter is new entry
      and the second is the list head, so ip->i_trunc_list should be the
      first parameter and the sdp->sd_trunc_list should be second.
      
      Signed-off-by: Wang Xibo<wang.xibo@zte.com.cn>
      Signed-off-by: Xiao Likun<xiao.likun@zte.com.cn>
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      e7cb550d
  2. 20 7月, 2017 1 次提交
  3. 19 7月, 2017 1 次提交
    • J
      gfs2: Don't clear SGID when inheriting ACLs · 914cea93
      Jan Kara 提交于
      When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
      set, DIR1 is expected to have SGID bit set (and owning group equal to
      the owning group of 'DIR0'). However when 'DIR0' also has some default
      ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
      'DIR1' to get cleared if user is not member of the owning group.
      
      Fix the problem by moving posix_acl_update_mode() out of
      __gfs2_set_acl() into gfs2_set_acl(). That way the function will not be
      called when inheriting ACLs which is what we want as it prevents SGID
      bit clearing and the mode has been properly set by posix_acl_create()
      anyway.
      
      Fixes: 07393101Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      914cea93
  4. 18 7月, 2017 1 次提交
  5. 17 7月, 2017 1 次提交
    • B
      GFS2: Prevent double brelse in gfs2_meta_indirect_buffer · 61eaadcd
      Bob Peterson 提交于
      Before this patch, problems reading in indirect buffers would send
      an IO error back to the caller, and release the buffer_head with
      brelse() in function gfs2_meta_indirect_buffer, however, it would
      still return the address of the buffer_head it released. After the
      error was discovered, function gfs2_block_map would call function
      release_metapath to free all buffers. That checked:
      if (mp->mp_bh[i] == NULL) but since the value was set after the
      error, it was non-zero, so brelse was called a second time. This
      resulted in the following error:
      
      kernel: WARNING: at fs/buffer.c:1224 __brelse+0x3a/0x40() (Tainted: G        W  -- ------------   )
      kernel: Hardware name: RHEV Hypervisor
      kernel: VFS: brelse: Trying to free free buffer
      
      This patch changes gfs2_meta_indirect_buffer so it only sets
      the buffer_head pointer in cases where it isn't released.
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      Acked-by: NSteven Whitehouse <swhiteho@redhat.com>
      61eaadcd
  6. 08 7月, 2017 3 次提交
    • K
      exec: Limit arg stack to at most 75% of _STK_LIM · da029c11
      Kees Cook 提交于
      To avoid pathological stack usage or the need to special-case setuid
      execs, just limit all arg stack usage to at most 75% of _STK_LIM (6MB).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da029c11
    • L
      vfs: fix flock compat thinko · b59eea55
      Linus Torvalds 提交于
      Michael Ellerman reported that commit 8c6657cb ("Switch flock
      copyin/copyout primitives to copy_{from,to}_user()") broke his
      networking on a bunch of PPC machines (64-bit kernel, 32-bit userspace).
      
      The reason is a brown-paper bug by that commit, which had the arguments
      to "copy_flock_fields()" in the wrong order, breaking the compat
      handling for file locking.  Apparently very few people run 32-bit user
      space on x86 any more, so the PPC people got the honor of noticing this
      "feature".
      
      Michael also sent a minimal diff that just changed the order of the
      arguments in that macro.
      
      This is not that minimal diff.
      
      This not only changes the order of the arguments in the macro, it also
      changes them to be pointers (to be consistent with all the other uses of
      those pointers), and makes the functions that do all of this also have
      the proper "const" attribution on the source pointers in order to make
      issues like that (using the source as a destination) be really obvious.
      Reported-by: NMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b59eea55
    • A
      gfs2: Fix glock rhashtable rcu bug · 961ae1d8
      Andreas Gruenbacher 提交于
      Before commit 88ffbf3e "GFS2: Use resizable hash table for glocks",
      glocks were freed via call_rcu to allow reading the glock hashtable
      locklessly using rcu.  This was then changed to free glocks immediately,
      which made reading the glock hashtable unsafe.  Bring back the original
      code for freeing glocks via call_rcu.
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      Cc: stable@vger.kernel.org # 4.3+
      961ae1d8
  7. 07 7月, 2017 9 次提交
  8. 06 7月, 2017 22 次提交