On Sun, Nov 17, 2024 at 11:51:39PM +0000, Piotr Zalewski wrote: > Hi, all > > This seems to be the proper way to fix this?: > > diff --git a/fs/bcachefs/btree_io.c b/fs/bcachefs/btree_io.c > index 89a42ee81e5c..f92a3fb946de 100644 > --- a/fs/bcachefs/btree_io.c > +++ b/fs/bcachefs/btree_io.c > @@ -324,6 +324,7 @@ static void btree_node_sort(struct bch_fs *c, struct > btree *b, > start_time = local_clock(); > > u64s = bch2_sort_keys(out->keys.start, &sort_iter.iter); > + memset((out->keys.start + u64s), 0, bytes - sizeof(struct btree_node) - > u64s * sizeof(u64)); > > out->keys.u64s = cpu_to_le16(u64s);
Did you do any analysis you can share? It seems like zeroing out the rest of the buffer shouldn't be necessary: we do that at write time, where it really is necessary, otherwise we shouldn't be accessing parts of the buffer that don't have valid keys in them. varint_decode_fast, used for inodes, does do reads (that aren't used) up to 7 bytes past the valid data, so it could be needed if we were seeing kmsan splats there - but this is bkey comparison, so something fishy seems to be going on.
