From: Eric Wheeler
When bch_cache_set_alloc() fails to kzalloc the cache_set, the
asyncronous closure handling tries to dereference a cache_set that
hadn't yet been allocated inside of cache_set_flush() which is called
by __cache_set_unregister() during cleanup. This appears to happen only
From: Zheng Liu
In bcache_init() function it forgot to unregister reboot notifier if
bcache fails to unregister a block device. This commit fixes this.
Signed-off-by: Zheng Liu
Tested-by: Joshua Schmid
Tested-by: Eric Wheeler
Cc: Kent Overstreet
Cc: sta...@vger.kernel.org
Signed-off-by:
From: Kent Overstreet
The code that handles overlapping extents that we've just read back in from disk
was depending on the behaviour of the code that handles overlapping extents as
we're inserting into a btree node in the case of an insert that forced an
existing extent to be split: on insert,
When bcache is built on top of raid1 devices, the following
warning happens:
WARNING: CPU: 2 PID: 8138 at include/linux/bio.h:559
raid1_write_request+0x994/0xba0 [raid1]
Call Trace:
dump_stack+0x19/0x1b
__warn+0xd8/0x100
warn_slowpath_null+0x1d/0x20
raid1_write_request+0x994/0xba0
When bcache is built on top of raid1 devices, the following
warning happens:
WARNING: CPU: 2 PID: 8138 at include/linux/bio.h:559
raid1_write_request+0x994/0xba0 [raid1]
Call Trace:
dump_stack+0x19/0x1b
__warn+0xd8/0x100
warn_slowpath_null+0x1d/0x20
raid1_write_request+0x994/0xba0
Adding user key might trigger 4-order allocation which is unreliable
in case of fragmented memory:
[ cut here ]
WARNING: CPU: 3 PID: 134927 at mm/page_alloc.c:3533
__alloc_pages_nodemask+0x1b1/0x600
order 4 >= 3, gfp 0x40d0
Kernel panic - not syncing: panic_on_warn
On 9/14/20 1:55 PM, Andrey Ryabinin wrote:
> Adding user key might trigger 4-order allocation which is unreliable
> in case of fragmented memory:
>
> [ cut here ]
> WARNING: CPU: 3 PID: 134927 at mm/page_alloc.c:3533
> __alloc_pages_nodemask+0x1b1/0x600
> order 4 >= 3,
Adding user key might trigger 4-order allocation which is unreliable
in case of fragmented memory:
[ cut here ]
WARNING: CPU: 3 PID: 134927 at mm/page_alloc.c:3533
__alloc_pages_nodemask+0x1b1/0x600
order 4 >= 3, gfp 0x40d0
Kernel panic - not syncing: panic_on_warn
From: Eric Wheeler
When bch_cache_set_alloc() fails to kzalloc the cache_set, the
asyncronous closure handling tries to dereference a cache_set that
hadn't yet been allocated inside of cache_set_flush() which is called
by __cache_set_unregister() during cleanup. This appears to happen only
From: Zheng Liu
In bcache_init() function it forgot to unregister reboot notifier if
bcache fails to unregister a block device. This commit fixes this.
Signed-off-by: Zheng Liu
Tested-by: Joshua Schmid
Tested-by: Eric Wheeler
Cc: Kent Overstreet
Cc: sta...@vger.kernel.org
Signed-off-by:
From: Kent Overstreet
The code that handles overlapping extents that we've just read back in from disk
was depending on the behaviour of the code that handles overlapping extents as
we're inserting into a btree node in the case of an insert that forced an
existing extent to be split: on insert,
When bcache is built on top of raid1 devices, the following
warning happens:
WARNING: CPU: 2 PID: 8138 at include/linux/bio.h:559
raid1_write_request+0x994/0xba0 [raid1]
Call Trace:
dump_stack+0x19/0x1b
__warn+0xd8/0x100
warn_slowpath_null+0x1d/0x20
raid1_write_request+0x994/0xba0
12 matches
Mail list logo
