[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [PATCH] fix dst_entry leak in icmp_push_reply()
From:       Ollie Wild <aaw () rincewind ! tv>
Date:       2005-08-18 18:45:55
Message-ID: 4304D763.4090001 () rincewind ! tv
[Download RAW message or body]

Ollie Wild wrote:

> Patrick McHardy wrote:
>
>> Your patch doesn't fit your description, the else-condition you're
>> adding triggers when the queue is empty, so what is the point?
>
>
> Since we're only calling ip_append_data() once here, the two 
> conditions are identical.

I should mention that this problem is not academic.  We've run into it 
in the field.  If a lot of ICMP destination unreachable messages are 
generated (by flooding a net_device with bad UDP packets for instance), 
the net_device can no longer be unregistered.

That said, I appreciate that the if-else condition doesn't seem quite 
right.  The problem is, the icmp_push_reply() routine is implicitly 
using the queue as a success indicator.  I put the 
ip_flush_pending_frames() call inside the else block because I wanted to 
guarantee that one of ip_push_pending_frames() and 
ip_flush_pending_frames() is always called.  Both will do proper cleanup.

I'm open to suggestions if you think there's a cleaner way to implement 
this.

Ollie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic