* Re: Linux 4.14 - regression: broken tun/tap / bridge network with virtio - bisected
From: Andreas Hartmann @ 2017-12-08 13:13 UTC (permalink / raw)
To: Michal Kubecek; +Cc: Jason Wang, David Miller, netdev
In-Reply-To: <20171208125835.xnjzidixymdqovmy@unicorn.suse.cz>
On 12/08/2017 at 01:58 PM Michal Kubecek wrote:
> On Fri, Dec 08, 2017 at 01:45:38PM +0100, Andreas Hartmann wrote:
>> On 12/08/2017 at 12:40 PM Michal Kubecek wrote:
>>> On Fri, Dec 08, 2017 at 11:31:50AM +0100, Andreas Hartmann wrote:
>>>>
>>>> When will there be a fix for 4.14? It is clearly a regression. Is
>>>> it possible / a good idea to just remove the complete patch series
>>>> "Remove UDP Fragmentation Offload support"?
>>>
>>> I cannot give an exact date but the patch is queued for stable (see
>>> http://patchwork.ozlabs.org/bundle/davem/stable/?state=* ) so that
>>> it should land in stable-4.14 in near future (weeks at most).
>>
>> Which one is it? I couldn't find any patch related to this problem at
>> first glance.
>
> "[net,v2] net: accept UFO datagrams from tuntap and packet" - the
> subject was mentioned in one of my earlier e-mails (with commit id).
Oh - I thought this would only work during live migration (which doesn't
happen here). My error.
Thanks,
regards,
Andreas
^ permalink raw reply
* Re: [PATCH v3 04/33] nds32: Kernel booting and initialization
From: Philippe Ombredanne @ 2017-12-08 13:19 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, LKML, Arnd Bergmann, linux-arch, Thomas Gleixner,
jason, marc.zyngier, Rob Herring, netdev, deanbo422,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, viro,
dhowells, Will Deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, Mark Rutland, greg,
Vincent Chen
In-Reply-To: <7131f15434d17eb64a83999bff9e96a7e9d4b5f5.1512723245.git.green.hu@gmail.com>
Dear Greentime,
On Fri, Dec 8, 2017 at 10:11 AM, Greentime Hu <green.hu@gmail.com> wrote:
> From: Greentime Hu <greentime@andestech.com>
>
> This patch includes the kernel startup code. It can get dtb pointer
> passed from bootloader. It will create a temp mapping by tlb
> instructions at beginning and goto start_kernel.
>
> Signed-off-by: Vincent Chen <vincentc@andestech.com>
> Signed-off-by: Greentime Hu <greentime@andestech.com>
[]
> --- /dev/null
> +++ b/arch/nds32/kernel/head.S
> @@ -0,0 +1,202 @@
> +/*
> + * Copyright (C) 2005-2017 Andes Technology Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
Have you considered using the new SPDX ids instead of this fine legalese?
e.g.:
// SPDX-License-Identifier: GPL-2.0
// Copyright (C) 2005-2017 Andes Technology Corporation
This is much shorter and neater (unless you are a legalese lover of course!)
Check also Thomas doc patches and Linus comments on why he prefers the
C++ comment style for these.
--
Cordially
Philippe Ombredanne, your friendly licensing scruffy bot
^ permalink raw reply
* Re: [PATCH v5 2/2] sock: Move the socket inuse to namespace.
From: Eric Dumazet @ 2017-12-08 13:24 UTC (permalink / raw)
To: Tonghao Zhang
Cc: David Miller, Cong Wang, Eric Dumazet, Willem de Bruijn,
Linux Kernel Network Developers
In-Reply-To: <CAMDZJNX-JTGhQNTJSByLC2LCW=uY9C8MfmRr2eYoxbPQGGg6Sw@mail.gmail.com>
On Fri, 2017-12-08 at 19:29 +0800, Tonghao Zhang wrote:
> hi all. we can add synchronize_rcu and rcu_barrier in
> sock_inuse_exit_net to
> ensure there are no outstanding rcu callbacks using this network
> namespace.
> we will not have to test if net->core.sock_inuse is NULL or not from
> sock_inuse_add(). :)
>
> static void __net_exit sock_inuse_exit_net(struct net *net)
> {
> free_percpu(net->core.prot_inuse);
> +
> + synchronize_rcu();
> + rcu_barrier();
> +
> + free_percpu(net->core.sock_inuse);
> }
Oh well. Do you have any idea of the major problem this would add ?
Try the following, before and after your patches :
for i in `seq 1 40`
do
(for j in `seq 1 100` ; do unshare -n /bin/true >/dev/null ; done) &
done
wait
( Check commit 8ca712c373a462cfa1b62272870b6c2c74aa83f9 )
This is a complex problem, we wont accept patches that kill network
namespaces dismantling performance by adding brute force
synchronize_rcu() or rcu_barrier() calls.
Why not freeing net->core.sock_inuse right before feeing net itself in
net_free() ?
You do not have to hijack sock_inuse_exit_net() just because it has a
misleading name.
^ permalink raw reply
* Re: [PATCH v3 04/33] nds32: Kernel booting and initialization
From: Greentime Hu @ 2017-12-08 13:25 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Greentime, LKML, Arnd Bergmann, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, netdev, Vincent Chen,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Al Viro, David Howells, Will Deacon, Daniel Lezcano, linux-serial,
Geert Uytterhoeven, Linus Walleij, Mark Rutland <mark.rutlan
In-Reply-To: <CAOFm3uF5BpxpAAH4eq-OSY1bS2cSGS27NY524JoAMzJ1F4bbrA@mail.gmail.com>
Hi, Philippe:
2017-12-08 21:19 GMT+08:00 Philippe Ombredanne <pombredanne@nexb.com>:
> Dear Greentime,
>
> On Fri, Dec 8, 2017 at 10:11 AM, Greentime Hu <green.hu@gmail.com> wrote:
>> From: Greentime Hu <greentime@andestech.com>
>>
>> This patch includes the kernel startup code. It can get dtb pointer
>> passed from bootloader. It will create a temp mapping by tlb
>> instructions at beginning and goto start_kernel.
>>
>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>> Signed-off-by: Greentime Hu <greentime@andestech.com>
> []
>> --- /dev/null
>> +++ b/arch/nds32/kernel/head.S
>> @@ -0,0 +1,202 @@
>> +/*
>> + * Copyright (C) 2005-2017 Andes Technology Corporation
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>
>
> Have you considered using the new SPDX ids instead of this fine legalese?
> e.g.:
>
> // SPDX-License-Identifier: GPL-2.0
> // Copyright (C) 2005-2017 Andes Technology Corporation
>
> This is much shorter and neater (unless you are a legalese lover of course!)
>
> Check also Thomas doc patches and Linus comments on why he prefers the
> C++ comment style for these.
Thanks for your suggestions. We'd like to do this change.
I will apply it in the next version patch.
^ permalink raw reply
* Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?
From: Eric Dumazet @ 2017-12-08 13:42 UTC (permalink / raw)
To: Matt Turner
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, Paolo Abeni,
Hannes Frederic Sowa, Peter Zijlstra (Intel), Thomas Gleixner,
Ingo Molnar, Manuel Lauss, LKML, netdev
In-Reply-To: <CAEdQ38HcPswBk3pUHzQerFZ=4KjPc5nVYTqNnGQNMk7QbPXuOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner <mattst88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner <mattst88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner <mattst88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
>>> corruption on the first file read.
>>>
>>> To demonstrate, I downloaded five identical copies of the gcc-5.4.0
>>> source tarball. On the NFS server, they hash to the same value:
>>>
>>> server distfiles # md5sum gcc-5.4.0.tar.bz2*
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.1
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.2
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.3
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.4
>>>
>>> On the MIPS system (the NFS client):
>>>
>>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
>>> 35346975989954df8a8db2b034da610d gcc-5.4.0.tar.bz2.2
>>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.1
>>> 35346975989954df8a8db2b034da610d gcc-5.4.0.tar.bz2.2
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.3
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.4
>>>
>>> The first file read will contain some corruption, and it is persistent until...
>>>
>>> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
>>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.1
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.2
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.3
>>> 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.4
>>>
>>> the caches are dropped, at which point it reads back properly.
>>>
>>> Note that the corruption is different across reboots, both in the size
>>> of the corruption and the location. I saw 1900~ and 1400~ byte
>>> sequences corrupted on separate occasions, which don't correspond to
>>> the system's 16kB page size.
>>>
>>> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
>>> today). All exhibit this behavior with differing frequencies. Earlier
>>> kernels seem to reproduce the issue less often, while more recent
>>> kernels reliably exhibit the problem every boot.
>>>
>>> How can I further debug this?
>>
>> I think I was wrong about the statement about kernels v3.19 to
>> 4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
>> bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq: Let
>> ksoftirqd do its job"). Still reproduces with current tip of Linus'
>> tree.
>>
>> Any ideas? The board's ethernet is an uncommon device supported by
>> CONFIG_SB1250_MAC. Something about the ethernet driver maybe?
>
> With the patch reverted on master (reverts cleanly), NFS corruption no
> longer happens.
Hi Matt.
Thanks for bisecting.
Patch simply exposes an existing bug more often by changing the way
driver functions are scheduled.
Which is probably a good thing.
sbmac_intr() looks extremely suspicious to me.
A NAPI driver hard interrupt should simply schedule NAPI.
Apparently, if sbmac_intr() can not grab NAPIF_STATE_SCHED bit, it
directly calls sbdma_rx_process() from
hard interrupt context.
Insane really.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v4 1/2] net: add support for Cavium PTP coprocessor
From: Philippe Ombredanne @ 2017-12-08 13:43 UTC (permalink / raw)
To: Aleksey Makarov
Cc: netdev, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
LKML, Goutham, Sunil, Radoslaw Biernacki, Robert Richter,
David Daney, Richard Cochran
In-Reply-To: <20171208103442.19354-2-aleksey.makarov@cavium.com>
Dear Aleksey, Dear Radoslaw,
On Fri, Dec 8, 2017 at 11:34 AM, Aleksey Makarov
<aleksey.makarov@cavium.com> wrote:
> From: Radoslaw Biernacki <rad@semihalf.com>
>
> This patch adds support for the Precision Time Protocol
> Clocks and Timestamping hardware found on Cavium ThunderX
> processors.
>
> Signed-off-by: Radoslaw Biernacki <rad@semihalf.com>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@cavium.com>
[]
> --- /dev/null
> +++ b/drivers/net/ethernet/cavium/common/cavium_ptp.c
> @@ -0,0 +1,334 @@
> +/*
> + * cavium_ptp.c - PTP 1588 clock on Cavium hardware
> + *
> + * Copyright (c) 2003-2015, 2017 Cavium, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
Have you considered using the new SPDX ids instead of this fine legalese? e.g.:
// SPDX-License-Identifier: GPL-2.0
This is much shorter and neater (unless you are a legalese lover of
course!)... Check also Thomas doc patches and Linus comments on why he
prefers the C++ comment style for these.
And even better, what about this more compact form? I am a big fan of the
C++ style comments for these (and so is Linus):
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2003-2015, 2017 Cavium, Inc.
// cavium_ptp.c - PTP 1588 clock on Cavium hardware
> + *
> + * This file may also be available under a different license from Cavium.
> + * Contact Cavium, Inc. for more information
> + */
I am not so sure that the kernel source tree is the right place for
commercial advertisement... I mean, this is a fine statement to put on
your company web site, but who reads this code: you and I.... do we
care seriously about this? Anyone who uses your hardware would likely
have some other kind of arrangements with your company anyway, making
this sentence moot in all cases. Therefore I tend to think this is
just a noisy distraction from your otherwise fine code contributions:
It does not come out to me as kernically-correct ;)
So can you consider removing this fine marketing statement from this
and other Cavium past, present and future contributions? That would be
much appreciated! (and while you are at it, using SPDX ids throughout
would give you good karma extra points)
PS: Now, if this "different license" of yours is a fine BSD or MIT,
you could use instead this SPDX shorthand to the same effect without
turning the kernel code into a billboard:
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
--
Cordially
Philippe Ombredanne, your ad-sensitive licensing scruffy
^ permalink raw reply
* Re: [PATCH v3 23/33] nds32: Generic timers support
From: Linus Walleij @ 2017-12-08 13:43 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel@vger.kernel.org, Arnd Bergmann,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, netdev, deanbo422,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Al Viro, David Howells, Will Deacon, Daniel Lezcano, linux-serial,
Geert Uytterhoeven, Mark Rutland, Greg KH, Vincent Chen
In-Reply-To: <9f074c94b56617d99f9c6741176bb2ee9dfc4331.1512723245.git.green.hu@gmail.com>
On Fri, Dec 8, 2017 at 10:12 AM, Greentime Hu <green.hu@gmail.com> wrote:
> From: Greentime Hu <greentime@andestech.com>
>
> This patch adds support for timer.
>
> Signed-off-by: Vincent Chen <vincentc@andestech.com>
> Signed-off-by: Greentime Hu <greentime@andestech.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?
From: Eric Dumazet @ 2017-12-08 13:52 UTC (permalink / raw)
To: Eric Dumazet, Matt Turner
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, Paolo Abeni,
Hannes Frederic Sowa, Peter Zijlstra (Intel), Thomas Gleixner,
Ingo Molnar, Manuel Lauss, LKML, netdev
In-Reply-To: <CANn89iJKGRLVNAE99JWiyXcOXveytkjbQAiZ9XPiJc6fyEdFVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote:
> On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner <mattst88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
> > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner <mattst88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > wrote:
> > > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner <mattst88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > wrote:
> > > > On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
> > > > corruption on the first file read.
> > > >
> > > > To demonstrate, I downloaded five identical copies of the gcc-
> > > > 5.4.0
> > > > source tarball. On the NFS server, they hash to the same value:
> > > >
> > > > server distfiles # md5sum gcc-5.4.0.tar.bz2*
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.1
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.2
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.3
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.4
> > > >
> > > > On the MIPS system (the NFS client):
> > > >
> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
> > > > 35346975989954df8a8db2b034da610d gcc-5.4.0.tar.bz2.2
> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.1
> > > > 35346975989954df8a8db2b034da610d gcc-5.4.0.tar.bz2.2
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.3
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.4
> > > >
> > > > The first file read will contain some corruption, and it is
> > > > persistent until...
> > > >
> > > > bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.1
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.2
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.3
> > > > 4c626ac2a83ef30dfb9260e6f59c2b30 gcc-5.4.0.tar.bz2.4
> > > >
> > > > the caches are dropped, at which point it reads back properly.
> > > >
> > > > Note that the corruption is different across reboots, both in
> > > > the size
> > > > of the corruption and the location. I saw 1900~ and 1400~ byte
> > > > sequences corrupted on separate occasions, which don't
> > > > correspond to
> > > > the system's 16kB page size.
> > > >
> > > > I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
> > > > today). All exhibit this behavior with differing frequencies.
> > > > Earlier
> > > > kernels seem to reproduce the issue less often, while more
> > > > recent
> > > > kernels reliably exhibit the problem every boot.
> > > >
> > > > How can I further debug this?
> > >
> > > I think I was wrong about the statement about kernels v3.19 to
> > > 4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
> > > bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq:
> > > Let
> > > ksoftirqd do its job"). Still reproduces with current tip of
> > > Linus'
> > > tree.
> > >
> > > Any ideas? The board's ethernet is an uncommon device supported
> > > by
> > > CONFIG_SB1250_MAC. Something about the ethernet driver maybe?
> >
> > With the patch reverted on master (reverts cleanly), NFS corruption
> > no
> > longer happens.
>
> Hi Matt.
>
> Thanks for bisecting.
>
> Patch simply exposes an existing bug more often by changing the way
> driver functions are scheduled.
>
> Which is probably a good thing.
>
> sbmac_intr() looks extremely suspicious to me.
>
> A NAPI driver hard interrupt should simply schedule NAPI.
>
> Apparently, if sbmac_intr() can not grab NAPIF_STATE_SCHED bit, it
> directly calls sbdma_rx_process() from
> hard interrupt context.
>
> Insane really.
Please try this fix (not compiled on my x86 laptop, and I had no coffee
yet, so it might have some trivial errors)
diff --git a/drivers/net/ethernet/broadcom/sb1250-mac.c b/drivers/net/ethernet/broadcom/sb1250-mac.c
index ecdef42f0ae63641419a603f0b4eec2fc213c334..3ddd9ca469b280e70509b22fd7d3f449c81fbedc 100644
--- a/drivers/net/ethernet/broadcom/sb1250-mac.c
+++ b/drivers/net/ethernet/broadcom/sb1250-mac.c
@@ -287,8 +287,6 @@ static int sbdma_add_rcvbuffer(struct sbmac_softc *sc, struct sbmacdma *d,
static int sbdma_add_txbuffer(struct sbmacdma *d, struct sk_buff *m);
static void sbdma_emptyring(struct sbmacdma *d);
static void sbdma_fillring(struct sbmac_softc *sc, struct sbmacdma *d);
-static int sbdma_rx_process(struct sbmac_softc *sc, struct sbmacdma *d,
- int work_to_do, int poll);
static void sbdma_tx_process(struct sbmac_softc *sc, struct sbmacdma *d,
int poll);
static int sbmac_initctx(struct sbmac_softc *s);
@@ -1063,7 +1061,7 @@ static void sbmac_netpoll(struct net_device *netdev)
********************************************************************* */
static int sbdma_rx_process(struct sbmac_softc *sc, struct sbmacdma *d,
- int work_to_do, int poll)
+ int work_to_do)
{
struct net_device *dev = sc->sbm_dev;
int curidx;
@@ -1076,7 +1074,6 @@ static int sbdma_rx_process(struct sbmac_softc *sc, struct sbmacdma *d,
prefetch(d);
-again:
/* Check if the HW dropped any frames */
dev->stats.rx_fifo_errors
+= __raw_readq(sc->sbm_rxdma.sbdma_oodpktlost) & 0xffff;
@@ -1169,10 +1166,7 @@ static int sbdma_rx_process(struct sbmac_softc *sc, struct sbmacdma *d,
}
prefetch(sb->data);
prefetch((const void *)(((char *)sb->data)+32));
- if (poll)
- dropped = netif_receive_skb(sb);
- else
- dropped = netif_rx(sb);
+ dropped = netif_receive_skb(sb);
if (dropped == NET_RX_DROP) {
dev->stats.rx_dropped++;
@@ -1201,10 +1195,6 @@ static int sbdma_rx_process(struct sbmac_softc *sc, struct sbmacdma *d,
d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr);
work_done++;
}
- if (!poll) {
- work_to_do = 32;
- goto again; /* collect fifo drop statistics again */
- }
done:
return work_done;
}
@@ -2006,11 +1996,6 @@ static irqreturn_t sbmac_intr(int irq,void *dev_instance)
__napi_schedule(&sc->napi);
/* Depend on the exit from poll to reenable intr */
}
- else {
- /* may leave some packets behind */
- sbdma_rx_process(sc,&(sc->sbm_rxdma),
- SBMAC_MAX_RXDESCR * 2, 0);
- }
}
return IRQ_RETVAL(handled);
}
@@ -2529,7 +2514,7 @@ static int sbmac_poll(struct napi_struct *napi, int budget)
struct sbmac_softc *sc = container_of(napi, struct sbmac_softc, napi);
int work_done;
- work_done = sbdma_rx_process(sc, &(sc->sbm_rxdma), budget, 1);
+ work_done = sbdma_rx_process(sc, &(sc->sbm_rxdma), budget);
sbdma_tx_process(sc, &(sc->sbm_txdma), 1);
if (work_done < budget) {
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 related
* Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
From: Philippe Ombredanne @ 2017-12-08 13:56 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev, Quentin Monnet, LKML, kernel-team, ast, daniel,
jakub.kicinski, kafai, David Ahern
In-Reply-To: <d3cc2f85-f3ee-7771-c5b2-13ca6e80a910@netronome.com>
On Fri, Dec 8, 2017 at 11:34 AM, Quentin Monnet
<quentin.monnet@netronome.com> wrote:
> 2017-12-07 18:39 UTC+0000 ~ Roman Gushchin <guro@fb.com>
>> This patch adds basic cgroup bpf operations to bpftool:
>> cgroup list, attach and detach commands.
[...]
>> --- /dev/null
>> +++ b/tools/bpf/bpftool/cgroup.c
>> @@ -0,0 +1,305 @@
>> +/*
>> + * Copyright (C) 2017 Facebook
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + *
>> + *
>> + */
>> +
Roman,
Have you considered using the simpler and new SPDX ids instead? e.g.:
// SPDX-License-Identifier: GPL-2.0+
// Copyright (C) 2017 Facebook
// Author: Roman Gushchin <guro@fb.com>
This would boost your code/comments ratio nicely IMHO.
For reference please check Linus [1][2][3], Thomas [4] and Greg [5]
comments on the topic of C++ style // comments!
Jonathan also wrote a nice background article on the SPDXification
topic at LWN [6]
PS: and if you could spread the word at FB, that would we awesome!
[1] https://lkml.org/lkml/2017/11/2/715
[2] https://lkml.org/lkml/2017/11/25/125
[3] https://lkml.org/lkml/2017/11/25/133
[4] https://lkml.org/lkml/2017/11/2/805
[5] https://lkml.org/lkml/2017/10/19/165
[6] https://lwn.net/Articles/739183/
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave
From: David Laight @ 2017-12-08 14:06 UTC (permalink / raw)
To: 'Xin Long', network dev, linux-sctp@vger.kernel.org
Cc: Marcelo Ricardo Leitner, Neil Horman, davem@davemloft.net
In-Reply-To: <ed729ca6023dea0812e4caa4d5da3259df375127.1512738021.git.lucien.xin@gmail.com>
From: Xin Long
> Sent: 08 December 2017 13:04
...
> @@ -264,8 +264,8 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
> frag |= SCTP_DATA_SACK_IMM;
> }
>
> - chunk = sctp_make_datafrag_empty(asoc, sinfo, len, frag,
> - 0, GFP_KERNEL);
> + chunk = asoc->stream.si->make_datafrag(asoc, sinfo, len, frag,
> + GFP_KERNEL);
I know that none of the sctp code is very optimised, but that indirect
call is going to be horrid.
David
^ permalink raw reply
* [PATCH] dt-bindings: fec: Make the phy-reset-gpio polarity explicit
From: Fabio Estevam @ 2017-12-08 14:11 UTC (permalink / raw)
To: davem; +Cc: fugang.duan, robh+dt, netdev, Fabio Estevam
From: Fabio Estevam <fabio.estevam@nxp.com>
The GPIO polarity passed to phy-reset-gpio is ignored by the FEC
driver and it is assumed to be active low.
It can be active high only when the 'phy-reset-active-high' property
is present.
The current examples pass active high polarity and work fine, but
in order to improve the documentation make it explicit what the real
polarity is.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Documentation/devicetree/bindings/net/fsl-fec.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
index f0dc944..2d41fb9 100644
--- a/Documentation/devicetree/bindings/net/fsl-fec.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -59,7 +59,7 @@ ethernet@83fec000 {
reg = <0x83fec000 0x4000>;
interrupts = <87>;
phy-mode = "mii";
- phy-reset-gpios = <&gpio2 14 0>; /* GPIO2_14 */
+ phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */
local-mac-address = [00 04 9F 01 1B B9];
phy-supply = <®_fec_supply>;
};
@@ -71,7 +71,7 @@ ethernet@83fec000 {
reg = <0x83fec000 0x4000>;
interrupts = <87>;
phy-mode = "mii";
- phy-reset-gpios = <&gpio2 14 0>; /* GPIO2_14 */
+ phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */
local-mac-address = [00 04 9F 01 1B B9];
phy-supply = <®_fec_supply>;
phy-handle = <ðphy>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
From: Roman Gushchin @ 2017-12-08 14:12 UTC (permalink / raw)
To: Quentin Monnet
Cc: netdev, linux-kernel, kernel-team, ast, daniel, jakub.kicinski,
kafai, David Ahern
In-Reply-To: <d3cc2f85-f3ee-7771-c5b2-13ca6e80a910@netronome.com>
On Fri, Dec 08, 2017 at 10:34:16AM +0000, Quentin Monnet wrote:
> 2017-12-07 18:39 UTC+0000 ~ Roman Gushchin <guro@fb.com>
> > This patch adds basic cgroup bpf operations to bpftool:
> > cgroup list, attach and detach commands.
> >
> > Usage is described in the corresponding man pages,
> > and examples are provided.
[...]
> > +MAP COMMANDS
> > +=============
> > +
> > +| **bpftool** **cgroup list** *CGROUP*
> > +| **bpftool** **cgroup attach** *CGROUP* *ATTACH_TYPE* *PROG* [*ATTACH_FLAGS*]
> > +| **bpftool** **cgroup detach** *CGROUP* *ATTACH_TYPE* *PROG*
> > +| **bpftool** **cgroup help**
> > +|
> > +| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
>
> Could you please give the different possible values for ATTACH_TYPE and
> ATTACH_FLAGS, and provide some documentation for the flags?
I intentionally didn't include the list of possible values, as it depends
on the exact kernel version, and other bpftool docs are carefully avoiding
specifying such things.
It would be nice to have a way to ask the kernel about provided bpf program types,
attach types, etc; but I'm not sure that hardcoding it in bpftool docs is
a good idea.
>
> > +
> > +DESCRIPTION
> > +===========
> > + **bpftool cgroup list** *CGROUP*
> > + List all programs attached to the cgroup *CGROUP*.
> > +
> > + Output will start with program ID followed by attach type,
> > + attach flags and program name.
> > +
> > + **bpftool cgroup attach** *CGROUP* *ATTACH_TYPE* *PROG* [*ATTACH_FLAGS*]
> > + Attach program *PROG* to the cgroup *CGROUP* with attach type
> > + *ATTACH_TYPE* and optional *ATTACH_FLAGS*.
[...]
> > +
> > + attach_type = parse_attach_type(argv[1]);
> > + if (attach_type == __MAX_BPF_ATTACH_TYPE) {
> > + p_err("invalid attach type");
> > + goto exit_cgroup;
> > + }
> > +
> > + argc -= 2;
> > + argv = &argv[2];
> > + prog_fd = prog_parse_fd(&argc, &argv);
> > + if (prog_fd < 0)
> > + goto exit_cgroup;
> > +
> > + if (bpf_prog_detach2(prog_fd, cgroup_fd, attach_type)) {
> > + p_err("failed to attach program");
>
> Failed to *detach* instead of “attach”.
Fixed.
>
> > + goto exit_prog;
> > + }
> > +
> > + if (json_output)
> > + jsonw_null(json_wtr);
> > +
> > + ret = 0;
> > +
> > +exit_prog:
> > + close(prog_fd);
> > +exit_cgroup:
> > + close(cgroup_fd);
> > +exit:
> > + return ret;
> > +}
>
> […]
>
> Very nice work on this v2, thanks a lot!
> Quentin
Thank you for reviewing!
^ permalink raw reply
* [PATCH] Bluetooth: Prevent stack info leak from the EFS element.
From: Greg Kroah-Hartman @ 2017-12-08 14:14 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo Padovan, Johan Hedberg
Cc: Ben Seri, netdev, linux-kernel
From: Ben Seri <ben@armis.com>
In the function l2cap_parse_conf_rsp and in the function
l2cap_parse_conf_req the following variable is declared without
initialization:
struct l2cap_conf_efs efs;
In addition, when parsing input configuration parameters in both of
these functions, the switch case for handling EFS elements may skip the
memcpy call that will write to the efs variable:
...
case L2CAP_CONF_EFS:
if (olen == sizeof(efs))
memcpy(&efs, (void *)val, olen);
...
The olen in the above if is attacker controlled, and regardless of that
if, in both of these functions the efs variable would eventually be
added to the outgoing configuration request that is being built:
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs);
So by sending a configuration request, or response, that contains an
L2CAP_CONF_EFS element, but with an element length that is not
sizeof(efs) - the memcpy to the uninitialized efs variable can be
avoided, and the uninitialized variable would be returned to the
attacker (16 bytes).
This issue has been assigned CVE-2017-1000410
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Ben Seri <ben@armis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bluetooth/l2cap_core.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
Marcel, for some reason this patch never got applied, despite lots of
advance notice. Please, someone queue it up as it resolves the above
very-well-reported issue.
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 43ba91c440bc..fc6615d59165 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3363,9 +3363,10 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
break;
case L2CAP_CONF_EFS:
- remote_efs = 1;
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
+ remote_efs = 1;
memcpy(&efs, (void *) val, olen);
+ }
break;
case L2CAP_CONF_EWS:
@@ -3584,16 +3585,17 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
break;
case L2CAP_CONF_EFS:
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
memcpy(&efs, (void *)val, olen);
- if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != chan->local_stype)
- return -ECONNREFUSED;
+ if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != chan->local_stype)
+ return -ECONNREFUSED;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
- (unsigned long) &efs, endptr - ptr);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
+ (unsigned long) &efs, endptr - ptr);
+ }
break;
case L2CAP_CONF_FCS:
^ permalink raw reply related
* Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
From: Roman Gushchin @ 2017-12-08 14:17 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, linux-kernel, kernel-team, ast, daniel, kafai,
Quentin Monnet, David Ahern
In-Reply-To: <20171207142306.285be14c@cakuba.netronome.com>
On Thu, Dec 07, 2017 at 02:23:06PM -0800, Jakub Kicinski wrote:
> On Thu, 7 Dec 2017 18:39:09 +0000, Roman Gushchin wrote:
> > This patch adds basic cgroup bpf operations to bpftool:
> > cgroup list, attach and detach commands.
> >
> > Usage is described in the corresponding man pages,
> > and examples are provided.
> >
> > Syntax:
> > $ bpftool cgroup list CGROUP
> > $ bpftool cgroup attach CGROUP ATTACH_TYPE PROG [ATTACH_FLAGS]
> > $ bpftool cgroup detach CGROUP ATTACH_TYPE PROG
> >
> > Signed-off-by: Roman Gushchin <guro@fb.com>
>
> Looks good, a few very minor nits/questions below.
>
> > diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
> > new file mode 100644
> > index 000000000000..88d67f74313f
> > --- /dev/null
> > +++ b/tools/bpf/bpftool/cgroup.c
> > @@ -0,0 +1,305 @@
> > +/*
> > + * Copyright (C) 2017 Facebook
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + *
> > + * Author: Roman Gushchin <guro@fb.com>
> > + */
> > +
> > +#include <fcntl.h>
> > +#include <stdlib.h>
> > +#include <string.h>
> > +#include <sys/stat.h>
> > +#include <sys/types.h>
> > +#include <unistd.h>
> > +
> > +#include <bpf.h>
> > +
> > +#include "main.h"
> > +
> > +static const char * const attach_type_strings[] = {
> > + [BPF_CGROUP_INET_INGRESS] = "ingress",
> > + [BPF_CGROUP_INET_EGRESS] = "egress",
> > + [BPF_CGROUP_INET_SOCK_CREATE] = "sock_create",
> > + [BPF_CGROUP_SOCK_OPS] = "sock_ops",
> > + [BPF_CGROUP_DEVICE] = "device",
> > + [__MAX_BPF_ATTACH_TYPE] = NULL,
> > +};
> > +
> > +static enum bpf_attach_type parse_attach_type(const char *str)
> > +{
> > + enum bpf_attach_type type;
> > +
> > + for (type = 0; type < __MAX_BPF_ATTACH_TYPE; type++) {
> > + if (attach_type_strings[type] &&
> > + strcmp(str, attach_type_strings[type]) == 0)
>
> Here and for matching flags you use straight strcmp(), not our locally
> defined is_prefix(), is this intentional? is_prefix() allows
> abbreviations, like in iproute2 commands. E.g. this would work:
Fixed in v3.
>
> # bpftool cg att /sys/fs/cgroup/test.slice/ dev id 1 allow_multi
>
> > + return type;
> > + }
> > +
> > + return __MAX_BPF_ATTACH_TYPE;
> > +}
>
> > +static int list_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type)
> > +{
> > + __u32 attach_flags;
> > + __u32 prog_ids[1024] = {0};
> > + __u32 prog_cnt, iter;
> > + char *attach_flags_str;
> > + int ret;
>
> nit: could you reorder the variables so they're listed longest to
> shortest (reverse christmas tree)?
>
> > + prog_cnt = ARRAY_SIZE(prog_ids);
> > + ret = bpf_prog_query(cgroup_fd, type, 0, &attach_flags, prog_ids,
> > + &prog_cnt);
> > + if (ret)
> > + return ret;
> > +
> > + if (prog_cnt == 0)
> > + return 0;
> > +
> > + switch (attach_flags) {
> > + case BPF_F_ALLOW_MULTI:
> > + attach_flags_str = "allow_multi";
> > + break;
> > + case BPF_F_ALLOW_OVERRIDE:
> > + attach_flags_str = "allow_override";
> > + break;
> > + case 0:
> > + attach_flags_str = "";
> > + break;
> > + default:
> > + attach_flags_str = "unknown";
>
> nit: would it make sense to perhaps print flags in hex format in this
> case?
>
> > + }
> > +
> > + for (iter = 0; iter < prog_cnt; iter++)
> > + list_bpf_prog(prog_ids[iter], attach_type_strings[type],
> > + attach_flags_str);
> > +
> > + return 0;
> > +}
>
> > +static int do_attach(int argc, char **argv)
> > +{
> > + int cgroup_fd, prog_fd;
> > + enum bpf_attach_type attach_type;
> > + int attach_flags = 0;
> > + int i;
> > + int ret = -1;
> > +
> > + if (argc < 4) {
> > + p_err("too few parameters for cgroup attach\n");
> > + goto exit;
> > + }
> > +
> > + cgroup_fd = open(argv[0], O_RDONLY);
> > + if (cgroup_fd < 0) {
> > + p_err("can't open cgroup %s\n", argv[1]);
> > + goto exit;
> > + }
> > +
> > + attach_type = parse_attach_type(argv[1]);
> > + if (attach_type == __MAX_BPF_ATTACH_TYPE) {
> > + p_err("invalid attach type\n");
> > + goto exit_cgroup;
> > + }
> > +
> > + argc -= 2;
> > + argv = &argv[2];
> > + prog_fd = prog_parse_fd(&argc, &argv);
> > + if (prog_fd < 0)
> > + goto exit_cgroup;
> > +
> > + for (i = 0; i < argc; i++) {
> > + if (strcmp(argv[i], "allow_multi") == 0) {
> > + attach_flags |= BPF_F_ALLOW_MULTI;
> > + } else if (strcmp(argv[i], "allow_override") == 0) {
> > + attach_flags |= BPF_F_ALLOW_OVERRIDE;
>
> This is the other potential place for is_prefix() I referred to.
Not sure about this case, as allow_multi and allow_override have
a common "allow_" prefix, so it might be confusing.
>
> That reminds me - would you care to also update Quentin's bash
> completions (tools/bpf/bpftool/bash-completion/bpftool)? They
> are _very_ nice to have in day to day use!
Sure, will do separately.
> Otherwise looks really nice, thanks for working on it!
Thank you for reviewing!
^ permalink raw reply
* Re: [PATCH v3] leds: trigger: Introduce a NETDEV trigger
From: Pavel Machek @ 2017-12-08 14:27 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Ben Whitten, rpurdie, jacek.anaszewski, linux-leds, LKML, netdev
In-Reply-To: <CAOFm3uGxzg45ZGmE4GRwy=oiaNERtq7tYdG4VwgZc0xgvXG6Pg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
On Thu 2017-12-07 14:01:39, Philippe Ombredanne wrote:
> Ben,
>
> On Thu, Dec 7, 2017 at 12:46 PM, Ben Whitten <ben.whitten@gmail.com> wrote:
> > From: Ben Whitten <ben.whitten@gmail.com>
> >
> > This commit introduces a NETDEV trigger for named device
> > activity. Available triggers are link, rx, and tx.
> >
> > Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
> []
> > --- /dev/null
> > +++ b/drivers/leds/trigger/ledtrig-netdev.c
> > @@ -0,0 +1,503 @@
> > +/*
> > + * LED Kernel Netdev Trigger
> > + *
> > + * Toggles the LED to reflect the link and traffic state of a named net device
> > + *
> > + * Copyright 2017 Ben Whitten <ben.whitten@gmail.com>
> > + *
> > + * Copyright 2007 Oliver Jowett <oliver@opencloud.com>
> > + *
> > + * Derived from ledtrig-timer.c which is:
> > + * Copyright 2005-2006 Openedhand Ltd.
> > + * Author: Richard Purdie <rpurdie@openedhand.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
>
> Have you considered using the new SPDX id instead ? See Thomas doc
> patches and Greg and Linus comments on the topic
> Here this would likely come out this way (yes, using a C++ comment at the top):
>
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * LED Kernel Netdev Trigger
> > + *
> > + * Toggles the LED to reflect the link and traffic state of a named net device
> > + *
> > + * Copyright 2017 Ben Whitten <ben.whitten@gmail.com>
> > + *
> > + * Copyright 2007 Oliver Jowett <oliver@opencloud.com>
> > + *
> > + * Derived from ledtrig-timer.c which is:
> > + * Copyright 2005-2006 Openedhand Ltd.
> > + * Author: Richard Purdie <rpurdie@openedhand.com>
> > + *
> > + */
>
>
> This is cleaner and simpler, don't you think?
Please consider putting SPDX where it logically belongs -- near the
copyright.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* pull-request: wireless-drivers 2017-12-08
From: Kalle Valo @ 2017-12-08 14:32 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this is a pull request to net tree for 4.15, more info in the signed tag
below. All small fixes and not really expecting any problems, but please
let me know if you have any.
Kalle
The following changes since commit f859b4af1c52493ec21173ccc73d0b60029b5b88:
sit: update frag_off info (2017-11-30 10:25:41 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-12-08
for you to fetch changes up to a41886f56b7bbb88e6a23b5d738a94f2632142a4:
Merge tag 'iwlwifi-for-kalle-2017-12-05' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2017-12-07 15:50:34 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.15
Second set of fixes for 4.15. This time a lot of iwlwifi patches and
two brcmfmac patches. Most important here are the MIC and IVC fixes
for iwlwifi to unbreak 9000 series.
iwlwifi
* fix rate-scaling to not start lowest possible rate
* fix the TX queue hang detection for AP/GO modes
* fix the TX queue hang timeout in monitor interfaces
* fix packet injection
* remove a wrong error message when dumping PCI registers
* fix race condition with RF-kill
* tell mac80211 when the MIC has been stripped (9000 series)
* tell mac80211 when the IVC has been stripped (9000 series)
* add 2 new PCI IDs, one for 9000 and one for 22000
* fix a queue hang due during a P2P Remain-on-Channel operation
brcmfmac
* fix a race which sometimes caused a crash during sdio unbind
* fix a kernel-doc related build error
----------------------------------------------------------------
Andy Shevchenko (1):
brcmfmac: Avoid build error with make W=1
Arend Van Spriel (1):
brcmfmac: change driver unbind order of the sdio function devices
David Spinadel (1):
iwlwifi: mvm: enable RX offloading with TKIP and WEP
Emmanuel Grumbach (3):
iwlwifi: mvm: don't use transmit queue hang detection when it is not possible
iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type
iwlwifi: mvm: fix packet injection
Ihab Zhaika (1):
iwlwifi: add new cards for 9260 and 22000 series
Johannes Berg (1):
iwlwifi: mvm: flush queue before deleting ROC
Kalle Valo (2):
Merge tag 'iwlwifi-for-kalle-2017-11-28' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'iwlwifi-for-kalle-2017-12-05' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Sara Sharon (3):
iwlwifi: pcie: fix erroneous "Read failed message"
iwlwifi: fix access to prph when transport is stopped
iwlwifi: mvm: mark MIC stripped MPDUs
Shaul Triebitz (1):
iwlwifi: mvm: set correct chains in Rx status
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/txq.h | 4 ++
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 2 -
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 ++
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 18 ++++++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 53 ++++++++++++++++------
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 24 +++++++++-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 13 +++++-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 2 +
.../net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 6 +++
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 10 ++++
15 files changed, 122 insertions(+), 27 deletions(-)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3] leds: trigger: Introduce a NETDEV trigger
From: Philippe Ombredanne @ 2017-12-08 14:32 UTC (permalink / raw)
To: Pavel Machek
Cc: Ben Whitten, rpurdie, jacek.anaszewski, linux-leds, LKML, netdev
In-Reply-To: <20171208142707.GA7793@amd>
Pavel,
On Fri, Dec 8, 2017 at 3:27 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Thu 2017-12-07 14:01:39, Philippe Ombredanne wrote:
>> Ben,
>>
>> On Thu, Dec 7, 2017 at 12:46 PM, Ben Whitten <ben.whitten@gmail.com> wrote:
>> > From: Ben Whitten <ben.whitten@gmail.com>
>> >
>> > This commit introduces a NETDEV trigger for named device
>> > activity. Available triggers are link, rx, and tx.
>> >
>> > Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
>> []
>> > --- /dev/null
>> > +++ b/drivers/leds/trigger/ledtrig-netdev.c
>> > @@ -0,0 +1,503 @@
>> > +/*
>> > + * LED Kernel Netdev Trigger
>> > + *
>> > + * Toggles the LED to reflect the link and traffic state of a named net device
>> > + *
>> > + * Copyright 2017 Ben Whitten <ben.whitten@gmail.com>
>> > + *
>> > + * Copyright 2007 Oliver Jowett <oliver@opencloud.com>
>> > + *
>> > + * Derived from ledtrig-timer.c which is:
>> > + * Copyright 2005-2006 Openedhand Ltd.
>> > + * Author: Richard Purdie <rpurdie@openedhand.com>
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License version 2 as
>> > + * published by the Free Software Foundation.
>> > + *
>> > + */
>>
>> Have you considered using the new SPDX id instead ? See Thomas doc
>> patches and Greg and Linus comments on the topic
>> Here this would likely come out this way (yes, using a C++ comment at the top):
>>
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/*
>> > + * LED Kernel Netdev Trigger
>> > + *
>> > + * Toggles the LED to reflect the link and traffic state of a named net device
>> > + *
>> > + * Copyright 2017 Ben Whitten <ben.whitten@gmail.com>
>> > + *
>> > + * Copyright 2007 Oliver Jowett <oliver@opencloud.com>
>> > + *
>> > + * Derived from ledtrig-timer.c which is:
>> > + * Copyright 2005-2006 Openedhand Ltd.
>> > + * Author: Richard Purdie <rpurdie@openedhand.com>
>> > + *
>> > + */
>>
>>
>> This is cleaner and simpler, don't you think?
>
> Please consider putting SPDX where it logically belongs -- near the
> copyright.
Linus wants it on the first line. So you could write this way alright:
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// Copyright 2017 Ben Whitten <ben.whitten@gmail.com>
>> > +// Copyright 2007 Oliver Jowett <oliver@opencloud.com>
>> > +/*
>> > + * LED Kernel Netdev Trigger
>> > + *
>> > + * Toggles the LED to reflect the link and traffic state of a named net device
>> > + *
>> > + * Derived from ledtrig-timer.c which is:
>> > + * Copyright 2005-2006 Openedhand Ltd.
>> > + * Author: Richard Purdie <rpurdie@openedhand.com>
>> > + *
>> > + */
For reference please check Linus [1][2][3], Thomas [4] and Greg [5]
comments on the topic of C++ style // comments and first line placement.
Jonathan also wrote a nice background article on the SPDXification
topic at LWN [6]
[1] https://lkml.org/lkml/2017/11/2/715
[2] https://lkml.org/lkml/2017/11/25/125
[3] https://lkml.org/lkml/2017/11/25/133
[4] https://lkml.org/lkml/2017/11/2/805
[5] https://lkml.org/lkml/2017/10/19/165
[6] https://lwn.net/Articles/739183/
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH net-next] macvlan: fix memory hole in macvlan_dev
From: Girish Moodalbail @ 2017-12-08 14:03 UTC (permalink / raw)
To: netdev, davem
Move 'macaddr_count' from after 'netpoll' to after 'nest_level' to pack
and reduce a memory hole.
Fixes: 88ca59d1aaf28c25 (macvlan: remove unused fields in struct macvlan_dev)
Signed-off-by: Girish Moodalbail <girish.moodalbail@oracle.com>
---
include/linux/if_macvlan.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index bedf54b..4cb7aee 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -30,10 +30,10 @@ struct macvlan_dev {
enum macvlan_mode mode;
u16 flags;
int nest_level;
+ unsigned int macaddr_count;
#ifdef CONFIG_NET_POLL_CONTROLLER
struct netpoll *netpoll;
#endif
- unsigned int macaddr_count;
};
static inline void macvlan_count_rx(const struct macvlan_dev *vlan,
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 0/4] bpftool: cgroup bpf operations
From: Roman Gushchin @ 2017-12-08 14:52 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, ast, daniel, jakub.kicinski, kafai,
guro, Quentin Monnet, David Ahern
This patchset adds basic cgroup bpf operations to bpftool.
Right now there is no convenient way to perform these operations.
The /samples/bpf/load_sock_ops.c implements attach/detacg operations,
but only for BPF_CGROUP_SOCK_OPS programs. Bps (part of bcc) implements
bpf introspection, but lacks any cgroup-related specific.
I find having a tool to perform these basic operations in the kernel tree
very useful, as it can be used in the corresponding bpf documentation
without creating additional dependencies. And bpftool seems to be
a right tool to extend with such functionality.
v3:
- SRC replaced with OBJ in prog load docs
- Output unknown attach type in hex
- License header in SPDX format
- Minor style fixes (e.g. variable reordering)
v2:
- Added prog load operations
- All cgroup operations are looking like bpftool cgroup <command>
- All cgroup-related stuff is moved to a separate file
- Added support for attach flags
- Added support for attaching/detaching programs by id, pinned name, etc
- Changed cgroup detach arguments order
- Added empty json output for succesful programs
- Style fixed: includes order, strncmp and macroses, error handling
- Added man pages
v1:
https://lwn.net/Articles/740366/
Roman Gushchin (4):
libbpf: add ability to guess program type based on section name
libbpf: prefer global symbols as bpf program name source
bpftool: implement prog load command
bpftool: implement cgroup bpf operations
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 92 +++++++
tools/bpf/bpftool/Documentation/bpftool-map.rst | 2 +-
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 12 +-
tools/bpf/bpftool/Documentation/bpftool.rst | 8 +-
tools/bpf/bpftool/cgroup.c | 300 +++++++++++++++++++++
tools/bpf/bpftool/common.c | 71 ++---
tools/bpf/bpftool/main.c | 3 +-
tools/bpf/bpftool/main.h | 2 +
tools/bpf/bpftool/prog.c | 29 +-
tools/lib/bpf/libbpf.c | 53 ++++
10 files changed, 533 insertions(+), 39 deletions(-)
create mode 100644 tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
create mode 100644 tools/bpf/bpftool/cgroup.c
--
2.14.3
^ permalink raw reply
* [PATCH v3 net-next 2/4] libbpf: prefer global symbols as bpf program name source
From: Roman Gushchin @ 2017-12-08 14:52 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, ast, daniel, jakub.kicinski, kafai,
guro, Quentin Monnet, David Ahern
In-Reply-To: <20171208145236.12635-1-guro@fb.com>
Libbpf picks the name of the first symbol in the corresponding
elf section to use as a program name. But without taking symbol's
scope into account it may end's up with some local label
as a program name. E.g.:
$ bpftool prog
1: type 15 name LBB0_10 tag 0390a5136ba23f5c
loaded_at Dec 07/17:22 uid 0
xlated 456B not jited memlock 4096B
Fix this by preferring global symbols as program name.
For instance:
$ bpftool prog
1: type 15 name bpf_prog1 tag 0390a5136ba23f5c
loaded_at Dec 07/17:26 uid 0
xlated 456B not jited memlock 4096B
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Quentin Monnet <quentin.monnet@netronome.com>
Cc: David Ahern <dsahern@gmail.com>
---
tools/lib/bpf/libbpf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 205b7822fa0a..65d0d0aff4fa 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -387,6 +387,8 @@ bpf_object__init_prog_names(struct bpf_object *obj)
continue;
if (sym.st_shndx != prog->idx)
continue;
+ if (GELF_ST_BIND(sym.st_info) != STB_GLOBAL)
+ continue;
name = elf_strptr(obj->efile.elf,
obj->efile.strtabidx,
--
2.14.3
^ permalink raw reply related
* [PATCH v3 net-next 3/4] bpftool: implement prog load command
From: Roman Gushchin @ 2017-12-08 14:52 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, ast, daniel, jakub.kicinski, kafai,
guro, Quentin Monnet, David Ahern
In-Reply-To: <20171208145236.12635-1-guro@fb.com>
Add the prog load command to load a bpf program from a specified
binary file and pin it to bpffs.
Usage description and examples are given in the corresponding man
page.
Syntax:
$ bpftool prog load OBJ FILE
FILE is a non-existing file on bpffs.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Quentin Monnet <quentin.monnet@netronome.com>
Cc: David Ahern <dsahern@gmail.com>
---
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 10 +++-
tools/bpf/bpftool/Documentation/bpftool.rst | 2 +-
tools/bpf/bpftool/common.c | 71 +++++++++++++-----------
tools/bpf/bpftool/main.h | 1 +
tools/bpf/bpftool/prog.c | 29 +++++++++-
5 files changed, 79 insertions(+), 34 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
index 36e8d1c3c40d..ffdb20e8280f 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
@@ -15,7 +15,7 @@ SYNOPSIS
*OPTIONS* := { { **-j** | **--json** } [{ **-p** | **--pretty** }] | { **-f** | **--bpffs** } }
*COMMANDS* :=
- { **show** | **dump xlated** | **dump jited** | **pin** | **help** }
+ { **show** | **dump xlated** | **dump jited** | **pin** | **load** | **help** }
MAP COMMANDS
=============
@@ -24,6 +24,7 @@ MAP COMMANDS
| **bpftool** **prog dump xlated** *PROG* [{**file** *FILE* | **opcodes**}]
| **bpftool** **prog dump jited** *PROG* [{**file** *FILE* | **opcodes**}]
| **bpftool** **prog pin** *PROG* *FILE*
+| **bpftool** **prog load** *OBJ* *FILE*
| **bpftool** **prog help**
|
| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
@@ -57,6 +58,11 @@ DESCRIPTION
Note: *FILE* must be located in *bpffs* mount.
+ **bpftool prog load** *OBJ* *FILE*
+ Load bpf program from binary *OBJ* and pin as *FILE*.
+
+ Note: *FILE* must be located in *bpffs* mount.
+
**bpftool prog help**
Print short help message.
@@ -126,8 +132,10 @@ EXAMPLES
|
| **# mount -t bpf none /sys/fs/bpf/**
| **# bpftool prog pin id 10 /sys/fs/bpf/prog**
+| **# bpftool prog load ./my_prog.o /sys/fs/bpf/prog2**
| **# ls -l /sys/fs/bpf/**
| -rw------- 1 root root 0 Jul 22 01:43 prog
+| -rw------- 1 root root 0 Jul 22 01:44 prog2
**# bpftool prog dum jited pinned /sys/fs/bpf/prog opcodes**
diff --git a/tools/bpf/bpftool/Documentation/bpftool.rst b/tools/bpf/bpftool/Documentation/bpftool.rst
index 926c03d5a8da..f547a0c0aa34 100644
--- a/tools/bpf/bpftool/Documentation/bpftool.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool.rst
@@ -26,7 +26,7 @@ SYNOPSIS
| **pin** | **help** }
*PROG-COMMANDS* := { **show** | **dump jited** | **dump xlated** | **pin**
- | **help** }
+ | **load** | **help** }
DESCRIPTION
===========
diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c
index 2bd3b280e6dd..b62c94e3997a 100644
--- a/tools/bpf/bpftool/common.c
+++ b/tools/bpf/bpftool/common.c
@@ -163,13 +163,49 @@ int open_obj_pinned_any(char *path, enum bpf_obj_type exp_type)
return fd;
}
-int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32))
+int do_pin_fd(int fd, const char *name)
{
char err_str[ERR_MAX_LEN];
- unsigned int id;
- char *endptr;
char *file;
char *dir;
+ int err = 0;
+
+ err = bpf_obj_pin(fd, name);
+ if (!err)
+ goto out;
+
+ file = malloc(strlen(name) + 1);
+ strcpy(file, name);
+ dir = dirname(file);
+
+ if (errno != EPERM || is_bpffs(dir)) {
+ p_err("can't pin the object (%s): %s", name, strerror(errno));
+ goto out_free;
+ }
+
+ /* Attempt to mount bpffs, then retry pinning. */
+ err = mnt_bpffs(dir, err_str, ERR_MAX_LEN);
+ if (!err) {
+ err = bpf_obj_pin(fd, name);
+ if (err)
+ p_err("can't pin the object (%s): %s", name,
+ strerror(errno));
+ } else {
+ err_str[ERR_MAX_LEN - 1] = '\0';
+ p_err("can't mount BPF file system to pin the object (%s): %s",
+ name, err_str);
+ }
+
+out_free:
+ free(file);
+out:
+ return err;
+}
+
+int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32))
+{
+ unsigned int id;
+ char *endptr;
int err;
int fd;
@@ -195,35 +231,8 @@ int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32))
return -1;
}
- err = bpf_obj_pin(fd, *argv);
- if (!err)
- goto out_close;
-
- file = malloc(strlen(*argv) + 1);
- strcpy(file, *argv);
- dir = dirname(file);
-
- if (errno != EPERM || is_bpffs(dir)) {
- p_err("can't pin the object (%s): %s", *argv, strerror(errno));
- goto out_free;
- }
+ err = do_pin_fd(fd, *argv);
- /* Attempt to mount bpffs, then retry pinning. */
- err = mnt_bpffs(dir, err_str, ERR_MAX_LEN);
- if (!err) {
- err = bpf_obj_pin(fd, *argv);
- if (err)
- p_err("can't pin the object (%s): %s", *argv,
- strerror(errno));
- } else {
- err_str[ERR_MAX_LEN - 1] = '\0';
- p_err("can't mount BPF file system to pin the object (%s): %s",
- *argv, err_str);
- }
-
-out_free:
- free(file);
-out_close:
close(fd);
return err;
}
diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index bff330b49791..bec1ccbb49c7 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -111,6 +111,7 @@ char *get_fdinfo(int fd, const char *key);
int open_obj_pinned(char *path);
int open_obj_pinned_any(char *path, enum bpf_obj_type exp_type);
int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32));
+int do_pin_fd(int fd, const char *name);
int do_prog(int argc, char **arg);
int do_map(int argc, char **arg);
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index ad619b96c276..037484ceaeaf 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -45,6 +45,7 @@
#include <sys/stat.h>
#include <bpf.h>
+#include <libbpf.h>
#include "main.h"
#include "disasm.h"
@@ -635,6 +636,30 @@ static int do_pin(int argc, char **argv)
return err;
}
+static int do_load(int argc, char **argv)
+{
+ struct bpf_object *obj;
+ int prog_fd;
+
+ if (argc != 2)
+ usage();
+
+ if (bpf_prog_load(argv[0], BPF_PROG_TYPE_UNSPEC, &obj, &prog_fd)) {
+ p_err("failed to load program\n");
+ return -1;
+ }
+
+ if (do_pin_fd(prog_fd, argv[1])) {
+ p_err("failed to pin program\n");
+ return -1;
+ }
+
+ if (json_output)
+ jsonw_null(json_wtr);
+
+ return 0;
+}
+
static int do_help(int argc, char **argv)
{
if (json_output) {
@@ -647,13 +672,14 @@ static int do_help(int argc, char **argv)
" %s %s dump xlated PROG [{ file FILE | opcodes }]\n"
" %s %s dump jited PROG [{ file FILE | opcodes }]\n"
" %s %s pin PROG FILE\n"
+ " %s %s load OBJ FILE\n"
" %s %s help\n"
"\n"
" " HELP_SPEC_PROGRAM "\n"
" " HELP_SPEC_OPTIONS "\n"
"",
bin_name, argv[-2], bin_name, argv[-2], bin_name, argv[-2],
- bin_name, argv[-2], bin_name, argv[-2]);
+ bin_name, argv[-2], bin_name, argv[-2], bin_name, argv[-2]);
return 0;
}
@@ -663,6 +689,7 @@ static const struct cmd cmds[] = {
{ "help", do_help },
{ "dump", do_dump },
{ "pin", do_pin },
+ { "load", do_load },
{ 0 }
};
--
2.14.3
^ permalink raw reply related
* [PATCH v3 net-next 1/4] libbpf: add ability to guess program type based on section name
From: Roman Gushchin @ 2017-12-08 14:52 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, ast, daniel, jakub.kicinski, kafai,
guro, Quentin Monnet, David Ahern
In-Reply-To: <20171208145236.12635-1-guro@fb.com>
The bpf_prog_load() function will guess program type if it's not
specified explicitly. This functionality will be used to implement
loading of different programs without asking a user to specify
the program type. In first order it will be used by bpftool.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Quentin Monnet <quentin.monnet@netronome.com>
Cc: David Ahern <dsahern@gmail.com>
---
tools/lib/bpf/libbpf.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 5aa45f89da93..205b7822fa0a 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1721,6 +1721,45 @@ BPF_PROG_TYPE_FNS(tracepoint, BPF_PROG_TYPE_TRACEPOINT);
BPF_PROG_TYPE_FNS(xdp, BPF_PROG_TYPE_XDP);
BPF_PROG_TYPE_FNS(perf_event, BPF_PROG_TYPE_PERF_EVENT);
+#define BPF_PROG_SEC(string, type) { string, sizeof(string), type }
+static const struct {
+ const char *sec;
+ size_t len;
+ enum bpf_prog_type prog_type;
+} section_names[] = {
+ BPF_PROG_SEC("socket", BPF_PROG_TYPE_SOCKET_FILTER),
+ BPF_PROG_SEC("kprobe/", BPF_PROG_TYPE_KPROBE),
+ BPF_PROG_SEC("kretprobe/", BPF_PROG_TYPE_KPROBE),
+ BPF_PROG_SEC("tracepoint/", BPF_PROG_TYPE_TRACEPOINT),
+ BPF_PROG_SEC("xdp", BPF_PROG_TYPE_XDP),
+ BPF_PROG_SEC("perf_event", BPF_PROG_TYPE_PERF_EVENT),
+ BPF_PROG_SEC("cgroup/skb", BPF_PROG_TYPE_CGROUP_SKB),
+ BPF_PROG_SEC("cgroup/sock", BPF_PROG_TYPE_CGROUP_SOCK),
+ BPF_PROG_SEC("cgroup/dev", BPF_PROG_TYPE_CGROUP_DEVICE),
+ BPF_PROG_SEC("sockops", BPF_PROG_TYPE_SOCK_OPS),
+ BPF_PROG_SEC("sk_skb", BPF_PROG_TYPE_SK_SKB),
+};
+#undef BPF_PROG_SEC
+
+static enum bpf_prog_type bpf_program__guess_type(struct bpf_program *prog)
+{
+ int i;
+
+ if (!prog->section_name)
+ goto err;
+
+ for (i = 0; i < ARRAY_SIZE(section_names); i++)
+ if (strncmp(prog->section_name, section_names[i].sec,
+ section_names[i].len) == 0)
+ return section_names[i].prog_type;
+
+err:
+ pr_warning("failed to guess program type based on section name %s\n",
+ prog->section_name);
+
+ return BPF_PROG_TYPE_UNSPEC;
+}
+
int bpf_map__fd(struct bpf_map *map)
{
return map ? map->fd : -EINVAL;
@@ -1832,6 +1871,18 @@ int bpf_prog_load(const char *file, enum bpf_prog_type type,
return -ENOENT;
}
+ /*
+ * If type is not specified, try to guess it based on
+ * section name.
+ */
+ if (type == BPF_PROG_TYPE_UNSPEC) {
+ type = bpf_program__guess_type(prog);
+ if (type == BPF_PROG_TYPE_UNSPEC) {
+ bpf_object__close(obj);
+ return -EINVAL;
+ }
+ }
+
bpf_program__set_type(prog, type);
err = bpf_object__load(obj);
if (err) {
--
2.14.3
^ permalink raw reply related
* [PATCH v3 net-next 4/4] bpftool: implement cgroup bpf operations
From: Roman Gushchin @ 2017-12-08 14:52 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, ast, daniel, jakub.kicinski, kafai,
guro, Quentin Monnet, David Ahern
In-Reply-To: <20171208145236.12635-1-guro@fb.com>
This patch adds basic cgroup bpf operations to bpftool:
cgroup list, attach and detach commands.
Usage is described in the corresponding man pages,
and examples are provided.
Syntax:
$ bpftool cgroup list CGROUP
$ bpftool cgroup attach CGROUP ATTACH_TYPE PROG [ATTACH_FLAGS]
$ bpftool cgroup detach CGROUP ATTACH_TYPE PROG
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
---
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 92 +++++++
tools/bpf/bpftool/Documentation/bpftool-map.rst | 2 +-
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 2 +-
tools/bpf/bpftool/Documentation/bpftool.rst | 6 +-
tools/bpf/bpftool/cgroup.c | 300 +++++++++++++++++++++
tools/bpf/bpftool/main.c | 3 +-
tools/bpf/bpftool/main.h | 1 +
7 files changed, 401 insertions(+), 5 deletions(-)
create mode 100644 tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
create mode 100644 tools/bpf/bpftool/cgroup.c
diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
new file mode 100644
index 000000000000..61ded613aee1
--- /dev/null
+++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
@@ -0,0 +1,92 @@
+================
+bpftool-cgroup
+================
+-------------------------------------------------------------------------------
+tool for inspection and simple manipulation of eBPF progs
+-------------------------------------------------------------------------------
+
+:Manual section: 8
+
+SYNOPSIS
+========
+
+ **bpftool** [*OPTIONS*] **cgroup** *COMMAND*
+
+ *OPTIONS* := { { **-j** | **--json** } [{ **-p** | **--pretty** }] | { **-f** | **--bpffs** } }
+
+ *COMMANDS* :=
+ { **list** | **attach** | **detach** | **help** }
+
+MAP COMMANDS
+=============
+
+| **bpftool** **cgroup list** *CGROUP*
+| **bpftool** **cgroup attach** *CGROUP* *ATTACH_TYPE* *PROG* [*ATTACH_FLAGS*]
+| **bpftool** **cgroup detach** *CGROUP* *ATTACH_TYPE* *PROG*
+| **bpftool** **cgroup help**
+|
+| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
+
+DESCRIPTION
+===========
+ **bpftool cgroup list** *CGROUP*
+ List all programs attached to the cgroup *CGROUP*.
+
+ Output will start with program ID followed by attach type,
+ attach flags and program name.
+
+ **bpftool cgroup attach** *CGROUP* *ATTACH_TYPE* *PROG* [*ATTACH_FLAGS*]
+ Attach program *PROG* to the cgroup *CGROUP* with attach type
+ *ATTACH_TYPE* and optional *ATTACH_FLAGS*.
+
+ **bpftool cgroup detach** *CGROUP* *ATTACH_TYPE* *PROG*
+ Detach *PROG* from the cgroup *CGROUP* and attach type
+ *ATTACH_TYPE*.
+
+ **bpftool prog help**
+ Print short help message.
+
+OPTIONS
+=======
+ -h, --help
+ Print short generic help message (similar to **bpftool help**).
+
+ -v, --version
+ Print version number (similar to **bpftool version**).
+
+ -j, --json
+ Generate JSON output. For commands that cannot produce JSON, this
+ option has no effect.
+
+ -p, --pretty
+ Generate human-readable JSON output. Implies **-j**.
+
+ -f, --bpffs
+ Show file names of pinned programs.
+
+EXAMPLES
+========
+|
+| **# mount -t bpf none /sys/fs/bpf/**
+| **# mkdir /sys/fs/cgroup/test.slice**
+| **# bpftool prog load ./device_cgroup.o /sys/fs/bpf/prog**
+| **# bpftool cgroup attach /sys/fs/cgroup/test.slice/ device id 1 allow_multi**
+
+**# bpftool cgroup list /sys/fs/cgroup/test.slice/**
+
+::
+
+ ID AttachType AttachFlags Name
+ 1 device allow_multi bpf_prog1
+
+|
+| **# bpftool cgroup detach /sys/fs/cgroup/test.slice/ device id 1**
+| **# bpftool cgroup list /sys/fs/cgroup/test.slice/**
+
+::
+
+ ID AttachType AttachFlags Name
+
+SEE ALSO
+========
+ **bpftool**\ (8), **bpftool-prog**\ (8), **bpftool-map**\ (8)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-map.rst b/tools/bpf/bpftool/Documentation/bpftool-map.rst
index 9f51a268eb06..421cabc417e6 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-map.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-map.rst
@@ -128,4 +128,4 @@ EXAMPLES
SEE ALSO
========
- **bpftool**\ (8), **bpftool-prog**\ (8)
+ **bpftool**\ (8), **bpftool-prog**\ (8), **bpftool-cgroup**\ (8)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
index ffdb20e8280f..81c97c0e9b67 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
@@ -155,4 +155,4 @@ EXAMPLES
SEE ALSO
========
- **bpftool**\ (8), **bpftool-map**\ (8)
+ **bpftool**\ (8), **bpftool-map**\ (8), **bpftool-cgroup**\ (8)
diff --git a/tools/bpf/bpftool/Documentation/bpftool.rst b/tools/bpf/bpftool/Documentation/bpftool.rst
index f547a0c0aa34..6732a5a617e4 100644
--- a/tools/bpf/bpftool/Documentation/bpftool.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool.rst
@@ -16,7 +16,7 @@ SYNOPSIS
**bpftool** **version**
- *OBJECT* := { **map** | **program** }
+ *OBJECT* := { **map** | **program** | **cgroup** }
*OPTIONS* := { { **-V** | **--version** } | { **-h** | **--help** }
| { **-j** | **--json** } [{ **-p** | **--pretty** }] }
@@ -28,6 +28,8 @@ SYNOPSIS
*PROG-COMMANDS* := { **show** | **dump jited** | **dump xlated** | **pin**
| **load** | **help** }
+ *CGROUP-COMMANDS* := { **list** | **attach** | **detach** | **help** }
+
DESCRIPTION
===========
*bpftool* allows for inspection and simple modification of BPF objects
@@ -53,4 +55,4 @@ OPTIONS
SEE ALSO
========
- **bpftool-map**\ (8), **bpftool-prog**\ (8)
+ **bpftool-map**\ (8), **bpftool-prog**\ (8), **bpftool-cgroup**\ (8)
diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
new file mode 100644
index 000000000000..8116d58699af
--- /dev/null
+++ b/tools/bpf/bpftool/cgroup.c
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2017 Facebook
+// Author: Roman Gushchin <guro@fb.com>
+
+#include <fcntl.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+#include <bpf.h>
+
+#include "main.h"
+
+static const char * const attach_type_strings[] = {
+ [BPF_CGROUP_INET_INGRESS] = "ingress",
+ [BPF_CGROUP_INET_EGRESS] = "egress",
+ [BPF_CGROUP_INET_SOCK_CREATE] = "sock_create",
+ [BPF_CGROUP_SOCK_OPS] = "sock_ops",
+ [BPF_CGROUP_DEVICE] = "device",
+ [__MAX_BPF_ATTACH_TYPE] = NULL,
+};
+
+static enum bpf_attach_type parse_attach_type(const char *str)
+{
+ enum bpf_attach_type type;
+
+ for (type = 0; type < __MAX_BPF_ATTACH_TYPE; type++) {
+ if (attach_type_strings[type] &&
+ is_prefix(str, attach_type_strings[type]))
+ return type;
+ }
+
+ return __MAX_BPF_ATTACH_TYPE;
+}
+
+static int list_bpf_prog(int id, const char *attach_type_str,
+ const char *attach_flags_str)
+{
+ struct bpf_prog_info info = {};
+ __u32 info_len = sizeof(info);
+ int prog_fd;
+
+ prog_fd = bpf_prog_get_fd_by_id(id);
+ if (prog_fd < 0)
+ return -1;
+
+ if (bpf_obj_get_info_by_fd(prog_fd, &info, &info_len)) {
+ close(prog_fd);
+ return -1;
+ }
+
+ if (json_output) {
+ jsonw_start_object(json_wtr);
+ jsonw_uint_field(json_wtr, "id", info.id);
+ jsonw_string_field(json_wtr, "attach_type",
+ attach_type_str);
+ jsonw_string_field(json_wtr, "attach_flags",
+ attach_flags_str);
+ jsonw_string_field(json_wtr, "name", info.name);
+ jsonw_end_object(json_wtr);
+ } else {
+ printf("%-8u %-15s %-15s %-15s\n", info.id,
+ attach_type_str,
+ attach_flags_str,
+ info.name);
+ }
+
+ close(prog_fd);
+ return 0;
+}
+
+static int list_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type)
+{
+ __u32 prog_ids[1024] = {0};
+ char *attach_flags_str;
+ __u32 prog_cnt, iter;
+ __u32 attach_flags;
+ char buf[16];
+ int ret;
+
+ prog_cnt = ARRAY_SIZE(prog_ids);
+ ret = bpf_prog_query(cgroup_fd, type, 0, &attach_flags, prog_ids,
+ &prog_cnt);
+ if (ret)
+ return ret;
+
+ if (prog_cnt == 0)
+ return 0;
+
+ switch (attach_flags) {
+ case BPF_F_ALLOW_MULTI:
+ attach_flags_str = "allow_multi";
+ break;
+ case BPF_F_ALLOW_OVERRIDE:
+ attach_flags_str = "allow_override";
+ break;
+ case 0:
+ attach_flags_str = "";
+ break;
+ default:
+ snprintf(buf, sizeof(buf), "unknown(%x)", attach_flags);
+ attach_flags_str = buf;
+ }
+
+ for (iter = 0; iter < prog_cnt; iter++)
+ list_bpf_prog(prog_ids[iter], attach_type_strings[type],
+ attach_flags_str);
+
+ return 0;
+}
+
+static int do_list(int argc, char **argv)
+{
+ enum bpf_attach_type type;
+ int cgroup_fd;
+ int ret = -1;
+
+ if (argc < 1) {
+ p_err("too few parameters for cgroup list\n");
+ goto exit;
+ } else if (argc > 1) {
+ p_err("too many parameters for cgroup list\n");
+ goto exit;
+ }
+
+ cgroup_fd = open(argv[0], O_RDONLY);
+ if (cgroup_fd < 0) {
+ p_err("can't open cgroup %s\n", argv[1]);
+ goto exit;
+ }
+
+ if (json_output)
+ jsonw_start_array(json_wtr);
+ else
+ printf("%-8s %-15s %-15s %-15s\n", "ID", "AttachType",
+ "AttachFlags", "Name");
+
+ for (type = 0; type < __MAX_BPF_ATTACH_TYPE; type++) {
+ /*
+ * Not all attach types may be supported, so it's expected,
+ * that some requests will fail.
+ * If we were able to get the list for at least one
+ * attach type, let's return 0.
+ */
+ if (list_attached_bpf_progs(cgroup_fd, type) == 0)
+ ret = 0;
+ }
+
+ if (json_output)
+ jsonw_end_array(json_wtr);
+
+ close(cgroup_fd);
+exit:
+ return ret;
+}
+
+static int do_attach(int argc, char **argv)
+{
+ int cgroup_fd, prog_fd;
+ enum bpf_attach_type attach_type;
+ int attach_flags = 0;
+ int i;
+ int ret = -1;
+
+ if (argc < 4) {
+ p_err("too few parameters for cgroup attach\n");
+ goto exit;
+ }
+
+ cgroup_fd = open(argv[0], O_RDONLY);
+ if (cgroup_fd < 0) {
+ p_err("can't open cgroup %s\n", argv[1]);
+ goto exit;
+ }
+
+ attach_type = parse_attach_type(argv[1]);
+ if (attach_type == __MAX_BPF_ATTACH_TYPE) {
+ p_err("invalid attach type\n");
+ goto exit_cgroup;
+ }
+
+ argc -= 2;
+ argv = &argv[2];
+ prog_fd = prog_parse_fd(&argc, &argv);
+ if (prog_fd < 0)
+ goto exit_cgroup;
+
+ for (i = 0; i < argc; i++) {
+ if (strcmp(argv[i], "allow_multi") == 0) {
+ attach_flags |= BPF_F_ALLOW_MULTI;
+ } else if (strcmp(argv[i], "allow_override") == 0) {
+ attach_flags |= BPF_F_ALLOW_OVERRIDE;
+ } else {
+ p_err("unknown option: %s\n", argv[i]);
+ goto exit_cgroup;
+ }
+ }
+
+ if (bpf_prog_attach(prog_fd, cgroup_fd, attach_type, attach_flags)) {
+ p_err("failed to attach program");
+ goto exit_prog;
+ }
+
+ if (json_output)
+ jsonw_null(json_wtr);
+
+ ret = 0;
+
+exit_prog:
+ close(prog_fd);
+exit_cgroup:
+ close(cgroup_fd);
+exit:
+ return ret;
+}
+
+static int do_detach(int argc, char **argv)
+{
+ int prog_fd, cgroup_fd;
+ enum bpf_attach_type attach_type;
+ int ret = -1;
+
+ if (argc < 4) {
+ p_err("too few parameters for cgroup detach\n");
+ goto exit;
+ }
+
+ cgroup_fd = open(argv[0], O_RDONLY);
+ if (cgroup_fd < 0) {
+ p_err("can't open cgroup %s\n", argv[1]);
+ goto exit;
+ }
+
+ attach_type = parse_attach_type(argv[1]);
+ if (attach_type == __MAX_BPF_ATTACH_TYPE) {
+ p_err("invalid attach type");
+ goto exit_cgroup;
+ }
+
+ argc -= 2;
+ argv = &argv[2];
+ prog_fd = prog_parse_fd(&argc, &argv);
+ if (prog_fd < 0)
+ goto exit_cgroup;
+
+ if (bpf_prog_detach2(prog_fd, cgroup_fd, attach_type)) {
+ p_err("failed to detach program");
+ goto exit_prog;
+ }
+
+ if (json_output)
+ jsonw_null(json_wtr);
+
+ ret = 0;
+
+exit_prog:
+ close(prog_fd);
+exit_cgroup:
+ close(cgroup_fd);
+exit:
+ return ret;
+}
+
+static int do_help(int argc, char **argv)
+{
+ if (json_output) {
+ jsonw_null(json_wtr);
+ return 0;
+ }
+
+ fprintf(stderr,
+ "Usage: %s %s list CGROUP\n"
+ " %s %s attach CGROUP TYPE PROG [ATTACH_FLAGS]\n"
+ " %s %s detach CGROUP TYPE PROG\n"
+ " %s %s help\n"
+ "\n"
+ " ATTACH_FLAGS := { allow_multi | allow_override }"
+ " " HELP_SPEC_PROGRAM "\n"
+ " " HELP_SPEC_OPTIONS "\n"
+ "",
+ bin_name, argv[-2], bin_name, argv[-2],
+ bin_name, argv[-2], bin_name, argv[-2]);
+
+ return 0;
+}
+
+static const struct cmd cmds[] = {
+ { "list", do_list },
+ { "attach", do_attach },
+ { "detach", do_detach },
+ { "help", do_help },
+ { 0 }
+};
+
+int do_cgroup(int argc, char **argv)
+{
+ return cmd_select(cmds, argc, argv, do_help);
+}
diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c
index d294bc8168be..ecd53ccf1239 100644
--- a/tools/bpf/bpftool/main.c
+++ b/tools/bpf/bpftool/main.c
@@ -85,7 +85,7 @@ static int do_help(int argc, char **argv)
" %s batch file FILE\n"
" %s version\n"
"\n"
- " OBJECT := { prog | map }\n"
+ " OBJECT := { prog | map | cgroup }\n"
" " HELP_SPEC_OPTIONS "\n"
"",
bin_name, bin_name, bin_name);
@@ -173,6 +173,7 @@ static const struct cmd cmds[] = {
{ "batch", do_batch },
{ "prog", do_prog },
{ "map", do_map },
+ { "cgroup", do_cgroup },
{ "version", do_version },
{ 0 }
};
diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index bec1ccbb49c7..8f6d3cac0347 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -115,6 +115,7 @@ int do_pin_fd(int fd, const char *name);
int do_prog(int argc, char **arg);
int do_map(int argc, char **arg);
+int do_cgroup(int argc, char **arg);
int prog_parse_fd(int *argc, char ***argv);
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
From: Roman Gushchin @ 2017-12-08 14:53 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: netdev, Quentin Monnet, LKML, kernel-team, ast, daniel,
jakub.kicinski, kafai, David Ahern
In-Reply-To: <CAOFm3uEFF=7DuxsT-+45q2ZENDfhitUg18V53qtOo9fj7JHOvA@mail.gmail.com>
On Fri, Dec 08, 2017 at 02:56:15PM +0100, Philippe Ombredanne wrote:
> On Fri, Dec 8, 2017 at 11:34 AM, Quentin Monnet
> <quentin.monnet@netronome.com> wrote:
> > 2017-12-07 18:39 UTC+0000 ~ Roman Gushchin <guro@fb.com>
> >> This patch adds basic cgroup bpf operations to bpftool:
> >> cgroup list, attach and detach commands.
>
> [...]
> >> --- /dev/null
> >> +++ b/tools/bpf/bpftool/cgroup.c
> >> @@ -0,0 +1,305 @@
> >> +/*
> >> + * Copyright (C) 2017 Facebook
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU General Public License
> >> + * as published by the Free Software Foundation; either version
> >> + * 2 of the License, or (at your option) any later version.
> >> + *
> >> + *
> >> + */
> >> +
>
> Roman,
> Have you considered using the simpler and new SPDX ids instead? e.g.:
>
> // SPDX-License-Identifier: GPL-2.0+
> // Copyright (C) 2017 Facebook
> // Author: Roman Gushchin <guro@fb.com>
>
> This would boost your code/comments ratio nicely IMHO.
Thanks, applied to v3!
^ permalink raw reply
* Re: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave
From: Marcelo Ricardo Leitner @ 2017-12-08 14:56 UTC (permalink / raw)
To: David Laight
Cc: 'Xin Long', network dev, linux-sctp@vger.kernel.org,
Neil Horman, davem@davemloft.net
In-Reply-To: <2ca21c61e82a44daa29226eac54a4950@AcuMS.aculab.com>
On Fri, Dec 08, 2017 at 02:06:04PM +0000, David Laight wrote:
> From: Xin Long
> > Sent: 08 December 2017 13:04
> ...
> > @@ -264,8 +264,8 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
> > frag |= SCTP_DATA_SACK_IMM;
> > }
> >
> > - chunk = sctp_make_datafrag_empty(asoc, sinfo, len, frag,
> > - 0, GFP_KERNEL);
> > + chunk = asoc->stream.si->make_datafrag(asoc, sinfo, len, frag,
> > + GFP_KERNEL);
>
> I know that none of the sctp code is very optimised, but that indirect
> call is going to be horrid.
Yeah.. but there is no way to avoid the double derreference
considering we only have the asoc pointer in there and we have to
reach the contents of the data chunk operations struct, and the .si
part is the same as 'stream' part as it's a constant offset.
Due to the for() in there, we could add a variable to store
asoc->stream.si outside the for and then we can do only a single deref
inside it. Xin, can you please try and see if the generated code is
different?
Other suggestions?
Marcelo
^ 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