All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@gmail.com>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	davem@davemloft.net, kuba@kernel.org
Cc: dirk.behme@de.bosch.com, Shashikant.Suguni@in.bosch.com,
	netdev@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH/RFC v2] net: ethernet: ravb: exit if hardware is in-progress in tx timeout
Date: Mon, 20 Jul 2020 20:14:31 +0300	[thread overview]
Message-ID: <7d37c358-fab9-8ec1-6fff-688d33898b09@gmail.com> (raw)
In-Reply-To: <1595246298-29260-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>

Hello!

On 7/20/20 2:58 PM, Yoshihiro Shimoda wrote:

> According to the report of [1], this driver is possible to cause
> the following error in ravb_tx_timeout_work().
> 
> ravb e6800000.ethernet ethernet: failed to switch device to config mode

   Hmm, maybe we need a larger timeout there? The current one amounts to only
~100 ms for all cases (maybe we should parametrize the timeout?)...
  
> This error means that the hardware could not change the state
> from "Operation" to "Configuration" while some tx and/or rx queue
> are operating. After that, ravb_config() in ravb_dmac_init() will fail,

   Are we seeing double messages from ravb_config()? I think we aren't...

> and then any descriptors will be not allocaled anymore so that NULL
> pointer dereference happens after that on ravb_start_xmit().
> 
> To fix the issue, the ravb_tx_timeout_work() should check
> the return value of ravb_stop_dma() whether this hardware can be
> re-initialized or not. If ravb_stop_dma() fails, ravb_tx_timeout_work()
> re-enables TX and RX and just exits.
> 
> [1]
> https://lore.kernel.org/linux-renesas-soc/20200518045452.2390-1-dirk.behme@de.bosch.com/
> 
> Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

   Assuming the comment below is fixed:

Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>

> ---
>  Changes from RFC v1:
>  - Check the return value of ravb_stop_dma() and exit if the hardware
>    condition can not be initialized in the tx timeout.
>  - Update the commit subject and description.
>  - Fix some typo.
>  https://patchwork.kernel.org/patch/11570217/
> 
>  Unfortunately, I still didn't reproduce the issue yet. So, I still
>  marked RFC on this patch.

    I think the Bosch people should test this patch, as they reported the kernel oops...

> 
>  drivers/net/ethernet/renesas/ravb_main.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index a442bcf6..500f5c1 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1458,7 +1458,18 @@ static void ravb_tx_timeout_work(struct work_struct *work)
>  		ravb_ptp_stop(ndev);
>  
>  	/* Wait for DMA stopping */
> -	ravb_stop_dma(ndev);
> +	if (ravb_stop_dma(ndev)) {
> +		/* If ravb_stop_dma() fails, the hardware is still in-progress
> +		 * as "Operation" mode for TX and/or RX. So, this should not

   s/in-progress as "Operation" mode/operating/.

> +		 * call the following functions because ravb_dmac_init() is
> +		 * possible to fail too. Also, this should not retry
> +		 * ravb_stop_dma() again and again here because it's possible
> +		 * to wait forever. So, this just re-enables the TX and RX and
> +		 * skip the following re-initialization procedure.
> +		 */
> +		ravb_rcv_snd_enable(ndev);
> +		goto out;
> +	}
>  
>  	ravb_ring_free(ndev, RAVB_BE);
>  	ravb_ring_free(ndev, RAVB_NC);
> @@ -1467,6 +1478,7 @@ static void ravb_tx_timeout_work(struct work_struct *work)
>  	ravb_dmac_init(ndev);

   BTW, that one also may fail...

>  	ravb_emac_init(ndev);
>  
> +out:
>  	/* Initialise PTP Clock driver */
>  	if (priv->chip_id == RCAR_GEN2)
>  		ravb_ptp_init(ndev, priv->pdev);
> 


  reply	other threads:[~2020-07-20 17:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20 11:58 [PATCH/RFC v2] net: ethernet: ravb: exit if hardware is in-progress in tx timeout Yoshihiro Shimoda
2020-07-20 17:14 ` Sergei Shtylyov [this message]
2020-07-21  1:39   ` Yoshihiro Shimoda

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=7d37c358-fab9-8ec1-6fff-688d33898b09@gmail.com \
    --to=sergei.shtylyov@gmail.com \
    --cc=Shashikant.Suguni@in.bosch.com \
    --cc=davem@davemloft.net \
    --cc=dirk.behme@de.bosch.com \
    --cc=kuba@kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.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.