netdev - Re: [PATCH] gainfar.c : skb_over

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20100621.134733.115953029.davem@davemloft.net>
Date:	Mon, 21 Jun 2010 13:47:33 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	liberty@...ricom.com
Cc:	galak@...nel.crashing.org, netdev@...r.kernel.org
Subject: Re: [PATCH] gainfar.c : skb_over_panic

From: Eran Liberty <liberty@...ricom.com>
Date: Mon, 21 Jun 2010 12:13:29 +0300

> I have compared the suggested patch with what the function
> skb_recycle_check() does. Both patch and skb_recycle_check()
> have skb_reset_tail_pointer(). While the patch zero only skb->len,
> skb_recycle_check()
> clears the whole skb (up to tail). On top of that skb_recycle_check()
> preforms a whole set of other checks and cleanups. The question is,
> which action is MORE correct: the pin-point action of the patch
> suggested or the broader checks of skb_recycle_check() function?

At this stage in the code we know exactly what modifications, if any,
we've made to the SKB state.  Therefore it makes sense to only fix
up the tiny amount of changes we've made instead of doing a complete
skb_recycle_call() which seems entirely excessive in this situation.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html