Re: __kfree_skb eventually calls kfree_skb violating dropwatch assumption

On Wed, Oct 12, 2011 at 09:17:56PM -0500, Suresh, Charles wrote:

kfree_skb can be called from __kfree_skb through the following call chain :

kfree_skb  <- skb_drop_list <- skb_drop_fraglist <- skb_release_data <-  skb_release_all <- __kfree_skb (on the 2.38.4 kernel).

This violates the assumption in the dropwatch tool that discarded packets go through the kfree_skb path and all others must go through the consume_skb path (thus resulting in the over-counting of discarded packets in dropwatch).

Neil Horman the author of dropwatch suggested that this could be fixed by skb_drop_list calling consume_skb instead of kfree_skb.

Charles

Acutally, looking closer at this, I think we dont' even really need to change
anything, Once acme is done pushing the changes that enable easier user space
symbol matching, I can just modify the dropwatch perf script and user space tool
to filter traces of kfree_skb that occur from skb_drop_list.  The only two
places that call is used is from pskb_trim and via a call to kfree_skb or
consume_skb.  Neither call should be considered and independent drop event.

Neil