bcache: fix stack corruption by PRECEDING_KEY()
Recently people report bcache code compiled with gcc9 is broken, one of
the buggy behavior I observe is that two adjacent 4KB I/Os should merge
into one but they don't. Finally it turns out to be a stack corruption
caused by macro PRECEDING_KEY().
See how PRECEDING_KEY() is defined in bset.h,
437 #define PRECEDING_KEY(_k) \
438 ({ \
439 struct bkey *_ret = NULL; \
440 \
441 if (KEY_INODE(_k) || KEY_OFFSET(_k)) { \
442 _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0); \
443 \
444 if (!_ret->low) \
445 _ret->high--; \
446 _ret->low--; \
447 } \
448 \
449 _ret; \
450 })
At line 442, _ret points to address of a on-stack variable combined by
KEY(), the life range of this on-stack variable is in line 442-446,
once _ret is returned to bch_btree_insert_key(), the returned address
points to an invalid stack address and this address is overwritten in
the following called bch_btree_iter_init(). Then argument 'search' of
bch_btree_iter_init() points to some address inside stackframe of
bch_btree_iter_init(), exact address depends on how the compiler
allocates stack space. Now the stack is corrupted.
Fixes: 0eacac22034c ("bcache: PRECEDING_KEY()")
Signed-off-by: Coly Li <colyli at suse.de>
Reviewed-by: Rolf Fokkens <rolf at rolffokkens.nl>
Reviewed-by: Pierre JUHEN <pierre.juhen at orange.fr>
Tested-by: Shenghui Wang <shhuiw at foxmail.com>
Tested-by: Pierre JUHEN <pierre.juhen at orange.fr>
Cc: Kent Overstreet <kent.overstreet at gmail.com>
Cc: Nix <nix at esperi.org.uk>
Cc: stable at vger.kernel.org
Signed-off-by: Jens Axboe <axboe at kernel.dk>
UnifiedSplitRaw
