From: David Woodhouse <dwmw2@infradead.org>
To: netdev@vger.kernel.org
Cc: Simon Arlott <simon@fire.lp0.eu>,
linux-atm-general@lists.sourceforge.net, nathan@traverse.com.au
Subject: [PATCH RFC] solos-pci: Fix BUG() with shared skb
Date: Tue, 03 Sep 2013 16:45:25 +0100 [thread overview]
Message-ID: <1378223125.4210.11.camel@i7.infradead.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]
Simon reported this BUG():
kernel BUG at net/core/skbuff.c:1065!
Call Trace:
[<f9b7c12c>] ? pppoatm_send+0x3f/0x1a0 [pppoatm]
[<f8751797>] psend+0xa9/0x14a [solos_pci]
[<f9b7c248>] pppoatm_send+0x15b/0x1a0 [pppoatm]
[<f8a2f77d>] ppp_push+0x76/0x533 [ppp_generic]
(Rest of backtrace at http://s85.org/mn0aOxMN — the skb appears to be
IPv6, forwarded from another interface over PPPoATM.)
I wasn't expecting to see shared skbs in the ATM driver's ->send()
function. Is this the right fix?
I've included the whole function in the patch context... I appear to be
jumping through a lot of hand-coded hoops here, just to ensure that I
can safely prepend my own device's hardware header to the skb. This
makes me think that I'm doing something severely wrong. There ought to
be an easier way of doing this, surely? What am I missing?
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 32784d1..b15e475 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -1135,40 +1135,50 @@ static uint32_t fpga_tx(struct solos_card *card)
static int psend(struct atm_vcc *vcc, struct sk_buff *skb)
{
struct solos_card *card = vcc->dev->dev_data;
struct pkt_hdr *header;
int pktlen;
pktlen = skb->len;
if (pktlen > (BUF_SIZE - sizeof(*header))) {
dev_warn(&card->dev->dev, "Length of PDU is too large. Dropping PDU.\n");
solos_pop(vcc, skb);
return 0;
}
+ /* This is skb_share_check() except it uses solos_pop() instead of kfree_skb() */
+ if (skb_shared(skb)) {
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+ if (unlikely(!nskb)) {
+ solos_pop(vcc, skb);
+ return 0;
+ }
+ consume_skb(skb);
+ skb = nskb;
+ }
if (!skb_clone_writable(skb, sizeof(*header))) {
int expand_by = 0;
int ret;
if (skb_headroom(skb) < sizeof(*header))
expand_by = sizeof(*header) - skb_headroom(skb);
ret = pskb_expand_head(skb, expand_by, 0, GFP_ATOMIC);
if (ret) {
dev_warn(&card->dev->dev, "pskb_expand_head failed.\n");
solos_pop(vcc, skb);
return ret;
}
}
header = (void *)skb_push(skb, sizeof(*header));
/* This does _not_ include the size of the header */
header->size = cpu_to_le16(pktlen);
header->vpi = cpu_to_le16(vcc->vpi);
header->vci = cpu_to_le16(vcc->vci);
header->type = cpu_to_le16(PKT_DATA);
fpga_queue(card, SOLOS_CHAN(vcc->dev), skb, vcc);
return 0;
}
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
next reply other threads:[~2013-09-03 15:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-03 15:45 David Woodhouse [this message]
2013-09-04 18:30 ` [PATCH RFC] solos-pci: Fix BUG() with shared skb David Miller
2013-09-04 20:41 ` David Woodhouse
2013-09-04 21:51 ` David Miller
2015-09-15 19:10 ` David Woodhouse
2015-09-16 11:32 ` Simon Arlott
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=1378223125.4210.11.camel@i7.infradead.org \
--to=dwmw2@infradead.org \
--cc=linux-atm-general@lists.sourceforge.net \
--cc=nathan@traverse.com.au \
--cc=netdev@vger.kernel.org \
--cc=simon@fire.lp0.eu \
/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).