From: jamal <[EMAIL PROTECTED]>
Date: Tue, 22 Nov 2005 08:01:07 -0500
> Dave, if (ACK from Brian && no further comments) please apply
> Also, same comment applies as before; this is a bug fix and you may
> wanna consider it as 2.6.15 material.
Applied, thanks everyone.
-
To unsubscribe from this
On Tue, 2005-22-11 at 11:06 -0800, Brian Pomerantz wrote:
> Hmm...I think I must have copied that up to my pirahaven account after
> making that change but I tested without it. I had originally read
> that macro as the same as the IN_DEV_PROMOTE_SECONDARIES but realized
> it wasn't the same prior
On Tue, Nov 22, 2005 at 08:01:07AM -0500, jamal wrote:
>
> Ok, here it is with the change to check the sysctl once.
>
> Brian, can you retest on your side - my basic tests pass.
> If it passes, just respond with an acked-by comment.
>
> Dave, if (ACK from Brian && no further comments) please ap
On Tue, Nov 22, 2005 at 01:46:26PM -0500, jamal wrote:
>
> Hrm - this was not in the patch i posted. Are you sure this passed the
> test?
> What the above does is say we are going to record the last primary only
> if we are _not_ doing promotion. The reverse of what i would expect.
>
Hmm...I thi
On Tue, 2005-22-11 at 10:29 -0800, Brian Pomerantz wrote:
> On Tue, Nov 22, 2005 at 08:01:07AM -0500, jamal wrote:
> >
> > Ok, here it is with the change to check the sysctl once.
> >
> > Brian, can you retest on your side - my basic tests pass.
> > If it passes, just respond with an acked-by co
On Tue, Nov 22, 2005 at 08:01:07AM -0500, jamal wrote:
>
> Ok, here it is with the change to check the sysctl once.
>
> Brian, can you retest on your side - my basic tests pass.
> If it passes, just respond with an acked-by comment.
>
> Dave, if (ACK from Brian && no further comments) please ap
Ok, here it is with the change to check the sysctl once.
Brian, can you retest on your side - my basic tests pass.
If it passes, just respond with an acked-by comment.
Dave, if (ACK from Brian && no further comments) please apply
Also, same comment applies as before; this is a bug fix and you m
On Tue, 2005-22-11 at 05:20 +0100, Patrick McHardy wrote:
> jamal wrote:
> > My point is: it clearly a bigger issue in a lot of places in the net
> > code - almost all ipv4 syctls suffer from this issue then.
>
> Well, you have to check the code that uses them to see if it is
> a problem. In thi
jamal wrote:
On Tue, 2005-22-11 at 04:45 +0100, Patrick McHardy wrote:
jamal wrote:
My point is: it clearly a bigger issue in a lot of places in the net
code - almost all ipv4 syctls suffer from this issue then.
Well, you have to check the code that uses them to see if it is
a problem. In
On Tue, 2005-22-11 at 04:45 +0100, Patrick McHardy wrote:
> jamal wrote:
> >
> > yes, RTNL is one but most of the ones i just inspected are protected
> > under dev_base_lock; so this should be sufficient, no?
>
> You mean other sysctls? I guess it depends on which ones you're
> talking about, bu
jamal wrote:
On Tue, 2005-22-11 at 04:14 +0100, Patrick McHardy wrote:
jamal wrote:
Of course, the underlying assumption is that in fact it could happen.
Could it actually happen? Because if that was the case, a lot of code in
the net area would need to be audited and fixed.
I don't see a
On Tue, 2005-22-11 at 04:14 +0100, Patrick McHardy wrote:
> jamal wrote:
> > Of course, the underlying assumption is that in fact it could happen.
> > Could it actually happen? Because if that was the case, a lot of code in
> > the net area would need to be audited and fixed.
>
> I don't see anyt
jamal wrote:
On Tue, 2005-22-11 at 03:56 +0100, Patrick McHardy wrote:
Yes. promote can only be non-NULL if it was set at the time the first
check was performed. If you check twice and it is changed in between
the secondaries will get neither removed nor promoted. In fact,
the first check insid
On Tue, 2005-22-11 at 03:56 +0100, Patrick McHardy wrote:
> jamal wrote:
>
> > Are you suggesting not to check for IN_DEV_PROMOTE_SECONDARIES the
> > second time?
>
> Yes. promote can only be non-NULL if it was set at the time the first
> check was performed.
> If you check twice and it is chan
jamal wrote:
On Tue, 2005-22-11 at 03:18 +0100, Patrick McHardy wrote:
it still has a different race, IN_DEV_PROMOTE_SECONDARIES can change
between the first and the second check, just checking for
promote != NULL is enough and prevents that race.
Are you suggesting not to check for IN_DE
On Tue, 2005-22-11 at 03:18 +0100, Patrick McHardy wrote:
> it still has a different race, IN_DEV_PROMOTE_SECONDARIES can change
> between the first and the second check, just checking for
> promote != NULL is enough and prevents that race.
Are you suggesting not to check for IN_DEV_PROMOTE_SE
Patrick McHardy wrote:
jamal wrote:
Dave,
This is a bug fix. So not sure if it is fitting for 2.6.15 or not.
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4ec4b2c..495bf22 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -283,18 +289,32 @@ static void inet_del_ifa(stru
jamal wrote:
Dave,
This is a bug fix. So not sure if it is fitting for 2.6.15 or not.
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4ec4b2c..495bf22 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -283,18 +289,32 @@ static void inet_del_ifa(struct in_devic
*/
Dave,
This is a bug fix. So not sure if it is fitting for 2.6.15 or not.
Much thanks to Brian Pomerantz for thorough testing over the weekend and
today.
cheers,
jamal
This patch fixes the problem with promoting aliases when:
a) a single primary and > 1 secondary addresses
b) multiple primary
On Tue, Nov 08, 2005 at 03:11:15PM +0100, Patrick McHardy wrote:
>
> Yes, fixing it correctly looks very hard. Just changing the routes
> doesn't seem right to me, someone might have added it with exactly
> this prefsrc and doesn't want it to change, its also not clear how
> to notify on this. Tak
Thomas Graf wrote:
> * Patrick McHardy <[EMAIL PROTECTED]> 2005-11-08 15:11
>
>>I have a patch to do this, but it needs some debugging, for some
>>unknown reason it crashes sometimes if I remove addresses without
>>specifying the mask.
>
> Interesting, do you use an iproute2 version with the wild
* Patrick McHardy <[EMAIL PROTECTED]> 2005-11-08 15:11
> Yes, fixing it correctly looks very hard. Just changing the routes
> doesn't seem right to me, someone might have added it with exactly
> this prefsrc and doesn't want it to change, its also not clear how
> to notify on this.
Right, OTOH thi
Thomas Graf wrote:
> * Thomas Graf <[EMAIL PROTECTED]> 2005-11-05 14:46
>
>>Assuming this is a separate bug, I'm not sure if this is the right
>>way to fix it. I think it would be better to rewrite the preferred
>>source address of all related local routes and only perform a
>>remove-and-add on th
* Thomas Graf <[EMAIL PROTECTED]> 2005-11-05 14:46
> Assuming this is a separate bug, I'm not sure if this is the right
> way to fix it. I think it would be better to rewrite the preferred
> source address of all related local routes and only perform a
> remove-and-add on the secondary address bein
> > Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_
> > any notification.
>
> Flushes do not generate notifications. The reason is technical: they
> are usually massive, do overflow buffer, get lost and listeners have
> to do painful resynchronization. The justification: they are
Hello!
> Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_
> any notification.
Flushes do not generate notifications. The reason is technical: they
are usually massive, do overflow buffer, get lost and listeners have
to do painful resynchronization. The justification: they are use
* Patrick McHardy <[EMAIL PROTECTED]> 2005-11-05 05:28
> The reason why all routes are deleted is because their prefered
> source addresses is the primary address. fn_flush_list should
> probably send the missing notifications for the deleted routes.
> Changing address promotion to not delete the o
27 matches
Mail list logo
