Re: BUG: warning at net/core/dev.c:1171/skb_checksum_help() 2.6.18-rc3

[Patrick McHardy <kaber@trash.net>]

David Miller wrote:
> I noticed a subtle semantic change for nf_queue().  Previously, if we
> can't grab the module reference for the matching entry, we'd not free
> the skb, return 0, and the caller tries to iterate to the next hook.
> 
> That behavior is preserved for singleton frames, but that's not what
> happens for GSO frames.  Instead, the GSO frame is split up and we
> always return "1" even if some of the subsegments cause __nf_queue()
> to return 0 due to the case described in the previous paragraph.

I couldn't think of a better way to handle this except to just deliver
everything we can and drop the rest, since the caller doesn't know
anything about the individual segments we can't simply deliver the
remaining ones to the next hook.

> It is, however, mindful to free up the kfree_skb so it doesn't cause a
> leak or anything like that.
> 
> Does this matter?

I don't think it does. Its a huge corner case (unloading of the
module which issued the QUEUE verdict while queueing the packet),
and worst case is that we drop some segments or the entire packet.