* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Eric Dumazet @ 2011-03-19 15:44 UTC (permalink / raw)
To: Oliver Neukum
Cc: Anca Emanuel, piotr, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <201103191641.41718.oliver@neukum.org>
Le samedi 19 mars 2011 à 16:41 +0100, Oliver Neukum a écrit :
> Thank you. I feel like banging my head against something.
>
Well, it happens, dont worry ;)
^ permalink raw reply
* Re: [PATCHv2 3/9] macb: unify at91 and avr32 platform data
From: Nicolas Ferre @ 2011-03-19 15:49 UTC (permalink / raw)
To: Russell King - ARM Linux, Jamie Iles, Peter Korsgaard,
avictor.za@gmail.com, plagnioj
Cc: linux-arm-kernel, netdev
In-Reply-To: <20110318155428.GA22087@n2100.arm.linux.org.uk>
On 3/18/2011 11:54 PM, Russell King - ARM Linux :
> On Fri, Mar 18, 2011 at 03:48:39PM +0000, Jamie Iles wrote:
>> On Fri, Mar 18, 2011 at 03:41:18PM +0000, Russell King - ARM Linux wrote:
>>> On Thu, Mar 17, 2011 at 09:51:01PM +0000, Jamie Iles wrote:
>>>> On Thu, Mar 17, 2011 at 09:34:03AM +0000, Jamie Iles wrote:
>>>>> Ok, I'll rename to macb_platform_data and update at91_ether to use
>>>>> that with a comment describing that we're sharing the platform data
>>>>> with macb. At least that gets rid of the preprocessor stuff in
>>>>> board.h for at91 too.
>>>>
>>>> So here's the updated patch with changes to the at91_ether driver to
>>>> share the data with macb.
>>>>
>>>> Russell, are you happy to take this series? If so, how would you prefer
>>>> it, in the patch system or as a git pull?
>>>
>>> As Nicolas Ferre is listed in MAINTAINERS as being responsible for the
>>> MACB driver, I think he should at last Ack these patches first.
>>
>> OK, that's absolutely fine with me.
>>
>>> I'm also concious of the fact that Linus complains if my tree contains
>>> changes for drivers/ stuff as well as ARM stuff, so I'm nervous about
>>> taking it as-is. So, I'd rather see drivers stuff separated as much
>>> as possible from the arch updates.
>>
>> I happy to split the driver and arch updates, but I'm not sure that it
>> can be done in such a way that platforms would build between the arch
>> and driver merges.
>>
>>> I'm also concious that this has become ready for potentially merging
>>> during the merge window, and therefore hasn't had previous exposure
>>> in linux-next, and so should wait until the next merge window. I do
>>> feel that I'm going to be yelled at for saying that... but I'm sure
>>> I'll also be yelled at if I did take it.
>>
>> I don't have any problem with waiting until the next merge window, and
>> to be honest I'd like see these patches have some time in next as I
>> can't test them on devices with a MACB.
>
> Okay, that sounds like a very good reason to wait until Nicolas can
> review them and provide an ack.
Be sure that I am silently following this series in the background (too
silently ? ;-) ). I will provide an ack after a last review and testing
but as you have all fruitfully discussed main aspects I am very happy
with the way it is going.
Thanks to all of you, best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 15:52 UTC (permalink / raw)
To: Oliver Neukum
Cc: Eric Dumazet, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <201103191641.41718.oliver@neukum.org>
On 19.03.2011 16:41, Oliver Neukum wrote:
> Am Samstag, 19. März 2011, 16:39:11 schrieben Sie:
>> Le samedi 19 mars 2011 à 16:33 +0100, Eric Dumazet a écrit :
>>> Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
>>>> Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
>>>>
>>>>> Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
>>>>> (r8169: support control of advertising.)
>>>>>
>>>>> Reverting it brings back NIC for me
>>>>
>>>> Odd. It worked for me. Are you testing on a gigabit switch? Could you send
>>>> me dmesg? Does it work if you use ethtool to advertise a lower speed?
>>>>
>>>> Regards
>>>> Oliver
>>>
>>> I found the bug, I am sending a patch in two minutes.
>>>
>>
>> Here it is
>>
>> [PATCH] r8169: fix a bug in rtl8169_init_phy()
>>
>> commit 54405cde7624 (r8169: support control of advertising.)
>> introduced a bug in rtl8169_init_phy()
>
> Thank you. I feel like banging my head against something.
If it will work I will be banging against the wall. I am missing for a
fresh new kernel with networking.
--
Szef TVN24 do dziennikarzy: Kochani, przez dwa lata waliliśmy w obóz
rządzący. Tak dalej byc nie może. Jesteśmy telewizją niezależną i to
zobowiązuje. Teraz będziemy kopać w opozycję.
NP: Big Big Train - Victorian Brickwork
NB: 2.6.38-git3
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Eric Dumazet @ 2011-03-19 16:04 UTC (permalink / raw)
To: piotr
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <4D84D098.1050802@example.com>
Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
> I do not understand. I reverted the commit you mentioned and am building
> now. Will it suffice?
>
Either you
1) Revert the commit
OR
2) apply my patch
;)
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 16:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
On 19.03.2011 16:39, Eric Dumazet wrote:
> Le samedi 19 mars 2011 à 16:33 +0100, Eric Dumazet a écrit :
>> Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
>>> Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
>>>
>>>> Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
>>>> (r8169: support control of advertising.)
>>>>
>>>> Reverting it brings back NIC for me
>>>
>>> Odd. It worked for me. Are you testing on a gigabit switch? Could you send
>>> me dmesg? Does it work if you use ethtool to advertise a lower speed?
>>>
>>> Regards
>>> Oliver
>>
>> I found the bug, I am sending a patch in two minutes.
I do not understand. I reverted the commit you mentioned and am building
now. Will it suffice?
Regards,
Piotr Hosowicz
--
TV: "W tej chwili, że się tak wyrażę, zaliczonych mamy 17 zawodniczek."
NP: Big Big Train - Victorian Brickwork
NB: 2.6.38-git3
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 15:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
On 19.03.2011 16:39, Eric Dumazet wrote:
> Le samedi 19 mars 2011 à 16:33 +0100, Eric Dumazet a écrit :
>> Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
>>> Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
>>>
>>>> Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
>>>> (r8169: support control of advertising.)
>>>>
>>>> Reverting it brings back NIC for me
>>>
>>> Odd. It worked for me. Are you testing on a gigabit switch? Could you send
>>> me dmesg? Does it work if you use ethtool to advertise a lower speed?
>>>
>>> Regards
>>> Oliver
>>
>> I found the bug, I am sending a patch in two minutes.
I do not understand. I reverted the commit you mentioned and am building
now. Will it suffice?
Regards,
Piotr Hosowicz
--
TV: "W tej chwili, że się tak wyrażę, zaliczonych mamy 17 zawodniczek."
NP: Big Big Train - Victorian Brickwork
NB: 2.6.38-git3
^ permalink raw reply
* Re: [PATCH] net: drop NETIF_F_GSO from hw_features without NETIF_F_SG
From: Michał Mirosław @ 2011-03-19 16:18 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev
In-Reply-To: <20110319074653.GA12820@core.hellgate.ch>
2011/3/19 Roger Luethi <rl@hellgate.ch>:
> On Fri, 18 Mar 2011 21:43:23 +0100, Micha? Miros?aw wrote:
>> 2011/3/18 Roger Luethi <rl@hellgate.ch>:
>> > register_netdevice() removes NETIF_F_GSO from dev->features and
>> > dev->wanted_features for hardware without NETIF_F_SG to "avoid warning from
>> > netdev_fix_features()".
>> >
>> > However, as the flag remains set in dev->hw_features, users trying to
>> > enable GSO via ethtool will still end up with NETIF_F_GSO stuck in
>> > wanted_features, resulting in a warning every time they try to change any
>> > feature (until they use ethtool to "disable" GSO):
>>
>> That's expected, as it allows the user to debug why his request didn't
>> work as expected. I think that those messages should get demoted to
>> DEBUG if that's too noisy. The network core imposed conditions could
>> be explained in Documentation/ or ethtool manpage instead.
>
> I agree that it is good to have a note explaining what happened in the
> kernel log, and the patch I posted does not do that; that is easy to fix.
>
> However, I still think the current, unpatched behavior is confusing users.
> ethtool_get_features() will happily tell the user that GSO is available for
> a NIC even if it is not (because the NIC does not support SG). Then, if the
> user tries to enable GSO, the operation fails silently: ethtool won't get
> an error code, so it looks as if the operation succeeded. The user needs to
> look into the kernel log or actually verify the offload settings to realize
> that something went wrong.
Actually, the user will get the information that GSO wasn't enabled,
though not while using ETHTOOL_SGSO.
OTOH, I think I can see what's your point - I got confused by your
proposed patch. The correct way is to remove NETIF_F_GSO from
hw_features when NETIF_F_SG is not present in hw_features (and not
wanted_features as you're patch is doing). The idea here is that a
driver might advertise SG in changeable features (that's hw_features)
but not enable it by default for whatever reason.
Do you want to prepare a patch for this? Please remember about
compatibility with per-offload ethtool ops if you do - this needs to
be there until all drivers are converted to hw_features.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 16:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <1300550653.2831.34.camel@edumazet-laptop>
On 19.03.2011 17:04, Eric Dumazet wrote:
> Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
>
>> I do not understand. I reverted the commit you mentioned and am building
>> now. Will it suffice?
>>
>
> Either you
>
> 1) Revert the commit
OK. This is what I've done and everything is OK, net works as usual. But
what should I do next? Will the revert be done on the GIT server? And
when? I try not to clone to much and wastefuly. And am new to GIT so
sorry for the question.
>
> OR
>
> 2) apply my patch
Regards and thanks,
Piotr Hosowicz
--
Jest jedna korzyść z posiadania TV - jak dobrze
rozregulujesz odbiornik, trafisz na promieniowanie
mikrofalowe z początków Wszechświata.
NP: Big Big Train - Master James Of St George
NB: 2.6.38-20110319-1638-net+
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Anca Emanuel @ 2011-03-19 16:38 UTC (permalink / raw)
To: piotr
Cc: Eric Dumazet, Oliver Neukum, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <4D84D956.8090407@example.com>
On Sat, Mar 19, 2011 at 6:27 PM, Piotr Hosowicz <piotr@hosowicz.com> wrote:
> On 19.03.2011 17:04, Eric Dumazet wrote:
>>
>> Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
>>
>>> I do not understand. I reverted the commit you mentioned and am building
>>> now. Will it suffice?
>>>
>>
>> Either you
>>
>> 1) Revert the commit
>
> OK. This is what I've done and everything is OK, net works as usual. But
> what should I do next? Will the revert be done on the GIT server? And when?
> I try not to clone to much and wastefuly. And am new to GIT so sorry for the
> question.
Next: Test Eric's patch, and send and email with Tested-by tag.
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Eric Dumazet @ 2011-03-19 16:41 UTC (permalink / raw)
To: Anca Emanuel
Cc: piotr, Oliver Neukum, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <AANLkTim9m2A6MXBrx2QHLYNTph9mW9+BUyQpwL5QpjtB@mail.gmail.com>
Le samedi 19 mars 2011 à 18:38 +0200, Anca Emanuel a écrit :
> Next: Test Eric's patch, and send and email with Tested-by tag.
Well, my patch was actually tested on one of my machines ;)
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 17:03 UTC (permalink / raw)
To: Anca Emanuel
Cc: Eric Dumazet, Oliver Neukum, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <AANLkTim9m2A6MXBrx2QHLYNTph9mW9+BUyQpwL5QpjtB@mail.gmail.com>
On 19.03.2011 17:38, Anca Emanuel wrote:
> On Sat, Mar 19, 2011 at 6:27 PM, Piotr Hosowicz<piotr@hosowicz.com> wrote:
>> On 19.03.2011 17:04, Eric Dumazet wrote:
>>>
>>> Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
>>>
>>>> I do not understand. I reverted the commit you mentioned and am building
>>>> now. Will it suffice?
>>>>
>>>
>>> Either you
>>>
>>> 1) Revert the commit
>>
>> OK. This is what I've done and everything is OK, net works as usual. But
>> what should I do next? Will the revert be done on the GIT server? And when?
>> I try not to clone to much and wastefuly. And am new to GIT so sorry for the
>> question.
>
> Next: Test Eric's patch, and send and email with Tested-by tag.
I just built the kernel with the commit reverted as Eric said in the
beginning and it works. Should I build again with patching in place of
reverting and report it? Is the method same as ordinary patching?
Regards,
Piotr Hosowicz
--
Sygnaturka utworzona wyłącznie ze zrecyklingowanych literek
najwyższej jakości poddanych procesowi starannej selekcji.
NP: Big Big Train - The Underfall Yard
NB: 2.6.38-20110319-1638-net+
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Anca Emanuel @ 2011-03-19 17:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, piotr, LKML, netdev, Francois Romieu, David Miller,
Linus Torvalds
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
On Sat, Mar 19, 2011 at 5:39 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le samedi 19 mars 2011 à 16:33 +0100, Eric Dumazet a écrit :
>> Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
>> > Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
>> >
>> > > Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
>> > > (r8169: support control of advertising.)
>> > >
>> > > Reverting it brings back NIC for me
>> >
>> > Odd. It worked for me. Are you testing on a gigabit switch? Could you send
>> > me dmesg? Does it work if you use ethtool to advertise a lower speed?
>> >
>> > Regards
>> > Oliver
>>
>> I found the bug, I am sending a patch in two minutes.
>>
>
> Here it is
>
> [PATCH] r8169: fix a bug in rtl8169_init_phy()
>
> commit 54405cde7624 (r8169: support control of advertising.)
> introduced a bug in rtl8169_init_phy()
>
> Reported-by: Piotr Hosowicz <piotr@hosowicz.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Oliver Neukum <oliver@neukum.org>
> Cc: Francois Romieu <romieu@fr.zoreil.com>
> ---
> drivers/net/r8169.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 5e40351..493b0de 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -2685,9 +2685,9 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
> rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
> ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
> ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
> - tp->mii.supports_gmii ?
> + (tp->mii.supports_gmii ?
> ADVERTISED_1000baseT_Half |
> - ADVERTISED_1000baseT_Full : 0);
> + ADVERTISED_1000baseT_Full : 0));
>
> if (RTL_R8(PHYstatus) & TBI_Enable)
> netif_info(tp, link, dev, "TBI auto-negotiating\n");
>
>
>
Thanks Eric, It Woks now !
My r8169 was not working see:
https://lkml.org/lkml/2011/3/19/19
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 18:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
On 19.03.2011 16:39, Eric Dumazet wrote:
> Le samedi 19 mars 2011 à 16:33 +0100, Eric Dumazet a écrit :
>> Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
>>> Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
>>>
>>>> Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
>>>> (r8169: support control of advertising.)
>>>>
>>>> Reverting it brings back NIC for me
>>>
>>> Odd. It worked for me. Are you testing on a gigabit switch? Could you send
>>> me dmesg? Does it work if you use ethtool to advertise a lower speed?
>>>
>>> Regards
>>> Oliver
>>
>> I found the bug, I am sending a patch in two minutes.
>>
>
> Here it is
>
> [PATCH] r8169: fix a bug in rtl8169_init_phy()
>
> commit 54405cde7624 (r8169: support control of advertising.)
> introduced a bug in rtl8169_init_phy()
>
> Reported-by: Piotr Hosowicz<piotr@hosowicz.com>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> Cc: Oliver Neukum<oliver@neukum.org>
> Cc: Francois Romieu<romieu@fr.zoreil.com>
Tested-by: Piotr Hosowicz<piotr@hosowicz.com>
Works OK now.
Regards,
Piotr Hosowicz
--
Parafrazując Einsteina: w socjaliźmie są dwa zawody z przy-
szłością: piekarz i urzędnik, chociaż co do pierwszego to
nie mam pewności. (by Kubarek, http://blog.kubarek.info/)
NP: Karmakanic - Send a message from the heart
NB: 2.6.38-20110319-1638-net++
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Francois Romieu @ 2011-03-19 19:41 UTC (permalink / raw)
To: Oliver Neukum
Cc: Eric Dumazet, Anca Emanuel, piotr, LKML, netdev, David Miller,
Hayes
In-Reply-To: <201103191641.41718.oliver@neukum.org>
Hayes Cced.
Oliver Neukum <oliver@neukum.org> :
[wrong operator priority fixed by Eric]
> Thank you. I feel like banging my head against something.
Spare your walls : I added the test and I was quite satisfied
after testing ... with an always gigabit capable peer :o/
--
Ueimor
^ permalink raw reply
* Re: [PATCH] bonding: fix a typo in a comment
From: David Miller @ 2011-03-19 20:36 UTC (permalink / raw)
To: nicolas.2p.debian; +Cc: fubar, andy, netdev
In-Reply-To: <1300541467-6133-1-git-send-email-nicolas.2p.debian@free.fr>
From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Date: Sat, 19 Mar 2011 14:31:07 +0100
> Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: David Miller @ 2011-03-19 20:38 UTC (permalink / raw)
To: eric.dumazet
Cc: oliver, anca.emanuel, piotr, linux-kernel, netdev, romieu,
torvalds
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 19 Mar 2011 16:39:11 +0100
> [PATCH] r8169: fix a bug in rtl8169_init_phy()
>
> commit 54405cde7624 (r8169: support control of advertising.)
> introduced a bug in rtl8169_init_phy()
>
> Reported-by: Piotr Hosowicz <piotr@hosowicz.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6, thanks Eric.
Linus, this is definitely the bug you were seeing too.
> Cc: Oliver Neukum <oliver@neukum.org>
> Cc: Francois Romieu <romieu@fr.zoreil.com>
> ---
> drivers/net/r8169.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 5e40351..493b0de 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -2685,9 +2685,9 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
> rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
> ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
> ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
> - tp->mii.supports_gmii ?
> + (tp->mii.supports_gmii ?
> ADVERTISED_1000baseT_Half |
> - ADVERTISED_1000baseT_Full : 0);
> + ADVERTISED_1000baseT_Full : 0));
>
> if (RTL_R8(PHYstatus) & TBI_Enable)
> netif_info(tp, link, dev, "TBI auto-negotiating\n");
>
>
^ permalink raw reply
* Re: [PATCH 2/4] ipv4: fix route deletion for IPs on many subnets
From: Julian Anastasov @ 2011-03-19 21:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110318.215751.108772214.davem@davemloft.net>
Hello,
On Fri, 18 Mar 2011, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Sat, 19 Mar 2011 01:17:01 +0200 (EET)
>
>> + if (ifa->ifa_flags & IFA_F_SECONDARY) {
>> prim = inet_ifa_byprefix(in_dev, any, ifa->ifa_mask);
>> if (prim == NULL) {
>> printk(KERN_WARNING "fib_del_ifaddr: bug: prim == NULL\n");
>> return;
>> }
>> + if (iprim && iprim != prim) {
>> + printk(KERN_WARNING "fib_del_ifaddr: bug: iprim != prim\n");
>> + return;
>> + }
>> + } else if (!ipv4_is_zeronet(any) &&
>> + (any != ifa->ifa_local || ifa->ifa_prefixlen < 32)) {
>> + fib_magic(RTM_DELROUTE,
>> + dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
>> + any, ifa->ifa_prefixlen, prim);
>> + subnet = 1;
>> }
>>
>> /* Deletion is more complicated than add.
>> @@ -755,6 +769,49 @@ static void fib_del_ifaddr(struct in_ifa
> ...
>> + /* Ignore ifa1 if it uses different primary IP (prefsrc) */
>> + if (ifa1->ifa_flags & IFA_F_SECONDARY) {
>> + /* Another address from our subnet? */
> ...
>> + ifa1->ifa_mask != prim1->ifa_mask ||
>> + !inet_ifa_match(ifa1->ifa_address, prim1))
>> + prim1 = inet_ifa_byprefix(in_dev,
>> + ifa1->ifa_address,
>> + ifa1->ifa_mask);
>
> Julian there exists all kinds of incorrect indentation in this patch,
> could you please fix it up?
It seems my mail client problem is not gone.
I'll use a script from now on. Will resend all patches 1-4
as v2 because all are broken.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 2/4] ipv4: fix route deletion for IPs on many subnets
From: David Miller @ 2011-03-19 22:08 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1103192339200.2471@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 19 Mar 2011 23:41:36 +0200 (EET)
> It seems my mail client problem is not gone.
> I'll use a script from now on. Will resend all patches 1-4
> as v2 because all are broken.
Ok, thanks.
^ permalink raw reply
* [PATCH v2 1/4] ipv4: match prefsrc when deleting routes
From: Julian Anastasov @ 2011-03-19 22:13 UTC (permalink / raw)
To: netdev; +Cc: David Miller
fib_table_delete forgets to match the routes by prefsrc.
Callers can specify known IP in fc_prefsrc and we should remove
the exact route. This is needed for cases when same local or
broadcast addresses are used in different subnets and the
routes differ only in prefsrc. All callers that do not provide
fc_prefsrc will ignore the route prefsrc as before and will
delete the first occurence. That is how the ip route del default
magic works.
Current callers are:
- ip_rt_ioctl where rtentry_to_fib_config provides fc_prefsrc only
when the provided device name matches IP label with colon.
- inet_rtm_delroute where RTA_PREFSRC is optional too
- fib_magic which deals with routes when deleting addresses
and where the fc_prefsrc is always set with the primary IP
for the concerned IFA.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/fib_trie.c | 2 ++
1 file changed, 2 insertions(+)
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/fib_trie.c linux/net/ipv4/fib_trie.c
--- net-next-2.6-bef55ae/linux/net/ipv4/fib_trie.c 2011-03-13 01:08:55.000000000 +0200
+++ linux/net/ipv4/fib_trie.c 2011-03-16 09:53:26.824191983 +0200
@@ -1665,6 +1665,8 @@ int fib_table_delete(struct fib_table *t
if ((!cfg->fc_type || fa->fa_type == cfg->fc_type) &&
(cfg->fc_scope == RT_SCOPE_NOWHERE ||
fa->fa_scope == cfg->fc_scope) &&
+ (!cfg->fc_prefsrc ||
+ fi->fib_prefsrc == cfg->fc_prefsrc) &&
(!cfg->fc_protocol ||
fi->fib_protocol == cfg->fc_protocol) &&
fib_nh_match(cfg, fi) == 0) {
^ permalink raw reply
* [PATCH v2 2/4] ipv4: fix route deletion for IPs on many subnets
From: Julian Anastasov @ 2011-03-19 22:13 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Alex Sidorenko reported for problems with local
routes left after IP addresses are deleted. It happens
when same IPs are used in more than one subnet for the
device.
Fix fib_del_ifaddr to restrict the checks for duplicate
local and broadcast addresses only to the IFAs that use
our primary IFA or another primary IFA with same address.
And we expect the prefsrc to be matched when the routes
are deleted because it is possible they to differ only by
prefsrc. This patch prevents local and broadcast routes
to be leaked until their primary IP is deleted finally
from the box.
As the secondary address promotion needs to delete
the routes for all secondaries that used the old primary IFA,
add option to ignore these secondaries from the checks and
to assume they are already deleted, so that we can safely
delete the route while these IFAs are still on the device list.
Reported-by: Alex Sidorenko <alexandre.sidorenko@hp.com>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/net/route.h | 1
net/ipv4/fib_frontend.c | 101 ++++++++++++++++++++++++++++++++++++++++------
2 files changed, 89 insertions(+), 13 deletions(-)
diff -urp net-next-2.6-bef55ae/linux/include/net/route.h linux/include/net/route.h
--- net-next-2.6-bef55ae/linux/include/net/route.h 2011-03-13 01:08:55.000000000 +0200
+++ linux/include/net/route.h 2011-03-16 03:08:36.135967550 +0200
@@ -207,6 +207,7 @@ extern int ip_rt_dump(struct sk_buff *s
struct in_ifaddr;
extern void fib_add_ifaddr(struct in_ifaddr *);
+extern void fib_del_ifaddr(struct in_ifaddr *, struct in_ifaddr *);
static inline void ip_rt_put(struct rtable * rt)
{
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/fib_frontend.c linux/net/ipv4/fib_frontend.c
--- net-next-2.6-bef55ae/linux/net/ipv4/fib_frontend.c 2011-03-13 01:08:55.000000000 +0200
+++ linux/net/ipv4/fib_frontend.c 2011-03-16 03:32:13.816970273 +0200
@@ -722,12 +722,17 @@ void fib_add_ifaddr(struct in_ifaddr *if
}
}
-static void fib_del_ifaddr(struct in_ifaddr *ifa)
+/* Delete primary or secondary address.
+ * Optionally, on secondary address promotion consider the addresses
+ * from subnet iprim as deleted, even if they are in device list.
+ * In this case the secondary ifa can be in device list.
+ */
+void fib_del_ifaddr(struct in_ifaddr *ifa, struct in_ifaddr *iprim)
{
struct in_device *in_dev = ifa->ifa_dev;
struct net_device *dev = in_dev->dev;
struct in_ifaddr *ifa1;
- struct in_ifaddr *prim = ifa;
+ struct in_ifaddr *prim = ifa, *prim1 = NULL;
__be32 brd = ifa->ifa_address | ~ifa->ifa_mask;
__be32 any = ifa->ifa_address & ifa->ifa_mask;
#define LOCAL_OK 1
@@ -735,17 +740,26 @@ static void fib_del_ifaddr(struct in_ifa
#define BRD0_OK 4
#define BRD1_OK 8
unsigned ok = 0;
+ int subnet = 0; /* Primary network */
+ int gone = 1; /* Address is missing */
+ int same_prefsrc = 0; /* Another primary with same IP */
- if (!(ifa->ifa_flags & IFA_F_SECONDARY))
- fib_magic(RTM_DELROUTE,
- dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
- any, ifa->ifa_prefixlen, prim);
- else {
+ if (ifa->ifa_flags & IFA_F_SECONDARY) {
prim = inet_ifa_byprefix(in_dev, any, ifa->ifa_mask);
if (prim == NULL) {
printk(KERN_WARNING "fib_del_ifaddr: bug: prim == NULL\n");
return;
}
+ if (iprim && iprim != prim) {
+ printk(KERN_WARNING "fib_del_ifaddr: bug: iprim != prim\n");
+ return;
+ }
+ } else if (!ipv4_is_zeronet(any) &&
+ (any != ifa->ifa_local || ifa->ifa_prefixlen < 32)) {
+ fib_magic(RTM_DELROUTE,
+ dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
+ any, ifa->ifa_prefixlen, prim);
+ subnet = 1;
}
/* Deletion is more complicated than add.
@@ -755,6 +769,49 @@ static void fib_del_ifaddr(struct in_ifa
*/
for (ifa1 = in_dev->ifa_list; ifa1; ifa1 = ifa1->ifa_next) {
+ if (ifa1 == ifa) {
+ /* promotion, keep the IP */
+ gone = 0;
+ continue;
+ }
+ /* Ignore IFAs from our subnet */
+ if (iprim && ifa1->ifa_mask == iprim->ifa_mask &&
+ inet_ifa_match(ifa1->ifa_address, iprim))
+ continue;
+
+ /* Ignore ifa1 if it uses different primary IP (prefsrc) */
+ if (ifa1->ifa_flags & IFA_F_SECONDARY) {
+ /* Another address from our subnet? */
+ if (ifa1->ifa_mask == prim->ifa_mask &&
+ inet_ifa_match(ifa1->ifa_address, prim))
+ prim1 = prim;
+ else {
+ /* We reached the secondaries, so
+ * same_prefsrc should be determined.
+ */
+ if (!same_prefsrc)
+ continue;
+ /* Search new prim1 if ifa1 is not
+ * using the current prim1
+ */
+ if (!prim1 ||
+ ifa1->ifa_mask != prim1->ifa_mask ||
+ !inet_ifa_match(ifa1->ifa_address, prim1))
+ prim1 = inet_ifa_byprefix(in_dev,
+ ifa1->ifa_address,
+ ifa1->ifa_mask);
+ if (!prim1)
+ continue;
+ if (prim1->ifa_local != prim->ifa_local)
+ continue;
+ }
+ } else {
+ if (prim->ifa_local != ifa1->ifa_local)
+ continue;
+ prim1 = ifa1;
+ if (prim != prim1)
+ same_prefsrc = 1;
+ }
if (ifa->ifa_local == ifa1->ifa_local)
ok |= LOCAL_OK;
if (ifa->ifa_broadcast == ifa1->ifa_broadcast)
@@ -763,19 +820,37 @@ static void fib_del_ifaddr(struct in_ifa
ok |= BRD1_OK;
if (any == ifa1->ifa_broadcast)
ok |= BRD0_OK;
+ /* primary has network specific broadcasts */
+ if (prim1 == ifa1 && ifa1->ifa_prefixlen < 31) {
+ __be32 brd1 = ifa1->ifa_address | ~ifa1->ifa_mask;
+ __be32 any1 = ifa1->ifa_address & ifa1->ifa_mask;
+
+ if (!ipv4_is_zeronet(any1)) {
+ if (ifa->ifa_broadcast == brd1 ||
+ ifa->ifa_broadcast == any1)
+ ok |= BRD_OK;
+ if (brd == brd1 || brd == any1)
+ ok |= BRD1_OK;
+ if (any == brd1 || any == any1)
+ ok |= BRD0_OK;
+ }
+ }
}
if (!(ok & BRD_OK))
fib_magic(RTM_DELROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim);
- if (!(ok & BRD1_OK))
- fib_magic(RTM_DELROUTE, RTN_BROADCAST, brd, 32, prim);
- if (!(ok & BRD0_OK))
- fib_magic(RTM_DELROUTE, RTN_BROADCAST, any, 32, prim);
+ if (subnet && ifa->ifa_prefixlen < 31) {
+ if (!(ok & BRD1_OK))
+ fib_magic(RTM_DELROUTE, RTN_BROADCAST, brd, 32, prim);
+ if (!(ok & BRD0_OK))
+ fib_magic(RTM_DELROUTE, RTN_BROADCAST, any, 32, prim);
+ }
if (!(ok & LOCAL_OK)) {
fib_magic(RTM_DELROUTE, RTN_LOCAL, ifa->ifa_local, 32, prim);
/* Check, that this local address finally disappeared. */
- if (inet_addr_type(dev_net(dev), ifa->ifa_local) != RTN_LOCAL) {
+ if (gone &&
+ inet_addr_type(dev_net(dev), ifa->ifa_local) != RTN_LOCAL) {
/* And the last, but not the least thing.
* We must flush stray FIB entries.
*
@@ -896,7 +971,7 @@ static int fib_inetaddr_event(struct not
rt_cache_flush(dev_net(dev), -1);
break;
case NETDEV_DOWN:
- fib_del_ifaddr(ifa);
+ fib_del_ifaddr(ifa, NULL);
fib_update_nh_saddrs(dev);
if (ifa->ifa_dev->ifa_list == NULL) {
/* Last address was deleted from this interface.
^ permalink raw reply
* [PATCH v2 3/4] ipv4: remove the routes on secondary promotion
From: Julian Anastasov @ 2011-03-19 22:13 UTC (permalink / raw)
To: netdev; +Cc: David Miller
The secondary address promotion relies on fib_sync_down_addr
to remove all routes created for the secondary addresses when
the old primary address is deleted. It does not happen for cases
when the primary address is also in another subnet. Fix that
by deleting local and broadcast routes for all secondaries while
they are on device list and by faking that all addresses from
this subnet are to be deleted. It relies on fib_del_ifaddr being
able to ignore the IPs from the concerned subnet while checking
for duplication.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/devinet.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c
--- net-next-2.6-bef55ae/linux/net/ipv4/devinet.c 2011-03-13 01:08:55.000000000 +0200
+++ linux/net/ipv4/devinet.c 2011-03-16 10:54:42.669192601 +0200
@@ -345,6 +345,17 @@ static void __inet_del_ifa(struct in_dev
}
}
+ /* On promotion all secondaries from subnet are changing
+ * the primary IP, we must remove all their routes silently
+ * and later to add them back with new prefsrc. Do this
+ * while all addresses are on the device list.
+ */
+ for (ifa = promote; ifa; ifa = ifa->ifa_next) {
+ if (ifa1->ifa_mask == ifa->ifa_mask &&
+ inet_ifa_match(ifa1->ifa_address, ifa))
+ fib_del_ifaddr(ifa, ifa1);
+ }
+
/* 2. Unlink it */
*ifap = ifa1->ifa_next;
^ permalink raw reply
* [PATCH v2 4/4] ipv4: optimize route adding on secondary promotion
From: Julian Anastasov @ 2011-03-19 22:13 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Optimize the calling of fib_add_ifaddr for all
secondary addresses after the promoted one to start from
their place, not from the new place of the promoted
secondary. It will save some CPU cycles because we
are sure the promoted secondary was first for the subnet
and all next secondaries do not change their place.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/devinet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c
--- net-next-2.6-bef55ae/linux/net/ipv4/devinet.c 2011-03-18 00:57:39.000000000 +0200
+++ linux/net/ipv4/devinet.c 2011-03-18 10:40:08.135271482 +0200
@@ -375,6 +375,7 @@ static void __inet_del_ifa(struct in_dev
blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
if (promote) {
+ struct in_ifaddr *next_sec = promote->ifa_next;
if (prev_prom) {
prev_prom->ifa_next = promote->ifa_next;
@@ -386,7 +387,7 @@ static void __inet_del_ifa(struct in_dev
rtmsg_ifa(RTM_NEWADDR, promote, nlh, pid);
blocking_notifier_call_chain(&inetaddr_chain,
NETDEV_UP, promote);
- for (ifa = promote->ifa_next; ifa; ifa = ifa->ifa_next) {
+ for (ifa = next_sec; ifa; ifa = ifa->ifa_next) {
if (ifa1->ifa_mask != ifa->ifa_mask ||
!inet_ifa_match(ifa1->ifa_address, ifa))
continue;
^ permalink raw reply
* [PATCH] ROSE: prevent heap corruption with bad facilities
From: Dan Rosenberg @ 2011-03-19 23:28 UTC (permalink / raw)
To: ralf, davem; +Cc: netdev, security
When parsing the FAC_NATIONAL_DIGIS facilities field, keeping the
counter field in an unsigned char is insufficient, since the counter is
incremented by AX25_ADDR_LEN (7) with each loop. Providing a field
length of 0xf, for example, causes heap corruption because the counter
wraps without ever reaching the length and data is copied past the
boundaries of the source_digis or dest_digis facilities arrays. Change
the counter to an unsigned ints to prevent this wrapping and overflow.
Additionally, when parsing the FAC_CCITT_DEST_NSAP and
FAC_CCITT_SRC_NSAP facilities fields, a length of less than 10 results
in an underflow in a memcpy size, resulting in a kernel panic due to
massive heap corruption. Abort facilities parsing on this invalid
length value.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable@kernel.org
---
net/rose/rose_subr.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/net/rose/rose_subr.c b/net/rose/rose_subr.c
index 1734abb..fee9de4 100644
--- a/net/rose/rose_subr.c
+++ b/net/rose/rose_subr.c
@@ -240,7 +240,8 @@ int rose_decode(struct sk_buff *skb, int *ns, int *nr, int *q, int *d, int *m)
static int rose_parse_national(unsigned char *p, struct rose_facilities_struct *facilities, int len)
{
unsigned char *pt;
- unsigned char l, lg, n = 0;
+ unsigned char l, n = 0;
+ unsigned int lg;
int fac_national_digis_received = 0;
do {
@@ -334,12 +335,16 @@ static int rose_parse_ccitt(unsigned char *p, struct rose_facilities_struct *fac
case 0xC0:
l = p[1];
if (*p == FAC_CCITT_DEST_NSAP) {
+ if (l < 10)
+ return -1;
memcpy(&facilities->source_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
callsign[l - 10] = '\0';
asc2ax(&facilities->source_call, callsign);
}
if (*p == FAC_CCITT_SRC_NSAP) {
+ if (l < 10)
+ return -1;
memcpy(&facilities->dest_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
callsign[l - 10] = '\0';
@@ -379,6 +384,11 @@ int rose_parse_facilities(unsigned char *p,
case FAC_CCITT: /* CCITT */
len = rose_parse_ccitt(p + 1, facilities, facilities_len - 1);
+
+ /* Invalid facilities */
+ if (len < 0)
+ return 0;
+
facilities_len -= len + 1;
p += len + 1;
break;
^ permalink raw reply related
* [PATCH] irda: prevent heap corruption on invalid nickname
From: Dan Rosenberg @ 2011-03-20 1:16 UTC (permalink / raw)
To: samuel, davem; +Cc: netdev, security
Invalid nicknames containing only spaces will result in an underflow in
a memcpy size calculation, subsequently destroying the heap and
panicking.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable@kernel.org
---
net/irda/irnet/irnet_ppp.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/irda/irnet/irnet_ppp.c b/net/irda/irnet/irnet_ppp.c
index 7c567b8..881ee51 100644
--- a/net/irda/irnet/irnet_ppp.c
+++ b/net/irda/irnet/irnet_ppp.c
@@ -105,6 +105,9 @@ irnet_ctrl_write(irnet_socket * ap,
while(isspace(start[length - 1]))
length--;
+ DABORT(length < 5, -EINVAL,
+ CTRL_ERROR, "Invalid nickname.\n");
+
/* Copy the name for later reuse */
memcpy(ap->rname, start + 5, length - 5);
ap->rname[length - 5] = '\0';
^ permalink raw reply related
* [PATCH] socket: increase default maximum listen queue length
From: Hagen Paul Pfeifer @ 2011-03-20 1:50 UTC (permalink / raw)
To: netdev; +Cc: Hagen Paul Pfeifer, Eric Dumazet
sysctl_somaxconn (SOMAXCONN: 128) specifies the maximum number of
sockets in state SYN_RECV per listen socket queue. At listen(2) time the
backlog is adjusted to this limit if bigger then that.
Afterwards in reqsk_queue_alloc() the backlog value is checked again
(nr_table_entries == backlog):
nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
nr_table_entries = max_t(u32, nr_table_entries, 8);
nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
sysctl_max_syn_backlog on the other hand is dynamically adjusted,
depending on the memory characteristic of the system. Default is 256,
128 for small systems and up to 1024 for bigger systems.
For real server work the defacto sysctl_somaxconn limit seems inadequate:
Experiments with real servers show, that it is absolutely not enough
even at 100conn/sec. 256 cures most of problems.
Increase default sysctl_somaxconn from 128 to 256 to meet todays condition by
simultaneously limit nr_table_entries by sysctl_max_syn_backlog which is
based on memory condition (max(128, (tcp_hashinfo.ehash_mask + 1 / 256)).
Signed_off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/socket.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index edbb1d0..bf35ce2 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -237,7 +237,7 @@ struct ucred {
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
-#define SOMAXCONN 128
+#define SOMAXCONN 256
/* Flags we can use with send/ and recv.
Added those for 1003.1g not all are supported yet
--
1.7.4.1.57.g0466.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox