* 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
* Re: [PATCH] socket: increase default maximum listen queue length
From: David Miller @ 2011-03-20 4:41 UTC (permalink / raw)
To: hagen; +Cc: netdev, eric.dumazet
In-Reply-To: <1300585811-21566-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Sun, 20 Mar 2011 02:50:11 +0100
> 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.
What in the world is a server running on multi-GHZ cpus doing such
that it cannot accept() fast enough to keep up with a 100 connections
per second?
We were handling that just fine 10+ years ago.
The math simply doesn't add up.
Either your numbers are wrong or the server design is brain-dead.
^ permalink raw reply
* Re: [PATCH] ROSE: prevent heap corruption with bad facilities
From: Dan Rosenberg @ 2011-03-20 6:03 UTC (permalink / raw)
To: ralf; +Cc: davem, netdev, security
In-Reply-To: <1300577313.12507.17.camel@dan>
On Sat, 2011-03-19 at 19:28 -0400, Dan Rosenberg wrote:
> 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.
Please disregard this patch, my brain wasn't working properly when I
wrote it. There are problems in these areas, but this fix is incomplete
(and the description for the first issue is practically nonsensical).
I'll resend a new version shortly.
>
> 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
* [PATCH] niu: Rename NIU parent platform device name to fix conflict.
From: David Miller @ 2011-03-20 6:07 UTC (permalink / raw)
To: grant.likely; +Cc: netdev
When the OF device driver bits were converted over to the platform
device infrastructure in commit 74888760d40b3ac9054f9c5fa07b566c0676ba2d
("dt/net: Eliminate users of of_platform_{,un}register_driver") we
inadvertantly created probing problems in the OF case.
The NIU driver creates a dummy platform device to represent the
board that contains one or more child NIU devices. Unfortunately
we use the same name, "niu", as the OF device driver itself uses.
The result is that we try to probe the dummy "niu" parent device we
create, and since it has a NULL ofdevice pointer etc. everything
explodes:
[783019.128243] niu: niu.c:v1.1 (Apr 22, 2010)
[783019.128810] Unable to handle kernel NULL pointer dereference
[783019.128949] tsk->{mm,active_mm}->context = 000000000000039e
[783019.129078] tsk->{mm,active_mm}->pgd = fffff803afc5a000
[783019.129206] \|/ ____ \|/
[783019.129213] "@'/ .. \`@"
[783019.129220] /_| \__/ |_\
[783019.129226] \__U_/
[783019.129378] modprobe(2004): Oops [#1]
[783019.129423] TSTATE: 0000000011001602 TPC: 0000000010052ff8 TNPC: 000000000061bbb4 Y: 00000000 Not tainted
[783019.129542] TPC: <niu_of_probe+0x3c/0x2dc [niu]>
[783019.129624] g0: 8080000000000000 g1: 0000000000000000 g2: 0000000010056000 g3: 0000000000000002
[783019.129733] g4: fffff803fc1da0c0 g5: fffff800441e2000 g6: fffff803fba84000 g7: 0000000000000000
[783019.129842] o0: fffff803fe7df010 o1: 0000000010055700 o2: 0000000000000000 o3: fffff803fbacaca0
[783019.129951] o4: 0000000000000080 o5: 0000000000777908 sp: fffff803fba866e1 ret_pc: 0000000010052ff4
[783019.130083] RPC: <niu_of_probe+0x38/0x2dc [niu]>
[783019.130165] l0: fffff803fe7df010 l1: fffff803fbacafc0 l2: fffff803fbacaca0 l3: ffffffffffffffed
[783019.130273] l4: 0000000000000000 l5: 000000007fffffff l6: fffff803fba86f40 l7: 0000000000000001
[783019.130382] i0: fffff803fe7df000 i1: fffff803fc20aba0 i2: 0000000000000000 i3: 0000000000000001
[783019.130490] i4: 0000000000000000 i5: 0000000000000000 i6: fffff803fba867a1 i7: 000000000062038c
[783019.130614] I7: <platform_drv_probe+0xc/0x20>
Fix by simply renaming the parent device to "niu-board".
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Grant, I'll push this fix via the net-2.6 tree, you don't have
to worry about it.
drivers/net/niu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index 40fa59e..32678b6 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -9501,7 +9501,7 @@ static struct niu_parent * __devinit niu_new_parent(struct niu *np,
struct niu_parent *p;
int i;
- plat_dev = platform_device_register_simple("niu", niu_parent_index,
+ plat_dev = platform_device_register_simple("niu-board", niu_parent_index,
NULL, 0);
if (IS_ERR(plat_dev))
return NULL;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] ROSE: prevent heap corruption with bad facilities
From: David Miller @ 2011-03-20 6:07 UTC (permalink / raw)
To: drosenberg; +Cc: ralf, netdev, security
In-Reply-To: <1300601004.1869.1.camel@dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Sun, 20 Mar 2011 02:03:24 -0400
> Please disregard this patch, my brain wasn't working properly when I
> wrote it. There are problems in these areas, but this fix is incomplete
> (and the description for the first issue is practically nonsensical).
> I'll resend a new version shortly.
Ok.
^ permalink raw reply
* [PATCH v2] irda: prevent heap corruption on invalid nickname
From: Dan Rosenberg @ 2011-03-20 6:14 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.
v2 also catches the case where the provided nickname is longer than the
buffer size, which can result in controllable heap corruption.
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..2bb2beb 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 || length > NICKNAME_MAX_LEN + 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
* Re: [PATCH] niu: Rename NIU parent platform device name to fix conflict.
From: Grant Likely @ 2011-03-20 6:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110319.230733.193709340.davem@davemloft.net>
On Sun, Mar 20, 2011 at 12:07 AM, David Miller <davem@davemloft.net> wrote:
>
> When the OF device driver bits were converted over to the platform
> device infrastructure in commit 74888760d40b3ac9054f9c5fa07b566c0676ba2d
> ("dt/net: Eliminate users of of_platform_{,un}register_driver") we
> inadvertantly created probing problems in the OF case.
[...]
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> Grant, I'll push this fix via the net-2.6 tree, you don't have
> to worry about it.
Okay, thanks.
g.
>
> drivers/net/niu.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/niu.c b/drivers/net/niu.c
> index 40fa59e..32678b6 100644
> --- a/drivers/net/niu.c
> +++ b/drivers/net/niu.c
> @@ -9501,7 +9501,7 @@ static struct niu_parent * __devinit niu_new_parent(struct niu *np,
> struct niu_parent *p;
> int i;
>
> - plat_dev = platform_device_register_simple("niu", niu_parent_index,
> + plat_dev = platform_device_register_simple("niu-board", niu_parent_index,
> NULL, 0);
> if (IS_ERR(plat_dev))
> return NULL;
> --
> 1.7.4.1
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v2] ROSE: prevent heap corruption with bad facilities
From: Dan Rosenberg @ 2011-03-20 6:43 UTC (permalink / raw)
To: ralf, davem; +Cc: netdev, security
When parsing the FAC_NATIONAL_DIGIS facilities field, it's possible for
a remote host to provide more digipeaters than expected, resulting in
heap corruption. Check against ROSE_MAX_DIGIS to prevent overflows, and
abort facilities parsing on failure.
Additionally, when parsing the FAC_CCITT_DEST_NSAP and
FAC_CCITT_SRC_NSAP facilities fields, a remote host can provide a length
of less than 10, resulting in an underflow in a memcpy size, causing a
kernel panic due to massive heap corruption. A length of greater than
20 results in a stack overflow of the callsign array. Abort facilities
parsing on these invalid length values.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable@kernel.org
---
net/rose/rose_subr.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/rose/rose_subr.c b/net/rose/rose_subr.c
index 1734abb..6f5f0b5 100644
--- a/net/rose/rose_subr.c
+++ b/net/rose/rose_subr.c
@@ -290,10 +290,15 @@ static int rose_parse_national(unsigned char *p, struct rose_facilities_struct *
facilities->source_ndigis = 0;
facilities->dest_ndigis = 0;
for (pt = p + 2, lg = 0 ; lg < l ; pt += AX25_ADDR_LEN, lg += AX25_ADDR_LEN) {
- if (pt[6] & AX25_HBIT)
+ if (pt[6] & AX25_HBIT) {
+ if (facilities->dest_ndigis >= ROSE_MAX_DIGIS)
+ return -1;
memcpy(&facilities->dest_digis[facilities->dest_ndigis++], pt, AX25_ADDR_LEN);
- else
+ } else {
+ if (facilities->source_ndigis >= ROSE_MAX_DIGIS)
+ return -1;
memcpy(&facilities->source_digis[facilities->source_ndigis++], pt, AX25_ADDR_LEN);
+ }
}
}
p += l + 2;
@@ -333,6 +338,11 @@ static int rose_parse_ccitt(unsigned char *p, struct rose_facilities_struct *fac
case 0xC0:
l = p[1];
+
+ /* Prevent overflows*/
+ if (l < 10 || l > 20)
+ return -1;
+
if (*p == FAC_CCITT_DEST_NSAP) {
memcpy(&facilities->source_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
@@ -373,12 +383,16 @@ int rose_parse_facilities(unsigned char *p,
switch (*p) {
case FAC_NATIONAL: /* National */
len = rose_parse_national(p + 1, facilities, facilities_len - 1);
+ if (len < 0)
+ return 0;
facilities_len -= len + 1;
p += len + 1;
break;
case FAC_CCITT: /* CCITT */
len = rose_parse_ccitt(p + 1, facilities, facilities_len - 1);
+ if (len < 0)
+ return 0;
facilities_len -= len + 1;
p += len + 1;
break;
^ permalink raw reply related
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Jerry Chu @ 2011-03-20 7:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1300514604.2831.23.camel@edumazet-laptop>
On Fri, Mar 18, 2011 at 11:03 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Le vendredi 18 mars 2011 à 22:38 -0700, Jerry Chu a écrit :
> > On Fri, Mar 18, 2011 at 10:02 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > Le vendredi 18 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
> > >
> > >> I'm well aware of the past, hideous O(n**2) problem of reading
> > >> /proc/net/tcp but I
> > >> thought the problem has been fixed by Tom Herbert a while back, no?
> > >> (See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
> > >>
> > >
> > > O(N) is still too slow, to gather stats for your socket, if you want to
> > > gather stats once per second for example.
> >
> > I don't see anyway around O(n). The netlink/inet_diag_dump() will take at
> > best O(n) too.
>
> 1) netlink is extensible, without breaking old apps.
>
> 2) netlink is able to dump part of the information, while
> whith /proc/net/tcp you have to cat all the file and grep the needed
> info. O(1) is better than O(10)
>
> Example :
>
> I only want info of socket identified by dst ip 192.168.0.144 and dst
> port 58196
>
> # ss -emoi dst 192.168.20.144:58196
> State Recv-Q Send-Q Local Address:Port Peer Address:Port
> ESTAB 0 0 192.168.20.108:65111 192.168.20.144:58196 ino:3302 sk:ffff88011c278c80
> mem:(r0,w0,f0,t0) sack cubic wscale:7,7 rto:201 rtt:1.75/0.75 cwnd:10 send 66.7Mbps rcv_space:14600
>
> I want all sockets to remote 192.168.20.110
> # ss -emoi dst 192.168.20.110
> State Recv-Q Send-Q Local Address:Port Peer Address:Port
> ESTAB 0 0 ::ffff:192.168.20.108:ssh ::ffff:192.168.20.110:47633 timer:(keepalive,120min,0) ino:70342 sk:ffff88011c381500
> mem:(r0,w0,f0,t0) ts sack ecn cubic wscale:8,7 rto:207 rtt:7.625/11.5 ato:40 cwnd:10 send 15.2Mbps rcv_rtt:1 rcv_space:14480
I presume the filtering of specific IP addrs/ports are done in the
kernel to short-circuit the
O(n) loop. Otherwise it seems moot (i.e., it still costs O(n)).
A quick look at inet_csk_diag_dump() does not reveal anything like
that. But I haven't
looked hard enough.
>
>
> 3) getsockopt(fd) is O(1)
>
> >
> > >
> > > AFAIK, I am not sure we want to allow any user to access all these data
> > > for all tcp sockets on the machine. This might have security impacts.
> >
> > This seems to be an orthogonal issue to netlink or /proc/net/tcp.
>
> getsockopt(fd) only finds information about your own socket.
Make no mistake if my usage case was driven by specific apps why would I
waste my time chasing /proc/net/tcp? In fact we've had a private
TCP_INFO_EXT socket option for years used by some specific apps. (We
have not tried to pushed it upstreams because some of the counters we collect
are too Google specific.)
But my immediate use of the counters/stats proposed here is for our internal
monitor programs to take samples occasionally from ALL CONNECTIONS, or for
diagnosis purpose from the TCP layer when we don't have specific info about the
apps' IP or port# (so we just want to dump info from all connections).
>
> An application might want to log tcp information only right before
> closing one socket. This sounds more practical than having a separate
> spy thread.
I'm not trying to use /proc/net/tcp (or netlink) because I don't know about
other, more efficient way to retrieve counters from a subset, or even just one
specific connection as explained above.
Jerry
>
>
>
^ permalink raw reply
* [PATCH 1/1] solos-pci: Fix debugging to include size, vpi/vci, but omit preamble
From: Philip Prindeville @ 2011-03-20 7:47 UTC (permalink / raw)
To: Netdev; +Cc: linux-atm-general@lists.sourceforge.net
Show the buffer length, vpi, and vci as we do on receive. Use the word "port" instead of "device" consistently.
Don't display the "struct pkt_hdr" preamble on the sk_buff when doing hexdump of frame data.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
---
--- a/drivers/atm/solos-pci.c.orig 2011-03-19 12:19:06.000000000 -0600
+++ b/drivers/atm/solos-pci.c 2011-03-19 12:45:18.000000000 -0600
@@ -697,7 +697,7 @@ void solos_bh(unsigned long card_arg)
size);
}
if (atmdebug) {
- dev_info(&card->dev->dev, "Received: device %d\n", port);
+ dev_info(&card->dev->dev, "Received: port %d\n", port);
dev_info(&card->dev->dev, "size: %d VPI: %d VCI: %d\n",
size, le16_to_cpu(header->vpi),
le16_to_cpu(header->vci));
@@ -1025,8 +1025,15 @@ static uint32_t fpga_tx(struct solos_car
/* Clean up and free oldskb now it's gone */
if (atmdebug) {
+ struct pkt_hdr *header = (void *)oldskb->data;
+ int size = le16_to_cpu(header->size);
+
+ skb_pull(oldskb, sizeof(*header));
dev_info(&card->dev->dev, "Transmitted: port %d\n",
port);
+ dev_info(&card->dev->dev, "size: %d VPI: %d VCI: %d\n",
+ size, le16_to_cpu(header->vpi),
+ le16_to_cpu(header->vci));
print_buffer(oldskb);
}
^ permalink raw reply
* Re: [PATCH] socket: increase default maximum listen queue length
From: Eric Dumazet @ 2011-03-20 8:30 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev
In-Reply-To: <1300585811-21566-1-git-send-email-hagen@jauu.net>
Le dimanche 20 mars 2011 à 02:50 +0100, Hagen Paul Pfeifer a écrit :
> 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
Hmm, real problem is not the 'maximum queue value', but the minimum one.
If application says : listen(fd, 10), you are stuck.
128 or 256 is way too small on some servers, where admin can tune
in /etc/sysctl.conf :
net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 8192
But application also needs to use : listen(fd, 8192)
^ permalink raw reply
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