* [PATCH net-next] Revert "ipv6: Initial skb->dev and skb->protocol in ip6_output"
From: Chenbo Feng @ 2017-06-09 19:56 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Lorenzo Colitti, Eric Dumazet, Chenbo Feng
From: Chenbo Feng <fengc@google.com>
This reverts commit 97a7a37a7b7b("ipv6: Initial skb->dev and
skb->protocol in ip6_output") since it does not handles the
skb->dev assignment inside ip6_fragment() code path properly.
Need to rework and upload again
Fixes: 97a7a37a7b7b("ipv6: Initial skb->dev and skb->protocol in ip6_output")
Signed-off-by: Chenbo Feng <fengc@google.com>
---
net/ipv6/ip6_output.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 02cd44f..bf8a58a 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -67,6 +67,9 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
struct in6_addr *nexthop;
int ret;
+ skb->protocol = htons(ETH_P_IPV6);
+ skb->dev = dev;
+
if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
@@ -151,9 +154,6 @@ int ip6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
struct net_device *dev = skb_dst(skb)->dev;
struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
- skb->protocol = htons(ETH_P_IPV6);
- skb->dev = dev;
-
if (unlikely(idev->cnf.disable_ipv6)) {
IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTDISCARDS);
kfree_skb(skb);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 7/8] net: mvmdio: add xmdio support
From: Russell King - ARM Linux @ 2017-06-09 19:56 UTC (permalink / raw)
To: Antoine Tenart
Cc: Andrew Lunn, Florian Fainelli, davem, jason, gregory.clement,
sebastian.hesselbarth, thomas.petazzoni, mw, netdev,
linux-arm-kernel
In-Reply-To: <20170609162216.GF31464@kwain>
On Fri, Jun 09, 2017 at 06:22:16PM +0200, Antoine Tenart wrote:
> On Fri, Jun 09, 2017 at 05:03:40PM +0200, Andrew Lunn wrote:
> > > There are two busses, one generating c22 transactions and one generating
> > > c45 transactions. Each bus has its own MDC/MDIO pins.
> >
> > O.K. That is what i wanted to know. So we want two completely separate
> > device tree bindings, busses registered with Linux, etc.
> >
> > Thanks for clarification.
>
> So in the end I need one change in v3: to bind the xSMI usage to
> marvell,xmdio and the SMI one to marvell,orion-mdio. (Plus the GENMASK
> and offset comments).
Also, you need to
1. trap out on incorrect MII_ADDR_C45 in regnum for the interface.
2. mask the dev_addr with GENMASK(4, 0) (as merely shifting will leave
the MII_ADDR_C45 bit set.)
3. moving MVMDIO_XSMI_PHYADDR_SHIFT / MVMDIO_XSMI_DEVADDR_SHIFT /
MVMDIO_XSMI_READ_OPERATION / MVMDIO_XSMI_WRITE_OPERATION under the
MVMDIO_XSMI_MGNT_REG reg - these definitions are nothing to do with
MVMDIO_XSMI_ADDR_REG.
4. fixing MVMDIO_XSMI_WRITE_OPERATION to be 5 << 26, not 5 << 27.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [Intel-wired-lan] [i40e] regression on TCP stream and TCP maerts, kernel-4.12.0-0.rc2
From: Alexander Duyck @ 2017-06-09 19:59 UTC (permalink / raw)
To: Adrian Tomasov, Jeff Kirsher, Jacob Keller
Cc: Duyck, Alexander H, osabart@redhat.com, netdev@vger.kernel.org,
aokuliar@redhat.com, intel-wired-lan@lists.osuosl.org,
jhladky@redhat.com
In-Reply-To: <1497004478.32667.16.camel@redhat.com>
On Fri, Jun 9, 2017 at 3:34 AM, Adrian Tomasov <atomasov@redhat.com> wrote:
> On Thu, 2017-06-01 at 19:18 +0000, Duyck, Alexander H wrote:
>> On Thu, 2017-06-01 at 12:14 +0200, Adrian Tomasov wrote:
>> >
>> > On Wed, 2017-05-31 at 14:42 -0700, Alexander Duyck wrote:
>> > >
>> > >
>> > > On Wed, May 31, 2017 at 6:48 AM, Adrian Tomasov <atomasov@redhat.
>> > > com>
>> > > wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Tue, 2017-05-30 at 18:27 -0700, Alexander Duyck wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
>> > > > > <alexander.duyck@gmail.com> wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar <aokuliar@red
>> > > > > > hat.
>> > > > > > com>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Hello,
>> > > > > > >
>> > > > > > > we found regression on intel card(XL710) with i40e
>> > > > > > > driver.
>> > > > > > > Regression is
>> > > > > > > about ~45%
>> > > > > > > on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6.
>> > > > > > > Regression
>> > > > > > > was first
>> > > > > > > visible in kernel-4.12.0-0.rc1.
>> > > > > > >
>> > > > > > > More details about results you can see in uploaded images
>> > > > > > > in
>> > > > > > > bugzilla. [0]
>> > > > > > >
>> > > > > > >
>> > > > > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=195923
>> > > > > > >
>> > > > > > >
>> > > > > > > Best regards, / S pozdravom,
>> > > > > > >
>> > > > > > > Adrián Tomašov
>> > > > > > > Kernel Performance QE
>> > > > > > > atomasov@redhat.com
>> > > > > >
>> > > > > > I have added the i40e driver maintainer and the intel-
>> > > > > > wired-lan
>> > > > > > mailing list so that we can make are developers aware of
>> > > > > > the
>> > > > > > issue.
>> > > > > >
>> > > > > > Thanks.
>> > > > > >
>> > > > > > - Alex
>> > > > >
>> > > > > Adam,
>> > > > >
>> > > > > We are having some issues trying to reproduce what you
>> > > > > reported.
>> > > > >
>> > > > > Can you provide some additional data. Specifically we would
>> > > > > be
>> > > > > looking
>> > > > > for an "ethtool -i", and an "ethtool -S" for the port before
>> > > > > and
>> > > > > after
>> > > > > the test. If you can attach it to the bugzilla that would be
>> > > > > appreciated.
>> > > > >
>> > > > > Thanks.
>> > > > >
>> > > > > - Alex
>> > > >
>> > > > Hello Alex,
>> > > >
>> > > > requested files are updated in bugzilla.
>> > > >
>> > > > If you have any questions about testing feel free to ask.
>> > > >
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Adrian
>> > >
>> > > So looking at the data I wonder if we don't have an MTU mismatch
>> > > in
>> > > the network config. I notice the "after" has rx_length_errors
>> > > being
>> > > reported. Recent changes made it so that i40e doesn't support
>> > > jumbo
>> > > frames by default, whereas before we could. You might want to
>> > > check
>> > > for that as that could cause the kind of performance issues you
>> > > are
>> > > seeing.
>> > >
>> > > - Alex
>> >
>> > There isn't MTU mismatch. Traffic path is : server -> switch ->
>> > server.
>> >
>> >
>> > Output from switch:
>> >
>> > > show interfaces et-0/0/18
>> > Physical interface: et-0/0/18, Enabled, Physical link is Up
>> > Interface index: 644, SNMP ifIndex: 538
>> > Link-level type: Ethernet, MTU: 1514, Speed: 40Gbps, BPDU
>> > Error:
>> > None, MAC-REWRITE Error: None, Loopback: Disabled, Source
>> > filtering:
>> > Disabled, Flow control: Disabled, Media type: Fiber
>> > Device flags : Present Running
>> > Interface flags: SNMP-Traps Internal: 0x4000
>> > Link flags : None
>> > CoS queues : 12 supported, 12 maximum usable queues
>> > Current address: d4:04:ff:90:5a:4b, Hardware address:
>> > d4:04:ff:90:5a:4b
>> > Last flapped : 2017-06-01 10:09:32 CEST (01:21:29 ago)
>> > Input rate : 432 bps (0 pps)
>> > Output rate : 8336 bps (11 pps)
>> > Active alarms : None
>> > Active defects : None
>> > Interface transmit statistics: Disabled
>> >
>> > Logical interface et-0/0/18.0 (Index 552) (SNMP ifIndex 539)
>> > Flags: SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
>> > Input packets : 464041
>> > Output packets: 209210
>> > Protocol eth-switch, MTU: 1514
>> > Flags: Is-Primary, Trunk-Mode
>> >
>> >
>> > MTU is same for all et-0/0/x interfaces.
>> >
>> > - Adrian
>>
>> One thing you might try try doing is toggling the legacy-rx flag
>> using
>> the "ethtool --show-priv-flags/--set-priv-flags" command to see if
>> that
>> has any impact. That will help to rule things out as the most
>> significant change I can think of is the recent update of the Rx path
>> to support XDP.
>>
>> Also one other thing you might try would be to use a fixed interrupt
>> moderation rate by locking things down using "ethtool -C" to disable
>> adaptive interrupt moderation and lock the Rx usecs and Tx usecs at
>> some predefined values. I seem to recall there have been some
>> interrupt
>> moderation changes made recently that might be impacting the
>> performance.
>>
>> Beyond that is there any chance you would be able to bisect the
>> issue?
>> Unfortunately we haven't be able to reproduce it internally so
>> anything
>> that would help us to narrow down the problem would be useful.
>>
>> Thanks.
>>
>> - Alex
>
> Hello Alex,
>
> I updated firmware in NIC and it didn't make any changes. Current
> firmware version is "firmware-version: 5.05 0x800028a6 1.1568.0".
>
>
> I tried bisect this issue with new firmware and successfully found
> first bad commit. Log from bisecting is pasted in the end. For testing
> of kernel builds I used clear distribution install of RHEL7 and turn
> of irqbalance. Test run between 2 servers with same HW an SW
> configuration. NIC was put into different IPv4 subnet to avoid
> undesirable communication.
>
>
> testing command : netperf -L 192.168.0.1 -H 192.168.0.2 -T 0,0 -t
> TCP_STREAM -l 30 -- -m 4096
>
>
> [root@vales1 linux]# git bisect good
> 47994c119a36e28e1779efabc92d6ab5329a6f75 is the first bad commit
> commit 47994c119a36e28e1779efabc92d6ab5329a6f75
> Author: Jacob Keller <jacob.e.keller@intel.com>
> Date: Wed Apr 19 09:25:57 2017 -0400
>
> i40e: remove hw_disabled_flags in favor of using separate flag bits
>
> The hw_disabled_flags field was added as a way of signifying that
> a feature was automatically or temporarily disabled. However, we
> actually only use this for FDir features. Replace its use with new
> _AUTO_DISABLED flags instead. This is more readable, because you
> aren't
> setting an *_ENABLED flag to *disable* the feature.
>
> Additionally, clean up a few areas where we used these bits. First,
> we
> don't really need to set the auto-disable flag for ATR if we're
> fully
> disabling the feature via ethtool.
>
> Second, we should always clear the auto-disable bits in case they
> somehow
> got set when the feature was disabled. However, avoid displaying
> a message that we've re-enabled the feature.
>
> Third, we shouldn't be re-enabling ATR in the SB ntuple add flow,
> because it might have been disabled due to space constraints.
> Instead,
> we should just wait for the fdir_check_and_reenable to be called by
> the
> watchdog.
>
> Overall, this change allows us to simplify some code by removing an
> extra field we didn't need, and the result should make it more
> clear as
> to what we're actually doing with these flags.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> :040000 040000 e2f7724e0e857b902ebfeb7104ac18ecf6b90e36
> 524e5f2381a64fb152ec00638d738a4f28968455 M drivers
> [root@vales1 linux]# git bisect log
> git bisect start
> # good: [5a7ad1146caa895ad718a534399e38bd2ba721b7] Linux 4.11-rc8
> git bisect good 5a7ad1146caa895ad718a534399e38bd2ba721b7
> # bad: [2ea659a9ef488125eb46da6eb571de5eae5c43f6] Linux 4.12-rc1
> git bisect bad 2ea659a9ef488125eb46da6eb571de5eae5c43f6
> # bad: [221656e7c4ce342b99c31eca96c1cbb6d1dce45f] Merge tag 'sound-
> 4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
> git bisect bad 221656e7c4ce342b99c31eca96c1cbb6d1dce45f
> # bad: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> git bisect bad 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
> # good: [2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf] rhashtable: Do not
> lower max_elems when max_size is zero
> git bisect good 2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf
> # good: [6dc2cce9321198172cd96f955a5fc798a4cc35a6] Merge branch 'x86-
> process-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect good 6dc2cce9321198172cd96f955a5fc798a4cc35a6
> # good: [b68e7e952f24527de62f4768b1cead91f92f5f6e] Merge branch 'for-
> linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
> git bisect good b68e7e952f24527de62f4768b1cead91f92f5f6e
> # bad: [773225388dae15e72790d6f573e2e70e96292b6b] net: thunderx:
> Optimize page recycling for XDP
> git bisect bad 773225388dae15e72790d6f573e2e70e96292b6b
> # bad: [edd7f4efa8111efc279582290acc4d54d405748a] Merge branch 'bpf-
> samples-skb_mode-bug-fixes'
> git bisect bad edd7f4efa8111efc279582290acc4d54d405748a
> # good: [0da36b9774cc24bac4bff446edf49f31aa98a282] i40e: use
> DECLARE_BITMAP for state fields
> git bisect good 0da36b9774cc24bac4bff446edf49f31aa98a282
> # bad: [1d11e732e7d501c4a231f0b32cf8b81990592689] virtio-net: use
> netif_tx_napi_add for tx napi
> git bisect bad 1d11e732e7d501c4a231f0b32cf8b81990592689
> # bad: [d1f496fd8f34a40458d0eda6be0655926559e546] bpf: restore skb->sk
> before pskb_trim() call
> git bisect bad d1f496fd8f34a40458d0eda6be0655926559e546
> # bad: [3dfc3eb581645bc503c7940861f494a0d75615da] i40evf: hide unused
> variable
> git bisect bad 3dfc3eb581645bc503c7940861f494a0d75615da
> # bad: [47994c119a36e28e1779efabc92d6ab5329a6f75] i40e: remove
> hw_disabled_flags in favor of using separate flag bits
> git bisect bad 47994c119a36e28e1779efabc92d6ab5329a6f75
> # good: [789f38ca70e0b2848472aaf5f278aa3deabd4a4e] i40evf: remove
> needless min_t() on num_online_cpus()*2
> git bisect good 789f38ca70e0b2848472aaf5f278aa3deabd4a4e
> # first bad commit: [47994c119a36e28e1779efabc92d6ab5329a6f75] i40e:
> remove hw_disabled_flags in favor of using separate flag bits
>
> [root@vales1 linux]# ethtool -i ens1f0
> driver: i40e
> version: 2.1.14-k
> firmware-version: 5.05 0x800028a6 1.1568.0
> expansion-rom-version:
> bus-info: 0000:04:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes
>
>
> - Adrian
>
Okay I think I have an idea what is going on.
Looking at the code there is a bug and apparently it is fixed in:
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?h=dev-queue&id=b699c97b570ac69989955a7a9f05722abd3177cf
I am assuming that is being submitted to net at some point since this
is a bug that is visible in Linus's tree. Jeff do we have an ETA on
when that patch might go out?
Thanks.
Alex
^ permalink raw reply
* Re: [PATCH v2 7/8] net: mvmdio: add xmdio support
From: Russell King - ARM Linux @ 2017-06-09 20:00 UTC (permalink / raw)
To: Antoine Tenart
Cc: Andrew Lunn, davem, jason, gregory.clement, sebastian.hesselbarth,
f.fainelli, thomas.petazzoni, mw, netdev, linux-arm-kernel
In-Reply-To: <20170609064019.GB31464@kwain>
On Fri, Jun 09, 2017 at 08:40:19AM +0200, Antoine Tenart wrote:
> Hi Andrew,
>
> On Thu, Jun 08, 2017 at 06:03:31PM +0200, Andrew Lunn wrote:
> > On Thu, Jun 08, 2017 at 11:26:52AM +0200, Antoine Tenart wrote:
> > > +#define MVMDIO_XSMI_MGNT_REG 0x0
> > > +#define MVMDIO_XSMI_READ_VALID BIT(29)
> > > +#define MVMDIO_XSMI_BUSY BIT(30)
> > > +#define MVMDIO_XSMI_ADDR_REG 0x8
> > > +#define MVMDIO_XSMI_PHYADDR_SHIFT 16
> > > +#define MVMDIO_XSMI_DEVADDR_SHIFT 21
> > > +#define MVMDIO_XSMI_READ_OPERATION (0x7 << 26)
> > > +#define MVMDIO_XSMI_WRITE_OPERATION (0x5 << 27)
> >
> > These two operations seem odd. Generally ops have the same shift.
>
> Indeed, this is odd. I'll have a look at this.
The Marvell driver uses 5 << 26:
+#define XOPCODE_OFFS 26
+#define XOPCODE_ADDR_READ (7 << XOPCODE_OFFS)
+#define XOPCODE_ADDR_WRITE (5 << XOPCODE_OFFS)
What this means is that with the incorrect shift in your driver,
although writes appeared to work, they actually resulted in a
post-read-increment-address frame (and hence no error.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* RE: [Intel-wired-lan] [i40e] regression on TCP stream and TCP maerts, kernel-4.12.0-0.rc2
From: Keller, Jacob E @ 2017-06-09 20:25 UTC (permalink / raw)
To: Alexander Duyck, Adrian Tomasov, Kirsher, Jeffrey T
Cc: Duyck, Alexander H, osabart@redhat.com, netdev@vger.kernel.org,
aokuliar@redhat.com, intel-wired-lan@lists.osuosl.org,
jhladky@redhat.com
In-Reply-To: <CAKgT0UcKnDu-VUci6TT0Pfxu6eDSvVxSb0KyRgn4VUmG1gMiqg@mail.gmail.com>
> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> Sent: Friday, June 09, 2017 12:59 PM
> To: Adrian Tomasov <atomasov@redhat.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Duyck, Alexander H <alexander.h.duyck@intel.com>; osabart@redhat.com;
> netdev@vger.kernel.org; aokuliar@redhat.com; intel-wired-lan@lists.osuosl.org;
> jhladky@redhat.com
> Subject: Re: [Intel-wired-lan] [i40e] regression on TCP stream and TCP maerts,
> kernel-4.12.0-0.rc2
>
> On Fri, Jun 9, 2017 at 3:34 AM, Adrian Tomasov <atomasov@redhat.com> wrote:
> > On Thu, 2017-06-01 at 19:18 +0000, Duyck, Alexander H wrote:
> >> On Thu, 2017-06-01 at 12:14 +0200, Adrian Tomasov wrote:
> >> >
> >> > On Wed, 2017-05-31 at 14:42 -0700, Alexander Duyck wrote:
> >> > >
> >> > >
> >> > > On Wed, May 31, 2017 at 6:48 AM, Adrian Tomasov <atomasov@redhat.
> >> > > com>
> >> > > wrote:
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Tue, 2017-05-30 at 18:27 -0700, Alexander Duyck wrote:
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
> >> > > > > <alexander.duyck@gmail.com> wrote:
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar <aokuliar@red
> >> > > > > > hat.
> >> > > > > > com>
> >> > > > > > wrote:
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Hello,
> >> > > > > > >
> >> > > > > > > we found regression on intel card(XL710) with i40e
> >> > > > > > > driver.
> >> > > > > > > Regression is
> >> > > > > > > about ~45%
> >> > > > > > > on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6.
> >> > > > > > > Regression
> >> > > > > > > was first
> >> > > > > > > visible in kernel-4.12.0-0.rc1.
> >> > > > > > >
> >> > > > > > > More details about results you can see in uploaded images
> >> > > > > > > in
> >> > > > > > > bugzilla. [0]
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=195923
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Best regards, / S pozdravom,
> >> > > > > > >
> >> > > > > > > Adrián Tomašov
> >> > > > > > > Kernel Performance QE
> >> > > > > > > atomasov@redhat.com
> >> > > > > >
> >> > > > > > I have added the i40e driver maintainer and the intel-
> >> > > > > > wired-lan
> >> > > > > > mailing list so that we can make are developers aware of
> >> > > > > > the
> >> > > > > > issue.
> >> > > > > >
> >> > > > > > Thanks.
> >> > > > > >
> >> > > > > > - Alex
> >> > > > >
> >> > > > > Adam,
> >> > > > >
> >> > > > > We are having some issues trying to reproduce what you
> >> > > > > reported.
> >> > > > >
> >> > > > > Can you provide some additional data. Specifically we would
> >> > > > > be
> >> > > > > looking
> >> > > > > for an "ethtool -i", and an "ethtool -S" for the port before
> >> > > > > and
> >> > > > > after
> >> > > > > the test. If you can attach it to the bugzilla that would be
> >> > > > > appreciated.
> >> > > > >
> >> > > > > Thanks.
> >> > > > >
> >> > > > > - Alex
> >> > > >
> >> > > > Hello Alex,
> >> > > >
> >> > > > requested files are updated in bugzilla.
> >> > > >
> >> > > > If you have any questions about testing feel free to ask.
> >> > > >
> >> > > >
> >> > > > Best regards,
> >> > > >
> >> > > > Adrian
> >> > >
> >> > > So looking at the data I wonder if we don't have an MTU mismatch
> >> > > in
> >> > > the network config. I notice the "after" has rx_length_errors
> >> > > being
> >> > > reported. Recent changes made it so that i40e doesn't support
> >> > > jumbo
> >> > > frames by default, whereas before we could. You might want to
> >> > > check
> >> > > for that as that could cause the kind of performance issues you
> >> > > are
> >> > > seeing.
> >> > >
> >> > > - Alex
> >> >
> >> > There isn't MTU mismatch. Traffic path is : server -> switch ->
> >> > server.
> >> >
> >> >
> >> > Output from switch:
> >> >
> >> > > show interfaces et-0/0/18
> >> > Physical interface: et-0/0/18, Enabled, Physical link is Up
> >> > Interface index: 644, SNMP ifIndex: 538
> >> > Link-level type: Ethernet, MTU: 1514, Speed: 40Gbps, BPDU
> >> > Error:
> >> > None, MAC-REWRITE Error: None, Loopback: Disabled, Source
> >> > filtering:
> >> > Disabled, Flow control: Disabled, Media type: Fiber
> >> > Device flags : Present Running
> >> > Interface flags: SNMP-Traps Internal: 0x4000
> >> > Link flags : None
> >> > CoS queues : 12 supported, 12 maximum usable queues
> >> > Current address: d4:04:ff:90:5a:4b, Hardware address:
> >> > d4:04:ff:90:5a:4b
> >> > Last flapped : 2017-06-01 10:09:32 CEST (01:21:29 ago)
> >> > Input rate : 432 bps (0 pps)
> >> > Output rate : 8336 bps (11 pps)
> >> > Active alarms : None
> >> > Active defects : None
> >> > Interface transmit statistics: Disabled
> >> >
> >> > Logical interface et-0/0/18.0 (Index 552) (SNMP ifIndex 539)
> >> > Flags: SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
> >> > Input packets : 464041
> >> > Output packets: 209210
> >> > Protocol eth-switch, MTU: 1514
> >> > Flags: Is-Primary, Trunk-Mode
> >> >
> >> >
> >> > MTU is same for all et-0/0/x interfaces.
> >> >
> >> > - Adrian
> >>
> >> One thing you might try try doing is toggling the legacy-rx flag
> >> using
> >> the "ethtool --show-priv-flags/--set-priv-flags" command to see if
> >> that
> >> has any impact. That will help to rule things out as the most
> >> significant change I can think of is the recent update of the Rx path
> >> to support XDP.
> >>
> >> Also one other thing you might try would be to use a fixed interrupt
> >> moderation rate by locking things down using "ethtool -C" to disable
> >> adaptive interrupt moderation and lock the Rx usecs and Tx usecs at
> >> some predefined values. I seem to recall there have been some
> >> interrupt
> >> moderation changes made recently that might be impacting the
> >> performance.
> >>
> >> Beyond that is there any chance you would be able to bisect the
> >> issue?
> >> Unfortunately we haven't be able to reproduce it internally so
> >> anything
> >> that would help us to narrow down the problem would be useful.
> >>
> >> Thanks.
> >>
> >> - Alex
> >
> > Hello Alex,
> >
> > I updated firmware in NIC and it didn't make any changes. Current
> > firmware version is "firmware-version: 5.05 0x800028a6 1.1568.0".
> >
> >
> > I tried bisect this issue with new firmware and successfully found
> > first bad commit. Log from bisecting is pasted in the end. For testing
> > of kernel builds I used clear distribution install of RHEL7 and turn
> > of irqbalance. Test run between 2 servers with same HW an SW
> > configuration. NIC was put into different IPv4 subnet to avoid
> > undesirable communication.
> >
> >
> > testing command : netperf -L 192.168.0.1 -H 192.168.0.2 -T 0,0 -t
> > TCP_STREAM -l 30 -- -m 4096
> >
> >
> > [root@vales1 linux]# git bisect good
> > 47994c119a36e28e1779efabc92d6ab5329a6f75 is the first bad commit
> > commit 47994c119a36e28e1779efabc92d6ab5329a6f75
> > Author: Jacob Keller <jacob.e.keller@intel.com>
> > Date: Wed Apr 19 09:25:57 2017 -0400
> >
> > i40e: remove hw_disabled_flags in favor of using separate flag bits
> >
> > The hw_disabled_flags field was added as a way of signifying that
> > a feature was automatically or temporarily disabled. However, we
> > actually only use this for FDir features. Replace its use with new
> > _AUTO_DISABLED flags instead. This is more readable, because you
> > aren't
> > setting an *_ENABLED flag to *disable* the feature.
> >
> > Additionally, clean up a few areas where we used these bits. First,
> > we
> > don't really need to set the auto-disable flag for ATR if we're
> > fully
> > disabling the feature via ethtool.
> >
> > Second, we should always clear the auto-disable bits in case they
> > somehow
> > got set when the feature was disabled. However, avoid displaying
> > a message that we've re-enabled the feature.
> >
> > Third, we shouldn't be re-enabling ATR in the SB ntuple add flow,
> > because it might have been disabled due to space constraints.
> > Instead,
> > we should just wait for the fdir_check_and_reenable to be called by
> > the
> > watchdog.
> >
> > Overall, this change allows us to simplify some code by removing an
> > extra field we didn't need, and the result should make it more
> > clear as
> > to what we're actually doing with these flags.
> >
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >
> > :040000 040000 e2f7724e0e857b902ebfeb7104ac18ecf6b90e36
> > 524e5f2381a64fb152ec00638d738a4f28968455 M drivers
> > [root@vales1 linux]# git bisect log
> > git bisect start
> > # good: [5a7ad1146caa895ad718a534399e38bd2ba721b7] Linux 4.11-rc8
> > git bisect good 5a7ad1146caa895ad718a534399e38bd2ba721b7
> > # bad: [2ea659a9ef488125eb46da6eb571de5eae5c43f6] Linux 4.12-rc1
> > git bisect bad 2ea659a9ef488125eb46da6eb571de5eae5c43f6
> > # bad: [221656e7c4ce342b99c31eca96c1cbb6d1dce45f] Merge tag 'sound-
> > 4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
> > git bisect bad 221656e7c4ce342b99c31eca96c1cbb6d1dce45f
> > # bad: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> > git bisect bad 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
> > # good: [2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf] rhashtable: Do not
> > lower max_elems when max_size is zero
> > git bisect good 2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf
> > # good: [6dc2cce9321198172cd96f955a5fc798a4cc35a6] Merge branch 'x86-
> > process-for-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> > git bisect good 6dc2cce9321198172cd96f955a5fc798a4cc35a6
> > # good: [b68e7e952f24527de62f4768b1cead91f92f5f6e] Merge branch 'for-
> > linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
> > git bisect good b68e7e952f24527de62f4768b1cead91f92f5f6e
> > # bad: [773225388dae15e72790d6f573e2e70e96292b6b] net: thunderx:
> > Optimize page recycling for XDP
> > git bisect bad 773225388dae15e72790d6f573e2e70e96292b6b
> > # bad: [edd7f4efa8111efc279582290acc4d54d405748a] Merge branch 'bpf-
> > samples-skb_mode-bug-fixes'
> > git bisect bad edd7f4efa8111efc279582290acc4d54d405748a
> > # good: [0da36b9774cc24bac4bff446edf49f31aa98a282] i40e: use
> > DECLARE_BITMAP for state fields
> > git bisect good 0da36b9774cc24bac4bff446edf49f31aa98a282
> > # bad: [1d11e732e7d501c4a231f0b32cf8b81990592689] virtio-net: use
> > netif_tx_napi_add for tx napi
> > git bisect bad 1d11e732e7d501c4a231f0b32cf8b81990592689
> > # bad: [d1f496fd8f34a40458d0eda6be0655926559e546] bpf: restore skb->sk
> > before pskb_trim() call
> > git bisect bad d1f496fd8f34a40458d0eda6be0655926559e546
> > # bad: [3dfc3eb581645bc503c7940861f494a0d75615da] i40evf: hide unused
> > variable
> > git bisect bad 3dfc3eb581645bc503c7940861f494a0d75615da
> > # bad: [47994c119a36e28e1779efabc92d6ab5329a6f75] i40e: remove
> > hw_disabled_flags in favor of using separate flag bits
> > git bisect bad 47994c119a36e28e1779efabc92d6ab5329a6f75
> > # good: [789f38ca70e0b2848472aaf5f278aa3deabd4a4e] i40evf: remove
> > needless min_t() on num_online_cpus()*2
> > git bisect good 789f38ca70e0b2848472aaf5f278aa3deabd4a4e
> > # first bad commit: [47994c119a36e28e1779efabc92d6ab5329a6f75] i40e:
> > remove hw_disabled_flags in favor of using separate flag bits
> >
> > [root@vales1 linux]# ethtool -i ens1f0
> > driver: i40e
> > version: 2.1.14-k
> > firmware-version: 5.05 0x800028a6 1.1568.0
> > expansion-rom-version:
> > bus-info: 0000:04:00.0
> > supports-statistics: yes
> > supports-test: yes
> > supports-eeprom-access: yes
> > supports-register-dump: yes
> > supports-priv-flags: yes
> >
> >
> > - Adrian
> >
>
> Okay I think I have an idea what is going on.
>
> Looking at the code there is a bug and apparently it is fixed in:
> https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-
> queue.git/commit/?h=dev-
> queue&id=b699c97b570ac69989955a7a9f05722abd3177cf
>
> I am assuming that is being submitted to net at some point since this
> is a bug that is visible in Linus's tree. Jeff do we have an ETA on
> when that patch might go out?
>
> Thanks.
>
> Alex
Yes please, we should backport the fix into net. What can I do to help this?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH] sh_eth: add support to change MTU
From: Niklas Söderlund @ 2017-06-09 20:27 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <15374026-bf82-5b4c-7d1a-53b21dff3451@cogentembedded.com>
Hi Sergei,
Thanks for your feedback.
On 2017-06-09 19:31:09 +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 06/09/2017 06:30 PM, Niklas Söderlund wrote:
>
> > The hardware supports the MTU to be changed and the driver it self is
> > somewhat prepared to support this. This patch hooks up the callbacks to
> > be able to change the MTU from user-space.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> [...]
>
> One more thing off my back, thanks! :-)
> I'm OK with this patch in principle (but have several nits):
Will update nits and send v2 containing your Acked-by.
>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Thanks :-)
>
> > diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> > index f68c4db656eda846..da41eda7bfada6b9 100644
> > --- a/drivers/net/ethernet/renesas/sh_eth.c
> > +++ b/drivers/net/ethernet/renesas/sh_eth.c
> [...]
> > @@ -3171,6 +3184,13 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
> > }
> > sh_eth_set_default_cpu_data(mdp->cd);
> >
> > + /* Datasheet states max MTU should be 2048 but due to the
>
> User's manual. :-)
Will update in v2.
> Somehow I thought it supports jumbo frames but the manual doesn't confirm
> that... ah, that's EtherAVB! :-)
Yes I did look for that but could not find that for sh_eth :-)
>
> > + * aliment calculations in sh_eth_ring_init() the practical
>
> Alignment.
Will fix in v2.
>
> > + * MTU is a bit less. Maybe this can be optimized some more.
>
> Undoubtedly... :-)
:-)
>
> [...]
>
> MBR, Sergei
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* [PATCH v2] sh_eth: add support to change MTU
From: Niklas Söderlund @ 2017-06-09 20:32 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, linux-renesas-soc, Niklas Söderlund
The hardware supports the MTU to be changed and the driver it self is
somewhat prepared to support this. This patch hooks up the callbacks to
be able to change the MTU from user-space.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Based on v4.12-rc1 and tested on Renesas R-Car Koelsch M2.
Test procedure:
1. On host set MTU to something large (9000) was used for this test.
2. On target set MTU to something other then 1500, in this test the max
MTU of 1978 is used.
3. Send ping with large payload and observe that it works.
ping -M do -s 1954 <target>
The reason for 1954 instead of 1982 is two fold:
1. On Linux (different on Mac IIRC) the ICMP/ping implementation
doesn’t encapsulate the 28 byte ICMP (8) + IP (20).
2. The driver internally reserve 4 bytes of transmission buffer for
an optional VLAN header (4). And since no VLAN is used in this
setup the additional 4 bytes can carry data.
4. For extra verification the packet flow is inspected using tcpdump to
verify that there is no packet fragmentation.
* Changes since v1
- Fix spelling mistake in comment, thanks Sergei!
- Add Acked-by from Sergei.
drivers/net/ethernet/renesas/sh_eth.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index f68c4db656eda846..9c6e4025bfc9f5c5 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -2558,6 +2558,17 @@ static int sh_eth_do_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
return phy_mii_ioctl(phydev, rq, cmd);
}
+static int sh_eth_change_mtu(struct net_device *dev, int new_mtu)
+{
+ if (netif_running(dev))
+ return -EBUSY;
+
+ dev->mtu = new_mtu;
+ netdev_update_features(dev);
+
+ return 0;
+}
+
/* For TSU_POSTn. Please refer to the manual about this (strange) bitfields */
static void *sh_eth_tsu_get_post_reg_offset(struct sh_eth_private *mdp,
int entry)
@@ -3029,6 +3040,7 @@ static const struct net_device_ops sh_eth_netdev_ops = {
.ndo_set_rx_mode = sh_eth_set_rx_mode,
.ndo_tx_timeout = sh_eth_tx_timeout,
.ndo_do_ioctl = sh_eth_do_ioctl,
+ .ndo_change_mtu = sh_eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
};
@@ -3043,6 +3055,7 @@ static const struct net_device_ops sh_eth_netdev_ops_tsu = {
.ndo_vlan_rx_kill_vid = sh_eth_vlan_rx_kill_vid,
.ndo_tx_timeout = sh_eth_tx_timeout,
.ndo_do_ioctl = sh_eth_do_ioctl,
+ .ndo_change_mtu = sh_eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
};
@@ -3171,6 +3184,13 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
}
sh_eth_set_default_cpu_data(mdp->cd);
+ /* User's manua states max MTU should be 2048 but due to the
+ * alignment calculations in sh_eth_ring_init() the practical
+ * MTU is a bit less. Maybe this can be optimized some more.
+ */
+ ndev->max_mtu = 2000 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
+ ndev->min_mtu = ETH_MIN_MTU;
+
/* set function */
if (mdp->cd->tsu)
ndev->netdev_ops = &sh_eth_netdev_ops_tsu;
--
2.13.1
^ permalink raw reply related
* Re: [PATCH v2] sh_eth: add support to change MTU
From: Niklas Söderlund @ 2017-06-09 20:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <20170609203215.1206-1-niklas.soderlund+renesas@ragnatech.se>
On 2017-06-09 22:32:15 +0200, Niklas Söderlund wrote:
> The hardware supports the MTU to be changed and the driver it self is
> somewhat prepared to support this. This patch hooks up the callbacks to
> be able to change the MTU from user-space.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
>
> Based on v4.12-rc1 and tested on Renesas R-Car Koelsch M2.
>
> Test procedure:
>
> 1. On host set MTU to something large (9000) was used for this test.
>
> 2. On target set MTU to something other then 1500, in this test the max
> MTU of 1978 is used.
>
> 3. Send ping with large payload and observe that it works.
>
> ping -M do -s 1954 <target>
>
> The reason for 1954 instead of 1982 is two fold:
>
> 1. On Linux (different on Mac IIRC) the ICMP/ping implementation
> doesn’t encapsulate the 28 byte ICMP (8) + IP (20).
> 2. The driver internally reserve 4 bytes of transmission buffer for
> an optional VLAN header (4). And since no VLAN is used in this
> setup the additional 4 bytes can carry data.
>
> 4. For extra verification the packet flow is inspected using tcpdump to
> verify that there is no packet fragmentation.
>
> * Changes since v1
> - Fix spelling mistake in comment, thanks Sergei!
> - Add Acked-by from Sergei.
>
> drivers/net/ethernet/renesas/sh_eth.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index f68c4db656eda846..9c6e4025bfc9f5c5 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -2558,6 +2558,17 @@ static int sh_eth_do_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
> return phy_mii_ioctl(phydev, rq, cmd);
> }
>
> +static int sh_eth_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + if (netif_running(dev))
> + return -EBUSY;
> +
> + dev->mtu = new_mtu;
> + netdev_update_features(dev);
> +
> + return 0;
> +}
> +
> /* For TSU_POSTn. Please refer to the manual about this (strange) bitfields */
> static void *sh_eth_tsu_get_post_reg_offset(struct sh_eth_private *mdp,
> int entry)
> @@ -3029,6 +3040,7 @@ static const struct net_device_ops sh_eth_netdev_ops = {
> .ndo_set_rx_mode = sh_eth_set_rx_mode,
> .ndo_tx_timeout = sh_eth_tx_timeout,
> .ndo_do_ioctl = sh_eth_do_ioctl,
> + .ndo_change_mtu = sh_eth_change_mtu,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_set_mac_address = eth_mac_addr,
> };
> @@ -3043,6 +3055,7 @@ static const struct net_device_ops sh_eth_netdev_ops_tsu = {
> .ndo_vlan_rx_kill_vid = sh_eth_vlan_rx_kill_vid,
> .ndo_tx_timeout = sh_eth_tx_timeout,
> .ndo_do_ioctl = sh_eth_do_ioctl,
> + .ndo_change_mtu = sh_eth_change_mtu,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_set_mac_address = eth_mac_addr,
> };
> @@ -3171,6 +3184,13 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
> }
> sh_eth_set_default_cpu_data(mdp->cd);
>
> + /* User's manua states max MTU should be 2048 but due to the
s/manua/manual/
Do I need to resend or can this be fixed up when applying? Sorry for
this.
> + * alignment calculations in sh_eth_ring_init() the practical
> + * MTU is a bit less. Maybe this can be optimized some more.
> + */
> + ndev->max_mtu = 2000 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> + ndev->min_mtu = ETH_MIN_MTU;
> +
> /* set function */
> if (mdp->cd->tsu)
> ndev->netdev_ops = &sh_eth_netdev_ops_tsu;
> --
> 2.13.1
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* BUG: Bad page state in process Compositor pfn:c03e2
From: Алексей Болдырев @ 2017-06-09 20:31 UTC (permalink / raw)
To: netdev
[ 1621.875870] BUG: Bad page state in process Compositor pfn:c03e2
[ 1621.875876] page:ffffea000300f880 count:-1 mapcount:0 mapping: (null) index:0x0
[ 1621.875878] flags: 0x100000000000000()
[ 1621.875881] raw: 0100000000000000 0000000000000000 0000000000000000 ffffffffffffffff
[ 1621.875882] raw: 0000000000000000 dead000000000200 0000000000000000 0000000000000000
[ 1621.875883] page dumped because: nonzero _count
[ 1621.875884] Modules linked in: vhost_net vhost tap af_packet tun ebtable_filter ebtables x_tables dummy nbd bridge 8021q garp mrp stp llc ata_generic pata_acpi snd_hda_codec_realtek snd_hda_codec_generic snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media snd_hda_intel snd_hda_codec snd_pcsp snd_hda_core snd_hwdep kvm_amd snd_pcm kvm snd_timer snd irqbypass e1000 soundcore pata_atiixp nouveau r8169 ttm tpm_infineon mii wmi acpi_cpufreq ohci_pci tpm_tis ohci_hcd tpm_tis_core tpm fuse ipv6 crc_ccitt unix
[ 1621.875907] CPU: 0 PID: 3674 Comm: Compositor Not tainted 4.11.3 #2
[ 1621.875907] Hardware name: MSI MS-7715/870-C45(FX) V2 (MS-7715) , BIOS V3.1 04/16/2012
[ 1621.875908] Call Trace:
[ 1621.875914] dump_stack+0x4d/0x65
[ 1621.875916] bad_page+0xc1/0x130
[ 1621.875917] check_new_page_bad+0x75/0x80
[ 1621.875918] get_page_from_freelist+0x6fd/0xab0
[ 1621.875920] ? enqueue_task_fair+0xfa5/0x1910
[ 1621.875921] ? select_task_rq_fair+0xaeb/0xed0
[ 1621.875923] __alloc_pages_nodemask+0xcb/0x200
[ 1621.875924] alloc_pages_current+0x8d/0x110
[ 1621.875926] alloc_skb_with_frags+0xcb/0x1c0
[ 1621.875928] sock_alloc_send_pskb+0x1e4/0x210
[ 1621.875931] unix_stream_sendmsg+0x26c/0x3b0 [unix]
[ 1621.875932] sock_sendmsg+0x33/0x40
[ 1621.875933] sock_write_iter+0x76/0xd0
[ 1621.875935] __do_readv_writev+0x29e/0x370
[ 1621.875936] do_readv_writev+0x78/0xa0
[ 1621.875937] vfs_writev+0x37/0x50
[ 1621.875939] ? __fdget_pos+0x12/0x50
[ 1621.875940] ? vfs_writev+0x37/0x50
[ 1621.875940] do_writev+0x4d/0xd0
[ 1621.875942] SyS_writev+0xb/0x10
[ 1621.875943] entry_SYSCALL_64_fastpath+0x13/0x94
[ 1621.875944] RIP: 0033:0x7f730f8dd2f0
[ 1621.875945] RSP: 002b:00007f72f15f55f0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
[ 1621.875946] RAX: ffffffffffffffda RBX: 00007f72cc39cf28 RCX: 00007f730f8dd2f0
[ 1621.875947] RDX: 0000000000000003 RSI: 00007f72f15f5790 RDI: 0000000000000004
[ 1621.875947] RBP: 00007f72c7ee1c00 R08: 0000000000000000 R09: 0000000000000000
[ 1621.875948] R10: 0000000000000020 R11: 0000000000000293 R12: 00007f72f15f6e01
[ 1621.875948] R13: 0000000000000000 R14: 0000000000000166 R15: 00007f72cc39d428
[ 1621.875949] Disabling lock debugging due to kernel taint
^ permalink raw reply
* Re: [PATCH v2] sh_eth: add support to change MTU
From: Sergei Shtylyov @ 2017-06-09 20:44 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: netdev, linux-renesas-soc
In-Reply-To: <20170609203215.1206-1-niklas.soderlund+renesas@ragnatech.se>
On 06/09/2017 11:32 PM, Niklas Söderlund wrote:
> The hardware supports the MTU to be changed and the driver it self is
> somewhat prepared to support this. This patch hooks up the callbacks to
> be able to change the MTU from user-space.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
>
> Based on v4.12-rc1 and tested on Renesas R-Car Koelsch M2.
>
> Test procedure:
>
> 1. On host set MTU to something large (9000) was used for this test.
>
> 2. On target set MTU to something other then 1500, in this test the max
> MTU of 1978 is used.
>
> 3. Send ping with large payload and observe that it works.
>
> ping -M do -s 1954 <target>
>
> The reason for 1954 instead of 1982 is two fold:
>
> 1. On Linux (different on Mac IIRC) the ICMP/ping implementation
> doesn’t encapsulate the 28 byte ICMP (8) + IP (20).
> 2. The driver internally reserve 4 bytes of transmission buffer for
> an optional VLAN header (4). And since no VLAN is used in this
> setup the additional 4 bytes can carry data.
>
> 4. For extra verification the packet flow is inspected using tcpdump to
> verify that there is no packet fragmentation.
>
> * Changes since v1
> - Fix spelling mistake in comment, thanks Sergei!
> - Add Acked-by from Sergei.
>
> drivers/net/ethernet/renesas/sh_eth.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index f68c4db656eda846..9c6e4025bfc9f5c5 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -2558,6 +2558,17 @@ static int sh_eth_do_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
> return phy_mii_ioctl(phydev, rq, cmd);
> }
>
> +static int sh_eth_change_mtu(struct net_device *dev, int new_mtu)
Hmm, wait... The 'struct net_device *' typed variables are consistently
called 'ndev' throughout the driver. Please rename, sorry for not noticing the
1st time... :-<
[...]
MBR, Sergei
^ permalink raw reply
* office for an agent/mediator
From: Martin Parrish @ 2017-06-09 20:48 UTC (permalink / raw)
VALERO CRUDE USA is looking for an agent, to be our coordinator in
Europe and Asia,
which you will act as an intermediary between our company and the
final buyer of petroleum products in those regions,Inform us if you are
interested
Sincerely,
Martin Parrish
(Vice-President Alternate Fuels)
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Initial skb->dev and skb->protocol in ip6_output
From: Eric Dumazet @ 2017-06-09 21:11 UTC (permalink / raw)
To: Chenbo Feng; +Cc: netdev, David Miller, Lorenzo Colitti, Chenbo Feng
In-Reply-To: <1497035168-9093-1-git-send-email-chenbofeng.kernel@gmail.com>
On Fri, Jun 9, 2017 at 12:06 PM, Chenbo Feng
<chenbofeng.kernel@gmail.com> wrote:
> From: Chenbo Feng <fengc@google.com>
>
> Move the initialization of skb->dev and skb->protocol from
> ip6_finish_output2 to ip6_output. This can make the skb->dev and
> skb->protocol information avalaible to the CGROUP eBPF filter.
>
> Signed-off-by: Chenbo Feng <fengc@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> ---
Arg, you mixed my Acked-by for your other patch :/
^ permalink raw reply
* Re: [PATCH net-next] bpf: Remove duplicate tcp_filter hook in ipv6
From: Eric Dumazet @ 2017-06-09 21:12 UTC (permalink / raw)
To: Chenbo Feng; +Cc: netdev, David Miller, Lorenzo Colitti, Chenbo Feng
In-Reply-To: <1497035857-9927-1-git-send-email-chenbofeng.kernel@gmail.com>
On Fri, Jun 9, 2017 at 12:17 PM, Chenbo Feng
<chenbofeng.kernel@gmail.com> wrote:
> From: Chenbo Feng <fengc@google.com>
>
> There are two tcp_filter hooks in tcp_ipv6 ingress path currently.
> One is at tcp_v6_rcv and another is in tcp_v6_do_rcv. It seems the
> tcp_filter() call inside tcp_v6_do_rcv is redundent and some packet
> will be filtered twice in this situation. This will cause trouble
> when using eBPF filters to account traffic data.
>
> Signed-off-by: Chenbo Feng <fengc@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv6/tcp_ipv6.c | 3 ---
> 1 file changed, 3 deletions(-)
Yes, this is the patch I agreed on ;)
Thanks
^ permalink raw reply
* Re: Repeatable inet6_dump_fib crash in stock 4.12.0-rc4+
From: Eric Dumazet @ 2017-06-09 21:25 UTC (permalink / raw)
To: David Ahern; +Cc: Cong Wang, Ben Greear, netdev
In-Reply-To: <7e0c97fa-cd6e-ed0f-bf99-0e4af40fbd2f@gmail.com>
On Fri, 2017-06-09 at 07:27 -0600, David Ahern wrote:
> On 6/8/17 11:55 PM, Cong Wang wrote:
> > On Thu, Jun 8, 2017 at 2:27 PM, Ben Greear <greearb@candelatech.com> wrote:
> >>
> >> As far as I can tell, the patch did not help, or at least we still reproduce
> >> the
> >> crash easily.
> >
> > netlink dump is serialized by nlk->cb_mutex so I don't think that
> > patch makes any sense w.r.t race condition.
>
> From what I can see fn_sernum should be accessed under table lock, so
> when saving and checking it during a walk make sure it the lock is held.
> That has nothing to do with the netlink dump, but the table changing
> during a walk.
Yes, your patch makes total sense, of course.
>
>
> >> (gdb) l *(fib6_walk_continue+0x76)
> >> 0x188c6 is in fib6_walk_continue
> >> (/home/greearb/git/linux-2.6/net/ipv6/ip6_fib.c:1593).
> >> 1588 if (fn == w->root)
> >> 1589 return 0;
> >> 1590 pn = fn->parent;
> >> 1591 w->node = pn;
> >> 1592 #ifdef CONFIG_IPV6_SUBTREES
> >> 1593 if (FIB6_SUBTREE(pn) == fn) {
> >
> > Apparently fn->parent is NULL here for some reason, but
> > I don't know if that is expected or not. If a simple NULL check
> > is not enough here, we have to trace why it is NULL.
>
> From my understanding, parent should not be null hence the attempts to
> fix access to table nodes under a lock. ie., figuring out why it is null
> here.
^ permalink raw reply
* Re: [PATCH net-next 0/3] mlx4 drivers: version update
From: Doug Ledford @ 2017-06-09 21:26 UTC (permalink / raw)
To: David Miller, tariqt-VPRAkNaXOzVWk0Htik3J/w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
eranbe-VPRAkNaXOzVWk0Htik3J/w, leonro-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20170607.153333.2137691985139660875.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wed, 2017-06-07 at 15:33 -0400, David Miller wrote:
> From: Tariq Toukan <tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Date: Wed, 7 Jun 2017 16:26:12 +0300
>
> > This patchset contains version updates for the MLX4 drivers:
> > Core, EN, and IB.
> >
> > Just like we've done in mlx5, we modify the outdated driver
> > version (reported in ethtool for example).
> > This better reflects the current driver state, and removes the
> > redundant date string.
> > We are not going to change this frequently or even use it.
> >
> > I include the IB patch in this series as it has similar subject
> > and content.
> > It does not cause any kind of conflict with Doug's tree.
> > The rdma mailing list is CCed.
> > Please let me know if I need to submit this differently.
>
> Ok, series applied.
>
> Doug, let me know if you want to handle this differently or want
> me to change something.
>
> Thanks.
You've got it, I'll skip it, it's all good.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] ipv4: igmp: fix a use after free
From: Cong Wang @ 2017-06-09 21:35 UTC (permalink / raw)
To: Xin Long; +Cc: Eric Dumazet, Andrey Konovalov, David S. Miller, netdev
In-Reply-To: <CADvbK_fbxdkZUdJK=qUx+neTNfiOUJrm3-AvBa2+a4eB1b+PWA@mail.gmail.com>
On Fri, Jun 9, 2017 at 11:05 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Sat, Jun 10, 2017 at 1:01 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> This is what I thought in my first response, until I realized
>> it is not pure RCU, otherwise pmc->lock should not be taken
>> in igmpv3_send_cr(). It seems the code is mixing the use
>> of spinlock and RCU.
> rcu lock is for pmc not being freed, and spinlock is for pmc's
> members' modification. is there some rule these two locks
> should be mixed?
>
This is exactly why I said we are mixing RCU and spinlock.
>
>>
>> We need RCU anyway, ip_check_mc_rcu() is the real fast
>> path where we don't take spinlock. I think we will need more
>> work.
> It seems all add_grec() callings needs spinlock, maybe add_grec
> modifies pmc's member. it's hard to drop spinlock.
>
> from ip_check_mc_rcu you mentioned about, it should be right
> to call ip_mc_clear_src after rcu grace period, like Eric's patch.
Well, more than just that, we need to use proper RCU API for
pmc->sources and you know it is a singly linked list...
I will work on this.
^ permalink raw reply
* Re: [PATCH net] Fix an intermittent pr_emerg warning about lo becoming free.
From: Cong Wang @ 2017-06-09 21:48 UTC (permalink / raw)
To: Krister Johansen
Cc: David Miller, Eric Dumazet, Linux Kernel Network Developers,
Kaiwen Xu
In-Reply-To: <20170609184303.GC2766@templeofstupid.com>
On Fri, Jun 9, 2017 at 11:43 AM, Krister Johansen
<kjlx@templeofstupid.com> wrote:
> On Fri, Jun 09, 2017 at 11:18:44AM -0700, Cong Wang wrote:
>> On Thu, Jun 8, 2017 at 1:12 PM, Krister Johansen
>> <kjlx@templeofstupid.com> wrote:
>> > The way this works is that if there's still a reference on the dst entry
>> > at the time we try to free it, it gets placed in the gc list by
>> > __dst_free and the dst_destroy() call is invoked by the gc task once the
>> > refcount is 0. If the gc task processes a 10th or less of its entries
>> > on a single pass, it inreases the amount of time it waits between gc
>> > intervals.
>> >
>> > Looking at the gc_task intervals, they started at 663ms when we invoked
>> > __dst_free(). After that, they increased to 1663, 3136, 5567, 8191,
>> > 10751, and 14848. The release that set the refcnt to 0 on our dst entry
>> > occurred after the gc_task was enqueued for 14 second interval so we had
>> > to wait longer than the warning time in wait_allrefs in order for the
>> > dst entry to get free'd and the hold on 'lo' to be released.
>> >
>>
>> I am glad to see you don't have a dst leak here.
>>
>> But from my experience of a similar bug (refcnt wait on lo), this goes
>> infinitely rather than just 14sec, so it looked more like a real leak than
>> just a gc delay. So in your case, this annoying warning eventually
>> disappears, right?
>
> That's correct. The problem occurs intermittently, and the warnings are
> less frequent than the interval in netdev_wait_allrefs(). At least when
> I observed it, it tended to conincide with our controlplane canary
> issuing an API call that lead to a network namespace teardown on the
> dataplane.
Great! Then the bug I saw is different from this one and it is probably
a dst leak.
Thanks.
^ permalink raw reply
* [PATCH] net: aquantia: atlantic: remove declaration of hw_atl_utils_hw_set_power
From: Philippe Reynes @ 2017-06-09 21:50 UTC (permalink / raw)
To: Alexander.Loktionov, Pavel.Belous, davem, Dmitry.Bezrukov,
vomlehn
Cc: netdev, linux-kernel, Philippe Reynes
This function is not defined, so no need to declare it.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
.../aquantia/atlantic/hw_atl/hw_atl_utils.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
index b8e3d88..a66aee5 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
@@ -193,9 +193,6 @@ int hw_atl_utils_hw_get_regs(struct aq_hw_s *self,
struct aq_hw_caps_s *aq_hw_caps,
u32 *regs_buff);
-int hw_atl_utils_hw_get_settings(struct aq_hw_s *self,
- struct ethtool_cmd *cmd);
-
int hw_atl_utils_hw_set_power(struct aq_hw_s *self,
unsigned int power_state);
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 2/8] net: ena: fix bug that might cause hang after consecutive open/close interface.
From: netanel @ 2017-06-09 22:13 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys
In-Reply-To: <1497046437-20390-1-git-send-email-netanel@amazon.com>
From: Netanel Belgazal <netanel@amazon.com>
Fixing a bug that the driver does not unmask the IO interrupts
in ndo_open():
occasionally, the MSI-X interrupt (for one or more IO queues)
can be masked when ndo_close() was called.
If that is followed by ndo open(),
then the MSI-X will be still masked so no interrupt
will be received by the driver.
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 41 ++++++++++++++++++----------
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 7c1214d..0e3c60c7 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -1078,6 +1078,26 @@ inline void ena_adjust_intr_moderation(struct ena_ring *rx_ring,
rx_ring->per_napi_bytes = 0;
}
+static inline void ena_unmask_interrupt(struct ena_ring *tx_ring,
+ struct ena_ring *rx_ring)
+{
+ struct ena_eth_io_intr_reg intr_reg;
+
+ /* Update intr register: rx intr delay,
+ * tx intr delay and interrupt unmask
+ */
+ ena_com_update_intr_reg(&intr_reg,
+ rx_ring->smoothed_interval,
+ tx_ring->smoothed_interval,
+ true);
+
+ /* It is a shared MSI-X.
+ * Tx and Rx CQ have pointer to it.
+ * So we use one of them to reach the intr reg
+ */
+ ena_com_unmask_intr(rx_ring->ena_com_io_cq, &intr_reg);
+}
+
static inline void ena_update_ring_numa_node(struct ena_ring *tx_ring,
struct ena_ring *rx_ring)
{
@@ -1108,7 +1128,6 @@ static int ena_io_poll(struct napi_struct *napi, int budget)
{
struct ena_napi *ena_napi = container_of(napi, struct ena_napi, napi);
struct ena_ring *tx_ring, *rx_ring;
- struct ena_eth_io_intr_reg intr_reg;
u32 tx_work_done;
u32 rx_work_done;
@@ -1149,22 +1168,9 @@ static int ena_io_poll(struct napi_struct *napi, int budget)
if (ena_com_get_adaptive_moderation_enabled(rx_ring->ena_dev))
ena_adjust_intr_moderation(rx_ring, tx_ring);
- /* Update intr register: rx intr delay,
- * tx intr delay and interrupt unmask
- */
- ena_com_update_intr_reg(&intr_reg,
- rx_ring->smoothed_interval,
- tx_ring->smoothed_interval,
- true);
-
- /* It is a shared MSI-X.
- * Tx and Rx CQ have pointer to it.
- * So we use one of them to reach the intr reg
- */
- ena_com_unmask_intr(rx_ring->ena_com_io_cq, &intr_reg);
+ ena_unmask_interrupt(tx_ring, rx_ring);
}
-
ena_update_ring_numa_node(tx_ring, rx_ring);
ret = rx_work_done;
@@ -1485,6 +1491,11 @@ static int ena_up_complete(struct ena_adapter *adapter)
ena_napi_enable_all(adapter);
+ /* Enable completion queues interrupt */
+ for (i = 0; i < adapter->num_queues; i++)
+ ena_unmask_interrupt(&adapter->tx_ring[i],
+ &adapter->rx_ring[i]);
+
/* schedule napi in case we had pending packets
* from the last time we disable napi
*/
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 0/8] Bug fixes in ena ethernet driver
From: Belgazal, Netanel @ 2017-06-09 22:13 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Woodhouse, David, Machulsky, Zorik,
Matushevsky, Alexander, BSHARA, Said, Wilson, Matt,
Liguori, Anthony, Bshara, Nafea, Schmeilin, Evgeny
In-Reply-To: <20170609.153312.1390770571565991697.davem@davemloft.net>
I the last minute I fixed patchset #6 commit subject from stuck to hang and I forget to remove it.
Sorry for that.
resubmitted.
________________________________________
From: David Miller <davem@davemloft.net>
Sent: Friday, June 9, 2017 10:33 PM
To: Belgazal, Netanel
Cc: netdev@vger.kernel.org; Woodhouse, David; Machulsky, Zorik; Matushevsky, Alexander; BSHARA, Said; Wilson, Matt; Liguori, Anthony; Bshara, Nafea; Schmeilin, Evgeny
Subject: Re: [PATCH net-next 0/8] Bug fixes in ena ethernet driver
From: <netanel@amazon.com>
Date: Fri, 9 Jun 2017 09:55:16 +0300
> This patchset contains fixes for the bugs that were discovered so far.
You submitted patch #6 twice, once with the word "stuck" in the subject
line, once with the word "hang" in the subject line.
Please sort this out and resubmit, thanks.
^ permalink raw reply
* [PATCH net-next 3/8] net: ena: add missing return when ena_com_get_io_handlers() fails
From: netanel @ 2017-06-09 22:13 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys
In-Reply-To: <1497046437-20390-1-git-send-email-netanel@amazon.com>
From: Netanel Belgazal <netanel@amazon.com>
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 0e3c60c7..1e71e89 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -1543,6 +1543,7 @@ static int ena_create_io_tx_queue(struct ena_adapter *adapter, int qid)
"Failed to get TX queue handlers. TX queue num %d rc: %d\n",
qid, rc);
ena_com_destroy_io_queue(ena_dev, ena_qid);
+ return rc;
}
ena_com_update_numa_node(tx_ring->ena_com_io_cq, ctx.numa_node);
@@ -1607,6 +1608,7 @@ static int ena_create_io_rx_queue(struct ena_adapter *adapter, int qid)
"Failed to get RX queue handlers. RX queue num %d rc: %d\n",
qid, rc);
ena_com_destroy_io_queue(ena_dev, ena_qid);
+ return rc;
}
ena_com_update_numa_node(rx_ring->ena_com_io_cq, ctx.numa_node);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/8] Bug fixes in ena ethernet driver
From: netanel @ 2017-06-09 22:13 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys
From: Netanel Belgazal <netanel@amazon.com>
This patchset contains fixes for the bugs that were discovered so far.
Netanel Belgazal (8):
net: ena: fix rare uncompleted admin command false alarm
net: ena: fix bug that might cause hang after consecutive open/close
interface.
net: ena: add missing return when ena_com_get_io_handlers() fails
net: ena: fix race condition between submit and completion admin
command
net: ena: add missing unmap bars on device removal
net: ena: fix theoretical Rx hang on low memory systems
net: ena: disable admin msix while working in polling mode
net: ena: bug fix in lost tx packets detection mechanism
drivers/net/ethernet/amazon/ena/ena_com.c | 35 +++--
drivers/net/ethernet/amazon/ena/ena_ethtool.c | 2 +-
drivers/net/ethernet/amazon/ena/ena_netdev.c | 179 +++++++++++++++++++-------
drivers/net/ethernet/amazon/ena/ena_netdev.h | 16 ++-
4 files changed, 168 insertions(+), 64 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 1/8] net: ena: fix rare uncompleted admin command false alarm
From: netanel @ 2017-06-09 22:13 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys
In-Reply-To: <1497046437-20390-1-git-send-email-netanel@amazon.com>
From: Netanel Belgazal <netanel@amazon.com>
The current flow to detect admin completion is:
while (command_not_completed) {
if (timeout)
error
check_for_completion()
sleep()
}
So in case the sleep took more than the timeout
(in case the thread/workqueue was not scheduled due to higher priority
task or prolonged VMexit), the driver can detect a stall even if
the completion is present.
The fix changes the order of this function to first check for
completion and only after that check if the timeout expired.
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_com.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
index 08d11ce..e1c2fab 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_com.c
@@ -508,15 +508,20 @@ static int ena_com_comp_status_to_errno(u8 comp_status)
static int ena_com_wait_and_process_admin_cq_polling(struct ena_comp_ctx *comp_ctx,
struct ena_com_admin_queue *admin_queue)
{
- unsigned long flags;
- u32 start_time;
+ unsigned long flags, timeout;
int ret;
- start_time = ((u32)jiffies_to_usecs(jiffies));
+ timeout = jiffies + ADMIN_CMD_TIMEOUT_US;
+
+ while (1) {
+ spin_lock_irqsave(&admin_queue->q_lock, flags);
+ ena_com_handle_admin_completion(admin_queue);
+ spin_unlock_irqrestore(&admin_queue->q_lock, flags);
- while (comp_ctx->status == ENA_CMD_SUBMITTED) {
- if ((((u32)jiffies_to_usecs(jiffies)) - start_time) >
- ADMIN_CMD_TIMEOUT_US) {
+ if (comp_ctx->status != ENA_CMD_SUBMITTED)
+ break;
+
+ if (time_is_before_jiffies(timeout)) {
pr_err("Wait for completion (polling) timeout\n");
/* ENA didn't have any completion */
spin_lock_irqsave(&admin_queue->q_lock, flags);
@@ -528,10 +533,6 @@ static int ena_com_wait_and_process_admin_cq_polling(struct ena_comp_ctx *comp_c
goto err;
}
- spin_lock_irqsave(&admin_queue->q_lock, flags);
- ena_com_handle_admin_completion(admin_queue);
- spin_unlock_irqrestore(&admin_queue->q_lock, flags);
-
msleep(100);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 4/8] net: ena: fix race condition between submit and completion admin command
From: netanel @ 2017-06-09 22:13 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys
In-Reply-To: <1497046437-20390-1-git-send-email-netanel@amazon.com>
From: Netanel Belgazal <netanel@amazon.com>
Bug:
"Completion context is occupied" error printout will be noticed in
dmesg.
This error will cause the admin command to fail, which will lead to
an ena_probe() failure or a watchdog reset (depends on which admin
command failed).
Root cause:
__ena_com_submit_admin_cmd() is the function that submits new entries to
the admin queue.
The function have a check that makes sure the queue is not full and the
function does not override any outstanding command.
It uses head and tail indexes for this check.
The head is increased by ena_com_handle_admin_completion() which runs
from interrupt context, and the tail index is increased by the submit
function (the function is running under ->q_lock, so there is no risk
of multithread increment).
Each command is associated with a completion context. This context
allocated before call to __ena_com_submit_admin_cmd() and freed by
ena_com_wait_and_process_admin_cq_interrupts(), right after the command
was completed.
This can lead to a state where the head was increased, the check passed,
but the completion context is still in use.
Solution:
Use the atomic variable ->outstanding_cmds instead of using the head and
the tail indexes.
This variable is safe for use since it is bumped in get_comp_ctx() in
__ena_com_submit_admin_cmd() and is freed by comp_ctxt_release()
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_com.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
index e1c2fab..ea60b9e 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_com.c
@@ -232,11 +232,9 @@ static struct ena_comp_ctx *__ena_com_submit_admin_cmd(struct ena_com_admin_queu
tail_masked = admin_queue->sq.tail & queue_size_mask;
/* In case of queue FULL */
- cnt = admin_queue->sq.tail - admin_queue->sq.head;
+ cnt = atomic_read(&admin_queue->outstanding_cmds);
if (cnt >= admin_queue->q_depth) {
- pr_debug("admin queue is FULL (tail %d head %d depth: %d)\n",
- admin_queue->sq.tail, admin_queue->sq.head,
- admin_queue->q_depth);
+ pr_debug("admin queue is full.\n");
admin_queue->stats.out_of_space++;
return ERR_PTR(-ENOSPC);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 5/8] net: ena: add missing unmap bars on device removal
From: netanel @ 2017-06-09 22:13 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys
In-Reply-To: <1497046437-20390-1-git-send-email-netanel@amazon.com>
From: Netanel Belgazal <netanel@amazon.com>
This patch also change the mapping functions to devm_ functions
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 1e71e89..4e9fbdd 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -2853,6 +2853,11 @@ static void ena_release_bars(struct ena_com_dev *ena_dev, struct pci_dev *pdev)
{
int release_bars;
+ if (ena_dev->mem_bar)
+ devm_iounmap(&pdev->dev, ena_dev->mem_bar);
+
+ devm_iounmap(&pdev->dev, ena_dev->reg_bar);
+
release_bars = pci_select_bars(pdev, IORESOURCE_MEM) & ENA_BAR_MASK;
pci_release_selected_regions(pdev, release_bars);
}
@@ -2940,8 +2945,9 @@ static int ena_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_free_ena_dev;
}
- ena_dev->reg_bar = ioremap(pci_resource_start(pdev, ENA_REG_BAR),
- pci_resource_len(pdev, ENA_REG_BAR));
+ ena_dev->reg_bar = devm_ioremap(&pdev->dev,
+ pci_resource_start(pdev, ENA_REG_BAR),
+ pci_resource_len(pdev, ENA_REG_BAR));
if (!ena_dev->reg_bar) {
dev_err(&pdev->dev, "failed to remap regs bar\n");
rc = -EFAULT;
@@ -2961,8 +2967,9 @@ static int ena_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
ena_set_push_mode(pdev, ena_dev, &get_feat_ctx);
if (ena_dev->tx_mem_queue_type == ENA_ADMIN_PLACEMENT_POLICY_DEV) {
- ena_dev->mem_bar = ioremap_wc(pci_resource_start(pdev, ENA_MEM_BAR),
- pci_resource_len(pdev, ENA_MEM_BAR));
+ ena_dev->mem_bar = devm_ioremap_wc(&pdev->dev,
+ pci_resource_start(pdev, ENA_MEM_BAR),
+ pci_resource_len(pdev, ENA_MEM_BAR));
if (!ena_dev->mem_bar) {
rc = -EFAULT;
goto err_device_destroy;
--
2.7.4
^ 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