Florian Westphal <fw@xxxxxxxxx> wrote:
> Michal Hocko <mhocko@xxxxxxxx> wrote:
> > On Mon 26-09-22 12:08:00, Florian Westphal wrote:
> > > Michal Hocko <mhocko@xxxxxxxx> wrote:
> > > > + old_tbl = rht_dereference_rcu(ht->tbl, ht);
> > > > + size = tbl->size;
> > > > +
> > > > + data = ERR_PTR(-EBUSY);
> > > > +
> > > > + if (rht_grow_above_75(ht, tbl))
> > > > + size *= 2;
> > > > + /* Do not schedule more than one rehash */
> > > > + else if (old_tbl != tbl)
> > > > + return data;
> > > > +
> > > > + data = ERR_PTR(-ENOMEM);
> > > > +
> > > > + rcu_read_unlock();
> > > > + new_tbl = bucket_table_alloc(ht, size, GFP_KERNEL);
> > > > + rcu_read_lock();
> > >
> > > I don't think this is going to work, there can be callers that
> > > rely on rcu protected data structures getting free'd.
> >
> > The caller of this function drops RCU for each retry, why should be the
> > called function any special?
>
> I was unfortunately never able to fully understand rhashtable.
Obviously.
> AFAICS the rcu_read_lock/unlock in the caller is pointless,
> or at least dubious.
Addedum, I can't read:
void *rhashtable_insert_slow(struct rhashtable *ht, const void *key,
struct rhash_head *obj)
{
void *data;
do {
rcu_read_lock();
data = rhashtable_try_insert(ht, key, obj);
rcu_read_unlock();
}
} while (PTR_ERR(data) == -EAGAIN);
}
... which is needed to prevent a lockdep splat in
rhashtable_try_insert() -- there is no guarantee the caller already
has rcu_read_lock().
> To the best of my knowledge there are users of this interface that
> invoke it with rcu read lock held, and since those always nest, the
> rcu_read_unlock() won't move us to GFP_KERNEL territory.
>
> I guess you can add a might_sleep() and ask kernel to barf at runtime.
I did and it triggers. Caller is inet_frag_find(), triggered
via 'ping -s 60000 $addr'.
