linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: Zhang Heng <zhangheng@kylinos.cn>,
	axboe@kernel.dk, phasta@kernel.org,
	 andriy.shevchenko@linux.intel.com, broonie@kernel.org,
	lizetao1@huawei.com, viro@zeniv.linux.org.uk,
	fourier.thomas@gmail.com, anuj20.g@samsung.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] block: mtip32xx: Prioritize state cleanup over memory freeing in the mtip_pci_probe error path.
Date: Mon, 25 Aug 2025 13:33:17 +0200	[thread overview]
Message-ID: <ab3196a1e0ccb8f94eafb83de589c0ae8f82d598.camel@mailbox.org> (raw)
In-Reply-To: <20250823083222.3137817-1-zhangheng@kylinos.cn>

On Sat, 2025-08-23 at 16:32 +0800, Zhang Heng wrote:
> The original sequence kfree(dd); pci_set_drvdata(pdev, NULL); creates a
> theoretical race condition window. Between these two calls, the pci_dev
> structure retains a dangling pointer to the already-freed device private
> data (dd). Any concurrent access to the drvdata (e.g., from an interrupt
> handler or an unexpected call to remove) would lead to a use-after-free
> kernel oops.

I tend to disagree I think . This is the driver's probe() function. It
is always invoked serially by the driver core.

remove() cannot be called while probe() is still running.

Thus, the only potential explosion that could happen would be if an
interrupt handler were to be set up in this probe() and then accesses
dd.

However, if that were the case, everything would be exploding already
because there is no place in the code that tears down that interrupt
handler or other potential parallel accessors before kfree(dd) is
called.

In this case, the relevant call is pci_enable_msi(). Sooner errors,
like iomap_err: are jumped to before that's the case. Which is the only
sane design for probe() anyways. Otherwise, pci_disable_msi() switches
that off again; IOW: there are no racers.

So I think that the pci_set_drvdata(… NULL) can be removed
alltogether. 

When working on the probe() / remove() paths last and this year, I came
to believe that calls like that were often used because of a
misunderstanding of how the driver core APIs work.


P.


> 
> Changes made:
> 1. `pci_set_drvdata(pdev, NULL);` - First, atomically sever the link
> from the pci_dev.
> 2. `kfree(dd);` - Then, safely free the private memory.
> 
> This ensures the kernel state is always consistent before resources
> are released, adhering to defensive programming principles.
> 
> Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
> ---
>  drivers/block/mtip32xx/mtip32xx.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c
> index 8fc7761397bd..f228363e6b1c 100644
> --- a/drivers/block/mtip32xx/mtip32xx.c
> +++ b/drivers/block/mtip32xx/mtip32xx.c
> @@ -3839,9 +3839,8 @@ static int mtip_pci_probe(struct pci_dev *pdev,
>  	}
>  
>  iomap_err:
> -	kfree(dd);
>  	pci_set_drvdata(pdev, NULL);
> -	return rv;
> +	kfree(dd);
>  done:
>  	return rv;
>  }


  parent reply	other threads:[~2025-08-25 11:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-23  8:32 [PATCH v2] block: mtip32xx: Prioritize state cleanup over memory freeing in the mtip_pci_probe error path Zhang Heng
2025-08-25 10:56 ` Andy Shevchenko
2025-08-25 10:58   ` Andy Shevchenko
2025-08-25 11:33 ` Philipp Stanner [this message]
2025-08-25 13:40   ` Andy Shevchenko

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=ab3196a1e0ccb8f94eafb83de589c0ae8f82d598.camel@mailbox.org \
    --to=phasta@mailbox.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anuj20.g@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=broonie@kernel.org \
    --cc=fourier.thomas@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizetao1@huawei.com \
    --cc=phasta@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zhangheng@kylinos.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).