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. - 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
