* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Ard Biesheuvel @ 2018-09-13 15:07 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Andrew Lutomirski, LKML, Netdev, David Miller, Greg Kroah-Hartman,
Samuel Neves, Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CAHmME9pp8HoisxQWL_eELR-ziiBii-7mcA=oF9UF-WMucewX5w@mail.gmail.com>
On 13 September 2018 at 16:18, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Thu, Sep 13, 2018 at 1:45 AM Andy Lutomirski <luto@kernel.org> wrote:
>> I'm not convinced that there's any real need for *all* crypto
>> algorithms to move into lib/zinc or to move at all. As I see it,
>> there are two classes of crypto algorithms in the kernel:
>>
>> a) Crypto that is used by code that chooses its algorithm statically
>> and wants synchronous operations. These include everything in
>> drivers/char/random.c, but also a bunch of various networking things
>> that are hardcoded and basically everything that uses stack buffers.
>> (This means it includes all the code that I broke when I did
>> VMAP_STACK. Sign.)
>
> Right, exactly. This is what will wind up using Zinc. I'm working on
> an example usage of this for v4 of the patch submission, which you can
> ogle in a preview here if you're curious:
>
> https://git.zx2c4.com/linux-dev/commit/?h=big_key_rewrite
>
> 28 insertions, 206 deletions :-D
>
I must say, that actually looks pretty good.
>> b) Crypto that is used dynamically. This includes dm-crypt
>> (aes-xts-plain64, aes-cbc-essiv, etc), all the ALG_IF interfaces, a
>> lot of IPSEC stuff, possibly KCM, and probably many more. These will
>> get comparatively little benefit from being converted to a zinc-like
>> interface. For some of these cases, it wouldn't make any sense at all
>> to convert them. Certainly the ones that do async hardware crypto
>> using DMA engines will never look at all like zinc, even under the
>> hood.
>
> Right, this is what the crypto API will continue to be used for.
>
>
>> I think that, as a short-term goal, it makes a lot of sense to have
>> implementations of the crypto that *new* kernel code (like Wireguard)
>> wants to use in style (a) that live in /lib, and it obviously makes
>> sense to consolidate their implementations with the crypto/
>> implementations in a timely manner. As a medium-term goal, adding
>> more algorithms as needed for things that could use the simpler APIs
>> (Bluetooth, perhaps) would make sense.
>
> Agreed 100%. With regards to "consolidate their implementations" --
> I've actually already done this after your urging yesterday, and so
> that will be a part of v4.
>
>> But I see no reason at all that /lib should ever contain a grab-bag of
>> crypto implementations just for the heck of it. They should have real
>> in-kernel users IMO. And this means that there will probably always
>> be some crypto implementations in crypto/ for things like aes-xts.
>
> Right, precisely.
>
> Jason
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] man: Add devlink health man page
From: Andrew Lunn @ 2018-09-13 15:12 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Jakub Kicinski,
Simon Horman, Alexander Duyck, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <66584ca2-8efa-9a6d-c1f3-1cf81cb04259@mellanox.com>
> >>>> devlink health sensor set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
> >>>> Sets TX_COMP_ERROR sensor parameters for a specific device.
> >>This is what I had in mind:
> >>1. command interface error
> >>2. command interface timeout
> >>3. stuck TX queue (like tx_timeout)
> >>4. stuck TX completion queue (driver did not process packets in a reasonable
> >>time period)
> >>5. stuck RX queue
> >>6. RX completion error
> >>7. TX completion error
> >>8. HW / FW catastrophic error report
> >>9. completion queue overrun
> Such issues do exist in production environment, and need to be handled even
> if root cause is a bug which will be fixed in latest release. My feature
> should help developers / administrator to control and recover their live
> systems, by auto correction and logging support.
> Goal is:
> - Provide alert debug information
> - Self healing
> - If problem needs vendor support, provide a way to gather all needed
> debugging information.
So maybe you have the wrong name for this. Health is nice in terms of
Marketing, but we are actually talking about bug recovery.
devlink bug sensor set pci/0000:01:00.0 name command_interface_error action reset off action dump on
devlink bug sensor set pci/0000:01:00.0 name command_interface_timeout action reset off action dump on
devlink bug sensor set pci/0000:01:00.0 name transmit_completion_error action reset off action dump on
devlink bug sensor set pci/0000:01:00.0 name completion_queue_overrun action reset off action dump on
seems a lot more understandable than:
devlink health set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
Andrew
^ permalink raw reply
* Re: [PATCH v3 net-next 0/6] Add support for Lantiq / Intel vrx200 network
From: David Miller @ 2018-09-13 15:15 UTC (permalink / raw)
To: hauke
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree
In-Reply-To: <20180909201647.32727-1-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sun, 9 Sep 2018 22:16:41 +0200
> This adds basic support for the GSWIP (Gigabit Switch) found in the
> VRX200 SoC.
> There are different versions of this IP core used in different SoCs, but
> this driver was currently only tested on the VRX200 SoC line, for other
> SoCs this driver probably need some adoptions to work.
>
> I also plan to add Layer 2 offloading to the DSA driver and later also
> layer 3 offloading which is supported by the PPE HW block.
>
> All these patches should go through the net-next tree.
>
> This depends on the patch "MIPS: lantiq: dma: add dev pointer" which
> should go into 4.19.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH iproute2] iproute2: fix use-after-free
From: Stephen Hemminger @ 2018-09-13 15:19 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार)
Cc: Mahesh Bandewar, netdev
In-Reply-To: <CAF2d9jgpN0T+BuMTk9GwNKVEcmH2V_yC8R=WvWYCZ95E_pkfwg@mail.gmail.com>
On Wed, 12 Sep 2018 23:07:20 -0700
Mahesh Bandewar (महेश बंडेवार) <maheshb@google.com> wrote:
> On Wed, Sep 12, 2018 at 5:33 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Wed, 12 Sep 2018 16:29:28 -0700
> > Mahesh Bandewar <mahesh@bandewar.net> wrote:
> >
> > > From: Mahesh Bandewar <maheshb@google.com>
> > >
> > > A local program using iproute2 lib pointed out the issue and looking
> > > at the code it is pretty obvious -
> > >
> > > a = (struct nlmsghdr *)b;
> > > ...
> > > free(b);
> > > if (a->nlmsg_seq == seq)
> > > ...
> > >
> > > Fixes: 86bf43c7c2fd ("lib/libnetlink: update rtnl_talk to support malloc buff at run time")
> > > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> >
> > Yes, this is a real problem.
> >
> > Maybe a minimal patch like this would be enough:
> actually that will leave the memory leak at the 'goto next' line (just
> few lines below) since that jump will overwrite the buf.
It looks like everytime in the while loop. a new buffer is allocated.
So yes, it looks like old, my patch, and your patch would leak there
was an error followed by other data in response.
Though I doubt kernel would ever do that.
The only user of iov style messages to the kernel is in tc batching.
My gut feeling is that if one message in batch has error, then
the netlink code should return that error and stop processing more.
^ permalink raw reply
* Re: [PATCH 2/2] net: qcom/emac: add shared mdio bus support
From: Wang, Dongsheng @ 2018-09-13 15:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: timur@kernel.org, davem@davemloft.net, Zheng, Joey,
netdev@vger.kernel.org
In-Reply-To: <20180913124229.GD11702@lunn.ch>
On 9/13/2018 8:42 PM, Andrew Lunn wrote:
> On Thu, Sep 13, 2018 at 05:04:53PM +0800, Wang Dongsheng wrote:
>> Share the mii_bus for others MAC device because QDF2400 emac
>> include MDIO, and the motherboard has more than one PHY connected
>> to an MDIO bus.
>>
>> Tested: QDF2400 (ACPI), buildin/insmod/rmmod
>>
>> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
> Hi Wang
>
> This is a pretty big patch, and is hard to review. Could you try to
> break it up into a number of smaller patches. You could for example
> first refactor emacs_phy_config(), without making any functional
> changes. Then add the sharing. Maybe do OF an ACPI in different
> patches?
>
> Thanks
> Andrew
>
Ok, thanks.
Cheers
Dongsheng
^ permalink raw reply
* Re: [PATCHv2 net] ipv6: use rt6_info members when dst is set in rt6_fill_node
From: David Miller @ 2018-09-13 15:21 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, dsa, roopa
In-Reply-To: <84d6cd6a280394837623ddb49186e5c299eb7a03.1536647638.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 11 Sep 2018 14:33:58 +0800
> In inet6_rtm_getroute, since Commit 93531c674315 ("net/ipv6: separate
> handling of FIB entries from dst based routes"), it has used rt->from
> to dump route info instead of rt.
>
> However for some route like cache, some of its information like flags
> or gateway is not the same as that of the 'from' one. It caused 'ip
> route get' to dump the wrong route information.
>
> In Jianlin's testing, the output information even lost the expiration
> time for a pmtu route cache due to the wrong fib6_flags.
>
> So change to use rt6_info members for dst addr, src addr, flags and
> gateway when it tries to dump a route entry without fibmatch set.
>
> v1->v2:
> - not use rt6i_prefsrc.
> - also fix the gw dump issue.
>
> Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks Xin.
^ permalink raw reply
* RE: [PATCH] hv_netvsc: fix schedule in RCU context
From: Haiyang Zhang @ 2018-09-13 15:33 UTC (permalink / raw)
To: Stephen Hemminger, KY Srinivasan
Cc: netdev@vger.kernel.org, Stephen Hemminger
In-Reply-To: <20180913150342.32101-1-sthemmin@microsoft.com>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, September 13, 2018 11:04 AM
> To: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>
> Cc: netdev@vger.kernel.org; Stephen Hemminger <sthemmin@microsoft.com>
> Subject: [PATCH] hv_netvsc: fix schedule in RCU context
>
> When netvsc device is removed it can call reschedule in RCU context.
> This happens because canceling the subchannel setup work could (in theory)
> cause a reschedule when manipulating the timer.
>
> To reproduce, run with lockdep enabled kernel and unbind
> a network device from hv_netvsc (via sysfs).
>
> [ 160.682011] WARNING: suspicious RCU usage
> [ 160.707466] 4.19.0-rc3-uio+ #2 Not tainted
> [ 160.709937] -----------------------------
> [ 160.712352] ./include/linux/rcupdate.h:302 Illegal context switch in RCU
> read-side critical section!
> [ 160.723691]
> [ 160.723691] other info that might help us debug this:
> [ 160.723691]
> [ 160.730955]
> [ 160.730955] rcu_scheduler_active = 2, debug_locks = 1
> [ 160.762813] 5 locks held by rebind-eth.sh/1812:
> [ 160.766851] #0: 000000008befa37a (sb_writers#6){.+.+}, at:
> vfs_write+0x184/0x1b0
> [ 160.773416] #1: 00000000b097f236 (&of->mutex){+.+.}, at:
> kernfs_fop_write+0xe2/0x1a0
> [ 160.783766] #2: 0000000041ee6889 (kn->count#3){++++}, at:
> kernfs_fop_write+0xeb/0x1a0
> [ 160.787465] #3: 0000000056d92a74 (&dev->mutex){....}, at:
> device_release_driver_internal+0x39/0x250
> [ 160.816987] #4: 0000000030f6031e (rcu_read_lock){....}, at:
> netvsc_remove+0x1e/0x250 [hv_netvsc]
> [ 160.828629]
> [ 160.828629] stack backtrace:
> [ 160.831966] CPU: 1 PID: 1812 Comm: rebind-eth.sh Not tainted 4.19.0-rc3-
> uio+ #2
> [ 160.832952] Hardware name: Microsoft Corporation Virtual Machine/Virtual
> Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
> [ 160.832952] Call Trace:
> [ 160.832952] dump_stack+0x85/0xcb
> [ 160.832952] ___might_sleep+0x1a3/0x240
> [ 160.832952] __flush_work+0x57/0x2e0
> [ 160.832952] ? __mutex_lock+0x83/0x990
> [ 160.832952] ? __kernfs_remove+0x24f/0x2e0
> [ 160.832952] ? __kernfs_remove+0x1b2/0x2e0
> [ 160.832952] ? mark_held_locks+0x50/0x80
> [ 160.832952] ? get_work_pool+0x90/0x90
> [ 160.832952] __cancel_work_timer+0x13c/0x1e0
> [ 160.832952] ? netvsc_remove+0x1e/0x250 [hv_netvsc]
> [ 160.832952] ? __lock_is_held+0x55/0x90
> [ 160.832952] netvsc_remove+0x9a/0x250 [hv_netvsc]
> [ 160.832952] vmbus_remove+0x26/0x30
> [ 160.832952] device_release_driver_internal+0x18a/0x250
> [ 160.832952] unbind_store+0xb4/0x180
> [ 160.832952] kernfs_fop_write+0x113/0x1a0
> [ 160.832952] __vfs_write+0x36/0x1a0
> [ 160.832952] ? rcu_read_lock_sched_held+0x6b/0x80
> [ 160.832952] ? rcu_sync_lockdep_assert+0x2e/0x60
> [ 160.832952] ? __sb_start_write+0x141/0x1a0
> [ 160.832952] ? vfs_write+0x184/0x1b0
> [ 160.832952] vfs_write+0xbe/0x1b0
> [ 160.832952] ksys_write+0x55/0xc0
> [ 160.832952] do_syscall_64+0x60/0x1b0
> [ 160.832952] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 160.832952] RIP: 0033:0x7fe48f4c8154
>
> Resolve this by getting RTNL earlier. This is safe because the subchannel
> work queue does trylock on RTNL and will detect the race.
>
> Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Thank you!
^ permalink raw reply
* Re: [net-next, PATCH 2/2, v2] net: socionext: add XDP support
From: Ilias Apalodimas @ 2018-09-13 15:36 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, jaswinder.singh, ard.biesheuvel, masami.hiramatsu, arnd,
mykyta.iziumtsev, bjorn.topel, magnus.karlsson, daniel, ast
In-Reply-To: <20180913163206.4feed505@redhat.com>
On Thu, Sep 13, 2018 at 04:32:06PM +0200, Jesper Dangaard Brouer wrote:
> On Wed, 12 Sep 2018 12:29:15 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>
> > On Wed, Sep 12, 2018 at 11:25:24AM +0200, Jesper Dangaard Brouer wrote:
> > > On Wed, 12 Sep 2018 12:02:38 +0300
> > > Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> > >
> > > > static const struct net_device_ops netsec_netdev_ops = {
> > > > .ndo_init = netsec_netdev_init,
> > > > .ndo_uninit = netsec_netdev_uninit,
> > > > @@ -1430,6 +1627,7 @@ static const struct net_device_ops netsec_netdev_ops = {
> > > > .ndo_set_mac_address = eth_mac_addr,
> > > > .ndo_validate_addr = eth_validate_addr,
> > > > .ndo_do_ioctl = netsec_netdev_ioctl,
> > > > + .ndo_bpf = netsec_xdp,
> > > > };
> > > >
> > >
> > > You have not implemented ndo_xdp_xmit.
> > >
> > > Thus, you have "only" implemented the RX side of XDP_REDIRECT. Which
> > > allows you to do, cpumap and AF_XDP redirects, but not allowing other
> > > drivers to XDP send out this device.
> >
> > Correct, that was the planning, is ndo_xdp_xmit() needed for the patch or
> > is the patch message just misleading and i should change that ?
>
> Yes, I think you should ALSO implement ndo_xdp_xmit, maybe as a separate
> patch, but in the same series. (Our experience is that if we don't
> require this, people forget to complete this part of the XDP support).
Ok makes sense. Already started on that i should have something soon
>
> Also you XDP_TX is not optimal, as it (looks like) you flush TX on
> every send.
Yes i do, the driver is queueing packet by packet (in it's default skb
implemetation) so i just did the same. Agree it's far from optimal though
i'll see if i can change than on the next version
>
> BTW, do you have any performance numbers?
Yes XDP_TX is doing ~330kpps and XDP_REDIRECT ~340kpps(dropping packets)
using 64b packets. I am not really sure if this is a hardware limitation
due to only using a single queue. I used ./samples/bpf/xdpsock for AF_XDP
and ./samples/bpf/xdp2 for XDP_TX. I hope i am doing the right tests
The default Rx path is doing ~220kpps with the improved memory allocation
scheme so we do have some improvement although we are far away from line
rate
The default Tx seems to hang after some point with a txq full message so
i don't have any precice numbers for that
This change on the driver started as an investigation of using AF_XDP
for Time Sensitive networking setups. The offloading seems to work wonders
there since the latency is reduced *A LOT* (more than 10x in my case) in
Rx path
Another thing i did consider is that Bjorn is right. Since i only have 1
shared txq i need locking to avoid race conditions.
Once again thanks for reviewing this
/Ilias
^ permalink raw reply
* Re: [PATCH v4 3/3] IB/ipoib: Log sysfs 'dev_id' accesses from userspace
From: Doug Ledford @ 2018-09-13 15:45 UTC (permalink / raw)
To: Arseny Maslennikov, Jason Gunthorpe; +Cc: linux-rdma, netdev
In-Reply-To: <20180909205512.GA5918@cello.Dlink>
[-- Attachment #1: Type: text/plain, Size: 3657 bytes --]
On Sun, 2018-09-09 at 23:55 +0300, Arseny Maslennikov wrote:
> On Sun, Sep 09, 2018 at 09:11:46PM +0300, Arseny Maslennikov wrote:
> > On Fri, Sep 07, 2018 at 09:43:59AM -0600, Jason Gunthorpe wrote:
> > > On Thu, Sep 06, 2018 at 05:51:12PM +0300, Arseny Maslennikov wrote:
> > > > Some tools may currently be using only the deprecated attribute;
> > > > let's print an elaborate and clear deprecation notice to kmsg.
> > > >
> > > > To do that, we have to replace the whole sysfs file, since we inherit
> > > > the original one from netdev.
> > > >
> > > > Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> > > > drivers/infiniband/ulp/ipoib/ipoib_main.c | 31 +++++++++++++++++++++++
> > > > 1 file changed, 31 insertions(+)
> > > >
> > > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > index 30f840f874b3..74732726ec6f 100644
> > > > +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > @@ -2386,6 +2386,35 @@ int ipoib_add_pkey_attr(struct net_device *dev)
> > > > return device_create_file(&dev->dev, &dev_attr_pkey);
> > > > }
> > > >
> > > > +/*
> > > > + * We erroneously exposed the iface's port number in the dev_id
> > > > + * sysfs field long after dev_port was introduced for that purpose[1],
> > > > + * and we need to stop everyone from relying on that.
> > > > + * Let's overload the shower routine for the dev_id file here
> > > > + * to gently bring the issue up.
> > > > + *
> > > > + * [1] https://www.spinics.net/lists/netdev/msg272123.html
> > > > + */
> > > > +static ssize_t dev_id_show(struct device *dev,
> > > > + struct device_attribute *attr, char *buf)
> > > > +{
> > > > + struct net_device *ndev = to_net_dev(dev);
> > > > +
> > > > + if (ndev->dev_id == ndev->dev_port)
> > > > + netdev_info_once(ndev,
> > > > + "\"%s\" wants to know my dev_id. Should it look at dev_port instead? See Documentation/ABI/testing/sysfs-class-net for more info.\n",
> > > > + current->comm);
> > > > +
> > > > + return sprintf(buf, "%#x\n", ndev->dev_id);
> > > > +}
> > > > +static DEVICE_ATTR_RO(dev_id);
> > > > +
> > > > +int ipoib_intercept_dev_id_attr(struct net_device *dev)
> > > > +{
> > > > + device_remove_file(&dev->dev, &dev_attr_dev_id);
> > > > + return device_create_file(&dev->dev, &dev_attr_dev_id);
> > > > +}
> > >
> > > Isn't this racey with userspace? Ie what happens if udev is querying
> > > the dev_id right here?
> >
> > udev in particular does not use dev_id at all since 2014, because "why
> > would we keep using dev_id if it is not the right thing to use?".
> >
> > >
> > > Do we know there is no userspace doing this?
> > >
> >
> > Not for sure.
> >
> > If we move all the sysfs handling stuff we introduce in _add_port():
> > - pkey
> > - umcast
> > - {create,delete}_child
> > - connected/datagram mode
> > to _ndo_init(), which is called by register_netdev before it sends
> > the netlink message, would that suffice to eliminate the race?
> > (Sysfs files for {create,delete}_child go to _parent_init() then).
> >
>
> No, we can't, sorry for the noise. ndo_init() runs before the kobject
> becomes available.
>
> Anyway, our sysfs attributes being racy is unrelated to the patch series
> subject, and I can't come up with any other ideas what to do with them
> that do not involve adjustments to register_netdev.
Agreed (that fixing the race issues is a different patch series).
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Subject: [PATCH] rtl_bt: Add firmware and configuration files for the Bluetooth part of RTL8822CU
From: Josh Boyer @ 2018-09-13 15:48 UTC (permalink / raw)
To: Larry Finger
Cc: Linux Firmware, Linux Wireless, netdev, 陆朱伟
In-Reply-To: <20180905155146.28556-1-Larry.Finger@lwfinger.net>
On Wed, Sep 5, 2018 at 11:52 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> These devices are new models from Realtek. Updates to driver btrtl will
> soon be submitted to the kernel.
>
> These files were provided by the Realtek developer.
>
> Signed-off-by: 陆朱伟 <alex_lu@realsil.com.cn>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> WHENCE | 2 ++
> rtl_bt/rtl8822cu_fw.bin | Bin 0 -> 22412 bytes
> 2 files changed, 2 insertions(+)
> create mode 100644 rtl_bt/rtl8822cu_fw.bin
>
Applied (with fixed Subject), and pushed out.
josh
^ permalink raw reply
* Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels
From: Florian Westphal @ 2018-09-13 21:03 UTC (permalink / raw)
To: David Miller
Cc: fw, linux, netdev, steffen.klassert, linux-kernel, torvalds,
christophe.gouault
In-Reply-To: <20180913.102305.939671149040995911.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Thu, 13 Sep 2018 18:38:48 +0200
>
> > Wolfgang Walter <linux@stwm.de> wrote:
> >> What I can say is that it depends mainly on number of policy rules and SA.
> >
> > Thats already a good hint, I guess we're hitting long hash chains in
> > xfrm_policy_lookup_bytype().
>
> I don't really see how recent changes can influence that.
I don't think there is a recent change that did this.
Walter says < 4.14 is ok, so this is likely related to flow cache removal.
F.e. it looks like all prefixed policies end up in a linked list
(net->xfrm.policy_inexact) and are not even in a hash table.
I am staring at b58555f1767c9f4e330fcf168e4e753d2d9196e0
but can't figure out how to configure that away from the
'no hashing for prefixed policies' default or why we even have
policy_inexact in first place :/
I'll look at this again tomorrow.
^ permalink raw reply
* Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels
From: David Miller @ 2018-09-13 21:12 UTC (permalink / raw)
To: fw
Cc: linux, netdev, steffen.klassert, linux-kernel, torvalds,
christophe.gouault
In-Reply-To: <20180913210325.5usfj2rorvuvtyc7@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 13 Sep 2018 23:03:25 +0200
> I am staring at b58555f1767c9f4e330fcf168e4e753d2d9196e0
> but can't figure out how to configure that away from the
> 'no hashing for prefixed policies' default or why we even have
> policy_inexact in first place :/
>
> I'll look at this again tomorrow.
The inexact list exists to handle prefixed input keys.
At the time that I wrote all of the control plane hash table
stuff, configurations I could find consisted of:
1) Entires with non-prefixed keys, which are easy to hash.
The number of entries could be large (e.g. cell phone
network)
2) A very small number of prefixed policies.
So hashing, when possible, falling back to the linked list
for prefixed stuff.
Beforehand we only had the linked list :-)
^ permalink raw reply
* Re: [PATCH 2/2] netlink: add ethernet address policy types
From: Michal Kubecek @ 2018-09-13 16:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev
In-Reply-To: <1536842777.4160.9.camel@sipsolutions.net>
On Thu, Sep 13, 2018 at 02:46:17PM +0200, Johannes Berg wrote:
> On Thu, 2018-09-13 at 14:24 +0200, Michal Kubecek wrote:
> > On Thu, Sep 13, 2018 at 02:16:06PM +0200, Johannes Berg wrote:
> > > On Thu, 2018-09-13 at 14:12 +0200, Michal Kubecek wrote:
> > > > Maybe rather
> > > >
> > > > #define NLA_ETH_ADDR NLA_BINARY_EXACT, .len = ETH_ALEN
> > > > #define NLA_IP6_ADDR NLA_BINARY_EXACT, .len = sizeof(struct in6_addr)
> > > >
> > > > so that one could write
> > > >
> > > > { .type = NLA_ETH_ADDR }
> > >
> > > Yeah, that's possible. I considered it for a second, but it was slightly
> > > too magical for my taste :-)
> > >
> > > Better pick a different "namespace", perhaps NLA_POLICY_ETH_ADDR or so?
> >
> > Right, that sounds better. I'm afraid anything too tricky would
> > inevitably trick people into using it in an unexpected way and ending up
> > with very confusing error messages.
>
> Right.
>
> Then again though, we already have NLA_MSECS which is basically
> equivalent to NLA_U64 afaict, so why not have more types?
>
> It doesn't really cost us that much, just a few bytes in the validation?
And one more branch in the switch in validate_nla().
I'm not really opposed to having special policy types for MAC/IPv4/IPv6
address, these types are quite common, at least in networking code which
is where netlink is used most oftena. I rather felt that technically the
only difference between MAC and IPv6 address is the size and as we have
.len already, it would be more useful to have generic policy allowing to
also handle other fixes size data types.
On the other hand, if there was a trend of adding special policies for
more "endemic" data types, it might be more appropriate to introduce
a generic policy where validation_data would be a "validator function"
doing specific checks (probably using a union to allow type check of the
callback). But that's not happening (yet).
> Also, with .type = NLA_ETH_ADDR_COMPAT we could get a warning, which is
> not true for just checking .len.
We could have three flavors of NLA_BINARY.
Michal Kubecek
^ permalink raw reply
* Re: [Patch net-next] llc: avoid blocking in llc_sap_close()
From: David Miller @ 2018-09-13 16:05 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <20180911184206.8461-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 11 Sep 2018 11:42:06 -0700
> llc_sap_close() is called by llc_sap_put() which
> could be called in BH context in llc_rcv(). We can't
> block in BH.
>
> There is no reason to block it here, kfree_rcu() should
> be sufficient.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks Cong.
^ permalink raw reply
* Re: [Patch net] net_sched: notify filter deletion when deleting a chain
From: David Miller @ 2018-09-13 16:08 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jiri
In-Reply-To: <20180911212223.11613-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 11 Sep 2018 14:22:23 -0700
> When we delete a chain of filters, we need to notify
> user-space we are deleting each filters in this chain
> too.
>
> Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi")
> Cc: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks Cong.
^ permalink raw reply
* What is the best forum (mailing list, irc etc) to ask questions about the usage of AF_XDP sockets.
From: Konrad Djimeli @ 2018-09-13 16:31 UTC (permalink / raw)
To: netdev; +Cc: bjorn.topel, jakub.kicinski
Hello,
I have been working on trying to make use of AF_XDP sockets as part of a
project I working on, and I have been facing some issues but I am not
sure where to ask questions related to the usage of AF_XDP, since this
is a development mailing list.
Thanks
Konrad
www.djimeli.me
^ permalink raw reply
* Re: [PATCH v4 0/3] IB/ipoib: Use dev_port to disambiguate port numbers
From: Doug Ledford @ 2018-09-13 16:50 UTC (permalink / raw)
To: Arseny Maslennikov, linux-rdma; +Cc: Jason Gunthorpe, netdev
In-Reply-To: <20180906145112.29245-1-ar@cs.msu.ru>
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
On Thu, 2018-09-06 at 17:51 +0300, Arseny Maslennikov wrote:
> Pre-3.15 userspace had trouble distinguishing different ports
> of a NIC on a single PCI bus/device/function. To solve this,
> a sysfs field `dev_port' was introduced quite a while ago
> (commit v3.14-rc3-739-g3f85944fe207), and some relevant device
> drivers were fixed to use it, but not in case of IPoIB.
>
> The convention for some reason never got documented in the kernel, but
> was immediately adopted by userspace (notably udev[1][2], biosdevname[3])
>
> 1/3 documents the sysfs field — that's why I'm CC-ing netdev.
>
> This series was tested on and applies to 4.19-rc2.
>
> [1] https://lists.freedesktop.org/archives/systemd-devel/2014-June/020788.html
> [2] https://lists.freedesktop.org/archives/systemd-devel/2014-July/020804.html
> [3] https://github.com/CloudAutomationNTools/biosdevname/blob/c795d51dd93a5309652f0d635f12a3ecfabfaa72/src/eths.c#L38
>
> v1->v2: replace a line instead of inserting and then removing.
> v2->v3: restore both attributes, output a notice of deprecation to kmsg.
> v3->v4: style adjustments, join the deprecation notice to single line.
>
> Arseny Maslennikov (3):
> Documentation/ABI: document /sys/class/net/*/dev_port
> IB/ipoib: Use dev_port to expose network interface port numbers
> IB/ipoib: Log sysfs 'dev_id' accesses from userspace
>
> Documentation/ABI/testing/sysfs-class-net | 18 +++++++++++++
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 33 +++++++++++++++++++++++
> 2 files changed, 51 insertions(+)
>
Series applied to for-next. But I think we should watch feedback from
people, and if people think the notification about using the wrong
variable is too noisy, then we might want to revert it or modify it to
only print out once per specific executable instead of once per run of
each executable.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: What is the best forum (mailing list, irc etc) to ask questions about the usage of AF_XDP sockets.
From: Jakub Kicinski @ 2018-09-13 16:52 UTC (permalink / raw)
To: Konrad Djimeli; +Cc: netdev, bjorn.topel
In-Reply-To: <9ec1520651dddbd4723bf44bf820dbbc@igalia.com>
On Thu, 13 Sep 2018 18:31:55 +0200, Konrad Djimeli wrote:
> Hello,
>
> I have been working on trying to make use of AF_XDP sockets as part of a
> project I working on, and I have been facing some issues but I am not
> sure where to ask questions related to the usage of AF_XDP, since this
> is a development mailing list.
IMHO AF_XDP is quite fresh so it should be okay to ask questions on
netdev. There is also xdp-newbies mailing list which seems very
appropriate for less advanced questions!
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] netlink: ipv4 igmp join notifications
From: Roopa Prabhu @ 2018-09-13 17:03 UTC (permalink / raw)
To: Patrick Ruddy
Cc: netdev, Jiří Pírko, Stephen Hemminger,
Nikolay Aleksandrov
In-Reply-To: <CAJieiUgopvmN5VVntPwffP5YmVZGFsWJvafSSXj83DVBVA61uQ@mail.gmail.com>
On Thu, Sep 6, 2018 at 8:40 PM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On Thu, Sep 6, 2018 at 2:10 AM, Patrick Ruddy
> <pruddy@vyatta.att-mail.com> wrote:
>> Some userspace applications need to know about IGMP joins from the
>> kernel for 2 reasons:
>> 1. To allow the programming of multicast MAC filters in hardware
>> 2. To form a multicast FORUS list for non link-local multicast
>> groups to be sent to the kernel and from there to the interested
>> party.
>> (1) can be fulfilled but simply sending the hardware multicast MAC
>> address to be programmed but (2) requires the L3 address to be sent
>> since this cannot be constructed from the MAC address whereas the
>> reverse translation is a standard library function.
>>
>> This commit provides addition and deletion of multicast addresses
>> using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET. It also
>> provides the RTM_GETMDB extension to allow multicast join state to
>> be read from the kernel.
>>
>> Signed-off-by: Patrick Ruddy <pruddy@vyatta.att-mail.com>
>> ---
>> v3 rework to use RTM_***MDB messages as per review comments.
>
> Patrick, this version seems to be using RTM_***MDB msgs with the
> RTM_*ADDR format.
> We cant do that...because existing RTM_MDB users will be confused.
>
> My request was to evaluate RTM_***MDB msg format. see
> nlmsg_populate_mdb_fill for details.
>
> If you can wait a day or two I can share some experimental code that
> moves high level RTM_*MDB msg handling into net/core/rtnetlink.c
> similar to RTM_*FDB
>
I was trying to get a default per interface (non bridge) RTM_*MDB
working, but realized that the dev->mc
entries are already getting dumped as part of RTM_*FDB msgs instead of
RTM_*MDB. (see net/core/rtnetlink.c:ndo_dflt_fdb_dump).
This adds another wrench.
so, that puts us back to your use of RTM_NEWADDR.
Instead of using IFA_ADDRESS, you could introduce a new one
IFA_IGMP_MULTICAST (since IFA_MULTICAST is already taken).
To keep existing users of RTM_NEWADDR unaffected. I think you can use
the IPMR family with RTM_NEWADDR.
We can introduce new notification group. (We can choose to add a new
family too, but that seems unnecessary)
since you only need dumps:
rtnl_register(RTNL_FAMILY_IPMR, RTM_GETADDR, NULL, igmp_rtm_dumpaddrs, 0);
For notifications, since we already have many variants for routes, I
don't see a problem adding similar addr variants
RTNLGRP_IPV4_MCADDR
(Others on the list may have more feedback).
^ permalink raw reply
* Re: [PATCH net-next v2] net: sched: change tcf_del_walker() to take idrinfo->lock
From: Cong Wang @ 2018-09-13 17:13 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <vbfefdzm74n.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Wed, Sep 12, 2018 at 1:51 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Fri 07 Sep 2018 at 19:12, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Fri, Sep 7, 2018 at 6:52 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> >>
> >> Action API was changed to work with actions and action_idr in concurrency
> >> safe manner, however tcf_del_walker() still uses actions without taking a
> >> reference or idrinfo->lock first, and deletes them directly, disregarding
> >> possible concurrent delete.
> >>
> >> Add tc_action_wq workqueue to action API. Implement
> >> tcf_idr_release_unsafe() that assumes external synchronization by caller
> >> and delays blocking action cleanup part to tc_action_wq workqueue. Extend
> >> tcf_action_cleanup() with 'async' argument to indicate that function should
> >> free action asynchronously.
> >
> > Where exactly is blocking in tcf_action_cleanup()?
> >
> > From your code, it looks like free_tcf(), but from my observation,
> > the only blocking function inside is tcf_action_goto_chain_fini()
> > which calls __tcf_chain_put(). But, __tcf_chain_put() is blocking
> > _ONLY_ when tc_chain_notify() is called, for tc action it is never
> > called.
> >
> > So, what else is blocking?
>
> __tcf_chain_put() calls tc_chain_tmplt_del(), which calls
> ops->tmplt_destroy(). This last function uses hw offload API, which is
> blocking.
Good to know.
Can we just make ops->tmplt_destroy() to use workqueue?
Making tc action to workqueue seems overkill, for me.
^ permalink raw reply
* Re: [PATCH net-next 08/13] net: sched: rename tcf_block_get{_ext}() and tcf_block_put{_ext}()
From: Cong Wang @ 2018-09-13 17:21 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Stephen Hemminger, Kirill Tkhai, Paul E. McKenney,
Nicolas Dichtel, Leon Romanovsky, Greg KH, mark.rutland,
Florian Westphal, David Ahern, lucien xin, Jakub Kicinski,
Christian Brauner, Jiri Benc
In-Reply-To: <vbfin3bm8ch.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Wed, Sep 12, 2018 at 1:24 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Fri 07 Sep 2018 at 20:09, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Thu, Sep 6, 2018 at 12:59 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> >>
> >> Functions tcf_block_get{_ext}() and tcf_block_put{_ext}() actually
> >> attach/detach block to specific Qdisc besides just taking/putting
> >> reference. Rename them according to their purpose.
> >
> > Where exactly does it attach to?
> >
> > Each qdisc provides a pointer to a pointer of a block, like
> > &cl->block. It is where the result is saved to. It takes a parameter
> > of Qdisc* merely for read-only purpose.
>
> tcf_block_attach_ext() passes qdisc parameter to tcf_block_owner_add()
> which saves qdisc to new tcf_block_owner_item and adds the item to
> block's owner list. I proposed several naming options for these
> functions to Jiri on internal review and he suggested "attach" as better
> option.
But that is merely item->q = q, this is why I said it is read-only,
hard to claim this is attaching.
>
> >
> > So, renaming it to *attach() is even confusing, at least not
> > any better. Please find other names or leave them as they are.
>
> What would you recommend?
I don't know, perhaps "acquire"?
Or, leaving tcf_block_get() as it is but rename your refcnt
increment function to be something like tcf_block_refcnt_get()?
^ permalink raw reply
* Re: [PATCH net-next] tg3: Fix fall-through annotations
From: David Miller @ 2018-09-13 22:37 UTC (permalink / raw)
To: gustavo; +Cc: siva.kallam, prashant, mchan, netdev, linux-kernel
In-Reply-To: <20180913183922.GA31390@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 13 Sep 2018 13:39:22 -0500
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] pktgen: Fix fall-through annotation
From: David Miller @ 2018-09-13 22:37 UTC (permalink / raw)
To: gustavo; +Cc: netdev, linux-kernel
In-Reply-To: <20180913190320.GA9551@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 13 Sep 2018 14:03:20 -0500
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* [PATCH net-next 0/2] net/sched: act_police: lockless data path
From: Davide Caratti @ 2018-09-13 17:29 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller; +Cc: netdev
the data path of 'police' action can be faster if we avoid using spinlocks:
- patch 1 converts act_police to use per-cpu counters
- patch 2 lets act_police use RCU to access its configuration data.
test procedure (using pktgen from https://github.com/netoptimizer):
# ip link add name eth1 type dummy
# ip link set dev eth1 up
# tc qdisc add dev eth1 clsact
# tc filter add dev eth1 egress matchall action police \
> rate 2gbit burst 100k conform-exceed pass/pass index 100
# for c in 1 2 4; do
> ./pktgen_bench_xmit_mode_queue_xmit.sh -v -s 64 -t $c -n 5000000 -i eth1
> done
test results (avg. pps/thread):
$c | before patch | after patch | improvement
----+--------------+--------------+-------------
1 | 3518448 | 3591240 | irrelevant
2 | 3070065 | 3383393 | 10%
4 | 1540969 | 3238385 | 110%
Davide Caratti (2):
net/sched: act_police: use per-cpu counters
net/sched: act_police: don't use spinlock in the data path
net/sched/act_police.c | 186 +++++++++++++++++++++++------------------
1 file changed, 106 insertions(+), 80 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next 1/2] net/sched: act_police: use per-cpu counters
From: Davide Caratti @ 2018-09-13 17:29 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1536852493.git.dcaratti@redhat.com>
use per-CPU counters, instead of sharing a single set of stats with all
cores. This removes the need of using spinlock when statistics are read
or updated.
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_police.c | 46 ++++++++++++++++++++----------------------
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index 393c7a670300..965a48d3ec35 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -110,7 +110,7 @@ static int tcf_police_init(struct net *net, struct nlattr *nla,
if (!exists) {
ret = tcf_idr_create(tn, parm->index, NULL, a,
- &act_police_ops, bind, false);
+ &act_police_ops, bind, true);
if (ret) {
tcf_idr_cleanup(tn, parm->index);
return ret;
@@ -137,7 +137,8 @@ static int tcf_police_init(struct net *net, struct nlattr *nla,
}
if (est) {
- err = gen_replace_estimator(&police->tcf_bstats, NULL,
+ err = gen_replace_estimator(&police->tcf_bstats,
+ police->common.cpu_bstats,
&police->tcf_rate_est,
&police->tcf_lock,
NULL, est);
@@ -207,32 +208,27 @@ static int tcf_police_act(struct sk_buff *skb, const struct tc_action *a,
struct tcf_result *res)
{
struct tcf_police *police = to_police(a);
- s64 now;
- s64 toks;
- s64 ptoks = 0;
+ s64 now, toks, ptoks = 0;
+ int ret;
- spin_lock(&police->tcf_lock);
-
- bstats_update(&police->tcf_bstats, skb);
tcf_lastuse_update(&police->tcf_tm);
+ bstats_cpu_update(this_cpu_ptr(police->common.cpu_bstats), skb);
+ spin_lock(&police->tcf_lock);
if (police->tcfp_ewma_rate) {
struct gnet_stats_rate_est64 sample;
if (!gen_estimator_read(&police->tcf_rate_est, &sample) ||
sample.bps >= police->tcfp_ewma_rate) {
- police->tcf_qstats.overlimits++;
- if (police->tcf_action == TC_ACT_SHOT)
- police->tcf_qstats.drops++;
- spin_unlock(&police->tcf_lock);
- return police->tcf_action;
+ ret = police->tcf_action;
+ goto inc_overlimits;
}
}
if (qdisc_pkt_len(skb) <= police->tcfp_mtu) {
if (!police->rate_present) {
- spin_unlock(&police->tcf_lock);
- return police->tcfp_result;
+ ret = police->tcfp_result;
+ goto unlock;
}
now = ktime_get_ns();
@@ -253,18 +249,20 @@ static int tcf_police_act(struct sk_buff *skb, const struct tc_action *a,
police->tcfp_t_c = now;
police->tcfp_toks = toks;
police->tcfp_ptoks = ptoks;
- if (police->tcfp_result == TC_ACT_SHOT)
- police->tcf_qstats.drops++;
- spin_unlock(&police->tcf_lock);
- return police->tcfp_result;
+ ret = police->tcfp_result;
+ goto inc_drops;
}
}
-
- police->tcf_qstats.overlimits++;
- if (police->tcf_action == TC_ACT_SHOT)
- police->tcf_qstats.drops++;
+ ret = police->tcf_action;
+
+inc_overlimits:
+ qstats_overlimit_inc(this_cpu_ptr(police->common.cpu_qstats));
+inc_drops:
+ if (ret == TC_ACT_SHOT)
+ qstats_drop_inc(this_cpu_ptr(police->common.cpu_qstats));
+unlock:
spin_unlock(&police->tcf_lock);
- return police->tcf_action;
+ return ret;
}
static int tcf_police_dump(struct sk_buff *skb, struct tc_action *a,
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox