public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: netdev@vger.kernel.org, nbd@nbd.name, john@phrozen.org,
	sean.wang@mediatek.com, Mark-MC.Lee@mediatek.com,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, matthias.bgg@gmail.com,
	linux-mediatek@lists.infradead.org, lorenzo.bianconi@redhat.com
Subject: Re: [PATCH net-next] net: ethernet: mtk_wed: fix possible deadlock if mtk_wed_wo_init fails
Date: Mon, 5 Dec 2022 11:32:03 +0200	[thread overview]
Message-ID: <Y426k9VzOzYlXuOo@unreal> (raw)
In-Reply-To: <Y420B4/IpwFHJAck@lore-desk>

On Mon, Dec 05, 2022 at 10:04:07AM +0100, Lorenzo Bianconi wrote:
> On Dec 05, Leon Romanovsky wrote:
> > On Sun, Dec 04, 2022 at 04:09:21PM +0100, Lorenzo Bianconi wrote:
> > > > On Fri, Dec 02, 2022 at 06:36:33PM +0100, Lorenzo Bianconi wrote:
> > > > > Introduce __mtk_wed_detach() in order to avoid a possible deadlock in
> > > > > mtk_wed_attach routine if mtk_wed_wo_init fails.
> > > > > 
> > > > > Fixes: 4c5de09eb0d0 ("net: ethernet: mtk_wed: add configure wed wo support")
> > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > ---
> > > > >  drivers/net/ethernet/mediatek/mtk_wed.c     | 24 ++++++++++++++-------
> > > > >  drivers/net/ethernet/mediatek/mtk_wed_mcu.c | 10 ++++++---
> > > > >  drivers/net/ethernet/mediatek/mtk_wed_wo.c  |  3 +++
> > > > >  3 files changed, 26 insertions(+), 11 deletions(-)
> > > > 
> > > > <...>
> > > > 
> > > > > diff --git a/drivers/net/ethernet/mediatek/mtk_wed_mcu.c b/drivers/net/ethernet/mediatek/mtk_wed_mcu.c
> > > > > index f9539e6233c9..b084009a32f9 100644
> > > > > --- a/drivers/net/ethernet/mediatek/mtk_wed_mcu.c
> > > > > +++ b/drivers/net/ethernet/mediatek/mtk_wed_mcu.c
> > > > > @@ -176,6 +176,9 @@ int mtk_wed_mcu_send_msg(struct mtk_wed_wo *wo, int id, int cmd,
> > > > >  	u16 seq;
> > > > >  	int ret;
> > > > >  
> > > > > +	if (!wo)
> > > > > +		return -ENODEV;
> > > > 
> > > > <...>
> > > > 
> > > > >  static void
> > > > >  mtk_wed_wo_hw_deinit(struct mtk_wed_wo *wo)
> > > > >  {
> > > > > +	if (!wo)
> > > > > +		return;
> > > > 
> > > > How are these changes related to the written in deadlock?
> > > > How is it possible to get internal mtk functions without valid wo?
> > > 
> > > Hi Leon,
> > > 
> > > if mtk_wed_rro_alloc() fails in mtk_wed_attach(), we will end up running
> > > __mtk_wed_detach() when wo struct is not allocated yet (wo is allocated in
> > > mtk_wed_wo_init()).
> > 
> > IMHO, it is a culprit, proper error unwind means that you won't call to
> > uninit functions for something that is not initialized yet. It is better
> > to fix it instead of adding "if (!wo) ..." checks.
> 
> So, iiuc, you would prefer to do something like:
> 
> __mtk_wed_detach()
> {
> 	...
> 	if (mtk_wed_get_rx_capa(dev) && wo) {
> 		mtk_wed_wo_reset(dev);
> 		mtk_wed_free_rx_rings(dev);
> 		mtk_wed_wo_deinit(hw);
> 	}
> 	...
> 	
> Right? I am fine both ways :)

Yes

> 
> > 
> > > Moreover __mtk_wed_detach() can run mtk_wed_wo_reset() and mtk_wed_wo_deinit()
> > 
> > This is another side of same coin. If you can run them in parallel, you
> > need locking protection and ability to cancel work, so nothing is going
> > to be executed once cleanup succeeded.
> 
> Sorry, I did not get what you mean here with 'in parallel'. __mtk_wed_detach()
> always run with hw_lock mutex help in both mtk_wed_attach() or
> mtk_wed_detach().

Lock is not enough, you need to make sure that no underlying code is
called without wo. You suggestion above is fine. The less low level code
will have "if (!wo) ...", the better will be.

Thanks

> 
> Regards,
> Lorenzo
> 
> > 
> > These were my 2 cents, totally IMHO.
> > 
> > Thanks



  reply	other threads:[~2022-12-05  9:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 17:36 [PATCH net-next] net: ethernet: mtk_wed: fix possible deadlock if mtk_wed_wo_init fails Lorenzo Bianconi
2022-12-04 13:06 ` Leon Romanovsky
2022-12-04 15:09   ` Lorenzo Bianconi
2022-12-05  7:29     ` Leon Romanovsky
2022-12-05  9:04       ` Lorenzo Bianconi
2022-12-05  9:32         ` Leon Romanovsky [this message]
2022-12-06  1:44         ` Jakub Kicinski
2022-12-06 23:52           ` Lorenzo Bianconi
2022-12-07  1:24             ` Jakub Kicinski
2022-12-07  8:58               ` Lorenzo Bianconi

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=Y426k9VzOzYlXuOo@unreal \
    --to=leon@kernel.org \
    --cc=Mark-MC.Lee@mediatek.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=john@phrozen.org \
    --cc=kuba@kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox