From: Jakub Kicinski <kuba@kernel.org>
To: Simon Horman <horms@kernel.org>
Cc: Yang Zi <2959243019@qq.com>,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
andrew+netdev@lunn.ch, kees@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: liquidio: avoid sleeping allocation under octeon_devices_lock
Date: Wed, 2 Sep 2026 17:58:08 -0700 [thread overview]
Message-ID: <20260902175808.095e3cd4@kernel.org> (raw)
In-Reply-To: <20260902155423.GG396647@horms.kernel.org>
On Wed, 2 Sep 2026 16:54:23 +0100 Simon Horman wrote:
> On Tue, Aug 25, 2026 at 04:50:55PM +0800, Yang Zi wrote:
> > octeon_allocate_device() holds the spinlock octeon_devices_lock while
> > calling octeon_allocate_device_mem(), which uses vzalloc(). vzalloc()
> > can sleep, so this is a "scheduling while atomic" bug that can trigger a
> > sleeping-in-atomic warning (or deadlock on a preemptible kernel).
> >
> > The memory allocation does not touch octeon_device[], octeon_device_count
> > or the free-slot search, so it does not need the lock. Move the
> > octeon_allocate_device_mem() call ahead of the lock: allocate the device
> > memory first, then take the lock only to find a free slot and register
> > the new device in the octeon_device[] array. If no slot is available
> > (all MAX_OCTEON_DEVICES slots in use), free the freshly allocated memory
> > and return NULL as before.
> >
> > The lock therefore continues to protect exactly the data it documents:
> > the octeon_device[] array and octeon_device_count.
> >
> > Signed-off-by: Yang Zi <2959243019@qq.com>
>
> This patch has been marked as Not Applicable in patchwork.
> I assume that is because it doesn't apply.
> Which I believe, in turn, is because it is whitespace mangled:
> the tabs appear to have been substituted for combinations
> of spaces and non-breaking spaces.
>
> Please consider updating the way that you send patches -
> e.g. using b4 or a different mail server - and reposting.
Also we should consider deleting liquidio instead of fixing it?
It's _stupendously_ buggy, and Orphaned.
next prev parent reply other threads:[~2026-09-03 0:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 8:50 [PATCH] net: liquidio: avoid sleeping allocation under octeon_devices_lock Yang Zi
2026-09-02 15:54 ` Simon Horman
2026-09-03 0:58 ` Jakub Kicinski [this message]
2026-09-03 10:28 ` Simon Horman
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=20260902175808.095e3cd4@kernel.org \
--to=kuba@kernel.org \
--cc=2959243019@qq.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.