lkml.org 
[lkml]   [1999]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: triggered 2.2.1 kernel panic in ppp
Date
From
a sun <asun@saul7.u.washington.edu> writes:
> hi all,
>
> i was finally able to trigger a ppp bug that's plagued me sporadically
> and inconsistently. it turns out the following is happening (which
> explains the difficulty in repeating it):
> 1) linux gets a vj compressed packet
> 2) it calls rcv_proto_vjc_comp() (line 2050 in ppp.c)
> 3) for certain packets, slhc_uncompress() returns an
> uncompressed frame < compressed one. as a result,
> skb->len > new_count + PPP_HDRLEN (by 7 bytes)
> 4) pow! skb_put() dies horribly.
>
> before i stick in the obvious patch, i just want to make sure that
> it's valid to have uncompressed packets smaller than the corresponding
> compressed ones.

Yes, no matter what the compression algorithm, there will
always be data blocks which it can't compress at all.
All algorithms will always add some book-keeping stuff of
their own into the resulting datastream, and thus the input
data will be wrapped into such markers -- enlarging it.

I bet you have been moving some compressed data (GZIP,
BZIP2, GIF, JPEG) while that did hit ?

> -a
> asun@u.washington.edu

/Matti Aarnio <matti.aarnio@sonera.fi>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.032 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site