On Mon, Oct 29, 2018 at 8:08 PM Eric Dumazet [off-list ref] wrote:

On 10/29/2018 07:41 PM, Cong Wang wrote:

quoted

On Mon, Oct 29, 2018 at 7:25 PM Eric Dumazet [off-list ref] wrote:

quoted

On 10/29/2018 07:21 PM, Cong Wang wrote:

quoted

On Mon, Oct 29, 2018 at 7:14 PM Eric Dumazet [off-list ref] wrote:

quoted

Would not it be simpler to set ip_summed to CHECKSUM_NONE (no need to save old_csum) ?

For !CHECKSUM_COMPLETE, ip_summed should be untouched, right?

If you mean only setting to CHECKSUM_NONE for CHECKSUM_COMPLETE case,
the end result may not be simpler.

I meant to reinstate what was there before my patch in this error case

       if (skb->ip_summed == CHECKSUM_COMPLETE)
               skb->ip_summed = CHECKSUM_NONE;

That would only be run in error (quite unlikely) path, instead of saving old_csum in all cases.

I know your point, however, I am not sure that is a desired behavior.

On failure, I think the whole skb should be restored to its previous state
before entering this function, changing it to CHECKSUM_NONE on failure
is inconsistent with success case.

Before my patch, we were changing skb->ip_summed to CHECKSUM_NONE,
so why suddenly we need to be consistent ?

That is because setting it to CHECKSUM_NONE _was_ how the success
case works and nothing _was_ needed for failure case.

You changed how we handle checksum for success case, it is why we need
to change for the failure case too.

In any case, ip_check_defrag() should really drop this skb, as for other allocation
failures (like skb_share_check()), if really we want consistency.

I have the same feeling, just not brave enough to change the logic of
ip_check_defrag() where pskb_may_pull() failure is treated in a same way.