Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 26 11月, 2017 1 次提交
  3. 25 11月, 2017 5 次提交
    • M
      bcache: check return value of register_shrinker · 6c4ca1e3
      由 Michael Lyle 提交于 
      register_shrinker is now __must_check, so check it to kill a warning.
Caller of bch_btree_cache_alloc in super.c appropriately checks return
value so this is fully plumbed through.

This V2 fixes checkpatch warnings and improves the commit description,
as I was too hasty getting the previous version out.
Signed-off-by: NMichael Lyle <mlyle@lyle.org>
Reviewed-by: NVojtech Pavlik <vojtech@suse.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
      6c4ca1e3
    • R
      bcache: recover data from backing when data is clean · e393aa24
      由 Rui Hua 提交于 
      When we send a read request and hit the clean data in cache device, there
is a situation called cache read race in bcache(see the commit in the tail
of cache_look_up(), the following explaination just copy from there):
The bucket we're reading from might be reused while our bio is in flight,
and we could then end up reading the wrong data. We guard against this
by checking (in bch_cache_read_endio()) if the pointer is stale again;
if so, we treat it as an error (s->iop.error = -EINTR) and reread from
the backing device (but we don't pass that error up anywhere)

It should be noted that cache read race happened under normal
circumstances, not the circumstance when SSD failed, it was counted
and shown in  /sys/fs/bcache/XXX/internal/cache_read_races.

Without this patch, when we use writeback mode, we will never reread from
the backing device when cache read race happened, until the whole cache
device is clean, because the condition
(s->recoverable && (dc && !atomic_read(&dc->has_dirty))) is false in
cached_dev_read_error(). In this situation, the s->iop.error(= -EINTR)
will be passed up, at last, user will receive -EINTR when it's bio end,
this is not suitable, and wield to up-application.

In this patch, we use s->read_dirty_data to judge whether the read
request hit dirty data in cache device, it is safe to reread data from
the backing device when the read request hit clean data. This can not
only handle cache read race, but also recover data when failed read
request from cache device.

[edited by mlyle to fix up whitespace, commit log title, comment
spelling]

Fixes: d59b2379 ("bcache: only permit to recovery read error when cache device is clean")
Cc: <stable@vger.kernel.org> # 4.14
Signed-off-by: NHua Rui <huarui.dev@gmail.com>
Reviewed-by: NMichael Lyle <mlyle@lyle.org>
Reviewed-by: NColy Li <colyli@suse.de>
Signed-off-by: NMichael Lyle <mlyle@lyle.org>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
      e393aa24
    • H
      bcache: Fix building error on MIPS · cf33c1ee
      由 Huacai Chen 提交于 
      This patch try to fix the building error on MIPS. The reason is MIPS
has already defined the PTR macro, which conflicts with the PTR macro
in include/uapi/linux/bcache.h.

[fixed by mlyle: corrected a line-length issue]

Cc: stable@vger.kernel.org
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Reviewed-by: NMichael Lyle <mlyle@lyle.org>
Signed-off-by: NMichael Lyle <mlyle@lyle.org>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
      cf33c1ee
    • T
      bcache: add a comment in journal bucket reading · bb22cafd
      由 Tang Junhui 提交于 
      Journal bucket is a circular buffer, the bucket
can be like YYYNNNYY, which means the first valid journal in
the 7th bucket, and the latest valid journal in third bucket, in
this case, if we do not try we the zero index first, We
may get a valid journal in the 7th bucket, then we call
find_next_bit(bitmap,ca->sb.njournal_buckets, l + 1) to get the
first invalid bucket after the 7th bucket, because all these
buckets is valid, so no bit 1 in bitmap, thus find_next_bit()
function would return with ca->sb.njournal_buckets (8). So, after
that, bcache only read journal in 7th and 8the bucket,
the first to the third buckets are lost.

So, it is important to let developer know that, we need to try
the zero index at first in the hash-search, and avoid any breaks
in future's code modification.

[ML: Fixed whitespace & formatting & file permissions]
Signed-off-by: NTang Junhui <tang.junhui@zte.com.cn>
Signed-off-by: NMichael Lyle <mlyle@lyle.org>
Reviewed-by: NMichael Lyle <mlyle@lyle.org>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
      bb22cafd
    • J
      nvme-fc: don't use bit masks for set/test_bit() numbers · 26c0a26d
      由 Jens Axboe 提交于 
      So far harmless, but it's confusing and a bug waiting to happen if the
shifts grow larger than 4.
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
      26c0a26d
  5. 23 11月, 2017 1 次提交
  7. 22 11月, 2017 1 次提交
    • D
      null_blk: fix dev->badblocks leak · 1addb798
      由 David Disseldorp 提交于 
      null_alloc_dev() allocates memory for dev->badblocks, but cleanup
currently only occurs in the configfs release codepath, missing a number
of other places.

This bug was found running the blktests block/010 test, alongside
kmemleak:
rapido1:/blktests# ./check block/010
...
rapido1:/blktests# echo scan > /sys/kernel/debug/kmemleak
[  306.966708] kmemleak: 32 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
rapido1:/blktests# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff88001f86d000 (size 4096):
  comm "modprobe", pid 231, jiffies 4294892415 (age 318.252s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff814b0379>] kmemleak_alloc+0x49/0xa0
    [<ffffffff810f180f>] kmem_cache_alloc+0x9f/0xe0
    [<ffffffff8124e45f>] badblocks_init+0x2f/0x60
    [<ffffffffa0019fae>] 0xffffffffa0019fae
    [<ffffffffa0021273>] nullb_device_badblocks_store+0x63/0x130 [null_blk]
    [<ffffffff810004cd>] do_one_initcall+0x3d/0x170
    [<ffffffff8109fe0d>] do_init_module+0x56/0x1e9
    [<ffffffff8109ebd7>] load_module+0x1c47/0x26a0
    [<ffffffff8109f819>] SyS_finit_module+0xa9/0xd0
    [<ffffffff814b4f60>] entry_SYSCALL_64_fastpath+0x13/0x94

Fixes: 2f54a613 ("nullb: badbblocks support")
Reviewed-by: NShaohua Li <shli@fb.com>
Signed-off-by: NDavid Disseldorp <ddiss@suse.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
      1addb798
  9. 20 11月, 2017 9 次提交
  11. 19 11月, 2017 2 次提交
  13. 18 11月, 2017 10 次提交
  15. 17 11月, 2017 11 次提交