All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Martin Zaharinov <micron10@gmail.com>
Cc: Florian Westphal <fw@strlen.de>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	pablo@netfilter.org, Paolo Abeni <pabeni@redhat.com>,
	netdev <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, linux-mm@kvack.org,
	mhocko@suse.com
Subject: Re: Bug Report Flowtable NFT with kernel 5.19.9
Date: Thu, 22 Sep 2022 14:12:54 +0200	[thread overview]
Message-ID: <20220922121254.GA19803@breakpoint.cc> (raw)
In-Reply-To: <09BE0B8A-3ADF-458E-B75E-931B74996355@gmail.com>

Martin Zaharinov <micron10@gmail.com> wrote:
> This is bug report for flowtable and kernel 5.19.9
> 
> simple config nat + flowtable 

CC mm experts.  I'm not sure that this is a bug in netfilter/rhashtable,
looks like mm problem perhaps?

I am a bit confused wrt. kvzalloc+GFP_ATOMIC.  This looks like following is happening:

5.19.9 kernel BUGs with:

> Sep 22 07:43:49  [460691.305266][   C28] kernel BUG at mm/vmalloc.c:2437!

[ BUG_ON(in_interrupt ]

> Sep 22 07:43:50  [460692.031617][   C28] Call Trace:
> Sep 22 07:43:50  [460692.064498][   C28]  <IRQ>
> Sep 22 07:43:50  [460692.096177][   C28]  __vmalloc_node_range+0x96/0x1e0
> Sep 22 07:43:50  [460692.128014][   C28]  ? bucket_table_alloc.isra.0+0x47/0x140
> Sep 22 07:43:50  [460692.160134][   C28]  kvmalloc_node+0x92/0xb0
> Sep 22 07:43:50  [460692.191885][   C28]  ? bucket_table_alloc.isra.0+0x47/0x140
> Sep 22 07:43:50  [460692.224234][   C28]  bucket_table_alloc.isra.0+0x47/0x140
> Sep 22 07:43:50  [460692.256840][   C28]  rhashtable_try_insert+0x3a4/0x440

[ rest irrelevant ]

AFAICS this is caused by kvzalloc(GFP_ATOMIC) which somehow ends up in
GFP_KERNEL-only territory?  Looking at recent history I see

commit a421ef303008b0ceee2cfc625c3246fa7654b0ca
Author: Michal Hocko <mhocko@suse.com>
Date:   Fri Jan 14 14:07:07 2022 -0800

    mm: allow !GFP_KERNEL allocations for kvmalloc

before this, GFP_ATOMIC made sure we stay with plain kmalloc, but
now it appears that we can end up in places where GFP_ATOMIC isn't
allowed?

Original bug report is here:
https://lore.kernel.org/netdev/09BE0B8A-3ADF-458E-B75E-931B74996355@gmail.com/T/#u

  reply	other threads:[~2022-09-22 12:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22  6:08 Bug Report Flowtable NFT with kernel 5.19.9 Martin Zaharinov
2022-09-22 12:12 ` Florian Westphal [this message]
2022-09-23  5:54   ` Martin Zaharinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220922121254.GA19803@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=micron10@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.