* Re: [PATCH 0/3] smsc75xx: more minor fixes
From: David Miller @ 2012-05-08 3:44 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1336129033-15826-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Fri, 4 May 2012 11:57:10 +0100
> 3 more minor patches for smsc75xx
>
> Steve Glendinning (3):
> smsc75xx: replace 0xffff with PHY_INT_SRC_CLEAR_ALL
> smsc75xx: eliminate unnecessary phy register read
> smsc75xx: let EEPROM determine GPIO/LED settings
All applied to net-next. Please be specific in the future about where
you want patches applied, these wouldn't apply cleanly until I merged
'net' into 'net-next' to propagate recent bug fixes first.
^ permalink raw reply
* [README] net --> net-next merge
From: David Miller @ 2012-05-08 3:41 UTC (permalink / raw)
To: netdev; +Cc: sfr, linville, jeffrey.t.kirsher
I just merged net into net-next, there were two major conflicts.
1) The known iwlwifi conflict due to the skb->truesize bug fix in
'net'.
I used the conflict resolution posted by John and later by Stephen
when he resolved it for -next.
John, please double-check my work.
2) drivers/net/ethernet/intel/e1000e/param.c got a conflict in
the code which validates adapter->itr settings.
The net-next side looked more sophisticated so that's what I
used.
Jeff, please double-check and send me fixup patches if necessary.
Thanks.
^ permalink raw reply
* Re: [PATCH RESEND 2/5] net: fec: adopt pinctrl support
From: Dong Aisheng @ 2012-05-08 3:44 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel, Arnd Bergmann, netdev, Sascha Hauer,
Olof Johansson, Dong Aisheng, David S. Miller
In-Reply-To: <1336352040-28447-3-git-send-email-shawn.guo@linaro.org>
On Mon, May 07, 2012 at 08:53:57AM +0800, Shawn Guo wrote:
> Cc: netdev@vger.kernel.org
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
Regards
Dong Aisheng
^ permalink raw reply
* Re: [PATCH 13/25] ipvs: remove check for IP_VS_CONN_F_SYNC from ip_vs_bind_dest
From: Simon Horman @ 2012-05-08 3:15 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20120507.221617.296952751857969791.davem@davemloft.net>
On Mon, May 07, 2012 at 10:16:17PM -0400, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Tue, 8 May 2012 11:08:44 +0900
>
> > can I fix this up as a subsequent patch?
>
> Pablo's tree needs to get respun to address the other feedback
> I gave, so no reason for him or you to not fix this as well.
Understood.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the ceph tree
From: Stephen Rothwell @ 2012-05-08 3:09 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Eric Dumazet, Sage Weil, Sage Weil
[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/ceph/osdmap.c between commit 8b3932690084 ("crush: warn on do_rule
failure") from the ceph tree and commit 95c961747284 ("net: cleanup
unsigned to unsigned int") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/ceph/osdmap.c
index 2592f3c,56e561a..0000000
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@@ -991,11 -998,12 +991,11 @@@ int ceph_calc_object_layout(struct ceph
struct ceph_file_layout *fl,
struct ceph_osdmap *osdmap)
{
- unsigned num, num_mask;
+ unsigned int num, num_mask;
struct ceph_pg pgid;
- s32 preferred = (s32)le32_to_cpu(fl->fl_pg_preferred);
int poolid = le32_to_cpu(fl->fl_pg_pool);
struct ceph_pg_pool_info *pool;
- unsigned ps;
+ unsigned int ps;
BUG_ON(!osdmap);
@@@ -1027,7 -1045,8 +1027,7 @@@ static int *calc_pg_raw(struct ceph_osd
struct ceph_pg_mapping *pg;
struct ceph_pg_pool_info *pool;
int ruleno;
- unsigned poolid, ps, pps, t, r;
- unsigned int poolid, ps, pps, t;
- int preferred;
++ unsigned int poolid, ps, pps, t, r;
poolid = le32_to_cpu(pgid.pool);
ps = le16_to_cpu(pgid.ps);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PULL net-next] macvtap, vhost and virtio tools updates
From: David Miller @ 2012-05-08 3:06 UTC (permalink / raw)
To: mst; +Cc: netdev, kvm, jasowang
In-Reply-To: <20120507205537.GA27950@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 7 May 2012 23:55:39 +0300
> There are mostly bugfixes here.
> I hope to merge some more patches by 3.5, in particular
> vlan support fixes are waiting for Eric's ack,
> and a version of tracepoint patch might be
> ready in time, but let's merge what's ready so it's testable.
>
> This includes a ton of zerocopy fixes by Jason -
> good stuff but too intrusive for 3.4 and zerocopy is experimental
> anyway.
>
> virtio supported delayed interrupt for a while now
> so adding support to the virtio tool made sense
>
> Please pull into net-next and merge for 3.5.
Pulled, please give a review to:
http://patchwork.ozlabs.org/patch/156821/
http://patchwork.ozlabs.org/patch/156822/
Thanks.
^ permalink raw reply
* Re: [patch net-next] net: IP_MULTICAST_IF setsockopt now recognizes struct mreq
From: David Miller @ 2012-05-08 3:03 UTC (permalink / raw)
To: jpirko; +Cc: netdev, eric.dumazet, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <1336120665-954-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Fri, 4 May 2012 10:37:45 +0200
> Until now, struct mreq has not been recognized and it was worked with
> as with struct in_addr. That means imr_multiaddr was copied to
> imr_address. So do recognize struct mreq here and copy that correctly.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Fair enough, applied.
^ permalink raw reply
* Re: [PATCH v6 3/3] netdev/of/phy: Add MDIO bus multiplexer driven by GPIO lines.
From: David Miller @ 2012-05-08 2:59 UTC (permalink / raw)
To: ddaney.cavm
Cc: ralf, grant.likely, rob.herring, devicetree-discuss, netdev,
linux-kernel, linux-mips, afleming, galak, david.daney
In-Reply-To: <1336007799-31016-4-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Wed, 2 May 2012 18:16:39 -0700
> From: David Daney <david.daney@cavium.com>
>
> The GPIO pins select which sub bus is connected to the master.
>
> Initially tested with an sn74cbtlv3253 switch device wired into the
> MDIO bus.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH v6 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Miller @ 2012-05-08 2:58 UTC (permalink / raw)
To: ddaney.cavm
Cc: ralf, grant.likely, rob.herring, devicetree-discuss, netdev,
linux-kernel, linux-mips, afleming, galak, david.daney
In-Reply-To: <1336007799-31016-3-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Wed, 2 May 2012 18:16:38 -0700
> From: David Daney <david.daney@cavium.com>
>
> This patch adds a somewhat generic framework for MDIO bus
> multiplexers. It is modeled on the I2C multiplexer.
>
> The multiplexer is needed if there are multiple PHYs with the same
> address connected to the same MDIO bus adepter, or if there is
> insufficient electrical drive capability for all the connected PHY
> devices.
>
> Conceptually it could look something like this:
...
> This framework configures the bus topology from device tree data. The
> mechanics of switching the multiplexer is left to device specific
> drivers.
>
> The follow-on patch contains a multiplexer driven by GPIO lines.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH v6 1/3] netdev/of/phy: New function: of_mdio_find_bus().
From: David Miller @ 2012-05-08 2:58 UTC (permalink / raw)
To: ddaney.cavm
Cc: ralf, grant.likely, rob.herring, devicetree-discuss, netdev,
linux-kernel, linux-mips, afleming, galak, david.daney
In-Reply-To: <1336007799-31016-2-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Wed, 2 May 2012 18:16:37 -0700
> From: David Daney <david.daney@cavium.com>
>
> Add of_mdio_find_bus() which allows an mii_bus to be located given its
> associated the device tree node.
>
> This is needed by the follow-on patch to add a driver for MDIO bus
> multiplexers.
>
> The of_mdiobus_register() function is modified so that the device tree
> node is recorded in the mii_bus. Then we can find it again by
> iterating over all mdio_bus_class devices.
>
> Because the OF device tree has now become an integral part of the
> kernel, this can live in mdio_bus.c (which contains the needed
> mdio_bus_class structure) instead of of_mdio.c.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH] [IPV6] remove sysctl accept_source_route
From: David Miller @ 2012-05-08 2:56 UTC (permalink / raw)
To: eldad; +Cc: kuznet, jmorris, yoshfuji, kaber, eric.dumazet, linux-kernel,
netdev
In-Reply-To: <1335695830-19176-1-git-send-email-eldad@fogrefinery.com>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Sun, 29 Apr 2012 12:37:10 +0200
> The only place where the accpet_source_route flag is checked is when we
> are processing the type 2 routing header. In that case we only allow it if
> it (1) has only segments left = 1 and (2) if it matches our home address,
> which is the behavior required by RFC 6275 (see sections 8.5, 11.3.3), and
> it doesn't make sense to block rh2 when we're a mobile node.
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Considering commits:
commit c382bb9d32a55029fb13b118858e25908fab4617
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue Jul 10 22:47:58 2007 -0700
[IPV6]: Restore semantics of Routing Header processing.
The "fix" for emerging security threat was overkill and it broke
basic semantic of IPv6 routing header processing. We should assume
RT0 (or even RT2, depends on configuration) as "unknown" RH type so
that we
- silently ignore the routing header if segleft == 0
- send ICMPv6 Parameter Problem message back to the sender,
otherwise.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
and:
commit bb4dbf9e61d0801927e7df2569bb3dd8287ea301
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue Jul 10 22:55:49 2007 -0700
[IPV6]: Do not send RH0 anymore.
Based on <draft-ietf-ipv6-deprecate-rh0-00.txt>.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
the current behavior seems very much intentional.
Secondly, we cannot just delete sysctls like this, if someone
depends upon whatever current behavior is we will break them.
Therefore, on either account, I cannot apply this patch.
Sorry.
^ permalink raw reply
* Re: [PATCH 0/8] ISDN patches for net-next
From: David Miller @ 2012-05-08 2:42 UTC (permalink / raw)
To: tilman; +Cc: isdn, netdev, hjlipp, keil, i4ldeveloper, linux-kernel
In-Reply-To: <20120507.222912.1594023027707777260.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 07 May 2012 22:29:12 -0400 (EDT)
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Tue, 08 May 2012 02:24:17 +0200
>
>> On 26.04.2012 01:02, /me wrote:
>>> here's a series of eight patches to the Kernel CAPI subsystem and
>>> the Gigaset driver. Please consider for application to net-next.
>>> The first three should also go into -stable and are tagged accordingly.
>>
>> Is there anything missing for these to be accepted into net-next?
>> Or should I just be patient?
>
> I'll take care of it, I just put them back into "under review" state
> in patchwork.
All applied and pushed out to net-next, thanks Tilman.
^ permalink raw reply
* Re: [PATCH 0/8] ISDN patches for net-next
From: David Miller @ 2012-05-08 2:29 UTC (permalink / raw)
To: tilman; +Cc: isdn, netdev, hjlipp, keil, i4ldeveloper, linux-kernel
In-Reply-To: <4FA867B1.9080003@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Tue, 08 May 2012 02:24:17 +0200
> On 26.04.2012 01:02, /me wrote:
>> here's a series of eight patches to the Kernel CAPI subsystem and
>> the Gigaset driver. Please consider for application to net-next.
>> The first three should also go into -stable and are tagged accordingly.
>
> Is there anything missing for these to be accepted into net-next?
> Or should I just be patient?
I'll take care of it, I just put them back into "under review" state
in patchwork.
^ permalink raw reply
* Re: [PATCH 13/25] ipvs: remove check for IP_VS_CONN_F_SYNC from ip_vs_bind_dest
From: David Miller @ 2012-05-08 2:17 UTC (permalink / raw)
To: jengelh; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1205080414470.19642@frira.vanv.qr>
From: Jan Engelhardt <jengelh@inai.de>
Date: Tue, 8 May 2012 04:15:15 +0200 (CEST)
> On Tuesday 2012-05-08 03:36, David Miller wrote:
>
>>From: pablo@netfilter.org
>>Date: Tue, 8 May 2012 02:22:07 +0200
>>
>>> + /* It is a normal connection, so modify the counters
>>> + * according to the flags, later the protocol can
>>> + * update them on state change */
>>
>>Rather:
>>
>> /* It is a normal connection, so modify the counters
>> * according to the flags, later the protocol can
>> * update them on state change
>> */
>
> Well, CodingStyle even says
We've discussed this to death, subsystem maintainers can ask
for whatever they want and this is what I've asked for for years.
^ permalink raw reply
* Re: [PATCH 13/25] ipvs: remove check for IP_VS_CONN_F_SYNC from ip_vs_bind_dest
From: David Miller @ 2012-05-08 2:16 UTC (permalink / raw)
To: horms; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20120508020843.GA9027@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Tue, 8 May 2012 11:08:44 +0900
> can I fix this up as a subsequent patch?
Pablo's tree needs to get respun to address the other feedback
I gave, so no reason for him or you to not fix this as well.
^ permalink raw reply
* Re: [PATCH 13/25] ipvs: remove check for IP_VS_CONN_F_SYNC from ip_vs_bind_dest
From: Jan Engelhardt @ 2012-05-08 2:15 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20120507.213607.2054696052002528963.davem@davemloft.net>
On Tuesday 2012-05-08 03:36, David Miller wrote:
>From: pablo@netfilter.org
>Date: Tue, 8 May 2012 02:22:07 +0200
>
>> + /* It is a normal connection, so modify the counters
>> + * according to the flags, later the protocol can
>> + * update them on state change */
>
>Rather:
>
> /* It is a normal connection, so modify the counters
> * according to the flags, later the protocol can
> * update them on state change
> */
Well, CodingStyle even says
> /*
> * It is a normal connection, so modify the counters
> * according to the flags, later the protocol can
> * update them on state change.
> */
^ permalink raw reply
* Re: [PATCH 13/25] ipvs: remove check for IP_VS_CONN_F_SYNC from ip_vs_bind_dest
From: Simon Horman @ 2012-05-08 2:08 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20120507.213607.2054696052002528963.davem@davemloft.net>
On Mon, May 07, 2012 at 09:36:07PM -0400, David Miller wrote:
> From: pablo@netfilter.org
> Date: Tue, 8 May 2012 02:22:07 +0200
>
> > + /* It is a normal connection, so modify the counters
> > + * according to the flags, later the protocol can
> > + * update them on state change */
>
> Rather:
>
> /* It is a normal connection, so modify the counters
> * according to the flags, later the protocol can
> * update them on state change
> */
Hi Dave,
can I fix this up as a subsequent patch?
^ permalink raw reply
* [PATCH 3/3] openvswitch: Validation of IPv6 set port action uses IPv4 header
From: Jesse Gross @ 2012-05-08 1:51 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1336441885-11085-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Pravin B Shelar <pshelar-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
When the kernel validates set TCP/UDP port actions, it looks at
the ports in the existing flow to make sure that the L4 header exists.
However, these actions always use the IPv4 version of the struct.
Following patch fixes this by checking for flow ip protocol first.
Signed-off-by: Pravin B Shelar <pshelar-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/datapath.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4cb615d..777716b 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -421,6 +421,19 @@ static int validate_sample(const struct nlattr *attr,
return validate_actions(actions, key, depth + 1);
}
+static int validate_tp_port(const struct sw_flow_key *flow_key)
+{
+ if (flow_key->eth.type == htons(ETH_P_IP)) {
+ if (flow_key->ipv4.tp.src && flow_key->ipv4.tp.dst)
+ return 0;
+ } else if (flow_key->eth.type == htons(ETH_P_IPV6)) {
+ if (flow_key->ipv6.tp.src && flow_key->ipv6.tp.dst)
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static int validate_set(const struct nlattr *a,
const struct sw_flow_key *flow_key)
{
@@ -462,18 +475,13 @@ static int validate_set(const struct nlattr *a,
if (flow_key->ip.proto != IPPROTO_TCP)
return -EINVAL;
- if (!flow_key->ipv4.tp.src || !flow_key->ipv4.tp.dst)
- return -EINVAL;
-
- break;
+ return validate_tp_port(flow_key);
case OVS_KEY_ATTR_UDP:
if (flow_key->ip.proto != IPPROTO_UDP)
return -EINVAL;
- if (!flow_key->ipv4.tp.src || !flow_key->ipv4.tp.dst)
- return -EINVAL;
- break;
+ return validate_tp_port(flow_key);
default:
return -EINVAL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] openvswitch: Release rtnl_lock if ovs_vport_cmd_build_info() failed.
From: Jesse Gross @ 2012-05-08 1:51 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1336441885-11085-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Ansis Atteka <aatteka-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
This patch fixes a possible lock-up bug where rtnl_lock might not
get released.
Signed-off-by: Ansis Atteka <aatteka-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/datapath.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index e44e631..4cb615d 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1641,10 +1641,9 @@ static int ovs_vport_cmd_set(struct sk_buff *skb, struct genl_info *info)
reply = ovs_vport_cmd_build_info(vport, info->snd_pid, info->snd_seq,
OVS_VPORT_CMD_NEW);
if (IS_ERR(reply)) {
- err = PTR_ERR(reply);
netlink_set_err(init_net.genl_sock, 0,
- ovs_dp_vport_multicast_group.id, err);
- return 0;
+ ovs_dp_vport_multicast_group.id, PTR_ERR(reply));
+ goto exit_unlock;
}
genl_notify(reply, genl_info_net(info), info->snd_pid,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] openvswitch: Add length check when retrieving TCP flags.
From: Jesse Gross @ 2012-05-08 1:51 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1336441885-11085-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
When collecting TCP flags we check that the IP header indicates that
a TCP header is present but not that the packet is actually long
enough to contain the header. This adds a check to prevent reading
off the end of the packet.
In practice, this is only likely to result in reading of bad data and
not a crash due to the presence of struct skb_shared_info at the end
of the packet.
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/flow.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 1252c30..2a11ec2 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -183,7 +183,8 @@ void ovs_flow_used(struct sw_flow *flow, struct sk_buff *skb)
u8 tcp_flags = 0;
if (flow->key.eth.type == htons(ETH_P_IP) &&
- flow->key.ip.proto == IPPROTO_TCP) {
+ flow->key.ip.proto == IPPROTO_TCP &&
+ likely(skb->len >= skb_transport_offset(skb) + sizeof(struct tcphdr))) {
u8 *tcp = (u8 *)tcp_hdr(skb);
tcp_flags = *(tcp + TCP_FLAGS_OFFSET) & TCP_FLAG_MASK;
}
--
1.7.9.5
^ permalink raw reply related
* [GIT net] Open vSwitch
From: Jesse Gross @ 2012-05-08 1:51 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
A few patches for net/3.4.
The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928:
Linux 3.4-rc1 (2012-03-31 16:24:09 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git fixes
for you to fetch changes up to 072ae6314a191e3a9fc309b1e4e539ac7abc48ad:
openvswitch: Validation of IPv6 set port action uses IPv4 header (2012-05-07 17:23:10 -0700)
----------------------------------------------------------------
Ansis Atteka (1):
openvswitch: Release rtnl_lock if ovs_vport_cmd_build_info() failed.
Jesse Gross (1):
openvswitch: Add length check when retrieving TCP flags.
Pravin B Shelar (1):
openvswitch: Validation of IPv6 set port action uses IPv4 header
net/openvswitch/datapath.c | 27 +++++++++++++++++----------
net/openvswitch/flow.c | 3 ++-
2 files changed, 19 insertions(+), 11 deletions(-)
^ permalink raw reply
* SO_TIMESTAMP on tcp sockets?
From: Andy Lutomirski @ 2012-05-08 1:39 UTC (permalink / raw)
To: Network Development
I've been using SO_TIMESTAMPNS to good effect on udp sockets. I'd
like to do the same thing for tcp. I realize that this is
semantically strange [1], but I don't think there's a real issue for
my use case. We have very thin streams -- we are likely to process
each incoming segment as it is received, and I want the most precise
timestamp possible on each segment.
A simple approach (I think) would be for a recvmsg on a tcp socket
with SO_TIMESTAMP(NS) to return at most one skb worth of data along
with the timestamp associated with that skb. This could be a little
strange if multiple segments overlap or if lro is involved, but
neither of those cases seems like a major problem.
Is there any interest in something like this?
Thanks,
Andy
[1] http://comments.gmane.org/gmane.linux.network/159574
^ permalink raw reply
* Re: [PATCH 13/25] ipvs: remove check for IP_VS_CONN_F_SYNC from ip_vs_bind_dest
From: David Miller @ 2012-05-08 1:36 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1336436539-5880-14-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Tue, 8 May 2012 02:22:07 +0200
> + /* It is a normal connection, so modify the counters
> + * according to the flags, later the protocol can
> + * update them on state change */
Rather:
/* It is a normal connection, so modify the counters
* according to the flags, later the protocol can
* update them on state change
*/
^ permalink raw reply
* Re: [PATCH 02/25] netfilter: nf_ct_helper: allow to disable automatic helper assignment
From: David Miller @ 2012-05-08 1:34 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1336436539-5880-3-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Tue, 8 May 2012 02:21:56 +0200
> + if (!net->ct.helper_sysctl_header) {
> + printk(KERN_ERR "nf_conntrack_helper: can't register to sysctl.\n");
> + goto out_register;
> + }
Please use pr_err().
> + printk(KERN_INFO "nf_conntrack: automatic helper "
> + "assignment is deprecated. Please, read "
> + "http://www.netfilter.org/news.html#2012-04-03\n");
> + net->ct.auto_assign_helper_warned = true;
Please use pr_info().
Pointers to web sites to explain a problem is absolutely not
appropriate in kernel log messages, nor commit messages.
Either add a document to the kernel tree, or explain things
fully both in the kernel log message and the commit message.
^ permalink raw reply
* Re: [PATCH net-next 0/2] extend sch_mqprio to distribute traffic not only by ETS TC
From: John Fastabend @ 2012-05-08 0:54 UTC (permalink / raw)
To: Amir Vadai; +Cc: David S. Miller, netdev, Oren Duer, Liran Liss
In-Reply-To: <1336287910-12010-1-git-send-email-amirv@mellanox.com>
On 5/6/2012 12:05 AM, Amir Vadai wrote:
> This series comes to revive the discussion initiated on the thread "net:
> support tx_ring per UP in HW based QoS mechanism" (see
> http://marc.info/?t=133165957200004&r=1&w=2) with the major issue to be address
> is - how should sk_prio<=> TC be done, for both, tagged and untagged traffic.
> Following is a staged description addressing the background, problem
> description, current situation, suggestion for the change and implementation of
> it.
OK but the mqprio qdisc is only concerned with mapping skb->priority to
queue sets I perhaps unfortunately called the queue sets tc's. Try not
to get hung up on my perhaps limiting naming of variables and functions.
mqprio is used outside of 802.1Q as well in these cases a traffic class
is not usually even defined.
>
> Background
> ----------
> Egress traffic has 3 layers of management to configure QoS attributes:
> * Application - sets sk_prio
> * setsockopt() - application may set sk_prio using SO_PRIORITY or IP_TOS
> * Host admin - sets sk_prio <=> UP
> * net_prio cgroup
net_prio cgroup is about setting skb->priority not really UP.
> * Egress map for tagged traffic
> * Net admin - sets UP <=> TC + TC QoS attributes
> * lldpad
> Commit 4f57c087de9 "net: implement mechanism for HW based QOS" introduced a
> mechanism for lower layer devices to steer traffic using skb->priority to tx
> queues.
yep that was my first comment.
>
> Problem
> -------
> How should sk_prio <=> TC be done, for both, tagged and untagged traffic?
>
> Current situation
> -----------------
> * The network priority cgroup infrastructure commit 5bc1421e, introduced implicit
> assumption that sk_prio == UP.
I don't think this is true at least this is not my perspective.
The cgroup infrastructure in that commit sets the skb->priority. What you
do with the priority and if you map it to a UP or qdisc classes or some
other thing is up to the lower layers. In the DCBX context it eventually
gets mapped to some queue sets but that is only one usage case.
> * tc tool is used to map UP <=> TC for both tagged and untagged traffic.
Yes. But this is just a display issue. If I was being more general I
would have named this 'priority to queue set'. A bit short sighted
on my part.
> * egress map and lldptool and ignored when tc tool is being used.
Agreed. And this creates a bit of a nuisance but I believe it can
be resolved in user space. AFAIK all the interfaces needed are available.
> * HW queue is per TC.
>
> Suggestion
> ----------
> * sk_prio is an attribute controlled by the Application or cgroup.
> As used to be in tagged traffic
This is the current usage correct?
> * tc tool is used by the Host admin and sets sk_prio <=> UP for untagged
> traffic. The rest of the chain is UP <=> TC mapped by the Net admin (using
> DCBx netlink).
This seems fine. But, what exactly is broken today? If you use the current
mqprio qdisc and rename tc to queue_set then this works right?
> To keep backward compatibility, will have an option to set tc tool to
> compatabilty mode, in which, the old sk_prio <=> TC will be kept.
> * Depending on HW, queue selection is by UP or by TC.
>
> Implementation
> --------------
> Extended mqprio hw attribute:
> * Bit 1: is queue offset/count owned by HW
> * Bits 2-7: HW queueing type.
> * 0 - by ETS TC
> * 1 - by UP
>
> __skb_tx_hash() is now aware to the HW queuing type (pg_type): for pg_type
> being ETS TC, traffic is distributed as it was before - tagged and untagged
> packets are distributed by netdev_get_prio_tc_map. For pg_type being UP, tagged
> and untagged packets are distributed by UP (taken from egress map for tagged
> traffic, or netdev_get_prio_tc_map for untagged).
I guess I don't see why we need this. If you keep the mqprio priority to
queue set mapping set to 1:1. Then modify the egress map accordingly then
this should work right?
For example:
If we want to map 8 802.1Q priority code points onto 4 traffic classes this
should work,
egress map: 0:0 1:0 2:1 3:1 4:2 5:2 6:3 7:3 <-- vlan layer inserts correct tag
mqprio up2tc: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 <-- mqprio with unfortunate 'tc' name maps priority to queues
dcbnl up2tc: 0:0 1:0 2:1 3:1 4:2 5:2 6:3 7:3 <-- dcbx pushes up2tc mapping correctly
We may need to fixup userspace tools some but I think the kernel mechanisms
are in place.
BTW I did think about this while implementing the existing code and decided
that rather than create more if/else branches the case you are describing
could be handled by independently controlling the priority to queue set mappings
in mqprio and the egress map.
Feel free to let me know where I went wrong or why this doesn't work on
your hardware. I agree though we may need to fixup lldpad and maybe even
'tc' some to get this to look correct in user space and get automagically
setup correctly.
Thanks,
.John
^ 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