* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: Mugunthan V N @ 2013-11-14 12:45 UTC (permalink / raw)
To: Daniel Mack, netdev; +Cc: davem
In-Reply-To: <1384347180-3490-1-git-send-email-zonque@gmail.com>
On Wednesday 13 November 2013 06:23 PM, Daniel Mack wrote:
> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
> on dual MAC enabled machines.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> drivers/net/ethernet/ti/cpsw.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index edd3e79..702b063 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -2173,8 +2173,11 @@ static int cpsw_suspend(struct device *dev)
>
> if (netif_running(ndev))
> cpsw_ndo_stop(ndev);
> +
> soft_reset("sliver 0", &priv->slaves[0].sliver->soft_reset);
> - soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
> + if (priv->data.dual_emac)
> + soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
Is this tested on a system with both ports in switch mode?
I don't think this will not work with both ports in switch mode.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH net 5/6] ti_cpsw: Validate hwtstamp_config completely before applying it
From: Mugunthan V N @ 2013-11-14 12:49 UTC (permalink / raw)
To: Ben Hutchings, David Miller, Felipe Balbi; +Cc: netdev, Richard Cochran
In-Reply-To: <1384390056.29151.12.camel@bwh-desktop.uk.level5networks.com>
On Thursday 14 November 2013 06:17 AM, Ben Hutchings wrote:
> cpsw_hwtstamp_ioctl() should validate all fields of hwtstamp_config,
> and the hardware version, before making any changes. Currently it
> sets the TX configuration before validating the rx_filter field
> or that the hardware supports timestamping.
>
> Also correct the error code for hardware versions that don't
> support timestamping. ENOTSUPP is used by the NFS implementation
> and is not part of userland API; we want EOPNOTSUPP (which glibc
> also calls ENOTSUP, with one 'P').
>
> Untested as I don't have a cross-compiler to hand.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
Acked-by: Mugunthan V N <mugunthanvnm@gmail.com>
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH net 2/3] sit: link local routes are missing
From: Nicolas Dichtel @ 2013-11-14 12:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1384433467-4780-1-git-send-email-nicolas.dichtel@6wind.com>
When a link local address was added to a sit interface, the corresponding route
was not configured. This breaks routing protocols that use the link local
address, like OSPFv3.
To ease the code reading, I remove sit_route_add(), which only adds v4 mapped
routes, and add this kind of route directly in sit_add_v4_addrs(). Thus link
local and v4 mapped routes are configured in the same place.
Reported-by: Li Hongjun <hongjun.li@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 24 +++++-------------------
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 4e558e5e0e42..237bceb74c4e 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2006,23 +2006,6 @@ static void addrconf_add_mroute(struct net_device *dev)
ip6_route_add(&cfg);
}
-#if IS_ENABLED(CONFIG_IPV6_SIT)
-static void sit_route_add(struct net_device *dev)
-{
- struct fib6_config cfg = {
- .fc_table = RT6_TABLE_MAIN,
- .fc_metric = IP6_RT_PRIO_ADDRCONF,
- .fc_ifindex = dev->ifindex,
- .fc_dst_len = 96,
- .fc_flags = RTF_UP | RTF_NONEXTHOP,
- .fc_nlinfo.nl_net = dev_net(dev),
- };
-
- /* prefix length - 96 bits "::d.d.d.d" */
- ip6_route_add(&cfg);
-}
-#endif
-
static struct inet6_dev *addrconf_add_dev(struct net_device *dev)
{
struct inet6_dev *idev;
@@ -2556,6 +2539,7 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
struct net_device *dev;
struct net *net = dev_net(idev->dev);
int scope, plen;
+ u32 pflags = 0;
ASSERT_RTNL();
@@ -2569,10 +2553,12 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
} else {
scope = IPV6_ADDR_COMPATv4;
plen = 96;
+ pflags |= RTF_NONEXTHOP;
}
if (addr.s6_addr32[3]) {
add_addr(idev, &addr, plen, scope);
+ addrconf_prefix_route(&addr, plen, idev->dev, 0, pflags);
return;
}
@@ -2596,6 +2582,8 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
}
add_addr(idev, &addr, plen, flag);
+ addrconf_prefix_route(&addr, plen, idev->dev, 0,
+ pflags);
}
}
}
@@ -2731,8 +2719,6 @@ static void addrconf_sit_config(struct net_device *dev)
if (dev->flags&IFF_POINTOPOINT)
addrconf_add_mroute(dev);
- else
- sit_route_add(dev);
}
#endif
--
1.8.4.1
^ permalink raw reply related
* [PATCH net 3/3] sit/gre6: don't try to add the same route two times
From: Nicolas Dichtel @ 2013-11-14 12:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1384433467-4780-1-git-send-email-nicolas.dichtel@6wind.com>
addrconf_add_linklocal() already adds the link local route, so there is no
reason to add it before calling this function.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 237bceb74c4e..cfc47b364e51 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2709,7 +2709,6 @@ static void addrconf_sit_config(struct net_device *dev)
struct in6_addr addr;
ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
- addrconf_prefix_route(&addr, 64, dev, 0, 0);
if (!ipv6_generate_eui64(addr.s6_addr + 8, dev))
addrconf_add_linklocal(idev, &addr);
return;
@@ -2736,8 +2735,6 @@ static void addrconf_gre_config(struct net_device *dev)
}
ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
- addrconf_prefix_route(&addr, 64, dev, 0, 0);
-
if (!ipv6_generate_eui64(addr.s6_addr + 8, dev))
addrconf_add_linklocal(idev, &addr);
}
--
1.8.4.1
^ permalink raw reply related
* [PATCH net 1/3] sit: fix prefix length of ll and v4mapped addresses
From: Nicolas Dichtel @ 2013-11-14 12:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
When the local IPv4 endpoint is wilcard (0.0.0.0), the prefix length is
correctly set, ie 64 if the address is a link local one or 96 if the address is
a v4 mapped one.
But when the local endpoint is specified, the prefix length is set to 128 for
both kind of address. This patch fix this wrong prefix length.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cd3fb301da38..4e558e5e0e42 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2555,7 +2555,7 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
struct in6_addr addr;
struct net_device *dev;
struct net *net = dev_net(idev->dev);
- int scope;
+ int scope, plen;
ASSERT_RTNL();
@@ -2565,12 +2565,14 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
if (idev->dev->flags&IFF_POINTOPOINT) {
addr.s6_addr32[0] = htonl(0xfe800000);
scope = IFA_LINK;
+ plen = 64;
} else {
scope = IPV6_ADDR_COMPATv4;
+ plen = 96;
}
if (addr.s6_addr32[3]) {
- add_addr(idev, &addr, 128, scope);
+ add_addr(idev, &addr, plen, scope);
return;
}
@@ -2582,7 +2584,6 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
int flag = scope;
for (ifa = in_dev->ifa_list; ifa; ifa = ifa->ifa_next) {
- int plen;
addr.s6_addr32[3] = ifa->ifa_local;
@@ -2593,10 +2594,6 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
continue;
flag |= IFA_HOST;
}
- if (idev->dev->flags&IFF_POINTOPOINT)
- plen = 64;
- else
- plen = 96;
add_addr(idev, &addr, plen, flag);
}
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: Daniel Mack @ 2013-11-14 12:56 UTC (permalink / raw)
To: Mugunthan V N, netdev; +Cc: davem
In-Reply-To: <5284C602.8000103@ti.com>
On 11/14/2013 01:45 PM, Mugunthan V N wrote:
> On Wednesday 13 November 2013 06:23 PM, Daniel Mack wrote:
>> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
>> on dual MAC enabled machines.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>> ---
>> drivers/net/ethernet/ti/cpsw.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>> index edd3e79..702b063 100644
>> --- a/drivers/net/ethernet/ti/cpsw.c
>> +++ b/drivers/net/ethernet/ti/cpsw.c
>> @@ -2173,8 +2173,11 @@ static int cpsw_suspend(struct device *dev)
>>
>> if (netif_running(ndev))
>> cpsw_ndo_stop(ndev);
>> +
>> soft_reset("sliver 0", &priv->slaves[0].sliver->soft_reset);
>> - soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>> + if (priv->data.dual_emac)
>> + soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>
> Is this tested on a system with both ports in switch mode?
Nope. I got an Ooops when I tried to suspend a machine that has only one
slave configured in DTS.
> I don't think this will not work with both ports in switch mode.
Why? Isn't priv->data.dual_emac in that case? The same condition is
checked for in cpsw_remove().
Thanks,
Daniel
^ permalink raw reply
* Re: [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Nicolas Dichtel @ 2013-11-14 13:05 UTC (permalink / raw)
To: David Miller
Cc: hannes, netdev, David.Laight, jiri, vyasevich, kuznet, jmorris,
yoshfuji, kaber, thaller, stephen
In-Reply-To: <20131111.001803.110603937316567461.davem@davemloft.net>
Le 11/11/2013 06:18, David Miller a écrit :
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Sat, 9 Nov 2013 01:54:34 +0100
>
>> This feature allows to a send packets with address source set to 0.0.0.0 even if
>> an ip address is available on another interface.
>>
>> It's useful for DHCP client, to allow them to use UDP sockets and be compliant
>> with the RFC2131, Section 4.1:
>>
>> 4.1 Constructing and sending DHCP messages
>> ...
>> DHCP messages broadcast by a client prior to that client obtaining
>> its IP address must have the source address field in the IP header
>> set to 0.
>>
>> Based on a previous work from
>> Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> This requirement of the RFC is inconsistent with a host based
> addressing model, that which Linux employs, it assumes an interface
> based one.
There are some exceptions, for example when user tunes arp_ignore sysctl ;-)
>
> The wording here is also very ambiguous.
>
> This RFC fails to even remotely consider what the right behavior
> should be in a host based addressing environment at all, and anyone
> reading this RFC should just accept that.
I agree that this is ambiguous. And it's a 'must', not a 'MUST', which
is not the same for an RFC ;-)
>
> Furthermore, the fact that you're implementing _addressing_ policy in
> the UDP code makes this change even more unreasonable.
>
I made this choice because using 0.0.0.0, for TCP for example, seems a
non-sense.
But fair enough, let's drop this patch.
Thank you,
Nicolas
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: Mugunthan V N @ 2013-11-14 13:09 UTC (permalink / raw)
To: Daniel Mack, netdev; +Cc: davem
In-Reply-To: <5284C87A.60404@gmail.com>
On Thursday 14 November 2013 06:26 PM, Daniel Mack wrote:
> On 11/14/2013 01:45 PM, Mugunthan V N wrote:
>> On Wednesday 13 November 2013 06:23 PM, Daniel Mack wrote:
>>> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
>>> on dual MAC enabled machines.
>>>
>>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>>> ---
>>> drivers/net/ethernet/ti/cpsw.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>>> index edd3e79..702b063 100644
>>> --- a/drivers/net/ethernet/ti/cpsw.c
>>> +++ b/drivers/net/ethernet/ti/cpsw.c
>>> @@ -2173,8 +2173,11 @@ static int cpsw_suspend(struct device *dev)
>>>
>>> if (netif_running(ndev))
>>> cpsw_ndo_stop(ndev);
>>> +
>>> soft_reset("sliver 0", &priv->slaves[0].sliver->soft_reset);
>>> - soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>>> + if (priv->data.dual_emac)
>>> + soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>> Is this tested on a system with both ports in switch mode?
> Nope. I got an Ooops when I tried to suspend a machine that has only one
> slave configured in DTS.
But the changes above will fail with system with two ports and in switch
mode.
>
>> I don't think this will not work with both ports in switch mode.
> Why? Isn't priv->data.dual_emac in that case? The same condition is
> checked for in cpsw_remove().
In cpsw_remove that check is used to unregister the second network
interface registered for same device for port 2. Now I got the issue,
this has to be done via for_each_slave().
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH net 0/6] net_tstamp: Validate hwtstamp_config completely before applying it
From: Richard Cochran @ 2013-11-14 13:26 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1384389542.29151.5.camel@bwh-desktop.uk.level5networks.com>
On Thu, Nov 14, 2013 at 12:39:02AM +0000, Ben Hutchings wrote:
> This series fixes very similar bugs in 6 implementations of
> SIOCSHWTSTAMP.
>
> Ben.
>
> Ben Hutchings (6):
> tg3: Validate hwtstamp_config completely before applying it
> e1000e: Validate hwtstamp_config completely before applying it
> pch_gbe: Validate hwtstamp_config completely before applying it
> stmmac: Validate hwtstamp_config completely before applying it
> ti_cpsw: Validate hwtstamp_config completely before applying it
> ixp4xx_eth: Validate hwtstamp_config completely before applying it
For the series,
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* [RFC 8/7] genetlink: make all genl_ops users const
From: Johannes Berg @ 2013-11-14 13:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Now that genl_ops are no longer modified in place when
registering, they can be made const. This patch was done
mostly with spatch:
@@
identifier ops;
@@
+const
struct genl_ops ops[] = {
...
};
(except the struct thing in net/openvswitch/datapath.c)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/team/team.c | 2 +-
drivers/net/wireless/mac80211_hwsim.c | 2 +-
kernel/taskstats.c | 2 +-
net/core/drop_monitor.c | 2 +-
net/hsr/hsr_netlink.c | 2 +-
net/ieee802154/netlink.c | 2 +-
net/ipv4/tcp_metrics.c | 2 +-
net/irda/irnetlink.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
net/netfilter/ipvs/ip_vs_ctl.c | 2 +-
net/netlabel/netlabel_cipso_v4.c | 2 +-
net/netlabel/netlabel_mgmt.c | 2 +-
net/netlabel/netlabel_unlabeled.c | 2 +-
net/nfc/netlink.c | 2 +-
net/openvswitch/datapath.c | 10 +++++-----
net/wimax/stack.c | 2 +-
net/wireless/nl80211.c | 2 +-
17 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 50e43e6..6390254 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2644,7 +2644,7 @@ static int team_nl_cmd_port_list_get(struct sk_buff *skb,
return err;
}
-static struct genl_ops team_nl_ops[] = {
+static const struct genl_ops team_nl_ops[] = {
{
.cmd = TEAM_CMD_NOOP,
.doit = team_nl_cmd_noop,
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index de0df86..cfc3fda 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2097,7 +2097,7 @@ out:
}
/* Generic Netlink operations array */
-static struct genl_ops hwsim_ops[] = {
+static const struct genl_ops hwsim_ops[] = {
{
.cmd = HWSIM_CMD_REGISTER,
.policy = hwsim_genl_policy,
diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index 609e77f..76595cd 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -673,7 +673,7 @@ err:
nlmsg_free(rep_skb);
}
-static struct genl_ops taskstats_ops[] = {
+static const struct genl_ops taskstats_ops[] = {
{
.cmd = TASKSTATS_CMD_GET,
.doit = taskstats_user_cmd,
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 5e78d44..f9fe2f2 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -333,7 +333,7 @@ out:
return NOTIFY_DONE;
}
-static struct genl_ops dropmon_ops[] = {
+static const struct genl_ops dropmon_ops[] = {
{
.cmd = NET_DM_CMD_CONFIG,
.doit = net_dm_cmd_config,
diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
index 8f52a9f..79d72ca 100644
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -389,7 +389,7 @@ fail:
}
-static struct genl_ops hsr_ops[] = {
+static const struct genl_ops hsr_ops[] = {
{
.cmd = HSR_C_GET_NODE_STATUS,
.flags = 0,
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index eb9faef..3ffcdbb 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -109,7 +109,7 @@ out:
return -ENOBUFS;
}
-static struct genl_ops ieee8021154_ops[] = {
+static const struct genl_ops ieee8021154_ops[] = {
/* see nl-phy.c */
IEEE802154_DUMP(IEEE802154_LIST_PHY, ieee802154_list_phy,
ieee802154_dump_phy),
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 2ab09cb..9b780c1 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -988,7 +988,7 @@ static int tcp_metrics_nl_cmd_del(struct sk_buff *skb, struct genl_info *info)
return 0;
}
-static struct genl_ops tcp_metrics_nl_ops[] = {
+static const struct genl_ops tcp_metrics_nl_ops[] = {
{
.cmd = TCP_METRICS_CMD_GET,
.doit = tcp_metrics_nl_cmd_get,
diff --git a/net/irda/irnetlink.c b/net/irda/irnetlink.c
index c3297126..bf5d7d4 100644
--- a/net/irda/irnetlink.c
+++ b/net/irda/irnetlink.c
@@ -131,7 +131,7 @@ static const struct nla_policy irda_nl_policy[IRDA_NL_ATTR_MAX + 1] = {
[IRDA_NL_ATTR_MODE] = { .type = NLA_U32 },
};
-static struct genl_ops irda_nl_ops[] = {
+static const struct genl_ops irda_nl_ops[] = {
{
.cmd = IRDA_NL_CMD_SET_MODE,
.doit = irda_nl_set_mode,
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index be446d5..57db66e 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -793,7 +793,7 @@ static struct nla_policy l2tp_nl_policy[L2TP_ATTR_MAX + 1] = {
},
};
-static struct genl_ops l2tp_nl_ops[] = {
+static const struct genl_ops l2tp_nl_ops[] = {
{
.cmd = L2TP_CMD_NOOP,
.doit = l2tp_nl_cmd_noop,
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 62786a4..fc8a04e 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3567,7 +3567,7 @@ out:
}
-static struct genl_ops ip_vs_genl_ops[] __read_mostly = {
+static const struct genl_ops ip_vs_genl_ops[] __read_mostly = {
{
.cmd = IPVS_CMD_NEW_SERVICE,
.flags = GENL_ADMIN_PERM,
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index a110064..7066917 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -737,7 +737,7 @@ static int netlbl_cipsov4_remove(struct sk_buff *skb, struct genl_info *info)
* NetLabel Generic NETLINK Command Definitions
*/
-static struct genl_ops netlbl_cipsov4_ops[] = {
+static const struct genl_ops netlbl_cipsov4_ops[] = {
{
.cmd = NLBL_CIPSOV4_C_ADD,
.flags = GENL_ADMIN_PERM,
diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
index dd1c37d..7de6f66 100644
--- a/net/netlabel/netlabel_mgmt.c
+++ b/net/netlabel/netlabel_mgmt.c
@@ -705,7 +705,7 @@ version_failure:
* NetLabel Generic NETLINK Command Definitions
*/
-static struct genl_ops netlbl_mgmt_genl_ops[] = {
+static const struct genl_ops netlbl_mgmt_genl_ops[] = {
{
.cmd = NLBL_MGMT_C_ADD,
.flags = GENL_ADMIN_PERM,
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index 8f08974..76ee925 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -1323,7 +1323,7 @@ unlabel_staticlistdef_return:
* NetLabel Generic NETLINK Command Definitions
*/
-static struct genl_ops netlbl_unlabel_genl_ops[] = {
+static const struct genl_ops netlbl_unlabel_genl_ops[] = {
{
.cmd = NLBL_UNLABEL_C_STATICADD,
.flags = GENL_ADMIN_PERM,
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 84b7e3e..f558561 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -1364,7 +1364,7 @@ static int nfc_genl_se_io(struct sk_buff *skb, struct genl_info *info)
return dev->ops->se_io(dev, se_idx, apdu, apdu_len, se_io_cb, ctx);
}
-static struct genl_ops nfc_genl_ops[] = {
+static const struct genl_ops nfc_genl_ops[] = {
{
.cmd = NFC_CMD_GET_DEVICE,
.doit = nfc_genl_get_device,
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 1408adc..91e1c92 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -557,7 +557,7 @@ static const struct nla_policy packet_policy[OVS_PACKET_ATTR_MAX + 1] = {
[OVS_PACKET_ATTR_ACTIONS] = { .type = NLA_NESTED },
};
-static struct genl_ops dp_packet_genl_ops[] = {
+static const struct genl_ops dp_packet_genl_ops[] = {
{ .cmd = OVS_PACKET_CMD_EXECUTE,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = packet_policy,
@@ -1034,7 +1034,7 @@ static int ovs_flow_cmd_dump(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
-static struct genl_ops dp_flow_genl_ops[] = {
+static const struct genl_ops dp_flow_genl_ops[] = {
{ .cmd = OVS_FLOW_CMD_NEW,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = flow_policy,
@@ -1392,7 +1392,7 @@ static int ovs_dp_cmd_dump(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
-static struct genl_ops dp_datapath_genl_ops[] = {
+static const struct genl_ops dp_datapath_genl_ops[] = {
{ .cmd = OVS_DP_CMD_NEW,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = datapath_policy,
@@ -1753,7 +1753,7 @@ out:
return skb->len;
}
-static struct genl_ops dp_vport_genl_ops[] = {
+static const struct genl_ops dp_vport_genl_ops[] = {
{ .cmd = OVS_VPORT_CMD_NEW,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = vport_policy,
@@ -1779,7 +1779,7 @@ static struct genl_ops dp_vport_genl_ops[] = {
struct genl_family_and_ops {
struct genl_family *family;
- struct genl_ops *ops;
+ const struct genl_ops *ops;
int n_ops;
struct genl_multicast_group *group;
};
diff --git a/net/wimax/stack.c b/net/wimax/stack.c
index 4b7f15a..47170c9 100644
--- a/net/wimax/stack.c
+++ b/net/wimax/stack.c
@@ -415,7 +415,7 @@ static const struct nla_policy wimax_gnl_policy[WIMAX_GNL_ATTR_MAX + 1] = {
},
};
-static struct genl_ops wimax_gnl_ops[] = {
+static const struct genl_ops wimax_gnl_ops[] = {
{
.cmd = WIMAX_GNL_OP_MSG_FROM_USER,
.flags = GENL_ADMIN_PERM,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index a7f4e79..7a92c45 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8937,7 +8937,7 @@ static void nl80211_post_doit(struct genl_ops *ops, struct sk_buff *skb,
rtnl_unlock();
}
-static struct genl_ops nl80211_ops[] = {
+static const struct genl_ops nl80211_ops[] = {
{
.cmd = NL80211_CMD_GET_WIPHY,
.doit = nl80211_get_wiphy,
--
1.8.4.rc3
^ permalink raw reply related
* RE: [PATCH] rds: Error on offset mismatch if not loopback
From: Venkat Venkatsubra @ 2013-11-14 13:43 UTC (permalink / raw)
To: Honggang LI, Josh Hunt; +Cc: David Miller, jjolly, LKML, netdev
In-Reply-To: <52841F95.7040204@redhat.com>
-----Original Message-----
From: Honggang LI [mailto:honli@redhat.com]
Sent: Wednesday, November 13, 2013 6:56 PM
To: Josh Hunt; Venkat Venkatsubra
Cc: David Miller; jjolly@suse.com; LKML; netdev@vger.kernel.org
Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
On 11/14/2013 01:40 AM, Josh Hunt wrote:
> On Wed, Nov 13, 2013 at 9:16 AM, Venkat Venkatsubra
> <venkat.x.venkatsubra@oracle.com> wrote:
>>
>> -----Original Message-----
>> From: Josh Hunt [mailto:joshhunt00@gmail.com]
>> Sent: Tuesday, November 12, 2013 10:25 PM
>> To: David Miller
>> Cc: jjolly@suse.com; LKML; Venkat Venkatsubra; netdev@vger.kernel.org
>> Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
>>
>> On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt <joshhunt00@gmail.com> wrote:
>>> On Sat, Sep 22, 2012 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: John Jolly <jjolly@suse.com>
>>>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>>>
>>>>> Attempting an rds connection from the IP address of an IPoIB
>>>>> interface to itself causes a kernel panic due to a BUG_ON() being triggered.
>>>>> Making the test less strict allows rds-ping to work without
>>>>> crashing the machine.
>>>>>
>>>>> A local unprivileged user could use this flaw to crash the system.
>>>>>
>>>>> Signed-off-by: John Jolly <jjolly@suse.com>
>>>> Besides the questions being asked of you by Venkat Venkatsubra,
>>>> this patch has another issue.
>>>>
>>>> It has been completely corrupted by your email client, it has
>>>> turned all TAB characters into spaces, making the patch useless.
>>>>
>>>> Please learn how to send a patch unmolested in the body of your
>>>> email. Test it by emailing the patch to yourself, and verifying
>>>> that you can in fact apply the patch you receive in that email.
>>>> Then, and only then, should you consider making a new submission of
>>>> this patch.
>>>>
>>>> Use Documentation/email-clients.txt for guidance.
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>> I think this issue was lost in the shuffle. It appears that redhat,
>>> ubuntu, and oracle are maintaining local patches to resolve this:
>>>
>>> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d636
>>> 85
>>> 2be130fa15fa8be10d4704e8
>>> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>> http://ubuntu.5.x6.nabble.com/CVE-2012-2372-RDS-local-ping-DOS-td498
>>> 53
>>> 88.html
>>>
>>> Given that Oracle has applied it I'll make the assumption that
>>> Venkat's question was answered at some point.
>>>
>>> David - I can resubmit the patch with the proper signed-off-by and
>>> formatting if you are willing to apply it unless John wants to try
>>> again. I think it's time this got upstream.
>>>
>>> --
>>> Josh
>> Ugh.. hopefully resending with all the html crap removed...
>>
>> --
>> Josh
>>
>> Hi Josh,
>>
>> No, I still didn't get an answer for how "off" could be non-zero in case of rds-ping to hit BUG_ON(off % RDS_FRAG_SIZE).
>> Because, rds-ping uses zero byte messages to ping.
>> If you have a test case that reproduces the kernel panic I can try it out and see how that can happen.
>> The Oracle's internal code I checked doesn't have that patch applied.
>>
>> Venkat
> No I don't have a test case. I came across this CVE while doing an
> audit and noticed it was patched in Ubuntu's kernel and other distros,
> but was not in the upstream kernel yet. Quick googling of lkml showed
> that there were at least two attempts to get this patch upstream, but
> both had issues due to not following the proper submission process:
>
> https://lkml.org/lkml/2012/10/22/433
> https://lkml.org/lkml/2012/9/21/505
>
> From my searching it appears the initial bug was found by someone at redhat:
> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>
> I've added Li Honggang the reporter of this issue from Redhat to the
> mail. Hopefully he can share his testcase.
The test case is very simple:
Steps to Reproduce:
1. yum install -y rds-tools
2. [root@rdma3 ~]# ifconfig ib0 | grep 'inet addr'
inet addr:172.31.0.3 Bcast:172.31.0.255 Mask:255.255.255.0
3. [root@rdma3 ~]# /usr/bin/rds-ping 172.31.0.3 <<<< kernel panic (You may need to wait for a few seconds before the kernel panic.)
>
> and possibly requires certain hardware as Jay writes in the first link above:
> "...some Infiniband HCAs(QLogic, possibly others) the machine will panic..."
This bug can be reproduced with Mellanox HCAs (mlx4_ib.ko and mthca.ko), QLogic HCA (ib_qib.ko). I did not test the QLogic HCA running "ib_ipath.ko".
As I know the upstream code of RDS is broken. There are *many* RDS bugs.
Best regards.
Honggang
>
> I was referring to this oracle commit:
> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d63685
> 2be130fa15fa8be10d4704e8
>
> I have no experience with this code. There were a few comments around
> the reset and xmit fns about making sure the caller did certain things
> if not they were racy, but I have no idea if that's coming into play
> here.
>
Hi Honggang,
I ran rds-ping over local interface for 30 minutes. I stopped it after that.
It didn't hit any panic.
# ip addr show dev ib0
6: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast qlen 1024
link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:21:28:00:01:cf:63:db brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet 10.196.4.125/30 brd 10.196.4.127 scope global ib0
inet6 fe80::221:2800:1cf:63db/64 scope link
valid_lft forever preferred_lft forever
#
# rds-ping 10.196.4.125
1: 170 usec
2: 171 usec
....
....
....
1860: 173 usec
1861: 171 usec
1862: 177 usec
1863: 168 usec
1864: 171 usec
1865: 175 usec
^C#
I tested with Oracle UEK2 which is based on 2.6.39 kernel. Mellanox IB adaptor.
19:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0)
There is something about your setup that must be causing it for you.
Can I work with you offline if you are available ?
The panic you are hitting is not making sense to me.
Venkat
^ permalink raw reply
* Re: [PATCH] rds: fix local ping DoS
From: Josh Hunt @ 2013-11-14 13:45 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, venkat.x.venkatsubra@oracle.com,
linux-kernel@vger.kernel.org, jjolly@suse.com,
fenlason@redhat.com, honli@redhat.com
In-Reply-To: <20131114.020355.1973894145326845195.davem@davemloft.net>
On 11/14/2013 01:03 AM, David Miller wrote:
> From: Josh Hunt <johunt@akamai.com>
> Date: Wed, 13 Nov 2013 17:15:43 -0800
>
>> The rds_ib_xmit function in net/rds/ib_send.c in the Reliable Datagram Sockets
>> (RDS) protocol implementation allows local users to cause a denial of service
>> (BUG_ON and kernel panic) by establishing an RDS connection with the source
>> IP address equal to the IPoIB interface's own IP address, as demonstrated by
>> rds-ping.
>>
>> A local unprivileged user could use this flaw to crash the system.
>>
>> CVE-2012-2372
>>
>> Reported-by: Honggang Li <honli@redhat.com>
>> Signed-off-by: Josh Hunt <johunt@akamai.com>
>
> I'm sorry I can't apply this. This commit message needs to be much
> less terse and explain things more.
>
> First of all, why is the "off % RDS_FRAG_SIZE" important?
>
> And, even more importantly, why is is OK to avoid this assertion just
> because we're going over loopback?
>
> Furthermore, why doesn't net/rds/iw_send.c:rds_iw_xmit() have the same
> exact problem? It makes the same exact assertion check.
>
> I know this RDS code is a steaming pile of poo, but that doesn't mean
> we just randomly adjust assertions to make crashes go away without
> sufficient understanding of exactly what's going on.
>
> Thanks.
>
Sure understandable questions. Unfortunately I don't have the hardware
to properly debug and analyze. I was just trying to get this through on
the assumption that the previous attempts just failed due to incorrect
submission procedures and lack of a reproducible testcase. If nothing
else this whole thing brought out the testcase :)
Testcase from Honggang's earlier mail:
<snip>
The test case is very simple:
Steps to Reproduce:
1. yum install -y rds-tools
2. [root@rdma3 ~]# ifconfig ib0 | grep 'inet addr'
inet addr:172.31.0.3 Bcast:172.31.0.255 Mask:255.255.255.0
3. [root@rdma3 ~]# /usr/bin/rds-ping 172.31.0.3 <<<< kernel panic (You
may need to wait for a few seconds before the kernel panic.)
This bug can be reproduced with Mellanox HCAs (mlx4_ib.ko and mthca.ko),
QLogic HCA (ib_qib.ko). I did not test the QLogic HCA running "ib_ipath.ko".
</snip>
Perhaps Venkat or someone else with the hardware mentioned can provide a
better explanation and better solution to the crash.
Josh
^ permalink raw reply
* Re: [PATCH] net: sctp: bug-fixing: retran_path not set properly after transports recovering (v3)
From: Neil Horman @ 2013-11-14 13:55 UTC (permalink / raw)
To: Chang Xiangzhong; +Cc: vyasevich, davem, linux-sctp, netdev
In-Reply-To: <1384387106-8105-1-git-send-email-changxiangzhong@gmail.com>
On Thu, Nov 14, 2013 at 12:58:26AM +0100, Chang Xiangzhong wrote:
> When a transport recovers due to the new coming sack, SCTP should
> iterate all of its transport_list to locate the __two__ most recently used
> transport and set to active_path and retran_path respectively. The exising
> code does not find the two properly - In case of the following list:
>
> [most-recent] -> [2nd-most-recent] -> ...
>
> Both active_path and retran_path would be set to the 1st element.
>
> The bug happens when:
> 1) multi-homing
> 2) failure/partial_failure transport recovers
> Both active_path and retran_path would be set to the same most-recent one, in
> other words, retran_path would not take its role - an end user might not even
> notice this issue.
>
> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH net v2 0/2] macvlan: disable LRO on lowerdev instead of a macvlan
From: Michal Kubecek @ 2013-11-14 14:00 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
A customer of ours encountered a problem with LRO on an ixgbe network
card. Analysis showed that it was a known conflict of forwarding and LRO
but the forwarding was enabled in an LXC container where only a macvlan
was, not the ethernet device itself.
I believe the solution is exactly the same as what we do for "normal"
(802.1q) VLAN devices: if dev_disable_lro() is called for such device,
LRO is disabled on the underlying "real" device instead.
v2: adapt to changes merged from net-next
Michal Kubecek (2):
macvlan: introduce macvlan_dev_real_dev() helper function
macvlan: disable LRO on lower device instead of macvlan
include/linux/if_macvlan.h | 16 ++++++++++++++++
net/core/dev.c | 5 +++++
2 files changed, 21 insertions(+)
--
1.8.1.4
^ permalink raw reply
* [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: Michal Kubecek @ 2013-11-14 14:00 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <cover.1384436410.git.mkubecek@suse.cz>
Introduce helper function macvlan_dev_real_dev which returns the
underlying device of a macvlan device, similar to vlan_dev_real_dev()
for 802.1q VLAN devices.
v2: IFF_MACVLAN flag and equivalent of is_macvlan_dev() were
introduced in the meantime
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
include/linux/if_macvlan.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index c270285..ac9aab2 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -119,4 +119,20 @@ extern int macvlan_link_register(struct rtnl_link_ops *ops);
extern netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
struct net_device *dev);
+#if IS_ENABLED(CONFIG_MACVLAN)
+static inline struct net_device *
+macvlan_dev_real_dev(const struct net_device *dev)
+{
+ struct macvlan_dev *macvlan = netdev_priv(dev);
+
+ return macvlan->lowerdev;
+}
+#else
+static inline struct net_device *
+macvlan_dev_real_dev(const struct net_device *dev)
+{
+ return NULL;
+}
+#endif
+
#endif /* _LINUX_IF_MACVLAN_H */
--
1.8.1.4
^ permalink raw reply related
* [PATCH net v2 2/2] macvlan: disable LRO on lower device instead of macvlan
From: Michal Kubecek @ 2013-11-14 14:00 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <cover.1384436410.git.mkubecek@suse.cz>
A macvlan device has always LRO disabled so that calling
dev_disable_lro() on it does nothing. If we need to disable LRO
e.g. because
- the macvlan device is inserted into a bridge
- IPv6 forwarding is enabled for it
- it is in a different namespace than lowerdev and IPv4
forwarding is enabled in it
we need to disable LRO on its underlying device instead (as we
do for 802.1q VLAN devices).
v2: use newly introduced netif_is_macvlan()
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
net/core/dev.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 974143d..7e00a73 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -131,6 +131,7 @@
#include <linux/static_key.h>
#include <linux/hashtable.h>
#include <linux/vmalloc.h>
+#include <linux/if_macvlan.h>
#include "net-sysfs.h"
@@ -1424,6 +1425,10 @@ void dev_disable_lro(struct net_device *dev)
if (is_vlan_dev(dev))
dev = vlan_dev_real_dev(dev);
+ /* the same for macvlan devices */
+ if (netif_is_macvlan(dev))
+ dev = macvlan_dev_real_dev(dev);
+
dev->wanted_features &= ~NETIF_F_LRO;
netdev_update_features(dev);
--
1.8.1.4
^ permalink raw reply related
* [RFC 9/7] genetlink: make genl_ops flags a u8 and move to end
From: Johannes Berg @ 2013-11-14 14:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
To save some space in the struct on 32-bit systems,
make the flags a u8 (only 4 bits are used) and also
move them to the end of the struct.
This has no impact on 64-bit systems as alignment of
the struct in an array uses up the space anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/genetlink.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index 0b6b10b..eddcdf2 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -110,15 +110,15 @@ static inline void genl_info_net_set(struct genl_info *info, struct net *net)
* @ops_list: operations list
*/
struct genl_ops {
- u8 cmd;
- u8 internal_flags;
- unsigned int flags;
const struct nla_policy *policy;
int (*doit)(struct sk_buff *skb,
struct genl_info *info);
int (*dumpit)(struct sk_buff *skb,
struct netlink_callback *cb);
int (*done)(struct netlink_callback *cb);
+ u8 cmd;
+ u8 internal_flags;
+ u8 flags;
};
int __genl_register_family(struct genl_family *family);
--
1.8.4.rc3
^ permalink raw reply related
* Re: IPv6: Blackhole route support partial ?
From: Hannes Frederic Sowa @ 2013-11-14 14:11 UTC (permalink / raw)
To: Kamala R; +Cc: davem, linux-kernel, netdev
In-Reply-To: <CAP8BHkEyASA52Q4Zg4w5OqR7Hv7Y_it8SnG_tMPViza_T9TV+Q@mail.gmail.com>
Hi!
On Thu, Nov 14, 2013 at 01:50:20PM +0530, Kamala R wrote:
> I have one quick question before I send the patch across. I noticed
> that "ip -6 route show" shows an error -22 in the output which
> signifies -EINVAL associated with blackhole routes. This behaviour is
> not consistent with that of "ip route show" that shows no such error
> for a blackhole route. Does this qualify a bug that needs fixing ?
You mean that we don't show the error for IPv4 routes? Is this a kernel or
iproute problem?
Greetings,
Hannes
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-14 14:27 UTC (permalink / raw)
To: Veaceslav Falico, Vlad Yasevich; +Cc: Stefan Priebe, Linux Netdev List
In-Reply-To: <20131114115451.GT19702@redhat.com>
On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>> Can you try out attached patch please. I ran it in my environment and
>> always get promisc link when attaching devices to the bridge.
>
> It's interesting, actually, why do we need to check for IFF_UP at all when
> changing flags.
>
> The addition of IFF_UP goes up to:
>
> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
> Author: Patrick McHardy <kaber@trash.net>
> Date: Tue Oct 7 15:26:48 2008 -0700
>
> net: only invoke dev->change_rx_flags when device is UP
>
> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
> VLAN
> device down that is in promiscous mode:
>
> When the VLAN device is set down, the promiscous count on the real
> device is decremented by one by vlan_dev_stop(). When removing the
> promiscous flag from the VLAN device afterwards, the promiscous
> count on the real device is decremented a second time by the
> vlan_change_rx_flags() callback.
>
> ... snip ...
>
This was applied in 2.6.27 timeframe.
> However, I'm not sure that this is still needed, cause:
>
> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
> Author: Matthijs Kooijman <matthijs@stdin.nl>
> Date: Mon Oct 31 04:53:13 2011 +0000
>
> vlan: Don't propagate flag changes on down interfaces.
>
> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
> IFF_PROMISC
> flags are cleared or set on the underlying interface. So, if these
> flags
> are changed on a vlan interface that is not up, the flags underlying
> interface might be set or cleared twice.
>
> Only propagating flag changes when a device is up makes sure this does
> not happen. It also makes sure that an underlying device is not set to
> promiscuous or allmulti mode for a vlan device that is down.
>
> ... snip ...
>
And this in 3.2. So how did this work for Stefan in 3.9? Unless there
is something in Ubuntu that changed how the stacked interfaces are
configured and is keeping interfaces down longer then it used to.
> which fixed completely the initial issue with vlans.
>
> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(), and
> let the drivers using it handle its own logic, as vlan does?
>
This should work, but this might regress a few drivers. Looking through
the callers of dev_set_promiscuity at least DSA driver suffers
the same fate as VLAN.
-vlad
> Something like this:
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8ffc52e..9615cd7 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
> *dev, int flags)
> {
> const struct net_device_ops *ops = dev->netdev_ops;
>
> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
> + if (ops->ndo_change_rx_flags)
> ops->ndo_change_rx_flags(dev, flags);
> }
>
>
>>
>> Thanks
>> -vlad
^ permalink raw reply
* Re: [PATCH iproute2] htb: support 64bit rates
From: Eric Dumazet @ 2013-11-14 14:28 UTC (permalink / raw)
To: Yang Yingliang; +Cc: Stephen Hemminger, netdev
In-Reply-To: <528485D0.5030300@huawei.com>
On Thu, 2013-11-14 at 16:12 +0800, Yang Yingliang wrote:
> On 2013/11/13 6:34, Eric Dumazet wrote:
>
> [...]
> > @@ -256,6 +270,7 @@ static int htb_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
> > struct tc_htb_glob *gopt;
> > double buffer,cbuffer;
> > unsigned int linklayer;
> > + __u64 rate64, ceil64;
> > SPRINT_BUF(b1);
> > SPRINT_BUF(b2);
> > SPRINT_BUF(b3);
> > @@ -275,12 +290,25 @@ static int htb_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
> > if (show_details)
> > fprintf(f, "quantum %d ", (int)hopt->quantum);
> > }
> > - fprintf(f, "rate %s ", sprint_rate(hopt->rate.rate, b1));
> > +
> > + rate64 = hopt->rate.rate;
> > + if (tb[TCA_HTB_RATE64] &&
> > + RTA_PAYLOAD(tb[TCA_HTB_RATE64]) >= sizeof(rate64)) {
> > + rate64 = rta_getattr_u64(tb[TCA_HTB_RATE64]);
> > + }
> > +
>
> If RTA_PAYLOAD(tb[TCA_HTB_RATE64]) < sizeof(rate64),
> it means something wrong, it don't need to continue,
> "return -1" would be better.
Nothing wrong actually.
Checking for these conditions are absolutely normal, to maintain
compatibility between old/new tc and or kernels.
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-14 14:29 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico, Vlad Yasevich; +Cc: Linux Netdev List
In-Reply-To: <5284DDCE.4090901@gmail.com>
Am 14.11.2013 15:27, schrieb Vlad Yasevich:
> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>> Can you try out attached patch please. I ran it in my environment and
>>> always get promisc link when attaching devices to the bridge.
>>
>> It's interesting, actually, why do we need to check for IFF_UP at all
>> when
>> changing flags.
>>
>> The addition of IFF_UP goes up to:
>>
>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>> Author: Patrick McHardy <kaber@trash.net>
>> Date: Tue Oct 7 15:26:48 2008 -0700
>>
>> net: only invoke dev->change_rx_flags when device is UP
>>
>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
>> VLAN
>> device down that is in promiscous mode:
>>
>> When the VLAN device is set down, the promiscous count on the real
>> device is decremented by one by vlan_dev_stop(). When removing the
>> promiscous flag from the VLAN device afterwards, the promiscous
>> count on the real device is decremented a second time by the
>> vlan_change_rx_flags() callback.
>>
>> ... snip ...
>>
>
> This was applied in 2.6.27 timeframe.
>
>> However, I'm not sure that this is still needed, cause:
>>
>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>> Date: Mon Oct 31 04:53:13 2011 +0000
>>
>> vlan: Don't propagate flag changes on down interfaces.
>>
>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>> IFF_PROMISC
>> flags are cleared or set on the underlying interface. So, if these
>> flags
>> are changed on a vlan interface that is not up, the flags underlying
>> interface might be set or cleared twice.
>>
>> Only propagating flag changes when a device is up makes sure this
>> does
>> not happen. It also makes sure that an underlying device is not
>> set to
>> promiscuous or allmulti mode for a vlan device that is down.
>>
>> ... snip ...
>>
>
> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
> is something in Ubuntu that changed how the stacked interfaces are
> configured and is keeping interfaces down longer then it used to.
Stop here ;-) in 3.9 it was the other way round.
This one worked:
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 \ vmbr1.3000
> \ ---- tap114i1
this one did not:
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 ----- bond1.3000 --- vmbr1v3000
> \ ---- tap114i1
Now with the patch - the 2nd one works the first one does not.
Stefan
>> which fixed completely the initial issue with vlans.
>>
>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>> and
>> let the drivers using it handle its own logic, as vlan does?
>>
>
> This should work, but this might regress a few drivers. Looking through
> the callers of dev_set_promiscuity at least DSA driver suffers
> the same fate as VLAN.
>
> -vlad
>
>> Something like this:
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 8ffc52e..9615cd7 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>> *dev, int flags)
>> {
>> const struct net_device_ops *ops = dev->netdev_ops;
>>
>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>> + if (ops->ndo_change_rx_flags)
>> ops->ndo_change_rx_flags(dev, flags);
>> }
>>
>>
>>>
>>> Thanks
>>> -vlad
>
^ permalink raw reply
* Re: [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Hannes Frederic Sowa @ 2013-11-14 14:31 UTC (permalink / raw)
To: David Miller
Cc: nicolas.dichtel, netdev, David.Laight, jiri, vyasevich, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <20131111.001803.110603937316567461.davem@davemloft.net>
On Mon, Nov 11, 2013 at 12:18:03AM -0500, David Miller wrote:
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Sat, 9 Nov 2013 01:54:34 +0100
>
> > This feature allows to a send packets with address source set to 0.0.0.0 even if
> > an ip address is available on another interface.
> >
> > It's useful for DHCP client, to allow them to use UDP sockets and be compliant
> > with the RFC2131, Section 4.1:
> >
> > 4.1 Constructing and sending DHCP messages
> > ...
> > DHCP messages broadcast by a client prior to that client obtaining
> > its IP address must have the source address field in the IP header
> > set to 0.
> >
> > Based on a previous work from
> > Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
> >
> > Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> This requirement of the RFC is inconsistent with a host based
> addressing model, that which Linux employs, it assumes an interface
> based one.
>
> The wording here is also very ambiguous.
>
> This RFC fails to even remotely consider what the right behavior
> should be in a host based addressing environment at all, and anyone
> reading this RFC should just accept that.
>
> Furthermore, the fact that you're implementing _addressing_ policy in
> the UDP code makes this change even more unreasonable.
I agree on this and will check how other operating systems which only
use sockets do deal with that.
Do you have an idea how to deal with the rp_filter issue if no ip address is
set? Should we relax it in such cases?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH iproute2] htb: support 64bit rates
From: Eric Dumazet @ 2013-11-14 14:32 UTC (permalink / raw)
To: Yang Yingliang; +Cc: Stephen Hemminger, netdev
In-Reply-To: <528483CE.6050100@huawei.com>
On Thu, 2013-11-14 at 16:03 +0800, Yang Yingliang wrote:
> On 2013/11/13 22:21, Eric Dumazet wrote:
> > On Wed, 2013-11-13 at 17:11 +0800, Yang Yingliang wrote:
> >>> - if (!buffer) buffer = opt.rate.rate / get_hz() + mtu;
> >>> - if (!cbuffer) cbuffer = opt.ceil.rate / get_hz() + mtu;
> >>> + if (!buffer)
> >>> + buffer = rate64 / get_hz() + mtu;
> >>> + if (!cbuffer)
> >>> + cbuffer = ceil64 / get_hz() + mtu;
> >>
> >> Hi,
> >> It may overflow here if rate64 and mtu are big enough.
> >
> > Not really.
> >
> > get_hz() on current kernels is really huge : 1000000000
>
> Yeah, in normal condition, it won't happen.
> If user make a wrong input, such as "rate 0x800000000Gbit",
> Overflow happens. Although it has no impact on the value of the "opt.buffer".
> If it's better to have a judgement of the buffer's value. :)
Oh well, I can see you never really used HTB on high rates.
I'll send a v2 so that you can feel better ;)
^ permalink raw reply
* [PATCH 2/2] netfilter: synproxy: correct wscale option passing
From: Martin Topholm @ 2013-11-14 14:35 UTC (permalink / raw)
To: pablo; +Cc: brouer, kaber, netfilter-devel, netdev
In-Reply-To: <1384439731-16296-1-git-send-email-mph@one.com>
Timestamp are used to store additional syncookie parameters such as sack,
ecn, and wscale. The wscale value we need to encode is the client's
wscale, since we can't recover that later in the session. Next overwrite
the wscale option so the later synproxy_send_client_synack will send
the backend's wscale to the client.
Signed-off-by: Martin Topholm <mph@one.com>
Reviewed-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/netfilter/nf_synproxy_core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
index cdf4567..9858e3e 100644
--- a/net/netfilter/nf_synproxy_core.c
+++ b/net/netfilter/nf_synproxy_core.c
@@ -151,9 +151,10 @@ void synproxy_init_timestamp_cookie(const struct xt_synproxy_info *info,
opts->tsecr = opts->tsval;
opts->tsval = tcp_time_stamp & ~0x3f;
- if (opts->options & XT_SYNPROXY_OPT_WSCALE)
- opts->tsval |= info->wscale;
- else
+ if (opts->options & XT_SYNPROXY_OPT_WSCALE) {
+ opts->tsval |= opts->wscale;
+ opts->wscale = info->wscale;
+ } else
opts->tsval |= 0xf;
if (opts->options & XT_SYNPROXY_OPT_SACK_PERM)
^ permalink raw reply related
* Re: [RFC 0/7] genetlink: reduce ops size and complexity
From: Johannes Berg @ 2013-11-14 14:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
On Thu, 2013-11-14 at 10:14 +0100, Johannes Berg wrote:
> This series of patches updates a few genetlink users and then
> makes the ops a static const array, reducing kernel size and
> code complexity.
FWIW, for the full series (including patches 8 and 9) we get
drivers/net/team/team.c | 2
drivers/net/wireless/mac80211_hwsim.c | 2
include/net/genetlink.h | 17 +---
kernel/taskstats.c | 39 +++------
net/core/drop_monitor.c | 2
net/hsr/hsr_netlink.c | 46 ++++-------
net/ieee802154/ieee802154.h | 19 ++++
net/ieee802154/netlink.c | 28 +++++--
net/ieee802154/nl-mac.c | 61 ++-------------
net/ieee802154/nl-phy.c | 37 +--------
net/ipv4/tcp_metrics.c | 2
net/irda/irnetlink.c | 2
net/l2tp/l2tp_netlink.c | 2
net/netfilter/ipvs/ip_vs_ctl.c | 2
net/netlabel/netlabel_cipso_v4.c | 2
net/netlabel/netlabel_mgmt.c | 2
net/netlabel/netlabel_unlabeled.c | 2
net/netlink/genetlink.c | 133
+++++++++-------------------------
net/nfc/netlink.c | 2
net/openvswitch/datapath.c | 10 +-
net/wimax/op-msg.c | 25 ------
net/wimax/op-reset.c | 17 ----
net/wimax/op-rfkill.c | 21 -----
net/wimax/op-state-get.c | 17 ----
net/wimax/stack.c | 79 ++++++++++----------
net/wimax/wimax-internal.h | 7 +
net/wireless/nl80211.c | 2
27 files changed, 190 insertions(+), 390 deletions(-)
johannes
^ 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