All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: WangYuli <wangyuli@uniontech.com>
Cc: louis.peens@corigine.com, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	chenlinxuan@uniontech.com, viro@zeniv.linux.org.uk,
	oss-drivers@corigine.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, guanwentao@uniontech.com,
	niecheng1@uniontech.com, Jun Zhan <zhanjun@uniontech.com>
Subject: Re: [PATCH] nfp: nfp_alloc_bar: Fix double unlock
Date: Mon, 23 Jun 2025 13:11:41 -0700	[thread overview]
Message-ID: <20250623131141.332c631c@kernel.org> (raw)
In-Reply-To: <9EE5B02BB2EF6895+20250623041104.61044-1-wangyuli@uniontech.com>

On Mon, 23 Jun 2025 12:11:04 +0800 WangYuli wrote:
> The lock management in the nfp_alloc_bar function is problematic:
> 
>  *1. The function acquires the lock at the beginning:
> spin_lock_irqsave(&nfp->bar_lock, irqflags).
> 
>   2. When barnum < 0 and in non-blocking mode, the code jumps to
> the err_nobar label. However, in this non-blocking path, if
> barnum < 0, the code releases the lock and calls nfp_wait_for_bar.
> 
>   3. Inside nfp_wait_for_bar, find_unused_bar_and_lock is called,
> which holds the lock upon success (indicated by the __release
> annotation). Consequently, when nfp_wait_for_bar returns
> successfully, the lock is still held.
> 
>   4. But at the err_nobar label, the code always executes
> spin_unlock_irqrestore(&nfp->bar_lock, irqflags).
> 
>   5. The problem arises when nfp_wait_for_bar successfully finds a
> BAR: the lock is still held, but if a subsequent reconfigure_bar
> fails, the code will attempt to unlock it again at err_nobar,
> leading to a double unlock.

I don't understand what you're trying to say.
If you think your analysis is correct please provide a more exact
execution path with a code listing.
-- 
pw-bot: cr

  reply	other threads:[~2025-06-23 20:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-23  4:11 [PATCH] nfp: nfp_alloc_bar: Fix double unlock WangYuli
2025-06-23 20:11 ` Jakub Kicinski [this message]
2025-07-01  7:45   ` Chen Linxuan
2025-07-01  7:54     ` Chen Linxuan

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=20250623131141.332c631c@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=chenlinxuan@uniontech.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=guanwentao@uniontech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=louis.peens@corigine.com \
    --cc=netdev@vger.kernel.org \
    --cc=niecheng1@uniontech.com \
    --cc=oss-drivers@corigine.com \
    --cc=pabeni@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wangyuli@uniontech.com \
    --cc=zhanjun@uniontech.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.