Paul Mackerras wrote :
> Philippe De Muyter writes:
>
> > Actually, that's probably the case I had, but my fix gets the ip adresses
> > 4byte aligned in my case : I had verified the address of the saddr field,
> > and I needed to shift the buffer by 3, not 1, to get it 4byte aligned.
>
> Please outline the code flow that leads to that situation. AFAICS we
> would only need to shift the buffer by 3 if we had a compressed
> (1-byte) protocol number at the original skb->data, implying that the
> protocol byte was first. But if the protocol byte was first, then
> this code:
>
> if (buf[0] != PPP_ALLSTATIONS)
> skb_reserve(skb, 2 + (buf[0] & 1));
>
> at line 893 should have moved skb->data up by 3 bytes already, since a
> 1-byte protocol number is always odd.
>
> If that is not the case then there is something else going on beyond
> the data getting misaligned, and I would like to know what it is.
I just noticed something at the end of process_input_packet :
/* queue the frame to be processed */
skb->cb[0] = ap->state;
skb_queue_tail(&ap->rqueue, skb);
ap->rpkt = 0;
ap->state = 0;
return;
err:
/* frame had an error, remember that, reset SC_TOSS & SC_ESCAPE */
ap->state = SC_PREV_ERROR;
if (skb)
skb_trim(skb, 0);
}
In the normal case, skb is given to the next stage and ap->rpkt is reset,
but in the error case, skb is kept, ap->rpkt is not reset, so we keep
the skb with skb->data aligned for one message and we put another one
into it :)
Could that not be the culprit ?
Philippe
>
> Paul.
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
