* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: David Miller @ 2016-05-03 16:12 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, talal, eranbe
In-Reply-To: <1462284844-16926-1-git-send-email-saeedm@mellanox.com>
Please don't have two patch series pending for the same driver (mlx5) and
the same tree (net-next).
This makes things extremely confusing (is patch set #2 dependent upon #1?
what if I ask for changes to patch set #1?).
So always let the first patch series get fully resolved before sending
the second series.
I'm tossing this series out.
^ permalink raw reply
* Re: [PATCH 0/2] sctp: Add GSO support
From: David Miller @ 2016-05-03 16:09 UTC (permalink / raw)
To: marcelo.leitner
Cc: netdev, vyasevich, nhorman, linux-sctp, David.Laight,
alexander.duyck
In-Reply-To: <20160503114918.GD5676@localhost.localdomain>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Tue, 3 May 2016 08:49:18 -0300
> So this is just for pure tx path, no forwarding involved.
And if that GSO segment is looped back into the stack via the
loopback interface, the packet classifier mirror action, or
netfilter?
You cannot just GSO things and then not handle such packets
properly on receive.
^ permalink raw reply
* Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
From: David Miller @ 2016-05-03 16:06 UTC (permalink / raw)
To: lars.ellenberg
Cc: nicolas.dichtel, netdev, philipp.reisner, drbd-dev, linux-kernel
In-Reply-To: <20160503100644.GE16459@soda.linbit>
From: Lars Ellenberg <lars.ellenberg@linbit.com>
Date: Tue, 3 May 2016 12:06:44 +0200
> Whereas using some arbitrary value will be wrong,
> and will needlessly break userland.
It cannot break userland.
A fundamental property of netlink is that all code must silently
ignore netlink attributes it does not understand.
This is why netlink is easily extensible.
If code isn't doing that, it is broken and must be fixed.
^ permalink raw reply
* Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
From: David Miller @ 2016-05-03 16:05 UTC (permalink / raw)
To: lars.ellenberg
Cc: nicolas.dichtel, netdev, philipp.reisner, drbd-dev, linux-kernel
In-Reply-To: <20160503100644.GE16459@soda.linbit>
From: Lars Ellenberg <lars.ellenberg@linbit.com>
Date: Tue, 3 May 2016 12:06:44 +0200
> Please just NOT use an additional "field",
> but always use 0 to pad.
You can't, it doesn't work.
We are adding a new field to every netlink protocol family that has this
alignment problem.
^ permalink raw reply
* Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?
From: Hannes Frederic Sowa @ 2016-05-03 16:01 UTC (permalink / raw)
To: Guillaume Nault; +Cc: Richard Weinberger, Wang Shanker, netdev, LKML
In-Reply-To: <20160503155157.GB1304@alphalink.fr>
On 03.05.2016 17:51, Guillaume Nault wrote:
> On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote:
>> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote:
>>> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr>
>>> wrote:
>>>> On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
>>>>> static int ppp_open(struct inode *inode, struct file *file)
>>>>> {
>>>>> /*
>>>>> * This could (should?) be enforced by the permissions on /dev/ppp.
>>>>> */
>>>>> if (!capable(CAP_NET_ADMIN))
>>>>> return -EPERM;
>>>>> return 0;
>>>>> }
>>>>> ```
>>>>>
>>>>> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
>>>>> permission of the device node. If there is no need, I suggest that the
>>>>> CAP_NET_ADMIN check be removed.
>>>>>
>>>> If this test was removed here, then it'd have to be added again in the
>>>> PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
>>>> should require CAP_NET_ADMIN. Therefore that wouldn't help for your
>>>> case.
>>>> I don't know why the test was placed in ppp_open() in the first place,
>>>> but changing it now would have side effects on user space. So I'd
>>>> rather leave the code as is.
>>>
>>> I think the question is whether we really require having CAP_NET_ADMIN
>>> in the initial namespace and not just in the current one.
>>> Is ppp not network namespace aware?
>>
>> I agree, ns_capable(net->user_ns, CAP_NET_ADMIN), would probably make
>> more sense.
>>
> I guess you assume net is set to current->nsproxy->net_ns here.
> Why about ns_capable(current_user_ns(), CAP_NET_ADMIN)?
>
> From my understanding of the code (I currently have no practical
> experience with user namespaces), net->user_ns points to the userns in
> which the current netns was created, while current_user_ns() refers to
> the caller's userns. Shouldn't we check the later? Otherwise, any
> process running in the netns would have the same capabilities regarding
> PPP ioctls().
We want to test our (*current) capability in the user namespace the net
namespace was created. current is implied here.
If you create a new user_namespace ontop the same network stack you
shouldn't have those capabilities, otherwise you can elevate capabilities.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH v1 net] net/mlx4: Avoid wrong virtual mappings
From: David Miller @ 2016-05-03 16:00 UTC (permalink / raw)
To: gerlitz.or; +Cc: hagaya, netdev, okaya, timur, eranbe, yishaih, talal, saeedm
In-Reply-To: <CAJ3xEMjomTc5JNNEknk-JMBUtvAcb5xY8La4zT4mKG2Ad=V85Q@mail.gmail.com>
From: Or Gerlitz <gerlitz.or@gmail.com>
Date: Tue, 3 May 2016 10:45:43 +0300
> The patch changes the driver to do single allocation for potentially
> very large HW WQE descriptor buffers such as those used by the RDMA
> (mlx5_ib) driver.
I know exactly what this patch does and how, but thanks for trying to
teach me what it does anyways.
^ permalink raw reply
* Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?
From: Guillaume Nault @ 2016-05-03 15:51 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Richard Weinberger, Wang Shanker, netdev, LKML
In-Reply-To: <1462274614.1336993.596603129.675ECADD@webmail.messagingengine.com>
On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote:
> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote:
> > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr>
> > wrote:
> > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
> > >> static int ppp_open(struct inode *inode, struct file *file)
> > >> {
> > >> /*
> > >> * This could (should?) be enforced by the permissions on /dev/ppp.
> > >> */
> > >> if (!capable(CAP_NET_ADMIN))
> > >> return -EPERM;
> > >> return 0;
> > >> }
> > >> ```
> > >>
> > >> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
> > >> permission of the device node. If there is no need, I suggest that the
> > >> CAP_NET_ADMIN check be removed.
> > >>
> > > If this test was removed here, then it'd have to be added again in the
> > > PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
> > > should require CAP_NET_ADMIN. Therefore that wouldn't help for your
> > > case.
> > > I don't know why the test was placed in ppp_open() in the first place,
> > > but changing it now would have side effects on user space. So I'd
> > > rather leave the code as is.
> >
> > I think the question is whether we really require having CAP_NET_ADMIN
> > in the initial namespace and not just in the current one.
> > Is ppp not network namespace aware?
>
> I agree, ns_capable(net->user_ns, CAP_NET_ADMIN), would probably make
> more sense.
>
I guess you assume net is set to current->nsproxy->net_ns here.
Why about ns_capable(current_user_ns(), CAP_NET_ADMIN)?
>From my understanding of the code (I currently have no practical
experience with user namespaces), net->user_ns points to the userns in
which the current netns was created, while current_user_ns() refers to
the caller's userns. Shouldn't we check the later? Otherwise, any
process running in the netns would have the same capabilities regarding
PPP ioctls().
But I'm certainly missing important points. Interactions between netns
and userns are something I never investigated before, and using
net->user_ns seems to be way more common than using current_user_ns()
for checking capabilities in the networking stack.
^ permalink raw reply
* [patch added to 3.12-stable] cpuset: Fix potential deadlock w/ set_mems_allowed
From: Jiri Slaby @ 2016-05-03 15:47 UTC (permalink / raw)
To: stable
Cc: John Stultz, Peter Zijlstra, Mathieu Desnoyers, Steven Rostedt,
David S. Miller, netdev, Ingo Molnar, Jiri Slaby
In-Reply-To: <1462290468-14130-1-git-send-email-jslaby@suse.cz>
From: John Stultz <john.stultz@linaro.org>
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===============
commit db751fe3ea6880ff5ac5abe60cb7b80deb5a4140 upstream.
After adding lockdep support to seqlock/seqcount structures,
I started seeing the following warning:
[ 1.070907] ======================================================
[ 1.072015] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[ 1.073181] 3.11.0+ #67 Not tainted
[ 1.073801] ------------------------------------------------------
[ 1.074882] kworker/u4:2/708 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 1.076088] (&p->mems_allowed_seq){+.+...}, at: [<ffffffff81187d7f>] new_slab+0x5f/0x280
[ 1.077572]
[ 1.077572] and this task is already holding:
[ 1.078593] (&(&q->__queue_lock)->rlock){..-...}, at: [<ffffffff81339f03>] blk_execute_rq_nowait+0x53/0xf0
[ 1.080042] which would create a new lock dependency:
[ 1.080042] (&(&q->__queue_lock)->rlock){..-...} -> (&p->mems_allowed_seq){+.+...}
[ 1.080042]
[ 1.080042] but this new dependency connects a SOFTIRQ-irq-safe lock:
[ 1.080042] (&(&q->__queue_lock)->rlock){..-...}
[ 1.080042] ... which became SOFTIRQ-irq-safe at:
[ 1.080042] [<ffffffff810ec179>] __lock_acquire+0x5b9/0x1db0
[ 1.080042] [<ffffffff810edfe5>] lock_acquire+0x95/0x130
[ 1.080042] [<ffffffff818968a1>] _raw_spin_lock+0x41/0x80
[ 1.080042] [<ffffffff81560c9e>] scsi_device_unbusy+0x7e/0xd0
[ 1.080042] [<ffffffff8155a612>] scsi_finish_command+0x32/0xf0
[ 1.080042] [<ffffffff81560e91>] scsi_softirq_done+0xa1/0x130
[ 1.080042] [<ffffffff8133b0f3>] blk_done_softirq+0x73/0x90
[ 1.080042] [<ffffffff81095dc0>] __do_softirq+0x110/0x2f0
[ 1.080042] [<ffffffff81095fcd>] run_ksoftirqd+0x2d/0x60
[ 1.080042] [<ffffffff810bc506>] smpboot_thread_fn+0x156/0x1e0
[ 1.080042] [<ffffffff810b3916>] kthread+0xd6/0xe0
[ 1.080042] [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
[ 1.080042]
[ 1.080042] to a SOFTIRQ-irq-unsafe lock:
[ 1.080042] (&p->mems_allowed_seq){+.+...}
[ 1.080042] ... which became SOFTIRQ-irq-unsafe at:
[ 1.080042] ... [<ffffffff810ec1d3>] __lock_acquire+0x613/0x1db0
[ 1.080042] [<ffffffff810edfe5>] lock_acquire+0x95/0x130
[ 1.080042] [<ffffffff810b3df2>] kthreadd+0x82/0x180
[ 1.080042] [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
[ 1.080042]
[ 1.080042] other info that might help us debug this:
[ 1.080042]
[ 1.080042] Possible interrupt unsafe locking scenario:
[ 1.080042]
[ 1.080042] CPU0 CPU1
[ 1.080042] ---- ----
[ 1.080042] lock(&p->mems_allowed_seq);
[ 1.080042] local_irq_disable();
[ 1.080042] lock(&(&q->__queue_lock)->rlock);
[ 1.080042] lock(&p->mems_allowed_seq);
[ 1.080042] <Interrupt>
[ 1.080042] lock(&(&q->__queue_lock)->rlock);
[ 1.080042]
[ 1.080042] *** DEADLOCK ***
The issue stems from the kthreadd() function calling set_mems_allowed
with irqs enabled. While its possibly unlikely for the actual deadlock
to trigger, a fix is fairly simple: disable irqs before taking the
mems_allowed_seq lock.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Link: http://lkml.kernel.org/r/1381186321-4906-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
include/linux/cpuset.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index a7ebb89ae9fb..ade2390ffe92 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -132,10 +132,14 @@ static inline bool read_mems_allowed_retry(unsigned int seq)
static inline void set_mems_allowed(nodemask_t nodemask)
{
+ unsigned long flags;
+
task_lock(current);
+ local_irq_save(flags);
write_seqcount_begin(¤t->mems_allowed_seq);
current->mems_allowed = nodemask;
write_seqcount_end(¤t->mems_allowed_seq);
+ local_irq_restore(flags);
task_unlock(current);
}
--
2.8.2
^ permalink raw reply related
* Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions
From: John Stultz @ 2016-05-03 15:44 UTC (permalink / raw)
To: David B. Robins
Cc: lkml, Dean Jenkins, Mark Craske, David S. Miller, YongQin Liu,
Guodong Xu, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Ivan Vecera
In-Reply-To: <87ed4c76328ed9dc5591359ea0e98ab9-xeNgNI7VTeVeoWH0uzbU5w@public.gmane.org>
On Tue, May 3, 2016 at 7:42 AM, David B. Robins <linux-AegXhGwVzVhoAEGGzP886w@public.gmane.org> wrote:
> On 2016-05-03 00:55, John Stultz wrote:
>>
>> Looking through the commits since the v4.1 kernel where we didn't see
>> this, I narrowed the regression down, and reverting the following two
>> commits seems to avoid the problem:
>>
>> 6a570814cd430fa5ef4f278e8046dcf12ee63f13 asix: Continue processing URB
>> if no RX netdev buffer
>> 3f30b158eba5c604b6e0870027eef5d19fc9271d asix: On RX avoid creating
>> bad Ethernet frames
>>
>
> I don't think the first one is giving you problems (except as triggered by
> the second) but I had concerns about the second myself (and emailed the
> author off-list, but received no reply), and we did not take that commit for
> our own product.
Yes, the first/later commit is being reverted as it modifies code that
was also changed by the second/earlier one. So the 3f30 patch doesn't
revert cleanly by itself, but I have tested by just removing the (now
modified by 6a57) chunk of code it adds does seem to avoid the problem
as well. Though I wasn't able to review things closely enough to be
confident that didn't introduce any subtle bugs in the remaining logic
in the 6a57 patch.
> Specifically, the second change, 3f30... (original patch:
> https://www.mail-archive.com/netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg80720.html) (1)
> appears to do the exact opposite of what it claims, i.e., instead of "resync
> if this looks like a header", it does "resync if this does NOT look like a
> (packet) header", where "looks like a header" means "bits 0-10 (size) are
> equal to the bitwise-NOT of bits 16-26", and (2) can happen by coincidence
> for 1/2048 32-bit values starting a continuation URB (easy to hit dealing
> with large volumes of video data as we were). It appears to expect the
> header for every URB whereas the rest of the code at least expects it only
> once per network packet (look at following code that only reads it for
> remaining == 0).
>
> So that change made no sense to me, but I don't have significant kernel dev
> experience. Effectively it will drop/truncate every (2047/2048) split
> (longer than an URB) packet, and report an error for the second URB and then
> again for treating said second URB as a first URB for a packet. I would
> expect your problems will go away just removing the second change. You could
> also change the != to == in "if (size != ...)" but then you'd still have
> 1/2048 (depending on data patterns) false positives.
I'll have to look into this more. I'm not super familiar with usb or
networking, so I'm not sure I can judge the better approach.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: Davicom DM9162 PHY supported in the kernel?
From: Andrew Lunn @ 2016-05-03 15:36 UTC (permalink / raw)
To: Amr Bekhit; +Cc: Florian Fainelli, netdev
In-Reply-To: <CAOLz05pidfdJXR58a+xjvp02EyPhUJnz9odpM-VFtkCQ2bhtNQ@mail.gmail.com>
> Any ideas as to why I can't get any packets out? Is there a way for me
> to test whether there is an issue between the MAC and PHY?
Does it perform auto-negotiate? If it does, the PHY to the cable is
probably O.K.
Have you checked the status bits. Loopback, Power down, Isolate?
Andrew
^ permalink raw reply
* Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Alexander Duyck @ 2016-05-03 15:29 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, Alexander Duyck, talal@mellanox.com,
Linux Netdev List, Michael Chan, David Miller, Gal Pressman,
Eran Ben Elisha
In-Reply-To: <57289C95.8030401@mellanox.com>
On Tue, May 3, 2016 at 5:41 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 5/2/2016 6:41 PM, Alexander Duyck wrote:
>>>
>>> >Just one more piece to clarify... in the general case (e.g inner
>>> >packet size 1.5k...64k), the last segment would not have the same
>>> >length as the other segments, what happens on that case?
>>
>> Actually in the case of GSO partial we have go through the software
>> segmentation code and trim off any last bit that doesn't match the MSS
>> of the rest of the frame. That way you end up with one frame that has
>> some number of MSS sized chunks, and then one remainder if there is a
>> frame that would be a different size.
>
>
> OK, thanks for further clarifying this, will look on the docs you pointed
> etc. From what you wrote here I understand it's indeed possible for one
> frame to be of different size from the rest, but the LCO thing still works
> somehow..
We split the one that would be a different size off via GSO. So we
end up sending up 2 frames to the device if there is going to be one
piece that doesn't quite match. We split that one piece off via GSO.
That is one of the reasons why I referred to it as partial GSO as all
we are using the software segmentation code for is to make sure we
have the GSO block consists of segments that are all the same size.
- Alex
^ permalink raw reply
* Re: [PATCH] gre6: add Kconfig dependency for NET_IPGRE_DEMUX
From: Tom Herbert @ 2016-05-03 15:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Thomas Egerer, Paolo Abeni,
Linux Kernel Network Developers, LKML
In-Reply-To: <1462288817-721172-1-git-send-email-arnd@arndb.de>
On Tue, May 3, 2016 at 8:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The ipv6 gre implementation was cleaned up to share more code
> with the ipv4 version, but it can be enabled even when NET_IPGRE_DEMUX
> is disabled, resulting in a link error:
>
> net/built-in.o: In function `gre_rcv':
> :(.text+0x17f5d0): undefined reference to `gre_parse_header'
> ERROR: "gre_parse_header" [net/ipv6/ip6_gre.ko] undefined!
>
> This adds a Kconfig dependency to prevent that now invalid
> configuration.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE functions")
> ---
Acked-by: Tom Herbert <tom@herbertland.com>
> net/ipv6/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
> index 11e875ffd7ac..3f8411328de5 100644
> --- a/net/ipv6/Kconfig
> +++ b/net/ipv6/Kconfig
> @@ -218,6 +218,7 @@ config IPV6_GRE
> tristate "IPv6: GRE tunnel"
> select IPV6_TUNNEL
> select NET_IP_TUNNEL
> + depends on NET_IPGRE_DEMUX
> ---help---
> Tunneling means encapsulating data of one protocol type within
> another protocol and sending it over a channel that understands the
> --
> 2.7.0
>
^ permalink raw reply
* [PATCH net-next 5/5] net: remove dev->trans_start
From: Florian Westphal @ 2016-05-03 14:33 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <1462285994-31983-1-git-send-email-fw@strlen.de>
previous patches removed all direct accesses to dev->trans_start,
so change the netif_trans_update helper to update trans_start of
netdev queue 0 instead and then remove trans_start from struct net_device.
AFAICS a lot of the netif_trans_update() invocations are now useless
because they occur in ndo_start_xmit and driver doesn't set LLTX
(i.e. stack already took care of the update).
As I can't test any of them it seems better to just leave them alone.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
include/linux/netdevice.h | 15 +++++----------
net/sched/sch_generic.c | 10 +++-------
3 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 8e6c0f2..f6da6b7 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -328,7 +328,7 @@ static void i40e_tx_timeout(struct net_device *netdev)
unsigned long trans_start;
q = netdev_get_tx_queue(netdev, i);
- trans_start = q->trans_start ? : netdev->trans_start;
+ trans_start = q->trans_start;
if (netif_xmit_stopped(q) &&
time_after(jiffies,
(trans_start + netdev->watchdog_timeo))) {
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 798f285..fba2faa 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -581,7 +581,7 @@ struct netdev_queue {
spinlock_t _xmit_lock ____cacheline_aligned_in_smp;
int xmit_lock_owner;
/*
- * please use this field instead of dev->trans_start
+ * Time (in jiffies) of last Tx
*/
unsigned long trans_start;
@@ -1545,7 +1545,6 @@ enum netdev_priv_flags {
*
* @offload_fwd_mark: Offload device fwding mark
*
- * @trans_start: Time (in jiffies) of last Tx
* @watchdog_timeo: Represents the timeout that is used by
* the watchdog (see dev_watchdog())
* @watchdog_timer: List of timers
@@ -1794,13 +1793,6 @@ struct net_device {
#endif
/* These may be needed for future network-power-down code. */
-
- /*
- * trans_start here is expensive for high speed devices on SMP,
- * please use netdev_queue->trans_start instead.
- */
- unsigned long trans_start;
-
struct timer_list watchdog_timer;
int __percpu *pcpu_refcnt;
@@ -3484,7 +3476,10 @@ static inline void txq_trans_update(struct netdev_queue *txq)
/* legacy drivers only, netdev_start_xmit() sets txq->trans_start */
static inline void netif_trans_update(struct net_device *dev)
{
- dev->trans_start = jiffies;
+ struct netdev_queue *txq = netdev_get_tx_queue(dev, 0);
+
+ if (txq->trans_start != jiffies)
+ txq->trans_start = jiffies;
}
/**
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 70182cf..269dd71 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -227,13 +227,12 @@ unsigned long dev_trans_start(struct net_device *dev)
if (is_vlan_dev(dev))
dev = vlan_dev_real_dev(dev);
- res = dev->trans_start;
- for (i = 0; i < dev->num_tx_queues; i++) {
+ res = netdev_get_tx_queue(dev, 0)->trans_start;
+ for (i = 1; i < dev->num_tx_queues; i++) {
val = netdev_get_tx_queue(dev, i)->trans_start;
if (val && time_after(val, res))
res = val;
}
- dev->trans_start = res;
return res;
}
@@ -256,10 +255,7 @@ static void dev_watchdog(unsigned long arg)
struct netdev_queue *txq;
txq = netdev_get_tx_queue(dev, i);
- /*
- * old device drivers set dev->trans_start
- */
- trans_start = txq->trans_start ? : dev->trans_start;
+ trans_start = txq->trans_start;
if (netif_xmit_stopped(txq) &&
time_after(jiffies, (trans_start +
dev->watchdog_timeo))) {
--
2.7.3
^ permalink raw reply related
* [PATCH net v2] vlan: Propagate MAC address to VLANs unless explicitly set
From: Mike Manning @ 2016-05-03 15:20 UTC (permalink / raw)
To: netdev
In-Reply-To: <5728BA0B.6050807@brocade.com>
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
Continuing to inherit the MAC address unless explicitly changed for
the VLAN allows IPv6 EUI64 addresses for the VLAN to reflect the change
and thus for DAD to behave as expected for the given MAC.
Signed-off-by: Mike Manning <mmanning@brocade.com>
---
net/8021q/vlan.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -286,22 +286,25 @@ static void vlan_sync_address(struct net
struct net_device *vlandev)
{
struct vlan_dev_priv *vlan = vlan_dev_priv(vlandev);
+ bool real_addr_in_use;
/* May be called without an actual change */
if (ether_addr_equal(vlan->real_dev_addr, dev->dev_addr))
return;
- /* vlan address was different from the old address and is equal to
+ real_addr_in_use =
+ ether_addr_equal(vlandev->dev_addr, vlan->real_dev_addr);
+
+ /* vlan address was different from the real address and is equal to
* the new address */
- if (!ether_addr_equal(vlandev->dev_addr, vlan->real_dev_addr) &&
+ if ((vlandev->flags & IFF_UP) && !real_addr_in_use &&
ether_addr_equal(vlandev->dev_addr, dev->dev_addr))
dev_uc_del(dev, vlandev->dev_addr);
- /* vlan address was equal to the old address and is different from
+ /* vlan address was equal to the real address so now also inherit
* the new address */
- if (ether_addr_equal(vlandev->dev_addr, vlan->real_dev_addr) &&
- !ether_addr_equal(vlandev->dev_addr, dev->dev_addr))
- dev_uc_add(dev, vlandev->dev_addr);
+ if (real_addr_in_use)
+ ether_addr_copy(vlandev->dev_addr, dev->dev_addr);
ether_addr_copy(vlan->real_dev_addr, dev->dev_addr);
}
@@ -389,13 +392,8 @@ static int vlan_device_event(struct noti
case NETDEV_CHANGEADDR:
/* Adjust unicast filters on underlying device */
- vlan_group_for_each_dev(grp, i, vlandev) {
- flgs = vlandev->flags;
- if (!(flgs & IFF_UP))
- continue;
-
+ vlan_group_for_each_dev(grp, i, vlandev)
vlan_sync_address(dev, vlandev);
- }
break;
case NETDEV_CHANGEMTU:
--
1.7.10.4
^ permalink raw reply
* [PATCH] gre6: add Kconfig dependency for NET_IPGRE_DEMUX
From: Arnd Bergmann @ 2016-05-03 15:19 UTC (permalink / raw)
To: David S. Miller
Cc: Arnd Bergmann, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Tom Herbert, Thomas Egerer, Paolo Abeni, netdev,
linux-kernel
The ipv6 gre implementation was cleaned up to share more code
with the ipv4 version, but it can be enabled even when NET_IPGRE_DEMUX
is disabled, resulting in a link error:
net/built-in.o: In function `gre_rcv':
:(.text+0x17f5d0): undefined reference to `gre_parse_header'
ERROR: "gre_parse_header" [net/ipv6/ip6_gre.ko] undefined!
This adds a Kconfig dependency to prevent that now invalid
configuration.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE functions")
---
net/ipv6/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index 11e875ffd7ac..3f8411328de5 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -218,6 +218,7 @@ config IPV6_GRE
tristate "IPv6: GRE tunnel"
select IPV6_TUNNEL
select NET_IP_TUNNEL
+ depends on NET_IPGRE_DEMUX
---help---
Tunneling means encapsulating data of one protocol type within
another protocol and sending it over a channel that understands the
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net] vlan: Propagate MAC address changes properly
From: Mike Manning @ 2016-05-03 15:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160503.001651.132843090236435270.davem@davemloft.net>
On 05/03/2016 05:16 AM, David Miller wrote:
> From: Mike Manning <mmanning@brocade.com>
> Date: Sat, 30 Apr 2016 11:32:37 +0100
>
>> The MAC address of the physical interface is only copied to the VLAN
>> when it is first created, resulting in an inconsistency after MAC
>> address changes of only newly created VLANs having an up-to-date MAC.
>>
>> Continuing to inherit the MAC address unless explicitly changed for
>> the VLAN allows IPv6 EUI64 addresses for the VLAN to reflect the change
>> and thus for DAD to behave as expected for the given MAC.
>>
>> Signed-off-by: Mike Manning <mmanning@brocade.com>
>
> What is this code really trying to achieve?
>
> Is it "Propagate real device MAC changes to undelying vlan device,
> but not if the user set the vlan MAC explicitly."?
Right, I will update the subject header to make this clearer
>
> If so, implement that instead of all of these confusing tests.
>
> If the vlan device's set_mac_address operation is ever called,
> set a boolean value in the vlan device private to true and test
> it here.
>
Given that this information is implicit in real_dev_addr, I am reluctant
to add another member to the vlan_dev_priv data structure, especially given
that there may be a large number of VLANs. Instead I have added a variable
real_addr_in_use in vlan_sync_address() to make this clearer.
^ permalink raw reply
* Re: [PATCH net-next] gre: change gre_parse_header to return the header length
From: Tom Herbert @ 2016-05-03 15:18 UTC (permalink / raw)
To: Jiri Benc; +Cc: Linux Kernel Network Developers, David Miller
In-Reply-To: <3627136025fbd767d70e2ce563aa5e37373c880a.1462280197.git.jbenc@redhat.com>
On Tue, May 3, 2016 at 6:00 AM, Jiri Benc <jbenc@redhat.com> wrote:
> It's easier for gre_parse_header to return the header length instead of
> filing it into a parameter. That way, the callers that don't care about the
> header length can just check whether the returned value is lower than zero.
>
> In gre_err, the tunnel header must not be pulled. See commit b7f8fe251e46
> ("gre: do not pull header in ICMP error processing") for details.
>
> This patch reduces the conflict between the mentioned commit and commit
> 95f5c64c3c13 ("gre: Move utility functions to common headers").
>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> To resolve the conflict between net and net-next, please apply this patch to
> net-next and then pull net into net-next. At the conflicting places, take
> the hunks from net-next (including the large code removal at the beginning
> of ip_gre.c).
>
> The only exception is a call to gre_build_header/build_header in
> gre_fb_xmit; in there, also take the hunk from net-next but change
> "htons(ETH_P_TEB)" to "proto".
>
> Alternatively, this patch can be used during merge for the conflict
> resolution instead of committing it on its own.
> ---
> include/net/gre.h | 2 +-
> net/ipv4/gre_demux.c | 6 +++---
> net/ipv4/ip_gre.c | 9 +++------
> net/ipv6/ip6_gre.c | 3 ++-
> 4 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/gre.h b/include/net/gre.h
> index 29e37322c06e..a14093c70eab 100644
> --- a/include/net/gre.h
> +++ b/include/net/gre.h
> @@ -26,7 +26,7 @@ int gre_del_protocol(const struct gre_protocol *proto, u8 version);
> struct net_device *gretap_fb_dev_create(struct net *net, const char *name,
> u8 name_assign_type);
> int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
> - bool *csum_err, int *hdr_len);
> + bool *csum_err);
>
> static inline int gre_calc_hlen(__be16 o_flags)
> {
> diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
> index 371674801e84..a41e73ab1369 100644
> --- a/net/ipv4/gre_demux.c
> +++ b/net/ipv4/gre_demux.c
> @@ -60,8 +60,9 @@ int gre_del_protocol(const struct gre_protocol *proto, u8 version)
> }
> EXPORT_SYMBOL_GPL(gre_del_protocol);
>
> +/* Fills in tpi and returns header length to be pulled. */
> int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
> - bool *csum_err, int *ret_hdr_len)
> + bool *csum_err)
> {
> const struct gre_base_hdr *greh;
> __be32 *options;
> @@ -119,8 +120,7 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
> return -EINVAL;
> }
> }
> - *ret_hdr_len = hdr_len;
> - return 0;
> + return hdr_len;
> }
> EXPORT_SYMBOL(gre_parse_header);
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 2480d79b0e37..d4ee229880bf 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -221,16 +221,12 @@ static void gre_err(struct sk_buff *skb, u32 info)
> const int code = icmp_hdr(skb)->code;
> struct tnl_ptk_info tpi;
> bool csum_err = false;
> - int hdr_len;
>
> - if (gre_parse_header(skb, &tpi, &csum_err, &hdr_len)) {
> + if (gre_parse_header(skb, &tpi, &csum_err) < 0) {
> if (!csum_err) /* ignore csum errors. */
> return;
> }
>
> - if (iptunnel_pull_header(skb, hdr_len, tpi.proto, false))
> - return;
> -
> if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
> ipv4_update_pmtu(skb, dev_net(skb->dev), info,
> skb->dev->ifindex, 0, IPPROTO_GRE, 0);
> @@ -314,7 +310,8 @@ static int gre_rcv(struct sk_buff *skb)
> }
> #endif
>
> - if (gre_parse_header(skb, &tpi, &csum_err, &hdr_len) < 0)
> + hdr_len = gre_parse_header(skb, &tpi, &csum_err);
> + if (hdr_len < 0)
> goto drop;
>
> if (iptunnel_pull_header(skb, hdr_len, tpi.proto, false))
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index 10127741a60d..47b671a46dc4 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -468,7 +468,8 @@ static int gre_rcv(struct sk_buff *skb)
> bool csum_err = false;
> int hdr_len;
>
> - if (gre_parse_header(skb, &tpi, &csum_err, &hdr_len) < 0)
> + hdr_len = gre_parse_header(skb, &tpi, &csum_err);
> + if (hdr_len < 0)
> goto drop;
>
> if (iptunnel_pull_header(skb, hdr_len, tpi.proto, false))
> --
> 1.8.3.1
>
Acked-by: Tom Herbert <tom@herbertland.com>
^ permalink raw reply
* [PATCH net-next 3/3] gre: receive also TEB packets for lwtunnels
From: Jiri Benc @ 2016-05-03 15:10 UTC (permalink / raw)
To: netdev; +Cc: Thomas Graf, pravin shelar, Simon Horman
In-Reply-To: <cover.1462286214.git.jbenc@redhat.com>
For ipgre interfaces in collect metadata mode, receive also traffic with
encapsulated Ethernet headers. The lwtunnel users are supposed to sort this
out correctly. This allows to have mixed Ethernet + L3-only traffic on the
same lwtunnel interface. This is the same way as VXLAN-GPE behaves.
To keep backwards compatibility and prevent any surprises, gretap interfaces
have priority in receiving packets with Ethernet headers.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
include/net/ip_tunnels.h | 1 +
net/ipv4/ip_gre.c | 39 ++++++++++++++++++++++++++++-----------
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 6d790910ebdf..d916b4315903 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -160,6 +160,7 @@ struct tnl_ptk_info {
#define PACKET_RCVD 0
#define PACKET_REJECT 1
+#define PACKET_NEXT 2
#define IP_TNL_HASH_BITS 7
#define IP_TNL_HASH_SIZE (1 << IP_TNL_HASH_BITS)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 8f377dad5489..2b267e71ebf5 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -260,26 +260,20 @@ static __be32 tunnel_id_to_key(__be64 x)
#endif
}
-static int ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi,
- int hdr_len)
+static int __ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi,
+ struct ip_tunnel_net *itn, int hdr_len, bool raw_proto)
{
- struct net *net = dev_net(skb->dev);
struct metadata_dst *tun_dst = NULL;
- struct ip_tunnel_net *itn;
const struct iphdr *iph;
struct ip_tunnel *tunnel;
- if (tpi->proto == htons(ETH_P_TEB))
- itn = net_generic(net, gre_tap_net_id);
- else
- itn = net_generic(net, ipgre_net_id);
-
iph = ip_hdr(skb);
tunnel = ip_tunnel_lookup(itn, skb->dev->ifindex, tpi->flags,
iph->saddr, iph->daddr, tpi->key);
if (tunnel) {
- if (iptunnel_pull_header(skb, hdr_len, tpi->proto, false) < 0)
+ if (__iptunnel_pull_header(skb, hdr_len, tpi->proto,
+ raw_proto, false) < 0)
goto drop;
skb_pop_mac_header(skb);
@@ -297,13 +291,36 @@ static int ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi,
ip_tunnel_rcv(tunnel, skb, tpi, tun_dst, log_ecn_error);
return PACKET_RCVD;
}
- return PACKET_REJECT;
+ return PACKET_NEXT;
drop:
kfree_skb(skb);
return PACKET_RCVD;
}
+static int ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi,
+ int hdr_len)
+{
+ struct net *net = dev_net(skb->dev);
+ struct ip_tunnel_net *itn;
+ int res;
+
+ if (tpi->proto == htons(ETH_P_TEB))
+ itn = net_generic(net, gre_tap_net_id);
+ else
+ itn = net_generic(net, ipgre_net_id);
+
+ res = __ipgre_rcv(skb, tpi, itn, hdr_len, false);
+ if (res == PACKET_NEXT && tpi->proto == htons(ETH_P_TEB)) {
+ /* ipgre tunnels in collect metadata mode should receive
+ * also ETH_P_TEB traffic.
+ */
+ itn = net_generic(net, ipgre_net_id);
+ res = __ipgre_rcv(skb, tpi, itn, hdr_len, true);
+ }
+ return res;
+}
+
static int gre_rcv(struct sk_buff *skb)
{
struct tnl_ptk_info tpi;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/3] gre: remove superfluous pskb_may_pull
From: Jiri Benc @ 2016-05-03 15:10 UTC (permalink / raw)
To: netdev; +Cc: Thomas Graf, pravin shelar, Simon Horman
In-Reply-To: <cover.1462286214.git.jbenc@redhat.com>
The call to gre_parse_header is either followed by iptunnel_pull_header, or
in the case of ICMP error path, the actual header is not accessed at all.
In the first case, iptunnel_pull_header will call pskb_may_pull anyway and
it's pointless to do it twice. The only difference is what call will fail
with what error code but the net effect is still the same in all call sites.
In the second case, pskb_may_pull is pointless, as skb->data is at the outer
IP header and not at the GRE header.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/ipv4/gre_demux.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
index a41e73ab1369..d78e2eefc0f7 100644
--- a/net/ipv4/gre_demux.c
+++ b/net/ipv4/gre_demux.c
@@ -114,11 +114,8 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
*/
if (greh->flags == 0 && tpi->proto == htons(ETH_P_WCCP)) {
tpi->proto = htons(ETH_P_IP);
- if ((*(u8 *)options & 0xF0) != 0x40) {
+ if ((*(u8 *)options & 0xF0) != 0x40)
hdr_len += 4;
- if (!pskb_may_pull(skb, hdr_len))
- return -EINVAL;
- }
}
return hdr_len;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/3] gre: move iptunnel_pull_header down to ipgre_rcv
From: Jiri Benc @ 2016-05-03 15:10 UTC (permalink / raw)
To: netdev; +Cc: Thomas Graf, pravin shelar, Simon Horman
In-Reply-To: <cover.1462286214.git.jbenc@redhat.com>
This will allow to make the pull dependent on the tunnel type.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/ipv4/ip_gre.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 8260a707b9b8..8f377dad5489 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -260,7 +260,8 @@ static __be32 tunnel_id_to_key(__be64 x)
#endif
}
-static int ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi)
+static int ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi,
+ int hdr_len)
{
struct net *net = dev_net(skb->dev);
struct metadata_dst *tun_dst = NULL;
@@ -278,6 +279,9 @@ static int ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi)
iph->saddr, iph->daddr, tpi->key);
if (tunnel) {
+ if (iptunnel_pull_header(skb, hdr_len, tpi->proto, false) < 0)
+ goto drop;
+
skb_pop_mac_header(skb);
if (tunnel->collect_md) {
__be16 flags;
@@ -294,6 +298,10 @@ static int ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi)
return PACKET_RCVD;
}
return PACKET_REJECT;
+
+drop:
+ kfree_skb(skb);
+ return PACKET_RCVD;
}
static int gre_rcv(struct sk_buff *skb)
@@ -314,10 +322,7 @@ static int gre_rcv(struct sk_buff *skb)
if (hdr_len < 0)
goto drop;
- if (iptunnel_pull_header(skb, hdr_len, tpi.proto, false))
- goto drop;
-
- if (ipgre_rcv(skb, &tpi) == PACKET_RCVD)
+ if (ipgre_rcv(skb, &tpi, hdr_len) == PACKET_RCVD)
return 0;
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/3] gre: receive also TEB packets for lwtunnels
From: Jiri Benc @ 2016-05-03 15:10 UTC (permalink / raw)
To: netdev; +Cc: Thomas Graf, pravin shelar, Simon Horman
NOTE: this patchset needs net merged to net-next.
This allows lwtunnel users to get also packets with ETH_P_TEB protocol
specified in GRE header through an ipgre interface. There's really nothing
special about these packets in the case of lwtunnels - it's just an inner
protocol like any other. The only complications stem from keeping
compatibility with other uses of GRE.
This will be used by openvswitch to support eth_push and eth_pop actions.
I'd also like to see tc support for lwtunnels (this feature included) in the
future.
The first patch is not directly related and can be submitted standalone if
needed.
Jiri Benc (3):
gre: remove superfluous pskb_may_pull
gre: move iptunnel_pull_header down to ipgre_rcv
gre: receive also TEB packets for lwtunnels
include/net/ip_tunnels.h | 1 +
net/ipv4/gre_demux.c | 5 +----
net/ipv4/ip_gre.c | 48 +++++++++++++++++++++++++++++++++++-------------
3 files changed, 37 insertions(+), 17 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: pull request [net]: batman-adv 20160430
From: Antonio Quartulli @ 2016-05-03 14:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20160503.001813.1881857417530292443.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
On Tue, May 03, 2016 at 12:18:13AM -0400, David Miller wrote:
> Pulled, thanks Antonio.
Thanks a lot David.
We now have some patches for net-next that somewhat depend on the fixes you
have recently pulled.
Do you have any plan on merging net into net-next in the following days ?
I am asking because I'd prefer to avoid you the hassle of dealing with the
conflicts.
Cheers,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] net: fec: only clear a queue's work bit if the queue was emptied
From: Lucas Stach @ 2016-05-03 14:42 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Fugang Duan, David S . Miller, netdev, kernel
In-Reply-To: <1462286333-23402-1-git-send-email-u.kleine-koenig@pengutronix.de>
Am Dienstag, den 03.05.2016, 16:38 +0200 schrieb Uwe Kleine-König:
> In the receive path a queue's work bit was cleared unconditionally even
> if fec_enet_rx_queue only read out a part of the available packets from
> the hardware. This resulted in not reading any packets in the next napi
> turn and so packets were delayed or lost.
>
> The obvious fix is to only clear a queue's bit when the queue was
> emptied.
>
> Fixes: 4d494cdc92b3 ("net: fec: change data structure to support multiqueue")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Hello,
>
> I created this patch against net/master. If you think it's to late to
> get it into 4.6 and it doesn't fit on net-next/master, just tell me and
> I will rebase.
>
> Best regards
> Uwe
>
>
> drivers/net/ethernet/freescale/fec_main.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index 08243c2ff4b4..2a03857cca18 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1521,9 +1521,15 @@ fec_enet_rx(struct net_device *ndev, int budget)
> struct fec_enet_private *fep = netdev_priv(ndev);
>
> for_each_set_bit(queue_id, &fep->work_rx, FEC_ENET_MAX_RX_QS) {
> - clear_bit(queue_id, &fep->work_rx);
> - pkt_received += fec_enet_rx_queue(ndev,
> + int ret;
> +
> + ret = fec_enet_rx_queue(ndev,
> budget - pkt_received, queue_id);
> +
> + if (ret < budget - pkt_received)
> + clear_bit(queue_id, &fep->work_rx);
> +
> + pkt_received += ret;
> }
> return pkt_received;
> }
^ permalink raw reply
* Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions
From: David B. Robins @ 2016-05-03 14:42 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Dean Jenkins, Mark Craske, David S. Miller, YongQin Liu,
Guodong Xu, linux-usb, netdev, Ivan Vecera
In-Reply-To: <CALAqxLUj+-yUGTNviHu4+KE9=JTxjZyHBv4pdUob=xndAr8ZmA@mail.gmail.com>
On 2016-05-03 00:55, John Stultz wrote:
> In testing with HiKey, we found that since commit 3f30b158eba5c60
> (asix: On RX avoid creating bad Ethernet frames), we're seeing lots of
> noise during network transfers:
>
> [ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
> synchronisation was lost, remaining 988
> [ 239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
> 0x54ebb5ec, offset 4
> [ 239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
> 0xcdffe7a2, offset 4
> [ 239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
> synchronisation was lost, remaining 988
> [ 239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
> 0x1d36f59d, offset 4
> [ 239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
> 0xaef3c1e9, offset 4
> [ 239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
> synchronisation was lost, remaining 988
> [ 239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
> 0x2881912, offset 4
> [ 239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
> 0x5638f7e2, offset 4
>
> And network throughput ends up being pretty bursty and slow with a
> overall throughput of at best ~30kB/s.
>
> Looking through the commits since the v4.1 kernel where we didn't see
> this, I narrowed the regression down, and reverting the following two
> commits seems to avoid the problem:
>
> 6a570814cd430fa5ef4f278e8046dcf12ee63f13 asix: Continue processing URB
> if no RX netdev buffer
> 3f30b158eba5c604b6e0870027eef5d19fc9271d asix: On RX avoid creating
> bad Ethernet frames
>
> With these reverted, we don't see all the error messages, and we see
> better ~1.1MB/s throughput (I've got a mouse plugged in, so I think
> the usb host is only running at "full-speed" mode here).
I don't think the first one is giving you problems (except as triggered
by the second) but I had concerns about the second myself (and emailed
the author off-list, but received no reply), and we did not take that
commit for our own product.
Specifically, the second change, 3f30... (original patch:
https://www.mail-archive.com/netdev@vger.kernel.org/msg80720.html) (1)
appears to do the exact opposite of what it claims, i.e., instead of
"resync if this looks like a header", it does "resync if this does NOT
look like a (packet) header", where "looks like a header" means "bits
0-10 (size) are equal to the bitwise-NOT of bits 16-26", and (2) can
happen by coincidence for 1/2048 32-bit values starting a continuation
URB (easy to hit dealing with large volumes of video data as we were).
It appears to expect the header for every URB whereas the rest of the
code at least expects it only once per network packet (look at following
code that only reads it for remaining == 0).
So that change made no sense to me, but I don't have significant kernel
dev experience. Effectively it will drop/truncate every (2047/2048)
split (longer than an URB) packet, and report an error for the second
URB and then again for treating said second URB as a first URB for a
packet. I would expect your problems will go away just removing the
second change. You could also change the != to == in "if (size != ...)"
but then you'd still have 1/2048 (depending on data patterns) false
positives.
> This worries me some, as the patches seem to describe trying to fix
> the issue they seem to cause, so I suspect a revert isn't the correct
> solution, but am not sure why we're having such trouble and the patch
> authors did not. I'd be happy to do further testing of patches if
> folks have any ideas.
>
> Originally Reported-by: Yongqin Liu <yongqin.liu@linaro.org>
>
> thanks
> -john
David
^ permalink raw reply
* [PATCH] net: fec: only clear a queue's work bit if the queue was emptied
From: Uwe Kleine-König @ 2016-05-03 14:38 UTC (permalink / raw)
To: Fugang Duan, David S . Miller; +Cc: kernel, netdev
In the receive path a queue's work bit was cleared unconditionally even
if fec_enet_rx_queue only read out a part of the available packets from
the hardware. This resulted in not reading any packets in the next napi
turn and so packets were delayed or lost.
The obvious fix is to only clear a queue's bit when the queue was
emptied.
Fixes: 4d494cdc92b3 ("net: fec: change data structure to support multiqueue")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
I created this patch against net/master. If you think it's to late to
get it into 4.6 and it doesn't fit on net-next/master, just tell me and
I will rebase.
Best regards
Uwe
drivers/net/ethernet/freescale/fec_main.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 08243c2ff4b4..2a03857cca18 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1521,9 +1521,15 @@ fec_enet_rx(struct net_device *ndev, int budget)
struct fec_enet_private *fep = netdev_priv(ndev);
for_each_set_bit(queue_id, &fep->work_rx, FEC_ENET_MAX_RX_QS) {
- clear_bit(queue_id, &fep->work_rx);
- pkt_received += fec_enet_rx_queue(ndev,
+ int ret;
+
+ ret = fec_enet_rx_queue(ndev,
budget - pkt_received, queue_id);
+
+ if (ret < budget - pkt_received)
+ clear_bit(queue_id, &fep->work_rx);
+
+ pkt_received += ret;
}
return pkt_received;
}
--
2.8.0.rc3
^ permalink raw reply related
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