* Re: [PATCH net-next] fq_codel: add batch ability to fq_codel_drop()
From: David Miller @ 2016-05-03 16:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dave.taht, chromatix99
In-Reply-To: <1462146446.5535.236.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 01 May 2016 16:47:26 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> In presence of inelastic flows and stress, we can call
> fq_codel_drop() for every packet entering fq_codel qdisc.
>
> fq_codel_drop() is quite expensive, as it does a linear scan
> of 4 KB of memory to find a fat flow.
> Once found, it drops the oldest packet of this flow.
>
> Instead of dropping a single packet, try to drop 50% of the backlog
> of this fat flow, with a configurable limit of 64 packets per round.
>
> TCA_FQ_CODEL_DROP_BATCH_SIZE is the new attribute to make this
> limit configurable.
>
> With this strategy the 4 KB search is amortized to a single cache line
> per drop [1], so fq_codel_drop() no longer appears at the top of kernel
> profile in presence of few inelastic flows.
>
> [1] Assuming a 64byte cache line, and 1024 buckets
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dave Taht <dave.taht@gmail.com>
> Cc: Jonathan Morton <chromatix99@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v2] ravb: Remove rx buffer ALIGN
From: David Miller @ 2016-05-03 16:45 UTC (permalink / raw)
To: ykaneko0929
Cc: netdev, sergei.shtylyov, horms, magnus.damm, linux-renesas-soc
In-Reply-To: <1462115991-27241-1-git-send-email-ykaneko0929@gmail.com>
From: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Date: Mon, 2 May 2016 00:19:51 +0900
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> Aligning the reception data size is not required.
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> Tested-by: Simon Horman <horms+renesas@verge.net.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v1 net] net/mlx4: Avoid wrong virtual mappings
From: David Miller @ 2016-05-03 16:41 UTC (permalink / raw)
To: hagaya
Cc: dledford, linux-rdma, netdev, okaya, timur, eli, ogerlitz, eranbe,
yishaih, talal, saeedm
In-Reply-To: <1461740820-15386-1-git-send-email-hagaya@mellanox.com>
From: Haggai Abramovsky <hagaya@mellanox.com>
Date: Wed, 27 Apr 2016 10:07:00 +0300
> @@ -419,7 +419,8 @@ static int set_rq_size(struct mlx4_ib_dev *dev, struct ib_qp_cap *cap,
> }
>
> static int set_kernel_sq_size(struct mlx4_ib_dev *dev, struct ib_qp_cap *cap,
> - enum mlx4_ib_qp_type type, struct mlx4_ib_qp *qp)
> + enum mlx4_ib_qp_type type, struct mlx4_ib_qp *qp,
> + int shrink_wqe)
> {
> int s;
>
Please use 'bool' and "true/false" for shrink_wqe.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: hns: update DT properties according to Rob's comments
From: David Miller @ 2016-05-03 16:37 UTC (permalink / raw)
To: robh
Cc: Yisen.Zhuang, devicetree, netdev, linux-arm-kernel, pawel.moll,
mark.rutland, ijc+devicetree, galak, will.deacon, catalin.marinas,
yankejian, huangdaode, salil.mehta, lipeng321, liguozhu,
xieqianqian, xuwei5, linuxarm
In-Reply-To: <20160503162444.GA4087@rob-hp-laptop>
From: Rob Herring <robh@kernel.org>
Date: Tue, 3 May 2016 11:24:44 -0500
> On Fri, Apr 29, 2016 at 01:39:49PM -0400, David Miller wrote:
>> From: Yisen Zhuang <Yisen.Zhuang@huawei.com>
>> Date: Thu, 28 Apr 2016 15:09:00 +0800
>>
>> > There are some inappropriate properties definition in hns DT. We update the definition
>> > according to Rob's review comments and fix some typos in binding.
>> >
>> > For more details, please see individual patches.
>>
>> Series applied, thanks.
>
> It would be nice to review patches addressing my comments before they
> get applied. Can you please give series with DT bindings a few more days
> for review before applying.
I can't go more than a day or so days, I refuse to let patches rot in
my backlog for more than that. I get sometimes a hundred new patch
submissions a day and what you are asking me to do would make maintainence
untenable for everyone, sorry.
Just be quicker on the review, then there are no problems.
^ permalink raw reply
* Re: [PATCH net v2] vlan: Propagate MAC address to VLANs unless explicitly set
From: David Miller @ 2016-05-03 16:36 UTC (permalink / raw)
To: mmanning; +Cc: netdev
In-Reply-To: <5728C1AC.3090708@brocade.com>
There is, at the very least, a two byte hole in the vlan_dev_priv structure.
Put the boolean there as I asked you to.
^ permalink raw reply
* Re: [PATCH net] vlan: Propagate MAC address changes properly
From: David Miller @ 2016-05-03 16:34 UTC (permalink / raw)
To: mmanning; +Cc: netdev
In-Reply-To: <5728C152.7090007@brocade.com>
From: Mike Manning <mmanning@brocade.com>
Date: Tue, 3 May 2016 16:18:42 +0100
> Given that this information is implicit in real_dev_addr
That's not the reason to make or not make the simplification I
asked you do.
You can add a multi-page comment to this code, and the confusing
tests are still rediculous.
Please add the boolean state as I asked you to.
^ permalink raw reply
* Re: pull request [net]: batman-adv 20160430
From: David Miller @ 2016-05-03 16:33 UTC (permalink / raw)
To: a
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20160503144229.GD11201-bY/dlpGjfuDhXIiyNabO3w@public.gmane.org>
From: Antonio Quartulli <a@unstable.cc>
Date: Tue, 3 May 2016 22:42:29 +0800
> 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.
I'll try to do this in the next few days.
^ permalink raw reply
* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: Saeed Mahameed @ 2016-05-03 16:28 UTC (permalink / raw)
To: David Miller
Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz, Tal Alon,
Eran Ben Elisha
In-Reply-To: <20160503.121845.38810507805302539.davem@davemloft.net>
On Tue, May 3, 2016 at 7:18 PM, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
>
> The first posting is implicitly "V1" and any subsequent version is
> therefore "v2", "v3", and so on.
>
Didn't know that, I am used to send V1 as an update of the first posting
Will change that habit.
Thanks
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: hns: update DT properties according to Rob's comments
From: Rob Herring @ 2016-05-03 16:24 UTC (permalink / raw)
To: David Miller
Cc: Yisen.Zhuang, devicetree, netdev, linux-arm-kernel, pawel.moll,
mark.rutland, ijc+devicetree, galak, will.deacon, catalin.marinas,
yankejian, huangdaode, salil.mehta, lipeng321, liguozhu,
xieqianqian, xuwei5, linuxarm
In-Reply-To: <20160429.133949.1719521222260369497.davem@davemloft.net>
On Fri, Apr 29, 2016 at 01:39:49PM -0400, David Miller wrote:
> From: Yisen Zhuang <Yisen.Zhuang@huawei.com>
> Date: Thu, 28 Apr 2016 15:09:00 +0800
>
> > There are some inappropriate properties definition in hns DT. We update the definition
> > according to Rob's review comments and fix some typos in binding.
> >
> > For more details, please see individual patches.
>
> Series applied, thanks.
It would be nice to review patches addressing my comments before they
get applied. Can you please give series with DT bindings a few more days
for review before applying.
Rob
^ permalink raw reply
* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: Saeed Mahameed @ 2016-05-03 16:20 UTC (permalink / raw)
To: David Miller
Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz, Tal Alon,
Eran Ben Elisha
In-Reply-To: <20160503.121254.1213266710265417601.davem@davemloft.net>
On Tue, May 3, 2016 at 7:12 PM, David Miller <davem@davemloft.net> wrote:
>
> Please don't have two patch series pending for the same driver (mlx5) and
> the same tree (net-next).
>
This is V1 of the the only ongoing series I have for net-next
what other series are you referring to ?
^ permalink raw reply
* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: David Miller @ 2016-05-03 16:18 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, talal, eranbe
In-Reply-To: <20160503.121254.1213266710265417601.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 03 May 2016 12:12:54 -0400 (EDT)
>
> 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.
Sorry, I just realized this is a new version of the previous series.
What confused me is "V1", because this isn't "V1". Please don't number
things like that.
The first posting is implicitly "V1" and any subsequent version is
therefore "v2", "v3", and so on.
Thanks.
^ permalink raw reply
* Re: [PATCH net v3 4/5] dt: cpsw: phy-handle, phy_id, and fixed-link are mutually exclusive
From: Rob Herring @ 2016-05-03 16:14 UTC (permalink / raw)
To: David Rivshin (Allworx)
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller, Mugunthan V N,
Grygorii Strashko, Andrew Goodbody, Markus Brunner,
Nicolas Chauvet
In-Reply-To: <1461807767-4563-1-git-send-email-drivshin.allworx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Apr 27, 2016 at 09:42:47PM -0400, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivshin-5fOYsn7Fw8lBDgjK7y7TUQ@public.gmane.org>
>
> The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> and only one need be specified. Make this clear in the binding doc.
>
> Also mark the phy_id property as deprecated, as phy-handle should be
> used instead.
>
> Signed-off-by: David Rivshin <drivshin-5fOYsn7Fw8lBDgjK7y7TUQ@public.gmane.org>
> ---
>
> Changes since v2 [1]:
> - split from previous patch 2
> - marked the phy_id property as deprecated [3]
> - removed Rob Herring's Acked-by due to above change
>
> Changes since v1 [2]:
> - Rebased (no conflicts)
> - Added Tested-by from Nicolas Chauvet
> - Added Acked-by from Rob Herring for the binding change
>
> [1] http://patchwork.ozlabs.org/patch/613260/
> [2] http://patchwork.ozlabs.org/patch/560324/
> [3] https://lkml.org/lkml/2016/4/22/494
>
>
> Documentation/devicetree/bindings/net/cpsw.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 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
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