* Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
From: David Ahern @ 2018-03-24 15:28 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <20180324150516.GA8940@splinter>
On 3/24/18 9:05 AM, Ido Schimmel wrote:
> On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote:
>> This set is the first of many changes to improve the scalability of the
>> IPv6 code. Follow on changes include:
>> - consolidating duplicate fib6_info references like IPv4 does with
>> duplicate fib_info
>
> Before that you need to further break fib6_info into fib6_info and
> fib6_alias, or I misunderstood you?
>
I was only listing the high level intent - to consolidate duplication. I
have not looked into that step yet, but I suspect that split can be done
in the same patch set as consolidating duplicate fib6_info.
As you know, my preference is to move to nexthop objects (makes fib6_nh
optional). I have IPv4 done; IPv6 requires this patch set. To get there
the patch sequence is:
1. separate data structures for fib and dst paths (this set),
2. cleanup set on top of this one (separate set only because this one is
at 21 patches), and
3. nexthop API.
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 19/21] net/ipv6: separate handling of FIB entries from dst based routes
From: David Ahern @ 2018-03-24 15:31 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <20180324143100.GA19895@splinter>
On 3/24/18 8:31 AM, Ido Schimmel wrote:
> On Sun, Mar 18, 2018 at 08:36:20PM -0700, David Ahern wrote:
>> @@ -405,18 +383,9 @@ static void ip6_dst_destroy(struct dst_entry *dst)
>> rt->rt6i_idev = NULL;
>> in6_dev_put(idev);
>> }
>> - bucket = rcu_dereference_protected(rt->rt6i_exception_bucket, 1);
>> - if (bucket) {
>> - rt->rt6i_exception_bucket = NULL;
>> - kfree(bucket);
>> - }
>> -
>> - m = rt->fib6_metrics;
>> - if (m != &dst_default_metrics && refcount_dec_and_test(&m->refcnt))
>> - kfree(m);
>
> You remove this...
>
>>
>> rt->from = NULL;
>> - dst_release(&from->dst);
>> + fib6_info_release(from);
>
> Yet fib6_info_release() doesn't take care of it (unlike the IPv4
> equivalent), which means you're leaking the metrics.
>
>> }
ok, I'll take a look. I thought I verified both paths (fib6_info and
dst) were freeing the metrics.
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
From: Ido Schimmel @ 2018-03-24 15:59 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <aee428c3-9c13-3cb8-0c3f-c69a7345e562@gmail.com>
On Sat, Mar 24, 2018 at 09:28:01AM -0600, David Ahern wrote:
> On 3/24/18 9:05 AM, Ido Schimmel wrote:
> > On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote:
> >> This set is the first of many changes to improve the scalability of the
> >> IPv6 code. Follow on changes include:
> >> - consolidating duplicate fib6_info references like IPv4 does with
> >> duplicate fib_info
> >
> > Before that you need to further break fib6_info into fib6_info and
> > fib6_alias, or I misunderstood you?
> >
>
> I was only listing the high level intent - to consolidate duplication. I
> have not looked into that step yet, but I suspect that split can be done
> in the same patch set as consolidating duplicate fib6_info.
I don't think you can perform consolidation of fib6_info as long as it
describes both the route and the nexthop info.
> As you know, my preference is to move to nexthop objects (makes fib6_nh
> optional). I have IPv4 done; IPv6 requires this patch set.
After going over your presentation [1] I was under the impression that
the fib6_info will be optional, not fib6_nh: "Idea is similar to adding
id to fib_info that is exposed to userspace. Subsequent routes pass id
to avoid fib_info overhead".
But I think misunderstood you. You want to introduce the nexthop API
that will allow you to have multiple fib6_info pointing to the same
fib6_nh?
1. http://vger.kernel.org/netconf2017_files/nexthop-objects.pdf
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 19/21] net/ipv6: separate handling of FIB entries from dst based routes
From: Ido Schimmel @ 2018-03-24 16:02 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <b5912ae8-0495-3df9-177d-ddd83d5248aa@gmail.com>
On Sat, Mar 24, 2018 at 09:31:02AM -0600, David Ahern wrote:
> On 3/24/18 8:31 AM, Ido Schimmel wrote:
> > On Sun, Mar 18, 2018 at 08:36:20PM -0700, David Ahern wrote:
> >> @@ -405,18 +383,9 @@ static void ip6_dst_destroy(struct dst_entry *dst)
> >> rt->rt6i_idev = NULL;
> >> in6_dev_put(idev);
> >> }
> >> - bucket = rcu_dereference_protected(rt->rt6i_exception_bucket, 1);
> >> - if (bucket) {
> >> - rt->rt6i_exception_bucket = NULL;
> >> - kfree(bucket);
> >> - }
> >> -
> >> - m = rt->fib6_metrics;
> >> - if (m != &dst_default_metrics && refcount_dec_and_test(&m->refcnt))
> >> - kfree(m);
> >
> > You remove this...
> >
> >>
> >> rt->from = NULL;
> >> - dst_release(&from->dst);
> >> + fib6_info_release(from);
> >
> > Yet fib6_info_release() doesn't take care of it (unlike the IPv4
> > equivalent), which means you're leaking the metrics.
> >
> >> }
>
> ok, I'll take a look. I thought I verified both paths (fib6_info and
> dst) were freeing the metrics.
I get this from kmemleak (applied your patchset on top of fe2d55d295cf):
unreferenced object 0xffff88004e2c16c8 (size 96):
comm "systemd-network", pid 1255, jiffies 4295166424 (age 957.858s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
ip6_route_info_create (/net/ipv6/route.c:2849)
ip6_route_add (/net/ipv6/route.c:2975)
inet6_rtm_newroute (/net/ipv6/route.c:4357)
rtnetlink_rcv_msg (/net/core/rtnetlink.c:4643)
netlink_rcv_skb (/net/netlink/af_netlink.c:2445)
netlink_unicast (/net/netlink/af_netlink.c:1309 /net/netlink/af_netlink.c:1334)
netlink_sendmsg (/net/netlink/af_netlink.c:1897)
sock_sendmsg (/net/socket.c:630 /net/socket.c:639)
SYSC_sendto (/net/socket.c:1748)
do_syscall_64 (/arch/x86/entry/common.c:287)
entry_SYSCALL_64_after_hwframe (/arch/x86/entry/entry_64.S:239)
0xffffffffffffffff (/./include/asm-generic/sections.h:42)
^ permalink raw reply
* Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink
From: Jiri Pirko @ 2018-03-24 16:02 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
David Ahern
In-Reply-To: <2eadcfb9-6dd2-d533-7ae3-c9299a70a172@cumulusnetworks.com>
Sat, Mar 24, 2018 at 04:05:38PM CET, dsa@cumulusnetworks.com wrote:
>On 3/24/18 1:26 AM, Jiri Pirko wrote:
>> Fri, Mar 23, 2018 at 04:13:14PM CET, dsa@cumulusnetworks.com wrote:
>>> On 3/23/18 9:05 AM, Jiri Pirko wrote:
>>>> Fri, Mar 23, 2018 at 04:03:40PM CET, dsa@cumulusnetworks.com wrote:
>>>>> On 3/23/18 9:01 AM, Jiri Pirko wrote:
>>>>>> Fri, Mar 23, 2018 at 03:31:02PM CET, dsa@cumulusnetworks.com wrote:
>>>>>>> On 3/23/18 12:50 AM, Jiri Pirko wrote:
>>>>>>>>> +void nsim_devlink_setup(struct netdevsim *ns)
>>>>>>>>> +{
>>>>>>>>> + struct net *net = dev_net(ns->netdev);
>>>>>>>>> + bool *reg_devlink = net_generic(net, nsim_devlink_id);
>>>>>>>>> + struct devlink *devlink;
>>>>>>>>> + int err = -ENOMEM;
>>>>>>>>> +
>>>>>>>>> + /* only one device per namespace controls devlink */
>>>>>>>>> + if (!*reg_devlink) {
>>>>>>>>> + ns->devlink = NULL;
>>>>>>>>> + return;
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> + devlink = devlink_alloc(&nsim_devlink_ops, 0);
>>>>>>>>> + if (!devlink)
>>>>>>>>> + return;
>>>>>>>>> +
>>>>>>>>> + devlink_net_set(devlink, net);
>>>>>>>>> + err = devlink_register(devlink, &ns->dev);
>>>>>>>>
>>>>>>>> This reg_devlink construct looks odd. Why don't you leave the devlink
>>>>>>>> instance in init_ns?
>>>>>>>
>>>>>>> It is a per-network namespace resource controller. Since struct devlink
>>>>>>
>>>>>> Wait a second. What do you mean by "per-network namespace"? Devlink
>>>>>> instance is always associated with one physical device. Like an ASIC.
>>>>>>
>>>>>>
>>>>>>> has a net entry, the simplest design is to put it into the namespace of
>>>>>>> the controller. Without it, controlling resource sizes in namespace
>>>>>>> 'foobar' has to be done from init_net, which is just wrong.
>>>>>
>>>>> you need to look at how netdevsim creates a device per netdevice.
>>>>
>>>> That means one devlink instance for each netdevsim device, doesn't it?
>>>>
>>>
>>> yes.
>>
>> Still not sure how to handle namespaces in devlink. Originally, I
>> thought it would be okay to leave all devlink instances in init_ns.
>> Because what happens if you move netdev to another namespace? Should the
>> devlink move as well? What if you have multiple ports, each in different
>> namespace. Can user move devlink instance to another namespace? Etc.
>>
>
>The devlink instance is associated with a 'struct device' and those do
>not change namespaces AFAIK.
Yeah. But you put devlink instance into namespace according to struct
net_device. That is mismatch.
^ permalink raw reply
* Re: [PATCH] of_net: Implement of_get_nvmem_mac_address helper
From: Mike Looijmans @ 2018-03-24 16:03 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, devicetree, f.fainelli, robh+dt,
frowand.list
In-Reply-To: <20180323194259.GP24361@lunn.ch>
On 23-03-18 20:42, Andrew Lunn wrote:
>> Indeed. I'll add my settings as an example. Where should I put this
>> documentation, in the commit comment or somewhere in
>> Documents/devicetree/bindings?
>
> Documention/devicetree/bindings/net/ethernet.txt
Ok
>> It's what I intended to do, but there were two problems with that:
>> - of_get_mac_address() returns a pointer to constant data in memory, but the
>> nvmem functions return an allocated memory object that must be freed after
>> use. This changes the way the call is to be made.
>> - The nvmem functions need the "struct device" pointer as well, while
>> of_get_mac_address() only gets passed the DT node.
>
> Does of_nvmem_cell_get() help?
Yes, looking at the interface, it would.
--
Mike Looijmans
^ permalink raw reply
* Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation
From: Jiri Pirko @ 2018-03-24 16:04 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, davem, idosch, jakub.kicinski, mlxsw, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <20180324144002.GA31941@lunn.ch>
Sat, Mar 24, 2018 at 03:40:02PM CET, andrew@lunn.ch wrote:
>> >The hardware and mechanical engineer is free to wire switch ports to
>> >the front panel however they want. That is why we put the netdev name
>> >in device tree.
>>
>> Got it. Hmm, so I think that the port number can be made optional and
>> when it is present, it would be used to generate phys_port_name. If
>> not, perhaps devlink port index could be used instead.
>>
>> So iiuc, you don't really need phys_port_name in dsa, as it provides
>> misleading names, right? Why is it implemented then?
>
>Hi Jiri
>
>Isn't the same true for all devices? It is not just DSA devices where
>the hardware engineer is free to wire up the front panel however they
>want, it can happen for any device.
In mlxsw, driver queries the FW to get this info.
^ permalink raw reply
* Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation
From: Jiri Pirko @ 2018-03-24 16:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, netdev, davem, idosch, jakub.kicinski, mlxsw,
vivien.didelot, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <0B8BC202-9067-4D34-AC4F-79DC33B4E6F9@gmail.com>
Sat, Mar 24, 2018 at 03:35:09PM CET, f.fainelli@gmail.com wrote:
>On March 24, 2018 12:45:51 AM PDT, Jiri Pirko <jiri@resnulli.us> wrote:
>>Fri, Mar 23, 2018 at 04:24:12PM CET, andrew@lunn.ch wrote:
>>>On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote:
>>>> Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@lunn.ch wrote:
>>>> >> I tested this for mlxsw and nfp. I have no way to test this on
>>DSA hw,
>>>> >> I would really appretiate DSA guys to test this.
>>>> >
>>>> >Hi Jiri
>>>> >
>>>> >With the missing break added, i get:
>>>> >
>>>> >root@zii-devel-b:~# ./iproute2/devlink/devlink port
>>>> >mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0
>>>> >mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1
>>>> >mdio_bus/0.1:00/2: type eth netdev lan2 flavour physical number 2
>>>> >mdio_bus/0.1:00/3: type notset
>>>> >mdio_bus/0.1:00/4: type notset
>>>> >mdio_bus/0.1:00/5: type notset flavour dsa number 5
>>>> >mdio_bus/0.1:00/6: type notset flavour cpu number 6
>>>> >mdio_bus/0.2:00/0: type eth netdev lan3 flavour physical number 0
>>>> >mdio_bus/0.2:00/1: type eth netdev lan4 flavour physical number 1
>>>> >mdio_bus/0.2:00/2: type eth netdev lan5 flavour physical number 2
>>>> >mdio_bus/0.2:00/3: type notset
>>>> >mdio_bus/0.2:00/4: type notset
>>>> >mdio_bus/0.2:00/5: type notset flavour dsa number 5
>>>> >mdio_bus/0.2:00/6: type notset flavour dsa number 6
>>>> >mdio_bus/0.4:00/0: type eth netdev lan6 flavour physical number 0
>>>> >mdio_bus/0.4:00/1: type eth netdev lan7 flavour physical number 1
>>>> >mdio_bus/0.4:00/2: type eth netdev lan8 flavour physical number 2
>>>> >mdio_bus/0.4:00/3: type eth netdev optical3 flavour physical number
>>3
>>>> >mdio_bus/0.4:00/4: type eth netdev optical4 flavour physical number
>>4
>>>> >mdio_bus/0.4:00/5: type notset
>>>> >mdio_bus/0.4:00/6: type notset
>>>> >mdio_bus/0.4:00/7: type notset
>>>> >mdio_bus/0.4:00/8: type notset
>>>> >mdio_bus/0.4:00/9: type notset flavour dsa number 9
>>>
>>>> That is basically front panel number for physical ports.
>>>
>>>You cannot make that assumption. As you can see here, we have 3 ports
>>>with the number 0.
>>>
>>>Look at clearfog, armada-388-clearfog.dts. port 0=lan5, port 1=lan4
>>>port 2=lan3, port 3=lan2, port 4=lan1, port 5=cpu, port 6=lan6.
>>>
>>>The hardware and mechanical engineer is free to wire switch ports to
>>>the front panel however they want. That is why we put the netdev name
>>>in device tree.
>>
>>Got it. Hmm, so I think that the port number can be made optional and
>>when it is present, it would be used to generate phys_port_name. If
>>not, perhaps devlink port index could be used instead.
>>
>>So iiuc, you don't really need phys_port_name in dsa, as it provides
>>misleading names, right? Why is it implemented then?
>
>We do need phys_port_name because there are switch configuration operations, e.g: ethtool::rxnfc which take a port number and queue number as part of the action to redirect a packet for instance. There is no way to obtain this physical port number other than either knowing it and hard coding it (not great) or scanning the device tree and look for the "reg" property value. phys_port_name gets you that and it is easy for an application to scan /sys/class/net/ on startup to get to know that (and other stuff as well).
Hmm. That sounds like misuse of phys_port_name. The original purpose was
to provide names as they are actually written on the front panel.
>
>--
>Florian
^ permalink raw reply
* switchdev and dsa
From: Ran Shalit @ 2018-03-24 16:12 UTC (permalink / raw)
To: netdev
Hello,
I am new with switchdev and dsa.
I would please like to ask if configuring a device tree/board file
with a switch (for example marvell switch) will provide all ports
behins the switch as valid interface (ethX) ports in userspace
ifconfig command ?
Thank you,
ranran
^ permalink raw reply
* Re: [PATCH] of_net: Implement of_get_nvmem_mac_address helper
From: Mike Looijmans @ 2018-03-24 16:17 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: netdev, linux-kernel, devicetree, robh+dt, frowand.list
In-Reply-To: <886c94ef-e2c8-2afa-307d-1924c74c6dc0@gmail.com>
On 23-03-18 20:33, Florian Fainelli wrote:
> On 03/23/2018 12:20 PM, Mike Looijmans wrote:
>> On 23-3-2018 16:11, Andrew Lunn wrote:
>>> On Fri, Mar 23, 2018 at 03:24:34PM +0100, Mike Looijmans wrote:
>>>> It's common practice to store MAC addresses for network interfaces into
>>>> nvmem devices. However the code to actually do this in the kernel lacks,
>>>> so this patch adds of_get_nvmem_mac_address() for drivers to obtain the
>>>> address from an nvmem cell provider.
>>>>
>>>> This is particulary useful on devices where the ethernet interface
>>>> cannot
>>>> be configured by the bootloader, for example because it's in an FPGA.
>>>>
>>>> Tested by adapting the cadence macb driver to call this instead of
>>>> of_get_mac_address().
>>>
>>> Hi Mike
>>>
>>> Please can you document the device tree binding. I assume you are
>>> adding a nvmen-cells and nvmem-cell-names to the Ethernet node in
>>> device tree.
>>
>> Indeed. I'll add my settings as an example. Where should I put this
>> documentation, in the commit comment or somewhere in
>> Documents/devicetree/bindings?
>>
>>>> +/**
>>>> + * Search the device tree for a MAC address, by calling
>>>> of_get_mac_address
>>>> + * and if that doesn't provide an address, fetch it from an nvmem
>>>> provider
>>>> + * using the name 'mac-address'.
>>>> + * On success, copies the new address is into memory pointed to by
>>>> addr and
>>>> + * returns 0. Returns a negative error code otherwise.
>>>> + * @dev: Pointer to the device containing the device_node
>>>> + * @addr: Pointer to receive the MAC address using ether_addr_copy()
>>>> + */
>>>> +int of_get_nvmem_mac_address(struct device *dev, char *addr)
>>>> +{
>>>> + const char *mac;
>>>> + struct nvmem_cell *cell;
>>>> + size_t len;
>>>> + int ret;
>>>> +
>>>> + mac = of_get_mac_address(dev->of_node);
>>>> + if (mac) {
>>>> + ether_addr_copy(addr, mac);
>>>> + return 0;
>>>> + }
>>>
>>> Is there a need to add a new API? Could of_get_mac_address() be
>>> extended to look in NVMEM? The MAC driver does not care. It is saying,
>>> using OF get me a MAC address. One API seems sufficient, and would
>>> mean you don't need to change the MAC drivers.
>>
>> It's what I intended to do, but there were two problems with that:
>> - of_get_mac_address() returns a pointer to constant data in memory, but
>> the nvmem functions return an allocated memory object that must be freed
>> after use. This changes the way the call is to be made.
>
> Yeah...
>
>> - The nvmem functions need the "struct device" pointer as well, while
>> of_get_mac_address() only gets passed the DT node.
>
> Bummer, you can't assume there is always a struct device associated with
> a struct device_node. Also, bigger question is, how can we make this
> work, for e.g: ACPI systems and therefore use an abstract fw_node handle?
>
Andrew Lunn's suggestion of using "of_nvmem_cell_get()" should solve this.
>> One approach would be to deprecate the of_get_mac_address() interface
>> and migrate existing drivers to the of_get_nvmem_mac_address() interface.
>
> Humm maybe, but clearly making of_get_mac_address() look for a nvmem is
> less error prone and does not require people to opt-in for the new
> helper, that seems beneficial to me.
Totally agree. But I can't think of a way that doesn't change the
method's signature. At some point the allocated nvmem buffer must be freed.
A quick survey for the of_get_mac_address users learns that most of them
do a memcpy (or similar) right after it, so for these drivers the
"of_get_nvmem_mac_address" style signature that performs the memcpy (or
better, ether_addr_copy) is a better fit, e.g.:
int of_get_mac_address(struct device_node *np, void *addr)
--
Mike Looijmans
^ permalink raw reply
* RE: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path
From: Michael Kelley (EOSG) @ 2018-03-24 16:48 UTC (permalink / raw)
To: Haiyang Zhang, davem@davemloft.net, netdev@vger.kernel.org
Cc: KY Srinivasan, Stephen Hemminger, olaf@aepfle.de,
vkuznets@redhat.com, devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180322190114.25596-2-haiyangz@linuxonhyperv.com>
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org <linux-kernel-owner@vger.kernel.org> On Behalf
> Of Haiyang Zhang
> Sent: Thursday, March 22, 2018 12:01 PM
> To: davem@davemloft.net; netdev@vger.kernel.org
> Cc: Haiyang Zhang <haiyangz@microsoft.com>; KY Srinivasan <kys@microsoft.com>; Stephen
> Hemminger <sthemmin@microsoft.com>; olaf@aepfle.de; vkuznets@redhat.com;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path
>
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> As defined in hyperv_net.h, the NVSP_STAT_SUCCESS is one not zero.
> Some functions returns 0 when it actually means NVSP_STAT_SUCCESS.
> This patch fixes them.
>
> In netvsc_receive(), it puts the last RNDIS packet's receive status
> for all packets in a vmxferpage which may contain multiple RNDIS
> packets.
> This patch puts NVSP_STAT_FAIL in the receive completion if one of
> the packets in a vmxferpage fails.
This patch changes the status field that is being reported back to
the Hyper-V host in the receive completion message in
enq_receive_complete(). The current code reports 0 on success,
and with the patch, it will report 1 on success. So does this change
affect anything on the Hyper-V side? Or is Hyper-V just ignoring
the value? If this change doesn't have any impact on the
interactions with Hyper-V, perhaps it would be good to explain
why in the commit message.
Michael
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/net/hyperv/netvsc.c | 8 ++++++--
> drivers/net/hyperv/netvsc_drv.c | 2 +-
> drivers/net/hyperv/rndis_filter.c | 4 ++--
> 3 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index aa95e81af6e5..1ddb2c39b6e4 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -1098,12 +1098,16 @@ static int netvsc_receive(struct net_device *ndev,
> void *data = recv_buf
> + vmxferpage_packet->ranges[i].byte_offset;
> u32 buflen = vmxferpage_packet->ranges[i].byte_count;
> + int ret;
>
> trace_rndis_recv(ndev, q_idx, data);
>
> /* Pass it to the upper layer */
> - status = rndis_filter_receive(ndev, net_device,
> - channel, data, buflen);
> + ret = rndis_filter_receive(ndev, net_device,
> + channel, data, buflen);
> +
> + if (unlikely(ret != NVSP_STAT_SUCCESS))
> + status = NVSP_STAT_FAIL;
> }
>
> enq_receive_complete(ndev, net_device, q_idx,
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index cdb78eefab67..33607995be62 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -818,7 +818,7 @@ int netvsc_recv_callback(struct net_device *net,
> u64_stats_update_end(&rx_stats->syncp);
>
> napi_gro_receive(&nvchan->napi, skb);
> - return 0;
> + return NVSP_STAT_SUCCESS;
> }
>
> static void netvsc_get_drvinfo(struct net_device *net,
> diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
> index 2dc00f714482..591fb8080f11 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -443,10 +443,10 @@ int rndis_filter_receive(struct net_device *ndev,
> "unhandled rndis message (type %u len %u)\n",
> rndis_msg->ndis_msg_type,
> rndis_msg->msg_len);
> - break;
> + return NVSP_STAT_FAIL;
> }
>
> - return 0;
> + return NVSP_STAT_SUCCESS;
> }
>
> static int rndis_filter_query_device(struct rndis_device *dev,
> --
> 2.15.1
^ permalink raw reply
* Re: [PATCH net-next RFC V1 2/5] net: phy: Move time stamping interface into the generic mdio layer.
From: Richard Cochran @ 2018-03-24 16:59 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, devicetree, Andrew Lunn, David Miller, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180321214513.5kkw4qpbhp3juxur@localhost>
On Wed, Mar 21, 2018 at 02:45:13PM -0700, Richard Cochran wrote:
> On Wed, Mar 21, 2018 at 12:10:07PM -0700, Florian Fainelli wrote:
> > > + phydev->mdio.ts_info = dp83640_ts_info;
> > > + phydev->mdio.hwtstamp = dp83640_hwtstamp;
> > > + phydev->mdio.rxtstamp = dp83640_rxtstamp;
> > > + phydev->mdio.txtstamp = dp83640_txtstamp;
> >
> > Why is this implemented a the mdio_device level and not at the
> > mdio_driver level? This looks like the wrong level at which this is done.
>
> The question could be asked of:
>
> struct mdio_device {
> int (*bus_match)(struct device *dev, struct device_driver *drv);
> void (*device_free)(struct mdio_device *mdiodev);
> void (*device_remove)(struct mdio_device *mdiodev);
> }
>
> I saw how this is done for the phy, etc, but I don't see any benefit
> of doing it that way. It would add an extra layer (or two) of
> indirection and save the space four pointer functions. Is that
> trade-off worth it?
Actually, there was another reason not to put these methods into the
driver structure. In contrast to phy_device, mdio_device doesn't have
a pointer to the driver structure. It looks like there is no way to
start from a mdio_device and get to a mdio_driver. Please correct me
if I'm wrong.
I propose keeping those methods in the mdio_device, wrapping them in
#ifdef CONFIG_NETWORK_PHY_TIMESTAMPING. That way, they do not add any
burden to the vast majority of users.
Thoughts?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next RFC V1 3/5] net: Introduce field for the MII time stamper.
From: Richard Cochran @ 2018-03-24 17:01 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, devicetree, Andrew Lunn, David Miller, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <cbab700a-8a4f-8c4a-b959-e356de006f6e@gmail.com>
On Wed, Mar 21, 2018 at 12:12:00PM -0700, Florian Fainelli wrote:
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 5fbb9f1da7fd..223d691aa0b0 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -1943,6 +1943,7 @@ struct net_device {
> > struct netprio_map __rcu *priomap;
> > #endif
> > struct phy_device *phydev;
> > + struct mdio_device *mdiots;
>
> phy_device embedds a mdio_device, can you find a way to rework the PHY
> PTP code to utilize the phy_device's mdio instance so do not introduce
> yet another pointer in that big structure that net_device already is?
You are right in that this field is wasted space for most users.
In V2 this will be inside #ifdef CONFIG_NETWORK_PHY_TIMESTAMPING.
Thanks,
Richard
^ permalink raw reply
* Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation
From: Florian Fainelli @ 2018-03-24 17:07 UTC (permalink / raw)
To: Jiri Pirko
Cc: Andrew Lunn, netdev, davem, idosch, jakub.kicinski, mlxsw,
vivien.didelot, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <20180324160749.GG1891@nanopsycho>
On March 24, 2018 9:07:49 AM PDT, Jiri Pirko <jiri@resnulli.us> wrote:
>Sat, Mar 24, 2018 at 03:35:09PM CET, f.fainelli@gmail.com wrote:
>>On March 24, 2018 12:45:51 AM PDT, Jiri Pirko <jiri@resnulli.us>
>wrote:
>>>Fri, Mar 23, 2018 at 04:24:12PM CET, andrew@lunn.ch wrote:
>>>>On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote:
>>>>> Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@lunn.ch wrote:
>>>>> >> I tested this for mlxsw and nfp. I have no way to test this on
>>>DSA hw,
>>>>> >> I would really appretiate DSA guys to test this.
>>>>> >
>>>>> >Hi Jiri
>>>>> >
>>>>> >With the missing break added, i get:
>>>>> >
>>>>> >root@zii-devel-b:~# ./iproute2/devlink/devlink port
>>>>> >mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0
>>>>> >mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1
>>>>> >mdio_bus/0.1:00/2: type eth netdev lan2 flavour physical number 2
>>>>> >mdio_bus/0.1:00/3: type notset
>>>>> >mdio_bus/0.1:00/4: type notset
>>>>> >mdio_bus/0.1:00/5: type notset flavour dsa number 5
>>>>> >mdio_bus/0.1:00/6: type notset flavour cpu number 6
>>>>> >mdio_bus/0.2:00/0: type eth netdev lan3 flavour physical number 0
>>>>> >mdio_bus/0.2:00/1: type eth netdev lan4 flavour physical number 1
>>>>> >mdio_bus/0.2:00/2: type eth netdev lan5 flavour physical number 2
>>>>> >mdio_bus/0.2:00/3: type notset
>>>>> >mdio_bus/0.2:00/4: type notset
>>>>> >mdio_bus/0.2:00/5: type notset flavour dsa number 5
>>>>> >mdio_bus/0.2:00/6: type notset flavour dsa number 6
>>>>> >mdio_bus/0.4:00/0: type eth netdev lan6 flavour physical number 0
>>>>> >mdio_bus/0.4:00/1: type eth netdev lan7 flavour physical number 1
>>>>> >mdio_bus/0.4:00/2: type eth netdev lan8 flavour physical number 2
>>>>> >mdio_bus/0.4:00/3: type eth netdev optical3 flavour physical
>number
>>>3
>>>>> >mdio_bus/0.4:00/4: type eth netdev optical4 flavour physical
>number
>>>4
>>>>> >mdio_bus/0.4:00/5: type notset
>>>>> >mdio_bus/0.4:00/6: type notset
>>>>> >mdio_bus/0.4:00/7: type notset
>>>>> >mdio_bus/0.4:00/8: type notset
>>>>> >mdio_bus/0.4:00/9: type notset flavour dsa number 9
>>>>
>>>>> That is basically front panel number for physical ports.
>>>>
>>>>You cannot make that assumption. As you can see here, we have 3
>ports
>>>>with the number 0.
>>>>
>>>>Look at clearfog, armada-388-clearfog.dts. port 0=lan5, port 1=lan4
>>>>port 2=lan3, port 3=lan2, port 4=lan1, port 5=cpu, port 6=lan6.
>>>>
>>>>The hardware and mechanical engineer is free to wire switch ports to
>>>>the front panel however they want. That is why we put the netdev
>name
>>>>in device tree.
>>>
>>>Got it. Hmm, so I think that the port number can be made optional and
>>>when it is present, it would be used to generate phys_port_name. If
>>>not, perhaps devlink port index could be used instead.
>>>
>>>So iiuc, you don't really need phys_port_name in dsa, as it provides
>>>misleading names, right? Why is it implemented then?
>>
>>We do need phys_port_name because there are switch configuration
>operations, e.g: ethtool::rxnfc which take a port number and queue
>number as part of the action to redirect a packet for instance. There
>is no way to obtain this physical port number other than either knowing
>it and hard coding it (not great) or scanning the device tree and look
>for the "reg" property value. phys_port_name gets you that and it is
>easy for an application to scan /sys/class/net/ on startup to get to
>know that (and other stuff as well).
>
>Hmm. That sounds like misuse of phys_port_name. The original purpose
>was
>to provide names as they are actually written on the front panel.
Ok, if we look back at the history of the changes I had implemented ndo_phys_port_id() to return the port number initially, but this was wrong and reverted based on your feedback, and then ndo_phys_port_name() was implemented with your reviewed-by tag:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/dsa/slave.c?id=3a543ef479868e36c95935de320608a7e41466ca
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/dsa/slave.c?id=592050b2541407d033da18226d3644644832d082
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/dsa/slave.c?id=592050b2541407d033da18226d3644644832d082
Now that this is reported through sysfs it unfortunately becomes ABI and we should not be breaking user applications relying on that and there is at least one I know of...
What is an appropriate attribute to use to return the physical port number within a given switch?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Richard Cochran @ 2018-03-24 17:12 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, devicetree, David Miller, Florian Fainelli, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180321235007.GA28402@lunn.ch>
On Thu, Mar 22, 2018 at 12:50:07AM +0100, Andrew Lunn wrote:
> How clever is this device? Can it tell the difference between
> 1000Base-X and SGMII? Can it figure out that the MAC is repeating
> every bit 100 times and so has dropped to 10Mbits? Does it understand
> EEE? Does it need to know if RGMII or RGMII-ID is being used?
This device isn't configurable at run time for any of those AFAICT.
Those decisions are made when the IP core is synthesized as part of
the HW design.
> Can such a device really operation without the MAC being involved? My
> feeling is it needs to understand how the MII bus is being used. It
> might also be that the device is less capable than the MAC, so you
> need to turn off some of the MAC features. I think you are going to
> need the MAC actively involved in this.
You are right in that this particular device *does* need to know the
link speed. I have neglected that part for this RFC. I'm looking for
a notification based method of informing the device of link speed
changes, but without hacking any MAC driver.
In general, we might see devices one day that care about things like
EEE for example, but let's cross that bridge when we come to it. In
the case of EEE, when the user enables it via ethtool we can tell the
time stamping device directly without hacking the MAC driver.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH bpf] tools: bpftool: don't use hex numbers in JSON output
From: Alexei Starovoitov @ 2018-03-24 17:40 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: daniel, oss-drivers, netdev
In-Reply-To: <20180324024512.20477-1-jakub.kicinski@netronome.com>
On Fri, Mar 23, 2018 at 07:45:12PM -0700, Jakub Kicinski wrote:
> JSON does not accept hex numbers with 0x prefix. Simply print
> as decimal numbers, JSON should be primarily machine-readable.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
> Fixes: 831a0aafe5c3 ("tools: bpftool: add JSON output for `bpftool map *` commands")
Applied to bpf tree, thanks Jakub.
^ permalink raw reply
* Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation
From: Jiri Pirko @ 2018-03-24 17:42 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, netdev, davem, idosch, jakub.kicinski, mlxsw,
vivien.didelot, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <D017986F-35B3-4B33-B2FF-97103AA9964A@gmail.com>
Sat, Mar 24, 2018 at 06:07:27PM CET, f.fainelli@gmail.com wrote:
>On March 24, 2018 9:07:49 AM PDT, Jiri Pirko <jiri@resnulli.us> wrote:
>>Sat, Mar 24, 2018 at 03:35:09PM CET, f.fainelli@gmail.com wrote:
>>>On March 24, 2018 12:45:51 AM PDT, Jiri Pirko <jiri@resnulli.us>
>>wrote:
>>>>Fri, Mar 23, 2018 at 04:24:12PM CET, andrew@lunn.ch wrote:
>>>>>On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote:
>>>>>> Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@lunn.ch wrote:
>>>>>> >> I tested this for mlxsw and nfp. I have no way to test this on
>>>>DSA hw,
>>>>>> >> I would really appretiate DSA guys to test this.
>>>>>> >
>>>>>> >Hi Jiri
>>>>>> >
>>>>>> >With the missing break added, i get:
>>>>>> >
>>>>>> >root@zii-devel-b:~# ./iproute2/devlink/devlink port
>>>>>> >mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0
>>>>>> >mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1
>>>>>> >mdio_bus/0.1:00/2: type eth netdev lan2 flavour physical number 2
>>>>>> >mdio_bus/0.1:00/3: type notset
>>>>>> >mdio_bus/0.1:00/4: type notset
>>>>>> >mdio_bus/0.1:00/5: type notset flavour dsa number 5
>>>>>> >mdio_bus/0.1:00/6: type notset flavour cpu number 6
>>>>>> >mdio_bus/0.2:00/0: type eth netdev lan3 flavour physical number 0
>>>>>> >mdio_bus/0.2:00/1: type eth netdev lan4 flavour physical number 1
>>>>>> >mdio_bus/0.2:00/2: type eth netdev lan5 flavour physical number 2
>>>>>> >mdio_bus/0.2:00/3: type notset
>>>>>> >mdio_bus/0.2:00/4: type notset
>>>>>> >mdio_bus/0.2:00/5: type notset flavour dsa number 5
>>>>>> >mdio_bus/0.2:00/6: type notset flavour dsa number 6
>>>>>> >mdio_bus/0.4:00/0: type eth netdev lan6 flavour physical number 0
>>>>>> >mdio_bus/0.4:00/1: type eth netdev lan7 flavour physical number 1
>>>>>> >mdio_bus/0.4:00/2: type eth netdev lan8 flavour physical number 2
>>>>>> >mdio_bus/0.4:00/3: type eth netdev optical3 flavour physical
>>number
>>>>3
>>>>>> >mdio_bus/0.4:00/4: type eth netdev optical4 flavour physical
>>number
>>>>4
>>>>>> >mdio_bus/0.4:00/5: type notset
>>>>>> >mdio_bus/0.4:00/6: type notset
>>>>>> >mdio_bus/0.4:00/7: type notset
>>>>>> >mdio_bus/0.4:00/8: type notset
>>>>>> >mdio_bus/0.4:00/9: type notset flavour dsa number 9
>>>>>
>>>>>> That is basically front panel number for physical ports.
>>>>>
>>>>>You cannot make that assumption. As you can see here, we have 3
>>ports
>>>>>with the number 0.
>>>>>
>>>>>Look at clearfog, armada-388-clearfog.dts. port 0=lan5, port 1=lan4
>>>>>port 2=lan3, port 3=lan2, port 4=lan1, port 5=cpu, port 6=lan6.
>>>>>
>>>>>The hardware and mechanical engineer is free to wire switch ports to
>>>>>the front panel however they want. That is why we put the netdev
>>name
>>>>>in device tree.
>>>>
>>>>Got it. Hmm, so I think that the port number can be made optional and
>>>>when it is present, it would be used to generate phys_port_name. If
>>>>not, perhaps devlink port index could be used instead.
>>>>
>>>>So iiuc, you don't really need phys_port_name in dsa, as it provides
>>>>misleading names, right? Why is it implemented then?
>>>
>>>We do need phys_port_name because there are switch configuration
>>operations, e.g: ethtool::rxnfc which take a port number and queue
>>number as part of the action to redirect a packet for instance. There
>>is no way to obtain this physical port number other than either knowing
>>it and hard coding it (not great) or scanning the device tree and look
>>for the "reg" property value. phys_port_name gets you that and it is
>>easy for an application to scan /sys/class/net/ on startup to get to
>>know that (and other stuff as well).
>>
>>Hmm. That sounds like misuse of phys_port_name. The original purpose
>>was
>>to provide names as they are actually written on the front panel.
>
>Ok, if we look back at the history of the changes I had implemented ndo_phys_port_id() to return the port number initially, but this was wrong and reverted based on your feedback, and then ndo_phys_port_name() was implemented with your reviewed-by tag:
>
>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/dsa/slave.c?id=3a543ef479868e36c95935de320608a7e41466ca
>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/dsa/slave.c?id=592050b2541407d033da18226d3644644832d082
>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/dsa/slave.c?id=592050b2541407d033da18226d3644644832d082
>
>Now that this is reported through sysfs it unfortunately becomes ABI and we should not be breaking user applications relying on that and there is at least one I know of...
>
>What is an appropriate attribute to use to return the physical port number within a given switch?
I don't think there's one out there. I tried to add it in this patchset.
^ permalink raw reply
* Re: [PATCH bpf] nfp: bpf: fix check of program max insn count
From: Alexei Starovoitov @ 2018-03-24 17:44 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: daniel, oss-drivers, netdev
In-Reply-To: <20180324030013.26436-1-jakub.kicinski@netronome.com>
On Fri, Mar 23, 2018 at 08:00:13PM -0700, Jakub Kicinski wrote:
> NFP program allocation length is in bytes and NFP program length
> is in instructions, fix the comparison of the two.
>
> Fixes: 9314c442d7dd ("nfp: bpf: move translation prepare to offload.c")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Jiong Wang <jiong.wang@netronome.com>
Applied to bpf tree, thanks Jakub.
^ permalink raw reply
* [iproute PATCH] ssfilter: Eliminate shift/reduce conflicts
From: Phil Sutter @ 2018-03-24 17:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
The problematic bit was the 'expr: expr expr' rule. Fix this by making
'expr' token represent a single filter only and introduce a new token
'exprlist' to represent a combination of filters.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/ssfilter.y | 52 +++++++++++++++++++++++++++-------------------------
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/misc/ssfilter.y b/misc/ssfilter.y
index 4db3c95faa3cc..88d4229a9b241 100644
--- a/misc/ssfilter.y
+++ b/misc/ssfilter.y
@@ -42,7 +42,7 @@ static void yyerror(char *s)
%nonassoc '!'
%%
-applet: null expr
+applet: null exprlist
{
*yy_ret = $2;
$$ = $2;
@@ -51,6 +51,32 @@ applet: null expr
;
null: /* NOTHING */ { $$ = NULL; }
;
+exprlist: expr
+ | '!' expr
+ {
+ $$ = alloc_node(SSF_NOT, $2);
+ }
+ | '(' exprlist ')'
+ {
+ $$ = $2;
+ }
+ | exprlist '|' expr
+ {
+ $$ = alloc_node(SSF_OR, $1);
+ $$->post = $3;
+ }
+ | exprlist '&' expr
+ {
+ $$ = alloc_node(SSF_AND, $1);
+ $$->post = $3;
+ }
+ | exprlist expr
+ {
+ $$ = alloc_node(SSF_AND, $1);
+ $$->post = $2;
+ }
+ ;
+
expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_DCOND, $2);
@@ -128,30 +154,6 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_S_AUTO, NULL);
}
- | expr '|' expr
- {
- $$ = alloc_node(SSF_OR, $1);
- $$->post = $3;
- }
- | expr expr
- {
- $$ = alloc_node(SSF_AND, $1);
- $$->post = $2;
- }
- | expr '&' expr
-
- {
- $$ = alloc_node(SSF_AND, $1);
- $$->post = $3;
- }
- | '!' expr
- {
- $$ = alloc_node(SSF_NOT, $2);
- }
- | '(' expr ')'
- {
- $$ = $2;
- }
;
%%
--
2.16.1
^ permalink raw reply related
* [iproute PATCH 2/3] ss: Put filter DB parsing into a separate function
From: Phil Sutter @ 2018-03-24 18:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20180324181811.22615-1-phil@nwl.cc>
Use a table for database name parsing. The tricky bit is to allow for
association of a (nearly) arbitrary number of DBs with each name.
Luckily the number is not fully arbitrary as there is an upper bound of
MAX_DB items. Since it is not possible to have a variable length
array inside a variable length array, use this knowledge to make the
inner array of fixed length. But since DB values start from zero, an
explicit end entry needs to be present as well, so the inner array has
to be MAX_DB + 1 in size.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/ss.c | 114 ++++++++++++++++++++++++++++++--------------------------------
1 file changed, 56 insertions(+), 58 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index 2044776ba310b..e6511014ba3f4 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -340,6 +340,61 @@ static void filter_db_set(struct filter *f, int db, bool enable)
do_default = 0;
}
+static int filter_db_parse(struct filter *f, const char *s)
+{
+ const struct {
+ const char *name;
+ int dbs[MAX_DB + 1];
+ } db_name_tbl[] = {
+#define ENTRY(name, ...) { #name, { __VA_ARGS__, MAX_DB }}
+ ENTRY(all, UDP_DB, DCCP_DB, TCP_DB, RAW_DB, \
+ UNIX_ST_DB, UNIX_DG_DB, UNIX_SQ_DB, \
+ PACKET_R_DB, PACKET_DG_DB, NETLINK_DB, \
+ SCTP_DB, VSOCK_ST_DB, VSOCK_DG_DB),
+ ENTRY(inet, UDP_DB, DCCP_DB, TCP_DB, SCTP_DB, RAW_DB),
+ ENTRY(udp, UDP_DB),
+ ENTRY(dccp, DCCP_DB),
+ ENTRY(tcp, TCP_DB),
+ ENTRY(sctp, SCTP_DB),
+ ENTRY(raw, RAW_DB),
+ ENTRY(unix, UNIX_ST_DB, UNIX_DG_DB, UNIX_SQ_DB),
+ ENTRY(unix_stream, UNIX_ST_DB),
+ ENTRY(u_str, UNIX_ST_DB), /* alias for unix_stream */
+ ENTRY(unix_dgram, UNIX_DG_DB),
+ ENTRY(u_dgr, UNIX_DG_DB), /* alias for unix_dgram */
+ ENTRY(unix_seqpacket, UNIX_SQ_DB),
+ ENTRY(u_seq, UNIX_SQ_DB), /* alias for unix_seqpacket */
+ ENTRY(packet, PACKET_R_DB, PACKET_DG_DB),
+ ENTRY(packet_raw, PACKET_R_DB),
+ ENTRY(p_raw, PACKET_R_DB), /* alias for packet_raw */
+ ENTRY(packet_dgram, PACKET_DG_DB),
+ ENTRY(p_dgr, PACKET_DG_DB), /* alias for packet_dgram */
+ ENTRY(netlink, NETLINK_DB),
+ ENTRY(vsock, VSOCK_ST_DB, VSOCK_DG_DB),
+ ENTRY(vsock_stream, VSOCK_ST_DB),
+ ENTRY(v_str, VSOCK_ST_DB), /* alias for vsock_stream */
+ ENTRY(vsock_dgram, VSOCK_DG_DB),
+ ENTRY(v_dgr, VSOCK_DG_DB), /* alias for vsock_dgram */
+#undef ENTRY
+ };
+ bool enable = true;
+ unsigned int i;
+ const int *dbp;
+
+ if (s[0] == '!') {
+ enable = false;
+ s++;
+ }
+ for (i = 0; i < ARRAY_SIZE(db_name_tbl); i++) {
+ if (strcmp(s, db_name_tbl[i].name))
+ continue;
+ for (dbp = db_name_tbl[i].dbs; *dbp != MAX_DB; dbp++)
+ filter_db_set(f, *dbp, enable);
+ return 0;
+ }
+ return -1;
+}
+
static void filter_af_set(struct filter *f, int af)
{
f->states |= default_afs[af].states;
@@ -4757,66 +4812,9 @@ int main(int argc, char *argv[])
}
p = p1 = optarg;
do {
- bool enable = true;
-
if ((p1 = strchr(p, ',')) != NULL)
*p1 = 0;
- if (p[0] == '!') {
- enable = false;
- p++;
- }
- if (strcmp(p, "all") == 0) {
- filter_default_dbs(¤t_filter, enable);
- } else if (strcmp(p, "inet") == 0) {
- filter_db_set(¤t_filter, UDP_DB, enable);
- filter_db_set(¤t_filter, DCCP_DB, enable);
- filter_db_set(¤t_filter, TCP_DB, enable);
- filter_db_set(¤t_filter, SCTP_DB, enable);
- filter_db_set(¤t_filter, RAW_DB, enable);
- } else if (strcmp(p, "udp") == 0) {
- filter_db_set(¤t_filter, UDP_DB, enable);
- } else if (strcmp(p, "dccp") == 0) {
- filter_db_set(¤t_filter, DCCP_DB, enable);
- } else if (strcmp(p, "tcp") == 0) {
- filter_db_set(¤t_filter, TCP_DB, enable);
- } else if (strcmp(p, "sctp") == 0) {
- filter_db_set(¤t_filter, SCTP_DB, enable);
- } else if (strcmp(p, "raw") == 0) {
- filter_db_set(¤t_filter, RAW_DB, enable);
- } else if (strcmp(p, "unix") == 0) {
- filter_db_set(¤t_filter, UNIX_ST_DB, enable);
- filter_db_set(¤t_filter, UNIX_DG_DB, enable);
- filter_db_set(¤t_filter, UNIX_SQ_DB, enable);
- } else if (strcasecmp(p, "unix_stream") == 0 ||
- strcmp(p, "u_str") == 0) {
- filter_db_set(¤t_filter, UNIX_ST_DB, enable);
- } else if (strcasecmp(p, "unix_dgram") == 0 ||
- strcmp(p, "u_dgr") == 0) {
- filter_db_set(¤t_filter, UNIX_DG_DB, enable);
- } else if (strcasecmp(p, "unix_seqpacket") == 0 ||
- strcmp(p, "u_seq") == 0) {
- filter_db_set(¤t_filter, UNIX_SQ_DB, enable);
- } else if (strcmp(p, "packet") == 0) {
- filter_db_set(¤t_filter, PACKET_R_DB, enable);
- filter_db_set(¤t_filter, PACKET_DG_DB, enable);
- } else if (strcmp(p, "packet_raw") == 0 ||
- strcmp(p, "p_raw") == 0) {
- filter_db_set(¤t_filter, PACKET_R_DB, enable);
- } else if (strcmp(p, "packet_dgram") == 0 ||
- strcmp(p, "p_dgr") == 0) {
- filter_db_set(¤t_filter, PACKET_DG_DB, enable);
- } else if (strcmp(p, "netlink") == 0) {
- filter_db_set(¤t_filter, NETLINK_DB, enable);
- } else if (strcmp(p, "vsock") == 0) {
- filter_db_set(¤t_filter, VSOCK_ST_DB, enable);
- filter_db_set(¤t_filter, VSOCK_DG_DB, enable);
- } else if (strcmp(p, "vsock_stream") == 0 ||
- strcmp(p, "v_str") == 0) {
- filter_db_set(¤t_filter, VSOCK_ST_DB, enable);
- } else if (strcmp(p, "vsock_dgram") == 0 ||
- strcmp(p, "v_dgr") == 0) {
- filter_db_set(¤t_filter, VSOCK_DG_DB, enable);
- } else {
+ if (filter_db_parse(¤t_filter, p)) {
fprintf(stderr, "ss: \"%s\" is illegal socket table id\n", p);
usage();
}
--
2.16.1
^ permalink raw reply related
* [iproute PATCH 3/3] ss: Drop filter_default_dbs()
From: Phil Sutter @ 2018-03-24 18:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20180324181811.22615-1-phil@nwl.cc>
Instead call filter_db_parse(..., "all"). This eliminates the duplicate
default DB definition.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/ss.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index e6511014ba3f4..ab2f07b9e5d4d 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -408,23 +408,6 @@ static int filter_af_get(struct filter *f, int af)
return !!(f->families & FAMILY_MASK(af));
}
-static void filter_default_dbs(struct filter *f, bool enable)
-{
- filter_db_set(f, UDP_DB, enable);
- filter_db_set(f, DCCP_DB, enable);
- filter_db_set(f, TCP_DB, enable);
- filter_db_set(f, RAW_DB, enable);
- filter_db_set(f, UNIX_ST_DB, enable);
- filter_db_set(f, UNIX_DG_DB, enable);
- filter_db_set(f, UNIX_SQ_DB, enable);
- filter_db_set(f, PACKET_R_DB, enable);
- filter_db_set(f, PACKET_DG_DB, enable);
- filter_db_set(f, NETLINK_DB, enable);
- filter_db_set(f, SCTP_DB, enable);
- filter_db_set(f, VSOCK_ST_DB, enable);
- filter_db_set(f, VSOCK_DG_DB, enable);
-}
-
static void filter_states_set(struct filter *f, int states)
{
if (states)
@@ -4906,7 +4889,7 @@ int main(int argc, char *argv[])
if (do_default) {
state_filter = state_filter ? state_filter : SS_CONN;
- filter_default_dbs(¤t_filter, true);
+ filter_db_parse(¤t_filter, "all");
}
filter_states_set(¤t_filter, state_filter);
--
2.16.1
^ permalink raw reply related
* [iproute PATCH 1/3] ss: Allow excluding a socket table from being queried
From: Phil Sutter @ 2018-03-24 18:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20180324181811.22615-1-phil@nwl.cc>
The original problem was that a simple call to 'ss' leads to loading of
sctp_diag kernel module which might not be desired. While searching for
a workaround, it became clear how inconvenient it is to exclude a single
socket table from being queried.
This patch allows to prefix an item passed to '-A' parameter with an
exclamation mark to inverse its meaning.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
man/man8/ss.8 | 8 ++++-
misc/ss.c | 108 ++++++++++++++++++++++++++++++++--------------------------
2 files changed, 66 insertions(+), 50 deletions(-)
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 973afbe0b386b..28033d8f01dda 100644
--- a/man/man8/ss.8
+++ b/man/man8/ss.8
@@ -317,7 +317,10 @@ Currently the following families are supported: unix, inet, inet6, link, netlink
List of socket tables to dump, separated by commas. The following identifiers
are understood: all, inet, tcp, udp, raw, unix, packet, netlink, unix_dgram,
unix_stream, unix_seqpacket, packet_raw, packet_dgram, dccp, sctp,
-vsock_stream, vsock_dgram.
+vsock_stream, vsock_dgram. Any item in the list may optionally be prefixed by
+an exclamation mark
+.RB ( ! )
+to exclude that socket table from being dumped.
.TP
.B \-D FILE, \-\-diag=FILE
Do not display anything, just dump raw information about TCP sockets to FILE after applying filters. If FILE is - stdout is used.
@@ -380,6 +383,9 @@ Find all local processes connected to X server.
.TP
.B ss -o state fin-wait-1 '( sport = :http or sport = :https )' dst 193.233.7/24
List all the tcp sockets in state FIN-WAIT-1 for our apache to network 193.233.7/24 and look at their timers.
+.TP
+.B ss -a -A 'all,!tcp'
+List sockets in all states from all socket tables but TCP.
.SH SEE ALSO
.BR ip (8),
.br
diff --git a/misc/ss.c b/misc/ss.c
index e087bef739b0d..2044776ba310b 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -329,10 +329,14 @@ static const struct filter default_afs[AF_MAX] = {
static int do_default = 1;
static struct filter current_filter;
-static void filter_db_set(struct filter *f, int db)
+static void filter_db_set(struct filter *f, int db, bool enable)
{
- f->states |= default_dbs[db].states;
- f->dbs |= 1 << db;
+ if (enable) {
+ f->states |= default_dbs[db].states;
+ f->dbs |= 1 << db;
+ } else {
+ f->dbs &= ~(1 << db);
+ }
do_default = 0;
}
@@ -349,21 +353,21 @@ static int filter_af_get(struct filter *f, int af)
return !!(f->families & FAMILY_MASK(af));
}
-static void filter_default_dbs(struct filter *f)
+static void filter_default_dbs(struct filter *f, bool enable)
{
- filter_db_set(f, UDP_DB);
- filter_db_set(f, DCCP_DB);
- filter_db_set(f, TCP_DB);
- filter_db_set(f, RAW_DB);
- filter_db_set(f, UNIX_ST_DB);
- filter_db_set(f, UNIX_DG_DB);
- filter_db_set(f, UNIX_SQ_DB);
- filter_db_set(f, PACKET_R_DB);
- filter_db_set(f, PACKET_DG_DB);
- filter_db_set(f, NETLINK_DB);
- filter_db_set(f, SCTP_DB);
- filter_db_set(f, VSOCK_ST_DB);
- filter_db_set(f, VSOCK_DG_DB);
+ filter_db_set(f, UDP_DB, enable);
+ filter_db_set(f, DCCP_DB, enable);
+ filter_db_set(f, TCP_DB, enable);
+ filter_db_set(f, RAW_DB, enable);
+ filter_db_set(f, UNIX_ST_DB, enable);
+ filter_db_set(f, UNIX_DG_DB, enable);
+ filter_db_set(f, UNIX_SQ_DB, enable);
+ filter_db_set(f, PACKET_R_DB, enable);
+ filter_db_set(f, PACKET_DG_DB, enable);
+ filter_db_set(f, NETLINK_DB, enable);
+ filter_db_set(f, SCTP_DB, enable);
+ filter_db_set(f, VSOCK_ST_DB, enable);
+ filter_db_set(f, VSOCK_DG_DB, enable);
}
static void filter_states_set(struct filter *f, int states)
@@ -4684,19 +4688,19 @@ int main(int argc, char *argv[])
follow_events = 1;
break;
case 'd':
- filter_db_set(¤t_filter, DCCP_DB);
+ filter_db_set(¤t_filter, DCCP_DB, true);
break;
case 't':
- filter_db_set(¤t_filter, TCP_DB);
+ filter_db_set(¤t_filter, TCP_DB, true);
break;
case 'S':
- filter_db_set(¤t_filter, SCTP_DB);
+ filter_db_set(¤t_filter, SCTP_DB, true);
break;
case 'u':
- filter_db_set(¤t_filter, UDP_DB);
+ filter_db_set(¤t_filter, UDP_DB, true);
break;
case 'w':
- filter_db_set(¤t_filter, RAW_DB);
+ filter_db_set(¤t_filter, RAW_DB, true);
break;
case 'x':
filter_af_set(¤t_filter, AF_UNIX);
@@ -4753,59 +4757,65 @@ int main(int argc, char *argv[])
}
p = p1 = optarg;
do {
+ bool enable = true;
+
if ((p1 = strchr(p, ',')) != NULL)
*p1 = 0;
+ if (p[0] == '!') {
+ enable = false;
+ p++;
+ }
if (strcmp(p, "all") == 0) {
- filter_default_dbs(¤t_filter);
+ filter_default_dbs(¤t_filter, enable);
} else if (strcmp(p, "inet") == 0) {
- filter_db_set(¤t_filter, UDP_DB);
- filter_db_set(¤t_filter, DCCP_DB);
- filter_db_set(¤t_filter, TCP_DB);
- filter_db_set(¤t_filter, SCTP_DB);
- filter_db_set(¤t_filter, RAW_DB);
+ filter_db_set(¤t_filter, UDP_DB, enable);
+ filter_db_set(¤t_filter, DCCP_DB, enable);
+ filter_db_set(¤t_filter, TCP_DB, enable);
+ filter_db_set(¤t_filter, SCTP_DB, enable);
+ filter_db_set(¤t_filter, RAW_DB, enable);
} else if (strcmp(p, "udp") == 0) {
- filter_db_set(¤t_filter, UDP_DB);
+ filter_db_set(¤t_filter, UDP_DB, enable);
} else if (strcmp(p, "dccp") == 0) {
- filter_db_set(¤t_filter, DCCP_DB);
+ filter_db_set(¤t_filter, DCCP_DB, enable);
} else if (strcmp(p, "tcp") == 0) {
- filter_db_set(¤t_filter, TCP_DB);
+ filter_db_set(¤t_filter, TCP_DB, enable);
} else if (strcmp(p, "sctp") == 0) {
- filter_db_set(¤t_filter, SCTP_DB);
+ filter_db_set(¤t_filter, SCTP_DB, enable);
} else if (strcmp(p, "raw") == 0) {
- filter_db_set(¤t_filter, RAW_DB);
+ filter_db_set(¤t_filter, RAW_DB, enable);
} else if (strcmp(p, "unix") == 0) {
- filter_db_set(¤t_filter, UNIX_ST_DB);
- filter_db_set(¤t_filter, UNIX_DG_DB);
- filter_db_set(¤t_filter, UNIX_SQ_DB);
+ filter_db_set(¤t_filter, UNIX_ST_DB, enable);
+ filter_db_set(¤t_filter, UNIX_DG_DB, enable);
+ filter_db_set(¤t_filter, UNIX_SQ_DB, enable);
} else if (strcasecmp(p, "unix_stream") == 0 ||
strcmp(p, "u_str") == 0) {
- filter_db_set(¤t_filter, UNIX_ST_DB);
+ filter_db_set(¤t_filter, UNIX_ST_DB, enable);
} else if (strcasecmp(p, "unix_dgram") == 0 ||
strcmp(p, "u_dgr") == 0) {
- filter_db_set(¤t_filter, UNIX_DG_DB);
+ filter_db_set(¤t_filter, UNIX_DG_DB, enable);
} else if (strcasecmp(p, "unix_seqpacket") == 0 ||
strcmp(p, "u_seq") == 0) {
- filter_db_set(¤t_filter, UNIX_SQ_DB);
+ filter_db_set(¤t_filter, UNIX_SQ_DB, enable);
} else if (strcmp(p, "packet") == 0) {
- filter_db_set(¤t_filter, PACKET_R_DB);
- filter_db_set(¤t_filter, PACKET_DG_DB);
+ filter_db_set(¤t_filter, PACKET_R_DB, enable);
+ filter_db_set(¤t_filter, PACKET_DG_DB, enable);
} else if (strcmp(p, "packet_raw") == 0 ||
strcmp(p, "p_raw") == 0) {
- filter_db_set(¤t_filter, PACKET_R_DB);
+ filter_db_set(¤t_filter, PACKET_R_DB, enable);
} else if (strcmp(p, "packet_dgram") == 0 ||
strcmp(p, "p_dgr") == 0) {
- filter_db_set(¤t_filter, PACKET_DG_DB);
+ filter_db_set(¤t_filter, PACKET_DG_DB, enable);
} else if (strcmp(p, "netlink") == 0) {
- filter_db_set(¤t_filter, NETLINK_DB);
+ filter_db_set(¤t_filter, NETLINK_DB, enable);
} else if (strcmp(p, "vsock") == 0) {
- filter_db_set(¤t_filter, VSOCK_ST_DB);
- filter_db_set(¤t_filter, VSOCK_DG_DB);
+ filter_db_set(¤t_filter, VSOCK_ST_DB, enable);
+ filter_db_set(¤t_filter, VSOCK_DG_DB, enable);
} else if (strcmp(p, "vsock_stream") == 0 ||
strcmp(p, "v_str") == 0) {
- filter_db_set(¤t_filter, VSOCK_ST_DB);
+ filter_db_set(¤t_filter, VSOCK_ST_DB, enable);
} else if (strcmp(p, "vsock_dgram") == 0 ||
strcmp(p, "v_dgr") == 0) {
- filter_db_set(¤t_filter, VSOCK_DG_DB);
+ filter_db_set(¤t_filter, VSOCK_DG_DB, enable);
} else {
fprintf(stderr, "ss: \"%s\" is illegal socket table id\n", p);
usage();
@@ -4898,7 +4908,7 @@ int main(int argc, char *argv[])
if (do_default) {
state_filter = state_filter ? state_filter : SS_CONN;
- filter_default_dbs(¤t_filter);
+ filter_default_dbs(¤t_filter, true);
}
filter_states_set(¤t_filter, state_filter);
--
2.16.1
^ permalink raw reply related
* [iproute PATCH 0/3] ss: Allow excluding a socket table from being queried
From: Phil Sutter @ 2018-03-24 18:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
The first patch in this series adds the new functionality, the remaining
two refactor the code a bit.
Phil Sutter (3):
ss: Allow excluding a socket table from being queried
ss: Put filter DB parsing into a separate function
ss: Drop filter_default_dbs()
man/man8/ss.8 | 8 +++-
misc/ss.c | 147 +++++++++++++++++++++++++++-------------------------------
2 files changed, 76 insertions(+), 79 deletions(-)
--
2.16.1
^ permalink raw reply
* [PATCH bpf-next 0/2] bpf_verifier_log changes
From: Martin KaFai Lau @ 2018-03-24 18:44 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
This patch set has some changes and clean-up works for
the bpf_verifier_log. They are the prep works for the
BTF (BPF Type Format).
Martin KaFai Lau (2):
bpf: Rename bpf_verifer_log
bpf: Add bpf_verifier_vlog() and bpf_verifier_log_needed()
include/linux/bpf_verifier.h | 13 ++++++++++---
kernel/bpf/verifier.c | 21 ++++++++++++---------
2 files changed, 22 insertions(+), 12 deletions(-)
--
2.9.5
^ permalink raw reply
* [PATCH bpf-next 1/2] bpf: Rename bpf_verifer_log
From: Martin KaFai Lau @ 2018-03-24 18:44 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180324184423.3053682-1-kafai@fb.com>
bpf_verifer_log =>
bpf_verifier_log
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@fb.com>
---
include/linux/bpf_verifier.h | 6 +++---
kernel/bpf/verifier.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index 6b66cd1aa0b9..c30668414b22 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -153,7 +153,7 @@ struct bpf_insn_aux_data {
#define BPF_VERIFIER_TMP_LOG_SIZE 1024
-struct bpf_verifer_log {
+struct bpf_verifier_log {
u32 level;
char kbuf[BPF_VERIFIER_TMP_LOG_SIZE];
char __user *ubuf;
@@ -161,7 +161,7 @@ struct bpf_verifer_log {
u32 len_total;
};
-static inline bool bpf_verifier_log_full(const struct bpf_verifer_log *log)
+static inline bool bpf_verifier_log_full(const struct bpf_verifier_log *log)
{
return log->len_used >= log->len_total - 1;
}
@@ -185,7 +185,7 @@ struct bpf_verifier_env {
bool allow_ptr_leaks;
bool seen_direct_write;
struct bpf_insn_aux_data *insn_aux_data; /* array of per-insn state */
- struct bpf_verifer_log log;
+ struct bpf_verifier_log log;
u32 subprog_starts[BPF_MAX_SUBPROGS];
/* computes the stack depth of each bpf function */
u16 subprog_stack_depth[BPF_MAX_SUBPROGS + 1];
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e93a6e48641b..1e84e02ff733 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -171,7 +171,7 @@ static DEFINE_MUTEX(bpf_verifier_lock);
static void log_write(struct bpf_verifier_env *env, const char *fmt,
va_list args)
{
- struct bpf_verifer_log *log = &env->log;
+ struct bpf_verifier_log *log = &env->log;
unsigned int n;
if (!log->level || !log->ubuf || bpf_verifier_log_full(log))
@@ -5611,7 +5611,7 @@ static void free_states(struct bpf_verifier_env *env)
int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
{
struct bpf_verifier_env *env;
- struct bpf_verifer_log *log;
+ struct bpf_verifier_log *log;
int ret = -EINVAL;
/* no program is valid */
--
2.9.5
^ 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