* [PATCH net-next 1/2] be2net: Modify GPL Marking in all source files.
From: sarveshwar.bandi @ 2013-01-22 8:14 UTC (permalink / raw)
To: davem; +Cc: netdev, Vasundhara Volam, Sarveshwar Bandi
From: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 25 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_cmds.c | 25 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_cmds.h | 25 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_ethtool.c | 25 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_hw.h | 25 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_main.c | 25 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_roce.c | 25 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_roce.h | 25 ++++++++++++++----------
8 files changed, 120 insertions(+), 80 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 4eba17b..f27fe8e 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
#ifndef BE_H
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 8a250c3..d1222a4 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
#include <linux/module.h>
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index d6552e1..9bd9aa5 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
/*
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 76b302f..6ea33a0 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
#include "be.h"
diff --git a/drivers/net/ethernet/emulex/benet/be_hw.h b/drivers/net/ethernet/emulex/benet/be_hw.h
index 541d453..e490f73 100644
--- a/drivers/net/ethernet/emulex/benet/be_hw.h
+++ b/drivers/net/ethernet/emulex/benet/be_hw.h
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
/********* Mailbox door bell *************/
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 5c99570..b1cc3f2 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
#include <linux/prefetch.h>
diff --git a/drivers/net/ethernet/emulex/benet/be_roce.c b/drivers/net/ethernet/emulex/benet/be_roce.c
index 55d32aa..ebc39a9 100644
--- a/drivers/net/ethernet/emulex/benet/be_roce.c
+++ b/drivers/net/ethernet/emulex/benet/be_roce.c
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
#include <linux/mutex.h>
diff --git a/drivers/net/ethernet/emulex/benet/be_roce.h b/drivers/net/ethernet/emulex/benet/be_roce.h
index db4ea80..3b57976 100644
--- a/drivers/net/ethernet/emulex/benet/be_roce.h
+++ b/drivers/net/ethernet/emulex/benet/be_roce.h
@@ -1,18 +1,23 @@
/*
- * Copyright (C) 2005 - 2011 Emulex
- * All rights reserved.
+ * This file is part of the Linux NIC driver for Emulex OneConnect CNA.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation. The full GNU General
- * Public License is included in this distribution in the file called COPYING.
+ * Copyright (C) 2005-2013 Emulex. All rights reserved.
*
- * Contact Information:
+ * EMULEX and SLI are trademarks of Emulex.
+ * www.emulex.com
* linux-drivers@emulex.com
*
- * Emulex
- * 3333 Susan Street
- * Costa Mesa, CA 92626
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
+ * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
*/
#ifndef BE_ROCE_H
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 2/2] be2net: Updating Module Author string and log message string to "Emulex Corporation"
From: sarveshwar.bandi @ 2013-01-22 8:14 UTC (permalink / raw)
To: davem; +Cc: netdev, Sarveshwar Bandi
In-Reply-To: <1358842449-9021-1-git-send-email-sarveshwar.bandi@emulex.com>
From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 8 ++++----
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index f27fe8e..6b3b606 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -41,13 +41,13 @@
#define DRV_VER "4.4.161.0u"
#define DRV_NAME "be2net"
-#define BE_NAME "ServerEngines BladeEngine2 10Gbps NIC"
-#define BE3_NAME "ServerEngines BladeEngine3 10Gbps NIC"
-#define OC_NAME "Emulex OneConnect 10Gbps NIC"
+#define BE_NAME "Emulex BladeEngine2"
+#define BE3_NAME "Emulex BladeEngine3"
+#define OC_NAME "Emulex OneConnect"
#define OC_NAME_BE OC_NAME "(be3)"
#define OC_NAME_LANCER OC_NAME "(Lancer)"
#define OC_NAME_SH OC_NAME "(Skyhawk)"
-#define DRV_DESC "ServerEngines BladeEngine 10Gbps NIC Driver"
+#define DRV_DESC "Emulex OneConnect 10Gbps NIC Driver"
#define BE_VENDOR_ID 0x19a2
#define EMULEX_VENDOR_ID 0x10df
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index b1cc3f2..6718339 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -30,7 +30,7 @@
MODULE_VERSION(DRV_VER);
MODULE_DEVICE_TABLE(pci, be_dev_ids);
MODULE_DESCRIPTION(DRV_DESC " " DRV_VER);
-MODULE_AUTHOR("ServerEngines Corporation");
+MODULE_AUTHOR("Emulex Corporation");
MODULE_LICENSE("GPL");
static unsigned int num_vfs;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: Hannes Frederic Sowa @ 2013-01-22 8:20 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev, davem
In-Reply-To: <50F9F875.30302@linux-ipv6.org>
Hello!
On Sat, Jan 19, 2013 at 10:35:49AM +0900, YOSHIFUJI Hideaki wrote:
> It seems this breaks 6rd receiving rules:
>
> BR:
> if (outer src ip4 != embedded src ip4)
> drop();
Of course, this would break 6rd as would it break 6to4. Note here, that
I also check for the inner ipv6 prefix. This check is only done, if the
inner ipv6 prefix matches a) the 6to4 prefix or b) the 6rd prefix. In 6rd,
as in 6to4, communication between 6rd nodes should take place directly,
without need for a relay. (Otherwise packets would get dropped, because
both source and destination ipv6 address would be in the 6rd/6to4 prefix
and the ipv4 addresses would not match, because one of them would be
the relay address.)
> CE:
> if (outer src ip4 != embedded src ip4 ||
> inner dest ip6 != configured ip6 prefix)
> drop();
Dito, would also break 6to4. Every packet from non-6rd domain would
violate this rule. I do also check the 6rd/6to4 prefix in this case.
In general, if the inner ipv6 address, regardless of source or
destination, does not match the 6rd/6to4 prefix, the packet will pass
without further checks from my patch.
>
> No?
I think that the distinction between BR and CE would make thinks just
more complicated. Also 6rd can be seen as a superset of 6to4 and should
not make any changes to the receiving rules, except being more tight.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH 0/6] ISDN patches for net-next
From: Tilman Schmidt @ 2013-01-22 8:23 UTC (permalink / raw)
To: David Miller; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20130121.173810.2229077237480842007.davem@davemloft.net>
Am 21.01.2013 23:38, schrieb David Miller:
> Patches 1-5 applied to net-next, patch 6 applied to 'net' and queued
> up for -stable.
Thanks.
> We don't have changes bypass 'net' and go into stable from net-next
> like you intended. We also don't use CC: stable for networking
> patches, you ask me to queue them up into my -stable patch queue
> for networking instead.
I see. Is there somewhere I can read up on the workflow for networking
patches and how it fits in with the general plan of things?
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
^ permalink raw reply
* [PATCH net] r8169: remove the obsolete and incorrect AMD workaround
From: Timo Teräs @ 2013-01-22 8:30 UTC (permalink / raw)
To: Francois Romieu, netdev; +Cc: Timo Teräs
In-Reply-To: <20130121234205.GA12449@electric-eye.fr.zoreil.com>
This was introduced in commit 6dccd16 "r8169: merge with version
6.001.00 of Realtek's r8169 driver". I did not find the version
6.001.00 online, but in 6.002.00 or any later r8169 from Realtek
this hunk is no longer present.
Also commit 05af214 "r8169: fix Ethernet Hangup for RTL8110SC
rev d" claims to have fixed this issue otherwise.
The magic compare mask of 0xfffe000 is dubious as it masks
parts of the Reserved part, and parts of the VLAN tag. But this
does not make much sense as the VLAN tag parts are perfectly
valid there. In matter of fact this seems to be triggered with
any VLAN tagged packet as RxVlanTag bit is matched. I would
suspect 0xfffe0000 was intended to test reserved part only.
Finally, this hunk is evil as it can cause more packets to be
handled than what was NAPI quota causing net/core/dev.c:
net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and
mess up the NAPI state causing device to hang.
As result, any system using VLANs and having high receive
traffic (so that NAPI poll budget limits rtl_rx) would result
in device hang.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
---
I decided to suggest just removal without the suggested WARN_ON_ONCE.
This is because the test is incorrect as explained above, and not
present anywhere else either. Oh yeah, and I'm feeling brave today ;)
If acceptable, this should go to -stable too. The hunk was introduced
in v2.6.23-rc1 and the alternate fix went in to v2.6.32-rc6.
drivers/net/ethernet/realtek/r8169.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ed96f30..c28bc31 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6111,13 +6111,6 @@ process_pkt:
tp->rx_stats.bytes += pkt_size;
u64_stats_update_end(&tp->rx_stats.syncp);
}
-
- /* Work around for AMD plateform. */
- if ((desc->opts2 & cpu_to_le32(0xfffe000)) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_05)) {
- desc->opts2 = 0;
- cur_rx++;
- }
}
count = cur_rx - tp->cur_rx;
--
1.8.1
^ permalink raw reply related
* Re: [PATCH 1/2] ipv4: Invalidate the socket cached route on pmtu events if possible
From: Steffen Klassert @ 2013-01-22 8:42 UTC (permalink / raw)
To: Julian Anastasov; +Cc: David Miller, Yurij M. Plotnikov, netdev
In-Reply-To: <alpine.LFD.2.00.1301212245170.1886@ja.ssi.bg>
On Mon, Jan 21, 2013 at 11:18:27PM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 21 Jan 2013, Steffen Klassert wrote:
>
> > +{
> > + const struct iphdr *iph = (const struct iphdr *) skb->data;
> > + struct flowi4 fl4;
> > + struct rtable *rt;
> > + struct dst_entry *dst;
> > +
> > + bh_lock_sock(sk);
> > + rt = (struct rtable *) __sk_dst_get(sk);
>
> I just saw another problem, sorry that
> I missed it the first time. Here __sk_dst_get
> does not get reference...
>
Somehow I thought that I can reuse the the refcount
from the socket, but __sk_dst_set() will release it
when we continue to use the same route.
> > +
> > + if (sock_owned_by_user(sk) || !rt) {
> > + __ipv4_sk_update_pmtu(skb, sk, mtu);
> > + goto out;
> > + }
> > +
> > + __build_flow_key(&fl4, sk, iph, 0, 0, 0, 0, 0);
> > +
> > + if (!__sk_dst_check(sk, 0)) {
> > + rt = ip_route_output_flow(sock_net(sk), &fl4, sk);
> > + if (IS_ERR(rt))
> > + goto out;
>
> but here rt->dst comes with reference.
>
> > + }
>
> May be here we can use 'else dst_hold(&rt->dst);' ?
> It is needed for __sk_dst_set.
>
> > +
> > + __ip_rt_update_pmtu((struct rtable *) rt->dst.path, &fl4, mtu);
> > +
> > + dst = dst_check(&rt->dst, 0);
> > + if (!dst) {
>
> dst_release(&rt->dst);
>
> > + rt = ip_route_output_flow(sock_net(sk), &fl4, sk);
> > + if (IS_ERR(rt))
> > + goto out;
> > +
> > + dst = &rt->dst;
>
> Remove above line...
>
> > + }
> > +
>
> and use here __sk_dst_set(sk, &rt->dst) instead:
>
> > + __sk_dst_set(sk, dst);
>
> Another variant is to remember with flag 'new_rt'
> that we should call __sk_dst_set, eg. when rt comes from
> ip_route_output_flow. By this way we can avoid some of
> the dst_hold/dst_release calls if sk_dst_cache is not
> changed. IIRC, according to sk_dst_check, dst_check can
> not return different dst from the ->check method.
>
With this variant, we also need to check the new_rt flag
before we call the dst_release() function you mentioned
above, right?
I think we should avoid refcounts whenever we can,
so I prefer this variant. I'll do a patch.
Thanks!
^ permalink raw reply
* Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
From: Oliver Neukum @ 2013-01-22 8:50 UTC (permalink / raw)
To: Bjørn Mork
Cc: Alexey Orishko, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Greg Suarez, Alexey Orishko
In-Reply-To: <87ip6qy2q7.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
On Monday 21 January 2013 16:28:48 Bjørn Mork wrote:
> Agreed. But I believe the condition should be
>
> if (!(info->flags & FLAG_SEND_ZLP) && !(info->flags & FLAG_MULTI_PACKET)) {
> ..
> } else {
> urb->transfer_flags |= URB_ZERO_PACKET;
> }
>
> to ensure that we send the ZLP in this case.
Why? If a driver wants ZLP, it can set FLAG_SEND_ZLP. Your proposed change
would take away an option from drivers without any gain.
> > Besides you may want the current behavior.
>
> Why? Does it ever make sense to prevent both the short packet and the
> ZLP?
Why not? It is possible and a driver may want it, so why forbid it?
Especially, as in theory it takes least bandwidth as a solution.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 3/3] net: cdc_ncm: fix error path for single interface probing
From: Oliver Neukum @ 2013-01-22 8:58 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb, Greg Suarez, Alexey Orishko
In-Reply-To: <1358783440-11459-4-git-send-email-bjorn@mork.no>
On Monday 21 January 2013 16:50:40 Bjørn Mork wrote:
> commit bbc8d92 (net: cdc_ncm: add Huawei devices) implemented
> support for devices with a single combined control and data
> interface. Fix up the error path so that we do not double
> release such interfaces in case of probing failures.
Hi Bjørn,
this should go also into stable. Could you submit?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 1/2] ipv4: Invalidate the socket cached route on pmtu events if possible
From: Julian Anastasov @ 2013-01-22 9:04 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, Yurij M. Plotnikov, netdev
In-Reply-To: <20130122084223.GC9147@secunet.com>
Hello,
On Tue, 22 Jan 2013, Steffen Klassert wrote:
> > Another variant is to remember with flag 'new_rt'
> > that we should call __sk_dst_set, eg. when rt comes from
> > ip_route_output_flow. By this way we can avoid some of
> > the dst_hold/dst_release calls if sk_dst_cache is not
> > changed. IIRC, according to sk_dst_check, dst_check can
> > not return different dst from the ->check method.
> >
>
> With this variant, we also need to check the new_rt flag
> before we call the dst_release() function you mentioned
> above, right?
Yes, also before the dst_release we add
after the first ip_route_output_flow.
> I think we should avoid refcounts whenever we can,
> so I prefer this variant. I'll do a patch.
Yes, the flag is preferred because we should
keep sk_dst_cache until we decide to replace it with
__sk_dst_set.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: tap devices not receiving packets from a bridge
From: Peter Lieven @ 2013-01-22 9:04 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Stefan Hajnoczi, qemu-devel, netdev
In-Reply-To: <20121123110146.GC7051@redhat.com>
On 23.11.2012 12:01, Michael S. Tsirkin wrote:
> On Fri, Nov 23, 2012 at 10:41:21AM +0100, Peter Lieven wrote:
>>
>> Am 23.11.2012 um 08:02 schrieb Stefan Hajnoczi:
>>
>>> On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote:
>>>> is anyone aware of a problem with the linux network bridge that in very rare circumstances stops
>>>> a bridge from sending pakets to a tap device?
>>>>
>>>> My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu Kernel 3.2.0-34.53
>>>> which is based on Linux 3.2.33.
>>>>
>>>> I was not yet able to reproduce the issue, it happens in really rare cases. The symptom is that
>>>> the tap does not have any TX packets. RX is working fine. I see the packets coming in at
>>>> the physical interface on the host, but they are not forwarded to the tap interface.
>>>> The bridge itself has learnt the mac address of the vServer that is connected to the tap interface.
>>>> It does not help to toggle the bridge link status, the tap interface status or the interface in the vServer.
>>>> It seems that problem occurs if a tap interface that has previously been used, but set to nonpersistent
>>>> is set persistent again and then is by chance assigned to the same vServer (=same mac address on same
>>>> bridge) again. Unfortunately it seems not to be reproducible.
>>>
>>> Not sure but this patch from Michael Tsirkin may help - it solves an
>>> issue with persistent tap devices:
>>>
>>> http://patchwork.ozlabs.org/patch/198598/
>>
>> Hi Stefan,
>>
>> thanks for the pointer. I have seen this patch, but I have neglected it because it was dealing
>> with persistent taps. But maybe the taps in the kernel are not deleted directly.
>> Can you remember what the syptomps of the above issue have been? Sorry for
>> being vague, but I currently have no clue whats going on.
>>
>> Can someone who has more internal knowledge of the bridging/tap code say if qemu can
>> be responsible at all if the tap device is not receiving packets from the bridge.
>>
>> If I have the following config. Lets say packets coming in via physical interface eth1.123,
>> and a bridge called br123.I further have a virtual machine with tap0. Both eth1.123
>> and tap0 are member of br123.
>>
>> If the issue occurs the vServer has no network connectivity inbound. If I sent a ping
>> from the vServer I see it on tap0 and leaving on eth1.123. I see further the arp reply coming
>> in via eth1.123, but the reply can't be seen on tap0.
>>
>> Peter
>
> If guest is not consuming packets, a TX queue in tap device
> will with time overrun (there's space for 1000 packets there).
> This is code from tun:
>
> if (skb_queue_len(&tfile->socket.sk->sk_receive_queue)
> >= dev->tx_queue_len / tun->numqueues){
> if (!(tun->flags & TUN_ONE_QUEUE)) {
> /* Normal queueing mode. */
> /* Packet scheduler handles dropping of further
> * packets. */
> netif_stop_subqueue(dev, txq);
>
> /* We won't see all dropped packets
> * individually, so overrun
> * error is more appropriate. */
> dev->stats.tx_fifo_errors++;
>
>
> So you can detect that this triggered by looking at fifo errors counter in device.
>
> Once this happens TX queue is stopped, then you hit this path:
>
> if (!netif_xmit_stopped(txq)) {
> __this_cpu_inc(xmit_recursion);
> rc = dev_hard_start_xmit(skb, dev, txq);
> __this_cpu_dec(xmit_recursion);
> if (dev_xmit_complete(rc)) {
> HARD_TX_UNLOCK(dev, txq);
> goto out;
> }
> }
>
> so packets are not passed to device anymore.
> It will stay this way until guest consumes some packets and
> queue is restarted.
After some time I again have a vServer in this state. It seems not like there
are no TX errors.
# ifconfig tap10
tap10 Link encap:Ethernet HWaddr 7a:59:20:6f:e7:e5
inet6 addr: fe80::7859:20ff:fe6f:e7e5/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:197431 errors:0 dropped:0 overruns:0 frame:0
TX packets:264309 errors:0 dropped:0 overruns:2 carrier:0
collisions:0 txqueuelen:500
RX bytes:13842063 (13.8 MB) TX bytes:35092821 (35.0 MB)
It seems like the bridge is not forwarding any packets to the tap device anymore altough it has learnt
the MAC-Adresses and there are also broadcast packets coming in.
Any more ideas where I could debug?
Peter
>
>>>
>>> Stefan
^ permalink raw reply
* pull request: ipsec 2013-01-22
From: Steffen Klassert @ 2013-01-22 9:06 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
1) The transport header did not point to the right place after
esp/ah processing on tunnel mode in the receive path. As a
result, the ECN field of the inner header was not set correctly,
fixes from Li RongQing.
2) We did a null check too late in one of the xfrm_replay advance
functions. This can lead to a division by zero, fix from
Nickolai Zeldovich.
3) The size calculation of the hash table missed the muiltplication
with the actual struct size when the hash table is freed.
We might call the wrong free function, fix from Michal Kubecek.
4) On IPsec pmtu events we can't access the transport headers of
the original packet, so force a relookup for all routes
to notify about the pmtu event.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit c7e2e1d72ed7707239d20525e0ebcad7e3303659:
ipv4: fix NULL checking in devinet_ioctl() (2013-01-06 21:11:18 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master
for you to fetch changes up to 05ab86c55683410593720003442dde629782aaac:
xfrm4: Invalidate all ipv4 routes on IPsec pmtu events (2013-01-21 12:43:54 +0100)
----------------------------------------------------------------
Li RongQing (2):
ah4/esp4: set transport header correctly for IPsec tunnel mode.
ah6/esp6: set transport header correctly for IPsec tunnel mode.
Michal Kubecek (1):
xfrm: fix freed block size calculation in xfrm_policy_fini()
Nickolai Zeldovich (1):
net/xfrm/xfrm_replay: avoid division by zero
Steffen Klassert (1):
xfrm4: Invalidate all ipv4 routes on IPsec pmtu events
net/ipv4/ah4.c | 18 ++++++++++++++----
net/ipv4/esp4.c | 12 +++++++++---
net/ipv4/ipcomp.c | 7 +++++--
net/ipv6/ah6.c | 11 +++++++++--
net/ipv6/esp6.c | 5 ++++-
net/xfrm/xfrm_policy.c | 2 +-
net/xfrm/xfrm_replay.c | 4 +++-
7 files changed, 45 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
From: Oliver Neukum @ 2013-01-22 9:07 UTC (permalink / raw)
To: Alexey ORISHKO
Cc: Bjørn Mork, Alexey Orishko, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, Greg Suarez
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520154A8EE17D8E@EXDCVYMBSTM006.EQ1STM.local>
On Monday 21 January 2013 18:59:05 Alexey ORISHKO wrote:
> Specification says:
> NCM/MBIM shall not send ZLP if buffer size is dwNtbOutMaxSize.
>
> The problem is:
> dwNtbOutMaxSize value is negotiated between host and device NCM/MBIM
> entities and usbnet has no knowledge about it.
>
> Adding one byte to make buffer looking like a short packet was most
> simple approach instead of inventing a way to communicate
> dwNtbOutMaxSize to usbnet.
>
> You could drop short packet approach if dwNtbOutMaxSize is provided
> to usbnet and decision is made accordingly to NCM/MBIM spec (with
> exception to faulty devices).
We could do that. Feel free to send a patch. ;-)
Regards
Oliver
^ permalink raw reply
* [PATCH 1/5] ah4/esp4: set transport header correctly for IPsec tunnel mode.
From: Steffen Klassert @ 2013-01-22 9:06 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1358845596-2066-1-git-send-email-steffen.klassert@secunet.com>
From: Li RongQing <roy.qing.li@gmail.com>
IPsec tunnel does not set ECN field to CE in inner header when
the ECN field in the outer header is CE, and the ECN field in
the inner header is ECT(0) or ECT(1).
The cause is ipip_hdr() does not return the correct address of
inner header since skb->transport-header is not the inner header
after esp_input_done2(), or ah_input().
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/ah4.c | 11 +++++++++--
net/ipv4/esp4.c | 5 ++++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index a0d8392..a154d0a 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -269,7 +269,11 @@ static void ah_input_done(struct crypto_async_request *base, int err)
skb->network_header += ah_hlen;
memcpy(skb_network_header(skb), work_iph, ihl);
__skb_pull(skb, ah_hlen + ihl);
- skb_set_transport_header(skb, -ihl);
+
+ if (x->props.mode == XFRM_MODE_TUNNEL)
+ skb_reset_transport_header(skb);
+ else
+ skb_set_transport_header(skb, -ihl);
out:
kfree(AH_SKB_CB(skb)->tmp);
xfrm_input_resume(skb, err);
@@ -381,7 +385,10 @@ static int ah_input(struct xfrm_state *x, struct sk_buff *skb)
skb->network_header += ah_hlen;
memcpy(skb_network_header(skb), work_iph, ihl);
__skb_pull(skb, ah_hlen + ihl);
- skb_set_transport_header(skb, -ihl);
+ if (x->props.mode == XFRM_MODE_TUNNEL)
+ skb_reset_transport_header(skb);
+ else
+ skb_set_transport_header(skb, -ihl);
err = nexthdr;
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index b61e9de..fd26ff4 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -346,7 +346,10 @@ static int esp_input_done2(struct sk_buff *skb, int err)
pskb_trim(skb, skb->len - alen - padlen - 2);
__skb_pull(skb, hlen);
- skb_set_transport_header(skb, -ihl);
+ if (x->props.mode == XFRM_MODE_TUNNEL)
+ skb_reset_transport_header(skb);
+ else
+ skb_set_transport_header(skb, -ihl);
err = nexthdr[1];
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] ah6/esp6: set transport header correctly for IPsec tunnel mode.
From: Steffen Klassert @ 2013-01-22 9:06 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1358845596-2066-1-git-send-email-steffen.klassert@secunet.com>
From: Li RongQing <roy.qing.li@gmail.com>
IPsec tunnel does not set ECN field to CE in inner header when
the ECN field in the outer header is CE, and the ECN field in
the inner header is ECT(0) or ECT(1).
The cause is ipip6_hdr() does not return the correct address of
inner header since skb->transport-header is not the inner header
after esp6_input_done2(), or ah6_input().
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/ah6.c | 11 +++++++++--
net/ipv6/esp6.c | 5 ++++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index ecc35b9..3842331 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -472,7 +472,10 @@ static void ah6_input_done(struct crypto_async_request *base, int err)
skb->network_header += ah_hlen;
memcpy(skb_network_header(skb), work_iph, hdr_len);
__skb_pull(skb, ah_hlen + hdr_len);
- skb_set_transport_header(skb, -hdr_len);
+ if (x->props.mode == XFRM_MODE_TUNNEL)
+ skb_reset_transport_header(skb);
+ else
+ skb_set_transport_header(skb, -hdr_len);
out:
kfree(AH_SKB_CB(skb)->tmp);
xfrm_input_resume(skb, err);
@@ -593,9 +596,13 @@ static int ah6_input(struct xfrm_state *x, struct sk_buff *skb)
skb->network_header += ah_hlen;
memcpy(skb_network_header(skb), work_iph, hdr_len);
- skb->transport_header = skb->network_header;
__skb_pull(skb, ah_hlen + hdr_len);
+ if (x->props.mode == XFRM_MODE_TUNNEL)
+ skb_reset_transport_header(skb);
+ else
+ skb_set_transport_header(skb, -hdr_len);
+
err = nexthdr;
out_free:
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 282f372..40ffd72 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -300,7 +300,10 @@ static int esp_input_done2(struct sk_buff *skb, int err)
pskb_trim(skb, skb->len - alen - padlen - 2);
__skb_pull(skb, hlen);
- skb_set_transport_header(skb, -hdr_len);
+ if (x->props.mode == XFRM_MODE_TUNNEL)
+ skb_reset_transport_header(skb);
+ else
+ skb_set_transport_header(skb, -hdr_len);
err = nexthdr[1];
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] net/xfrm/xfrm_replay: avoid division by zero
From: Steffen Klassert @ 2013-01-22 9:06 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1358845596-2066-1-git-send-email-steffen.klassert@secunet.com>
From: Nickolai Zeldovich <nickolai@csail.mit.edu>
All of the xfrm_replay->advance functions in xfrm_replay.c check if
x->replay_esn->replay_window is zero (and return if so). However,
one of them, xfrm_replay_advance_bmp(), divides by that value (in the
'%' operator) before doing the check, which can potentially trigger
a divide-by-zero exception. Some compilers will also assume that the
earlier division means the value cannot be zero later, and thus will
eliminate the subsequent zero check as dead code.
This patch moves the division to after the check.
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_replay.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
index 765f6fe..35754cc 100644
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -242,11 +242,13 @@ static void xfrm_replay_advance_bmp(struct xfrm_state *x, __be32 net_seq)
u32 diff;
struct xfrm_replay_state_esn *replay_esn = x->replay_esn;
u32 seq = ntohl(net_seq);
- u32 pos = (replay_esn->seq - 1) % replay_esn->replay_window;
+ u32 pos;
if (!replay_esn->replay_window)
return;
+ pos = (replay_esn->seq - 1) % replay_esn->replay_window;
+
if (seq > replay_esn->seq) {
diff = seq - replay_esn->seq;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] xfrm: fix freed block size calculation in xfrm_policy_fini()
From: Steffen Klassert @ 2013-01-22 9:06 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1358845596-2066-1-git-send-email-steffen.klassert@secunet.com>
From: Michal Kubecek <mkubecek@suse.cz>
Missing multiplication of block size by sizeof(struct hlist_head)
can cause xfrm_hash_free() to be called with wrong second argument
so that kfree() is called on a block allocated with vzalloc() or
__get_free_pages() or free_pages() is called with wrong order when
a namespace with enough policies is removed.
Bug introduced by commit a35f6c5d, i.e. versions >= 2.6.29 are
affected.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 41eabc4..07c5857 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2656,7 +2656,7 @@ static void xfrm_policy_fini(struct net *net)
WARN_ON(!hlist_empty(&net->xfrm.policy_inexact[dir]));
htab = &net->xfrm.policy_bydst[dir];
- sz = (htab->hmask + 1);
+ sz = (htab->hmask + 1) * sizeof(struct hlist_head);
WARN_ON(!hlist_empty(htab->table));
xfrm_hash_free(htab->table, sz);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/5] xfrm4: Invalidate all ipv4 routes on IPsec pmtu events
From: Steffen Klassert @ 2013-01-22 9:06 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1358845596-2066-1-git-send-email-steffen.klassert@secunet.com>
On IPsec pmtu events we can't access the transport headers of
the original packet, so we can't find the socket that sent
the packet. The only chance to notify the socket about the
pmtu change is to force a relookup for all routes. This
patch implenents this for the IPsec protocols.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/ah4.c | 7 +++++--
net/ipv4/esp4.c | 7 +++++--
net/ipv4/ipcomp.c | 7 +++++--
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index a154d0a..a69b4e4 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -420,9 +420,12 @@ static void ah4_err(struct sk_buff *skb, u32 info)
if (!x)
return;
- if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
+ if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH) {
+ atomic_inc(&flow_cache_genid);
+ rt_genid_bump(net);
+
ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_AH, 0);
- else
+ } else
ipv4_redirect(skb, net, 0, 0, IPPROTO_AH, 0);
xfrm_state_put(x);
}
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index fd26ff4..3b4f0cd 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -502,9 +502,12 @@ static void esp4_err(struct sk_buff *skb, u32 info)
if (!x)
return;
- if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
+ if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH) {
+ atomic_inc(&flow_cache_genid);
+ rt_genid_bump(net);
+
ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_ESP, 0);
- else
+ } else
ipv4_redirect(skb, net, 0, 0, IPPROTO_ESP, 0);
xfrm_state_put(x);
}
diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c
index d3ab47e..9a46dae 100644
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -47,9 +47,12 @@ static void ipcomp4_err(struct sk_buff *skb, u32 info)
if (!x)
return;
- if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
+ if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH) {
+ atomic_inc(&flow_cache_genid);
+ rt_genid_bump(net);
+
ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_COMP, 0);
- else
+ } else
ipv4_redirect(skb, net, 0, 0, IPPROTO_COMP, 0);
xfrm_state_put(x);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] Add support for netconsole driver used on bridge device with VIF attached
From: Ian Campbell @ 2013-01-22 9:23 UTC (permalink / raw)
To: yuval.shaia@oracle.com
Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org
In-Reply-To: <50FD8243.6000501@oracle.com>
On Mon, 2013-01-21 at 18:00 +0000, yuval.shaia@oracle.com wrote:
> On 01/21/2013 07:28 PM, Ian Campbell wrote:
> > On Mon, 2013-01-21 at 17:17 +0000, Yuval Shaia wrote:
> >
> >> When starting a VM which has virtual interface attached to the same
> >> bridge (i.e vif = [type=netfront,bridge=xenbr0'] in vm.cfg) which is
> >> used for netconsole the
> >> following message appears (after about 60 seconds) and VM creation
> >> operation fails.
> >> Error: Device 0 (vif) could not be connected. Hotplug scripts not
> >> working.
> > I'm not sure how this can relate netconsole since this happens before
> > the guest even runs, doesn't it?
> Running the same scenario without netconsole runs smoothly.
But why? I can't make sense of your scenario and therefore cannot
explain why this patch would make any difference. Perhaps your patch is
just papering over some other issue?
> >> As i see it, netconsole driver requires ndo_poll_controller from the
> >> device's controlling driver (function __netpoll_setup in
> >> net/core/netpoll.c), a thing that is not supported currently in
> >> xen_netback driver which is the driver that runs on dom0 and serve
> >> VM's virtual interface.
> > Which domain is using netconsole? Is it dom0 or domU? What parameters do
> > you give it?
> dom0.
> parameters: netconsole=1111@src-ip/xenbr0,2002@dst-ip/dst-mac
You give these parameters to dom0 so that dom0's own logs are sent to
some other host?
Are dst-ip and dst-mac a domain on the same host or are they some offbox
logging service?
I can see why the *bridge* device might need an ndo_poll_controller hook
in this setup but I can't see any reason why the netback device would
need one.
> >
> > I assume it is the domU but if that's the case I don't see why a netback
> > rather than netfront patch would be required.
> >
> > Or is dom0 doing netconsole where the log receiver is a domU?
> Log received at dom0 as output of xm cr vm.cfg command.
> netconsole is used on dom0 to monitor its log
Are you now saying that logging goes from domU to dom0? Which is it?
In this scenario there is really no reason I can see that netback would
need an ndo_poll_controller hook -- that would be needed in the domU in
the netfront driver.
Please can you explain the exact code path which results in this new
hook being called.
BTW looking at the patch as it is any use of this hook should be wrapped
in CONFIG_NET_POLL_CONTROLLER.
Ian.
^ permalink raw reply
* RE: [PATCH net-next 11/15] drivers/net: delete old fujitsu based eth16i driver
From: David Laight @ 2013-01-22 9:26 UTC (permalink / raw)
To: Paul Gortmaker, David Miller; +Cc: netdev, Mika Kuoppala
In-Reply-To: <1358819182-28032-12-git-send-email-paul.gortmaker@windriver.com>
If you had an etherteam 16i you really didn't want to be using it!
Of course, ICL used it as the standard ethernet card for
a few years!
Not that I kept any of them.
There was a hardware bug that meant that occaisionally
a receive packet would not be indicated to the host (not even
visible in the fifo) until the following packet arrived.
They would also reject received packets if the PHY signalled
a 'collision' even if the CRC was valid.
Most PHY only correctly detected collisions during transmit.
PHYs that correctly detect collision during RX were only
normally needed for MAC repeaters (which would also need
SQE disabled).
David
^ permalink raw reply
* Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
From: Oliver Neukum @ 2013-01-22 9:32 UTC (permalink / raw)
To: Alexey ORISHKO
Cc: Bjørn Mork, Alexey Orishko, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, Greg Suarez
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520154A8EE17D8E@EXDCVYMBSTM006.EQ1STM.local>
On Monday 21 January 2013 18:59:05 Alexey ORISHKO wrote:
> > > Either the FLAG_MULTI_PACKET minidriver will have already padded the
> > > buffer so that we do not hit (length % dev->maxpacket == 0), or we
> > > should choose one of the alternatives: ZLP or padding.
> >
> > But we cannot simply call __skb_put for a complicated data frame.
> > Besides you may want the current behavior.
> >
>
> Specification says:
> NCM/MBIM shall not send ZLP if buffer size is dwNtbOutMaxSize.
Hi,
one thing on a generic level, which I hope you don't take wrong, but I need
to make it clear. Usbnet is for every driver. What a spec says
or what the reality of implementations of that spec looks like, determine
what usbnet needs to support.
But what is not needed to implement that spec doesn't matter in deciding
what usbnet needs not support. Drivers may or may not need ZLPs.
Regards
Oliver
^ permalink raw reply
* Re: tap devices not receiving packets from a bridge
From: Peter Lieven @ 2013-01-22 9:43 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Stefan Hajnoczi, qemu-devel, netdev
In-Reply-To: <50FE5607.9020405@dlhnet.de>
On 22.01.2013 10:04, Peter Lieven wrote:
> On 23.11.2012 12:01, Michael S. Tsirkin wrote:
>> On Fri, Nov 23, 2012 at 10:41:21AM +0100, Peter Lieven wrote:
>>>
>>> Am 23.11.2012 um 08:02 schrieb Stefan Hajnoczi:
>>>
>>>> On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote:
>>>>> is anyone aware of a problem with the linux network bridge that in very rare circumstances stops
>>>>> a bridge from sending pakets to a tap device?
>>>>>
>>>>> My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu Kernel 3.2.0-34.53
>>>>> which is based on Linux 3.2.33.
>>>>>
>>>>> I was not yet able to reproduce the issue, it happens in really rare cases. The symptom is that
>>>>> the tap does not have any TX packets. RX is working fine. I see the packets coming in at
>>>>> the physical interface on the host, but they are not forwarded to the tap interface.
>>>>> The bridge itself has learnt the mac address of the vServer that is connected to the tap interface.
>>>>> It does not help to toggle the bridge link status, the tap interface status or the interface in the vServer.
>>>>> It seems that problem occurs if a tap interface that has previously been used, but set to nonpersistent
>>>>> is set persistent again and then is by chance assigned to the same vServer (=same mac address on same
>>>>> bridge) again. Unfortunately it seems not to be reproducible.
>>>>
>>>> Not sure but this patch from Michael Tsirkin may help - it solves an
>>>> issue with persistent tap devices:
>>>>
>>>> http://patchwork.ozlabs.org/patch/198598/
>>>
>>> Hi Stefan,
>>>
>>> thanks for the pointer. I have seen this patch, but I have neglected it because it was dealing
>>> with persistent taps. But maybe the taps in the kernel are not deleted directly.
>>> Can you remember what the syptomps of the above issue have been? Sorry for
>>> being vague, but I currently have no clue whats going on.
>>>
>>> Can someone who has more internal knowledge of the bridging/tap code say if qemu can
>>> be responsible at all if the tap device is not receiving packets from the bridge.
>>>
>>> If I have the following config. Lets say packets coming in via physical interface eth1.123,
>>> and a bridge called br123.I further have a virtual machine with tap0. Both eth1.123
>>> and tap0 are member of br123.
>>>
>>> If the issue occurs the vServer has no network connectivity inbound. If I sent a ping
>>> from the vServer I see it on tap0 and leaving on eth1.123. I see further the arp reply coming
>>> in via eth1.123, but the reply can't be seen on tap0.
>>>
>>> Peter
>>
>> If guest is not consuming packets, a TX queue in tap device
>> will with time overrun (there's space for 1000 packets there).
>> This is code from tun:
>>
>> if (skb_queue_len(&tfile->socket.sk->sk_receive_queue)
>> >= dev->tx_queue_len / tun->numqueues){
>> if (!(tun->flags & TUN_ONE_QUEUE)) {
>> /* Normal queueing mode. */
>> /* Packet scheduler handles dropping of further
>> * packets. */
>> netif_stop_subqueue(dev, txq);
>>
>> /* We won't see all dropped packets
>> * individually, so overrun
>> * error is more appropriate. */
>> dev->stats.tx_fifo_errors++;
>>
>>
>> So you can detect that this triggered by looking at fifo errors counter in device.
>>
>> Once this happens TX queue is stopped, then you hit this path:
>>
>> if (!netif_xmit_stopped(txq)) {
>> __this_cpu_inc(xmit_recursion);
>> rc = dev_hard_start_xmit(skb, dev, txq);
>> __this_cpu_dec(xmit_recursion);
>> if (dev_xmit_complete(rc)) {
>> HARD_TX_UNLOCK(dev, txq);
>> goto out;
>> }
>> }
>>
>> so packets are not passed to device anymore.
>> It will stay this way until guest consumes some packets and
>> queue is restarted.
>
> After some time I again have a vServer in this state. It seems not like there
> are no TX errors.
>
> # ifconfig tap10
> tap10 Link encap:Ethernet HWaddr 7a:59:20:6f:e7:e5
> inet6 addr: fe80::7859:20ff:fe6f:e7e5/64 Scope:Link
> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
> RX packets:197431 errors:0 dropped:0 overruns:0 frame:0
> TX packets:264309 errors:0 dropped:0 overruns:2 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:13842063 (13.8 MB) TX bytes:35092821 (35.0 MB)
>
> It seems like the bridge is not forwarding any packets to the tap device anymore altough it has learnt
> the MAC-Adresses and there are also broadcast packets coming in.
>
> Any more ideas where I could debug?
Would like to add I see the packets in ebtables forwarding chain, but the TX counters
of the interface are not increasing.
Peter
>
> Peter
>
>>
>>>>
>>>> Stefan
>
^ permalink raw reply
* RE: [PATCH RFC net-next 00/15] drivers/net: obsolete ISA driver round-up
From: David Laight @ 2013-01-22 9:46 UTC (permalink / raw)
To: Paul Gortmaker, David Miller
Cc: netdev, Donald Becker, Jeff Kirsher, Alan Cox, Andreas Mohr,
Jan-Pascal van Best, Mika Kuoppala
In-Reply-To: <1358819182-28032-1-git-send-email-paul.gortmaker@windriver.com>
ICL did ship a lot of 8bit ISA ethernet cards with the intel
chipset (might have been sourced from a 3rd party) - clearly
the hardware engineers built the cards without asking the
software guys about which chips were easy to drive.
The amd lance chips were easy (even allowing for some
little errata [1]), the intel one a real PITA.
Fortunately I never had to fix the Intel driver, largely
because I was doing the drivers for sparc systems.
But yes, on a 386/486 none of the PIO based 8-bit ethernet
cards could get anywhere near saturating a 10M LAN.
(Well, maybe just, and with full sized packets.)
Put the cards in a PCI system and it is actually worse.
Not only that, but while doing the slow ISA io the
cpu is spinning - so you really, really wanted a PCI
ethernet card.
So the only systems where you would be running an ISA
ethernet card are old 486 ones (not to be confused
with some new embedded 486 cpu).
So even the later ISA-pnp cards are of limited use.
Trying to use something based on the amd pcnet-isa
(lance on a card) is also fraught - as you need to
get one of the motherboard dma channels into
'cascade mode' - often not supported by the OS.
(And you'll probably fail to run the bloated board
EEPROM config tool as well.)
All best dead and buried!
David
[1] It really didn't like bus cycles terminating anywhere
near the 256 clocks cycle timeout.
^ permalink raw reply
* Re: [PATCH net 2/3] net: cdc_mbim: send ZLP after max sized NTBs
From: Bjørn Mork @ 2013-01-22 9:54 UTC (permalink / raw)
To: Alexey ORISHKO
Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org, Greg Suarez,
Oliver Neukum, Alexey Orishko
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520154A8EE17D57-8ZTw5gFVCTjVH5byLeRTJxkTb7+GphCuwzqs5ZKRSiY@public.gmane.org>
Alexey ORISHKO <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org> writes:
> If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU
> load, increasing interrupt load by factor of 2 in high load traffic
> scenario and possibly decreasing throughput for all other devices
> which behaves correctly.
Hello Alexey,
Still trying to understand the mechanisms involved here. I must
apologize for my lack of knowledge of the hardware restrictions
involved.
The current cdc_ncm/cdc_mbim drivers will pad a NTB to the full
dwNtbOutMaxSize whenever it reaches at least 512 bytes. The reason is
that this allows more efficient device DMA operation. This is something
we do to adapt to device hardware restrictions even though there is no
such recommendations in the NCM/MBIM specs. The penalty on the host and
bus should be obvious: Even with a quite small dwNtbOutMaxSize of 4096,
we end up sending 8 x 512-byte data packets instead of the 2 we could
have managed with.
Now you claim that sending 9 packets, where the last one is a zero
length packet, increaes the interrupt load by factor of 2? How is that?
This is where my lack of hardware knowledge shows up, but I assumed
based on the device DMA argument that the device USB engine would do the
actual packet reception and assembly and DMA the complete 4096-byte data
transfer to the device memory. Won't the device USB engine also handle
the ZLP? Won't it just collect 9 packets instead of 8 and assemble them
to the 4096-byte data transfer which is DMAed away the same way it would
if there were just 8 packets in the transfer? The only differences
being that the ZLP variant works even if the device stack for some
reason requests more than dwNtbOutMaxSize bytes (which of course could
be claimed to be stupid, but the spec allows it), and of course that we
waste even more USB bus bandwidth. But if USB bandwidth is a factor we
consider here then I am going to question the padding to dwNtbOutMaxSize
based on some devices having DMA restrictions making that more efficient.
Why is the device DMA restrictions not a fault, while the device ZLP
requirement is? Both seem like reasonable device hardware/firmware
implementation imposed restrictions to me. Something we'll just have to
accept.
Note that the problem with the ZLP on the Sierra devices is made much
worse than necessary by the padding. Without this we would rarely have
hit the dwNtbOutMaxSize limit, and would have been able to work around
it by simply using tx_max = dwNtbOutMaxSize - 1 if
(dwNtbOutMaxSize % wMaxPacketSize == 0).
Maybe that is what Windows does?
But we cannot do that due to other devices having issues with transfers
less than dwNtbOutMaxSize..
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ipv4: Fix route refcount on pmtu discovery
From: Steffen Klassert @ 2013-01-22 10:01 UTC (permalink / raw)
To: David Miller; +Cc: Julian Anastasov, netdev
git commit 9cb3a50c (ipv4: Invalidate the socket cached route on
pmtu events if possible) introduced a refcount problem. We don't
get a refcount on the route if we get it from__sk_dst_get(), but
we need one if we want to reuse this route because __sk_dst_set()
releases the refcount of the old route. This patch adds proper
refcount handling for that case. We introduce a 'new' flag to
indicate that we are going to use a new route and we release the
old route only if we replace it by a new one.
Reported-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/route.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 132737a..a0fcc47 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -985,6 +985,7 @@ void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu)
struct flowi4 fl4;
struct rtable *rt;
struct dst_entry *dst;
+ bool new = false;
bh_lock_sock(sk);
rt = (struct rtable *) __sk_dst_get(sk);
@@ -1000,20 +1001,26 @@ void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu)
rt = ip_route_output_flow(sock_net(sk), &fl4, sk);
if (IS_ERR(rt))
goto out;
+
+ new = true;
}
__ip_rt_update_pmtu((struct rtable *) rt->dst.path, &fl4, mtu);
dst = dst_check(&rt->dst, 0);
if (!dst) {
+ if (new)
+ dst_release(&rt->dst);
+
rt = ip_route_output_flow(sock_net(sk), &fl4, sk);
if (IS_ERR(rt))
goto out;
- dst = &rt->dst;
+ new = true;
}
- __sk_dst_set(sk, dst);
+ if (new)
+ __sk_dst_set(sk, &rt->dst);
out:
bh_unlock_sock(sk);
--
1.7.9.5
^ permalink raw reply related
* Re: [BUG] Bug in netprio_cgroup and netcls_cgroup ?
From: Daniel Wagner @ 2013-01-22 10:09 UTC (permalink / raw)
To: John Fastabend
Cc: Li Zefan, John Fastabend, Neil Horman, Daniel Wagner, LKML,
netdev-u79uwXL29TY76Z2rM5mHXA, Cgroups
In-Reply-To: <50FD786E.4050108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Jan 21, 2013 at 09:18:38AM -0800, John Fastabend wrote:
> On 01/21/2013 01:57 AM, Li Zefan wrote:
> > On 2013/1/21 17:27, Daniel Wagner wrote:
> >> On 21.01.2013 10:01, Li Zefan wrote:
> >>> On 2013/1/21 16:50, Daniel Wagner wrote:
> >>>> Hi Li,
> >>>>
> >>>> On 21.01.2013 07:08, Li Zefan wrote:
> >>>>> I'm not a network developer, so correct me if I'm wrong.
> >>>>>
> >>>>> Since commit 7955490f732c2b8
> >>>>> ("net: netprio_cgroup: rework update socket logic"), sock->sk->sk_cgrp_prioidx
> >>>>> is set when the socket is created, and won't be updated unless the task is
> >>>>> moved to another cgroup.
> >>>>>
> >>>>> Now the problem is, a socket can be _shared_ by multiple processes (fork, SCM_RIGHT).
> >>>>> If we place those processes in different cgroups, and each cgroup has
> >>>>> different configs, but all of the processes will send data via this socket
> >>>>> with the same network priority.
> >>>>
> >>>> Wouldn't that be addressed by 48a87cc26c13b68f6cce4e9d769fcb17a6b3e4b8
> >>>>
> >>>> net: netprio: fd passed in SCM_RIGHTS datagram not set correctly
> >>>>
> >>>> A socket fd passed in a SCM_RIGHTS datagram was not getting
> >>>> updated with the new tasks cgrp prioidx. This leaves IO on
> >>>> the socket tagged with the old tasks priority.
> >>>>
> >>>> To fix this add a check in the scm recvmsg path to update the
> >>>> sock cgrp prioidx with the new tasks value.
> >>>>
> >>>> As I read this this should work for net_prio.
> >>>>
> >>>
> >>> But after process A passed the socket fd to B, both A and B can use the
> >>> same socket to send data, right? Then if A and B were placed in different
> >>> cgroups with differnt configs, A's config won't take effect anymore.
> >>>
> >>> Am I missing something?
> >>
> >> I don't know. I guess at one point the socket resources are shared and then
> >> one configuration is taking preference. As you can see I am far away of
> >> being
> >> an expert in this field. Hopefully someone who understands this bits
> >> can chip in.
> >>
> >> BTW, isn't this a similar to what should happen with the block io cgroup?
> >> What is the behavior with a fd writing to a file in the scenario you
> >> describe above?
> >>
> >
> > It forbids task moving in this case:
> >
> > /*
> > * We cannot support shared io contexts, as we have no mean to support
> > * two tasks with the same ioc in two different groups without major rework
> > * of the main cic data structures. For now we allow a task to change
> > * its cgroup only if it's the only owner of its ioc.
> > */
> > static int blkcg_can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
> >
>
> OK, I guess we should do something similar in the netprio, netcls
> cgroups and
> yes document it as you noted in your last comment.
Here is my attempt to add such a check. I really don't know if this is the
correct way to do so. To test this I have written a test program, which
seems to test the right thing. Please have a look and let me know if
it is correct: http://www.monom.org/misc/scm_rights.c
And here a dirty first version of the patch:
>From 49a78d907eaf31c16673025e7e3b4844e419e416 Mon Sep 17 00:00:00 2001
From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
Date: Tue, 22 Jan 2013 11:08:22 +0100
Subject: [PATCH] net: net_prio: Block attach if a socket is shared
---
net/core/netprio_cgroup.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 847c02b..de4e6c5 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -274,9 +274,39 @@ static struct cftype ss_files[] = {
{ } /* terminate */
};
+static int check_cnt(const void *v, struct file *file, unsigned n)
+{
+ unsigned *flag = (unsigned *)v;
+ int err;
+
+ struct socket *sock = sock_from_file(file, &err);
+ if (sock && file_count(file) > 1)
+ *flag = 1;
+
+ return 0;
+}
+
+static int cgrp_can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
+{
+ struct task_struct *p;
+ unsigned flag = 0;
+
+ cgroup_taskset_for_each(p, cgrp, tset) {
+ task_lock(p);
+ iterate_fd(p->files, 0, check_cnt, &flag);
+ task_unlock(p);
+ }
+
+ if (flag != 0)
+ return -EINVAL;
+
+ return 0;
+}
+
struct cgroup_subsys net_prio_subsys = {
.name = "net_prio",
.create = cgrp_create,
+ .can_attach = cgrp_can_attach,
.destroy = cgrp_destroy,
.attach = net_prio_attach,
.subsys_id = net_prio_subsys_id,
--
1.8.0.rc0
^ 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