[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZvdSFlaEkk7fqZVl@gondor.apana.org.au>
Date: Sat, 28 Sep 2024 08:47:18 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Dave Chinner <david@...morbit.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Dave Chinner <dchinner@...hat.com>,
Thomas Graf <tgraf@...g.ch>, netdev@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs changes for 6.12-rc1
On Fri, Sep 27, 2024 at 08:11:06PM -0400, Kent Overstreet wrote:
>
> > > And, when I was torture testing that code I tripped over what appeared
> > > to be an infinite loop in rht_bucket() when a rehsah is in progress,
> > > which I worked around in
> > >
> > > a592cdf5164d bcachefs: don't use rht_bucket() in btree_key_cache_scan()
> >
> > You must not walk the rhashtable internal data structures by hand.
> > If you need to iterate through the whole table, use the provided
> > walking mechanism.
>
> I was just doing rht_for_each_entry_rcu() (open coded because you don't
> provide a safe version).
I'm talking about the commit a592cd above. You were doing this:
for (i = 0; i < tbl->size; i++)
rht_for_each_entry_rcu(ck, pos, tbl, i, hash) {
This is absolutely not allowed. The rhashtable must only be accessed
through the published API and not iterated over directly. This is
guaranteed to break during a resize/rehash.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists