lkml.org 
[lkml]   [2022]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH mm] mm: fix BUG with kvzalloc+GFP_ATOMIC
Florian Westphal <fw@strlen.de> wrote:
> Michal Hocko <mhocko@suse.com> wrote:
> > On Mon 26-09-22 12:08:00, Florian Westphal wrote:
> > > Michal Hocko <mhocko@suse.com> 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'.

\
 
 \ /
  Last update: 2022-09-26 17:08    [W:0.069 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site