Vague maybe ppp-related panic report for 2.6.23-rc9
Subsystems (2)
I'm running 2.6.23-rc9 on my laptop, and when in a coffee shop I use a Verizon EVDO card to get network access. This is a kyocera device that looks like a serial adapter behind an ohci usb controller, and uses the airprime driver (for usb device 0c88:17da). The actual IP networking is ppp over that serial adapter.
The connection is slightly flaky (I blame this on the Verizon coverage), so I end up restarting things every so often. The point of this email (at last) is that I've just seen my second panic (only
info: blinking caps lock led, since I've been in X) that seems correlated to stopping/restarting pppd.
Sorry for the lack of detail -- I've just switched to running in the console so if I can provoke the crash again I'll get a little more info. I just wanted to mention this in case someone has seen something similar or has any good ideas about how to capture debugging output on a laptop (when I'm not home and have no other boxes handy).
- R.
David Miller
maintainerFrom: Roland Dreier <[email protected]>
Date: Thu, 04 Oct 2007 11:12:42 -0700
Quoted 5 lines
Sorry for the lack of detail -- I've just switched to running in the console so if I can provoke the crash again I'll get a little more info. I just wanted to mention this in case someone has seen something similar or has any good ideas about how to capture debugging output on a laptop (when I'm not home and have no other boxes handy).
I don't want to jump the gun on the analysis but it just might be the packet sharing fixes Herbert put in a short time ago.
What you could do is go back to say rc2 and see if you still get the panics, then bisect from there to narrow it down.
If rc2 still gives the panic, it's something else, perhaps device specific.
Quoted 8 lines
I don't want to jump the gun on the analysis but it just might be the packet sharing fixes Herbert put in a short time ago.
What you could do is go back to say rc2 and see if you still get the panics, then bisect from there to narrow it down.
If rc2 still gives the panic, it's something else, perhaps device specific.
OK thanks. I'm still trying to find a good way to reproduce it, so I'm going to try to get it to happen with -rc9 while running in the console, and at least take a picture of the backtrace. If I find a good way to make it happen then I'll try rc2 and let you know.
- R.
Quoted 3 lines · David Miller
I don't want to jump the gun on the analysis but it just might be the packet sharing fixes Herbert put in a short time ago.
I think the only change of mine that could affect ppp over a serial line is this one. I couldn't see anything obvious in it but maybe someone else can.
Cheers,
Signature · 6 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
2a38b775b77f99308a4e571c13d908df78ac5e57drivers/net/ppp_generic.c +25 -19
@@ -1525,7 +1525,7 @@ ppp_input_error(struct ppp_channel *chan, int code)static void ppp_receive_frame (struct ppp *ppp,struct sk_buff *skb,struct channel *pch) { -if (skb->len >=2 ) { +if (pskb_may_pull (skb,2 )) {#ifdef CONFIG_PPP_MULTILINK /* XXX do channel-level decompression here */ if (PPP_PROTO (skb) ==PPP_MP )
@@ -1577,7 +1577,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)if (ppp->vj ==0 || (ppp->flags &SC_REJ_COMP_TCP )) goto err; -if (skb_tailroom (skb) <124 ) { +if (skb_tailroom (skb) <124 ||skb_cloned (skb)) {/* copy to a new sk_buff with more tailroom */ ns =dev_alloc_skb (skb->len +128 );if (ns ==0 ) {
@@ -1648,23 +1648,29 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)/* check if the packet passes the pass and active filters */ /* the filter instructions are constructed assuming a four-byte PPP header on each packet */ - *skb_push (skb,2 ) =0 ; -if (ppp->pass_filter - &&sk_run_filter (skb, ppp->pass_filter, - ppp->pass_len) ==0 ) { -if (ppp->debug &1 ) -printk (KERN_DEBUG "PPP: inbound frame not passed\n" ); -kfree_skb (skb); -return ; - } -if (!(ppp->active_filter - &&sk_run_filter (skb, ppp->active_filter, - ppp->active_len) ==0 )) - ppp->last_recv = jiffies; -skb_pull (skb,2 ); -#else - ppp->last_recv = jiffies; +if (ppp->pass_filter || ppp->active_filter) { +if (skb_cloned (skb) && +pskb_expand_head (skb,0 ,0 ,GFP_ATOMIC )) + goto err; + + *skb_push (skb,2 ) =0 ; +if (ppp->pass_filter + &&sk_run_filter (skb, ppp->pass_filter, + ppp->pass_len) ==0 ) { +if (ppp->debug &1 ) +printk (KERN_DEBUG "PPP: inbound frame " +"not passed\n" ); +kfree_skb (skb); +return ; + } +if (!(ppp->active_filter + &&sk_run_filter (skb, ppp->active_filter, + ppp->active_len) ==0 )) + ppp->last_recv = jiffies; +__skb_pull (skb,2 ); + } else#endif /* CONFIG_PPP_FILTER */ + ppp->last_recv = jiffies;if ((ppp->dev->flags &IFF_UP ) ==0 || ppp->npmode[npi] !=NPMODE_PASS ) {
@@ -1762,7 +1768,7 @@ ppp_receive_mp_frame(struct ppp *ppp, struct sk_buff *skb, struct channel *pch)struct channel *ch;int mphdrlen = (ppp->flags &SC_MP_SHORTSEQ )?MPHDRLEN_SSN :MPHDRLEN ; -if (!pskb_may_pull (skb, mphdrlen) || ppp->mrru ==0 ) +if (!pskb_may_pull (skb, mphdrlen +1 ) || ppp->mrru ==0 ) goto err;/* no good, throw it away */ /* Decode sequence number and begin/end bits */
Just as a quick update -- I seem to only be able to reproduce this crash when my ppp session drops, which seems associated with marginal signal. And unfortunately I have great coverage at home so I haven't been able to reproduce this again today. Maybe on the train tomorrow I can crash my laptop...
- R.