Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 4月, 2021 17 次提交
  3. 25 3月, 2021 1 次提交
  5. 24 3月, 2021 2 次提交
  7. 21 3月, 2021 10 次提交
  9. 20 3月, 2021 1 次提交
    • S
      cifs: fix allocation size on newly created files · 65af8f01
      由 Steve French 提交于 
      Applications that create and extend and write to a file do not
expect to see 0 allocation size.  When file is extended,
set its allocation size to a plausible value until we have a
chance to query the server for it.  When the file is cached
this will prevent showing an impossible number of allocated
blocks (like 0).  This fixes e.g. xfstests 614 which does

    1) create a file and set its size to 64K
    2) mmap write 64K to the file
    3) stat -c %b for the file (to query the number of allocated blocks)

It was failing because we returned 0 blocks.  Even though we would
return the correct cached file size, we returned an impossible
allocation size.
Signed-off-by: NSteve French <stfrench@microsoft.com>
CC: <stable@vger.kernel.org>
Reviewed-by: NAurelien Aptel <aaptel@suse.com>
      65af8f01
  11. 19 3月, 2021 2 次提交
  13. 18 3月, 2021 4 次提交
  15. 17 3月, 2021 3 次提交
    • C
      zonefs: fix to update .i_wr_refcnt correctly in zonefs_open_zone() · 6980d29c
      由 Chao Yu 提交于 
      In zonefs_open_zone(), if opened zone count is larger than
.s_max_open_zones threshold, we missed to recover .i_wr_refcnt,
fix this.

Fixes: b5c00e97 ("zonefs: open/close zone on file open/close")
Cc: <stable@vger.kernel.org>
Signed-off-by: NChao Yu <yuchao0@huawei.com>
Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      6980d29c
    • O
      kernel, fs: Introduce and use set_restart_fn() and arch_set_restart_data() · 5abbe51a
      由 Oleg Nesterov 提交于 
      Preparation for fixing get_nr_restart_syscall() on X86 for COMPAT.

Add a new helper which sets restart_block->fn and calls a dummy
arch_set_restart_data() helper.

Fixes: 609c19a3 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210201174641.GA17871@redhat.com
      5abbe51a
    • F
      btrfs: always pin deleted leaves when there are active tree mod log users · 485df755
      由 Filipe Manana 提交于 
      When freeing a tree block we may end up adding its extent back to the
free space cache/tree, as long as there are no more references for it,
it was created in the current transaction and writeback for it never
happened. This is generally fine, however when we have tree mod log
operations it can result in inconsistent versions of a btree after
unwinding extent buffers with the recorded tree mod log operations.

This is because:

* We only log operations for nodes (adding and removing key/pointers),
  for leaves we don't do anything;

* This means that we can log a MOD_LOG_KEY_REMOVE_WHILE_FREEING operation
  for a node that points to a leaf that was deleted;

* Before we apply the logged operation to unwind a node, we can have
  that leaf's extent allocated again, either as a node or as a leaf, and
  possibly for another btree. This is possible if the leaf was created in
  the current transaction and writeback for it never started, in which
  case btrfs_free_tree_block() returns its extent back to the free space
  cache/tree;

* Then, before applying the tree mod log operation, some task allocates
  the metadata extent just freed before, and uses it either as a leaf or
  as a node for some btree (can be the same or another one, it does not
  matter);

* After applying the MOD_LOG_KEY_REMOVE_WHILE_FREEING operation we now
  get the target node with an item pointing to the metadata extent that
  now has content different from what it had before the leaf was deleted.
  It might now belong to a different btree and be a node and not a leaf
  anymore.

  As a consequence, the results of searches after the unwinding can be
  unpredictable and produce unexpected results.

So make sure we pin extent buffers corresponding to leaves when there
are tree mod log users.

CC: stable@vger.kernel.org # 4.14+
Signed-off-by: NFilipe Manana <fdmanana@suse.com>
Signed-off-by: NDavid Sterba <dsterba@suse.com>
      485df755