* Re: [PATCH net-next 01/14] qed: Add CONFIG_QED_SRIOV
From: David Miller @ 2016-05-10 18:09 UTC (permalink / raw)
To: alexander.duyck; +Cc: Yuval.Mintz, netdev, Ariel.Elior
In-Reply-To: <CAKgT0UdvLpAxcCuNHZy6BJQyDiDOkpoJprjBXLM-43N5pGXOOg@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Tue, 10 May 2016 11:02:09 -0700
> On Tue, May 10, 2016 at 10:16 AM, Yuval Mintz <Yuval.Mintz@qlogic.com> wrote:
>> > From: Yuval Mintz <Yuval.Mintz@qlogic.com>
>>> Date: Mon, 9 May 2016 16:19:10 +0300
>>>
>>> > + /* bitmap indicating which fields hold valid values */
>>> > + aligned_u64 valid_bitmap;
>>>
>>> There is absolutely no reason to use aligned_u64 here. That type is for handling
>>> a specific issue in user facing APIs, which this is not.
>>
>> I'm not entirely convinced this is true; If we'll not enforce the alignment
>> of this 64-bit field, it's possible there will be differences between 32-bit
>> and 64-bit machines versions of this struct.
>> You have to recall that this is going to be copied via DMA between PF and VF,
>> so they must have the exact same representation of the structure.
>>
>> [If I'm wrong on the technical part here, please correct me; I vaguely
>> seem to recall that this was already discussed on bnx2x's implementation
>> of the hw-channel which also uses aligned u64 fields]
>
> I think your change does have an impact, I just don't know if you
> really realize what it will get you. Specifically what using the
> aligned_u64 is doing is forcing qed_bulletin_content to be u64 aligned
> and introducing two holes in qed_bulletin on 32 bit platforms where
> dma_addr_t might be 32 bit, and adding a 4 bytes of padding after
> size.
dma_addr_t is 32-bits on some 64-bit architectures too.
^ permalink raw reply
* Re: networking/ip-sysctl.txt: SRR or SSRR
From: David Miller @ 2016-05-10 18:13 UTC (permalink / raw)
To: lists; +Cc: netdev
In-Reply-To: <alpine.DEB.2.20.12.1605081823420.3193@trent.utfs.org>
From: Christian Kujau <lists@nerdbynature.de>
Date: Sun, 8 May 2016 18:23:59 -0700 (PDT)
> In Documentation/networking/ip-sysctl.txt, the accept_source_route
> parameter is described with:
>
> Accept packets with SRR option.
Every single variable name and function name dealing with this IP
option uses "srr", therefore I don't think we should adjust the
documentation either.
"srr" covers both the loose source route option and the strict source
route option.
Thanks.
^ permalink raw reply
* RE: [PATCH net-next 01/14] qed: Add CONFIG_QED_SRIOV
From: Yuval Mintz @ 2016-05-10 18:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ariel Elior
In-Reply-To: <20160510.140643.1891656073031893382.davem@davemloft.net>
> > I'm not entirely convinced this is true; If we'll not enforce the
> > alignment of this 64-bit field, it's possible there will be
> > differences between 32-bit and 64-bit machines versions of this struct.
> > You have to recall that this is going to be copied via DMA between PF
> > and VF, so they must have the exact same representation of the structure.
>
> Then use properly sized types to fill in all the space in the structure, that's how
> you guarantee layout, not aligned_u64. Also, do not use the packed attribute.
>
> struct foo {
> u32 x;
> u32 y;
> u64 z;
> };
>
> 'z' will always be 64-bit aligned.
Perhaps my bit-numeric is a bit weak - why is it so?
I.e., what prevents `z' from only being 32-bit aligned on a 32-bit machine?
Isn't it possible that (&x % 8) == 4, (&y % 8) == 0 and (&z % 8) == 4 on such a platform?
^ permalink raw reply
* Re: [PATCH 2/7] net: ircomm, cleanup TIOCGSERIAL
From: David Miller @ 2016-05-10 18:16 UTC (permalink / raw)
To: jslaby; +Cc: gregkh, linux-serial, linux-kernel, samuel, netdev
In-Reply-To: <1462777919-10367-2-git-send-email-jslaby@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Mon, 9 May 2016 09:11:54 +0200
> In ircomm_tty_get_serial_info, struct serial_struct is memset to 0 and
> then some members set to 0 explicitly.
>
> Remove the latter as it is obviously superfluous.
>
> And remove the retinfo check against NULL. copy_to_user will take care
> of that.
>
> Part of hub6 cleanup series.
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: pull-request: can-next 2016-05-09,pull-request: can-next 2016-05-09
From: David Miller @ 2016-05-10 18:19 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, linux-can
In-Reply-To: <5730639F.2030104@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 9 May 2016 12:17:03 +0200
> this is a pull request of 12 patches for net-next/master.
>
> Alexander Gerasiov and Nikita Edward Baruzdin each contribute a patch
> improving the sja1000 driver. Amitoj Kaur Chawla's patch converts the
> mcp251x driver to alloc_workqueue(). A patch by Oliver Hartkopp fixes
> the handling of CAN config options. Andreas Gröger improves the error
> handling in the janz-ican3 driver. The patch by Maximilian Schneider
> for the gs_usb improves probing of the USB driver. Finally there are 6
> improvement patches by Marek Vasut for the ifi CAN driver.
Pulled, thanks Marc.
^ permalink raw reply
* [PATCH net-next v4 0/2] net: vrf: Fixup PKTINFO to return enslaved device index
From: David Ahern @ 2016-05-10 18:19 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
Applications such as OSPF and BFD need the original ingress device not
the VRF device; the latter can be derived from the former. To that end
move the packet intercept from an rx handler that is invoked by
__netif_receive_skb_core to the ipv4 and ipv6 receive processing.
IPv6 already saves the skb_iif to the control buffer in ipv6_rcv. Since
the skb->dev has not been switched the cb has the enslaved device. Make
the same happen for IPv4 by adding the skb_iif to inet_skb_parm and set
it in ipv4 code after clearing the skb control buffer similar to IPv6.
>From there the pktinfo can just pull it from cb with the PKTINFO_SKB_CB
cast.
David Ahern (2):
net: l3mdev: Add hook in ip and ipv6
net: original ingress device index in PKTINFO
drivers/net/vrf.c | 189 ++++++++++++++++++++++------------------------
include/linux/ipv6.h | 17 ++++-
include/linux/netdevice.h | 2 +
include/net/ip.h | 1 +
include/net/l3mdev.h | 42 +++++++++++
include/net/tcp.h | 4 +-
net/core/dev.c | 3 +-
net/ipv4/ip_input.c | 8 ++
net/ipv4/ip_sockglue.c | 7 +-
net/ipv6/ip6_input.c | 7 ++
10 files changed, 178 insertions(+), 102 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH net-next 2/2] net: original ingress device index in PKTINFO
From: David Ahern @ 2016-05-10 18:19 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1462904391-1253-1-git-send-email-dsa@cumulusnetworks.com>
Applications such as OSPF and BFD need the original ingress device not
the VRF device; the latter can be derived from the former. To that end
add the skb_iif to inet_skb_parm and set it in ipv4 code after clearing
the skb control buffer similar to IPv6. From there the pktinfo can just
pull it from cb with the PKTINFO_SKB_CB cast.
The previous patch moving the skb->dev change to L3 means nothing else
is needed for IPv6; it just works.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
include/net/ip.h | 1 +
net/ipv4/ip_input.c | 1 +
net/ipv4/ip_sockglue.c | 7 ++++++-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 247ac82e9cf2..37165fba3741 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -36,6 +36,7 @@
struct sock;
struct inet_skb_parm {
+ int iif;
struct ip_options opt; /* Compiled IP options */
unsigned char flags;
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 37375eedeef9..4b351af3e67b 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -478,6 +478,7 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
/* Remove any debris in the socket control block */
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ IPCB(skb)->iif = skb->skb_iif;
/* Must drop socket now because of tproxy. */
skb_orphan(skb);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index bdb222c0c6a2..5805762d7fc7 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1193,7 +1193,12 @@ void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
ipv6_sk_rxinfo(sk);
if (prepare && skb_rtable(skb)) {
- pktinfo->ipi_ifindex = inet_iif(skb);
+ /* skb->cb is overloaded: prior to this point it is IP{6}CB
+ * which has interface index (iif) as the first member of the
+ * underlying inet{6}_skb_parm struct. This code then overlays
+ * PKTINFO_SKB_CB and in_pktinfo also has iif as the first
+ * element so the iif is picked up from the prior IPCB
+ */
pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb);
} else {
pktinfo->ipi_ifindex = 0;
--
2.1.4
^ permalink raw reply related
* [PATCH net-next v4 1/2] net: l3mdev: Add hook in ip and ipv6
From: David Ahern @ 2016-05-10 18:19 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1462904391-1253-1-git-send-email-dsa@cumulusnetworks.com>
Currently the VRF driver uses the rx_handler to switch the skb device
to the VRF device. Switching the dev prior to the ip / ipv6 layer
means the VRF driver has to duplicate IP/IPv6 processing which adds
overhead and makes features such as retaining the ingress device index
more complicated than necessary.
This patch moves the hook to the L3 layer just after the first NF_HOOK
for PRE_ROUTING. This location makes exposing the original ingress device
trivial (next patch) and allows adding other NF_HOOKs to the VRF driver
in the future.
dev_queue_xmit_nit is exported so that the VRF driver can cycle the skb
with the switched device through the packet taps to maintain current
behavior (tcpdump can be used on either the vrf device or the enslaved
devices).
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
v4
- removed extra line in if-else-if block in l3mdev_l3_rcv
- rebased to top of tree
v3
- reverted direct skb->data accesses caused by inadvertent drop of
65c38aa653c1 with forward port of this patch
v2
- add skb_l3mdev_slave helper for inet6_iif and tcp_v6_iif rather
than open coding the if case. Added benefit that the change compiles
out if CONFIG_NET_L3_MASTER_DEV is not enabled.
drivers/net/vrf.c | 189 ++++++++++++++++++++++------------------------
include/linux/ipv6.h | 17 ++++-
include/linux/netdevice.h | 2 +
include/net/l3mdev.h | 42 +++++++++++
include/net/tcp.h | 4 +-
net/core/dev.c | 3 +-
net/ipv4/ip_input.c | 7 ++
net/ipv6/ip6_input.c | 7 ++
8 files changed, 170 insertions(+), 101 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index c8db55aa8280..0ea29345eb2e 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -42,9 +42,6 @@
#define DRV_NAME "vrf"
#define DRV_VERSION "1.0"
-#define vrf_master_get_rcu(dev) \
- ((struct net_device *)rcu_dereference(dev->rx_handler_data))
-
struct net_vrf {
struct rtable *rth;
struct rt6_info *rt6;
@@ -60,90 +57,12 @@ struct pcpu_dstats {
struct u64_stats_sync syncp;
};
-/* neighbor handling is done with actual device; do not want
- * to flip skb->dev for those ndisc packets. This really fails
- * for multiple next protocols (e.g., NEXTHDR_HOP). But it is
- * a start.
- */
-#if IS_ENABLED(CONFIG_IPV6)
-static bool check_ipv6_frame(const struct sk_buff *skb)
-{
- const struct ipv6hdr *ipv6h;
- struct ipv6hdr _ipv6h;
- bool rc = true;
-
- ipv6h = skb_header_pointer(skb, 0, sizeof(_ipv6h), &_ipv6h);
- if (!ipv6h)
- goto out;
-
- if (ipv6h->nexthdr == NEXTHDR_ICMP) {
- const struct icmp6hdr *icmph;
- struct icmp6hdr _icmph;
-
- icmph = skb_header_pointer(skb, sizeof(_ipv6h),
- sizeof(_icmph), &_icmph);
- if (!icmph)
- goto out;
-
- switch (icmph->icmp6_type) {
- case NDISC_ROUTER_SOLICITATION:
- case NDISC_ROUTER_ADVERTISEMENT:
- case NDISC_NEIGHBOUR_SOLICITATION:
- case NDISC_NEIGHBOUR_ADVERTISEMENT:
- case NDISC_REDIRECT:
- rc = false;
- break;
- }
- }
-
-out:
- return rc;
-}
-#else
-static bool check_ipv6_frame(const struct sk_buff *skb)
-{
- return false;
-}
-#endif
-
-static bool is_ip_rx_frame(struct sk_buff *skb)
-{
- switch (skb->protocol) {
- case htons(ETH_P_IP):
- return true;
- case htons(ETH_P_IPV6):
- return check_ipv6_frame(skb);
- }
- return false;
-}
-
static void vrf_tx_error(struct net_device *vrf_dev, struct sk_buff *skb)
{
vrf_dev->stats.tx_errors++;
kfree_skb(skb);
}
-/* note: already called with rcu_read_lock */
-static rx_handler_result_t vrf_handle_frame(struct sk_buff **pskb)
-{
- struct sk_buff *skb = *pskb;
-
- if (is_ip_rx_frame(skb)) {
- struct net_device *dev = vrf_master_get_rcu(skb->dev);
- struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
-
- u64_stats_update_begin(&dstats->syncp);
- dstats->rx_pkts++;
- dstats->rx_bytes += skb->len;
- u64_stats_update_end(&dstats->syncp);
-
- skb->dev = dev;
-
- return RX_HANDLER_ANOTHER;
- }
- return RX_HANDLER_PASS;
-}
-
static struct rtnl_link_stats64 *vrf_get_stats64(struct net_device *dev,
struct rtnl_link_stats64 *stats)
{
@@ -506,28 +425,14 @@ static int do_vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
{
int ret;
- /* register the packet handler for slave ports */
- ret = netdev_rx_handler_register(port_dev, vrf_handle_frame, dev);
- if (ret) {
- netdev_err(port_dev,
- "Device %s failed to register rx_handler\n",
- port_dev->name);
- goto out_fail;
- }
-
ret = netdev_master_upper_dev_link(port_dev, dev, NULL, NULL);
if (ret < 0)
- goto out_unregister;
+ return ret;
port_dev->priv_flags |= IFF_L3MDEV_SLAVE;
cycle_netdev(port_dev);
return 0;
-
-out_unregister:
- netdev_rx_handler_unregister(port_dev);
-out_fail:
- return ret;
}
static int vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
@@ -544,8 +449,6 @@ static int do_vrf_del_slave(struct net_device *dev, struct net_device *port_dev)
netdev_upper_dev_unlink(port_dev, dev);
port_dev->priv_flags &= ~IFF_L3MDEV_SLAVE;
- netdev_rx_handler_unregister(port_dev);
-
cycle_netdev(port_dev);
return 0;
@@ -670,6 +573,95 @@ static int vrf_get_saddr(struct net_device *dev, struct flowi4 *fl4)
}
#if IS_ENABLED(CONFIG_IPV6)
+/* neighbor handling is done with actual device; do not want
+ * to flip skb->dev for those ndisc packets. This really fails
+ * for multiple next protocols (e.g., NEXTHDR_HOP). But it is
+ * a start.
+ */
+static bool ipv6_ndisc_frame(const struct sk_buff *skb)
+{
+ const struct ipv6hdr *iph = ipv6_hdr(skb);
+ bool rc = false;
+
+ if (iph->nexthdr == NEXTHDR_ICMP) {
+ const struct icmp6hdr *icmph;
+ struct icmp6hdr _icmph;
+
+ icmph = skb_header_pointer(skb, sizeof(*iph),
+ sizeof(_icmph), &_icmph);
+ if (!icmph)
+ goto out;
+
+ switch (icmph->icmp6_type) {
+ case NDISC_ROUTER_SOLICITATION:
+ case NDISC_ROUTER_ADVERTISEMENT:
+ case NDISC_NEIGHBOUR_SOLICITATION:
+ case NDISC_NEIGHBOUR_ADVERTISEMENT:
+ case NDISC_REDIRECT:
+ rc = true;
+ break;
+ }
+ }
+
+out:
+ return rc;
+}
+
+static struct sk_buff *vrf_ip6_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ /* if packet is NDISC keep the ingress interface */
+ if (!ipv6_ndisc_frame(skb)) {
+ skb->dev = vrf_dev;
+ skb->skb_iif = vrf_dev->ifindex;
+
+ skb_push(skb, skb->mac_len);
+ dev_queue_xmit_nit(skb, vrf_dev);
+ skb_pull(skb, skb->mac_len);
+
+ IP6CB(skb)->flags |= IP6SKB_L3SLAVE;
+ }
+
+ return skb;
+}
+
+#else
+static struct sk_buff *vrf_ip6_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ return skb;
+}
+#endif
+
+static struct sk_buff *vrf_ip_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ skb->dev = vrf_dev;
+ skb->skb_iif = vrf_dev->ifindex;
+
+ skb_push(skb, skb->mac_len);
+ dev_queue_xmit_nit(skb, vrf_dev);
+ skb_pull(skb, skb->mac_len);
+
+ return skb;
+}
+
+/* called with rcu lock held */
+static struct sk_buff *vrf_l3_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb,
+ u16 proto)
+{
+ switch (proto) {
+ case AF_INET:
+ return vrf_ip_rcv(vrf_dev, skb);
+ case AF_INET6:
+ return vrf_ip6_rcv(vrf_dev, skb);
+ }
+
+ return skb;
+}
+
+#if IS_ENABLED(CONFIG_IPV6)
static struct dst_entry *vrf_get_rt6_dst(const struct net_device *dev,
const struct flowi6 *fl6)
{
@@ -690,6 +682,7 @@ static const struct l3mdev_ops vrf_l3mdev_ops = {
.l3mdev_fib_table = vrf_fib_table,
.l3mdev_get_rtable = vrf_get_rtable,
.l3mdev_get_saddr = vrf_get_saddr,
+ .l3mdev_l3_rcv = vrf_l3_rcv,
#if IS_ENABLED(CONFIG_IPV6)
.l3mdev_get_rt6_dst = vrf_get_rt6_dst,
#endif
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 58d6e158755f..5c91b0b055d4 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -118,14 +118,29 @@ struct inet6_skb_parm {
#define IP6SKB_ROUTERALERT 8
#define IP6SKB_FRAGMENTED 16
#define IP6SKB_HOPBYHOP 32
+#define IP6SKB_L3SLAVE 64
};
+#if defined(CONFIG_NET_L3_MASTER_DEV)
+static inline bool skb_l3mdev_slave(__u16 flags)
+{
+ return flags & IP6SKB_L3SLAVE;
+}
+#else
+static inline bool skb_l3mdev_slave(__u16 flags)
+{
+ return false;
+}
+#endif
+
#define IP6CB(skb) ((struct inet6_skb_parm*)((skb)->cb))
#define IP6CBMTU(skb) ((struct ip6_mtuinfo *)((skb)->cb))
static inline int inet6_iif(const struct sk_buff *skb)
{
- return IP6CB(skb)->iif;
+ bool l3_slave = skb_l3mdev_slave(IP6CB(skb)->flags);
+
+ return l3_slave ? skb->skb_iif : IP6CB(skb)->iif;
}
struct tcp6_request_sock {
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 63580e6d0df4..c2f5112f08f7 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3258,6 +3258,8 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
bool is_skb_forwardable(const struct net_device *dev,
const struct sk_buff *skb);
+void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev);
+
extern int netdev_budget;
/* Called by rtnetlink.c:rtnl_unlock() */
diff --git a/include/net/l3mdev.h b/include/net/l3mdev.h
index 78872bd1dc2c..374388dc01c8 100644
--- a/include/net/l3mdev.h
+++ b/include/net/l3mdev.h
@@ -25,6 +25,8 @@
struct l3mdev_ops {
u32 (*l3mdev_fib_table)(const struct net_device *dev);
+ struct sk_buff * (*l3mdev_l3_rcv)(struct net_device *dev,
+ struct sk_buff *skb, u16 proto);
/* IPv4 ops */
struct rtable * (*l3mdev_get_rtable)(const struct net_device *dev,
@@ -134,6 +136,34 @@ int l3mdev_get_saddr(struct net *net, int ifindex, struct flowi4 *fl4);
struct dst_entry *l3mdev_get_rt6_dst(struct net *net, const struct flowi6 *fl6);
+static inline
+struct sk_buff *l3mdev_l3_rcv(struct sk_buff *skb, u16 proto)
+{
+ struct net_device *master = NULL;
+
+ if (netif_is_l3_slave(skb->dev))
+ master = netdev_master_upper_dev_get_rcu(skb->dev);
+ else if (netif_is_l3_master(skb->dev))
+ master = skb->dev;
+
+ if (master && master->l3mdev_ops->l3mdev_l3_rcv)
+ skb = master->l3mdev_ops->l3mdev_l3_rcv(master, skb, proto);
+
+ return skb;
+}
+
+static inline
+struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb)
+{
+ return l3mdev_l3_rcv(skb, AF_INET);
+}
+
+static inline
+struct sk_buff *l3mdev_ip6_rcv(struct sk_buff *skb)
+{
+ return l3mdev_l3_rcv(skb, AF_INET6);
+}
+
#else
static inline int l3mdev_master_ifindex_rcu(const struct net_device *dev)
@@ -194,6 +224,18 @@ struct dst_entry *l3mdev_get_rt6_dst(struct net *net, const struct flowi6 *fl6)
{
return NULL;
}
+
+static inline
+struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb)
+{
+ return skb;
+}
+
+static inline
+struct sk_buff *l3mdev_ip6_rcv(struct sk_buff *skb)
+{
+ return skb;
+}
#endif
#endif /* _NET_L3MDEV_H_ */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 4775a1bba7f7..405dca0c7431 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -786,7 +786,9 @@ struct tcp_skb_cb {
*/
static inline int tcp_v6_iif(const struct sk_buff *skb)
{
- return TCP_SKB_CB(skb)->header.h6.iif;
+ bool l3_slave = skb_l3mdev_slave(TCP_SKB_CB(skb)->header.h6.flags);
+
+ return l3_slave ? skb->skb_iif : TCP_SKB_CB(skb)->header.h6.iif;
}
#endif
diff --git a/net/core/dev.c b/net/core/dev.c
index c7490339315c..12436d1312ca 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1850,7 +1850,7 @@ static inline bool skb_loop_sk(struct packet_type *ptype, struct sk_buff *skb)
* taps currently in use.
*/
-static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
+void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
{
struct packet_type *ptype;
struct sk_buff *skb2 = NULL;
@@ -1907,6 +1907,7 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
rcu_read_unlock();
}
+EXPORT_SYMBOL_GPL(dev_queue_xmit_nit);
/**
* netif_setup_tc - Handle tc mappings on real_num_tx_queues change
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 751c0658e194..37375eedeef9 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -313,6 +313,13 @@ static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
const struct iphdr *iph = ip_hdr(skb);
struct rtable *rt;
+ /* if ingress device is enslaved to an L3 master device pass the
+ * skb to its handler for processing
+ */
+ skb = l3mdev_ip_rcv(skb);
+ if (!skb)
+ return NET_RX_SUCCESS;
+
if (net->ipv4.sysctl_ip_early_demux &&
!skb_dst(skb) &&
!skb->sk &&
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 6ed56012005d..f185cbcda114 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -49,6 +49,13 @@
int ip6_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
{
+ /* if ingress device is enslaved to an L3 master device pass the
+ * skb to its handler for processing
+ */
+ skb = l3mdev_ip6_rcv(skb);
+ if (!skb)
+ return NET_RX_SUCCESS;
+
if (net->ipv4.sysctl_ip_early_demux && !skb_dst(skb) && skb->sk == NULL) {
const struct inet6_protocol *ipprot;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] net: phylib: fix interrupts re-enablement in phy_start
From: Florian Fainelli @ 2016-05-10 18:25 UTC (permalink / raw)
To: shh.xie, netdev, davem; +Cc: Shaohui Xie, Andrew Lunn
In-Reply-To: <1462873346-46457-1-git-send-email-shh.xie@gmail.com>
On 05/10/2016 02:42 AM, shh.xie@gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
>
> If phy was suspended and is starting, current driver always enable
> phy's interrupts, if phy works in polling, phy can raise unexpected
> interrupt which will not be handled, the interrupt will block system
> enter suspend again. So interrupts should only be re-enabled if phy
> works in interrupt.
Your explanation makes sense. The commit message could you use some
improvements like s/phy/PHY/ and "works in interrupt mode", but that is
not a huge thing.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/phy/phy.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 6f221c8..baa5ecb 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -871,9 +871,11 @@ void phy_start(struct phy_device *phydev)
> break;
> case PHY_HALTED:
> /* make sure interrupts are re-enabled for the PHY */
> - err = phy_enable_interrupts(phydev);
> - if (err < 0)
> - break;
> + if (phydev->irq != PHY_POLL) {
> + err = phy_enable_interrupts(phydev);
> + if (err < 0)
> + break;
> + }
>
> phydev->state = PHY_RESUMING;
> do_resume = true;
>
--
Florian
^ permalink raw reply
* RE: [PATCH net-next 01/14] qed: Add CONFIG_QED_SRIOV
From: Yuval Mintz @ 2016-05-10 18:27 UTC (permalink / raw)
To: Yuval Mintz, David Miller; +Cc: netdev, Ariel Elior
In-Reply-To: <CO2PR11MB0088ECDC1D7A65B703E2DDE797710@CO2PR11MB0088.namprd11.prod.outlook.com>
> > > I'm not entirely convinced this is true; If we'll not enforce the
> > > alignment of this 64-bit field, it's possible there will be
> > > differences between 32-bit and 64-bit machines versions of this struct.
> > > You have to recall that this is going to be copied via DMA between
> > > PF and VF, so they must have the exact same representation of the structure.
> >
> > Then use properly sized types to fill in all the space in the
> > structure, that's how you guarantee layout, not aligned_u64. Also, do not use
> the packed attribute.
> >
> > struct foo {
> > u32 x;
> > u32 y;
> > u64 z;
> > };
> >
> > 'z' will always be 64-bit aligned.
>
> Perhaps my bit-numeric is a bit weak - why is it so?
> I.e., what prevents `z' from only being 32-bit aligned on a 32-bit machine?
> Isn't it possible that (&x % 8) == 4, (&y % 8) == 0 and (&z % 8) == 4 on such a
> platform?
If struct foo were to have been allocated, would it be guaranteed to be 64-bit
aligned on a 64-bit platform and 32-bit aligned on a 32-bit platform?
Assuming it is the case, is it theoretically possible that you'd have 2 different
32-bit platforms, where on one the `z' field would be packed while on the other
it will not, introducing a 4-byte gap [assuming `foo' itself was only 32-bit aligned]?
^ permalink raw reply
* Re: [PATCH net] drivers: net: Don't print unpopulated net_device name
From: Stephen Hemminger @ 2016-05-10 18:31 UTC (permalink / raw)
To: Harvey Hunt
Cc: davem, Robert Jarzmik, Barry Song, Marcel Ziswiler, netdev,
linux-kernel
In-Reply-To: <1462898601-5429-1-git-send-email-harvey.hunt@imgtec.com>
On Tue, 10 May 2016 17:43:21 +0100
Harvey Hunt <harvey.hunt@imgtec.com> wrote:
> For ethernet devices, net_device.name will be eth%d before
> register_netdev() is called. Don't print the net_device name until
> the format string is replaced.
>
> Cc: Robert Jarzmik <robert.jarzmik@free.fr>
> Cc: Barry Song <Baohua.Song@csr.com>
> Cc: Marcel Ziswiler <marcel@ziswiler.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> Signed-off-by: Harvey Hunt <harvey.hunt@imgtec.com>
> ---
> I've tested this patch on a board that has a DM9000, but haven't
> tested the other two network devices.
>
> drivers/net/ethernet/davicom/dm9000.c | 3 +--
> drivers/net/ethernet/micrel/ks8695net.c | 3 +--
> drivers/net/ethernet/netx-eth.c | 3 +--
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
> index 48d9194..89dcaa1 100644
> --- a/drivers/net/ethernet/davicom/dm9000.c
> +++ b/drivers/net/ethernet/davicom/dm9000.c
> @@ -1686,8 +1686,7 @@ dm9000_probe(struct platform_device *pdev)
> }
>
> if (!is_valid_ether_addr(ndev->dev_addr)) {
> - dev_warn(db->dev, "%s: Invalid ethernet MAC address. Please "
> - "set using ifconfig\n", ndev->name);
> + dev_warn(db->dev, "Invalid ethernet MAC address. Please set using ifconfig\n");
ifconfig is deprecated, therefore please don't tell users to use it.
^ permalink raw reply
* Re: [PATCH v2 1/2] net: nps_enet: Sync access to packet sent flag
From: Lino Sanfilippo @ 2016-05-10 18:32 UTC (permalink / raw)
To: Elad Kanfi, Lino Sanfilippo, David Miller
Cc: Noam Camus, linux-kernel@vger.kernel.org, abrodkin@synopsys.com,
Tal Zilcer, netdev@vger.kernel.org
In-Reply-To: <HE1PR0501MB20265121CBDB2D48F66D408CCD7F0@HE1PR0501MB2026.eurprd05.prod.outlook.com>
Hi Elad,
On 08.05.2016 15:44, Elad Kanfi wrote:
>
> After reviewing the code and your suggestion, it seems that we can do without the flag tx_packet_sent and therefor the first issue becomes irrelevant.
> The indication that a packet was sent is (tx_skb != NULL) , and the sequence will be:
>
> CPU A:
> 1. tx_skb = skb
> 2. wmb() /* make sure tx_skb reaches the RAM before the HW is informed and the IRQ is fired */
> 3. nps_enet_reg_set(priv, NPS_ENET_REG_TX_CTL, tx_ctrl.value); /* send frame */
>
> CPU B:
> 1. read tx_skb
> 2. if( tx_skb != NULL ) handle tx_skb
> 3. tx_skb = NULL
>
>
Ok, without the tx_packet_sent flag the code becomes simpler. But it
does not mean that we can toss the smp_rmb in the irq handler
completely. We still have to use a read barrier there to ensure that we
see the most recent value of tx_skb. E.g like this:
if (priv->tx_skb != NULL ) {
smp_rmb()
/ * handle tx_skb */
}
With both barriers in place the code should work as expected.
Regards,
Lino
^ permalink raw reply
* Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
From: Florian Fainelli @ 2016-05-10 18:32 UTC (permalink / raw)
To: Sergei Shtylyov, grant.likely, robh+dt, devicetree, netdev,
frowand.list, pawel.moll, mark.rutland, ijc+devicetree, galak
Cc: linux-kernel
In-Reply-To: <3641492.klKRrvS8tr@wasted.cogentembedded.com>
On 04/28/2016 03:12 PM, Sergei Shtylyov wrote:
> The PHY devices sometimes do have their reset signal (maybe even power
> supply?) tied to some GPIO and sometimes it also does happen that a boot
> loader does not leave it deasserted. So far this issue has been attacked
> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
> the GPIO in question; that solution, when applied to the device trees, led
> to adding the PHY reset GPIO properties to the MAC device node, with one
> exception: Cadence MACB driver which could handle the "reset-gpios" prop
> in a PHY device subnode. I believe that the correct approach is to teach
> the 'phylib' to get the MDIO device reset GPIO from the device tree node
> corresponding to this device -- which this patch is doing...
>
> Note that I had to modify the AT803x PHY driver as it would stop working
> otherwise as it made use of the reset GPIO for its own purposes...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
This looks good to me:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Can you follow up with changes in phy_{suspend,resume} if that is also
an use case that you have?
--
Florian
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Bjorn Andersson @ 2016-05-10 18:39 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Andy Gross
Cc: netdev, Olof Johansson, Arnd Bergmann, linux-arm-kernel,
linux-next, linux-kernel
In-Reply-To: <20160510112905.5bffcad8@canb.auug.org.au>
On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .callback = qcom_smd_qrtr_callback,
> ^
> net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')
>
> Caused by commit
>
> bdabad3e363d ("net: Add Qualcomm IPC router")
>
> interacting with commit
>
> b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")
>
> from the arm-soc tree.
>
> I added the following merge fix patch (and it turned out I needed the
> new stubs).
>
Sorry for not spotting this issue earlier, I missed Andy's second pull
request towards arm-soc and thought the SMD changes missed this cycle.
Your patch looks good, but I'm not sure how we should approach the merge
window; Andy can't pick the patch because he doesn't have the qrtr code
and David doesn't have the SMD patches coming through Andy.
FWIW, Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?
Suggestions are welcome.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v3 0/2] Net driver bugs fix
From: David Miller @ 2016-05-10 18:40 UTC (permalink / raw)
To: eladkan; +Cc: noamca, linux-kernel, abrodkin, netdev
In-Reply-To: <1462814000-16331-1-git-send-email-eladkan@mellanox.com>
From: Elad Kanfi <eladkan@mellanox.com>
Date: Mon, 9 May 2016 20:13:18 +0300
> Summary:
> 1. Bug description: TX done interrupts that arrives while interrupts
> are masked, during NAPI poll, will not trigger an interrupt handling.
> Since TX interrupt is of level edge we will lose the TX done interrupt.
> As a result all pending tx frames will get no service.
>
> Solution: Check if there is a pending tx request after unmasking the
> interrupt and if answer is yes then re-add ourselves to
> the NAPI poll list.
>
> 2. Bug description: CPU-A before sending a frame will set a variable
> to true. CPU-B that executes the tx done interrupt service routine
> might read a non valid value of that variable.
>
> Solution: Use the socket buffer pointer instead of the variable,
> and add a write memory barrier at the tx sending function after
> the pointer is set.
Series applied, thanks.
^ permalink raw reply
* [PATCH net] openvswitch: Fix cached ct with helper.
From: Joe Stringer @ 2016-05-10 18:40 UTC (permalink / raw)
To: netdev; +Cc: Joe Stringer, jarno
When using conntrack helpers from OVS, a common configuration is to
perform a lookup without specifying a helper, then go through a
firewalling policy, only to decide to attach a helper afterwards.
In this case, the initial lookup will cause a ct entry to be attached to
the skb, then the later commit with helper should attach the helper and
confirm the connection. However, the helper attachment has been missing.
If the user has enabled automatic helper attachment, then this issue
will be masked as it will be applied in init_conntrack(). It is also
masked if the action is executed from ovs_packet_cmd_execute() as that
will construct a fresh skb.
This patch fixes the issue by making an explicit call to try to assign
the helper if there is a discrepancy between the action's helper and the
current skb->nfct.
Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
Signed-off-by: Joe Stringer <joe@ovn.org>
---
net/openvswitch/conntrack.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index b5fea1101faa..89f61a1720eb 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -776,6 +776,18 @@ static int __ovs_ct_lookup(struct net *net, struct sw_flow_key *key,
return -EINVAL;
}
+ /* Userspace may decide to perform a ct lookup without a helper
+ * specified followed by a (recirculate and) commit with one.
+ * Therefore, for unconfirmed connections we need to attach the
+ * helper here.
+ */
+ if (!nf_ct_is_confirmed(ct) && info->helper && !nfct_help(ct)) {
+ int err = __nf_ct_try_assign_helper(ct, info->ct,
+ GFP_ATOMIC);
+ if (err)
+ return err;
+ }
+
/* Call the helper only if:
* - nf_conntrack_in() was executed above ("!cached") for a
* confirmed connection, or
--
2.1.4
^ permalink raw reply related
* Re: [PATCH nf-next,v2] gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)
From: Eric Dumazet @ 2016-05-10 18:54 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netdev, davem, laforge, aschultz, openbsc
In-Reply-To: <1462748148-17764-1-git-send-email-pablo@netfilter.org>
On Mon, 2016-05-09 at 00:55 +0200, Pablo Neira Ayuso wrote:
> +static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb,
> + bool xnet)
> +{
> + unsigned int hdrlen = sizeof(struct udphdr) +
> + sizeof(struct gtp1_header);
> + struct gtp1_header *gtp1;
> + struct pdp_ctx *pctx;
> + int ret = 0;
> +
> + if (!pskb_may_pull(skb, hdrlen))
> + return -1;
> +
> + gtp1 = (struct gtp1_header *)(skb->data + sizeof(struct udphdr));
> +
> + if ((gtp1->flags >> 5) != GTP_V1)
> + return 1;
> +
> + if (gtp1->type != GTP_TPDU)
> + return 1;
> +
> + /* From 29.060: "This field shall be present if and only if any one or
> + * more of the S, PN and E flags are set.".
> + *
> + * If any of the bit is set, then the remaining ones also have to be
> + * set.
> + */
> + if (gtp1->flags & GTP1_F_MASK)
> + hdrlen += 4;
> +
> + /* Make sure the header is larger enough, including extensions. */
> + if (!pskb_may_pull(skb, hdrlen))
> + return -1;
You need to reload gtp1 here, as the previous pskb_may_pull() might have
reallocated skb->head
> +
> + rcu_read_lock();
> + pctx = gtp1_pdp_find(gtp, ntohl(gtp1->tid));
Or risk a use after free here.
> + if (!pctx) {
> + netdev_dbg(gtp->dev, "No PDP ctx to decap skb=%p\n", skb);
> + ret = -1;
> + goto out_rcu;
> + }
> +
> + if (!gtp_check_src_ms(skb, pctx, hdrlen)) {
> + netdev_dbg(gtp->dev, "No PDP ctx for this MS\n");
> + ret = -1;
> + goto out_rcu;
> + }
> + rcu_read_unlock();
> +
> + /* Get rid of the GTP + UDP headers. */
> + return iptunnel_pull_header(skb, hdrlen, skb->protocol, xnet);
> +out_rcu:
> + rcu_read_unlock();
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: replace cnt & rtt with struct in pkts_acked()
From: David Miller @ 2016-05-10 19:00 UTC (permalink / raw)
To: brakmo; +Cc: netdev, kernel-team, ncardwell, eric.dumazet, ycheng
In-Reply-To: <1462830372-3563095-1-git-send-email-brakmo@fb.com>
From: Lawrence Brakmo <brakmo@fb.com>
Date: Mon, 9 May 2016 14:46:12 -0700
> @@ -197,15 +197,15 @@ static void bictcp_state(struct sock *sk, u8 new_state)
> /* Track delayed acknowledgment ratio using sliding window
> * ratio = (15*ratio + sample) / 16
> */
> -static void bictcp_acked(struct sock *sk, u32 cnt, s32 rtt)
> +static void bictcp_acked(struct sock *sk, const struct ack_sample *sample)
> {
> const struct inet_connection_sock *icsk = inet_csk(sk);
>
> if (icsk->icsk_ca_state == TCP_CA_Open) {
> struct bictcp *ca = inet_csk_ca(sk);
>
> - cnt -= ca->delayed_ack >> ACK_RATIO_SHIFT;
> - ca->delayed_ack += cnt;
> + ca->delayed_ack += sample->pkts_acked -
^^ Trailing whitespace on that line.
> + struct ack_sample sample = {.pkts_acked = pkts_acked,
> + .rtt_us = ca_rtt_us};
Please put a space after the openning parenthesis and before the closing parenthesis.
^ permalink raw reply
* Re: [PATCH v3 0/3] net: phy: add phy_ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-05-10 19:06 UTC (permalink / raw)
To: tremyfr; +Cc: fugang.duan, f.fainelli, decot, ben, netdev, linux-kernel
In-Reply-To: <1462832383-25541-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Tue, 10 May 2016 00:19:40 +0200
> Ethtool callbacks {get|set}_link_ksettings may be the
> same for many drivers. So we add two generics callbacks
> phy_ethtool_{get|set}_link_ksettings.
>
> To use those generics callbacks, the ethernet driver must
> use the pointer phydev contained in struct net_device, and
> not use a private structure to store this pointer.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3] block/drbd: align properly u64 in nl messages
From: Lars Ellenberg @ 2016-05-10 19:09 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <20160510.113949.2077250222547175741.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, May 10, 2016 at 11:39:49AM -0400, David Miller wrote:
> From: Lars Ellenberg <lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org>
> Date: Tue, 10 May 2016 11:40:23 +0200
excuse me for reordering the original:
> Anyways, back to the topic, can you please just relent and come to
> some kind of agreement about the fix for this alignment bug?
I thought we did? I'm fine with the "v3",
it even carries my signed-of-by.
Whether or not Nicholas wants to prefix those headers with drbd_,
I don't really care.
> This is taking a very long time and patches are just rotting in
> patchwork with no resolution. Why would
Nicholas asked how to go about DRBD,
I suggested to use 0 as a padding attribute,
and after taking a detour, he did. All good.
Rest of original:
> > If we introduce a new config option,
> > we have to add it to the config scanner (one line),
> > define min, max, default and scale (four short defines),
> > and add it to the netlink definition here (one line).
> > Done, rest of the code is generated,
> > both on the kernel side,
> > and on the drbd-utils side used to talk to the kernel.
> > We found that to be very convenient.
>
> But it entirely misses the core design point of netlink.
>
> Sender and receive _DO NOT_ need to coordinate at all. That's the
> whole point. So tightly coupling such coordination is going to run
> you into all kinds of problems.
>
> When implemented properly, the sender can emit whatever attributes it
> knows about and can generate, and the receive scans the attributes one
> by one and picks out the ones it understands and processes them.
>
> If you go against this model
> then you have no clean way to
We don't.
We extend (not violate) that model, so the sender *may* indicate
to the recipient that for some particular attribute, the sender would
rather have an "I don't understand this" return than a silent ignore.
And that we can indicate in the definition of the attributes which ones
are required to make a message meaningful.
> extend things whilst allowing existing software to continue working.
*that* is exactly why we use netlink,
and why we do things with it the way we do.
Actually I think what we are doing there is, comparatively, "elegant".
You obviously don't have to agree.
I could discuss this in more detail,
but I assume you are not really interested,
at least not here and now.
Thanks,
Lars
^ permalink raw reply
* Re: [PATCH net-next 01/14] qed: Add CONFIG_QED_SRIOV
From: David Miller @ 2016-05-10 19:10 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, Ariel.Elior
In-Reply-To: <CO2PR11MB0088ECDC1D7A65B703E2DDE797710@CO2PR11MB0088.namprd11.prod.outlook.com>
From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Tue, 10 May 2016 18:15:08 +0000
>> > I'm not entirely convinced this is true; If we'll not enforce the
>> > alignment of this 64-bit field, it's possible there will be
>> > differences between 32-bit and 64-bit machines versions of this struct.
>> > You have to recall that this is going to be copied via DMA between PF
>> > and VF, so they must have the exact same representation of the structure.
>>
>> Then use properly sized types to fill in all the space in the structure, that's how
>> you guarantee layout, not aligned_u64. Also, do not use the packed attribute.
>>
>> struct foo {
>> u32 x;
>> u32 y;
>> u64 z;
>> };
>>
>> 'z' will always be 64-bit aligned.
>
> Perhaps my bit-numeric is a bit weak - why is it so?
foo is 64-bit aligned, therefore a properly aligned struct member will
be so as well.
We absolutely depend upon this for several data structures in the kernel.
^ permalink raw reply
* Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
From: Sergei Shtylyov @ 2016-05-10 19:11 UTC (permalink / raw)
To: Florian Fainelli, grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5732294F.3060606-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello.
On 05/10/2016 09:32 PM, Florian Fainelli wrote:
>> The PHY devices sometimes do have their reset signal (maybe even power
>> supply?) tied to some GPIO and sometimes it also does happen that a boot
>> loader does not leave it deasserted. So far this issue has been attacked
>> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
>> the GPIO in question; that solution, when applied to the device trees, led
>> to adding the PHY reset GPIO properties to the MAC device node, with one
>> exception: Cadence MACB driver which could handle the "reset-gpios" prop
>> in a PHY device subnode. I believe that the correct approach is to teach
>> the 'phylib' to get the MDIO device reset GPIO from the device tree node
>> corresponding to this device -- which this patch is doing...
>>
>> Note that I had to modify the AT803x PHY driver as it would stop working
>> otherwise as it made use of the reset GPIO for its own purposes...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>
> This looks good to me:
>
> Acked-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thank you! I'll send v3 without [RFT] then.
> Can you follow up with changes in phy_{suspend,resume}
I'm not sure what changes you mean -- powering down the PHYs?
> if that is also
> an use case that you have?
No, I'm not into power management.
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
From: Florian Fainelli @ 2016-05-10 19:13 UTC (permalink / raw)
To: Sergei Shtylyov, grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5732327A.6080203-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On 05/10/2016 12:11 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 05/10/2016 09:32 PM, Florian Fainelli wrote:
>
>>> The PHY devices sometimes do have their reset signal (maybe even power
>>> supply?) tied to some GPIO and sometimes it also does happen that a boot
>>> loader does not leave it deasserted. So far this issue has been attacked
>>> from (as I believe) a wrong angle: by teaching the MAC driver to
>>> manipulate
>>> the GPIO in question; that solution, when applied to the device
>>> trees, led
>>> to adding the PHY reset GPIO properties to the MAC device node, with one
>>> exception: Cadence MACB driver which could handle the "reset-gpios" prop
>>> in a PHY device subnode. I believe that the correct approach is to teach
>>> the 'phylib' to get the MDIO device reset GPIO from the device tree node
>>> corresponding to this device -- which this patch is doing...
>>>
>>> Note that I had to modify the AT803x PHY driver as it would stop
>>> working
>>> otherwise as it made use of the reset GPIO for its own purposes...
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>
>> This looks good to me:
>>
>> Acked-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Thank you! I'll send v3 without [RFT] then.
>
>> Can you follow up with changes in phy_{suspend,resume}
>
> I'm not sure what changes you mean -- powering down the PHYs?
Yes, powering down, conversely up the PHY. The whole point of putting
this in PHYLIB is to be able to perform things like that. We do not need
this right now, but it would be nice if we saw that materialize at some
point.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [patch -mainline] qlcnic: potential NULL dereference in qlcnic_83xx_get_minidump_template()
From: Dan Carpenter @ 2016-05-10 19:20 UTC (permalink / raw)
To: Dept-GELinuxNICDev; +Cc: netdev, kernel-janitors
If qlcnic_fw_cmd_get_minidump_temp() fails then "fw_dump->tmpl_hdr" is
NULL or possibly freed. It can lead to an oops later.
Fixes: d01a6d3c8ae1 ('qlcnic: Add support to enable capability to extend minidump for iSCSI')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c
index cda9e60..0844b7c 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c
@@ -1417,6 +1417,7 @@ void qlcnic_83xx_get_minidump_template(struct qlcnic_adapter *adapter)
struct qlcnic_fw_dump *fw_dump = &ahw->fw_dump;
struct pci_dev *pdev = adapter->pdev;
bool extended = false;
+ int ret;
prev_version = adapter->fw_version;
current_version = qlcnic_83xx_get_fw_version(adapter);
@@ -1427,8 +1428,11 @@ void qlcnic_83xx_get_minidump_template(struct qlcnic_adapter *adapter)
if (qlcnic_83xx_md_check_extended_dump_capability(adapter))
extended = !qlcnic_83xx_extend_md_capab(adapter);
- if (!qlcnic_fw_cmd_get_minidump_temp(adapter))
- dev_info(&pdev->dev, "Supports FW dump capability\n");
+ ret = qlcnic_fw_cmd_get_minidump_temp(adapter);
+ if (ret)
+ return;
+
+ dev_info(&pdev->dev, "Supports FW dump capability\n");
/* Once we have minidump template with extended iSCSI dump
* capability, update the minidump capture mask to 0x1f as
^ permalink raw reply related
* Re: [Drbd-dev] [PATCH net-next v3] block/drbd: align properly u64 in nl messages
From: David Miller @ 2016-05-10 19:26 UTC (permalink / raw)
To: lars.ellenberg
Cc: nicolas.dichtel, netdev, philipp.reisner, drbd-dev, linux-kernel
In-Reply-To: <20160510190902.GF16459@soda.linbit>
From: Lars Ellenberg <lars.ellenberg@linbit.com>
Date: Tue, 10 May 2016 21:09:03 +0200
> On Tue, May 10, 2016 at 11:39:49AM -0400, David Miller wrote:
>> From: Lars Ellenberg <lars.ellenberg@linbit.com>
>> Date: Tue, 10 May 2016 11:40:23 +0200
>
> excuse me for reordering the original:
>
>> Anyways, back to the topic, can you please just relent and come to
>> some kind of agreement about the fix for this alignment bug?
>
> I thought we did? I'm fine with the "v3",
> it even carries my signed-of-by.
My bad, I missed that, I'll apply v3 thanks a lot!
^ 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