* Re: [iproute2] Bug#898840: Latest update breaks ip6 default gateway cli api
From: Luca Boccassi @ 2018-05-16 16:48 UTC (permalink / raw)
To: Michal Kubecek, netdev
Cc: Serhey Popovych, Stephen Hemminger, Hans van Kranenburg, 898840
In-Reply-To: <20180516145344.fle2t7qng7cvowsu@unicorn.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Wed, 2018-05-16 at 16:53 +0200, Michal Kubecek wrote:
> On Wed, May 16, 2018 at 02:42:24PM +0100, Luca Boccassi wrote:
> > Hans reported a regression in v4.16.0, ip route now requires -6 to
> > be
> > manually added when using v6 addresses while up to 4.15 it didn't,
> > the
> > commands quoted show the problem.
> >
> > Bisecting shows that the following commit from Serhey introduced
> > the
> > problem:
> >
> > 93fa12418dc6f5943692250244be303bb162175b
> > utils: Always specify family and ->bytelen in get_prefix_1()
> >
> > Could you please have a look when you have a moment? It's very easy
> > to
> > reproduce, and it breaks existing scripts and so on.
>
> Fixed already:
Ah fantastic, thanks, sorry I missed that.
--
Kind regards,
Luca Boccassi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()
From: kbuild test robot @ 2018-05-16 16:33 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, Florian Fainelli, Andrew Lunn, Vivien Didelot,
David S. Miller, Nicolas Ferre, Fugang Duan, Sergei Shtylyov,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Grygorii Strashko, Woojung Huh, Microchip Linux Driver Support,
Rob Herring, Frank Rowand, Antoine Tenart, Tobias Jordan <Tob
In-Reply-To: <20180515215930.12115-3-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 20047 bytes --]
Hi Florian,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/of-mdio-Fall-back-to-mdiobus_register-with-np-is-NULL/20180516-203317
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
.runtime_suspend = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:527:21: note: (near initialization for 'davinci_mdio_pm_ops.runtime_suspend')
SET_RUNTIME_PM_OPS(davinci_mdio_runtime_suspend,
^
include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_suspend = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:528:7: error: initializer element is not constant
davinci_mdio_runtime_resume, NULL)
^
include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_resume = resume_fn, \
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:528:7: note: (near initialization for 'davinci_mdio_pm_ops.runtime_resume')
davinci_mdio_runtime_resume, NULL)
^
include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_resume = resume_fn, \
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:330:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.suspend_late = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:31: note: (near initialization for 'davinci_mdio_pm_ops.suspend_late')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:330:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.suspend_late = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:53: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:331:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.resume_early = resume_fn, \
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:53: note: (near initialization for 'davinci_mdio_pm_ops.resume_early')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:331:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.resume_early = resume_fn, \
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:332:17: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.freeze_late = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:31: note: (near initialization for 'davinci_mdio_pm_ops.freeze_late')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:332:17: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.freeze_late = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:53: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:333:16: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.thaw_early = resume_fn, \
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:53: note: (near initialization for 'davinci_mdio_pm_ops.thaw_early')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:333:16: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.thaw_early = resume_fn, \
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:334:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.poweroff_late = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:31: note: (near initialization for 'davinci_mdio_pm_ops.poweroff_late')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:334:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.poweroff_late = suspend_fn, \
^~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:53: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:335:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.restore_early = resume_fn,
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:529:53: note: (near initialization for 'davinci_mdio_pm_ops.restore_early')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:335:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.restore_early = resume_fn,
^~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:539:12: error: initializer element is not constant
.remove = davinci_mdio_remove,
^~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:539:12: note: (near initialization for 'davinci_mdio_driver.remove')
drivers/net//ethernet/ti/davinci_mdio.c:542:19: error: invalid storage class for function 'davinci_mdio_init'
static int __init davinci_mdio_init(void)
^~~~~~~~~~~~~~~~~
In file included from drivers/net//ethernet/ti/davinci_mdio.c:27:0:
>> include/linux/module.h:130:42: error: invalid storage class for function '__inittest'
static inline initcall_t __maybe_unused __inittest(void) \
^
include/linux/module.h:120:30: note: in expansion of macro 'module_init'
#define device_initcall(fn) module_init(fn)
^~~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:546:1: note: in expansion of macro 'device_initcall'
device_initcall(davinci_mdio_init);
^~~~~~~~~~~~~~~
>> drivers/net//ethernet/ti/davinci_mdio.c:546:1: warning: 'alias' attribute ignored [-Wattributes]
drivers/net//ethernet/ti/davinci_mdio.c:548:20: error: invalid storage class for function 'davinci_mdio_exit'
static void __exit davinci_mdio_exit(void)
^~~~~~~~~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:548:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
static void __exit davinci_mdio_exit(void)
^~~~~~
In file included from drivers/net//ethernet/ti/davinci_mdio.c:27:0:
>> include/linux/module.h:136:42: error: invalid storage class for function '__exittest'
static inline exitcall_t __maybe_unused __exittest(void) \
^
drivers/net//ethernet/ti/davinci_mdio.c:552:1: note: in expansion of macro 'module_exit'
module_exit(davinci_mdio_exit);
^~~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:552:1: warning: 'alias' attribute ignored [-Wattributes]
In file included from include/linux/module.h:18:0,
from drivers/net//ethernet/ti/davinci_mdio.c:27:
include/linux/moduleparam.h:22:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
static const char __UNIQUE_ID(name)[] \
^
include/linux/module.h:161:32: note: in expansion of macro '__MODULE_INFO'
#define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
^~~~~~~~~~~~~
include/linux/module.h:199:34: note: in expansion of macro 'MODULE_INFO'
#define MODULE_LICENSE(_license) MODULE_INFO(license, _license)
^~~~~~~~~~~
drivers/net//ethernet/ti/davinci_mdio.c:554:1: note: in expansion of macro 'MODULE_LICENSE'
MODULE_LICENSE("GPL");
^~~~~~~~~~~~~~
>> drivers/net//ethernet/ti/davinci_mdio.c:555:1: error: expected declaration or statement at end of input
MODULE_DESCRIPTION("DaVinci MDIO driver");
^~~~~~~~~~~~~~~~~~
At top level:
drivers/net//ethernet/ti/davinci_mdio.c:357:12: warning: 'davinci_mdio_probe' defined but not used [-Wunused-function]
static int davinci_mdio_probe(struct platform_device *pdev)
^~~~~~~~~~~~~~~~~~
--
.runtime_suspend = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:527:21: note: (near initialization for 'davinci_mdio_pm_ops.runtime_suspend')
SET_RUNTIME_PM_OPS(davinci_mdio_runtime_suspend,
^
include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_suspend = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:528:7: error: initializer element is not constant
davinci_mdio_runtime_resume, NULL)
^
include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_resume = resume_fn, \
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:528:7: note: (near initialization for 'davinci_mdio_pm_ops.runtime_resume')
davinci_mdio_runtime_resume, NULL)
^
include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_resume = resume_fn, \
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:31: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:330:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.suspend_late = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:31: note: (near initialization for 'davinci_mdio_pm_ops.suspend_late')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:330:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.suspend_late = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:53: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:331:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.resume_early = resume_fn, \
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:53: note: (near initialization for 'davinci_mdio_pm_ops.resume_early')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:331:18: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.resume_early = resume_fn, \
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:31: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:332:17: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.freeze_late = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:31: note: (near initialization for 'davinci_mdio_pm_ops.freeze_late')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:332:17: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.freeze_late = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:53: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:333:16: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.thaw_early = resume_fn, \
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:53: note: (near initialization for 'davinci_mdio_pm_ops.thaw_early')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:333:16: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.thaw_early = resume_fn, \
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:31: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:334:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.poweroff_late = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:31: note: (near initialization for 'davinci_mdio_pm_ops.poweroff_late')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:334:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.poweroff_late = suspend_fn, \
^~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:53: error: initializer element is not constant
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:335:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.restore_early = resume_fn,
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:529:53: note: (near initialization for 'davinci_mdio_pm_ops.restore_early')
SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
include/linux/pm.h:335:19: note: in definition of macro 'SET_LATE_SYSTEM_SLEEP_PM_OPS'
.restore_early = resume_fn,
^~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:539:12: error: initializer element is not constant
.remove = davinci_mdio_remove,
^~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:539:12: note: (near initialization for 'davinci_mdio_driver.remove')
drivers/net/ethernet/ti/davinci_mdio.c:542:19: error: invalid storage class for function 'davinci_mdio_init'
static int __init davinci_mdio_init(void)
^~~~~~~~~~~~~~~~~
In file included from drivers/net/ethernet/ti/davinci_mdio.c:27:0:
>> include/linux/module.h:130:42: error: invalid storage class for function '__inittest'
static inline initcall_t __maybe_unused __inittest(void) \
^
include/linux/module.h:120:30: note: in expansion of macro 'module_init'
#define device_initcall(fn) module_init(fn)
^~~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:546:1: note: in expansion of macro 'device_initcall'
device_initcall(davinci_mdio_init);
^~~~~~~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:546:1: warning: 'alias' attribute ignored [-Wattributes]
drivers/net/ethernet/ti/davinci_mdio.c:548:20: error: invalid storage class for function 'davinci_mdio_exit'
static void __exit davinci_mdio_exit(void)
^~~~~~~~~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:548:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
static void __exit davinci_mdio_exit(void)
^~~~~~
In file included from drivers/net/ethernet/ti/davinci_mdio.c:27:0:
>> include/linux/module.h:136:42: error: invalid storage class for function '__exittest'
static inline exitcall_t __maybe_unused __exittest(void) \
^
drivers/net/ethernet/ti/davinci_mdio.c:552:1: note: in expansion of macro 'module_exit'
module_exit(davinci_mdio_exit);
^~~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:552:1: warning: 'alias' attribute ignored [-Wattributes]
In file included from include/linux/module.h:18:0,
from drivers/net/ethernet/ti/davinci_mdio.c:27:
include/linux/moduleparam.h:22:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
static const char __UNIQUE_ID(name)[] \
^
include/linux/module.h:161:32: note: in expansion of macro '__MODULE_INFO'
#define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
^~~~~~~~~~~~~
include/linux/module.h:199:34: note: in expansion of macro 'MODULE_INFO'
#define MODULE_LICENSE(_license) MODULE_INFO(license, _license)
^~~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:554:1: note: in expansion of macro 'MODULE_LICENSE'
MODULE_LICENSE("GPL");
^~~~~~~~~~~~~~
drivers/net/ethernet/ti/davinci_mdio.c:555:1: error: expected declaration or statement at end of input
MODULE_DESCRIPTION("DaVinci MDIO driver");
^~~~~~~~~~~~~~~~~~
At top level:
drivers/net/ethernet/ti/davinci_mdio.c:357:12: warning: 'davinci_mdio_probe' defined but not used [-Wunused-function]
static int davinci_mdio_probe(struct platform_device *pdev)
^~~~~~~~~~~~~~~~~~
vim +/__inittest +130 include/linux/module.h
0fd972a7 Paul Gortmaker 2015-05-01 127
0fd972a7 Paul Gortmaker 2015-05-01 128 /* Each module must use one module_init(). */
0fd972a7 Paul Gortmaker 2015-05-01 129 #define module_init(initfn) \
1f318a8b Arnd Bergmann 2017-02-01 @130 static inline initcall_t __maybe_unused __inittest(void) \
0fd972a7 Paul Gortmaker 2015-05-01 131 { return initfn; } \
0fd972a7 Paul Gortmaker 2015-05-01 132 int init_module(void) __attribute__((alias(#initfn)));
0fd972a7 Paul Gortmaker 2015-05-01 133
0fd972a7 Paul Gortmaker 2015-05-01 134 /* This is only required if you want to be unloadable. */
0fd972a7 Paul Gortmaker 2015-05-01 135 #define module_exit(exitfn) \
1f318a8b Arnd Bergmann 2017-02-01 @136 static inline exitcall_t __maybe_unused __exittest(void) \
0fd972a7 Paul Gortmaker 2015-05-01 137 { return exitfn; } \
0fd972a7 Paul Gortmaker 2015-05-01 138 void cleanup_module(void) __attribute__((alias(#exitfn)));
0fd972a7 Paul Gortmaker 2015-05-01 139
:::::: The code at line 130 was first introduced by commit
:::::: 1f318a8bafcfba9f0d623f4870c4e890fd22e659 modules: mark __inittest/__exittest as __maybe_unused
:::::: TO: Arnd Bergmann <arnd@arndb.de>
:::::: CC: Jessica Yu <jeyu@redhat.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 65284 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] bonding: allow carrier and link status to determine link state
From: David Miller @ 2018-05-16 16:28 UTC (permalink / raw)
To: jay.vosburgh; +Cc: dbanerje, netdev, vfalico, andy
In-Reply-To: <26172.1526487068@nyx>
From: Jay Vosburgh <jay.vosburgh@canonical.com>
Date: Wed, 16 May 2018 18:11:08 +0200
> Debabrata Banerjee <dbanerje@akamai.com> wrote:
>
>>In a mixed environment it may be difficult to tell if your hardware
>>support carrier, if it does not it can always report true. With a new
>>use_carrier option of 2, we can check both carrier and link status
>>sequentially, instead of one or the other
>
> Your reply in the prior discussion suggests to me that there is
> a bug somewhere else (perhaps in bonding, perhaps in the network
> driver), and this is just papering over it. As I said, I don't believe
> that an additional hack to bonding is the appropriate way to resolve
> this.
Sorry this crossed with my review and application of this series, my bad.
Debabrata please give a specific example of a case where the new "both"
mode actually is needed.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] sched: manipulate __QDISC_STATE_RUNNING in qdisc_run_* helpers
From: David Miller @ 2018-05-16 16:26 UTC (permalink / raw)
To: pabeni; +Cc: netdev, jhs, xiyou.wangcong, jiri, john.fastabend
In-Reply-To: <b589d9ffd51932b66469a36252d1dee0f9e825c7.1526374069.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Tue, 15 May 2018 10:50:31 +0200
> Currently NOLOCK qdiscs pay a measurable overhead to atomically
> manipulate the __QDISC_STATE_RUNNING. Such bit is flipped twice per
> packet in the uncontended scenario with packet rate below the
> line rate: on packed dequeue and on the next, failing dequeue attempt.
>
> This changeset moves the bit manipulation into the qdisc_run_{begin,end}
> helpers, so that the bit is now flipped only once per packet, with
> measurable performance improvement in the uncontended scenario.
>
> This also allows simplifying the qdisc teardown code path - since
> qdisc_is_running() is now effective for each qdisc type - and avoid a
> possible race between qdisc_run() and dev_deactivate_many(), as now
> the some_qdisc_is_busy() can properly detect NOLOCK qdiscs being busy
> dequeuing packets.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied, thank you.
^ permalink raw reply
* Re: [RESEND PATCH v2 1/1] net: phy: micrel: add 125MHz reference clock workaround
From: David Miller @ 2018-05-16 16:21 UTC (permalink / raw)
To: m.felsch
Cc: robh+dt, mark.rutland, andrew, f.fainelli, netdev, devicetree,
kernel, niebelm
In-Reply-To: <20180515081856.23322-2-m.felsch@pengutronix.de>
From: Marco Felsch <m.felsch@pengutronix.de>
Date: Tue, 15 May 2018 10:18:56 +0200
> From: Markus Niebel <Markus.Niebel@tqs.de>
>
> The micrel KSZ9031 phy has a optional clock pin (CLK125_NDO) which can be
> used as reference clock for the MAC unit. The clock signal must meet the
> RGMII requirements to ensure the correct data transmission between the
> MAC and the PHY. The KSZ9031 phy does not fulfill the duty cycle
> requirement if the phy is configured as slave. For a complete
> describtion look at the errata sheets: DS80000691D or DS80000692D.
>
> The errata sheet recommends to force the phy into master mode whenever
> there is a 1000Base-T link-up as work around. Only set the
> "micrel,force-master" property if you use the phy reference clock provided
> by CLK125_NDO pin as MAC reference clock in your application.
>
> Attenation, this workaround is only usable if the link partner can
> be configured to slave mode for 1000Base-T.
>
> Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
> [m.felsch@pengutronix.de: fix dt-binding documentation]
> [m.felsch@pengutronix.de: use already existing result var for read/write]
> [m.felsch@pengutronix.de: add error handling]
> [m.felsch@pengutronix.de: add more comments]
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] tcp: purge write queue in tcp_connect_init()
From: David Miller @ 2018-05-16 16:19 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, ycheng, ncardwell
In-Reply-To: <20180515041426.94062-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 14 May 2018 21:14:26 -0700
> syzkaller found a reliable way to crash the host, hitting a BUG()
> in __tcp_retransmit_skb()
>
> Malicous MSG_FASTOPEN is the root cause. We need to purge write queue
> in tcp_connect_init() at the point we init snd_una/write_seq.
>
> This patch also replaces the BUG() by a less intrusive WARN_ON_ONCE()
...
> Fixes: cf60af03ca4e ("net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN)")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [net 1/1] net/mlx5: Fix build break when CONFIG_SMP=n
From: David Miller @ 2018-05-16 16:17 UTC (permalink / raw)
To: saeedm; +Cc: netdev, rdunlap, linux, tglx
In-Reply-To: <20180514223810.21197-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 14 May 2018 15:38:10 -0700
> Avoid using the kernel's irq_descriptor and return IRQ vector affinity
> directly from the driver.
>
> This fixes the following build break when CONFIG_SMP=n
>
> include/linux/mlx5/driver.h: In function ‘mlx5_get_vector_affinity_hint’:
> include/linux/mlx5/driver.h:1299:13: error:
> ‘struct irq_desc’ has no member named ‘affinity_hint’
>
> Fixes: 6082d9c9c94a ("net/mlx5: Fix mlx5_get_vector_affinity function")
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> CC: Randy Dunlap <rdunlap@infradead.org>
> CC: Guenter Roeck <linux@roeck-us.net>
> CC: Thomas Gleixner <tglx@linutronix.de>
> Tested-by: Israel Rukshin <israelr@mellanox.com>
> ---
>
> For -stable v4.14
Applied and queued up for -stable, thanks.
^ permalink raw reply
* RE: ECMP routing: problematic selection of outgoing interface
From: Hirotaka Yamamoto @ 2018-05-16 16:16 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180516130128.GE22000@lunn.ch>
Hi Andrew,
> I assume you add the 192.168.11.1 and 192.168.12.1 to the interfaces
> using global scope? Global scope means the IP addresses are valid
> everywhere. All routers should know how to route packets to these IP
> addresses. So a host is free to pick any of its global scope IP
Yes their scopes are global,
> It sounds like your router is doing reverse path filtering. It is
> checking its routing table for the source address, and throwing the
> packets away if they don't come in the interface the route points out
> of.
and yes the routers do reverse path filtering.
Now I understood that this is an intended and in fact a legitimate behavior.
So it seems that one thing I can do is to talk with networking people to accept
these packets. Another option that has come to my mind is to change the
address scope to link-local and assign a global, routable address to a dummy
interface so that Linux chooses the address for the dummyif.
I'm going to evaluate these options. Thank you!
- ymmt
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] bonding: performance and reliability
From: David Miller @ 2018-05-16 16:16 UTC (permalink / raw)
To: dbanerje; +Cc: netdev, j.vosburgh, vfalico, andy
In-Reply-To: <20180514184810.15506-1-dbanerje@akamai.com>
From: Debabrata Banerjee <dbanerje@akamai.com>
Date: Mon, 14 May 2018 14:48:06 -0400
> Series of fixes to how rlb updates are handled, code cleanup, allowing
> higher performance tx hashing in balance-alb mode, and reliability of
> link up/down monitoring.
>
> v2: refactor bond_is_nondyn_tlb with inline fn, update log comment to
> point out that multicast addresses will not get rlb updates.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] bonding: allow carrier and link status to determine link state
From: Jay Vosburgh @ 2018-05-16 16:11 UTC (permalink / raw)
To: Debabrata Banerjee
Cc: David S . Miller, netdev, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <20180514184810.15506-5-dbanerje@akamai.com>
Debabrata Banerjee <dbanerje@akamai.com> wrote:
>In a mixed environment it may be difficult to tell if your hardware
>support carrier, if it does not it can always report true. With a new
>use_carrier option of 2, we can check both carrier and link status
>sequentially, instead of one or the other
Your reply in the prior discussion suggests to me that there is
a bug somewhere else (perhaps in bonding, perhaps in the network
driver), and this is just papering over it. As I said, I don't believe
that an additional hack to bonding is the appropriate way to resolve
this.
-J
>Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
>---
> Documentation/networking/bonding.txt | 4 ++--
> drivers/net/bonding/bond_main.c | 12 ++++++++----
> drivers/net/bonding/bond_options.c | 7 ++++---
> 3 files changed, 14 insertions(+), 9 deletions(-)
>
>diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
>index 9ba04c0bab8d..f063730e7e73 100644
>--- a/Documentation/networking/bonding.txt
>+++ b/Documentation/networking/bonding.txt
>@@ -828,8 +828,8 @@ use_carrier
> MII / ETHTOOL ioctl method to determine the link state.
>
> A value of 1 enables the use of netif_carrier_ok(), a value of
>- 0 will use the deprecated MII / ETHTOOL ioctls. The default
>- value is 1.
>+ 0 will use the deprecated MII / ETHTOOL ioctls. A value of 2
>+ will check both. The default value is 1.
>
> xmit_hash_policy
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index f7f8a49cb32b..7e9652c4b35c 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -132,7 +132,7 @@ MODULE_PARM_DESC(downdelay, "Delay before considering link down, "
> "in milliseconds");
> module_param(use_carrier, int, 0);
> MODULE_PARM_DESC(use_carrier, "Use netif_carrier_ok (vs MII ioctls) in miimon; "
>- "0 for off, 1 for on (default)");
>+ "0 for off, 1 for on (default), 2 for carrier then legacy checks");
> module_param(mode, charp, 0);
> MODULE_PARM_DESC(mode, "Mode of operation; 0 for balance-rr, "
> "1 for active-backup, 2 for balance-xor, "
>@@ -434,12 +434,16 @@ static int bond_check_dev_link(struct bonding *bond,
> int (*ioctl)(struct net_device *, struct ifreq *, int);
> struct ifreq ifr;
> struct mii_ioctl_data *mii;
>+ bool carrier = true;
>
> if (!reporting && !netif_running(slave_dev))
> return 0;
>
> if (bond->params.use_carrier)
>- return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
>+ carrier = netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
>+
>+ if (!carrier)
>+ return carrier;
>
> /* Try to get link status using Ethtool first. */
> if (slave_dev->ethtool_ops->get_link)
>@@ -4399,8 +4403,8 @@ static int bond_check_params(struct bond_params *params)
> downdelay = 0;
> }
>
>- if ((use_carrier != 0) && (use_carrier != 1)) {
>- pr_warn("Warning: use_carrier module parameter (%d), not of valid value (0/1), so it was set to 1\n",
>+ if (use_carrier < 0 || use_carrier > 2) {
>+ pr_warn("Warning: use_carrier module parameter (%d), not of valid value (0-2), so it was set to 1\n",
> use_carrier);
> use_carrier = 1;
> }
>diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
>index 8a945c9341d6..dba6cef05134 100644
>--- a/drivers/net/bonding/bond_options.c
>+++ b/drivers/net/bonding/bond_options.c
>@@ -164,9 +164,10 @@ static const struct bond_opt_value bond_primary_reselect_tbl[] = {
> };
>
> static const struct bond_opt_value bond_use_carrier_tbl[] = {
>- { "off", 0, 0},
>- { "on", 1, BOND_VALFLAG_DEFAULT},
>- { NULL, -1, 0}
>+ { "off", 0, 0},
>+ { "on", 1, BOND_VALFLAG_DEFAULT},
>+ { "both", 2, 0},
>+ { NULL, -1, 0}
> };
>
> static const struct bond_opt_value bond_all_slaves_active_tbl[] = {
>--
>2.17.0
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* [PATCH v3 iproute2-next 3/3] rdma: update man pages
From: Steve Wise @ 2018-05-15 20:41 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <cover.1526483157.git.swise@opengridcomputing.com>
Update the man pages for the resource attributes as well
as the driver-specific attributes.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
man/man8/rdma-resource.8 | 29 ++++++++++++++++++++++++++---
man/man8/rdma.8 | 2 +-
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/man/man8/rdma-resource.8 b/man/man8/rdma-resource.8
index ff5d25d..40b073d 100644
--- a/man/man8/rdma-resource.8
+++ b/man/man8/rdma-resource.8
@@ -7,13 +7,16 @@ rdma-resource \- rdma resource configuration
.in +8
.ti -8
.B rdma
-.RI "[ " OPTIONS " ]"
-.B resource
-.RI " { " COMMAND " | "
+.RI "[ " OPTIONS " ] " RESOURCE " { " COMMAND " | "
.BR help " }"
.sp
.ti -8
+.IR RESOURCE " := { "
+.BR cm_id " | " cq " | " mr " | " pd " | " qp " }"
+.sp
+
+.ti -8
.IR OPTIONS " := { "
\fB\-j\fR[\fIson\fR] |
\fB\-d\fR[\fIetails\fR] }
@@ -70,11 +73,31 @@ rdma res show qp link mlx5_4/- -d
Detailed view.
.RE
.PP
+rdma res show qp link mlx5_4/- -dd
+.RS 4
+Detailed view including driver-specific details.
+.RE
+.PP
rdma res show qp link mlx5_4/1 lqpn 0-6
.RS 4
Limit to specific Local QPNs.
.RE
.PP
+rdma resource show cm_id dst-port 7174
+.RS 4
+Show CM_IDs with destination ip port of 7174.
+.RE
+.PP
+rdma resource show cm_id src-addr 172.16.0.100
+.RS 4
+Show CM_IDs bound to local ip address 172.16.0.100
+.RE
+.PP
+rdma resource show cq pid 30489
+.RS 4
+Show CQs belonging to pid 30489
+.RE
+.PP
.SH SEE ALSO
.BR rdma (8),
diff --git a/man/man8/rdma.8 b/man/man8/rdma.8
index 6f88f37..12aa149 100644
--- a/man/man8/rdma.8
+++ b/man/man8/rdma.8
@@ -49,7 +49,7 @@ If there were any errors during execution of the commands, the application retur
.TP
.BR "\-d" , " --details"
-Output detailed information.
+Output detailed information. Adding a second \-d includes driver-specific details.
.TP
.BR "\-p" , " --pretty"
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 iproute2-next 2/3] rdma: print driver resource attributes
From: Steve Wise @ 2018-05-15 20:41 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <cover.1526483157.git.swise@opengridcomputing.com>
This enhancement allows printing rdma device-specific state, if provided
by the kernel. This is done in a generic manner, so rdma tool doesn't
need to know about the details of every type of rdma device.
Driver attributes for a rdma resource are in the form of <key,
[print_type], value> tuples, where the key is a string and the value can
be any supported driver attribute. The print_type attribute, if present,
provides a print format to use vs the standard print format for the type.
For example, the default print type for a PROVIDER_S32 value is "%d ",
but "0x%x " if the print_type of PRINT_TYPE_HEX is included inthe tuple.
Driver resources are only printed when the -dd flag is present.
If -p is present, then the output is formatted to not exceed 80 columns,
otherwise it is printed as a single row to be grep/awk friendly.
Example output:
# rdma resource show qp lqpn 1028 -dd -p
link cxgb4_0/- lqpn 1028 rqpn 0 type RC state RTS rq-psn 0 sq-psn 0 path-mig-state MIGRATED pid 0 comm [nvme_rdma]
sqid 1028 flushed 0 memsize 123968 cidx 85 pidx 85 wq_pidx 106 flush_cidx 85 in_use 0
size 386 flags 0x0 rqid 1029 memsize 16768 cidx 43 pidx 41 wq_pidx 171 msn 44 rqt_hwaddr 0x2a8a5d00
rqt_size 256 in_use 128 size 130
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
rdma/rdma.c | 9 ++-
rdma/rdma.h | 11 ++++
rdma/res.c | 30 +++------
rdma/utils.c | 196 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 224 insertions(+), 22 deletions(-)
diff --git a/rdma/rdma.c b/rdma/rdma.c
index b43e538..010e983 100644
--- a/rdma/rdma.c
+++ b/rdma/rdma.c
@@ -129,13 +129,14 @@ int main(int argc, char **argv)
{ "batch", required_argument, NULL, 'b' },
{ NULL, 0, NULL, 0 }
};
+ bool show_driver_details = false;
const char *batch_file = NULL;
bool pretty_output = false;
bool show_details = false;
bool json_output = false;
bool force = false;
- char *filename;
struct rd rd = {};
+ char *filename;
int opt;
int err;
@@ -152,7 +153,10 @@ int main(int argc, char **argv)
pretty_output = true;
break;
case 'd':
- show_details = true;
+ if (show_details)
+ show_driver_details = true;
+ else
+ show_details = true;
break;
case 'j':
json_output = true;
@@ -180,6 +184,7 @@ int main(int argc, char **argv)
argv += optind;
rd.show_details = show_details;
+ rd.show_driver_details = show_driver_details;
rd.json_output = json_output;
rd.pretty_output = pretty_output;
diff --git a/rdma/rdma.h b/rdma/rdma.h
index 1908fc4..fcaf9e6 100644
--- a/rdma/rdma.h
+++ b/rdma/rdma.h
@@ -55,6 +55,7 @@ struct rd {
char **argv;
char *filename;
bool show_details;
+ bool show_driver_details;
struct list_head dev_map_list;
uint32_t dev_idx;
uint32_t port_idx;
@@ -115,4 +116,14 @@ int rd_recv_msg(struct rd *rd, mnl_cb_t callback, void *data, uint32_t seq);
void rd_prepare_msg(struct rd *rd, uint32_t cmd, uint32_t *seq, uint16_t flags);
int rd_dev_init_cb(const struct nlmsghdr *nlh, void *data);
int rd_attr_cb(const struct nlattr *attr, void *data);
+int rd_attr_check(const struct nlattr *attr, int *typep);
+
+/*
+ * Print helpers
+ */
+void print_driver_table(struct rd *rd, struct nlattr *tb);
+void newline(struct rd *rd);
+void newline_indent(struct rd *rd);
+#define MAX_LINE_LENGTH 80
+
#endif /* _RDMA_TOOL_H_ */
diff --git a/rdma/res.c b/rdma/res.c
index 1a0aab6..074b992 100644
--- a/rdma/res.c
+++ b/rdma/res.c
@@ -439,10 +439,8 @@ static int res_qp_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -678,10 +676,8 @@ static int res_cm_id_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -804,10 +800,8 @@ static int res_cq_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -919,10 +913,8 @@ static int res_mr_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -1004,10 +996,8 @@ static int res_pd_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
diff --git a/rdma/utils.c b/rdma/utils.c
index 49c967f..79c3d9f 100644
--- a/rdma/utils.c
+++ b/rdma/utils.c
@@ -11,6 +11,7 @@
#include "rdma.h"
#include <ctype.h>
+#include <inttypes.h>
int rd_argc(struct rd *rd)
{
@@ -393,8 +394,32 @@ static const enum mnl_attr_data_type nldev_policy[RDMA_NLDEV_ATTR_MAX] = {
[RDMA_NLDEV_ATTR_RES_MRLEN] = MNL_TYPE_U64,
[RDMA_NLDEV_ATTR_NDEV_INDEX] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_NDEV_NAME] = MNL_TYPE_NUL_STRING,
+ [RDMA_NLDEV_ATTR_DRIVER] = MNL_TYPE_NESTED,
+ [RDMA_NLDEV_ATTR_DRIVER_ENTRY] = MNL_TYPE_NESTED,
+ [RDMA_NLDEV_ATTR_DRIVER_STRING] = MNL_TYPE_NUL_STRING,
+ [RDMA_NLDEV_ATTR_DRIVER_PRINT_TYPE] = MNL_TYPE_U8,
+ [RDMA_NLDEV_ATTR_DRIVER_S32] = MNL_TYPE_U32,
+ [RDMA_NLDEV_ATTR_DRIVER_U32] = MNL_TYPE_U32,
+ [RDMA_NLDEV_ATTR_DRIVER_S64] = MNL_TYPE_U64,
+ [RDMA_NLDEV_ATTR_DRIVER_U64] = MNL_TYPE_U64,
};
+int rd_attr_check(const struct nlattr *attr, int *typep)
+{
+ int type;
+
+ if (mnl_attr_type_valid(attr, RDMA_NLDEV_ATTR_MAX) < 0)
+ return MNL_CB_ERROR;
+
+ type = mnl_attr_get_type(attr);
+
+ if (mnl_attr_validate(attr, nldev_policy[type]) < 0)
+ return MNL_CB_ERROR;
+
+ *typep = nldev_policy[type];
+ return MNL_CB_OK;
+}
+
int rd_attr_cb(const struct nlattr *attr, void *data)
{
const struct nlattr **tb = data;
@@ -660,3 +685,174 @@ struct dev_map *dev_map_lookup(struct rd *rd, bool allow_port_index)
free(dev_name);
return dev_map;
}
+
+#define nla_type(attr) ((attr)->nla_type & NLA_TYPE_MASK)
+
+void newline(struct rd *rd)
+{
+ if (rd->json_output)
+ jsonw_end_array(rd->jw);
+ else
+ pr_out("\n");
+}
+
+void newline_indent(struct rd *rd)
+{
+ newline(rd);
+ if (!rd->json_output)
+ pr_out(" ");
+}
+
+static int print_driver_string(struct rd *rd, const char *key_str,
+ const char *val_str)
+{
+ if (rd->json_output) {
+ jsonw_string_field(rd->jw, key_str, val_str);
+ return 0;
+ } else {
+ return pr_out("%s %s ", key_str, val_str);
+ }
+}
+
+static int print_driver_s32(struct rd *rd, const char *key_str, int32_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %d ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%x ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_u32(struct rd *rd, const char *key_str, uint32_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %u ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%x ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_s64(struct rd *rd, const char *key_str, int64_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %" PRId64 " ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%" PRIx64 " ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_u64(struct rd *rd, const char *key_str, uint64_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %" PRIu64 " ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%" PRIx64 " ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_entry(struct rd *rd, struct nlattr *key_attr,
+ struct nlattr *val_attr,
+ enum rdma_nldev_print_type print_type)
+{
+ const char *key_str = mnl_attr_get_str(key_attr);
+ int attr_type = nla_type(val_attr);
+
+ switch (attr_type) {
+ case RDMA_NLDEV_ATTR_DRIVER_STRING:
+ return print_driver_string(rd, key_str,
+ mnl_attr_get_str(val_attr));
+ case RDMA_NLDEV_ATTR_DRIVER_S32:
+ return print_driver_s32(rd, key_str,
+ mnl_attr_get_u32(val_attr), print_type);
+ case RDMA_NLDEV_ATTR_DRIVER_U32:
+ return print_driver_u32(rd, key_str,
+ mnl_attr_get_u32(val_attr), print_type);
+ case RDMA_NLDEV_ATTR_DRIVER_S64:
+ return print_driver_s64(rd, key_str,
+ mnl_attr_get_u64(val_attr), print_type);
+ case RDMA_NLDEV_ATTR_DRIVER_U64:
+ return print_driver_u64(rd, key_str,
+ mnl_attr_get_u64(val_attr), print_type);
+ }
+ return -EINVAL;
+}
+
+void print_driver_table(struct rd *rd, struct nlattr *tb)
+{
+ int print_type = RDMA_NLDEV_PRINT_TYPE_UNSPEC;
+ struct nlattr *tb_entry, *key = NULL, *val;
+ int type, cc = 0;
+ int ret;
+
+ if (!rd->show_driver_details || !tb)
+ return;
+
+ if (rd->pretty_output)
+ newline_indent(rd);
+
+ /*
+ * Driver attrs are tuples of {key, [print-type], value}.
+ * The key must be a string. If print-type is present, it
+ * defines an alternate printf format type vs the native format
+ * for the attribute. And the value can be any available
+ * driver type.
+ */
+ mnl_attr_for_each_nested(tb_entry, tb) {
+
+ if (cc > MAX_LINE_LENGTH) {
+ if (rd->pretty_output)
+ newline_indent(rd);
+ cc = 0;
+ }
+ if (rd_attr_check(tb_entry, &type) != MNL_CB_OK)
+ return;
+ if (!key) {
+ if (type != MNL_TYPE_NUL_STRING)
+ return;
+ key = tb_entry;
+ } else if (type == MNL_TYPE_U8) {
+ print_type = mnl_attr_get_u8(tb_entry);
+ } else {
+ val = tb_entry;
+ ret = print_driver_entry(rd, key, val, print_type);
+ if (ret < 0)
+ return;
+ cc += ret;
+ print_type = RDMA_NLDEV_PRINT_TYPE_UNSPEC;
+ key = NULL;
+ }
+ }
+ return;
+}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 iproute2-next 1/3] rdma: update rdma_netlink.h to get new driver attributes
From: Steve Wise @ 2018-05-15 20:41 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <cover.1526483157.git.swise@opengridcomputing.com>
Pull in the rdma_netlink.h changes from kernel
commits:
25a0ad85156a ("RDMA/nldev: Add explicit pad attribute")
da5c85078215 ("RDMA/nldev: add driver-specific resource tracking)"
0d52d803767e ("RDMA/uapi: Fix uapi breakage")
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
rdma/include/uapi/rdma/rdma_netlink.h | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/rdma/include/uapi/rdma/rdma_netlink.h b/rdma/include/uapi/rdma/rdma_netlink.h
index 60416ed..6513fb8 100644
--- a/rdma/include/uapi/rdma/rdma_netlink.h
+++ b/rdma/include/uapi/rdma/rdma_netlink.h
@@ -249,10 +249,22 @@ enum rdma_nldev_command {
RDMA_NLDEV_NUM_OPS
};
+enum {
+ RDMA_NLDEV_ATTR_ENTRY_STRLEN = 16,
+};
+
+enum rdma_nldev_print_type {
+ RDMA_NLDEV_PRINT_TYPE_UNSPEC,
+ RDMA_NLDEV_PRINT_TYPE_HEX,
+};
+
enum rdma_nldev_attr {
/* don't change the order or add anything between, this is ABI! */
RDMA_NLDEV_ATTR_UNSPEC,
+ /* Pad attribute for 64b alignment */
+ RDMA_NLDEV_ATTR_PAD = RDMA_NLDEV_ATTR_UNSPEC,
+
/* Identifier for ib_device */
RDMA_NLDEV_ATTR_DEV_INDEX, /* u32 */
@@ -387,7 +399,6 @@ enum rdma_nldev_attr {
RDMA_NLDEV_ATTR_RES_PD_ENTRY, /* nested table */
RDMA_NLDEV_ATTR_RES_LOCAL_DMA_LKEY, /* u32 */
RDMA_NLDEV_ATTR_RES_UNSAFE_GLOBAL_RKEY, /* u32 */
-
/*
* Provides logical name and index of netdevice which is
* connected to physical port. This information is relevant
@@ -400,7 +411,24 @@ enum rdma_nldev_attr {
*/
RDMA_NLDEV_ATTR_NDEV_INDEX, /* u32 */
RDMA_NLDEV_ATTR_NDEV_NAME, /* string */
+ /*
+ * driver-specific attributes.
+ */
+ RDMA_NLDEV_ATTR_DRIVER, /* nested table */
+ RDMA_NLDEV_ATTR_DRIVER_ENTRY, /* nested table */
+ RDMA_NLDEV_ATTR_DRIVER_STRING, /* string */
+ /*
+ * u8 values from enum rdma_nldev_print_type
+ */
+ RDMA_NLDEV_ATTR_DRIVER_PRINT_TYPE, /* u8 */
+ RDMA_NLDEV_ATTR_DRIVER_S32, /* s32 */
+ RDMA_NLDEV_ATTR_DRIVER_U32, /* u32 */
+ RDMA_NLDEV_ATTR_DRIVER_S64, /* s64 */
+ RDMA_NLDEV_ATTR_DRIVER_U64, /* u64 */
+ /*
+ * Always the end
+ */
RDMA_NLDEV_ATTR_MAX
};
#endif /* _RDMA_NETLINK_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 iproute2-next 0/3] RDMA tool driver-specific resource tracking
From: Steve Wise @ 2018-05-16 15:05 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
This series enhances the iproute2 rdma tool to include displaying
driver-specific resource attributes. It is the user-space part of the
kernel driver resource tracking series that has been accepted for merging
into linux-4.18 [1]
If there are no additional review comments, it can now be merged, I think.
Changes since v2:
- resync rdma_netlink.h to fix uapi break
Changes since v1:
- commit log editorial fixes
- cite kernel commits that updated rdma_netlink.h in the
iproute2 commit syncing this header
- reorder stack definitions ala "reverse christmas tree"
- correctly handle unknown driver attributes when printing
Changes since v0/rfc:
- changed "provider" to "driver" based on kernel side changes
- updated man pages
- removed "RFC" tag
Thanks,
Steve.
[1] https://www.spinics.net/lists/linux-rdma/msg64199.html
Steve Wise (3):
rdma: update rdma_netlink.h to get new driver attributes
rdma: print driver resource attributes
rdma: update man pages
man/man8/rdma-resource.8 | 29 ++++-
man/man8/rdma.8 | 2 +-
rdma/include/uapi/rdma/rdma_netlink.h | 30 +++++-
rdma/rdma.c | 9 +-
rdma/rdma.h | 11 ++
rdma/res.c | 30 ++----
rdma/utils.c | 196 ++++++++++++++++++++++++++++++++++
7 files changed, 280 insertions(+), 27 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v3] ipvlan: call netdevice notifier when master mac address changed
From: David Miller @ 2018-05-16 16:00 UTC (permalink / raw)
To: liuqifa
Cc: dsahern, maheshb, weiyongjun1, maowenan, dingtianhong, netdev,
linux-kernel
In-Reply-To: <20180514113809.10196-1-liuqifa@huawei.com>
From: <liuqifa@huawei.com>
Date: Mon, 14 May 2018 19:38:09 +0800
> From: Keefe Liu <liuqifa@huawei.com>
>
> When master device's mac has been changed, the commit
> 32c10bbfe914 ("ipvlan: always use the current L2 addr of the
> master") makes the IPVlan devices's mac changed also, but it
> doesn't do related works such as flush the IPVlan devices's
> arp table.
>
> Signed-off-by: Keefe Liu <liuqifa@huawei.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [GIT PULL 00/11] perf/core improvements and fixes
From: Ingo Molnar @ 2018-05-16 15:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Clark Williams, linux-kernel, linux-perf-users, Adrian Hunter,
Agustin Vega-Frias, Alexander Shishkin, Andi Kleen,
Andy Lutomirski, Daniel Borkmann, Dave Hansen, David Ahern,
Ganapatrao Kulkarni, H . Peter Anvin, Jin Yao, Jiri Olsa,
Joerg Roedel, Kan Liang, Masami Hiramatsu, Namhyung Kim, netdev,
Peter
In-Reply-To: <20180516144908.22212-1-acme@kernel.org>
* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Hi Ingo,
>
> Please consider pulling, more to come as I go thru Adrian's x86
> PTI series and the C++ support improvements to 'perf probe', from
> Holger,
>
> Best Regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 291c161f6c65530092903fbea58eb07a62b220ba:
>
> Merge remote-tracking branch 'tip/perf/urgent' into perf/core (2018-05-15 10:30:17 -0300)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.18-20180516
>
> for you to fetch changes up to 7a36a287de9fbb1ba906e70573d3f2315f7fd609:
>
> perf bpf: Fix NULL return handling in bpf__prepare_load() (2018-05-16 10:01:55 -0300)
>
> ----------------------------------------------------------------
> perf/core improvements and fixes:
>
> - Add '-e intel_pt//u' test to the 'parse-events' 'perf test' entry,
> to help avoiding regressions in the events parser such as one
> that caused a revert in v4.17-rc (Arnaldo Carvalho de Melo)
>
> - Fix NULL return handling in bpf__prepare_load() (YueHaibing)
>
> - Warn about 'perf buildid-cache --purge-all' failures (Ravi Bangoria)
>
> - Add infrastructure to help in writing eBPF C programs to be used
> with '-e name.c' type events in tools such as 'record' and 'trace',
> with headers for common constructs and an examples directory that
> will get populated as we add more such helpers and the 'perf bpf'
> branch that Jiri Olsa has been working on (Arnaldo Carvalho de Melo)
>
> - Handle uncore event aliases in small groups properly (Kan Liang)
>
> - Use the "_stest" symbol to identify the kernel map when loading kcore (Adrian Hunter)
>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> ----------------------------------------------------------------
> Adrian Hunter (1):
> perf tools: Use the "_stest" symbol to identify the kernel map when loading kcore
>
> Arnaldo Carvalho de Melo (7):
> perf tests parse-events: Add intel_pt parse test
> perf llvm-utils: Add bpf include path to clang command line
> perf bpf: Add 'examples' directories
> perf bpf: Add bpf.h to be used in eBPF proggies
> perf bpf: Add kprobe example to catch 5s naps
> perf bpf: Add license(NAME) helper
> perf bpf: Add probe() helper to reduce kprobes boilerplate
>
> Kan Liang (1):
> perf parse-events: Handle uncore event aliases in small groups properly
>
> Ravi Bangoria (1):
> perf buildid-cache: Warn --purge-all failures
>
> YueHaibing (1):
> perf bpf: Fix NULL return handling in bpf__prepare_load()
>
> tools/perf/Makefile.config | 14 ++++
> tools/perf/Makefile.perf | 8 +++
> tools/perf/builtin-buildid-cache.c | 8 ++-
> tools/perf/examples/bpf/5sec.c | 49 ++++++++++++++
> tools/perf/examples/bpf/empty.c | 3 +
> tools/perf/include/bpf/bpf.h | 13 ++++
> tools/perf/tests/parse-events.c | 13 ++++
> tools/perf/util/Build | 2 +
> tools/perf/util/bpf-loader.c | 6 +-
> tools/perf/util/evsel.h | 1 +
> tools/perf/util/llvm-utils.c | 19 ++++--
> tools/perf/util/parse-events.c | 130 ++++++++++++++++++++++++++++++++++++-
> tools/perf/util/parse-events.h | 7 +-
> tools/perf/util/parse-events.y | 8 +--
> tools/perf/util/symbol.c | 16 ++---
> 15 files changed, 270 insertions(+), 27 deletions(-)
> create mode 100644 tools/perf/examples/bpf/5sec.c
> create mode 100644 tools/perf/examples/bpf/empty.c
> create mode 100644 tools/perf/include/bpf/bpf.h
Pulled, thanks a lot Arnaldo!
Ingo
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-16 15:53 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Roman Mashak, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
Eric Dumazet, kliteyn
In-Reply-To: <0426e39c-e9fd-50b1-3611-a804a965df50@mojatatu.com>
On Wed 16 May 2018 at 15:02, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 16/05/18 10:38 AM, Roman Mashak wrote:
>
>>>>
>>>> You may actually have broken something with your patches in this case.
>>>
>>> Results is for net-next without my patches.
>>
>> Do you have skbmod compiled in kernel or as a module?
>>
>
> Also - suggestion is to use latest iproute2 which interprets
> extended error information (instead of the classical
> "We have an error talking to the kernel").
>
> cheers,
> jamal
I have very recent iproute2 installed. Last commit date is May 9th.
^ permalink raw reply
* Re: [PATCH net-next 00/10] net/smc: enhancements 2018/05/15
From: David Miller @ 2018-05-16 15:51 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180515150503.47265-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Tue, 15 May 2018 17:04:53 +0200
> here are smc patches for net-next. The first one is a fix for net-next
> commit 01d2f7e2cdd3 "net/smc: sockopts TCP_NODELAY and TCP_CORK".
> Patch 7 improves Connection Layer Control error handling, patch 10
> improves abnormal termination of link groups. The remaining patches
> from Karsten improve Link Layer Control code.
Series applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH bpf-next 12/12] i40e: implement Tx zero-copy
From: Magnus Karlsson @ 2018-05-16 15:38 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Björn Töpel, Karlsson, Magnus, Alexander Duyck,
Alexander Duyck, John Fastabend, Alexei Starovoitov,
Willem de Bruijn, Daniel Borkmann, Michael S. Tsirkin,
Network Development, michael.lundkvist, Brandeburg, Jesse,
Singhai, Anjali, Zhang, Qi Z, intel-wired-lan
In-Reply-To: <CAJ8uoz39PnGmQ63VWezG1EBEM+ODrWSjZqKNGeO5oexvGs3pXA@mail.gmail.com>
On Wed, May 16, 2018 at 4:38 PM, Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
> On Wed, May 16, 2018 at 4:28 PM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
>> On Tue, 15 May 2018 21:06:15 +0200
>> Björn Töpel <bjorn.topel@gmail.com> wrote:
>>
>>> From: Magnus Karlsson <magnus.karlsson@intel.com>
>>>
>>> Here, the zero-copy ndo is implemented. As a shortcut, the existing
>>> XDP Tx rings are used for zero-copy. This means that and XDP program
>>> cannot redirect to an AF_XDP enabled XDP Tx ring.
>>
>> I've changed i40e1 to only have one queue via:
>> $ ethtool -L i40e1 combined 1
>>
>> And then, I'm sending on queue 1, which is/should not be avail... and then crash/BUG:
>>
>> $ sudo taskset -c 2 ./xdpsock --tx --interface=i40e1 --queue=1
>>
>> [ 3799.936877] Number of in use tx queues changed invalidating tc mappings. Priority traffic
>> classification disabled!
>> [ 3799.972970] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
>> [ 3799.980790] PGD 80000007b0992067 P4D 80000007b0992067 PUD 7b62d4067 PMD 0
>> [ 3799.987654] Oops: 0002 [#1] PREEMPT SMP PTI
>> [ 3799.991831] Modules linked in: nf_nat_masquerade_ipv4 tun nfnetlink bridge stp llc nf_nat
>> nf_conntrack rpcrdma ib_ipoib rdma_ucm ib_ucm ib_umad rdma_cm ib_cm iw_cm sunrpc mlx5_ib ib
>> _uverbs ib_core coretemp kvm_intel kvm irqbypass intel_cstate intel_uncore intel_rapl_perf p
>> cspkr i2c_i801 shpchp wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_pad sch_fq_codel i40e ml
>> x5_core hid_generic ixgbe igb devlink mdio ptp sd_mod i2c_algo_bit i2c_core pps_core [last u
>> nloaded: x_tables]
>> [ 3800.033472] CPU: 2 PID: 2006 Comm: xdpsock Not tainted 4.17.0-rc3-af_xdp03_ZC_rfc+ #155
>> [ 3800.041465] Hardware name: Supermicro Super Server/X10SRi-F, BIOS 2.0a 08/01/2016
>> [ 3800.048943] RIP: 0010:i40e_xmit_frame_ring+0xd4/0x1490 [i40e]
>> [ 3800.054683] RSP: 0018:ffffc9000407bcd0 EFLAGS: 00010293
>> [ 3800.059900] RAX: 0000000000000000 RBX: ffff88084f0fd200 RCX: 0000000000000000
>> [ 3800.067022] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8807b6e710c0
>> [ 3800.074148] RBP: ffff8807c6397800 R08: 00000000000000c0 R09: 0000000000000001
>> [ 3800.081270] R10: 0000000000000800 R11: 0000000000000010 R12: 0000000000000001
>> [ 3800.088396] R13: 0000000000000000 R14: 0000000000000001 R15: 000000000000003c
>> [ 3800.095520] FS: 00007f1d1e00bb80(0000) GS:ffff88087fc80000(0000) knlGS:0000000000000000
>> [ 3800.103597] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 3800.109335] CR2: 0000000000000008 CR3: 000000087d542001 CR4: 00000000003606e0
>> [ 3800.116458] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 3800.123583] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> [ 3800.130706] Call Trace:
>> [ 3800.133157] ? validate_xmit_skb.isra.116+0x1c/0x270
>> [ 3800.138118] dev_direct_xmit+0xec/0x1d0
>> [ 3800.141949] xsk_sendmsg+0x1f4/0x380
>> [ 3800.145521] sock_sendmsg+0x30/0x40
>> [ 3800.149005] __sys_sendto+0x10e/0x140
>> [ 3800.152662] ? __do_page_fault+0x283/0x500
>> [ 3800.156751] __x64_sys_sendto+0x24/0x30
>> [ 3800.160585] do_syscall_64+0x42/0xf0
>> [ 3800.164156] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 3800.169204] RIP: 0033:0x7f1d1d9db430
>> [ 3800.172774] RSP: 002b:00007fffb7278610 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
>> [ 3800.180333] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1d1d9db430
>> [ 3800.187456] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
>> [ 3800.194582] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>> [ 3800.201705] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000
>> [ 3800.208830] R13: 0000000000000000 R14: 0000000000755510 R15: 00007f1d0d3fc000
>> [ 3800.215953] Code: d0 0f 86 db 05 00 00 01 c8 0f b7 ca 29 c8 83 e8 01 39 c6 0f 8f ea 06 00 00 48 8b 45 28 48 8d 14 92 41 b9 01 00 00 00 4c 8d 2c d0 <49> 89 5d 08 8b 83 80 00 00 00 66 45 89 4d 14 41 89 45 10 0f b7
>> [ 3800.234798] RIP: i40e_xmit_frame_ring+0xd4/0x1490 [i40e] RSP: ffffc9000407bcd0
>> [ 3800.242005] CR2: 0000000000000008
>> [ 3800.245320] ---[ end trace f169e36f468e0c59 ]---
>> [ 3801.726719] Kernel panic - not syncing: Fatal exception in interrupt
>> [ 3801.733097] Kernel Offset: disabled
>> [ 3801.785836] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
>> [ 3801.793403] ------------[ cut here ]------------
>>
>> (gdb) list *(i40e_xmit_frame_ring)+0xd4
>> 0x2ccd4 is in i40e_xmit_frame_ring (drivers/net/ethernet/intel/i40e/i40e_txrx.c:4048).
>> warning: Source file is more recent than executable.
>> 4043 return NETDEV_TX_BUSY;
>> 4044 }
>> 4045
>> 4046 /* record the location of the first descriptor for this packet */
>> 4047 first = &tx_ring->tx_bi[tx_ring->next_to_use];
>> 4048 first->skb = skb;
>> 4049 first->bytecount = skb->len;
>> 4050 first->gso_segs = 1;
>> 4051
>> 4052 /* prepare the xmit flags */
>>
>>
>> (gdb) list *(xsk_sendmsg)+0x1f4
>> 0xffffffff81800c34 is in xsk_sendmsg (net/xdp/xsk.c:251).
>> warning: Source file is more recent than executable.
>> 246 skb_shinfo(skb)->destructor_arg = (void *)(long)id;
>> 247 skb->destructor = xsk_destruct_skb;
>> 248
>> 249 err = dev_direct_xmit(skb, xs->queue_id);
>> 250 /* Ignore NET_XMIT_CN as packet might have been sent */
>> 251 if (err == NET_XMIT_DROP || err == NETDEV_TX_BUSY) {
>> 252 err = -EAGAIN;
>> 253 /* SKB consumed by dev_direct_xmit() */
>> 254 goto out;
>> 255 }
>
Found it. Checked num_rx_queues in the xsk_bind code instead of
real_num_rx_queues. The code below will solve the problem. Will post a
proper patch for it tomorrow. Thanks Jesper for reporting this.
Appreciated.
/Magnus
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index ac97902..4b62a1e 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -391,7 +391,8 @@ static int xsk_bind(struct socket *sock, struct
sockaddr *addr, int addr_len)
goto out_unlock;
}
- if (sxdp->sxdp_queue_id >= dev->num_rx_queues) {
+ if ((xs->rx && sxdp->sxdp_queue_id >= dev->real_num_rx_queues) ||
+ (xs->tx && sxdp->sxdp_queue_id >= dev->real_num_tx_queues)) {
err = -EINVAL;
goto out_unlock;
}
^ permalink raw reply related
* Re: [pull request][net-next 00/16] Mellanox, mlx5e updates 2018-05-14
From: David Miller @ 2018-05-16 15:37 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180514221934.20246-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 14 May 2018 15:19:18 -0700
> The following series contains misc updates for mlx5e netdevice driver.
> For more information please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Saeed.
^ permalink raw reply
* Re: i40e - Is i40e_force_link_state doing the right thing ?
From: Chaitanya Lala @ 2018-05-16 15:35 UTC (permalink / raw)
To: Stachura, Mariusz
Cc: netdev@vger.kernel.org, Williams, Mitch A, Bowers, AndrewX,
Kirsher, Jeffrey T
In-Reply-To: <1F86EBA5C8668B468CEE1C33B96E862B36905E19@IRSMSX104.ger.corp.intel.com>
Hi Mariusz, ...
On Wed, May 16, 2018 at 12:49 AM, Stachura, Mariusz
<mariusz.stachura@intel.com> wrote:
>> Hi Mariusz, ...
>>
>> On Tue, May 15, 2018 at 2:24 PM, Stachura, Mariusz <mariusz.stachura@intel.com> wrote:
>>> On Tue, May 15, 2018 at 1:15 PM, Chaitanya Lala <chaitanya.lala@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I am trying to bring up a Intel XL710 4x10G Intel card using the
>>>> latest mainline top-of-tree.
>>>> The problem is that "ifconfig up" and "ifconfig down" do not take
>>>> effect at the link state level.
>>>> I tracked the problem down to i40e_force_link_state() when it is
>>>> called from i40e_down().
>>>> It calls i40e_force_link_state with "is_up" == false. In-turn it
>>>> calls, i40e_aq_set_link_restart_an(hw, true, NULL).
>>>>
>>>> Should the second argument of i40e_aq_set_link_restart_an be "is_up"
>>>> vs the current "true"
>>>> i.e. i40e_aq_set_link_restart_an(hw, is_up, NULL). ? When I make this
>>>> change, the link state syncs-up with the interface administrative
>>>> state.
>>>>
>>>> Is this a bug ?
>>>>
>>>> Thanks,
>>>> Chaitanya
>>>
>>> Hello Chaitanya,
>>>
>>> i40e_down() calls i40e_force_link_state with "is_up" == false only if interface's private flag "link-down-on-close" is set. By default the link is left up for manageability and VF traffic, user can use this flag to power down the interface on the link level. Does that work for you?
>>> The command is:
>>> "ethtool --set-priv-flags IFNAME link-down-on-close on" and then
>>
>> This flag is _on_ in my setup and hencet i40e_force_link_state is being called with is_up == false in my setup. The problem is that irrespective of value of "is_up" flag, i40e_force_link_state invokes i40e_aq_set_link_restart_an with second argument (enable_link) as "true". So i40e_aq_set_link_restart_an is always trying to enable link even if is_up was false. Is that correct behavior ?
>>
>> I have pasted code with my annotations below marked with "//XXX".
>> (...)
>> Thanks,
>> Chaitanya
>
> Hey,
> i40e_aq_set_link_restart_an has second argument set to "true" intentionally, as I understand the "link-down-on-close" does not work for you, right? I will double check if this feature works for me and get back to you, thank you again.
That's correct. Even with the flag set, if-down does not result in a
link down for me. Thanks for checking!
-
Chaitanya
> --------------------------------------------------------------------
>
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
>
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
> others is strictly prohibited.
^ permalink raw reply
* kernel BUG at lib/string.c:LINE! (4)
From: syzbot @ 2018-05-16 15:35 UTC (permalink / raw)
To: coreteam, davem, fw, horms, ja, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
Hello,
syzbot found the following crash on:
HEAD commit: 0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16e91017800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=aac887f77319868646df
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1665d637800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10517107800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+aac887f77319868646df@syzkaller.appspotmail.com
IPVS: Unknown mcast interface: veth1_to�a����
IPVS: Unknown mcast interface: veth1_to�a����
IPVS: Unknown mcast interface: veth1_to�a����
detected buffer overflow in strlen
------------[ cut here ]------------
kernel BUG at lib/string.c:1052!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 373 Comm: syz-executor936 Not tainted 4.17.0-rc4+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:fortify_panic+0x13/0x20 lib/string.c:1051
RSP: 0018:ffff8801c976f800 EFLAGS: 00010282
RAX: 0000000000000022 RBX: 0000000000000040 RCX: 0000000000000000
RDX: 0000000000000022 RSI: ffffffff8160f6f1 RDI: ffffed00392edef6
RBP: ffff8801c976f800 R08: ffff8801cf4c62c0 R09: ffffed003b5e4fb0
R10: ffffed003b5e4fb0 R11: ffff8801daf27d87 R12: ffff8801c976fa20
R13: ffff8801c976fae4 R14: ffff8801c976fae0 R15: 000000000000048b
FS: 00007fd99f75e700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200001c0 CR3: 00000001d6843000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
strlen include/linux/string.h:270 [inline]
strlcpy include/linux/string.h:293 [inline]
do_ip_vs_set_ctl+0x31c/0x1d00 net/netfilter/ipvs/ip_vs_ctl.c:2388
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x7d/0xd0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0xd8/0xf0 net/ipv4/ip_sockglue.c:1253
udp_setsockopt+0x62/0xa0 net/ipv4/udp.c:2487
ipv6_setsockopt+0x149/0x170 net/ipv6/ipv6_sockglue.c:917
tcp_setsockopt+0x93/0xe0 net/ipv4/tcp.c:3057
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3046
__sys_setsockopt+0x1bd/0x390 net/socket.c:1903
__do_sys_setsockopt net/socket.c:1914 [inline]
__se_sys_setsockopt net/socket.c:1911 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447369
RSP: 002b:00007fd99f75dda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000006e39e4 RCX: 0000000000447369
RDX: 000000000000048b RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000018 R09: 0000000000000000
R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000006e39e0
R13: 75a1ff93f0896195 R14: 6f745f3168746576 R15: 0000000000000001
Code: 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 48 89 df e8 d2 8f 48 fa eb
de 55 48 89 fe 48 c7 c7 60 65 64 88 48 89 e5 e8 91 dd f3 f9 <0f> 0b 90 90
90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41 56
RIP: fortify_panic+0x13/0x20 lib/string.c:1051 RSP: ffff8801c976f800
---[ end trace 624046f2d9af7702 ]---
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* WARNING: kmalloc bug in map_get_next_key
From: syzbot @ 2018-05-16 15:35 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: c5c7d7f3c451 Merge branch 'bpf-sock-hashmap'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13ec7877800000
kernel config: https://syzkaller.appspot.com/x/.config?x=10c4dc62055b68f5
dashboard link: https://syzkaller.appspot.com/bug?extid=e4566d29080e7f3460ff
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12c35417800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=178c97f7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e4566d29080e7f3460ff@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
WARNING: CPU: 0 PID: 4499 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
mm/slab_common.c:996
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4499 Comm: syz-executor050 Not tainted 4.17.0-rc3+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
RSP: 0018:ffff8801d907fc58 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801aeecb280 RCX: ffffffff8185ebd7
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffe1
RBP: ffff8801d907fc58 R08: ffff8801adb5e1c0 R09: ffffed0035a84700
R10: ffffed0035a84700 R11: ffff8801ad423803 R12: ffff8801aeecb280
R13: 00000000fffffff4 R14: ffff8801ad891a00 R15: 00000000014200c0
__do_kmalloc mm/slab.c:3713 [inline]
__kmalloc+0x25/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
map_get_next_key+0x24a/0x640 kernel/bpf/syscall.c:858
__do_sys_bpf kernel/bpf/syscall.c:2131 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2096 [inline]
__x64_sys_bpf+0x354/0x4f0 kernel/bpf/syscall.c:2096
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fd89
RSP: 002b:00007ffd6aab4668 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd89
RDX: 0000000000000007 RSI: 0000000020000040 RDI: 0000000000000004
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016b0
R13: 0000000000401740 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* WARNING: kmalloc bug in memdup_user (3)
From: syzbot @ 2018-05-16 15:35 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: c5c7d7f3c451 Merge branch 'bpf-sock-hashmap'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1626ae37800000
kernel config: https://syzkaller.appspot.com/x/.config?x=10c4dc62055b68f5
dashboard link: https://syzkaller.appspot.com/bug?extid=0f92a17b0706231d0a09
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=126a5197800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1598c477800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0f92a17b0706231d0a09@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
WARNING: CPU: 0 PID: 4531 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
mm/slab_common.c:996
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4531 Comm: syz-executor594 Not tainted 4.17.0-rc3+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
RSP: 0018:ffff8801ad4b7c48 EFLAGS: 00010246
RAX: 0000000000000000 RBX: fffffffffffffff4 RCX: ffffffff8185e678
RDX: ffffffff8185e6eb RSI: 0000000000000000 RDI: 00000000fffffffd
RBP: ffff8801ad4b7c48 R08: ffff8801adb3e2c0 R09: ffffed0035ba1f08
R10: ffffed0035ba1f08 R11: ffff8801add0f843 R12: 00000000fffffffd
R13: 0000000020000240 R14: 00000000ffffffff R15: 00000000014200c0
__do_kmalloc mm/slab.c:3713 [inline]
__kmalloc_track_caller+0x21/0x760 mm/slab.c:3733
memdup_user+0x2c/0xa0 mm/util.c:160
map_delete_elem+0x21b/0x4e0 kernel/bpf/syscall.c:796
__do_sys_bpf kernel/bpf/syscall.c:2128 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2096 [inline]
__x64_sys_bpf+0x33f/0x4f0 kernel/bpf/syscall.c:2096
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fd89
RSP: 002b:00007ffe3ad9ad78 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd89
RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016b0
R13: 0000000000401740 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-16 15:33 UTC (permalink / raw)
To: Roman Mashak
Cc: Jamal Hadi Salim, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
Eric Dumazet, kliteyn
In-Reply-To: <CAHvchG=Kj9HNfzWfbqGA1rmmTh=C5PDPKJfDO6mUyXtA052hog@mail.gmail.com>
On Wed 16 May 2018 at 14:38, Roman Mashak <mrv@mojatatu.com> wrote:
> On Wed, May 16, 2018 at 2:43 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
>>>>>> I'm trying to run tdc, but keep getting following error even on clean
>>>>>> branch without my patches:
>>>>>
>>>>> Vlad, not sure if you saw my email:
>>>>> Apply Roman's patch and try again
>>>>>
>>>>> https://marc.info/?l=linux-netdev&m=152639369112020&w=2
>>>>>
>>>>> cheers,
>>>>> jamal
>>>>
>>>> With patch applied I get following error:
>>>>
>>>> Test 7d50: Add skbmod action to set destination mac
>>>> exit: 255 0
>>>> dst MAC address <11:22:33:44:55:66>
>>>> RTNETLINK answers: No such file or directory
>>>> We have an error talking to the kernel
>>>>
>>>
>>> You may actually have broken something with your patches in this case.
>>
>> Results is for net-next without my patches.
>
> Do you have skbmod compiled in kernel or as a module?
Thanks, already figured out that default config has some actions
disabled.
Have more errors now. Everything related to ife:
Test 7682: Create valid ife encode action with mark and pass control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No such file or directory
We have an error talking to the kernel
Test ef47: Create valid ife encode action with mark and pipe control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test df43: Create valid ife encode action with mark and continue control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test e4cf: Create valid ife encode action with mark and drop control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test ccba: Create valid ife encode action with mark and reclassify control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test a1cf: Create valid ife encode action with mark and jump control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
...
And problem with u32:
Test e9a3: Add u32 with source match
-----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 ingress"
-----> prepare stage *** Error message: "Cannot find device "v0p1"
"
-----> prepare stage *** Aborting test run.
<_io.BufferedReader name=3> *** stdout ***
<_io.BufferedReader name=5> *** stderr ***
"-----> prepare stage" did not complete successfully
Exception <class '__main__.PluginMgrTestFail'> ('setup', None, '"-----> prepare stage" did not complete successfully') (caught in test_runner, running test 238 e9a3 Add u32 with source match stage setup)
---------------
traceback
File "./tdc.py", line 293, in test_runner
tap += run_one_test(pm, args, index, tidx)
File "./tdc.py", line 192, in run_one_test
prepare_env(args, pm, 'setup', "-----> prepare stage", tidx["setup"])
File "./tdc.py", line 177, in prepare_env
'"{}" did not complete successfully'.format(prefix))
---------------
---------------
Any suggestions regarding these errors?
Thanks,
Vlad
^ 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