* Re: [PATCH bluetooth-next] ieee802154: cc2520: Fix space before , coding style issue
From: Varka Bhadram @ 2015-01-26 14:05 UTC (permalink / raw)
To: Mohammad Jamal, alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1422021327-18815-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Jamal,
On Friday 23 January 2015 07:25 PM, Mohammad Jamal wrote:
> This patch removes the warnings (space before , ) shown by
> checkpatch.pl
Thanks for the patch.
Acked-by: Varka Bhadram <varkabhadram@gmail.com>
>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index a43c8ac..665a3db 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
> @@ -549,14 +549,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
> u8 rssi;
> int ret;
>
> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
> if (ret)
> return ret;
>
> if (status != RSSI_VALID)
> return -EINVAL;
>
> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
> if (ret)
> return ret;
>
--
Thanks and Regards,
Varka Bhadram.
^ permalink raw reply
* [PATCH net] ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
From: Hannes Frederic Sowa @ 2015-01-26 14:11 UTC (permalink / raw)
To: netdev; +Cc: lkundrak
Lubomir Rintel reported that during replacing a route the interface
reference counter isn't correctly decremented.
To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
| [root@rhel7-5 lkundrak]# sh -x lal
| + ip link add dev0 type dummy
| + ip link set dev0 up
| + ip link add dev1 type dummy
| + ip link set dev1 up
| + ip addr add 2001:db8:8086::2/64 dev dev0
| + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
| + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
| + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
| + ip link del dev0 type dummy
| Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
|
| Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
During replacement of a rt6_info we must walk all parent nodes and check
if the to be replaced rt6_info got propagated. If so, replace it with
an alive one.
Reported-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/ip6_fib.c | 45 ++++++++++++++++++++++++++-------------------
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 53775ee..263ef41 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -661,6 +661,29 @@ static int fib6_commit_metrics(struct dst_entry *dst, struct mx6_config *mxc)
return 0;
}
+static void fib6_purge_rt(struct rt6_info *rt, struct fib6_node *fn,
+ struct net *net)
+{
+ if (atomic_read(&rt->rt6i_ref) != 1) {
+ /* This route is used as dummy address holder in some split
+ * nodes. It is not leaked, but it still holds other resources,
+ * which must be released in time. So, scan ascendant nodes
+ * and replace dummy references to this route with references
+ * to still alive ones.
+ */
+ while (fn) {
+ if (!(fn->fn_flags & RTN_RTINFO) && fn->leaf == rt) {
+ fn->leaf = fib6_find_prefix(net, fn);
+ atomic_inc(&fn->leaf->rt6i_ref);
+ rt6_release(rt);
+ }
+ fn = fn->parent;
+ }
+ /* No more references are possible at this point. */
+ BUG_ON(atomic_read(&rt->rt6i_ref) != 1);
+ }
+}
+
/*
* Insert routing information in a node.
*/
@@ -808,11 +831,12 @@ add:
rt->dst.rt6_next = iter->dst.rt6_next;
atomic_inc(&rt->rt6i_ref);
inet6_rt_notify(RTM_NEWROUTE, rt, info);
- rt6_release(iter);
if (!(fn->fn_flags & RTN_RTINFO)) {
info->nl_net->ipv6.rt6_stats->fib_route_nodes++;
fn->fn_flags |= RTN_RTINFO;
}
+ fib6_purge_rt(iter, fn, info->nl_net);
+ rt6_release(iter);
}
return 0;
@@ -1323,24 +1347,7 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
fn = fib6_repair_tree(net, fn);
}
- if (atomic_read(&rt->rt6i_ref) != 1) {
- /* This route is used as dummy address holder in some split
- * nodes. It is not leaked, but it still holds other resources,
- * which must be released in time. So, scan ascendant nodes
- * and replace dummy references to this route with references
- * to still alive ones.
- */
- while (fn) {
- if (!(fn->fn_flags & RTN_RTINFO) && fn->leaf == rt) {
- fn->leaf = fib6_find_prefix(net, fn);
- atomic_inc(&fn->leaf->rt6i_ref);
- rt6_release(rt);
- }
- fn = fn->parent;
- }
- /* No more references are possible at this point. */
- BUG_ON(atomic_read(&rt->rt6i_ref) != 1);
- }
+ fib6_purge_rt(rt, fn, net);
inet6_rt_notify(RTM_DELROUTE, rt, info);
rt6_release(rt);
--
2.1.0
^ permalink raw reply related
* [PATCH net-next] vxlan: advertise link netns in fdb messages
From: Nicolas Dichtel @ 2015-01-26 13:10 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel
Previous commit is based on a wrong assumption, fdb messages are always sent
into the netns where the interface stands (see vxlan_fdb_notify()).
These fdb messages doesn't embed the rtnl attribute IFLA_LINK_NETNSID, thus we
need to add it (useful to interpret NDA_IFINDEX or NDA_DST for example).
Note also that vxlan_nlmsg_size() was not updated.
Fixes: 193523bf9373 ("vxlan: advertise netns of vxlan dev in fdb msg")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Note that NDA_NDM_IFINDEX_NETNSID exists only in net-next, thus it's still
possible to remove it.
drivers/net/vxlan.c | 5 +++--
include/uapi/linux/neighbour.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 19d3664ab9dd..c20a71fdcfa3 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -340,8 +340,8 @@ static int vxlan_fdb_info(struct sk_buff *skb, struct vxlan_dev *vxlan,
ndm->ndm_type = RTN_UNICAST;
if (!net_eq(dev_net(vxlan->dev), vxlan->net) &&
- nla_put_s32(skb, NDA_NDM_IFINDEX_NETNSID,
- peernet2id(vxlan->net, dev_net(vxlan->dev))))
+ nla_put_s32(skb, NDA_LINK_NETNSID,
+ peernet2id(dev_net(vxlan->dev), vxlan->net)))
goto nla_put_failure;
if (send_eth && nla_put(skb, NDA_LLADDR, ETH_ALEN, &fdb->eth_addr))
@@ -384,6 +384,7 @@ static inline size_t vxlan_nlmsg_size(void)
+ nla_total_size(sizeof(__be16)) /* NDA_PORT */
+ nla_total_size(sizeof(__be32)) /* NDA_VNI */
+ nla_total_size(sizeof(__u32)) /* NDA_IFINDEX */
+ + nla_total_size(sizeof(__s32)) /* NDA_LINK_NETNSID */
+ nla_total_size(sizeof(struct nda_cacheinfo));
}
diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
index 38f236853cc0..3873a35509aa 100644
--- a/include/uapi/linux/neighbour.h
+++ b/include/uapi/linux/neighbour.h
@@ -25,7 +25,7 @@ enum {
NDA_VNI,
NDA_IFINDEX,
NDA_MASTER,
- NDA_NDM_IFINDEX_NETNSID,
+ NDA_LINK_NETNSID,
__NDA_MAX
};
--
2.2.2
^ permalink raw reply related
* Re: [PATCH 3/3] net: allwinner: sun4i-emac: fix emac SRAM mapping
From: Jens Kuske @ 2015-01-26 14:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Arnd Bergmann, Lee Jones, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20150125162510.GK8470@lukather>
Hi,
On 25/01/15 17:25, Maxime Ripard wrote:
> Hi Jens,
>
> On Sun, Jan 25, 2015 at 04:49:19PM +0100, Jens Kuske wrote:
>> The EMAC needs SRAM block A3_A4 being mapped to EMAC peripheral to
>> work. This is done by the bootloader most of the time, but U-Boot
>> Falcon Mode, for example, skips emac initialization and SRAM would
>> stay mapped to the CPU.
>
> Thanks for reviving this.
>
>> Signed-off-by: Jens Kuske <jenskuske-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> drivers/net/ethernet/allwinner/Kconfig | 1 +
>> drivers/net/ethernet/allwinner/sun4i-emac.c | 18 ++++++++++++++++++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/allwinner/Kconfig b/drivers/net/ethernet/allwinner/Kconfig
>> index d8d95d4..508a288 100644
>> --- a/drivers/net/ethernet/allwinner/Kconfig
>> +++ b/drivers/net/ethernet/allwinner/Kconfig
>> @@ -28,6 +28,7 @@ config SUN4I_EMAC
>> select MII
>> select PHYLIB
>> select MDIO_SUN4I
>> + select MFD_SYSCON
>> ---help---
>> Support for Allwinner A10 EMAC ethernet driver.
>>
>> diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
>> index 1fcd556..86c891d 100644
>> --- a/drivers/net/ethernet/allwinner/sun4i-emac.c
>> +++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
>> @@ -18,6 +18,8 @@
>> #include <linux/gpio.h>
>> #include <linux/interrupt.h>
>> #include <linux/irq.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/mfd/syscon/sun4i-sc.h>
>> #include <linux/mii.h>
>> #include <linux/module.h>
>> #include <linux/netdevice.h>
>> @@ -28,6 +30,7 @@
>> #include <linux/of_platform.h>
>> #include <linux/platform_device.h>
>> #include <linux/phy.h>
>> +#include <linux/regmap.h>
>>
>> #include "sun4i-emac.h"
>>
>> @@ -78,6 +81,7 @@ struct emac_board_info {
>>
>> struct phy_device *phy_dev;
>> struct device_node *phy_node;
>> + struct regmap *sc;
>> unsigned int link;
>> unsigned int speed;
>> unsigned int duplex;
>> @@ -862,6 +866,18 @@ static int emac_probe(struct platform_device *pdev)
>> goto out;
>> }
>>
>> + /* Map SRAM_A3_A4 to EMAC */
>> + db->sc = syscon_regmap_lookup_by_compatible(
>> + "allwinner,sun4i-a10-syscon");
>> + if (IS_ERR(db->sc)) {
>> + dev_err(&pdev->dev, "failed to find syscon regmap\n");
>> + ret = PTR_ERR(db->sc);
>> + goto out;
>> + }
>> +
>> + regmap_update_bits(db->sc, SUN4I_SC1, SUN4I_SC1_SRAM_A3_A4_MAP_MASK,
>> + SUN4I_SC1_SRAM_A3_A4_MAP_EMAC);
>> +
>
> I don't think that using a syscon is the right solution here.
>
> All this SRAM mapping thing is mutually exclusive, and will possibly
> impact other drivers as well.
Each single SRAM area can only be mapped to a single peripheral, so as
long as the driver only changes bits related to his own area nothing can
go wrong I believe.
SRAM_C2 looks like it can be mapped do different devices (AE, CE, ACE),
but as far as I understand this, they are all related to the ACE device,
sharing a common register space, and would have to be handled by a
single driver anyway (if that will ever happen without docs)
https://linux-sunxi.org/ACE_Register_guide
> I think this is a more a case for a small driver in drivers/soc that
> would take care of this, and make sure that client drivers don't step
> on each other's toe.
I'm not convinced this is necessary, but what would this driver do
different than a basic regmap? Check if the area is already mapped by
any driver and deny mapping it again by a different driver? Which
different driver, each area is only interesting for a single
device/driver? Except maybe mapping it to CPU as general purpose sram,
but that would need some direct agreement with the driver to steal its
memory anyway.
Jens
^ permalink raw reply
* [PATCH 0/3] Restore UFO support to virtio_net devices
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: edumazet, mst, ben, virtualization
commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Thu Oct 30 18:27:12 2014 +0000
drivers/net: Disable UFO through virtio
Turned off UFO support to virtio-net based devices due to issues
with IPv6 fragment id generation for UFO packets. The issue
was that IPv6 UFO/GSO implementation expects the fragment id
to be supplied in skb_shinfo(). However, for packets generated
by the VMs, the fragment id is not supplied which causes all
IPv6 fragments to have the id of 0.
The problem is that turning off UFO support on tap/macvtap
as well as virtio devices caused issues with migrations.
Migrations would fail when moving a vm from a kernel supporting
expecting UFO to work to the newer kernels that disabled UFO.
This series provides a partial solution to address the migration
issue. The series reserves a bit in the skb and sets the bit
with the ipv6 fragment id has been generated for the packet.
UFO/GSO code then checks the bit to see if the fragment id
is already present or if a new fragment id needs to be generated.
This solution allows host-originated UFO packets to keep a
better randomized fragment id, as well as generating a randomized
id for VM generated traffic (solving the fragment id 0 issue).
Vladislav Yasevich (3):
ipv6: Select fragment id during UFO/GSO segmentation if not set.
Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
packets"
Revert "drivers/net: Disable UFO through virtio"
drivers/net/macvtap.c | 16 ++++++++--------
drivers/net/tun.c | 25 +++++++++----------------
drivers/net/virtio_net.c | 24 ++++++++++--------------
include/linux/skbuff.h | 3 ++-
include/net/ipv6.h | 2 ++
net/ipv6/ip6_output.c | 4 ++--
net/ipv6/output_core.c | 9 ++++++++-
net/ipv6/udp_offload.c | 10 +++++++++-
8 files changed, 50 insertions(+), 43 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: edumazet, mst, ben, virtualization
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
If the IPv6 fragment id has not been set and we perform
fragmentation due to UFO, select a new fragment id.
When we store the fragment id into skb_shinfo, set the bit
in the skb so we can re-use the selected id.
This preserves the behavior of UFO packets generated on the
host and solves the issue of id generation for packet sockets
and tap/macvtap devices.
This patch moves ipv6_select_ident() back in to the header file.
It also provides the helper function that sets skb_shinfo() frag
id and sets the bit.
It also makes sure that we select the fragment id when doing
just gso validation, since it's possible for the packet to
come from an untrusted source (VM) and be forwarded through
a UFO enabled device which will expect the fragment id.
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
include/linux/skbuff.h | 3 ++-
include/net/ipv6.h | 2 ++
net/ipv6/ip6_output.c | 4 ++--
net/ipv6/output_core.c | 9 ++++++++-
net/ipv6/udp_offload.c | 10 +++++++++-
5 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 85ab7d7..3ad5203 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -605,7 +605,8 @@ struct sk_buff {
__u8 ipvs_property:1;
__u8 inner_protocol_type:1;
__u8 remcsum_offload:1;
- /* 3 or 5 bit hole */
+ __u8 ufo_fragid_set:1;
+ /* 2 or 4 bit hole */
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 4292929..ca6137b 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -671,7 +671,9 @@ static inline int ipv6_addr_diff(const struct in6_addr *a1, const struct in6_add
return __ipv6_addr_diff(a1, a2, sizeof(struct in6_addr));
}
+void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt);
void ipv6_proxy_select_ident(struct sk_buff *skb);
+void ipv6_skb_set_fragid(struct sk_buff *skb, __be32 frag_id);
int ip6_dst_hoplimit(struct dst_entry *dst);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index ce69a12..b940b3f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -537,7 +537,7 @@ static void ip6_copy_metadata(struct sk_buff *to, struct sk_buff *from)
skb_copy_secmark(to, from);
}
-static void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
+void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
{
static u32 ip6_idents_hashrnd __read_mostly;
u32 hash, id;
@@ -1092,7 +1092,7 @@ static inline int ip6_ufo_append_data(struct sock *sk,
sizeof(struct frag_hdr)) & ~7;
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
ipv6_select_ident(&fhdr, rt);
- skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
+ ipv6_skb_set_fragid(skb, fhdr.identification);
append:
return skb_append_datato_frags(sk, skb, getfrag, from,
diff --git a/net/ipv6/output_core.c b/net/ipv6/output_core.c
index 97f41a3..68f879b 100644
--- a/net/ipv6/output_core.c
+++ b/net/ipv6/output_core.c
@@ -38,10 +38,17 @@ void ipv6_proxy_select_ident(struct sk_buff *skb)
hash = __ipv6_addr_jhash(&addrs[0], hash);
id = ip_idents_reserve(hash, 1);
- skb_shinfo(skb)->ip6_frag_id = htonl(id);
+ ipv6_skb_set_fragid(skb, htonl(id));
}
EXPORT_SYMBOL_GPL(ipv6_proxy_select_ident);
+void ipv6_skb_set_fragid(struct sk_buff *skb, __be32 frag_id)
+{
+ skb_shinfo(skb)->ip6_frag_id = frag_id;
+ skb->ufo_fragid_set = 1;
+}
+EXPORT_SYMBOL_GPL(ipv6_skb_set_fragid);
+
int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
{
u16 offset = sizeof(struct ipv6hdr);
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index b6aa8ed..7cda88d 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -52,6 +52,10 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
+ /* Set the IPv6 fragment id if not set yet */
+ if (!skb->ufo_fragid_set)
+ ipv6_proxy_select_ident(skb);
+
segs = NULL;
goto out;
}
@@ -108,7 +112,11 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
fptr->nexthdr = nexthdr;
fptr->reserved = 0;
- fptr->identification = skb_shinfo(skb)->ip6_frag_id;
+ if (!skb->ufo_fragid_set)
+ fptr->identification = skb_shinfo(skb)->ip6_frag_id;
+ else
+ ipv6_select_ident(fptr,
+ (struct rt6_info *)skb_dst(skb));
/* Fragment the skb. ipv6 header and the remaining fields of the
* fragment header are updated in ipv6_gso_segment()
--
1.9.3
^ permalink raw reply related
* [PATCH 3/3] Revert "drivers/net: Disable UFO through virtio"
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: edumazet, mst, ben, virtualization
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4.
Now that UFO functionality can correctly track the fragment
id has been selected and select a fragment id if necessary,
we can re-enable UFO on tap/macvap and virtio devices.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
drivers/net/macvtap.c | 13 ++++++++-----
drivers/net/tun.c | 19 ++++++++-----------
drivers/net/virtio_net.c | 24 ++++++++++--------------
3 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 0b86e46..919f4fc 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -80,7 +80,7 @@ static struct cdev macvtap_cdev;
static const struct proto_ops macvtap_socket_ops;
#define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
- NETIF_F_TSO6)
+ NETIF_F_TSO6 | NETIF_F_UFO)
#define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
@@ -585,8 +585,6 @@ static int macvtap_skb_from_vnet_hdr(struct macvtap_queue *q,
gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
- current->comm);
gso_type = SKB_GSO_UDP;
break;
default:
@@ -633,6 +631,8 @@ static void macvtap_skb_to_vnet_hdr(struct macvtap_queue *q,
vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (sinfo->gso_type & SKB_GSO_TCPV6)
vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (sinfo->gso_type & SKB_GSO_UDP)
+ vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
else
BUG();
if (sinfo->gso_type & SKB_GSO_TCP_ECN)
@@ -962,6 +962,9 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
if (arg & TUN_F_TSO6)
feature_mask |= NETIF_F_TSO6;
}
+
+ if (arg & TUN_F_UFO)
+ feature_mask |= NETIF_F_UFO;
}
/* tun/tap driver inverts the usage for TSO offloads, where
@@ -972,7 +975,7 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
* When user space turns off TSO, we turn off GSO/LRO so that
* user-space will not receive TSO frames.
*/
- if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6))
+ if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO))
features |= RX_OFFLOADS;
else
features &= ~RX_OFFLOADS;
@@ -1087,7 +1090,7 @@ static long macvtap_ioctl(struct file *file, unsigned int cmd,
case TUNSETOFFLOAD:
/* let the user check for future flags */
if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
- TUN_F_TSO_ECN))
+ TUN_F_TSO_ECN | TUN_F_UFO))
return -EINVAL;
rtnl_lock();
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 5ca42b7..10f9e40 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -186,7 +186,7 @@ struct tun_struct {
struct net_device *dev;
netdev_features_t set_features;
#define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO| \
- NETIF_F_TSO6)
+ NETIF_F_TSO6|NETIF_F_UFO)
int vnet_hdr_sz;
int sndbuf;
@@ -1176,18 +1176,8 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- {
- static bool warned;
-
- if (!warned) {
- warned = true;
- netdev_warn(tun->dev,
- "%s: using disabled UFO feature; please fix this program\n",
- current->comm);
- }
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
break;
- }
default:
tun->dev->stats.rx_frame_errors++;
kfree_skb(skb);
@@ -1294,6 +1284,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (sinfo->gso_type & SKB_GSO_TCPV6)
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (sinfo->gso_type & SKB_GSO_UDP)
+ gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else {
pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
@@ -1742,6 +1734,11 @@ static int set_offload(struct tun_struct *tun, unsigned long arg)
features |= NETIF_F_TSO6;
arg &= ~(TUN_F_TSO4|TUN_F_TSO6);
}
+
+ if (arg & TUN_F_UFO) {
+ features |= NETIF_F_UFO;
+ arg &= ~TUN_F_UFO;
+ }
}
/* This gives the user a way to test for new features in future by
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5ca9771..059fdf1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -490,17 +490,8 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- {
- static bool warned;
-
- if (!warned) {
- warned = true;
- netdev_warn(dev,
- "host using disabled UFO feature; please fix it\n");
- }
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
break;
- }
case VIRTIO_NET_HDR_GSO_TCPV6:
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
break;
@@ -888,6 +879,8 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
+ hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else
BUG();
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCP_ECN)
@@ -1748,7 +1741,7 @@ static int virtnet_probe(struct virtio_device *vdev)
dev->features |= NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST;
if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
- dev->hw_features |= NETIF_F_TSO
+ dev->hw_features |= NETIF_F_TSO | NETIF_F_UFO
| NETIF_F_TSO_ECN | NETIF_F_TSO6;
}
/* Individual feature bits: what can host handle? */
@@ -1758,9 +1751,11 @@ static int virtnet_probe(struct virtio_device *vdev)
dev->hw_features |= NETIF_F_TSO6;
if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_ECN))
dev->hw_features |= NETIF_F_TSO_ECN;
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UFO))
+ dev->hw_features |= NETIF_F_UFO;
if (gso)
- dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
+ dev->features |= dev->hw_features & (NETIF_F_ALL_TSO|NETIF_F_UFO);
/* (!csum && gso) case will be fixed by register_netdev() */
}
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
@@ -1798,7 +1793,8 @@ static int virtnet_probe(struct virtio_device *vdev)
/* If we can receive ANY GSO packets, we must allocate large ones. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6) ||
- virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN))
+ virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN) ||
+ virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UFO))
vi->big_packets = true;
if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
@@ -1994,9 +1990,9 @@ static struct virtio_device_id id_table[] = {
static unsigned int features[] = {
VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM,
VIRTIO_NET_F_GSO, VIRTIO_NET_F_MAC,
- VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_TSO6,
+ VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6,
VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
- VIRTIO_NET_F_GUEST_ECN,
+ VIRTIO_NET_F_GUEST_ECN, VIRTIO_NET_F_GUEST_UFO,
VIRTIO_NET_F_MRG_RXBUF, VIRTIO_NET_F_STATUS, VIRTIO_NET_F_CTRL_VQ,
VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] net: macb: allow deffered probe of the driver
From: Nicolas Ferre @ 2015-01-26 14:37 UTC (permalink / raw)
To: Nicolae Rosia, netdev@vger.kernel.org
In-Reply-To: <1421947441.717.4.camel@uti.ro>
Le 22/01/2015 18:31, Nicolae Rosia a écrit :
> The driver is trying to acquire clocks which maybe
> are not available yet. Allow the driver to request
> deffered probe by providing a probe function and
> registering it with module_platform_driver. [1]
> This patch is based on 3.19-rc5.
Do you have a use case for this need?
> [1] https://lkml.org/lkml/2013/9/23/118
>
> Signed-off-by: Nicolae Rosia <nicolae.rosia@certsign.ro>
But anyway, it's not harmful:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index 3767271..4dfcd66 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2148,7 +2148,7 @@ static void macb_probe_queues(void __iomem *mem,
> (*num_queues)++;
> }
>
> -static int __init macb_probe(struct platform_device *pdev)
> +static int macb_probe(struct platform_device *pdev)
> {
> struct macb_platform_data *pdata;
> struct resource *regs;
> @@ -2386,7 +2386,7 @@ err_out:
> return err;
> }
>
> -static int __exit macb_remove(struct platform_device *pdev)
> +static int macb_remove(struct platform_device *pdev)
> {
> struct net_device *dev;
> struct macb *bp;
> @@ -2449,7 +2449,8 @@ static int macb_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(macb_pm_ops, macb_suspend, macb_resume);
>
> static struct platform_driver macb_driver = {
> - .remove = __exit_p(macb_remove),
> + .probe = macb_probe,
> + .remove = macb_remove,
> .driver = {
> .name = "macb",
> .of_match_table = of_match_ptr(macb_dt_ids),
> @@ -2457,7 +2458,7 @@ static struct platform_driver macb_driver = {
> },
> };
>
> -module_platform_driver_probe(macb_driver, macb_probe);
> +module_platform_driver(macb_driver);
>
> MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/3] Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets"
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: virtualization, mst, ben, edumazet, Vladislav Yasevich
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
This reverts commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7.
Now that GSO layer can track if fragment id has been selected
and can allocate on if necessary, we don't need to do this in
tap and macvtap. This reverts most of the code and only keeps
the new ipv6 fragment id generation function that is still needed.
It also solves this issues for packet sockets which were
missed before.
Fixes: 3d0ad09412ff (drivers/net: Disable UFO through virtio)
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
drivers/net/macvtap.c | 3 ---
drivers/net/tun.c | 6 +-----
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 7df2217..0b86e46 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -17,7 +17,6 @@
#include <linux/fs.h>
#include <linux/uio.h>
-#include <net/ipv6.h>
#include <net/net_namespace.h>
#include <net/rtnetlink.h>
#include <net/sock.h>
@@ -589,8 +588,6 @@ static int macvtap_skb_from_vnet_hdr(struct macvtap_queue *q,
pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
current->comm);
gso_type = SKB_GSO_UDP;
- if (skb->protocol == htons(ETH_P_IPV6))
- ipv6_proxy_select_ident(skb);
break;
default:
return -EINVAL;
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16..5ca42b7 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -65,7 +65,6 @@
#include <linux/nsproxy.h>
#include <linux/virtio_net.h>
#include <linux/rcupdate.h>
-#include <net/ipv6.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
#include <net/rtnetlink.h>
@@ -1167,8 +1166,6 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
break;
}
- skb_reset_network_header(skb);
-
if (gso.gso_type != VIRTIO_NET_HDR_GSO_NONE) {
pr_debug("GSO!\n");
switch (gso.gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
@@ -1189,8 +1186,6 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
current->comm);
}
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
- if (skb->protocol == htons(ETH_P_IPV6))
- ipv6_proxy_select_ident(skb);
break;
}
default:
@@ -1221,6 +1216,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
}
+ skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
rxhash = skb_get_hash(skb);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Dan Williams @ 2015-01-26 15:03 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: David Miller, netdev, Vadim Kochan
In-Reply-To: <54C519B3.9050905@codeaurora.org>
On Sun, 2015-01-25 at 09:28 -0700, Harout Hedeshian wrote:
> On 01/25/2015 12:21 AM, Vadim Kochan wrote:
> > On Sat, Jan 24, 2015 at 11:14:32PM -0800, David Miller wrote:
> >> From: Harout Hedeshian <harouth@codeaurora.org>
> >> Date: Tue, 20 Jan 2015 10:06:05 -0700
> >>
> >>> The kernel forcefully applies MTU values received in router
> >>> advertisements provided the new MTU is less than the current. This
> >>> behavior is undesirable when the user space is managing the MTU.
> > Instead
> >>> a sysctl flag 'accept_ra_mtu' is introduced such that the user space
> >>> can control whether or not RA provided MTU updates should be applied.
> > The
> >>> default behavior is unchanged; user space must explicitly set this
> > flag
> >>> to 0 for RA MTUs to be ignored.
> >>>
> >>> Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
> >> Under what circumstances would userland ignore a router advertized
> >> MTU, and are the RFCs ok with this?
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Hi,
> >
> > I don't know if it make sense but I had the same use case when was
> > working on supporting IPv6 infrastructure for home gateway.
> > One of the provider had requirements to have ability set force IPv6 MTU
> > value via TR parameters and disable update it via RA.
> Hi David,
>
> We are optionally allowing the kernel shift this responsibility to the
> userland. The idea would be that the kernel would ignore it, not so much
> the userland. Just like Vadim, we may not want to use the MTU value
> which comes from the network. Instead, we get an MTU value from the
> cellular modem via configuration message, and that is the MTU we use.
Are you talking about an ethernet interface exposed by the modem, or a
separate network interface connected to a normal LAN? In the modem
case, why would the network-provided RA's MTU be incorrect, but the
modem's MTU be correct? If the normal LAN case, why would the modem's
MTU be correct for a different network that is broadcasting its own RAs?
Just curious...
Dan
> In any case, none of the RFCs state that the kernel must update the MTU
> and that the userland cannot. In fact, there is no mention of
> kernel/user space at all in the RFC for this particular RA message. What
> if someone wants to listen to these RA messages from userland and update
> the MTU? Surely, that won't violate the RFC. In such a case, the kernel
> is unnecessarily forcing policy on the user space.
>
> RFC4861 section 4.6.4 defines the MTU update option (RA option 5) for RA
> messages. I don't see any language where the receiver "MUST" apply this
> option. It merely states that the MTU value in the RA is "The
> recommended MTU for the link." The description goes on to point out why
> this option can be used by the router, but does not specifically enforce
> it. The only receive action specifically enforced by the RFC is that
> "This option MUST be silently ignored for other Neighbor Discovery
> messages."
>
> The risk of not applying the MTU updates is that packet may get dropped
> if path MTU discovery is disabled or broken on the network. HOWEVER,
> anyone explicitly setting accept_ra_mtu to 0 is already taking
> responsibility for enforcing the correct MTU. Since this patch by
> default does not change the kernel behavior, I don't see it breaking for
> users who are unaware of this option.
>
>
> Thanks,
> Harout
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: macb: allow deffered probe of the driver
From: Nicolae Rosia @ 2015-01-26 15:21 UTC (permalink / raw)
To: nicolas.ferre@atmel.com; +Cc: netdev@vger.kernel.org, michal.simek@xilinx.com
In-Reply-To: <54C6510C.8050002@atmel.com>
On Mon, 2015-01-26 at 15:37 +0100, Nicolas Ferre wrote:
> Do you have a use case for this need?
On my setup (Zynq Platform), the required clocks are
provided by a module which is loaded after this driver,
hence, the clock is not available at initialization time.
> But anyway, it's not harmful:
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thank you.
Best regards,
Nicolae Rosia
^ permalink raw reply
* Re: [PATCH 0/3] Restore UFO support to virtio_net devices
From: Michael S. Tsirkin @ 2015-01-26 15:28 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, virtualization, ben, edumazet, Vladislav Yasevich,
David Miller
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
On Mon, Jan 26, 2015 at 09:37:03AM -0500, Vladislav Yasevich wrote:
> commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
> Author: Ben Hutchings <ben@decadent.org.uk>
> Date: Thu Oct 30 18:27:12 2014 +0000
>
> drivers/net: Disable UFO through virtio
>
> Turned off UFO support to virtio-net based devices due to issues
> with IPv6 fragment id generation for UFO packets. The issue
> was that IPv6 UFO/GSO implementation expects the fragment id
> to be supplied in skb_shinfo(). However, for packets generated
> by the VMs, the fragment id is not supplied which causes all
> IPv6 fragments to have the id of 0.
>
> The problem is that turning off UFO support on tap/macvtap
> as well as virtio devices caused issues with migrations.
> Migrations would fail when moving a vm from a kernel supporting
> expecting UFO to work to the newer kernels that disabled UFO.
>
> This series provides a partial solution to address the migration
> issue. The series reserves a bit in the skb and sets the bit
> with the ipv6 fragment id has been generated for the packet.
> UFO/GSO code then checks the bit to see if the fragment id
> is already present or if a new fragment id needs to be generated.
> This solution allows host-originated UFO packets to keep a
> better randomized fragment id, as well as generating a randomized
> id for VM generated traffic (solving the fragment id 0 issue).
>
> Vladislav Yasevich (3):
> ipv6: Select fragment id during UFO/GSO segmentation if not set.
> Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
> packets"
> Revert "drivers/net: Disable UFO through virtio"
>
> drivers/net/macvtap.c | 16 ++++++++--------
> drivers/net/tun.c | 25 +++++++++----------------
> drivers/net/virtio_net.c | 24 ++++++++++--------------
> include/linux/skbuff.h | 3 ++-
> include/net/ipv6.h | 2 ++
> net/ipv6/ip6_output.c | 4 ++--
> net/ipv6/output_core.c | 9 ++++++++-
> net/ipv6/udp_offload.c | 10 +++++++++-
> 8 files changed, 50 insertions(+), 43 deletions(-)
Should also help a lot to put UDP performance where it was.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> --
> 1.9.3
^ permalink raw reply
* Re: [PATCH 0/3] Restore UFO support to virtio_net devices
From: Michael S. Tsirkin @ 2015-01-26 15:32 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: netdev, virtualization, edumazet, ben, David Miller
In-Reply-To: <20150126152842.GA5130@redhat.com>
On Mon, Jan 26, 2015 at 05:28:42PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 26, 2015 at 09:37:03AM -0500, Vladislav Yasevich wrote:
> > commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
> > Author: Ben Hutchings <ben@decadent.org.uk>
> > Date: Thu Oct 30 18:27:12 2014 +0000
> >
> > drivers/net: Disable UFO through virtio
> >
> > Turned off UFO support to virtio-net based devices due to issues
> > with IPv6 fragment id generation for UFO packets. The issue
> > was that IPv6 UFO/GSO implementation expects the fragment id
> > to be supplied in skb_shinfo(). However, for packets generated
> > by the VMs, the fragment id is not supplied which causes all
> > IPv6 fragments to have the id of 0.
> >
> > The problem is that turning off UFO support on tap/macvtap
> > as well as virtio devices caused issues with migrations.
> > Migrations would fail when moving a vm from a kernel supporting
> > expecting UFO to work to the newer kernels that disabled UFO.
> >
> > This series provides a partial solution to address the migration
> > issue. The series reserves a bit in the skb and sets the bit
> > with the ipv6 fragment id has been generated for the packet.
> > UFO/GSO code then checks the bit to see if the fragment id
> > is already present or if a new fragment id needs to be generated.
> > This solution allows host-originated UFO packets to keep a
> > better randomized fragment id, as well as generating a randomized
> > id for VM generated traffic (solving the fragment id 0 issue).
> >
> > Vladislav Yasevich (3):
> > ipv6: Select fragment id during UFO/GSO segmentation if not set.
> > Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
> > packets"
> > Revert "drivers/net: Disable UFO through virtio"
> >
> > drivers/net/macvtap.c | 16 ++++++++--------
> > drivers/net/tun.c | 25 +++++++++----------------
> > drivers/net/virtio_net.c | 24 ++++++++++--------------
> > include/linux/skbuff.h | 3 ++-
> > include/net/ipv6.h | 2 ++
> > net/ipv6/ip6_output.c | 4 ++--
> > net/ipv6/output_core.c | 9 ++++++++-
> > net/ipv6/udp_offload.c | 10 +++++++++-
> > 8 files changed, 50 insertions(+), 43 deletions(-)
>
> Should also help a lot to put UDP performance where it was.
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
BTW these might also be a good stable candidate.
>
> > --
> > 1.9.3
^ permalink raw reply
* Re: [PATCH net] ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
From: Lubomir Rintel @ 2015-01-26 15:36 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <131075b1c8770c414675094c292d394316e8cd17.1422281427.git.hannes@stressinduktion.org>
On Mon, 2015-01-26 at 15:11 +0100, Hannes Frederic Sowa wrote:
> Lubomir Rintel reported that during replacing a route the interface
> reference counter isn't correctly decremented.
>
> To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
> | [root@rhel7-5 lkundrak]# sh -x lal
> | + ip link add dev0 type dummy
> | + ip link set dev0 up
> | + ip link add dev1 type dummy
> | + ip link set dev1 up
> | + ip addr add 2001:db8:8086::2/64 dev dev0
> | + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
> | + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
> | + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
> | + ip link del dev0 type dummy
> | Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
> | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
> |
> | Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
> | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
>
> During replacement of a rt6_info we must walk all parent nodes and check
> if the to be replaced rt6_info got propagated. If so, replace it with
> an alive one.
>
> Reported-by: Lubomir Rintel <lkundrak@v3.sk>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> net/ipv6/ip6_fib.c | 45 ++++++++++++++++++++++++++-------------------
> 1 file changed, 26 insertions(+), 19 deletions(-)
Tested-by: Lubomir Rintel <lkundrak@v3.sk>
Thank you!
Lubo
^ permalink raw reply
* Re: [PATCH net] ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
From: Eric Dumazet @ 2015-01-26 16:02 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, lkundrak
In-Reply-To: <131075b1c8770c414675094c292d394316e8cd17.1422281427.git.hannes@stressinduktion.org>
On Mon, 2015-01-26 at 15:11 +0100, Hannes Frederic Sowa wrote:
> Lubomir Rintel reported that during replacing a route the interface
> reference counter isn't correctly decremented.
>
> To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
> | [root@rhel7-5 lkundrak]# sh -x lal
> | + ip link add dev0 type dummy
> | + ip link set dev0 up
> | + ip link add dev1 type dummy
> | + ip link set dev1 up
> | + ip addr add 2001:db8:8086::2/64 dev dev0
> | + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
> | + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
> | + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
> | + ip link del dev0 type dummy
> | Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
> | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
> |
> | Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
> | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
>
> During replacement of a rt6_info we must walk all parent nodes and check
> if the to be replaced rt6_info got propagated. If so, replace it with
> an alive one.
>
> Reported-by: Lubomir Rintel <lkundrak@v3.sk>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Hi Hannes
Was this bug added in commit 4a287eba2de395713d8b2b2aeaa69fa086832d34
("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support,
warn about missing CREATE flag") ?
Thanks !
^ permalink raw reply
* Re: [PATCH net] ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
From: Hannes Frederic Sowa @ 2015-01-26 16:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, lkundrak
In-Reply-To: <1422288129.29618.26.camel@edumazet-glaptop2.roam.corp.google.com>
On Mo, 2015-01-26 at 08:02 -0800, Eric Dumazet wrote:
> On Mon, 2015-01-26 at 15:11 +0100, Hannes Frederic Sowa wrote:
> > Lubomir Rintel reported that during replacing a route the interface
> > reference counter isn't correctly decremented.
> >
> > To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
> > | [root@rhel7-5 lkundrak]# sh -x lal
> > | + ip link add dev0 type dummy
> > | + ip link set dev0 up
> > | + ip link add dev1 type dummy
> > | + ip link set dev1 up
> > | + ip addr add 2001:db8:8086::2/64 dev dev0
> > | + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
> > | + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
> > | + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
> > | + ip link del dev0 type dummy
> > | Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
> > | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
> > |
> > | Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
> > | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
> >
> > During replacement of a rt6_info we must walk all parent nodes and check
> > if the to be replaced rt6_info got propagated. If so, replace it with
> > an alive one.
> >
> > Reported-by: Lubomir Rintel <lkundrak@v3.sk>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>
> Hi Hannes
>
> Was this bug added in commit 4a287eba2de395713d8b2b2aeaa69fa086832d34
> ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support,
> warn about missing CREATE flag") ?
Yes, this patch added the hunk which introduced this problem. Sorry, I
didn't bother to look into git history which patch was responsible,
because I thought it might well be there from the beginning of the
stack.
Fixes: 4a287eba2de3957 ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag")
^ permalink raw reply
* Re: [PATCH] net: macb: allow deffered probe of the driver
From: Nicolas Ferre @ 2015-01-26 16:08 UTC (permalink / raw)
To: Nicolae Rosia, Boris BREZILLON
Cc: netdev@vger.kernel.org, michal.simek@xilinx.com
In-Reply-To: <1422285264.2658.2.camel@uti.ro>
Le 26/01/2015 16:21, Nicolae Rosia a écrit :
> On Mon, 2015-01-26 at 15:37 +0100, Nicolas Ferre wrote:
>> Do you have a use case for this need?
> On my setup (Zynq Platform), the required clocks are
> provided by a module which is loaded after this driver,
> hence, the clock is not available at initialization time.
That's what I (actually Boris who I've consulted regarding this) felt.
Thanks for having confirmed this.
>> But anyway, it's not harmful:
>> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Thank you.
>
> Best regards,
> Nicolae Rosia
>
Bye,
--
Nicolas Ferre
^ permalink raw reply
* RE: [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-26 16:16 UTC (permalink / raw)
To: 'Dan Williams'
Cc: 'David Miller', netdev, 'Vadim Kochan'
In-Reply-To: <1422284628.2393.4.camel@dcbw.local>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Dan Williams
> Sent: Monday, January 26, 2015 8:04 AM
> To: Harout Hedeshian
> Cc: David Miller; netdev@vger.kernel.org; Vadim Kochan
> Subject: Re: [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable
> MTU updates from RA
>
> On Sun, 2015-01-25 at 09:28 -0700, Harout Hedeshian wrote:
> > On 01/25/2015 12:21 AM, Vadim Kochan wrote:
> > > On Sat, Jan 24, 2015 at 11:14:32PM -0800, David Miller wrote:
> > >> From: Harout Hedeshian <harouth@codeaurora.org>
> > >> Date: Tue, 20 Jan 2015 10:06:05 -0700
> > >>
> > >>> The kernel forcefully applies MTU values received in router
> > >>> advertisements provided the new MTU is less than the current. This
> > >>> behavior is undesirable when the user space is managing the MTU.
> > > Instead
> > >>> a sysctl flag 'accept_ra_mtu' is introduced such that the user
> > >>> space can control whether or not RA provided MTU updates should be
> applied.
> > > The
> > >>> default behavior is unchanged; user space must explicitly set this
> > > flag
> > >>> to 0 for RA MTUs to be ignored.
> > >>>
> > >>> Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
> > >> Under what circumstances would userland ignore a router advertized
> > >> MTU, and are the RFCs ok with this?
> > >> --
> > >> To unsubscribe from this list: send the line "unsubscribe netdev"
> > >> in the body of a message to majordomo@vger.kernel.org More
> > >> majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Hi,
> > >
> > > I don't know if it make sense but I had the same use case when was
> > > working on supporting IPv6 infrastructure for home gateway.
> > > One of the provider had requirements to have ability set force IPv6
> > > MTU value via TR parameters and disable update it via RA.
> > Hi David,
> >
> > We are optionally allowing the kernel shift this responsibility to the
> > userland. The idea would be that the kernel would ignore it, not so
> > much the userland. Just like Vadim, we may not want to use the MTU
> > value which comes from the network. Instead, we get an MTU value from
> > the cellular modem via configuration message, and that is the MTU we
> use.
>
> Are you talking about an ethernet interface exposed by the modem, or a
> separate network interface connected to a normal LAN? In the modem
> case, why would the network-provided RA's MTU be incorrect, but the
> modem's MTU be correct? If the normal LAN case, why would the modem's
> MTU be correct for a different network that is broadcasting its own RAs?
> Just curious...
>
> Dan
Hi Dan,
This is a really good question. In the case of a normal LAN, we will allow the kernel to handle the MTU values as they have been today (basically, keep the accept_ra_mtu=1). The issue is not really about the correctness of the RA MTU value (we assume this value is correct, otherwise we are in serious trouble).The issue is on the modem interfaces. To the modem, each protocol family is its own interface. This analogy breaks down for us in Linux because v4 and v6 are fundamentally the same net_device interface. From what I can tell, there is no /proc/sys/net/ipv4/conf/<dev>/mtu which means that IPv4 will take the MTU value from dev->mtu (see ipv4_mtu() ). In contrast, IPv6 maintains a separate MTU and will apply the RA MTUs such that they are less than the device's MTU (dev->mtu). For consist
ency, we have been asked to always pick the minimum value of the IPv4 and IPv6 MTU, and that will become the overall interface MTU. If the kernel goes and changes the V6 MTU without us knowing, the userland daemon which maintains the MTU parity will be out of sync. We *could* theoretically let the kernel apply RA MTU updates and we listen for netlink events, but that is unnecessarily complicated as we are already listening in multiple places for these MTU updates. Additionally, we have a problem where the default dev->mtu is 1500 bytes. If we have an IPv6-only network, then it is possible that the network will want to use an MTU > 1500 (esp. multimedia optimized carrier networks). Currently, ndisc.c compares the new MTU value with dev->mtu, if bigger, the RA is ignored. I don't see a goo
d alternative to this because there is no way for ndisc.c to know what the device's maximum physical capabilities are (or that we even want to use such a large MTU). Because of that, we have to have an out-of-band mechanism to adjust the interface MTU since we know that the hardware is capable of transmitting packets greater than 1500 bytes. Thus, instead of letting the kernel handle RA MTUs in some special circumstances, it is safer and cleaner to disable RA MTUs on the modem interface altogether and let userland pick the correct MTU.
One way to clean up this mess would be to make some changes in the way the kernel handles MTUs.
1. Make dev->mtu actually be the MTU the device is capable. For example, jumbo frame capable devices would set this to 9000 upon enumeration instead of 1500. This value would not be editable from userland. There would no longer be a need for driver to implement the MTU adjustment ndo.
2. *ALL* protocols must maintain their own MTU values. This would mean a new per-device proc entry for IPv4 at a minimum. The defaults of these values can remain 1500.
If we did this, then the kernel can apply RA MTUs > 1500, and we would get it for free (no changes in IPv6 code). IPv4 would be parity with IPv6 in terms of decoupling MTU from dev->mtu. This means userland can completely not care about the IPv6 MTU, and we can push back on the MTU consistency requirement. Of course, this is a pretty drastic change in interpretation of dev->mtu and would break a lot of userland utilities. Or maybe we leave #1 editable in userland so the utilities and IOCTLs still work, however, userland will now have to additionally adjust IPv4 MTU...
If the kernel community likes this approach, I would be happy to upload some patches which creates a new definition for IPv4 MTU. I think #1 will need more discussion.
If v4 and v6 were truly decoupled, then we could get rid of this minimum selection mess and special case handling for large IPv6 MTUs and this patch could go away.
Thanks,
Harout
^ permalink raw reply
* Re: [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Hannes Frederic Sowa @ 2015-01-26 16:19 UTC (permalink / raw)
To: David Miller; +Cc: harouth, netdev
In-Reply-To: <20150124.231432.1788575004982971514.davem@davemloft.net>
On Sa, 2015-01-24 at 23:14 -0800, David Miller wrote:
> From: Harout Hedeshian <harouth@codeaurora.org>
> Date: Tue, 20 Jan 2015 10:06:05 -0700
>
> > The kernel forcefully applies MTU values received in router
> > advertisements provided the new MTU is less than the current. This
> > behavior is undesirable when the user space is managing the MTU. Instead
> > a sysctl flag 'accept_ra_mtu' is introduced such that the user space
> > can control whether or not RA provided MTU updates should be applied. The
> > default behavior is unchanged; user space must explicitly set this flag
> > to 0 for RA MTUs to be ignored.
> >
> > Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
>
> Under what circumstances would userland ignore a router advertized
> MTU, and are the RFCs ok with this?
Sometimes those advertised MTUs are used to perform DoS attacks /
performance-degrading attacks (force generation of fragments e.g.) on
hosts. In larger, maybe non-controlled networks, it would be desirable
if one could disable acceptance of the MTU option.
Of course, there are similar issues with other options in RAs, too, but
mostly they result in more catastrophic connection failures. ;)
Bye,
Hannes
^ permalink raw reply
* [PATCH] net/9p: fix format string in p9_mount_tag_show()
From: Andrey Ryabinin @ 2015-01-26 16:48 UTC (permalink / raw)
To: linux-kernel
Cc: Aneesh Kumar K.V, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David S. Miller, v9fs-developer, netdev,
Andrey Ryabinin
Using "%s" for non-NULL terminated string is quite
dangerous, since this causes reading out of bounds.
chan->tag is non-NULL terminated, so precision
must be specified for printing it.
Fixes: 86c8437383ac ("net/9p: Add sysfs mount_tag file for virtio 9P device")
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
---
net/9p/trans_virtio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index daa749c..f0d5f90 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -504,7 +504,8 @@ static ssize_t p9_mount_tag_show(struct device *dev,
vdev = dev_to_virtio(dev);
chan = vdev->priv;
- return snprintf(buf, chan->tag_len + 1, "%s", chan->tag);
+ return snprintf(buf, chan->tag_len + 1, "%.*s",
+ chan->tag_len, chan->tag);
}
static DEVICE_ATTR(mount_tag, 0444, p9_mount_tag_show, NULL);
--
2.2.2
^ permalink raw reply related
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Hannes Frederic Sowa @ 2015-01-26 16:49 UTC (permalink / raw)
To: Brian Haley; +Cc: David Ahern, netdev
In-Reply-To: <54C2BA50.6080208@hp.com>
On Fr, 2015-01-23 at 16:17 -0500, Brian Haley wrote:
> On 01/23/2015 01:23 PM, David Ahern wrote:
>
> >>> Add a new sysctl to make this behavior optional. Setting defaults to flush
> >>> addresses to maintain backwards compatibility. When reset flushing is bypassed:
> >>>
> >>> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> >>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> >>> [root@f20 ~]# ip addr show dev eth1
> >>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
> >>> default qlen 1000
> >>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> >>> inet6 2000:11:1:1::1/64 scope global tentative
> >>> valid_lft forever preferred_lft forever
> >>> [root@f20 ~]# ip link set dev eth1 up
> >>> [root@f20 ~]# ip link set dev eth1 down
> >>> [root@f20 ~]# ip addr show dev eth1
> >>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
> >>> default qlen 1000
> >>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> >>> inet6 2000:11:1:1::1/64 scope global
> >>> valid_lft forever preferred_lft forever
> >>> inet6 fe80::4:11ff:fe22:3301/64 scope link
> >>> valid_lft forever preferred_lft forever
> >>
> >> I think this was brought up in a previous thread on this, but don't you have to
> >> do DAD on these addresses once the interface comes back up? Some other system
> >> could have come along, done DAD, succeeded, and is now using it. Or does the
> >> use of this flag assume the user is Ok without doing DAD, and will deal with the
> >> fallout?
> >
> > You have the same problem today, don't you? Current code allows an IPv6 address
> > to be configured on interface in the down state. The intent of this sysctl is to
> > allow that address to stay on an up-down cycle.
>
> Yes, looks like ndisc_send_skb() never returns any lower-level error back up to
> the caller, so it's assumed the Neighbour Advertisement is always sent.
> Although the address will be marked "tentative" until IFF_UP is set.
>
> > I don't have a strong IPv6 background so the first email thread and this RFC
> > patch are both asking first and foremost if there is any harm in this behavior.
> > None has been raised - so far. To maintain backwards compatibility this is a new
> > option which when reset allows the addresses to be retained (not flushed).
>
> Seems as though you're in an RFC grey area then. Personally, I'd do DAD, even
> though the possibility of a collision is always very small. But that's just my
> opinion.
I agree. If the interface is in a state where it doesn't listen for
other hosts doing DAD, we must initiate DAD for that address during
bringing the interface up.
I am even not so sure if this is a grey area. Anyway, the current
behavior is not best and we should change that if the kernel does not do
DAD on addresses added during ifdown. Hopefully people don't use this
trick. :)
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH] ethernet: fm10k: Actually drop 4 bits
From: Vick, Matthew @ 2015-01-26 16:58 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Alexander Duyck, Kirsher, Jeffrey T,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <87twzhknnl.fsf@rasmusvillemoes.dk>
On 1/23/15, 4:50 PM, "Rasmus Villemoes" <linux@rasmusvillemoes.dk> wrote:
>On Sat, Jan 24 2015, "Vick, Matthew" <matthew.vick@intel.com> wrote:
>
>> Good catch! I noticed this too and was getting a patch together to
>>address
>> this.
>>
>> The difference is that I was planning on not silently accepting an
>>invalid
>> VLAN ID to begin with and returning FM10K_ERR_PARAM if the VLAN was
>> invalid, which I think is a better approach for this situation. If it's
>> alright with you, I'll generate the patch shortly and credit you via
>>your
>> Reported-by.
>
>Sure, do what you think is best.
>
>Rasmus
Sounds good. I'll get the patch created and validated through Jeff's tree.
Cheers,
Matthew
^ permalink raw reply
* [PATCH 1/5] PCI: Add defines for max read request sizes
From: Rafał Miłecki @ 2015-01-26 17:05 UTC (permalink / raw)
To: Bjorn Helgaas, linux-pci
Cc: Matt Porter, Alexandre Bounine, Chris Metcalf, Bradley Grove,
linux-scsi, Realtek linux nic maintainers, netdev,
Rafał Miłecki
There are few drivers using magic numbers when operating with PCIe
capabilities and PCI_EXP_DEVCTL_READRQ. Define known values to allow
cleaning their code a bit.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
include/uapi/linux/pci_regs.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 4a1d0cc..efe3443 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -451,6 +451,10 @@
#define PCI_EXP_DEVCTL_AUX_PME 0x0400 /* Auxiliary Power PM Enable */
#define PCI_EXP_DEVCTL_NOSNOOP_EN 0x0800 /* Enable No Snoop */
#define PCI_EXP_DEVCTL_READRQ 0x7000 /* Max_Read_Request_Size */
+#define PCI_EXP_DEVCTL_READRQ_128B 0x0000 /* 128 Bytes */
+#define PCI_EXP_DEVCTL_READRQ_256B 0x1000 /* 256 Bytes */
+#define PCI_EXP_DEVCTL_READRQ_512B 0x2000 /* 512 Bytes */
+#define PCI_EXP_DEVCTL_READRQ_1024B 0x3000 /* 1024 Bytes */
#define PCI_EXP_DEVCTL_BCR_FLR 0x8000 /* Bridge Configuration Retry / FLR */
#define PCI_EXP_DEVSTA 10 /* Device Status */
#define PCI_EXP_DEVSTA_CED 0x0001 /* Correctable Error Detected */
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/5] r8169: use PCI define for max read request size
From: Rafał Miłecki @ 2015-01-26 17:06 UTC (permalink / raw)
To: Bjorn Helgaas, linux-pci
Cc: Realtek linux nic maintainers, netdev, Rafał Miłecki
In-Reply-To: <1422291922-12324-1-git-send-email-zajec5@gmail.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 14a1c5c..fa274e0 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4915,7 +4915,7 @@ static void r8168c_hw_jumbo_enable(struct rtl8169_private *tp)
RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) | Jumbo_En1);
- rtl_tx_performance_tweak(tp->pci_dev, 0x2 << MAX_READ_REQUEST_SHIFT);
+ rtl_tx_performance_tweak(tp->pci_dev, PCI_EXP_DEVCTL_READRQ_512B);
}
static void r8168c_hw_jumbo_disable(struct rtl8169_private *tp)
@@ -4948,7 +4948,7 @@ static void r8168e_hw_jumbo_enable(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, 0x3f);
RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) | 0x01);
- rtl_tx_performance_tweak(tp->pci_dev, 0x2 << MAX_READ_REQUEST_SHIFT);
+ rtl_tx_performance_tweak(tp->pci_dev, PCI_EXP_DEVCTL_READRQ_512B);
}
static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
@@ -4964,7 +4964,7 @@ static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
{
rtl_tx_performance_tweak(tp->pci_dev,
- (0x2 << MAX_READ_REQUEST_SHIFT) | PCI_EXP_DEVCTL_NOSNOOP_EN);
+ PCI_EXP_DEVCTL_READRQ_512B | PCI_EXP_DEVCTL_NOSNOOP_EN);
}
static void r8168b_0_hw_jumbo_disable(struct rtl8169_private *tp)
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH net-next 1/1] net: phy: unbind phy device from generic and specifical driver
From: Florian Fainelli @ 2015-01-26 17:14 UTC (permalink / raw)
To: Fugang Duan, davem; +Cc: netdev, s.hauer, bhutchings, stephen
In-Reply-To: <1422260045-22527-1-git-send-email-b38611@freescale.com>
On 26/01/15 00:14, Fugang Duan wrote:
> The current .phy_detach() function only unbind generic phy driver, which causes
> specifical driver suspend/resume function still work like Atheros AT803X PHYs.
>
> For example:
> ifconfig eth0 down
> echo mem > /sys/power/status
>
> After eth0 interface down, driver call phy_detach to unbind phy driver, and then
> do suspend/resume operation, at803x_suspend()/at803x_resume() functions still get
> called that call mdio bus read/write function. When eth0 interface down, MAC driver
> may close all clocks and mdio bus cannot work. So the issue happens.
I was just hitting this problem on Friday evening and was about to
submit a similar change. Thanks!
>
> The patch can unbind generic and specifical driver.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/phy/phy_device.c | 15 ++-------------
> 1 files changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 3fc91e8..8adbc5d 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -672,8 +672,6 @@ EXPORT_SYMBOL(phy_attach);
> */
> void phy_detach(struct phy_device *phydev)
> {
> - int i;
> -
> if (phydev->bus->dev.driver)
> module_put(phydev->bus->dev.driver->owner);
>
> @@ -681,17 +679,8 @@ void phy_detach(struct phy_device *phydev)
> phydev->attached_dev = NULL;
> phy_suspend(phydev);
>
> - /* If the device had no specific driver before (i.e. - it
> - * was using the generic driver), we unbind the device
> - * from the generic driver so that there's a chance a
> - * real driver could be loaded
> - */
> - for (i = 0; i < ARRAY_SIZE(genphy_driver); i++) {
> - if (phydev->dev.driver == &genphy_driver[i].driver) {
> - device_release_driver(&phydev->dev);
> - break;
> - }
> - }
> + if (phydev->dev.driver)
> + device_release_driver(&phydev->dev);
> }
> EXPORT_SYMBOL(phy_detach);
>
>
--
Florian
^ 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