On Sun, Feb 06, 2011 at 08:37:21PM +0100, Wolfgang Kufner wrote: > Hi Ivo, > > On Sun, Feb 6, 2011 at 5:17 PM, Ivo Van Doorn <ivdoorn@xxxxxxxxx> wrote: > > Between here and where you added the padding are a couple of function > > calls which use the skb->len field. So this patch would change the value what > > they expect. Have you checked the possible impact? > > I don't think skb_pad() touches skb->len. It writes zeros into the tailroom: Agreed, it doesn't look like skb_pad() affects that field. One point of concern though would be operations that changed the length so that the amount of padding applied was no longer correct. That isn't the case here, but it does make more sense logically that the padding would follow any adjustments to skb->len. My reason for moving it was that if the padding failed at the original location some data would have already been written to the hardware, potentially leaving it in a bad state (at a minimum it looks like beaconing would be left disabled). Maybe a better option would be to leave the padding at the original location and add some cleanup for the failure case. I don't have this hardware and am not familiar with it, but I'd be happy to rework the patch if someone who knows the hardware can advise me on what cleanup should be done. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
