From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Joakim Zhang <qiangqing.zhang@nxp.com>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
Oliver Hartkopp <socketcan@hartkopp.net>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: [5.10 CAN BUG report] kernel dump about echo skb
Date: Fri, 22 Jan 2021 09:58:47 +0100 [thread overview]
Message-ID: <20210122085847.xr6yo7wc6elwpbop@hardanger.blackshift.org> (raw)
In-Reply-To: <DB8PR04MB6795E0155F4523CA9D4AAC1CE6A10@DB8PR04MB6795.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Thu, Jan 21, 2021 at 08:37:31AM +0000, Joakim Zhang wrote:
> Our auto test scripts reports below kernel dump, after revert Oleksij Rempel
> patch "286228d382ba can: can_create_echo_skb(): fix echo skb generation: always
> use skb_clone()", this issue disappeared. What strange is that, commit message
> intends to fix this issue. Report it here to see if anyone meets the same issue
> or can give some suggestions. I will continue to dig how to reproduce it
> manually, now I don't know how to do it. Thanks.
The backtrace looks more or less like a normal TX-path to me. Although the send
is not directly in the call stack of a user space application, but it's
deferred and then sent by the net_tx_action().
I have the feeling, that this backtrace is triggered by the same problem that
Oleksij tried to fix. Some CAN frames were send on a socket, that socket was
closed and the skbs have reached 0 refcount, after this the frames were put
into the driver.
With Oleksij's patch the skb is always cloned, this means the refcount is
always checked. Reverting that patch covers the problem.
If you can reproduce, revert the patch and add a refcount check againt 0 only.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2021-01-22 9:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 8:37 [5.10 CAN BUG report] kernel dump about echo skb Joakim Zhang
2021-01-22 7:53 ` Joakim Zhang
2021-01-22 9:08 ` Vincent MAILHOL
2021-01-22 9:23 ` Marc Kleine-Budde
2021-01-22 9:40 ` Oleksij Rempel
2021-01-22 9:51 ` Vincent MAILHOL
2021-01-23 7:40 ` Joakim Zhang
2021-01-22 8:58 ` Marc Kleine-Budde [this message]
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=20210122085847.xr6yo7wc6elwpbop@hardanger.blackshift.org \
--to=mkl@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=qiangqing.zhang@nxp.com \
--cc=socketcan@hartkopp.net \
/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.