* Re: [net PATCH v4 5/6] virtio: add pci_down/pci_up configuration
From: Jason Wang @ 2017-01-16 3:57 UTC (permalink / raw)
To: John Fastabend, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170116000119.28980.89712.stgit@john-Precision-Tower-5810>
On 2017年01月16日 08:01, John Fastabend wrote:
> In virtio_net we need to do a full reset of the device to support
> queue reconfiguration and also we can trigger this via ethtool
> commands. So instead of open coding this in net driver push this
> into generic code in virtio. This also avoid exporting a handful
> of internal virtio routines.
Looks like this is not a pci specific stuffs. And there's some driver
left (e.g scsi and block).
In fact, I'm not sure touching other drivers is really needed. Maybe we
can just:
- move virtio_device_freeze(), virtio_device_restore() and
.freeze/.restore in virtio_driver out of CONFIG_PM_SLEEP
- move virtnet_freeze() and virtnet_restore() out of CONFIG_PM_SLEEP
- introduce virtio_net_reset() and call
virtio_device_freeze()/virtio_device_restore() there
Another possible issue for sleep/hibernation is xdp_prog were not
restored, if this is not XDP intended, we'd better fix this.
Thanks
[...]
^ permalink raw reply
* Re: [net PATCH v4 5/6] virtio: add pci_down/pci_up configuration
From: John Fastabend @ 2017-01-16 4:04 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <8844bce3-74bc-fca3-a87b-6736fc62fe62@redhat.com>
On 17-01-15 07:57 PM, Jason Wang wrote:
>
>
> On 2017年01月16日 08:01, John Fastabend wrote:
>> In virtio_net we need to do a full reset of the device to support
>> queue reconfiguration and also we can trigger this via ethtool
>> commands. So instead of open coding this in net driver push this
>> into generic code in virtio. This also avoid exporting a handful
>> of internal virtio routines.
>
> Looks like this is not a pci specific stuffs. And there's some driver left (e.g
> scsi and block).
>
> In fact, I'm not sure touching other drivers is really needed. Maybe we can just:
> - move virtio_device_freeze(), virtio_device_restore() and .freeze/.restore in
> virtio_driver out of CONFIG_PM_SLEEP
> - move virtnet_freeze() and virtnet_restore() out of CONFIG_PM_SLEEP
> - introduce virtio_net_reset() and call
> virtio_device_freeze()/virtio_device_restore() there
>
Michael, what do you think? I was following your suggestion on writing a
generic virtio reset here. I don't have a preference either way.
> Another possible issue for sleep/hibernation is xdp_prog were not restored, if
> this is not XDP intended, we'd better fix this.
Yep this bug exists even without this series. I'll add it to my list of things
to fix. Along with small packet max_mtu.
>
> Thanks
>
> [...]
^ permalink raw reply
* Re: [PATCH 1/2] qed: Replace memset with eth_zero_addr
From: David Miller @ 2017-01-16 4:38 UTC (permalink / raw)
To: mayhs11saini; +Cc: Yuval.Mintz, Ariel.Elior, everest-linux-l2, netdev
In-Reply-To: <1484538277-21376-1-git-send-email-mayhs11saini@gmail.com>
Please do not ever submit two patches which have the same exact commit
header line, as these two patches do.
When someone looks into the shortlog of GIT history all they will see
is "qed: Replace memset with eth_zero_addr" twice.
This gives the reader no idea what might be different between those
two changes.
Therefore you must give unique a commit header text for each change,
which communicates sufficiently what is different in each change.
^ permalink raw reply
* Re: [PATCH v2 net-next] net:add one common config ARCH_WANT_RELAX_ORDER to support relax ordering.
From: David Miller @ 2017-01-16 4:40 UTC (permalink / raw)
To: maowenan; +Cc: netdev, jeffrey.t.kirsher, alexander.duyck
In-Reply-To: <1483939954-9864-1-git-send-email-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Mon, 9 Jan 2017 13:32:34 +0800
> Relax ordering(RO) is one feature of 82599 NIC, to enable this feature can
> enhance the performance for some cpu architecure, such as SPARC and so on.
> Currently it only supports one special cpu architecture(SPARC) in 82599
> driver to enable RO feature, this is not very common for other cpu architecture
> which really needs RO feature.
> This patch add one common config CONFIG_ARCH_WANT_RELAX_ORDER to set RO feature,
> and should define CONFIG_ARCH_WANT_RELAX_ORDER in sparc Kconfig firstly.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Alexander and Jeff, please review.
^ permalink raw reply
* Re: pull-request: mac80211 2017-01-13
From: David Miller @ 2017-01-16 4:47 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170113135516.19593-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Fri, 13 Jan 2017 14:55:15 +0100
> Here's another update for the current cycle. Some of those
> patches have been sitting in our tree and I haven't been
> pulling them out quickly enough - will try to do better...
>
> Please pull and let me know if there's any problem.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH net 1/3] be2net: fix status check in be_cmd_pmac_add()
From: David Miller @ 2017-01-16 4:49 UTC (permalink / raw)
To: cera
Cc: netdev, sathya.perla, ajit.khaparde, sriharsha.basavapatna,
somnath.kotur
In-Reply-To: <20170113213829.22722-1-cera@cera.cz>
From: Ivan Vecera <cera@cera.cz>
Date: Fri, 13 Jan 2017 22:38:27 +0100
> Return value from be_mcc_notify_wait() contains a base completion status
> together with an additional status. The base_status() macro need to be
> used to access base status.
>
> Fixes: e3a7ae2 be2net: Changing MAC Address of a VF was broken
> Cc: Sathya Perla <sathya.perla@broadcom.com>
> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
> Cc: Somnath Kotur <somnath.kotur@broadcom.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/3] be2net: don't delete MAC on close on unprivileged BE3 VFs
From: David Miller @ 2017-01-16 4:50 UTC (permalink / raw)
To: cera
Cc: netdev, sathya.perla, ajit.khaparde, sriharsha.basavapatna,
somnath.kotur
In-Reply-To: <20170113213829.22722-2-cera@cera.cz>
From: Ivan Vecera <cera@cera.cz>
Date: Fri, 13 Jan 2017 22:38:28 +0100
> BE3 VFs without FILTMGMT privilege are not allowed to modify its MAC,
> VLAN table and UC/MC lists. So don't try to delete MAC on such VFs.
>
> Cc: Sathya Perla <sathya.perla@broadcom.com>
> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
> Cc: Somnath Kotur <somnath.kotur@broadcom.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
Applied.
^ permalink raw reply
* Re: [PATCH net 3/3] be2net: fix MAC addr setting on privileged BE3 VFs
From: David Miller @ 2017-01-16 4:50 UTC (permalink / raw)
To: cera
Cc: netdev, sathya.perla, ajit.khaparde, sriharsha.basavapatna,
somnath.kotur
In-Reply-To: <20170113213829.22722-3-cera@cera.cz>
From: Ivan Vecera <cera@cera.cz>
Date: Fri, 13 Jan 2017 22:38:29 +0100
> During interface opening MAC address stored in netdev->dev_addr is
> programmed in the HW with exception of BE3 VFs where the initial
> MAC is programmed by parent PF. This is OK when MAC address is not
> changed when an interfaces is down. In this case the requested MAC is
> stored to netdev->dev_addr and later is stored into HW during opening.
> But this is not done for all BE3 VFs so the NIC HW does not know
> anything about this change and all traffic is filtered.
>
> This is the case of bonding if fail_over_mac == 0 where the MACs of
> the slaves are changed while they are down.
>
> The be2net behavior is too restrictive because if a BE3 VF has
> the FILTMGMT privilege then it is able to modify its MAC without
> any restriction.
>
> To solve the described problem the driver should take care about these
> privileged BE3 VFs so the MAC is programmed during opening. And by
> contrast unpriviled BE3 VFs should not be allowed to change its MAC
> in any case.
>
> Cc: Sathya Perla <sathya.perla@broadcom.com>
> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
> Cc: Somnath Kotur <somnath.kotur@broadcom.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
Applied.
^ permalink raw reply
* Re: [net PATCH v4 6/6] virtio_net: XDP support for adjust_head
From: Jason Wang @ 2017-01-16 5:48 UTC (permalink / raw)
To: John Fastabend, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170116000142.28980.22658.stgit@john-Precision-Tower-5810>
On 2017年01月16日 08:01, John Fastabend wrote:
> Add support for XDP adjust head by allocating a 256B header region
> that XDP programs can grow into. This is only enabled when a XDP
> program is loaded.
>
> In order to ensure that we do not have to unwind queue headroom push
> queue setup below bpf_prog_add. It reads better to do a prog ref
> unwind vs another queue setup call.
>
> At the moment this code must do a full reset to ensure old buffers
> without headroom on program add or with headroom on program removal
> are not used incorrectly in the datapath. Ideally we would only
> have to disable/enable the RX queues being updated but there is no
> API to do this at the moment in virtio so use the big hammer. In
> practice it is likely not that big of a problem as this will only
> happen when XDP is enabled/disabled changing programs does not
> require the reset. There is some risk that the driver may either
> have an allocation failure or for some reason fail to correctly
> negotiate with the underlying backend in this case the driver will
> be left uninitialized. I have not seen this ever happen on my test
> systems and for what its worth this same failure case can occur
> from probe and other contexts in virtio framework.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/virtio_net.c | 110 ++++++++++++++++++++++++++++++++++------------
> 1 file changed, 82 insertions(+), 28 deletions(-)
>
[...]
> - vi->xdp_queue_pairs = xdp_qp;
> netif_set_real_num_rx_queues(dev, curr_qp + xdp_qp);
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> @@ -1746,6 +1789,21 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> }
>
> return 0;
> +
> +virtio_reset_err:
> + /* On reset error do our best to unwind XDP changes inflight and return
> + * error up to user space for resolution. The underlying PCI reset hung
> + * on us so not much we can do here.
It should work with other transport, so let's remove "PCI" here.
> + */
> + dev_warn(&dev->dev, "XDP reset failure and queues unstable\n");
> + vi->xdp_queue_pairs = oxdp_qp;
> +virtio_queue_err:
> + /* On queue set error we can unwind bpf ref count and user space can
> + * retry this is most likely an allocation failure.
> + */
> + if (prog)
> + bpf_prog_sub(prog, vi->max_queue_pairs - 1);
> + return err;
> }
>
> static bool virtnet_xdp_query(struct net_device *dev)
> @@ -2373,7 +2431,6 @@ static void virtnet_remove(struct virtio_device *vdev)
> free_netdev(vi->dev);
> }
>
> -#ifdef CONFIG_PM_SLEEP
> static int virtnet_freeze(struct virtio_device *vdev)
> {
> struct virtnet_info *vi = vdev->priv;
> @@ -2430,7 +2487,6 @@ static int virtnet_restore(struct virtio_device *vdev)
>
> return 0;
> }
> -#endif
If you do want to use virtio_device_reset(), it's better to squash this
into patch 5/6.
Other looks good.
Thanks
^ permalink raw reply
* Re: [net PATCH v4 0/6] virtio_net XDP fixes and adjust_header support
From: Jason Wang @ 2017-01-16 5:51 UTC (permalink / raw)
To: John Fastabend, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170115235528.28980.85142.stgit@john-Precision-Tower-5810>
On 2017年01月16日 07:59, John Fastabend wrote:
> This has a fix to handle small buffer free logic correctly and then
> also adds adjust head support.
>
> I pushed adjust head at net (even though its rc3) to avoid having
> to push another exception case into virtio_net to catch if the
> program uses adjust_head and then block it. If there are any strong
> objections to this we can push it at net-next and use a patch from
> Jakub to add the exception handling but then user space has to deal
> with it either via try/fail logic or via kernel version checks. Granted
> we already have some cases that need to be configured to enable XDP
> but I don't see any reason to have yet another one when we can fix it
> now vs delaying a kernel version.
>
>
> v2: fix spelling error, convert unsigned -> unsigned int
> v3: v2 git crashed during send so retrying sorry for the noise
> v4: changed layout of rtnl_lock fixes (Stephen)
> moved reset logic into virtio core with new patch (MST)
> fixed up linearize and some code cleanup (Jason)
>
> Otherwise did some generic code cleanup so might be a bit
> cleaner this time at least that is the hope.
>
> Thanks everyone for the v3 review.
Thanks, looks good to me overall, just few nits.
^ permalink raw reply
* Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
From: Juergen Gross @ 2017-01-16 6:24 UTC (permalink / raw)
To: Remanan Pillai, boris.ostrovsky, xen-devel, netdev, linux-kernel
Cc: Vineeth Remanan Pillai, kamatam, aliguori
In-Reply-To: <1484330100-3960-1-git-send-email-vineethp@u480fcf3b67f557f68df1.ant.amazon.com>
On 13/01/17 18:55, Remanan Pillai wrote:
> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
>
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
>
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
>
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Thanks,
Juergen
^ permalink raw reply
* Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats
From: Dmitry Vyukov @ 2017-01-16 7:11 UTC (permalink / raw)
To: Neil Horman
Cc: Vladislav Yasevich, David Miller, linux-sctp, netdev, LKML,
Kees Cook, syzkaller
In-Reply-To: <20170115203515.GA6274@neilslaptop.think-freely.org>
On Sun, Jan 15, 2017 at 9:35 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Sun, Jan 15, 2017 at 06:29:59PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
>> now I am seeing lots of:
>>
> If I'm not mistaken, its because thats specifically what that option does. From
> the Kconfig:
> onfig HARDENED_USERCOPY_PAGESPAN
> bool "Refuse to copy allocations that span multiple pages"
> depends on HARDENED_USERCOPY
> depends on EXPERT
> help
> When a multi-page allocation is done without __GFP_COMP,
> hardened usercopy will reject attempts to copy it. There are,
> however, several cases of this in the kernel that have not all
> been removed. This config is intended to be used only while
> trying to find such users.
>
> So, if the fuzzer does a setsockopt and the data it passes crosses a page
> boundary, it seems like this will get triggered. Based on the fact that its
> only used to find users that do this, it seems like not the sort of thing that
> you want enabled while running a fuzzer that might do it arbitrarily.
The code also takes into account compound pages. As far as I
understand the intention of the check is to effectively find
out-of-bounds copies (e.g. goes beyond the current heap allocation). I
would expect that stacks are allocated as compound pages and don't
trigger this check. I don't see it is firing in other similar places.
>> usercopy: kernel memory overwrite attempt detected to ffff8801a74f6f10
>> (<spans multiple pages>) (256 bytes)
>>
>> kernel BUG at mm/usercopy.c:75!
>> invalid opcode: 0000 [#1] SMP KASAN
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 15686 Comm: syz-executor3 Not tainted 4.9.0 #1
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> task: ffff8801c89b2500 task.stack: ffff8801a74f0000
>> RIP: 0010:[<ffffffff81a1b041>] [<ffffffff81a1b041>] report_usercopy
>> mm/usercopy.c:67 [inline]
>> RIP: 0010:[<ffffffff81a1b041>] [<ffffffff81a1b041>]
>> __check_object_size+0x2d1/0x9ec mm/usercopy.c:278
>> RSP: 0018:ffff8801a74f6cd0 EFLAGS: 00010286
>> RAX: 000000000000006b RBX: ffffffff84500120 RCX: 0000000000000000
>> RDX: 000000000000006b RSI: ffffffff815a7791 RDI: ffffed0034e9ed8c
>> RBP: ffff8801a74f6e48 R08: 0000000000000001 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000001 R12: ffff8801a74f6f10
>> R13: 0000000000000100 R14: ffffffff845000e0 R15: ffff8801a74f700f
>> FS: 00007f80918de700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000020058ffc CR3: 00000001cc1cc000 CR4: 00000000001406e0
>> Stack:
>> ffffffff8598fcc8 0000000000000000 000077ff80000000 ffffea0005c99608
>> ffffffff844fff40 ffffffff844fff40 0000000041b58ab3 ffffffff84ae0fa0
>> ffffffff81a1ad70 ffff8801c89b2500 dead000000000100 ffffffff814d4425
>> Call Trace:
>> [<ffffffff83e4ece9>] check_object_size include/linux/thread_info.h:129 [inline]
>> [<ffffffff83e4ece9>] copy_from_user arch/x86/include/asm/uaccess.h:692 [inline]
>> [<ffffffff83e4ece9>] sctp_getsockopt_assoc_stats+0x169/0xa10
>> net/sctp/socket.c:6182
>> [<ffffffff83e5cc52>] sctp_getsockopt+0x1af2/0x66a0 net/sctp/socket.c:6556
>> [<ffffffff834f92c5>] sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2649
>> [<ffffffff834f4910>] SYSC_getsockopt net/socket.c:1788 [inline]
>> [<ffffffff834f4910>] SyS_getsockopt+0x240/0x380 net/socket.c:1770
>> [<ffffffff81009798>] do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:280
>> [<ffffffff84370a49>] entry_SYSCALL64_slow_path+0x25/0x25
>> Code: b0 fe ff ff e8 e1 25 ce ff 48 8b 85 b0 fe ff ff 4d 89 e9 4c 89
>> e1 4c 89 f2 48 89 de 48 c7 c7 a0 01 50 84 49 89 c0 e8 51 d9 e0 ff <0f>
>> 0b e8 b8 25 ce ff 4c 89 f2 4c 89 ee 4c 89 e7 e8 6a 1b fc ff
>> RIP [<ffffffff81a1b041>] report_usercopy mm/usercopy.c:67 [inline]
>> RIP [<ffffffff81a1b041>] __check_object_size+0x2d1/0x9ec mm/usercopy.c:278
>> RSP <ffff8801a74f6cd0>
>> ---[ end trace 5e438996b2c0b35d ]---
>>
>>
>> I am not sure why check_object_size flags this an a bug,
>> copy_from_user copies into a stack object:
>>
>> static int sctp_getsockopt_assoc_stats(struct sock *sk, int len,
>> char __user *optval,
>> int __user *optlen)
>> {
>> struct sctp_assoc_stats sas;
>> len = min_t(size_t, len, sizeof(sas));
>> if (copy_from_user(&sas, optval, len))
>> return -EFAULT;
>>
>> Kees, can this be a false positive?
>>
>> On commit f4d3935e4f4884ba80561db5549394afb8eef8f7.
>>
^ permalink raw reply
* Re: [PATCH net-next v3 1/1] net sched actions: Add support for user cookies
From: Jiri Pirko @ 2017-01-16 7:27 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, netdev, jiri, paulb, john.fastabend, simon.horman, mrv,
hadarh, ogerlitz, roid, xiyou.wangcong, daniel
In-Reply-To: <ac5fe140-e52a-ff5c-dafe-2d6841b07560@mojatatu.com>
Sun, Jan 15, 2017 at 04:18:20PM CET, jhs@mojatatu.com wrote:
>On 17-01-15 10:01 AM, Jiri Pirko wrote:
>> Sun, Jan 15, 2017 at 03:01:19PM CET, jhs@mojatatu.com wrote:
>
>> > +cls_set_class(struct tcf_proto *tp, unsigned long *clp,
>>
>> ??
>>
>> > unsigned long cl)
>> > {
>> > unsigned long old_cl;
>> > -
>> > +
>>
>> ??
>>
>> > tcf_tree_lock(tp);
>> > old_cl = __cls_set_class(clp, cl);
>> > tcf_tree_unlock(tp);
>> > -
>> > +
>>
>> ??
>>
>> > return old_cl;
>> > }
>> >
>> > @@ -237,7 +237,7 @@ static inline int tcf_em_early_end(struct tcf_ematch *em, int result)
>> >
>> > return 0;
>> > }
>> > -
>> > +
>>
>> ??
>>
>
>All these things with "??" were annoying whitespace and stylistic
>things my fingers couldnt resist. It is legit to include such changes
>in a patch when touching the code (as long as not a bug fix).
Well, I think you should change this in a separate patch as it has 0
relation with this patch.
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Michal Hocko @ 2017-01-16 7:33 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Andrew Morton, Vlastimil Babka, David Rientjes, Mel Gorman,
Johannes Weiner, Al Viro, linux-mm, LKML, Martin Schwidefsky,
Heiko Carstens, Herbert Xu, Anton Vorontsov, Colin Cross,
Kees Cook, Tony Luck, Rafael J. Wysocki, Ben Skeggs,
Kent Overstreet, Santosh Raspatur, Hariprasad S, Ta
In-Reply-To: <20170114105632.GV20392@mtr-leonro.local>
On Sat 14-01-17 12:56:32, Leon Romanovsky wrote:
[...]
> Hi Michal,
>
> I don't see mlx5_vzalloc in the changed list. Any reason why did you skip it?
>
> 881 static inline void *mlx5_vzalloc(unsigned long size)
> 882 {
> 883 void *rtn;
> 884
> 885 rtn = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
> 886 if (!rtn)
> 887 rtn = vzalloc(size);
> 888 return rtn;
> 889 }
No reason to skip it, I just didn't see it. I will fold the following in
if you are OK with it
---
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index cdd2bd62f86d..5e6063170e48 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -874,12 +874,7 @@ static inline u16 cmdif_rev(struct mlx5_core_dev *dev)
static inline void *mlx5_vzalloc(unsigned long size)
{
- void *rtn;
-
- rtn = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
- if (!rtn)
- rtn = vzalloc(size);
- return rtn;
+ return kvzalloc(GFP_KERNEL, size);
}
static inline u32 mlx5_base_mkey(const u32 key)
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* Re: [PATCH v2 net-next] IPsec: do not ignore crypto err in ah input
From: Steffen Klassert @ 2017-01-16 7:35 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: herbert, davem, netdev, ofir.drang, gilad.benyossef,
Alexander Alemayhu
In-Reply-To: <1484460583-2303-1-git-send-email-gilad@benyossef.com>
On Sun, Jan 15, 2017 at 08:09:43AM +0200, Gilad Ben-Yossef wrote:
> ah input processing uses the asynchronous hash crypto API which supplies
> an error code as part of the operation completion but the error code was
> being ignored.
>
> Treat a crypto API error indication as a verification failure.
>
> While a crypto API reported error would almost certainly result in a
> memcmp of the digest failing anyway and thus the security risk seems
> minor, performing a memory compare on what might be uninitialized memory
> is wrong.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> CC: Alexander Alemayhu <alexander@alemayhu.com>
> ---
>
> The change was boot tested on Arm64 but I did not exercise
> the specific error code path in question.
>
> Changes from v1:
> - Fixed typo in patch description pointed out by Alexander
>
> net/ipv4/ah4.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
> index f2a7102..22377c8 100644
> --- a/net/ipv4/ah4.c
> +++ b/net/ipv4/ah4.c
> @@ -270,6 +270,9 @@ static void ah_input_done(struct crypto_async_request *base, int err)
> int ihl = ip_hdrlen(skb);
> int ah_hlen = (ah->hdrlen + 2) << 2;
>
> + if (err)
> + goto out;
> +
IPv6 has the same problem, can we get it fixed there too?
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] net/sched: cls_flower: Add user specified data
From: Paul Blakey @ 2017-01-16 7:54 UTC (permalink / raw)
To: John Fastabend, Jiri Pirko, Jamal Hadi Salim
Cc: paulb, David S. Miller, netdev, Jiri Pirko, Hadar Hen Zion,
Or Gerlitz, Roi Dayan, Roman Mashak
In-Reply-To: <587BC894.3080909@gmail.com>
On 15/01/2017 21:08, John Fastabend wrote:
> On 17-01-15 09:36 AM, Paul Blakey wrote:
>>
>>
>> On 08/01/2017 19:12, Jiri Pirko wrote:
>>> Mon, Jan 02, 2017 at 03:59:49PM CET, jhs@mojatatu.com wrote:
>>>>
>>>> We have been using a cookie as well for actions (which we have been
>>>> using but have been too lazy to submit so far). I am going to port
>>>> it over to the newer kernels and post it.
>>>
>>> Hard to deal with something we can't look at :)
>>>
>>>
>>>> In our case that is intended to be opaque to the kernel i.e kernel
>>>> never inteprets it; in that case it is similar to the kernel
>>>> FIB protocol field.
>>>
>>> In case of this patch, kernel also never interprets it. What makes you
>>> think otherwise. Bot kernel, it is always a binary blob.
>>>
>>>
>>>>
>>>> In your case - could this cookie have been a class/flowid
>>>> (a 32 bit)?
>>>> And would it not make more sense for it the cookie to be
>>>> generic to all classifiers? i.e why is it specific to flower?
>>>
>>> Correct, makes sense to have it generic for all cls and perhaps also
>>> acts.
>>>
>>>
>>
>> Hi all,
>> I've started implementing a general cookie for all classifiers,
>> I added the cookie on tcf_proto struct but then I realized that it won't work as
>> I want. What I want is cookie per internal element (those that are identified by
>> handles), which we can have many per one tcf_proto:
>>
>> tc filter add dev <DEV> parent ffff: prio 1 cookie 0x123 basic action drop
>> tc filter add dev <DEV> parent ffff: prio 1 cookie 0x456 "port6" basic action drop
>> tc filter add dev <DEV> parent ffff: prio 1 cookie 0x777 basic action drop
>>
>> So there is three options to do that:
>> 1) Implement it in each classifier, using some generic function. (kinda like
>> stats, where classifiler_dump() calls tcf_exts_dump_stats())
>> 2) Have a global hash table for cookies [prio,handle]->[cookie]
>> 3) Have it on flower only for now :)
>>
>> With the first one we will have to change each classifier (or leave it
>> unsupported as default).
>> Second is less code to change (instead of changing each classifier), but might
>> be slower. I'm afraid how it will affect dumping several filters.
>> Third is this patch.
>>
>> Thanks,
>> Paul.
>
> Avoid (2) it creates way more problems than its worth like is it locked/not
> locked, how is it synced, collisions, etc. Seems way overkill.
>
> I like the generic functionality of (1) but unless we see this pop up in
> different filters I wouldn't require it for now. If you just do it in flower
> (option 3) when its added to another classifier we can generalize it. As a
> middle ground creating nice helper routines as needed goes a long way.
>
> .John
>
Hi all,
So is everyone ok with leaving the commit as is, only adding user data
to flower for now?
Thanks,
Paul.
^ permalink raw reply
* pull request: bluetooth 2017-01-16
From: Johan Hedberg @ 2017-01-16 7:58 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
Hi Dave,
Here are a couple of important 802.15.4 driver fixes for the 4.10
kernel.
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit 8a430ed50bb1b19ca14a46661f3b1b35f2fb5c39:
net: ipv4: fix table id in getroute response (2017-01-12 15:18:20 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to 8e38b7d4d71479b23b77f01cf0e5071610b8f357:
ieee802154: atusb: fix driver to work with older firmware versions (2017-01-12 22:12:43 +0100)
----------------------------------------------------------------
Andrey Smirnov (1):
at86rf230: Allow slow GPIO pins for "rstn"
Stefan Schmidt (4):
ieee802154: atusb: do not use the stack for buffers to make them DMA able
ieee802154: atusb: make sure we set a randaom extended address if fetching fails
ieee802154: atusb: do not use the stack for address fetching to make it DMA able
ieee802154: atusb: fix driver to work with older firmware versions
drivers/net/ieee802154/at86rf230.c | 4 +--
drivers/net/ieee802154/atusb.c | 59 +++++++++++++++++++++++---------
2 files changed, 45 insertions(+), 18 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH for bnxt_re V3 03/21] bnxt_re: register with the NIC driver
From: Selvin Xavier @ 2017-01-16 8:08 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, linux-rdma, Linux Netdev List, Michael Chan,
Eddie Wai, Devesh Sharma, Somnath Kotur, Sriharsha Basavapatna
In-Reply-To: <20170115194143.GE20392@mtr-leonro.local>
On Mon, Jan 16, 2017 at 1:11 AM, Leon Romanovsky <leon@kernel.org> wrote:
> Recently, in one of our submission to netdev and rdma, we got
> a reminder that inline functions shouldn't be in *.c. Let for
> the compiler to decide.
>
> IMHO, it should be open-coded without wrappers and honestly I failed to
> understand why do you need so many wrappers for one line standard kernel
> functions.
Agreed. During the initial days of development, we had some debug code also
inside these wrapper functions. Since the debug code was removed before upstream
submission, this function ended up as a wrapper for standard kernel function.
It makes perfect sense to knock off these wrapper functions. I will
queue it for next
clean-up/bug fix patch series.
Thanks
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Tariq Toukan @ 2017-01-16 8:18 UTC (permalink / raw)
To: Michal Hocko, Andrew Morton
Cc: Vlastimil Babka, David Rientjes, Mel Gorman, Johannes Weiner,
Al Viro, linux-mm, LKML, Michal Hocko, Martin Schwidefsky,
Heiko Carstens, Herbert Xu, Anton Vorontsov, Colin Cross,
Kees Cook, Tony Luck, Rafael J. Wysocki, Ben Skeggs,
Kent Overstreet, Santosh Raspatur, Hariprasad S, Yishai
In-Reply-To: <20170112153717.28943-6-mhocko@kernel.org>
On 12/01/2017 5:37 PM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> There are many code paths opencoding kvmalloc. Let's use the helper
> instead. The main difference to kvmalloc is that those users are usually
> not considering all the aspects of the memory allocator. E.g. allocation
> requests < 64kB are basically never failing and invoke OOM killer to
> satisfy the allocation. This sounds too disruptive for something that
> has a reasonable fallback - the vmalloc. On the other hand those
> requests might fallback to vmalloc even when the memory allocator would
> succeed after several more reclaim/compaction attempts previously. There
> is no guarantee something like that happens though.
>
> This patch converts many of those places to kv[mz]alloc* helpers because
> they are more conservative.
>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Anton Vorontsov <anton@enomsg.org>
> Cc: Colin Cross <ccross@android.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Kent Overstreet <kent.overstreet@gmail.com>
> Cc: Santosh Raspatur <santosh@chelsio.com>
> Cc: Hariprasad S <hariprasad@chelsio.com>
> Cc: Tariq Toukan <tariqt@mellanox.com>
> Cc: Yishai Hadas <yishaih@mellanox.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Oleg Drokin <oleg.drokin@intel.com>
> Cc: Andreas Dilger <andreas.dilger@intel.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: David Sterba <dsterba@suse.com>
> Cc: "Yan, Zheng" <zyan@redhat.com>
> Cc: Ilya Dryomov <idryomov@gmail.com>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
Acked-by: Tariq Toukan <tariqt@mellanox.com>
For the mlx4 parts.
Regards.
Tariq
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Leon Romanovsky @ 2017-01-16 8:28 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Vlastimil Babka, David Rientjes, Mel Gorman,
Johannes Weiner, Al Viro, linux-mm, LKML, Martin Schwidefsky,
Heiko Carstens, Herbert Xu, Anton Vorontsov, Colin Cross,
Kees Cook, Tony Luck, Rafael J. Wysocki, Ben Skeggs,
Kent Overstreet, Santosh Raspatur, Hariprasad S, Ta
In-Reply-To: <20170116073310.GA7981@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]
On Mon, Jan 16, 2017 at 08:33:11AM +0100, Michal Hocko wrote:
> On Sat 14-01-17 12:56:32, Leon Romanovsky wrote:
> [...]
> > Hi Michal,
> >
> > I don't see mlx5_vzalloc in the changed list. Any reason why did you skip it?
> >
> > 881 static inline void *mlx5_vzalloc(unsigned long size)
> > 882 {
> > 883 void *rtn;
> > 884
> > 885 rtn = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
> > 886 if (!rtn)
> > 887 rtn = vzalloc(size);
> > 888 return rtn;
> > 889 }
>
> No reason to skip it, I just didn't see it. I will fold the following in
> if you are OK with it
Sure, no problem.
Once, the patch set is accepted, we (Mellanox) will get rid of mlx5_vzalloc().
Thanks
> ---
> diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
> index cdd2bd62f86d..5e6063170e48 100644
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@ -874,12 +874,7 @@ static inline u16 cmdif_rev(struct mlx5_core_dev *dev)
>
> static inline void *mlx5_vzalloc(unsigned long size)
> {
> - void *rtn;
> -
> - rtn = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
> - if (!rtn)
> - rtn = vzalloc(size);
> - return rtn;
> + return kvzalloc(GFP_KERNEL, size);
> }
>
> static inline u32 mlx5_base_mkey(const u32 key)
>
> --
> Michal Hocko
> SUSE Labs
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH for bnxt_re V3 03/21] bnxt_re: register with the NIC driver
From: Leon Romanovsky @ 2017-01-16 8:33 UTC (permalink / raw)
To: Selvin Xavier
Cc: Doug Ledford, linux-rdma, Linux Netdev List, Michael Chan,
Eddie Wai, Devesh Sharma, Somnath Kotur, Sriharsha Basavapatna
In-Reply-To: <CA+sbYW2SMbExwyw20TZtn3U13fkJvKCs5P8w5LdovN4Q3u0sjg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
On Mon, Jan 16, 2017 at 01:38:40PM +0530, Selvin Xavier wrote:
> On Mon, Jan 16, 2017 at 1:11 AM, Leon Romanovsky <leon@kernel.org> wrote:
> > Recently, in one of our submission to netdev and rdma, we got
> > a reminder that inline functions shouldn't be in *.c. Let for
> > the compiler to decide.
> >
> > IMHO, it should be open-coded without wrappers and honestly I failed to
> > understand why do you need so many wrappers for one line standard kernel
> > functions.
>
> Agreed. During the initial days of development, we had some debug code also
> inside these wrapper functions. Since the debug code was removed before upstream
> submission, this function ended up as a wrapper for standard kernel function.
> It makes perfect sense to knock off these wrapper functions. I will
> queue it for next
> clean-up/bug fix patch series.
I'm fine with it as long as it's done.
>
> Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net-next] net/sched: cls_flower: Disallow duplicate internal elements
From: Paul Blakey @ 2017-01-16 8:45 UTC (permalink / raw)
To: netdev, David S. Miller
Cc: Jiri Pirko, Roi Dayan, Or Gerlitz, Hadar Hen Zion, Paul Blakey
Flower currently allows having the same filter twice with the same
priority. Actions (and statistics update) will always execute on the
first inserted rule leaving the second rule unused.
This patch disallows that.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_flower.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index a3bfda3..2793445 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -134,6 +134,14 @@ static void fl_clear_masked_range(struct fl_flow_key *key,
memset(fl_key_get_start(key, mask), 0, fl_mask_range(mask));
}
+static struct cls_fl_filter *fl_lookup(struct cls_fl_head *head,
+ struct fl_flow_key *mkey)
+{
+ return rhashtable_lookup_fast(&head->ht,
+ fl_key_get_start(mkey, &head->mask),
+ head->ht_params);
+}
+
static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
struct tcf_result *res)
{
@@ -181,9 +189,7 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
fl_set_masked_key(&skb_mkey, &skb_key, &head->mask);
- f = rhashtable_lookup_fast(&head->ht,
- fl_key_get_start(&skb_mkey, &head->mask),
- head->ht_params);
+ f = fl_lookup(head, &skb_mkey);
if (f && !tc_skip_sw(f->flags)) {
*res = f->res;
return tcf_exts_exec(skb, &f->exts, res);
@@ -875,6 +881,11 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
goto errout;
if (!tc_skip_sw(fnew->flags)) {
+ if (!fold && fl_lookup(head, &fnew->mkey)) {
+ err = -EEXIST;
+ goto errout;
+ }
+
err = rhashtable_insert_fast(&head->ht, &fnew->ht_node,
head->ht_params);
if (err)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] mlx4: do not call napi_schedule() without care
From: Tariq Toukan @ 2017-01-16 9:02 UTC (permalink / raw)
To: Eric Dumazet, David Miller
Cc: netdev, Erez Shitrit, Eugenia Emantayev, Tariq Toukan
In-Reply-To: <1484325564.13165.30.camel@edumazet-glaptop3.roam.corp.google.com>
Thanks Eric.
On 13/01/2017 6:39 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Disable BH around the call to napi_schedule() to avoid following warning
>
> [ 52.095499] NOHZ: local_softirq_pending 08
> [ 52.421291] NOHZ: local_softirq_pending 08
> [ 52.608313] NOHZ: local_softirq_pending 08
>
> Fixes: 8d59de8f7bb3 ("net/mlx4_en: Process all completions in RX rings after port goes up")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Erez Shitrit <erezsh@mellanox.com>
> Cc: Eugenia Emantayev <eugenia@mellanox.com>
> Cc: Tariq Toukan <tariqt@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 4910d9af19335d4b97d39760c163b41eecc26242..761f8b12399cab245abccc0f7d7f84fde742c14d 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -1748,8 +1748,11 @@ int mlx4_en_start_port(struct net_device *dev)
> /* Process all completions if exist to prevent
> * the queues freezing if they are full
> */
> - for (i = 0; i < priv->rx_ring_num; i++)
> + for (i = 0; i < priv->rx_ring_num; i++) {
> + local_bh_disable();
> napi_schedule(&priv->rx_cq[i]->napi);
> + local_bh_enable();
> + }
>
> netif_tx_start_all_queues(dev);
> netif_device_attach(dev);
>
>
Acked-by: Tariq Toukan <tariqt@mellanox.com>
^ permalink raw reply
* Re: [PATCH 0/6] USB support for Broadcom NSP SoC
From: Kishon Vijay Abraham I @ 2017-01-16 9:17 UTC (permalink / raw)
To: Florian Fainelli, Yendapally Reddy Dhananjaya Reddy, Rob Herring,
Mark Rutland, Russell King, Ray Jui, Scott Branden, Jon Mason
Cc: netdev, bcm-kernel-feedback-list, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <79483fc3-5e91-a1f0-1dbf-1987682373e6@gmail.com>
On Tuesday 13 December 2016 07:50 AM, Florian Fainelli wrote:
> On 11/09/2016 01:33 AM, Yendapally Reddy Dhananjaya Reddy wrote:
>> This patch set contains the usb support for Broadcom NSP SoC.
>> The usb phy is connected through mdio interface. The mdio interface
>> can be used to access either internal phys or external phys using a
>> multiplexer.
>>
>> The first patch provides the documentation details for mdio-mux and
>> second patch provides the documentation details for usb3 phy. The third
>> patch contains the mdio-mux support and fourth patch contains the
>> changes to the mdio bus driver.
>>
>> The fifth patch provides the phy driver and sixth patch provides the
>> enable method for usb.
>>
>> This patch series has been tested on NSP bcm958625HR board.
>> This patch series is based on v4.9.0-rc1 and is available from github-
>> repo: https://github.com/Broadcom/cygnus-linux.git
>> branch:nsp-usb-v1
>
> Can you resubmit this patch series with the feedback from Andrew, Rob
> and Scott addressed?
can the phy patches be re-submitted based on latest mainline and addressing
those feedbacks?
Thanks
Kishon
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: Dan Carpenter @ 2017-01-16 9:19 UTC (permalink / raw)
To: David Miller
Cc: peppe.cavallaro, Joao.Pinto, alexandre.torgue, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <20170115.221438.1956356112755181222.davem@davemloft.net>
On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> From: Dan Carpenter <dan.carpenter@oracle.com>
> Date: Thu, 12 Jan 2017 21:46:32 +0300
>
> > The break statement should be indented one more tab.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Applied, but like Julia I think we might have a missing of_node_put()
> here.
Of course, sorry for dropping the ball on this. I'll send a patch for
that.
regards,
dan carpenter
^ 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