* Re: [PATCH net-next 0/2] ovs: refresh a flow via netlink
From: Jesse Gross @ 2016-03-17 22:54 UTC (permalink / raw)
To: Samuel Gauthier; +Cc: ovs dev, Linux Kernel Network Developers, David S. Miller
In-Reply-To: <CAMEOZh+TR3S+30e+u9yVH04XN2Z26WEnhNK=t7DFq8YaBmjFyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Mar 17, 2016 at 9:24 AM, Samuel Gauthier
<samuel.gauthier@6wind.com> wrote:
> 2016-03-17 0:23 GMT+01:00 Jesse Gross <jesse@kernel.org>:
>> On Wed, Mar 16, 2016 at 8:07 AM, Samuel Gauthier
>> <samuel.gauthier@6wind.com> wrote:
>>> This patchset adds a netlink api to refresh an existing flow in
>>> openvswitch.
>>>
>>> When a packet is sent in the openvswitch kernel datapath and no
>>> flow is found, the packet is sent to the ovs-vswitchd daemon,
>>> which will process the packet, and ask the kernel to create a new
>>> flow. The next packets for this flow will be processed by the
>>> kernel datapath. If a flow is not used for a (configurable)
>>> period of time, ovs-vswitchd removes the flow from the kernel.
>>>
>>> As a result, it can be tricky to test the kernel datapath against
>>> packets, as the first packets of each flow will have to go
>>> through the ovs-vswitchd daemon. For instance, to do a zeroloss
>>> performance test, you establish the flows, and then you have to
>>> perform your zeroloss test before the flow is removed by
>>> ovs-vswitchd.
>>>
>>> It is possible to configure a flow timeout in ovs-vswitchd (using
>>> other_config:max-idle option), but it changes the behavior for
>>> all the flows, which is not always what you want.
>>
>> It seems to me that it would be preferable to implement the necessary
>> behavior in userspace to handle this directly. The logic that is
>> removing the flow is in userspace, so rather than asking the kernel to
>> lie about the current state of things, we can just modify the logic to
>> handle this case.
>
> It seemed like a problem limited to the kernel datapath (i.e.: not to
> the other ovs datapaths), so it made sense to me to fix it by a
> netlink API.
I don't think that is true - the flow eviction logic is in userspace,
so it should be common to all datapaths. What the kernel is providing
is really very simple, just the last used time.
> The idea was to do something similar to the OVS_FLOW_ATTR_CLEAR
> attribute (which sets the flow statistics and used field to 0).
>
> This said, I could have a look to a pure userland solution, but I am
> not sure how to do it. Could you elaborate what you have in mind?
Well, truthfully, I would just use the existing max-idle option that
you mentioned. I'm not entirely sure what the issue is with it
applying to all flows, however, presumably it could be modified to
only apply to a subset if necessary. max-idle is implemented purely in
userspace, so I would start by looking at that and see how to tailor
it.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net 1/3] ipip: Properly mark ipip GRO packets as encapsulated.
From: Eric Dumazet @ 2016-03-17 22:29 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev, Patrick Boutilier
In-Reply-To: <1458239136-37814-1-git-send-email-jesse@kernel.org>
On Thu, 2016-03-17 at 11:25 -0700, Jesse Gross wrote:
> ipip encapsulated packets can be merged together by GRO but the result
> does not have the proper GSO type set or even marked as being
> encapsulated at all. Later retransmission of these packets will likely
> fail if the device does not support ipip offloads. This is similar to
> the issue resolved in IPv6 sit in feec0cb3
> ("ipv6: gro: support sit protocol").
>
> Reported-by: Patrick Boutilier <boutilpj@ednet.ns.ca>
> Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload")
> Signed-off-by: Jesse Gross <jesse@kernel.org>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
From: Ido Schimmel @ 2016-03-17 21:53 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Murali Karicheri, David Miller, sfeldma, netdev, jiri
In-Reply-To: <20160317202519.GA30210@lunn.ch>
Thu, Mar 17, 2016 at 10:25:19PM IST, andrew@lunn.ch wrote:
>On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>> David,
>>
>> On 08/18/2015 04:47 PM, David Miller wrote:
>> > I see some drivers where the foo_debugfs.c file is larger than the rest
>> > of the driver. Once people start using it, it's like crack, and they
>> > dump every single debugging widget they found useful at some point into
>> > there.
>> >
>> > This is not what we want. Most things I see in debugfs support was
>> > probably useful for debugging one particular bug but then it was never
>> > really useful again in the future. Those kinds of things can be done
>> > locally in someone's tree.
>> >
>> > I often see various kinds of "statistics" ending up in these things,
>> > or register dumps, both of which are 'ethtool' or similar material.
>> Very late to this discussion, but I need to port some of the internal code
>> to display the content of a ALE (Address Learning Engine) table maintained
>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>> information like below.
>>
>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>> index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr: ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>> index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr: 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>> index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr: 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>> index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr: d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>>
>> What is the available interface in kernel to expose this information
>> to user space as debugfs is not suggested based on this thread?
>
>This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
>returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
>switchdev_port_obj_dump() in the switchdev ops.
+1
Also, Murali, using standard interfaces instead of debugfs will allow
you to:
1) Upstream your code
2) Use existing tests for your code. In particular, the following
(which is used for mlxsw testing):
https://github.com/jpirko/lnst/blob/master/recipes/switchdev/l2-002-bridge_fdb.py
There are a bunch of others there which you'll probably find useful.
BTW, are you familiar with the following document?
https://www.kernel.org/doc/Documentation/networking/switchdev.txt
I believe it answers your question.
Good luck!
>
> Andrew
^ permalink raw reply
* Re: [RFC v2 -next 1/2] virtio: Start feature MTU support
From: Stephen Hemminger @ 2016-03-17 22:04 UTC (permalink / raw)
To: Aaron Conole; +Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <f7tfuvox128.fsf@redhat.com>
On Thu, 17 Mar 2016 17:10:55 -0400
Aaron Conole <aconole@redhat.com> wrote:
> Stephen Hemminger <stephen@networkplumber.org> writes:
>
> > On Tue, 15 Mar 2016 17:04:12 -0400
> > Aaron Conole <aconole@redhat.com> wrote:
> >
> >> --- a/include/uapi/linux/virtio_net.h
> >> +++ b/include/uapi/linux/virtio_net.h
> >> @@ -55,6 +55,7 @@
> >> #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
> >> * Steering */
> >> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> >> +#define VIRTIO_NET_F_MTU 25 /* Device supports Default MTU Negotiation */
> >>
> >> #ifndef VIRTIO_NET_NO_LEGACY
> >> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> >> @@ -73,6 +74,8 @@ struct virtio_net_config {
> >> * Legal values are between 1 and 0x8000
> >> */
> >> __u16 max_virtqueue_pairs;
> >> + /* Default maximum transmit unit advice */
> >> + __u16 mtu;
> >> } __attribute__((packed));
> >>
> >> /*
> >
> > You can't change user visible headers without breaking ABI.
> > This structure might be used by other user code. Also how can this
> > work if host is using old size of structure.
>
> How else can this field be added and remain compliant with the spec? The
> spec requires that mtu be passed in the virtio_net_config field.
>
> As for old sizeof, I think the absence of the VIRTIO_NET_F_MTU bit being
> asserted is confirmation that mtu is not valid (at least, it is implied
> in the spec).
Michael is right as long as the code checks for MTU flag before
referencing the mtu field, everything is fine. Actually, the structure
is never used directly only by fetching fields with offsetof
^ permalink raw reply
* Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory
From: Leo Li @ 2016-03-17 21:33 UTC (permalink / raw)
To: Rob Herring
Cc: Arnd Bergmann, Ulf Hansson, Zhao Qiang, xiaobo.xie,
linux-i2c@vger.kernel.org, linux-clk, Russell King,
Bhupesh Sharma, Joerg Roedel, scott.wood, Claudiu Manoil,
devicetree@vger.kernel.org, Yangbo Lu, Santosh Shilimkar,
linux-arm-kernel@lists.infradead.org, netdev,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Li Yang,
Linux IOMMU, Kumar Gala
In-Reply-To: <CAL_JsqL8NkEQx2NoVHSUGYhtNsybCo-yfBCde+_OuMmfwbhYEw@mail.gmail.com>
On Thu, Mar 17, 2016 at 12:57 PM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Mar 17, 2016 at 12:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thursday 17 March 2016 12:06:40 Rob Herring wrote:
>>> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>>> > similarity index 91%
>>> > rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>>> > rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
>>> > index b71b203..07adca9 100644
>>> > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>>> > +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>>> > @@ -25,6 +25,9 @@ Recommended properties:
>>> > - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
>>> > registers, for those SOCs that have a PAMU device.
>>> >
>>> > + - little-endian : Indicates that the global utilities block is little
>>> > + endian. The default is big endian.
>>>
>>> The default is "the native endianness of the system".
>>
>> This may be what is currently documented, but not what we are doing
>> in practice, as there is no "native endianess" for either PowerPC or
>> ARM -- both allow running big-endian or little-endian kernels and the
>> device registers are fixed.
>
> Notice I said system, not architecture. The way the device registers
> are fixed is what I mean by native endianness.
I think sometimes it's also hard to define the native endianess of the
system too. For whatever reason, we have hardware that having
big-endian registers on some on-chip devices but using little-endian
registers on other devices. Even if all the devices on certain
hardware use registers of the same endianess, it is also hard for the
device driver to know what the native endianess really is.
>
> If the purpose of adding this property now is to support GUTS on the
> ARM SoCs, then I'd argue using this property is probably wrong. If the
> PPC systems are designed with BE device registers and ARM systems with
> LE, then this property is not needed.
>
>> I think the property here is fine.
>
> Unless you have studied the FSL ARM based SoCs, then there is not
> enough information here to tell.
Recent FSL ARM SoCs seems to have more weird endianess issue. :( The
same IP could have registers of different endianess on different ARM
SoCs. That why we need to define the endianess explicitly in device
tree.
Regards,
Leo
^ permalink raw reply
* Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature
From: Aaron Conole @ 2016-03-17 21:24 UTC (permalink / raw)
To: Pankaj Gupta; +Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <1969060351.30231176.1458104130844.JavaMail.zimbra@redhat.com>
Pankaj Gupta <pagupta@redhat.com> writes:
>>
>> The following series adds the ability for a hypervisor to set an MTU on the
>> guest during feature negotiation phase. This is useful for VM orchestration
>> when, for instance, tunneling is involved and the MTU of the various systems
>> should be homogenous.
>>
>> The first patch adds the feature bit as described in the proposed VFIO spec
>
> You mean VIRTIO spec?
Yes, sorry.
>> addition found at
>> https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html
>>
>> The second patch adds a user of the bit, and a warning when the guest changes
>> the MTU from the hypervisor advised MTU. Future patches may add more thorough
>> error handling.
>>
>> v2:
>> * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni
>> * Additional test before printing a warning
>>
>> Aaron Conole (2):
>> virtio: Start feature MTU support
>> virtio_net: Read the advised MTU
>>
>> drivers/net/virtio_net.c | 12 ++++++++++++
>> include/uapi/linux/virtio_net.h | 3 +++
>> 2 files changed, 15 insertions(+)
>>
>> --
>> 2.5.0
>>
>>
^ permalink raw reply
* Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature
From: Aaron Conole @ 2016-03-17 21:24 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <56E87FEC.2030600@hpe.com>
Rick Jones <rick.jones2@hpe.com> writes:
> On 03/15/2016 02:04 PM, Aaron Conole wrote:
>> The following series adds the ability for a hypervisor to set an MTU on the
>> guest during feature negotiation phase. This is useful for VM orchestration
>> when, for instance, tunneling is involved and the MTU of the various systems
>> should be homogenous.
>>
>> The first patch adds the feature bit as described in the proposed VFIO spec
>> addition found at
>> https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html
>>
>> The second patch adds a user of the bit, and a warning when the guest changes
>> the MTU from the hypervisor advised MTU. Future patches may add more thorough
>> error handling.
>
> How do you see this interacting with VMs getting MTU settings via DHCP?
This is intended for networks where the VMs are not given MTU via
DHCP. I don't think it should negatively interfere with such a
network. Does that make sense?
-Aaron
> rick jones
>
>>
>> v2:
>> * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni
>> * Additional test before printing a warning
>>
>> Aaron Conole (2):
>> virtio: Start feature MTU support
>> virtio_net: Read the advised MTU
>>
>> drivers/net/virtio_net.c | 12 ++++++++++++
>> include/uapi/linux/virtio_net.h | 3 +++
>> 2 files changed, 15 insertions(+)
>>
^ permalink raw reply
* Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU
From: Aaron Conole @ 2016-03-17 21:20 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20160316142446.GA4446@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Tue, Mar 15, 2016 at 05:04:13PM -0400, Aaron Conole wrote:
>> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it
>> exists, read the advised MTU and use it.
>>
>> No proper error handling is provided for the case where a user changes the
>> negotiated MTU. A future commit will add proper error handling. Instead, a
>> warning is emitted if the guest changes the device MTU after previously
>> being given advice.
>
> I don't see this as an error. Device might at best give a hint,
> user/network admin always knows best.
>
>>
>> Signed-off-by: Aaron Conole <aconole@bytheb.org>
>> ---
>> v2:
>> * Whitespace cleanup in the last hunk
>> * Code style change around the pr_warn
>> * Additional test for mtu change before printing warning
>>
>> drivers/net/virtio_net.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 767ab11..429fe01 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -146,6 +146,7 @@ struct virtnet_info {
>> virtio_net_ctrl_ack ctrl_status;
>> u8 ctrl_promisc;
>> u8 ctrl_allmulti;
>> + bool negotiated_mtu;
>> };
>>
>> struct padded_vnet_hdr {
>> @@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
>>
>> static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> + struct virtnet_info *vi = netdev_priv(dev);
>> if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
>> return -EINVAL;
>> + if ((vi->negotiated_mtu) && (dev->mtu != new_mtu))
>> + pr_warn("changing mtu while the advised mtu bit exists.");
>
> I don't really see why are we warning here. Just drop this chunk,
> as well as the flag in struct virtnet_info.
Okay. I was warning because the user is changing this after telling to
use something different - but if you don't think it's an error, I will
drop it.
Thanks so much for the review, Michael!
-Aaron
>> dev->mtu = new_mtu;
>> return 0;
>> }
>> @@ -1836,6 +1840,13 @@ static int virtnet_probe(struct virtio_device *vdev)
>> if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
>> vi->has_cvq = true;
>>
>> + if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
>> + vi->negotiated_mtu = true;
>> + dev->mtu = virtio_cread16(vdev,
>> + offsetof(struct virtio_net_config,
>> + mtu));
>> + }
>> +
>> if (vi->any_header_sg)
>> dev->needed_headroom = vi->hdr_len;
>>
>> @@ -2019,6 +2030,7 @@ static unsigned int features[] = {
>> VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
>> VIRTIO_NET_F_CTRL_MAC_ADDR,
>> VIRTIO_F_ANY_LAYOUT,
>> + VIRTIO_NET_F_MTU,
>> };
>>
>> static struct virtio_driver virtio_net_driver = {
>> --
>> 2.5.0
^ permalink raw reply
* Re: Extreme slowness in IPIP tunnel when routing through kernel 3.18 and later
From: Jesse Gross @ 2016-03-17 21:18 UTC (permalink / raw)
To: Patrick Boutilier; +Cc: Linux Kernel Network Developers
In-Reply-To: <56EB1DF3.5000606@ednet.ns.ca>
On Thu, Mar 17, 2016 at 2:13 PM, Patrick Boutilier <boutilpj@ednet.ns.ca> wrote:
> On 03/17/2016 03:27 PM, Jesse Gross wrote:
>>
>> On Thu, Mar 17, 2016 at 7:02 AM, Patrick Boutilier <boutilpj@ednet.ns.ca>
>> wrote:
>>>
>>> I have an IPIP tunnel setup between two hosts in different buildings. The
>>> Linux router they route through causes extreme slowness in the tunnel
>>> when
>>> running kernels from 3.18 on . tcpdump shows many cksum errors which
>>> don't
>>> show up in the 3.17 and earlier kernels. Speed goes back to normal when
>>> rx-checksumming and tx-checksumming are turned off using ethtool on the
>>> Linux router . Would this be an effect of bulk network packet
>>> transmission
>>> that was introduced in 3.18 or some other issue?
>>
>>
>> I just sent out a likely fix, would you mind testing it?
>> https://patchwork.ozlabs.org/patch/599213/
>>
>
> Yes, that patch fixes the problem.
Great, thanks a lot for testing.
^ permalink raw reply
* Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU
From: Aaron Conole @ 2016-03-17 21:15 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <56E9699A.9030908@cogentembedded.com>
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> writes:
> Hello.
>
> On 3/16/2016 12:04 AM, Aaron Conole wrote:
>
>> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it
>> exists, read the advised MTU and use it.
>>
>> No proper error handling is provided for the case where a user changes the
>> negotiated MTU. A future commit will add proper error handling. Instead, a
>> warning is emitted if the guest changes the device MTU after previously
>> being given advice.
>>
>> Signed-off-by: Aaron Conole <aconole@bytheb.org>
>> ---
>> v2:
>> * Whitespace cleanup in the last hunk
>> * Code style change around the pr_warn
>> * Additional test for mtu change before printing warning
>>
>> drivers/net/virtio_net.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 767ab11..429fe01 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
> [...]
>> @@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
>>
>> static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> + struct virtnet_info *vi = netdev_priv(dev);
>> if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
>> return -EINVAL;
>> + if ((vi->negotiated_mtu) && (dev->mtu != new_mtu))
>
> Inner parens not needed, please be consistent with the code above.
Okay, I will do that.
Thanks so much for the review (again), Sergei!
-Aaron
> [...]
>
> MBR, Sergei
^ permalink raw reply
* Re: Extreme slowness in IPIP tunnel when routing through kernel 3.18 and later
From: Patrick Boutilier @ 2016-03-17 21:13 UTC (permalink / raw)
To: Jesse Gross; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAEh+42h0hdNSQDZyHDWHE0qx8bf4AzP0ooaBxPXsj=bf-L5hFQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
On 03/17/2016 03:27 PM, Jesse Gross wrote:
> On Thu, Mar 17, 2016 at 7:02 AM, Patrick Boutilier <boutilpj@ednet.ns.ca> wrote:
>> I have an IPIP tunnel setup between two hosts in different buildings. The
>> Linux router they route through causes extreme slowness in the tunnel when
>> running kernels from 3.18 on . tcpdump shows many cksum errors which don't
>> show up in the 3.17 and earlier kernels. Speed goes back to normal when
>> rx-checksumming and tx-checksumming are turned off using ethtool on the
>> Linux router . Would this be an effect of bulk network packet transmission
>> that was introduced in 3.18 or some other issue?
>
> I just sent out a likely fix, would you mind testing it?
> https://patchwork.ozlabs.org/patch/599213/
>
Yes, that patch fixes the problem.
Thanks.
[-- Attachment #2: boutilpj.vcf --]
[-- Type: text/x-vcard, Size: 286 bytes --]
begin:vcard
fn:Patrick Boutilier
n:Boutilier;Patrick
org:;Nova Scotia Department of Education
adr:;;2021 Brunswick Street;Halifax;NS;B3K 2Y5;Canada
email;internet:boutilpj@ednet.ns.ca
title:WAN Communications Specialist
tel;work:902-424-6800
tel;fax:902-424-0874
version:2.1
end:vcard
^ permalink raw reply
* Re: [RFC v2 -next 1/2] virtio: Start feature MTU support
From: Aaron Conole @ 2016-03-17 21:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <20160316112314.4510d386@samsung9>
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Tue, 15 Mar 2016 17:04:12 -0400
> Aaron Conole <aconole@redhat.com> wrote:
>
>> --- a/include/uapi/linux/virtio_net.h
>> +++ b/include/uapi/linux/virtio_net.h
>> @@ -55,6 +55,7 @@
>> #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
>> * Steering */
>> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>> +#define VIRTIO_NET_F_MTU 25 /* Device supports Default MTU Negotiation */
>>
>> #ifndef VIRTIO_NET_NO_LEGACY
>> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
>> @@ -73,6 +74,8 @@ struct virtio_net_config {
>> * Legal values are between 1 and 0x8000
>> */
>> __u16 max_virtqueue_pairs;
>> + /* Default maximum transmit unit advice */
>> + __u16 mtu;
>> } __attribute__((packed));
>>
>> /*
>
> You can't change user visible headers without breaking ABI.
> This structure might be used by other user code. Also how can this
> work if host is using old size of structure.
How else can this field be added and remain compliant with the spec? The
spec requires that mtu be passed in the virtio_net_config field.
As for old sizeof, I think the absence of the VIRTIO_NET_F_MTU bit being
asserted is confirmation that mtu is not valid (at least, it is implied
in the spec).
Thanks so much for the review, Stephen!
-Aaron
^ permalink raw reply
* Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
From: Florian Fainelli @ 2016-03-17 20:56 UTC (permalink / raw)
To: Murali Karicheri, David Miller, sfeldma; +Cc: netdev, andrew, jiri
In-Reply-To: <56EB0F37.9090908@ti.com>
On March 17, 2016 1:10:31 PM PDT, Murali Karicheri <m-karicheri2@ti.com> wrote:
>David,
>
>On 08/18/2015 04:47 PM, David Miller wrote:
>> I see some drivers where the foo_debugfs.c file is larger than the
>rest
>> of the driver. Once people start using it, it's like crack, and they
>> dump every single debugging widget they found useful at some point
>into
>> there.
>>
>> This is not what we want. Most things I see in debugfs support was
>> probably useful for debugging one particular bug but then it was
>never
>> really useful again in the future. Those kinds of things can be done
>> locally in someone's tree.
>>
>> I often see various kinds of "statistics" ending up in these things,
>> or register dumps, both of which are 'ethtool' or similar material.
>Very late to this discussion, but I need to port some of the internal
>code
>to display the content of a ALE (Address Learning Engine) table
>maintained
>in hardwareat L2 layer. Currently I have a sysfs implementation that
>dumps
>information like below.
>
>root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr:
>ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr:
>08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr:
>01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr:
>d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>
>What is the available interface in kernel to expose this information
>to user space as debugfs is not suggested based on this thread
Using something like bridge fdb show (bridge sub command part of iproute2) would give you most of what you need here, except the port mask (since that is semi implied by which interface you use for dumping) and internal flags about the address validity.
How frequently is this code used once you have a proper switch driver which supports the FDB add/del/dump operations?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
From: Murali Karicheri @ 2016-03-17 20:48 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, sfeldma, netdev, jiri
In-Reply-To: <20160317202519.GA30210@lunn.ch>
On 03/17/2016 04:25 PM, Andrew Lunn wrote:
> On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>> David,
>>
>> On 08/18/2015 04:47 PM, David Miller wrote:
>>> I see some drivers where the foo_debugfs.c file is larger than the rest
>>> of the driver. Once people start using it, it's like crack, and they
>>> dump every single debugging widget they found useful at some point into
>>> there.
>>>
>>> This is not what we want. Most things I see in debugfs support was
>>> probably useful for debugging one particular bug but then it was never
>>> really useful again in the future. Those kinds of things can be done
>>> locally in someone's tree.
>>>
>>> I often see various kinds of "statistics" ending up in these things,
>>> or register dumps, both of which are 'ethtool' or similar material.
>> Very late to this discussion, but I need to port some of the internal code
>> to display the content of a ALE (Address Learning Engine) table maintained
>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>> information like below.
>>
>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>> index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr: ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>> index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr: 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>> index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr: 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>> index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr: d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>>
>> What is the available interface in kernel to expose this information
>> to user space as debugfs is not suggested based on this thread?
>
> This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
> returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
> switchdev_port_obj_dump() in the switchdev ops.
>
Andrew,
Which tool user has to use to get this dump once implemented?
Murali
> Andrew
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: Extreme slowness in IPIP tunnel when routing through kernel 3.18 and later
From: Patrick Boutilier @ 2016-03-17 20:30 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALx6S34YOS=q2-sjK8ZkkRWZ152Y8SBWEP=oxJNM8HTQ-1MhRw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4540 bytes --]
On 03/17/2016 01:47 PM, Tom Herbert wrote:
> On Thu, Mar 17, 2016 at 7:02 AM, Patrick Boutilier <boutilpj@ednet.ns.ca> wrote:
>> I have an IPIP tunnel setup between two hosts in different buildings. The
>> Linux router they route through causes extreme slowness in the tunnel when
>> running kernels from 3.18 on . tcpdump shows many cksum errors which don't
>> show up in the 3.17 and earlier kernels. Speed goes back to normal when
>> rx-checksumming and tx-checksumming are turned off using ethtool on the
>> Linux router . Would this be an effect of bulk network packet transmission
>> that was introduced in 3.18 or some other issue?
>>
> If this is happening on a router then the only case where checksums
> are pertinent should be if GSO/GRO is enabled. Please try disabling
> these. Also, are these showing up as checksum errors on the receiver
> (netstat -s).
Yes, turning off GSO/GRO also fixes the issue.
Not sure which value of netstat I am looking for.
Compiling a new kernel now with Jesse's patch to test. Will report back
in a bit.
>
>
>>
>> eth2
>> driver: igb
>> version: 5.2.15-k
>> firmware-version: 1.5.1
>> bus-info: 0000:06:00.0
>> supports-statistics: yes
>> supports-test: yes
>> supports-eeprom-access: yes
>> supports-register-dump: yes
>> supports-priv-flags: no
>>
>>
>> eth6
>> driver: ixgbe
>> version: 3.19.1-k
>> firmware-version: 0x80000389
>> bus-info: 0000:41:00.0
>> supports-statistics: yes
>> supports-test: yes
>> supports-eeprom-access: yes
>> supports-register-dump: yes
>> supports-priv-flags: no
>>
>>
>>
>>
>>
>> Example of cksum from tcpdump:
>>
>> Flags [.], cksum 0x2237 (incorrect -> 0xbb02), seq 424119200:424120648, ack
>> 1, win 115, options [nop,nop,TS val 303173784 ecr 3971495454], length 1448
>>
>>
>>
>>
>>
>> Results of nuttcp test with rx-checksumming and tx-checksumming on:
>>
>>
>> Testing upload inside tunnel
>>
>>
>>
>> 0.0625 MB / 5.00 sec = 0.1048 Mbps 79 retrans
>> 0.0625 MB / 5.00 sec = 0.1048 Mbps 59 retrans
>> 0.0625 MB / 5.00 sec = 0.1049 Mbps 27 retrans
>>
>> 0.2096 MB / 16.11 sec = 0.1092 Mbps 0 %TX 0 %RX 186 retrans 0.47
>> msRTT
>>
>>
>>
>> Testing download inside tunnel
>>
>>
>>
>> 0.5000 MB / 5.00 sec = 0.8389 Mbps 112 retrans
>> 2.6250 MB / 5.00 sec = 4.4040 Mbps 412 retrans
>> 0.8750 MB / 5.00 sec = 1.4680 Mbps 156 retrans
>>
>> 4.0243 MB / 15.48 sec = 2.1809 Mbps 0 %TX 0 %RX 705 retrans 0.47
>> msRTT
>>
>>
>> Testing upload outside tunnel
>>
>>
>>
>> 423.0000 MB / 5.00 sec = 709.4949 Mbps 275 retrans
>> 442.0625 MB / 5.00 sec = 741.7008 Mbps 53 retrans
>> 418.5625 MB / 5.00 sec = 702.1329 Mbps 133 retrans
>>
>> 1287.0080 MB / 15.08 sec = 715.9252 Mbps 1 %TX 30 %RX 461 retrans 0.43
>> msRTT
>>
>>
>>
>> Testing download outside tunnel
>>
>>
>>
>> 552.4375 MB / 5.00 sec = 926.8347 Mbps 26 retrans
>> 555.1875 MB / 5.00 sec = 931.4499 Mbps 17 retrans
>> 553.0000 MB / 5.00 sec = 927.7802 Mbps 16 retrans
>>
>> 1664.2149 MB / 15.03 sec = 928.6737 Mbps 9 %TX 5 %RX 60 retrans 0.46
>> msRTT
>>
>>
>>
>>
>>
>>
>> Results of nuttcp test with rx-checksumming and tx-checksumming off:
>>
>>
>>
>> Testing upload inside tunnel
>>
>>
>>
>> 440.0000 MB / 5.00 sec = 738.0112 Mbps 117 retrans
>> 433.0000 MB / 5.00 sec = 726.4892 Mbps 135 retrans
>> 447.9375 MB / 5.00 sec = 751.5714 Mbps 112 retrans
>>
>> 1321.0069 MB / 15.04 sec = 736.7213 Mbps 3 %TX 21 %RX 364 retrans 0.51
>> msRTT
>>
>>
>>
>> Testing download inside tunnel
>>
>>
>>
>> 494.0625 MB / 5.00 sec = 828.8973 Mbps 335 retrans
>> 471.0000 MB / 5.00 sec = 790.2050 Mbps 219 retrans
>> 469.8750 MB / 5.00 sec = 788.3174 Mbps 220 retrans
>>
>> 1435.1875 MB / 15.00 sec = 802.4203 Mbps 89 %TX 12 %RX 774 retrans 0.46
>> msRTT
>>
>>
>> Testing upload outside tunnel
>>
>>
>>
>> 431.2500 MB / 5.00 sec = 723.2808 Mbps 33 retrans
>> 446.3750 MB / 5.00 sec = 748.9268 Mbps 10 retrans
>> 475.4375 MB / 5.00 sec = 797.7044 Mbps 0 retrans
>>
>> 1355.0834 MB / 15.06 sec = 754.6438 Mbps 1 %TX 33 %RX 43 retrans 0.53
>> msRTT
>>
>>
>>
>> Testing download outside tunnel
>>
>>
>>
>> 424.8125 MB / 5.00 sec = 712.7061 Mbps 102 retrans
>> 456.5625 MB / 5.00 sec = 765.9872 Mbps 80 retrans
>> 454.0000 MB / 5.00 sec = 761.6935 Mbps 116 retrans
>>
>> 1335.7823 MB / 15.01 sec = 746.6959 Mbps 4 %TX 5 %RX 298 retrans 0.55
>> msRTT
[-- Attachment #2: boutilpj.vcf --]
[-- Type: text/x-vcard, Size: 286 bytes --]
begin:vcard
fn:Patrick Boutilier
n:Boutilier;Patrick
org:;Nova Scotia Department of Education
adr:;;2021 Brunswick Street;Halifax;NS;B3K 2Y5;Canada
email;internet:boutilpj@ednet.ns.ca
title:WAN Communications Specialist
tel;work:902-424-6800
tel;fax:902-424-0874
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
From: Andrew Lunn @ 2016-03-17 20:25 UTC (permalink / raw)
To: Murali Karicheri; +Cc: David Miller, sfeldma, netdev, jiri
In-Reply-To: <56EB0F37.9090908@ti.com>
On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
> David,
>
> On 08/18/2015 04:47 PM, David Miller wrote:
> > I see some drivers where the foo_debugfs.c file is larger than the rest
> > of the driver. Once people start using it, it's like crack, and they
> > dump every single debugging widget they found useful at some point into
> > there.
> >
> > This is not what we want. Most things I see in debugfs support was
> > probably useful for debugging one particular bug but then it was never
> > really useful again in the future. Those kinds of things can be done
> > locally in someone's tree.
> >
> > I often see various kinds of "statistics" ending up in these things,
> > or register dumps, both of which are 'ethtool' or similar material.
> Very late to this discussion, but I need to port some of the internal code
> to display the content of a ALE (Address Learning Engine) table maintained
> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
> information like below.
>
> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
> index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr: ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
> index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr: 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
> index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr: 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
> index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr: d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>
> What is the available interface in kernel to expose this information
> to user space as debugfs is not suggested based on this thread?
This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
switchdev_port_obj_dump() in the switchdev ops.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
From: Murali Karicheri @ 2016-03-17 20:10 UTC (permalink / raw)
To: David Miller, sfeldma; +Cc: netdev, andrew, jiri
In-Reply-To: <20150818.134720.1520233036019988872.davem@davemloft.net>
David,
On 08/18/2015 04:47 PM, David Miller wrote:
> I see some drivers where the foo_debugfs.c file is larger than the rest
> of the driver. Once people start using it, it's like crack, and they
> dump every single debugging widget they found useful at some point into
> there.
>
> This is not what we want. Most things I see in debugfs support was
> probably useful for debugging one particular bug but then it was never
> really useful again in the future. Those kinds of things can be done
> locally in someone's tree.
>
> I often see various kinds of "statistics" ending up in these things,
> or register dumps, both of which are 'ethtool' or similar material.
Very late to this discussion, but I need to port some of the internal code
to display the content of a ALE (Address Learning Engine) table maintained
in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
information like below.
root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr: ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr: 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr: 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr: d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
What is the available interface in kernel to expose this information
to user space as debugfs is not suggested based on this thread?
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* [iproute PATCH v2] Use ARRAY_SIZE macro everywhere
From: Phil Sutter @ 2016-03-17 19:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20160317193740.GC5652@orbyte.nwl.cc>
This patch was generated by the following semantic patch (a trimmed down
version of what is shipped with Linux sources):
@@
type T;
T[] E;
@@
(
- (sizeof(E)/sizeof(*E))
+ ARRAY_SIZE(E)
|
- (sizeof(E)/sizeof(E[...]))
+ ARRAY_SIZE(E)
|
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
)
The only manual adjustment was to include utils.h in misc/nstat.c to make
the macro known there.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
Changes since v1:
- Rebased upon current master to avoid merge conflicts.
---
bridge/link.c | 6 +++---
ip/ipaddress.c | 6 +++---
ip/iplink_bond_slave.c | 4 ++--
misc/nstat.c | 3 ++-
misc/ss.c | 2 +-
tc/em_meta.c | 6 +++---
tc/f_u32.c | 2 +-
7 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index a9b1262dfdc2d..7ecc67f34b349 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -69,7 +69,7 @@ static const char *hw_mode[] = {"VEB", "VEPA"};
static void print_operstate(FILE *f, __u8 state)
{
- if (state >= sizeof(oper_states)/sizeof(oper_states[0]))
+ if (state >= ARRAY_SIZE(oper_states))
fprintf(f, "state %#x ", state);
else
fprintf(f, "state %s ", oper_states[state]);
@@ -90,7 +90,7 @@ static void print_onoff(FILE *f, char *flag, __u8 val)
static void print_hwmode(FILE *f, __u16 mode)
{
- if (mode >= sizeof(hw_mode)/sizeof(hw_mode[0]))
+ if (mode >= ARRAY_SIZE(hw_mode))
fprintf(f, "hwmode %#hx ", mode);
else
fprintf(f, "hwmode %s ", hw_mode[mode]);
@@ -318,7 +318,7 @@ static int brlink_modify(int argc, char **argv)
} else if (strcmp(*argv, "state") == 0) {
NEXT_ARG();
char *endptr;
- size_t nstates = sizeof(port_states) / sizeof(*port_states);
+ size_t nstates = ARRAY_SIZE(port_states);
state = strtol(*argv, &endptr, 10);
if (!(**argv != '\0' && *endptr == '\0')) {
for (state = 0; state < nstates; state++)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 9d254d27bc1bb..0b855a6f8c7cc 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -135,7 +135,7 @@ static const char *oper_states[] = {
static void print_operstate(FILE *f, __u8 state)
{
- if (state >= sizeof(oper_states)/sizeof(oper_states[0]))
+ if (state >= ARRAY_SIZE(oper_states))
fprintf(f, "state %#x ", state);
else {
if (brief) {
@@ -161,7 +161,7 @@ int get_operstate(const char *name)
{
int i;
- for (i = 0; i < sizeof(oper_states)/sizeof(oper_states[0]); i++)
+ for (i = 0; i < ARRAY_SIZE(oper_states); i++)
if (strcasecmp(name, oper_states[i]) == 0)
return i;
return -1;
@@ -202,7 +202,7 @@ static void print_linkmode(FILE *f, struct rtattr *tb)
{
unsigned int mode = rta_getattr_u8(tb);
- if (mode >= sizeof(link_modes) / sizeof(link_modes[0]))
+ if (mode >= ARRAY_SIZE(link_modes))
fprintf(f, "mode %d ", mode);
else
fprintf(f, "mode %s ", link_modes[mode]);
diff --git a/ip/iplink_bond_slave.c b/ip/iplink_bond_slave.c
index 2f3364ee45a54..d67793237edfc 100644
--- a/ip/iplink_bond_slave.c
+++ b/ip/iplink_bond_slave.c
@@ -26,7 +26,7 @@ static void print_slave_state(FILE *f, struct rtattr *tb)
{
unsigned int state = rta_getattr_u8(tb);
- if (state >= sizeof(slave_states) / sizeof(slave_states[0]))
+ if (state >= ARRAY_SIZE(slave_states))
fprintf(f, "state %d ", state);
else
fprintf(f, "state %s ", slave_states[state]);
@@ -43,7 +43,7 @@ static void print_slave_mii_status(FILE *f, struct rtattr *tb)
{
unsigned int status = rta_getattr_u8(tb);
- if (status >= sizeof(slave_mii_status) / sizeof(slave_mii_status[0]))
+ if (status >= ARRAY_SIZE(slave_mii_status))
fprintf(f, "mii_status %d ", status);
else
fprintf(f, "mii_status %s ", slave_mii_status[status]);
diff --git a/misc/nstat.c b/misc/nstat.c
index 22b27eba7c8f6..cc19b1cd89356 100644
--- a/misc/nstat.c
+++ b/misc/nstat.c
@@ -27,6 +27,7 @@
#include <signal.h>
#include <math.h>
#include <getopt.h>
+#include <utils.h>
#include <json_writer.h>
#include <SNAPSHOT.h>
@@ -94,7 +95,7 @@ static const char *useless_numbers[] = {
static int useless_number(const char *id)
{
int i;
- for (i=0; i<sizeof(useless_numbers)/sizeof(*useless_numbers); i++)
+ for (i=0; i<ARRAY_SIZE(useless_numbers); i++)
if (strcmp(id, useless_numbers[i]) == 0)
return 1;
return 0;
diff --git a/misc/ss.c b/misc/ss.c
index 13fcc8f661e52..0144dc10e4b45 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -668,7 +668,7 @@ static int get_slabstat(struct slabstat *s)
}
while(fgets(buf, sizeof(buf), fp) != NULL) {
int i;
- for (i=0; i<sizeof(slabstat_ids)/sizeof(slabstat_ids[0]); i++) {
+ for (i=0; i<ARRAY_SIZE(slabstat_ids); i++) {
if (memcmp(buf, slabstat_ids[i], strlen(slabstat_ids[i])) == 0) {
sscanf(buf, "%*s%d", ((int *)s) + i);
cnt--;
diff --git a/tc/em_meta.c b/tc/em_meta.c
index b64f333e5cb5b..bc871315d1d18 100644
--- a/tc/em_meta.c
+++ b/tc/em_meta.c
@@ -126,7 +126,7 @@ static struct meta_entry * lookup_meta_entry(struct bstr *kind)
{
int i;
- for (i = 0; i < (sizeof(meta_table)/sizeof(meta_table[0])); i++)
+ for (i = 0; i < ARRAY_SIZE(meta_table); i++)
if (!bstrcmp(kind, meta_table[i].kind) &&
meta_table[i].id != 0)
return &meta_table[i];
@@ -138,7 +138,7 @@ static struct meta_entry * lookup_meta_entry_byid(int id)
{
int i;
- for (i = 0; i < (sizeof(meta_table)/sizeof(meta_table[0])); i++)
+ for (i = 0; i < ARRAY_SIZE(meta_table); i++)
if (meta_table[i].id == id)
return &meta_table[i];
@@ -192,7 +192,7 @@ static void list_meta_ids(FILE *fd)
" ID Type Description\n" \
"--------------------------------------------------------");
- for (i = 0; i < (sizeof(meta_table)/sizeof(meta_table[0])); i++) {
+ for (i = 0; i < ARRAY_SIZE(meta_table); i++) {
if (meta_table[i].id == TCF_META_ID_SECTION) {
fprintf(fd, "\n%s:\n", meta_table[i].kind);
} else {
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 0b97678933a62..0fb671072b793 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -958,7 +958,7 @@ static void show_keys(FILE *f, const struct tc_u32_key *key)
if (!show_pretty)
goto show_k;
- for (i = 0; i < sizeof(u32_pprinters) / sizeof(u32_pprinters[0]); i++) {
+ for (i = 0; i < ARRAY_SIZE(u32_pprinters); i++) {
if (u32_pprinters[i].proto == ntohs(f_proto)) {
show_k:
u32_pprinters[i].pprinter(f, key);
--
2.7.2
^ permalink raw reply related
* Re: [iproute PATCH] Use ARRAY_SIZE macro everywhere
From: Phil Sutter @ 2016-03-17 19:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <1458242888-28978-1-git-send-email-phil@nwl.cc>
On Thu, Mar 17, 2016 at 08:28:08PM +0100, Phil Sutter wrote:
> This patch was generated by the following semantic patch (a trimmed down
> version of what is shipped with Linux sources):
And it was extracted from a tree with previous commits applied, sadly
interfering with context here. Therefore it won't apply cleanly to
master. Please ignore, I will resend a fixed version.
Sorry for the noise,
Phil
^ permalink raw reply
* [iproute PATCH] Use ARRAY_SIZE macro everywhere
From: Phil Sutter @ 2016-03-17 19:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
This patch was generated by the following semantic patch (a trimmed down
version of what is shipped with Linux sources):
@@
type T;
T[] E;
@@
(
- (sizeof(E)/sizeof(*E))
+ ARRAY_SIZE(E)
|
- (sizeof(E)/sizeof(E[...]))
+ ARRAY_SIZE(E)
|
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
)
The only manual adjustment was to include utils.h in misc/nstat.c to make
the macro known there.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
bridge/link.c | 6 +++---
ip/ipaddress.c | 6 +++---
ip/iplink_bond_slave.c | 4 ++--
misc/nstat.c | 3 ++-
misc/ss.c | 2 +-
tc/em_meta.c | 6 +++---
tc/f_u32.c | 2 +-
7 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index a9b1262dfdc2d..7ecc67f34b349 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -69,7 +69,7 @@ static const char *hw_mode[] = {"VEB", "VEPA"};
static void print_operstate(FILE *f, __u8 state)
{
- if (state >= sizeof(oper_states)/sizeof(oper_states[0]))
+ if (state >= ARRAY_SIZE(oper_states))
fprintf(f, "state %#x ", state);
else
fprintf(f, "state %s ", oper_states[state]);
@@ -90,7 +90,7 @@ static void print_onoff(FILE *f, char *flag, __u8 val)
static void print_hwmode(FILE *f, __u16 mode)
{
- if (mode >= sizeof(hw_mode)/sizeof(hw_mode[0]))
+ if (mode >= ARRAY_SIZE(hw_mode))
fprintf(f, "hwmode %#hx ", mode);
else
fprintf(f, "hwmode %s ", hw_mode[mode]);
@@ -318,7 +318,7 @@ static int brlink_modify(int argc, char **argv)
} else if (strcmp(*argv, "state") == 0) {
NEXT_ARG();
char *endptr;
- size_t nstates = sizeof(port_states) / sizeof(*port_states);
+ size_t nstates = ARRAY_SIZE(port_states);
state = strtol(*argv, &endptr, 10);
if (!(**argv != '\0' && *endptr == '\0')) {
for (state = 0; state < nstates; state++)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 73505d1769b6c..6f967a0329b49 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -135,7 +135,7 @@ static const char *oper_states[] = {
static void print_operstate(FILE *f, __u8 state)
{
- if (state >= sizeof(oper_states)/sizeof(oper_states[0])) {
+ if (state >= ARRAY_SIZE(oper_states)) {
fprintf(f, "state %#x ", state);
} else if (brief) {
color_fprintf(f, oper_state_color(state),
@@ -151,7 +151,7 @@ int get_operstate(const char *name)
{
int i;
- for (i = 0; i < sizeof(oper_states)/sizeof(oper_states[0]); i++)
+ for (i = 0; i < ARRAY_SIZE(oper_states); i++)
if (strcasecmp(name, oper_states[i]) == 0)
return i;
return -1;
@@ -192,7 +192,7 @@ static void print_linkmode(FILE *f, struct rtattr *tb)
{
unsigned int mode = rta_getattr_u8(tb);
- if (mode >= sizeof(link_modes) / sizeof(link_modes[0]))
+ if (mode >= ARRAY_SIZE(link_modes))
fprintf(f, "mode %d ", mode);
else
fprintf(f, "mode %s ", link_modes[mode]);
diff --git a/ip/iplink_bond_slave.c b/ip/iplink_bond_slave.c
index 2f3364ee45a54..d67793237edfc 100644
--- a/ip/iplink_bond_slave.c
+++ b/ip/iplink_bond_slave.c
@@ -26,7 +26,7 @@ static void print_slave_state(FILE *f, struct rtattr *tb)
{
unsigned int state = rta_getattr_u8(tb);
- if (state >= sizeof(slave_states) / sizeof(slave_states[0]))
+ if (state >= ARRAY_SIZE(slave_states))
fprintf(f, "state %d ", state);
else
fprintf(f, "state %s ", slave_states[state]);
@@ -43,7 +43,7 @@ static void print_slave_mii_status(FILE *f, struct rtattr *tb)
{
unsigned int status = rta_getattr_u8(tb);
- if (status >= sizeof(slave_mii_status) / sizeof(slave_mii_status[0]))
+ if (status >= ARRAY_SIZE(slave_mii_status))
fprintf(f, "mii_status %d ", status);
else
fprintf(f, "mii_status %s ", slave_mii_status[status]);
diff --git a/misc/nstat.c b/misc/nstat.c
index 22b27eba7c8f6..cc19b1cd89356 100644
--- a/misc/nstat.c
+++ b/misc/nstat.c
@@ -27,6 +27,7 @@
#include <signal.h>
#include <math.h>
#include <getopt.h>
+#include <utils.h>
#include <json_writer.h>
#include <SNAPSHOT.h>
@@ -94,7 +95,7 @@ static const char *useless_numbers[] = {
static int useless_number(const char *id)
{
int i;
- for (i=0; i<sizeof(useless_numbers)/sizeof(*useless_numbers); i++)
+ for (i=0; i<ARRAY_SIZE(useless_numbers); i++)
if (strcmp(id, useless_numbers[i]) == 0)
return 1;
return 0;
diff --git a/misc/ss.c b/misc/ss.c
index c1026a9de6997..24d1b28602a69 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -668,7 +668,7 @@ static int get_slabstat(struct slabstat *s)
}
while(fgets(buf, sizeof(buf), fp) != NULL) {
int i;
- for (i=0; i<sizeof(slabstat_ids)/sizeof(slabstat_ids[0]); i++) {
+ for (i=0; i<ARRAY_SIZE(slabstat_ids); i++) {
if (memcmp(buf, slabstat_ids[i], strlen(slabstat_ids[i])) == 0) {
sscanf(buf, "%*s%d", ((int *)s) + i);
cnt--;
diff --git a/tc/em_meta.c b/tc/em_meta.c
index b64f333e5cb5b..bc871315d1d18 100644
--- a/tc/em_meta.c
+++ b/tc/em_meta.c
@@ -126,7 +126,7 @@ static struct meta_entry * lookup_meta_entry(struct bstr *kind)
{
int i;
- for (i = 0; i < (sizeof(meta_table)/sizeof(meta_table[0])); i++)
+ for (i = 0; i < ARRAY_SIZE(meta_table); i++)
if (!bstrcmp(kind, meta_table[i].kind) &&
meta_table[i].id != 0)
return &meta_table[i];
@@ -138,7 +138,7 @@ static struct meta_entry * lookup_meta_entry_byid(int id)
{
int i;
- for (i = 0; i < (sizeof(meta_table)/sizeof(meta_table[0])); i++)
+ for (i = 0; i < ARRAY_SIZE(meta_table); i++)
if (meta_table[i].id == id)
return &meta_table[i];
@@ -192,7 +192,7 @@ static void list_meta_ids(FILE *fd)
" ID Type Description\n" \
"--------------------------------------------------------");
- for (i = 0; i < (sizeof(meta_table)/sizeof(meta_table[0])); i++) {
+ for (i = 0; i < ARRAY_SIZE(meta_table); i++) {
if (meta_table[i].id == TCF_META_ID_SECTION) {
fprintf(fd, "\n%s:\n", meta_table[i].kind);
} else {
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 0b97678933a62..0fb671072b793 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -958,7 +958,7 @@ static void show_keys(FILE *f, const struct tc_u32_key *key)
if (!show_pretty)
goto show_k;
- for (i = 0; i < sizeof(u32_pprinters) / sizeof(u32_pprinters[0]); i++) {
+ for (i = 0; i < ARRAY_SIZE(u32_pprinters); i++) {
if (u32_pprinters[i].proto == ntohs(f_proto)) {
show_k:
u32_pprinters[i].pprinter(f, key);
--
2.7.2
^ permalink raw reply related
* [PATCH v2 ethtool 2/2] Documentation for IPv6 NFC
From: Edward Cree @ 2016-03-17 19:17 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <56EB00D6.3060003@solarflare.com>
Leaves 'src-ip' and 'dst-ip' documented as taking x.x.x.x, because there's
more low-level nroff here than I can parse, let alone emit.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
ethtool.8.in | 29 ++++++++++++++++++++---------
ethtool.c | 4 +++-
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/ethtool.8.in b/ethtool.8.in
index 009711d..36da10e 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -74,7 +74,7 @@
.\"
.\" \(*NC - Network Classifier type values
.\"
-.ds NC \fBether\fP|\fBip4\fP|\fBtcp4\fP|\fBudp4\fP|\fBsctp4\fP|\fBah4\fP|\fBesp4\fP
+.ds NC \fBether\fP|\fBip4\fP|\fBtcp4\fP|\fBudp4\fP|\fBsctp4\fP|\fBah4\fP|\fBesp4\fP|\fBip6\fP|\fBtcp6\fP|\fBudp6\fP|\fBah6\fP|\fBesp6\fP|\fBsctp6\fP
..
.\"
.\" Start URL.
@@ -263,6 +263,7 @@ ethtool \- query or control network driver and hardware settings
.RB [ src\-ip \ \*(PA\ [ m \ \*(PA]]
.RB [ dst\-ip \ \*(PA\ [ m \ \*(PA]]
.BM tos
+.BM tclass
.BM l4proto
.BM src\-port
.BM dst\-port
@@ -710,6 +711,12 @@ udp4 UDP over IPv4
sctp4 SCTP over IPv4
ah4 IPSEC AH over IPv4
esp4 IPSEC ESP over IPv4
+ip6 Raw IPv6
+tcp6 TCP over IPv6
+udp6 UDP over IPv6
+sctp6 SCTP over IPv6
+ah6 IPSEC AH over IPv6
+esp6 IPSEC ESP over IPv6
.TE
.PP
For all fields that allow both a value and a mask to be specified, the
@@ -734,38 +741,42 @@ Valid only for flow-type ether.
.TP
.BR src\-ip \ \*(PA\ [ m \ \*(PA]
Specify the source IP address of the incoming packet to match along with
-an optional mask. Valid for all IPv4 based flow-types.
+an optional mask. Valid for all IP based flow-types.
.TP
.BR dst\-ip \ \*(PA\ [ m \ \*(PA]
Specify the destination IP address of the incoming packet to match along
-with an optional mask. Valid for all IPv4 based flow-types.
+with an optional mask. Valid for all IP based flow-types.
.TP
.BI tos \ N \\fR\ [\\fPm \ N \\fR]\\fP
Specify the value of the Type of Service field in the incoming packet to
match along with an optional mask. Applies to all IPv4 based flow-types.
.TP
+.BI tclass \ N \\fR\ [\\fPm \ N \\fR]\\fP
+Specify the value of the Traffic Class field in the incoming packet to
+match along with an optional mask. Applies to all IPv6 based flow-types.
+.TP
.BI l4proto \ N \\fR\ [\\fPm \ N \\fR]\\fP
Includes the layer 4 protocol number and optional mask. Valid only for
-flow-type ip4.
+flow-types ip4 and ip6.
.TP
.BI src\-port \ N \\fR\ [\\fPm \ N \\fR]\\fP
Specify the value of the source port field (applicable to TCP/UDP packets)
in the incoming packet to match along with an optional mask. Valid for
-flow-types ip4, tcp4, udp4, and sctp4.
+flow-types ip4, tcp4, udp4, and sctp4 and their IPv6 equivalents.
.TP
.BI dst\-port \ N \\fR\ [\\fPm \ N \\fR]\\fP
Specify the value of the destination port field (applicable to TCP/UDP
packets)in the incoming packet to match along with an optional mask.
-Valid for flow-types ip4, tcp4, udp4, and sctp4.
+Valid for flow-types ip4, tcp4, udp4, and sctp4 and their IPv6 equivalents.
.TP
.BI spi \ N \\fR\ [\\fPm \ N \\fR]\\fP
Specify the value of the security parameter index field (applicable to
AH/ESP packets)in the incoming packet to match along with an optional
-mask. Valid for flow-types ip4, ah4, and esp4.
+mask. Valid for flow-types ip4, ah4, and esp4 and their IPv6 equivalents.
.TP
.BI l4data \ N \\fR\ [\\fPm \ N \\fR]\\fP
Specify the value of the first 4 Bytes of Layer 4 in the incoming packet to
-match along with an optional mask. Valid for ip4 flow-type.
+match along with an optional mask. Valid for ip4 and ip6 flow-types.
.TP
.BI vlan\-etype \ N \\fR\ [\\fPm \ N \\fR]\\fP
Includes the VLAN tag Ethertype and an optional mask.
@@ -779,7 +790,7 @@ Includes 64-bits of user-specific data and an optional mask.
.BR dst-mac \ \*(MA\ [ m \ \*(MA]
Includes the destination MAC address, specified as 6 bytes in hexadecimal
separated by colons, along with an optional mask.
-Valid for all IPv4 based flow-types.
+Valid for all IP based flow-types.
.TP
.BI action \ N
Specifies the Rx queue to send packets to, or some other action.
diff --git a/ethtool.c b/ethtool.c
index b476dcc..a92137f 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4158,13 +4158,15 @@ static const struct option {
"Configure Rx network flow classification options or rules",
" rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|"
"tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r... |\n"
- " flow-type ether|ip4|tcp4|udp4|sctp4|ah4|esp4\n"
+ " flow-type ether|ip4|tcp4|udp4|sctp4|ah4|esp4|"
+ "ip6|tcp6|udp6|ah6|esp6|sctp6\n"
" [ src %x:%x:%x:%x:%x:%x [m %x:%x:%x:%x:%x:%x] ]\n"
" [ dst %x:%x:%x:%x:%x:%x [m %x:%x:%x:%x:%x:%x] ]\n"
" [ proto %d [m %x] ]\n"
" [ src-ip %d.%d.%d.%d [m %d.%d.%d.%d] ]\n"
" [ dst-ip %d.%d.%d.%d [m %d.%d.%d.%d] ]\n"
" [ tos %d [m %x] ]\n"
+ " [ tclass %d [m %x] ]\n"
" [ l4proto %d [m %x] ]\n"
" [ src-port %d [m %x] ]\n"
" [ dst-port %d [m %x] ]\n"
^ permalink raw reply related
* [PATCH v2 ethtool 1/2] Add IPv6 support to NFC
From: Edward Cree @ 2016-03-17 19:17 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <56EB00D6.3060003@solarflare.com>
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
ethtool.c | 21 +++++
rxclass.c | 267 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 274 insertions(+), 14 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 0cd0d4f..b476dcc 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -32,6 +32,7 @@
#include <sys/stat.h>
#include <stdio.h>
#include <stddef.h>
+#include <stdbool.h>
#include <errno.h>
#include <sys/utsname.h>
#include <limits.h>
@@ -3540,6 +3541,22 @@ static int do_permaddr(struct cmd_context *ctx)
return err;
}
+static bool flow_type_is_ntuple_supported(__u32 flow_type)
+{
+ switch (flow_type) {
+ case TCP_V4_FLOW:
+ case UDP_V4_FLOW:
+ case SCTP_V4_FLOW:
+ case AH_V4_FLOW:
+ case ESP_V4_FLOW:
+ case IPV4_USER_FLOW:
+ case ETHER_FLOW:
+ return true;
+ default:
+ return false;
+ }
+}
+
static int flow_spec_to_ntuple(struct ethtool_rx_flow_spec *fsp,
struct ethtool_rx_ntuple_flow_spec *ntuple)
{
@@ -3563,6 +3580,10 @@ static int flow_spec_to_ntuple(struct ethtool_rx_flow_spec *fsp,
fsp->m_ext.vlan_etype)
return -1;
+ /* IPv6 flow types are not supported by ntuple */
+ if (!flow_type_is_ntuple_supported(fsp->flow_type & ~FLOW_EXT))
+ return -1;
+
/* Set entire ntuple to ~0 to guarantee all masks are set */
memset(ntuple, ~0, sizeof(*ntuple));
diff --git a/rxclass.c b/rxclass.c
index cd686a3..c7bfeba 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -39,6 +39,25 @@ static void rxclass_print_ipv4_rule(__be32 sip, __be32 sipm, __be32 dip,
tos, tosm);
}
+static void rxclass_print_ipv6_rule(__be32 *sip, __be32 *sipm, __be32 *dip,
+ __be32 *dipm, u8 tclass, u8 tclassm)
+{
+ char sip_str[INET6_ADDRSTRLEN];
+ char sipm_str[INET6_ADDRSTRLEN];
+ char dip_str[INET6_ADDRSTRLEN];
+ char dipm_str[INET6_ADDRSTRLEN];
+
+ fprintf(stdout,
+ "\tSrc IP addr: %s mask: %s\n"
+ "\tDest IP addr: %s mask: %s\n"
+ "\tTraffic Class: 0x%x mask: 0x%x\n",
+ inet_ntop(AF_INET6, sip, sip_str, INET6_ADDRSTRLEN),
+ inet_ntop(AF_INET6, sipm, sipm_str, INET6_ADDRSTRLEN),
+ inet_ntop(AF_INET6, dip, dip_str, INET6_ADDRSTRLEN),
+ inet_ntop(AF_INET6, dipm, dipm_str, INET6_ADDRSTRLEN),
+ tclass, tclassm);
+}
+
static void rxclass_print_nfc_spec_ext(struct ethtool_rx_flow_spec *fsp)
{
if (fsp->flow_type & FLOW_EXT) {
@@ -127,7 +146,7 @@ static void rxclass_print_nfc_rule(struct ethtool_rx_flow_spec *fsp)
ntohl(fsp->h_u.esp_ip4_spec.spi),
ntohl(fsp->m_u.esp_ip4_spec.spi));
break;
- case IP_USER_FLOW:
+ case IPV4_USER_FLOW:
fprintf(stdout, "\tRule Type: Raw IPv4\n");
rxclass_print_ipv4_rule(fsp->h_u.usr_ip4_spec.ip4src,
fsp->m_u.usr_ip4_spec.ip4src,
@@ -143,6 +162,62 @@ static void rxclass_print_nfc_rule(struct ethtool_rx_flow_spec *fsp)
ntohl(fsp->h_u.usr_ip4_spec.l4_4_bytes),
ntohl(fsp->m_u.usr_ip4_spec.l4_4_bytes));
break;
+ case TCP_V6_FLOW:
+ case UDP_V6_FLOW:
+ case SCTP_V6_FLOW:
+ if (flow_type == TCP_V6_FLOW)
+ fprintf(stdout, "\tRule Type: TCP over IPv6\n");
+ else if (flow_type == UDP_V6_FLOW)
+ fprintf(stdout, "\tRule Type: UDP over IPv6\n");
+ else
+ fprintf(stdout, "\tRule Type: SCTP over IPv6\n");
+ rxclass_print_ipv6_rule(fsp->h_u.tcp_ip6_spec.ip6src,
+ fsp->m_u.tcp_ip6_spec.ip6src,
+ fsp->h_u.tcp_ip6_spec.ip6dst,
+ fsp->m_u.tcp_ip6_spec.ip6dst,
+ fsp->h_u.tcp_ip6_spec.tclass,
+ fsp->m_u.tcp_ip6_spec.tclass);
+ fprintf(stdout,
+ "\tSrc port: %d mask: 0x%x\n"
+ "\tDest port: %d mask: 0x%x\n",
+ ntohs(fsp->h_u.tcp_ip6_spec.psrc),
+ ntohs(fsp->m_u.tcp_ip6_spec.psrc),
+ ntohs(fsp->h_u.tcp_ip6_spec.pdst),
+ ntohs(fsp->m_u.tcp_ip6_spec.pdst));
+ break;
+ case AH_V6_FLOW:
+ case ESP_V6_FLOW:
+ if (flow_type == AH_V6_FLOW)
+ fprintf(stdout, "\tRule Type: IPSEC AH over IPv6\n");
+ else
+ fprintf(stdout, "\tRule Type: IPSEC ESP over IPv6\n");
+ rxclass_print_ipv6_rule(fsp->h_u.ah_ip6_spec.ip6src,
+ fsp->m_u.ah_ip6_spec.ip6src,
+ fsp->h_u.ah_ip6_spec.ip6dst,
+ fsp->m_u.ah_ip6_spec.ip6dst,
+ fsp->h_u.ah_ip6_spec.tclass,
+ fsp->m_u.ah_ip6_spec.tclass);
+ fprintf(stdout,
+ "\tSPI: %d mask: 0x%x\n",
+ ntohl(fsp->h_u.esp_ip6_spec.spi),
+ ntohl(fsp->m_u.esp_ip6_spec.spi));
+ break;
+ case IPV6_USER_FLOW:
+ fprintf(stdout, "\tRule Type: Raw IPv6\n");
+ rxclass_print_ipv6_rule(fsp->h_u.usr_ip6_spec.ip6src,
+ fsp->m_u.usr_ip6_spec.ip6src,
+ fsp->h_u.usr_ip6_spec.ip6dst,
+ fsp->m_u.usr_ip6_spec.ip6dst,
+ fsp->h_u.usr_ip6_spec.tclass,
+ fsp->m_u.usr_ip6_spec.tclass);
+ fprintf(stdout,
+ "\tProtocol: %d mask: 0x%x\n"
+ "\tL4 bytes: 0x%x mask: 0x%x\n",
+ fsp->h_u.usr_ip6_spec.l4_proto,
+ fsp->m_u.usr_ip6_spec.l4_proto,
+ ntohl(fsp->h_u.usr_ip6_spec.l4_4_bytes),
+ ntohl(fsp->m_u.usr_ip6_spec.l4_4_bytes));
+ break;
case ETHER_FLOW:
dmac = fsp->h_u.ether_spec.h_dest;
dmacm = fsp->m_u.ether_spec.h_dest;
@@ -190,21 +265,20 @@ static void rxclass_print_rule(struct ethtool_rx_flow_spec *fsp)
case SCTP_V4_FLOW:
case AH_V4_FLOW:
case ESP_V4_FLOW:
- case ETHER_FLOW:
- rxclass_print_nfc_rule(fsp);
- break;
- case IP_USER_FLOW:
- if (fsp->h_u.usr_ip4_spec.ip_ver == ETH_RX_NFC_IP4) {
- rxclass_print_nfc_rule(fsp);
- break;
- }
- /* IPv6 User Flow falls through to the case below */
case TCP_V6_FLOW:
case UDP_V6_FLOW:
case SCTP_V6_FLOW:
case AH_V6_FLOW:
case ESP_V6_FLOW:
- fprintf(stderr, "IPv6 flows not implemented\n");
+ case IPV6_USER_FLOW:
+ case ETHER_FLOW:
+ rxclass_print_nfc_rule(fsp);
+ break;
+ case IPV4_USER_FLOW:
+ if (fsp->h_u.usr_ip4_spec.ip_ver == ETH_RX_NFC_IP4)
+ rxclass_print_nfc_rule(fsp);
+ else /* IPv6 uses IPV6_USER_FLOW */
+ fprintf(stderr, "IPV4_USER_FLOW with wrong ip_ver\n");
break;
default:
fprintf(stderr, "rxclass: Unknown flow type\n");
@@ -530,6 +604,7 @@ typedef enum {
OPT_BE32,
OPT_BE64,
OPT_IP4,
+ OPT_IP6,
OPT_MAC,
} rule_opt_type_t;
@@ -663,6 +738,114 @@ static const struct rule_opts rule_nfc_usr_ip4[] = {
offsetof(struct ethtool_rx_flow_spec, m_ext.h_dest) },
};
+static const struct rule_opts rule_nfc_tcp_ip6[] = {
+ { "src-ip", OPT_IP6, NFC_FLAG_SADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_u.tcp_ip6_spec.ip6src),
+ offsetof(struct ethtool_rx_flow_spec, m_u.tcp_ip6_spec.ip6src) },
+ { "dst-ip", OPT_IP6, NFC_FLAG_DADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_u.tcp_ip6_spec.ip6dst),
+ offsetof(struct ethtool_rx_flow_spec, m_u.tcp_ip6_spec.ip6dst) },
+ { "tclass", OPT_U8, NFC_FLAG_TOS,
+ offsetof(struct ethtool_rx_flow_spec, h_u.tcp_ip6_spec.tclass),
+ offsetof(struct ethtool_rx_flow_spec, m_u.tcp_ip6_spec.tclass) },
+ { "src-port", OPT_BE16, NFC_FLAG_SPORT,
+ offsetof(struct ethtool_rx_flow_spec, h_u.tcp_ip6_spec.psrc),
+ offsetof(struct ethtool_rx_flow_spec, m_u.tcp_ip6_spec.psrc) },
+ { "dst-port", OPT_BE16, NFC_FLAG_DPORT,
+ offsetof(struct ethtool_rx_flow_spec, h_u.tcp_ip6_spec.pdst),
+ offsetof(struct ethtool_rx_flow_spec, m_u.tcp_ip6_spec.pdst) },
+ { "action", OPT_U64, NFC_FLAG_RING,
+ offsetof(struct ethtool_rx_flow_spec, ring_cookie), -1 },
+ { "loc", OPT_U32, NFC_FLAG_LOC,
+ offsetof(struct ethtool_rx_flow_spec, location), -1 },
+ { "vlan-etype", OPT_BE16, NTUPLE_FLAG_VETH,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.vlan_etype),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.vlan_etype) },
+ { "vlan", OPT_BE16, NTUPLE_FLAG_VLAN,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.vlan_tci),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.vlan_tci) },
+ { "user-def", OPT_BE64, NTUPLE_FLAG_UDEF,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.data),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.data) },
+ { "dst-mac", OPT_MAC, NFC_FLAG_MAC_ADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.h_dest),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.h_dest) },
+};
+
+static const struct rule_opts rule_nfc_esp_ip6[] = {
+ { "src-ip", OPT_IP6, NFC_FLAG_SADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_u.esp_ip6_spec.ip6src),
+ offsetof(struct ethtool_rx_flow_spec, m_u.esp_ip6_spec.ip6src) },
+ { "dst-ip", OPT_IP6, NFC_FLAG_DADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_u.esp_ip6_spec.ip6dst),
+ offsetof(struct ethtool_rx_flow_spec, m_u.esp_ip6_spec.ip6dst) },
+ { "tclass", OPT_U8, NFC_FLAG_TOS,
+ offsetof(struct ethtool_rx_flow_spec, h_u.esp_ip6_spec.tclass),
+ offsetof(struct ethtool_rx_flow_spec, m_u.esp_ip6_spec.tclass) },
+ { "spi", OPT_BE32, NFC_FLAG_SPI,
+ offsetof(struct ethtool_rx_flow_spec, h_u.esp_ip6_spec.spi),
+ offsetof(struct ethtool_rx_flow_spec, m_u.esp_ip6_spec.spi) },
+ { "action", OPT_U64, NFC_FLAG_RING,
+ offsetof(struct ethtool_rx_flow_spec, ring_cookie), -1 },
+ { "loc", OPT_U32, NFC_FLAG_LOC,
+ offsetof(struct ethtool_rx_flow_spec, location), -1 },
+ { "vlan-etype", OPT_BE16, NTUPLE_FLAG_VETH,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.vlan_etype),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.vlan_etype) },
+ { "vlan", OPT_BE16, NTUPLE_FLAG_VLAN,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.vlan_tci),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.vlan_tci) },
+ { "user-def", OPT_BE64, NTUPLE_FLAG_UDEF,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.data),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.data) },
+ { "dst-mac", OPT_MAC, NFC_FLAG_MAC_ADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.h_dest),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.h_dest) },
+};
+
+static const struct rule_opts rule_nfc_usr_ip6[] = {
+ { "src-ip", OPT_IP6, NFC_FLAG_SADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.ip6src),
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.ip6src) },
+ { "dst-ip", OPT_IP6, NFC_FLAG_DADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.ip6dst),
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.ip6dst) },
+ { "tclass", OPT_U8, NFC_FLAG_TOS,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.tclass),
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.tclass) },
+ { "l4proto", OPT_U8, NFC_FLAG_PROTO,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.l4_proto),
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.l4_proto) },
+ { "l4data", OPT_BE32, NFC_FLAG_SPI,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.l4_4_bytes),
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.l4_4_bytes) },
+ { "spi", OPT_BE32, NFC_FLAG_SPI,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.l4_4_bytes),
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.l4_4_bytes) },
+ { "src-port", OPT_BE16, NFC_FLAG_SPORT,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.l4_4_bytes),
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.l4_4_bytes) },
+ { "dst-port", OPT_BE16, NFC_FLAG_DPORT,
+ offsetof(struct ethtool_rx_flow_spec, h_u.usr_ip6_spec.l4_4_bytes) + 2,
+ offsetof(struct ethtool_rx_flow_spec, m_u.usr_ip6_spec.l4_4_bytes) + 2 },
+ { "action", OPT_U64, NFC_FLAG_RING,
+ offsetof(struct ethtool_rx_flow_spec, ring_cookie), -1 },
+ { "loc", OPT_U32, NFC_FLAG_LOC,
+ offsetof(struct ethtool_rx_flow_spec, location), -1 },
+ { "vlan-etype", OPT_BE16, NTUPLE_FLAG_VETH,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.vlan_etype),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.vlan_etype) },
+ { "vlan", OPT_BE16, NTUPLE_FLAG_VLAN,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.vlan_tci),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.vlan_tci) },
+ { "user-def", OPT_BE64, NTUPLE_FLAG_UDEF,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.data),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.data) },
+ { "dst-mac", OPT_MAC, NFC_FLAG_MAC_ADDR,
+ offsetof(struct ethtool_rx_flow_spec, h_ext.h_dest),
+ offsetof(struct ethtool_rx_flow_spec, m_ext.h_dest) },
+};
+
static const struct rule_opts rule_nfc_ether[] = {
{ "src", OPT_MAC, NFC_FLAG_SADDR,
offsetof(struct ethtool_rx_flow_spec, h_u.ether_spec.h_source),
@@ -726,6 +909,14 @@ static int rxclass_get_ipv4(char *str, __be32 *val)
return 0;
}
+static int rxclass_get_ipv6(char *str, __be32 *val)
+{
+ if (!inet_pton(AF_INET6, str, val))
+ return -1;
+
+ return 0;
+}
+
static int rxclass_get_ether(char *str, unsigned char *val)
{
unsigned int buf[ETH_ALEN];
@@ -851,6 +1042,16 @@ static int rxclass_get_val(char *str, unsigned char *p, u32 *flags,
*(__be32 *)&p[opt->moffset] = (__be32)mask;
break;
}
+ case OPT_IP6: {
+ __be32 val[4];
+ err = rxclass_get_ipv6(str, val);
+ if (err)
+ return -1;
+ memcpy(&p[opt->offset], val, sizeof(val));
+ if (opt->moffset >= 0)
+ memset(&p[opt->moffset], mask, sizeof(val));
+ break;
+ }
case OPT_MAC: {
unsigned char val[ETH_ALEN];
err = rxclass_get_ether(str, val);
@@ -950,6 +1151,17 @@ static int rxclass_get_mask(char *str, unsigned char *p,
*(__be32 *)&p[opt->moffset] = ~val;
break;
}
+ case OPT_IP6: {
+ __be32 val[4], *field;
+ int i;
+ err = rxclass_get_ipv6(str, val);
+ if (err)
+ return -1;
+ field = (__be32 *)&p[opt->moffset];
+ for (i = 0; i < 4; i++)
+ field[i] = ~val[i];
+ break;
+ }
case OPT_MAC: {
unsigned char val[ETH_ALEN];
int i;
@@ -996,7 +1208,19 @@ int rxclass_parse_ruleopts(struct cmd_context *ctx,
else if (!strcmp(argp[0], "esp4"))
flow_type = ESP_V4_FLOW;
else if (!strcmp(argp[0], "ip4"))
- flow_type = IP_USER_FLOW;
+ flow_type = IPV4_USER_FLOW;
+ else if (!strcmp(argp[0], "tcp6"))
+ flow_type = TCP_V6_FLOW;
+ else if (!strcmp(argp[0], "udp6"))
+ flow_type = UDP_V6_FLOW;
+ else if (!strcmp(argp[0], "sctp6"))
+ flow_type = SCTP_V6_FLOW;
+ else if (!strcmp(argp[0], "ah6"))
+ flow_type = AH_V6_FLOW;
+ else if (!strcmp(argp[0], "esp6"))
+ flow_type = ESP_V6_FLOW;
+ else if (!strcmp(argp[0], "ip6"))
+ flow_type = IPV6_USER_FLOW;
else if (!strcmp(argp[0], "ether"))
flow_type = ETHER_FLOW;
else
@@ -1014,10 +1238,25 @@ int rxclass_parse_ruleopts(struct cmd_context *ctx,
options = rule_nfc_esp_ip4;
n_opts = ARRAY_SIZE(rule_nfc_esp_ip4);
break;
- case IP_USER_FLOW:
+ case IPV4_USER_FLOW:
options = rule_nfc_usr_ip4;
n_opts = ARRAY_SIZE(rule_nfc_usr_ip4);
break;
+ case TCP_V6_FLOW:
+ case UDP_V6_FLOW:
+ case SCTP_V6_FLOW:
+ options = rule_nfc_tcp_ip6;
+ n_opts = ARRAY_SIZE(rule_nfc_tcp_ip6);
+ break;
+ case AH_V6_FLOW:
+ case ESP_V6_FLOW:
+ options = rule_nfc_esp_ip6;
+ n_opts = ARRAY_SIZE(rule_nfc_esp_ip6);
+ break;
+ case IPV6_USER_FLOW:
+ options = rule_nfc_usr_ip6;
+ n_opts = ARRAY_SIZE(rule_nfc_usr_ip6);
+ break;
case ETHER_FLOW:
options = rule_nfc_ether;
n_opts = ARRAY_SIZE(rule_nfc_ether);
@@ -1081,7 +1320,7 @@ int rxclass_parse_ruleopts(struct cmd_context *ctx,
}
}
- if (flow_type == IP_USER_FLOW)
+ if (flow_type == IPV4_USER_FLOW)
fsp->h_u.usr_ip4_spec.ip_ver = ETH_RX_NFC_IP4;
if (flags & (NTUPLE_FLAG_VLAN | NTUPLE_FLAG_UDEF | NTUPLE_FLAG_VETH))
fsp->flow_type |= FLOW_EXT;
^ permalink raw reply related
* [PATCH v2 ethtool 0/2] IPv6 RXNFC
From: Edward Cree @ 2016-03-17 19:09 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
This series adds support for steering of IPv6 receive flows.
Changes since v1:
* Fixed and simplified IPv6 address and mask parsing
* Made help text / man page more consistent
* Dropped ethtool-copy.h patch as upstream is now newer
Edward Cree (2):
Add IPv6 support to NFC
Documentation for IPv6 NFC
ethtool.8.in | 29 +++++--
ethtool.c | 25 +++++-
rxclass.c | 268 +++++++++++++++++++++++++++++++++++++++++++++++++++++++----
3 files changed, 298 insertions(+), 24 deletions(-)
^ permalink raw reply
* [PATCH net] net: bcmgenet: fix dma api length mismatch
From: Eric Dumazet @ 2016-03-17 18:57 UTC (permalink / raw)
To: Florian Fainelli, David Miller; +Cc: netdev, opendmb
In-Reply-To: <56EAE2A8.5000206@gmail.com>
From: Eric Dumazet <edumazet@google.com>
When un-mapping skb->data in __bcmgenet_tx_reclaim(),
we must use the length that was used in original dma_map_single(),
instead of skb->len that might be bigger (includes the frags)
We simply can store skb_len into tx_cb_ptr->dma_len and use it
at unmap time.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index d7e01a7..6746fd0 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1197,7 +1197,7 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
dev->stats.tx_bytes += tx_cb_ptr->skb->len;
dma_unmap_single(&dev->dev,
dma_unmap_addr(tx_cb_ptr, dma_addr),
- tx_cb_ptr->skb->len,
+ dma_unmap_len(tx_cb_ptr, dma_len),
DMA_TO_DEVICE);
bcmgenet_free_cb(tx_cb_ptr);
} else if (dma_unmap_addr(tx_cb_ptr, dma_addr)) {
@@ -1308,7 +1308,7 @@ static int bcmgenet_xmit_single(struct net_device *dev,
}
dma_unmap_addr_set(tx_cb_ptr, dma_addr, mapping);
- dma_unmap_len_set(tx_cb_ptr, dma_len, skb->len);
+ dma_unmap_len_set(tx_cb_ptr, dma_len, skb_len);
length_status = (skb_len << DMA_BUFLENGTH_SHIFT) | dma_desc_flags |
(priv->hw_params->qtag_mask << DMA_TX_QTAG_SHIFT) |
DMA_TX_APPEND_CRC;
^ permalink raw reply related
* Re: net/ppp: use-after-free in ppp_unregister_channel
From: Guillaume Nault @ 2016-03-17 18:30 UTC (permalink / raw)
To: Baozeng Ding; +Cc: linux-kernel, paulus, linux-ppp, netdev
In-Reply-To: <56e97869.6afe420a.80cd8.ffffde3d@mx.google.com>
On Wed, Mar 16, 2016 at 11:14:42PM +0800, Baozeng Ding wrote:
> Dear all,
> I've got the following use-after-free report while running syzkaller
> fuzzer. Unfortunately no reproducer. It was found in the Linux kernel
> version(4.4, on commit 9638685e32af961943b679fcb72d4ddd458eb18f).
>
> ==================================================================
> BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
> addr ffff880064e217e0
> Read of size 8 by task syz-executor/11581
> =============================================================================
> BUG net_namespace (Not tainted): kasan: bad access detected
> -----------------------------------------------------------------------------
>
> Disabling lock debugging due to kernel taint
> INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
> [< none >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
> [< none >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
> [< inline >] slab_alloc_node kernel/mm/slub.c:2532
> [< inline >] slab_alloc kernel/mm/slub.c:2574
> [< none >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
> [< inline >] kmem_cache_zalloc kernel/include/linux/slab.h:597
> [< inline >] net_alloc kernel/net/core/net_namespace.c:325
> [< none >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
> [< none >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
> [< none >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
> [< none >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
> [< inline >] copy_process kernel/kernel/fork.c:1274
> [< none >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
> [< inline >] SYSC_clone kernel/kernel/fork.c:1832
> [< none >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
> [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
>
> INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
> [< none >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
> [< inline >] slab_free kernel/mm/slub.c:2805
> [< none >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
> [< inline >] net_free kernel/net/core/net_namespace.c:341
> [< none >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
> [< none >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
> [< none >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
> [< none >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
> [< none >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
> [< none >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
> INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
> flags=0x5fffc0000004080
> INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
>
> CPU: 1 PID: 11581 Comm: syz-executor Tainted: G B 4.4.0+
> #5
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> 00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
> ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
> ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
> Call Trace:
> [< inline >] __dump_stack kernel/lib/dump_stack.c:15
> [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
> [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
> [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
> [< inline >] print_address_description kernel/mm/kasan/report.c:138
> [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
> [< inline >] kasan_report kernel/mm/kasan/report.c:259
> [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
> [< inline >] ? ppp_pernet kernel/include/linux/compiler.h:218
> [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
> [< inline >] ppp_pernet kernel/include/linux/compiler.h:218
> [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
> [< inline >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
> [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
> [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
> [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
> [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
> [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
> [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
> [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
> [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
> [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
> [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
> [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
> [< inline >] exit_task_work kernel/include/linux/task_work.h:21
> [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
> [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
> [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
> [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
> [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
> [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
> [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
> [< inline >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
> [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
> [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
> [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
> [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
> [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
> [< inline >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
> [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
> [< inline >] ? context_switch kernel/kernel/sched/core.c:2807
> [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
> [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
> [< inline >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
> [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
> [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
A network namespace has been removed while a ppp_async channel was
still registered in it. Then, unregistering this channel triggered the
bug because ppp_unregister_channel() tried to access its per-netns data
in the defunct namespace.
This scenario can happen at least with ppp_async and ppp_synctty, where
the userspace program and the PPP channel it handles can leave in
separate namespaces.
Thanks for the report, I can reproduce the bug and will work on a fix.
Guillaume
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox