Re: [PATCH] mm/mempolicy: Fix sleeping allocation in alloc_pages_bulk_weighted_interleave()

[Eric Dumazet]

On Fri, Aug 21, 2026 at 7:40 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 21 Aug 2026 17:04:07 +0000 Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
>
> > syzbot reported a sleeping function called from invalid context splat
> > in bucket_table_alloc().
>
> That was quick (7 minutes!).  I was just looking at this.

That is because I had the syzbot report in our private queue.

I thought it was a networking bug at first.

When I realized this was an mm bug, I decided to cook the patch,
release the syzbot report, and send the patch :)

>
> > When rhashtable_insert_slow() rehashes the table under rcu_read_lock(),
> > it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN).
> > If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof()
> > invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with
> > the passed GFP_ATOMIC flags.
> >
> > If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy,
> > alloc_pages_bulk_weighted_interleave() is called and currently hardcodes
> > GFP_KERNEL when allocating the temporary weights array, triggering
> > a might_alloc() splat in atomic/RCU contexts.
>
> 2 years ago.  Why are we discovering this now?

syzbot got better in recent weeks.

Google folks can look at go/syzkaller-llm-fuzzing

Thanks.