* [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
* [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
* [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 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
* 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
* 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: 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: 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 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 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] [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 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 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 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 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: [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
* 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: [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
* 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
* [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 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
* [PATCH V3 Resend 09/12] net/stmmac: Remove conditional compilation of clk code
From: Viresh Kumar @ 2012-05-08 3:52 UTC (permalink / raw)
To: akpm
Cc: spear-devel, viresh.linux, linux-kernel, linux-arm-kernel,
mturquette, sshtylyov, jgarzik, linux, w.sang, LW, andrew,
Viresh Kumar, Giuseppe Cavallaro, David S. Miller, netdev
In-Reply-To: <cover.1336448639.git.viresh.kumar@st.com>
With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
macros.
This also fixes error paths of probe(), as a goto is required in this patch.
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 41 ---------------------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 33 +++++++++--------
2 files changed, 17 insertions(+), 57 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index db2de9a..7f85895 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -81,9 +81,7 @@ struct stmmac_priv {
struct stmmac_counters mmc;
struct dma_features dma_cap;
int hw_cap_support;
-#ifdef CONFIG_HAVE_CLK
struct clk *stmmac_clk;
-#endif
int clk_csr;
};
@@ -103,42 +101,3 @@ int stmmac_dvr_remove(struct net_device *ndev);
struct stmmac_priv *stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
void __iomem *addr);
-
-#ifdef CONFIG_HAVE_CLK
-static inline int stmmac_clk_enable(struct stmmac_priv *priv)
-{
- if (!IS_ERR(priv->stmmac_clk))
- return clk_enable(priv->stmmac_clk);
-
- return 0;
-}
-
-static inline void stmmac_clk_disable(struct stmmac_priv *priv)
-{
- if (IS_ERR(priv->stmmac_clk))
- return;
-
- clk_disable(priv->stmmac_clk);
-}
-static inline int stmmac_clk_get(struct stmmac_priv *priv)
-{
- priv->stmmac_clk = clk_get(priv->device, NULL);
-
- if (IS_ERR(priv->stmmac_clk))
- return PTR_ERR(priv->stmmac_clk);
-
- return 0;
-}
-#else
-static inline int stmmac_clk_enable(struct stmmac_priv *priv)
-{
- return 0;
-}
-static inline void stmmac_clk_disable(struct stmmac_priv *priv)
-{
-}
-static inline int stmmac_clk_get(struct stmmac_priv *priv)
-{
- return 0;
-}
-#endif /* CONFIG_HAVE_CLK */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1a4cf81..bbdcb55 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -28,6 +28,7 @@
https://bugzilla.stlinux.com/
*******************************************************************************/
+#include <linux/clk.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <linux/ip.h>
@@ -165,12 +166,8 @@ static void stmmac_verify_args(void)
static void stmmac_clk_csr_set(struct stmmac_priv *priv)
{
-#ifdef CONFIG_HAVE_CLK
u32 clk_rate;
- if (IS_ERR(priv->stmmac_clk))
- return;
-
clk_rate = clk_get_rate(priv->stmmac_clk);
/* Platform provided default clk_csr would be assumed valid
@@ -192,7 +189,6 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
* we can not estimate the proper divider as it is not known
* the frequency of clk_csr_i. So we do not change the default
* divider. */
-#endif
}
#if defined(STMMAC_XMIT_DEBUG) || defined(STMMAC_RX_DEBUG)
@@ -971,7 +967,7 @@ static int stmmac_open(struct net_device *dev)
} else
priv->tm->enable = 1;
#endif
- stmmac_clk_enable(priv);
+ clk_enable(priv->stmmac_clk);
stmmac_check_ether_addr(priv);
@@ -1075,7 +1071,7 @@ open_error:
if (priv->phydev)
phy_disconnect(priv->phydev);
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
return ret;
}
@@ -1128,7 +1124,7 @@ static int stmmac_release(struct net_device *dev)
#ifdef CONFIG_STMMAC_DEBUG_FS
stmmac_exit_fs();
#endif
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
return 0;
}
@@ -1922,11 +1918,14 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
ret = register_netdev(ndev);
if (ret) {
pr_err("%s: ERROR %i registering the device\n", __func__, ret);
- goto error;
+ goto error_netdev_register;
}
- if (stmmac_clk_get(priv))
+ priv->stmmac_clk = clk_get(priv->device, NULL);
+ if (IS_ERR(priv->stmmac_clk)) {
pr_warning("%s: warning: cannot get CSR clock\n", __func__);
+ goto error_clk_get;
+ }
/* If a specific clk_csr value is passed from the platform
* this means that the CSR Clock Range selection cannot be
@@ -1944,15 +1943,17 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
if (ret < 0) {
pr_debug("%s: MDIO bus (id: %d) registration failed",
__func__, priv->plat->bus_id);
- goto error;
+ goto error_mdio_register;
}
return priv;
-error:
- netif_napi_del(&priv->napi);
-
+error_mdio_register:
+ clk_put(priv->stmmac_clk);
+error_clk_get:
unregister_netdev(ndev);
+error_netdev_register:
+ netif_napi_del(&priv->napi);
free_netdev(ndev);
return NULL;
@@ -2020,7 +2021,7 @@ int stmmac_suspend(struct net_device *ndev)
else {
stmmac_set_mac(priv->ioaddr, false);
/* Disable clock in case of PWM is off */
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
}
spin_unlock(&priv->lock);
return 0;
@@ -2044,7 +2045,7 @@ int stmmac_resume(struct net_device *ndev)
priv->hw->mac->pmt(priv->ioaddr, 0);
else
/* enable the clk prevously disabled */
- stmmac_clk_enable(priv);
+ clk_enable(priv->stmmac_clk);
netif_device_attach(ndev);
--
1.7.9
^ permalink raw reply related
* Re: SO_TIMESTAMP on tcp sockets?
From: Eric Dumazet @ 2012-05-08 4:37 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: Network Development
In-Reply-To: <CALCETrVUjLz63uzr+UTf-G1jq9QDcX6Gf9D6AWK8_GmunsJGnw@mail.gmail.com>
On Mon, 2012-05-07 at 18:39 -0700, Andy Lutomirski wrote:
> 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?
>
LRO/GRO is not really a problem, buffers are merged because they are
received in a very short time period. If you want nanosec timestamping
on TCP, just cancel the whole idea.
TCP can 'collapse' several buffers onto single ones (to reduce memory
overhead). Which timestamp would be chosen at collapse time ?
net-next also has tcp coalescing, wich also merge buffers as soon as
they enter receive or ofo queue.
Another problem with SO_TIMESTAMPNS is it globally enables time stamping
on all skbs on the host, adding some latencies. (ktime_get() can be
slowed down when time keeping triggers and hold xtime seqlock)
^ permalink raw reply
* Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering
From: Johannes Berg @ 2012-05-08 5:25 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120507.192052.181899101154654170.davem@davemloft.net>
On Mon, 2012-05-07 at 19:20 -0400, David Miller wrote:
> >> > Neither compare_ether_addr() nor compare_ether_addr_64bits()
> >> > (as it can fall back to the former) have comparison semantics
> >> > like memcmp() where the sign of the return value indicates sort
> >> > order. We had a bug in the wireless code due to a blind memcmp
> >> > replacement because of this.
> >> >
> >> > A cursory look suggests that the wireless bug was the only one
> >> > due to this semantic difference.
> >> >
> >> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> >> > ---
> >> > include/linux/etherdevice.h | 11 ++++++-----
> >> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >>
> >> The right way to avoid this kind of problems is to change these
> >> functions to return a bool
> >
> > Well, I guess so, but that'd be a weird thing for a compare_ function...
> > should probably be named equal_... then, but I'm not really able to do
> > such a huge change on the first day after my vacation :-)
>
> It's true the name could be improved, but changing the name is quite
> a large undertaking even with automated scripts.
>
> Even the bool change is slightly painful, since all of the explicit
> tests against integers (%99.999 of these are in wireless BTW :-) would
> need to be adjusted.
I suppose I could fix those first and then later change the type, but I
think having a "compare_ether_addr" function that returns *false* when
they *match* would be rather confusing. I'd rather have
"equal_ether_addr()" that returns *true* when they match.
I guess we could introduce equal_ether_addr() though and slowly convert,
keeping compare_ether_addr() as a sort of wrapper around it.
johannes
^ permalink raw reply
* Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering
From: David Miller @ 2012-05-08 6:26 UTC (permalink / raw)
To: johannes; +Cc: eric.dumazet, netdev
In-Reply-To: <1336454744.4328.2.camel@jlt3.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 08 May 2012 07:25:44 +0200
> I suppose I could fix those first and then later change the type, but I
> think having a "compare_ether_addr" function that returns *false* when
> they *match* would be rather confusing. I'd rather have
> "equal_ether_addr()" that returns *true* when they match.
>
> I guess we could introduce equal_ether_addr() though and slowly convert,
> keeping compare_ether_addr() as a sort of wrapper around it.
Indeed, this is one way to proceed.
^ 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