Messages in this thread | | | Date | Wed, 22 Nov 2023 18:57:25 -0500 | From | Kent Overstreet <> | Subject | Re: lockdep + kasan bug? |
| |
On Tue, Nov 21, 2023 at 12:41:26PM +0100, Peter Zijlstra wrote: > > I suspect the dodgy access is to chain_block_buckets[-1], which hits the last 4 > > bytes of the redzone and gets (incorrectly/misleadingly) attributed to > > nr_large_chain_blocks. > > That would mean @size == 0, at which point size_to_bucket() returns -1 > and the above happens. > > alloc_chain_hlocks() has 'size - req', for the first with the > precondition 'size >= rq', which allows the 0. > > The second is an iteration with the condition size > req, which does not > allow the 0 case. > > So the first, thing, IIRC, this is trying to split a block, > del_chain_block() takes what we need, and add_chain_block() puts back > the remainder, except in the above case the remainder is 0 sized and > things go sideways or so. > > Does the below help? > > --- > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index e85b5ad3e206..151bd3de5936 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -3497,7 +3497,8 @@ static int alloc_chain_hlocks(int req) > size = chain_block_size(curr); > if (likely(size >= req)) { > del_chain_block(0, size, chain_block_next(curr)); > - add_chain_block(curr + req, size - req); > + if (size > req) > + add_chain_block(curr + req, size - req); > return curr; > } > } >
Yep, no kasan splats with that patch
| |