Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] phy: added a PHY_BUSY state into phy_state_machine
From: kbuild test robot @ 2019-07-09  1:58 UTC (permalink / raw)
  To: kwangdo.yi; +Cc: kbuild-all, netdev, kwangdo.yi
In-Reply-To: <1562538732-20700-1-git-send-email-kwangdo.yi@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4357 bytes --]

Hi "kwangdo.yi",

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.2]
[cannot apply to next-20190708]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/kwangdo-yi/phy-added-a-PHY_BUSY-state-into-phy_state_machine/20190709-075228
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.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
        GCC_VERSION=7.4.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   drivers/net/phy/phy.c: In function 'phy_state_to_str':
>> drivers/net/phy/phy.c:38:2: warning: enumeration value 'PHY_BUSY' not handled in switch [-Wswitch]
     switch (st) {
     ^~~~~~
   drivers/net/phy/phy.c: In function 'phy_state_machine':
>> drivers/net/phy/phy.c:925:4: error: 'phy' undeclared (first use in this function)
       phy->state = PHY_BUSY;
       ^~~
   drivers/net/phy/phy.c:925:4: note: each undeclared identifier is reported only once for each function it appears in

vim +/phy +925 drivers/net/phy/phy.c

   894	
   895	/**
   896	 * phy_state_machine - Handle the state machine
   897	 * @work: work_struct that describes the work to be done
   898	 */
   899	void phy_state_machine(struct work_struct *work)
   900	{
   901		struct delayed_work *dwork = to_delayed_work(work);
   902		struct phy_device *phydev =
   903				container_of(dwork, struct phy_device, state_queue);
   904		bool needs_aneg = false, do_suspend = false;
   905		enum phy_state old_state;
   906		int err = 0;
   907	
   908		mutex_lock(&phydev->lock);
   909	
   910		old_state = phydev->state;
   911	
   912		switch (phydev->state) {
   913		case PHY_DOWN:
   914		case PHY_READY:
   915			break;
   916		case PHY_UP:
   917			needs_aneg = true;
   918	
   919			break;
   920		case PHY_NOLINK:
   921		case PHY_RUNNING:
   922		case PHY_BUSY:
   923			err = phy_check_link_status(phydev);
   924			if (err == -ETIMEDOUT && old_state == PHY_RUNNING) {
 > 925				phy->state = PHY_BUSY;
   926				err = 0;
   927	
   928			}
   929			break;
   930		case PHY_FORCING:
   931			err = genphy_update_link(phydev);
   932			if (err)
   933				break;
   934	
   935			if (phydev->link) {
   936				phydev->state = PHY_RUNNING;
   937				phy_link_up(phydev);
   938			} else {
   939				if (0 == phydev->link_timeout--)
   940					needs_aneg = true;
   941				phy_link_down(phydev, false);
   942			}
   943			break;
   944		case PHY_HALTED:
   945			if (phydev->link) {
   946				phydev->link = 0;
   947				phy_link_down(phydev, true);
   948				do_suspend = true;
   949			}
   950			break;
   951		}
   952	
   953		mutex_unlock(&phydev->lock);
   954	
   955		if (needs_aneg)
   956			err = phy_start_aneg(phydev);
   957		else if (do_suspend)
   958			phy_suspend(phydev);
   959	
   960		if (err < 0)
   961			phy_error(phydev);
   962	
   963		if (old_state != phydev->state) {
   964			phydev_dbg(phydev, "PHY state change %s -> %s\n",
   965				   phy_state_to_str(old_state),
   966				   phy_state_to_str(phydev->state));
   967			if (phydev->drv && phydev->drv->link_change_notify)
   968				phydev->drv->link_change_notify(phydev);
   969		}
   970	
   971		/* Only re-schedule a PHY state machine change if we are polling the
   972		 * PHY, if PHY_IGNORE_INTERRUPT is set, then we will be moving
   973		 * between states from phy_mac_interrupt().
   974		 *
   975		 * In state PHY_HALTED the PHY gets suspended, so rescheduling the
   976		 * state machine would be pointless and possibly error prone when
   977		 * called from phy_disconnect() synchronously.
   978		 */
   979		mutex_lock(&phydev->lock);
   980		if (phy_polling_mode(phydev) && phy_is_started(phydev))
   981			phy_queue_state_machine(phydev, PHY_STATE_TIME);
   982		mutex_unlock(&phydev->lock);
   983	}
   984	

---
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: 36418 bytes --]

^ permalink raw reply

* Re: [PATCH net-next,v3 11/11] netfilter: nf_tables: add hardware offload support
From: Jakub Kicinski @ 2019-07-09  1:44 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: netdev, davem, thomas.lendacky, f.fainelli, ariel.elior,
	michael.chan, madalin.bucur, yisen.zhuang, salil.mehta,
	jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, peppe.cavallaro,
	grygorii.strashko, andrew, vivien.didelot, alexandre.torgue,
	joabreu, linux-net-drivers, ogerlitz, Manish.Chopra,
	marcelo.leitner, mkubecek, venkatkumar.duvvuru, maxime.chevallier,
	cphealy, netfilter-devel
In-Reply-To: <20190708160614.2226-12-pablo@netfilter.org>

On Mon,  8 Jul 2019 18:06:13 +0200, Pablo Neira Ayuso wrote:
> This patch adds hardware offload support for nftables through the
> existing netdev_ops->ndo_setup_tc() interface, the TC_SETUP_CLSFLOWER
> classifier and the flow rule API. This hardware offload support is
> available for the NFPROTO_NETDEV family and the ingress hook.
> 
> Each nftables expression has a new ->offload interface, that is used to
> populate the flow rule object that is attached to the transaction
> object.
> 
> There is a new per-table NFT_TABLE_F_HW flag, that is set on to offload
> an entire table, including all of its chains.
> 
> This patch supports for basic metadata (layer 3 and 4 protocol numbers),
> 5-tuple payload matching and the accept/drop actions; this also includes
> basechain hardware offload only.
> 
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

Any particular reason to not fence this off with a device feature
(ethtool -k)?  Then you wouldn't need that per-driver list abomination
until drivers start advertising it..  IDK if we want the per-device
offload enable flags or not in general, it seems like a good idea in
general for admin to be able to disable offload per device 🤷

> +static int nft_flow_offload_rule(struct nft_trans *trans,
> +				 enum tc_fl_command command)
> +{
> +	struct nft_flow_rule *flow = nft_trans_flow_rule(trans);
> +	struct nft_rule *rule = nft_trans_rule(trans);
> +	struct tc_cls_flower_offload cls_flower = {};
> +	struct nft_base_chain *basechain;
> +	struct netlink_ext_ack extack;
> +	__be16 proto = ETH_P_ALL;
> +
> +	if (!nft_is_base_chain(trans->ctx.chain))
> +		return -EOPNOTSUPP;
> +
> +	basechain = nft_base_chain(trans->ctx.chain);
> +
> +	if (flow)
> +		proto = flow->proto;
> +
> +	nft_flow_offload_common_init(&cls_flower.common, proto, &extack);
> +	cls_flower.command = command;
> +	cls_flower.cookie = (unsigned long) rule;
> +	if (flow)
> +		cls_flower.rule = flow->rule;
> +
> +	return nft_setup_cb_call(basechain, TC_SETUP_CLSFLOWER, &cls_flower);
> +}

Are we 100% okay with using TC cls_flower structures and defines in nft
code?

^ permalink raw reply

* Re: [PATCH net-next,v3 08/11] drivers: net: use flow block API
From: Jakub Kicinski @ 2019-07-09  1:35 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: netdev, davem, thomas.lendacky, f.fainelli, ariel.elior,
	michael.chan, madalin.bucur, yisen.zhuang, salil.mehta,
	jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, peppe.cavallaro,
	grygorii.strashko, andrew, vivien.didelot, alexandre.torgue,
	joabreu, linux-net-drivers, ogerlitz, Manish.Chopra,
	marcelo.leitner, mkubecek, venkatkumar.duvvuru, maxime.chevallier,
	cphealy, netfilter-devel
In-Reply-To: <20190708160614.2226-9-pablo@netfilter.org>

On Mon,  8 Jul 2019 18:06:10 +0200, Pablo Neira Ayuso wrote:
> diff --git a/drivers/net/ethernet/netronome/nfp/bpf/main.c b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> index 0c93c84a188a..7549547c4ef0 100644
> --- a/drivers/net/ethernet/netronome/nfp/bpf/main.c
> +++ b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> @@ -160,6 +160,8 @@ static int nfp_bpf_setup_tc_block_cb(enum tc_setup_type type,
>  	return 0;
>  }
>  
> +static LIST_HEAD(nfp_bfp_block_cb_list);

This still says bfp.

> +
>  static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
>  			    enum tc_setup_type type, void *type_data)
>  {
> @@ -167,7 +169,8 @@ static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
>  
>  	switch (type) {
>  	case TC_SETUP_BLOCK:
> -		return flow_block_cb_setup_simple(type_data, NULL,
> +		return flow_block_cb_setup_simple(type_data,
> +						  &nfp_bfp_block_cb_list,
>  						  nfp_bpf_setup_tc_block_cb,
>  						  nn, nn, true);
>  	default:


^ permalink raw reply

* [PATCH net-next 2/2] tc-testing: introduce scapyPlugin for basic traffic
From: Lucas Bates @ 2019-07-09  1:34 UTC (permalink / raw)
  To: davem
  Cc: netdev, jhs, xiyou.wangcong, jiri, mleitner, vladbu, dcaratti,
	kernel, Lucas Bates
In-Reply-To: <1562636067-1338-1-git-send-email-lucasb@mojatatu.com>

The scapyPlugin allows for simple traffic generation in tdc to
test various tc features. It was tested with scapy v2.4.2, but
should work with any successive version.

In order to use the plugin's functionality, scapy must be
installed. This can be done with:
   pip3 install scapy

or to install 2.4.2:
   pip3 install scapy==2.4.2

If the plugin is unable to import the scapy module, it will
terminate the tdc run.

The plugin makes use of a new key in the test case data, 'scapy'.
This block contains three other elements: 'iface', 'count', and
'packet':

        "scapy": {
            "iface": "$DEV0",
            "count": 1,
            "packet": "Ether(type=0x800)/IP(src='16.61.16.61')/ICMP()"
        },

* iface is the name of the device on the host machine from which
  the packet(s) will be sent. Values contained within tdc_config.py's
  NAMES dict can be used here - this is useful if paired with
  nsPlugin
* count is the number of copies of this packet to be sent
* packet is a string detailing the different layers of the packet
  to be sent. If a property isn't explicitly set, scapy will set
  default values for you.

Layers in the packet info are separated by slashes. For info about
common TCP and IP properties, see:
https://blogs.sans.org/pen-testing/files/2016/04/ScapyCheatSheet_v0.2.pdf

Caution is advised when running tests using the scapy functionality,
since the plugin blindly sends the packet as defined in the test case
data.

See creating-testcases/scapy-example.json for sample test cases;
the first test is intended to pass while the second is intended to
fail.

Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
---
 .../creating-testcases/scapy-example.json          | 98 ++++++++++++++++++++++
 .../selftests/tc-testing/plugin-lib/scapyPlugin.py | 51 +++++++++++
 2 files changed, 149 insertions(+)
 create mode 100644 tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json
 create mode 100644 tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py

diff --git a/tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json b/tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json
new file mode 100644
index 0000000..5a9377b
--- /dev/null
+++ b/tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json
@@ -0,0 +1,98 @@
+[
+    {
+        "id": "b1e9",
+        "name": "Test matching of source IP",
+        "category": [
+            "actions",
+            "scapy"
+        ],
+        "plugins": {
+            "requires": [
+                "nsPlugin",
+                "scapyPlugin"
+            ]
+        },
+        "setup": [
+            [
+                "$TC qdisc del dev $DEV1 ingress",
+                0,
+                1,
+                2,
+                255
+            ],
+            "$TC qdisc add dev $DEV1 ingress"
+        ],
+        "cmdUnderTest": "$TC filter add dev $DEV1 parent ffff: prio 3 protocol ip flower src_ip 16.61.16.61 flowid 1:1 action ok",
+        "scapy": {
+            "iface": "$DEV0",
+            "count": 1,
+            "packet": "Ether(type=0x800)/IP(src='16.61.16.61')/ICMP()"
+        },
+        "expExitCode": "0",
+        "verifyCmd": "$TC -s -j filter ls dev $DEV1 ingress prio 3",
+        "matchJSON": [
+            {
+                "path": [
+                    1,
+                    "options",
+                    "actions",
+                    0,
+                    "stats",
+                    "packets"
+                ],
+                "value": 1
+            }
+        ],
+        "teardown": [
+            "$TC qdisc del dev $DEV1 ingress"
+        ]
+    },
+    {
+        "id": "e9c4",
+        "name": "Test matching of source IP with wrong count",
+        "category": [
+            "actions",
+            "scapy"
+        ],
+        "plugins": {
+            "requires": [
+                "nsPlugin",
+                "scapyPlugin"
+            ]
+        },
+        "setup": [
+            [
+                "$TC qdisc del dev $DEV1 ingress",
+                0,
+                1,
+                2,
+                255
+            ],
+            "$TC qdisc add dev $DEV1 ingress"
+        ],
+        "cmdUnderTest": "$TC filter add dev $DEV1 parent ffff: prio 3 protocol ip flower src_ip 16.61.16.61 flowid 1:1 action ok",
+        "scapy": {
+            "iface": "$DEV0",
+            "count": 3,
+            "packet": "Ether(type=0x800)/IP(src='16.61.16.61')/ICMP()"
+        },
+        "expExitCode": "0",
+        "verifyCmd": "$TC -s -j filter ls dev $DEV1 parent ffff:",
+        "matchJSON": [
+            {
+                "path": [
+                    1,
+                    "options",
+                    "actions",
+                    0,
+                    "stats",
+                    "packets"
+                ],
+                "value": 1
+            }
+        ],
+        "teardown": [
+            "$TC qdisc del dev $DEV1 ingress"
+        ]
+    }
+]
diff --git a/tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py b/tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py
new file mode 100644
index 0000000..db57916
--- /dev/null
+++ b/tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py
@@ -0,0 +1,51 @@
+#!/usr/bin/env python3
+
+import os
+import signal
+from string import Template
+import subprocess
+import time
+from TdcPlugin import TdcPlugin
+
+from tdc_config import *
+
+try:
+    from scapy.all import *
+except ImportError:
+    print("Unable to import the scapy python module.")
+    print("\nIf not already installed, you may do so with:")
+    print("\t\tpip3 install scapy==2.4.2")
+    exit(1)
+
+class SubPlugin(TdcPlugin):
+    def __init__(self):
+        self.sub_class = 'scapy/SubPlugin'
+        super().__init__()
+
+    def post_execute(self):
+        if 'scapy' not in self.args.caseinfo:
+            if self.args.verbose:
+                print('{}.post_execute: no scapy info in test case'.format(self.sub_class))
+            return
+
+        # Check for required fields
+        scapyinfo = self.args.caseinfo['scapy']
+        scapy_keys = ['iface', 'count', 'packet']
+        missing_keys = []
+        keyfail = False
+        for k in scapy_keys:
+            if k not in scapyinfo:
+                keyfail = True
+                missing_keys.add(k)
+        if keyfail:
+            print('{}: Scapy block present in the test, but is missing info:'
+                .format(self.sub_class))
+            print('{}'.format(missing_keys))
+
+        pkt = eval(scapyinfo['packet'])
+        if '$' in scapyinfo['iface']:
+            tpl = Template(scapyinfo['iface'])
+            scapyinfo['iface'] = tpl.safe_substitute(NAMES)
+        for count in range(scapyinfo['count']):
+            sendp(pkt, iface=scapyinfo['iface'])
+
--
2.7.4


^ permalink raw reply related

* [PATCH net-next 1/2] tc-testing: Allow tdc plugins to see test case data
From: Lucas Bates @ 2019-07-09  1:34 UTC (permalink / raw)
  To: davem
  Cc: netdev, jhs, xiyou.wangcong, jiri, mleitner, vladbu, dcaratti,
	kernel, Lucas Bates
In-Reply-To: <1562636067-1338-1-git-send-email-lucasb@mojatatu.com>

Instead of only passing the test case name and ID, pass the
entire current test case down to the plugins. This change
allows plugins to start accepting commands and directives
from the test cases themselves, for greater flexibility
in testing.

Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
---
 tools/testing/selftests/tc-testing/TdcPlugin.py |  5 ++---
 tools/testing/selftests/tc-testing/tdc.py       | 10 +++++-----
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/tc-testing/TdcPlugin.py b/tools/testing/selftests/tc-testing/TdcPlugin.py
index b980a56..79f3ca8 100644
--- a/tools/testing/selftests/tc-testing/TdcPlugin.py
+++ b/tools/testing/selftests/tc-testing/TdcPlugin.py
@@ -18,12 +18,11 @@ class TdcPlugin:
         if self.args.verbose > 1:
             print(' -- {}.post_suite'.format(self.sub_class))
 
-    def pre_case(self, testid, test_name, test_skip):
+    def pre_case(self, caseinfo, test_skip):
         '''run commands before test_runner does one test'''
         if self.args.verbose > 1:
             print(' -- {}.pre_case'.format(self.sub_class))
-        self.args.testid = testid
-        self.args.test_name = test_name
+        self.args.caseinfo = caseinfo
         self.args.test_skip = test_skip
 
     def post_case(self):
diff --git a/tools/testing/selftests/tc-testing/tdc.py b/tools/testing/selftests/tc-testing/tdc.py
index 1afa803..de7da9a 100755
--- a/tools/testing/selftests/tc-testing/tdc.py
+++ b/tools/testing/selftests/tc-testing/tdc.py
@@ -126,15 +126,15 @@ class PluginMgr:
         for pgn_inst in reversed(self.plugin_instances):
             pgn_inst.post_suite(index)
 
-    def call_pre_case(self, testid, test_name, *, test_skip=False):
+    def call_pre_case(self, caseinfo, *, test_skip=False):
         for pgn_inst in self.plugin_instances:
             try:
-                pgn_inst.pre_case(testid, test_name, test_skip)
+                pgn_inst.pre_case(caseinfo, test_skip)
             except Exception as ee:
                 print('exception {} in call to pre_case for {} plugin'.
                       format(ee, pgn_inst.__class__))
                 print('test_ordinal is {}'.format(test_ordinal))
-                print('testid is {}'.format(testid))
+                print('testid is {}'.format(caseinfo['id']))
                 raise
 
     def call_post_case(self):
@@ -379,14 +379,14 @@ def run_one_test(pm, args, index, tidx):
             res = TestResult(tidx['id'], tidx['name'])
             res.set_result(ResultState.skip)
             res.set_errormsg('Test case designated as skipped.')
-            pm.call_pre_case(tidx['id'], tidx['name'], test_skip=True)
+            pm.call_pre_case(tidx, test_skip=True)
             pm.call_post_execute()
             return res
 
     # populate NAMES with TESTID for this test
     NAMES['TESTID'] = tidx['id']
 
-    pm.call_pre_case(tidx['id'], tidx['name'])
+    pm.call_pre_case(tidx)
     prepare_env(args, pm, 'setup', "-----> prepare stage", tidx["setup"])
 
     if (args.verbose > 0):
-- 
2.7.4


^ permalink raw reply related

* [PATCH net-next 0/2] tc-testing: Add plugin for simple traffic generation
From: Lucas Bates @ 2019-07-09  1:34 UTC (permalink / raw)
  To: davem
  Cc: netdev, jhs, xiyou.wangcong, jiri, mleitner, vladbu, dcaratti,
	kernel, Lucas Bates

This series supersedes the previous submission that included a patch for test
case verification using JSON output.  It adds a new tdc plugin, scapyPlugin, as
a way to send traffic to test tc filters and actions.

The first patch makes a change to the TdcPlugin module that will allow tdc
plugins to examine the test case currently being executed, so plugins can
play a more active role in testing by accepting information or commands from
the test case.  This is required for scapyPlugin to work.

The second patch adds scapyPlugin itself, and an example test case file to
demonstrate how the scapy block works in the test cases.

Lucas Bates (2):
  tc-testing: Allow tdc plugins to see test case data
  tc-testing: introduce scapyPlugin for basic traffic

 tools/testing/selftests/tc-testing/TdcPlugin.py    |  5 +-
 .../creating-testcases/scapy-example.json          | 98 ++++++++++++++++++++++
 .../selftests/tc-testing/plugin-lib/scapyPlugin.py | 51 +++++++++++
 tools/testing/selftests/tc-testing/tdc.py          | 10 +--
 4 files changed, 156 insertions(+), 8 deletions(-)
 create mode 100644 tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json
 create mode 100644 tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py

--
2.7.4


^ permalink raw reply

* Re: [PATCH 1/4] dt-bindings: allow up to four clocks for orion-mdio
From: Rob Herring @ 2019-07-09  1:32 UTC (permalink / raw)
  To: josua; +Cc: netdev, stable, David S. Miller, Mark Rutland
In-Reply-To: <20190706151900.14355-2-josua@solid-run.com>

On Sat, Jul 6, 2019 at 9:31 AM <josua@solid-run.com> wrote:
>
> From: Josua Mayer <josua@solid-run.com>
>
> Armada 8040 needs four clocks to be enabled for MDIO accesses to work.
> Update the binding to allow the extra clock to be specified.
>
> Cc: stable@vger.kernel.org
> Fixes: 6d6a331f44a1 ("dt-bindings: allow up to three clocks for orion-mdio")
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
>  Documentation/devicetree/bindings/net/marvell-orion-mdio.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
> index 42cd81090a2c..3f3cfc1d8d4d 100644
> --- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
> @@ -16,7 +16,7 @@ Required properties:
>
>  Optional properties:
>  - interrupts: interrupt line number for the SMI error/done interrupt
> -- clocks: phandle for up to three required clocks for the MDIO instance
> +- clocks: phandle for up to four required clocks for the MDIO instance

This needs to enumerate exactly what the clocks are. Shouldn't there
be an additional clock-names value too?

Rob

^ permalink raw reply

* Re: [PATCH net-next,v3 01/11] net: flow_offload: add flow_block_cb_setup_simple()
From: Jakub Kicinski @ 2019-07-09  1:30 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: netdev, davem, thomas.lendacky, f.fainelli, ariel.elior,
	michael.chan, madalin.bucur, yisen.zhuang, salil.mehta,
	jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, peppe.cavallaro,
	grygorii.strashko, andrew, vivien.didelot, alexandre.torgue,
	joabreu, linux-net-drivers, ogerlitz, Manish.Chopra,
	marcelo.leitner, mkubecek, venkatkumar.duvvuru, maxime.chevallier,
	cphealy, netfilter-devel
In-Reply-To: <20190708160614.2226-2-pablo@netfilter.org>

On Mon,  8 Jul 2019 18:06:03 +0200, Pablo Neira Ayuso wrote:
> Most drivers do the same thing to set up the flow block callbacks, this
> patch adds a helper function to do this.
> 
> This preparation patch reduces the number of changes to adapt the
> existing drivers to use the flow block callback API.
> 
> This new helper function takes a flow block list per-driver, which is
> set to NULL until this driver list is used.
> 
> This patch also introduces the flow_block_command and
> flow_block_binder_type enumerations, which are renamed to use
> FLOW_BLOCK_* in follow up patches.
> 
> There are three definitions (aliases) in order to reduce the number of
> updates in this patch, which go away once drivers are fully adapted to
> use this flow block API.
> 
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>

Thanks!

^ permalink raw reply

* Re: [PATCH v2 net-next 3/3] tc-testing: introduce scapyPlugin for basic traffic
From: Lucas Bates @ 2019-07-09  1:28 UTC (permalink / raw)
  To: Alexander Aring
  Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim,
	Cong Wang, Jiri Pirko, Marcelo Ricardo Leitner, Vlad Buslov,
	Davide Caratti, kernel
In-Reply-To: <20190704202909.gmggf3agxjgvyjsj@x220t>

Sorry Alex, I completely forgot about this email.
On Thu, Jul 4, 2019 at 4:29 PM Alexander Aring <aring@mojatatu.com> wrote:
>
> Hi,
>
> On Wed, Jul 03, 2019 at 08:45:02PM -0400, Lucas Bates wrote:
> > The scapyPlugin allows for simple traffic generation in tdc to
> > test various tc features. It was tested with scapy v2.4.2, but
> > should work with any successive version.
> Is there a way to introduce thrid party scapy level descriptions which
> are not upstream yet?

Upstream to scapy? Not yet.  This version of the plugin is extremely
simple, and good for basic traffic.  I'll add features to it so we can
get more creative with the packets that can be sent, though.

Lucas

^ permalink raw reply

* Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface
From: Jakub Kicinski @ 2019-07-09  1:26 UTC (permalink / raw)
  To: Shannon Nelson; +Cc: netdev
In-Reply-To: <20190708192532.27420-20-snelson@pensando.io>

On Mon,  8 Jul 2019 12:25:32 -0700, Shannon Nelson wrote:
> Add a devlink interface for access to information that isn't
> normally available through ethtool or the iplink interface.
> 
> Example:
> 	$ ./devlink -j -p dev info pci/0000:b6:00.0
> 	{
> 	    "info": {
> 		"pci/0000:b6:00.0": {
> 		    "driver": "ionic",
> 		    "serial_number": "FLM18420073",
> 		    "versions": {
> 			"fixed": {
> 			    "fw_version": "0.11.0-50",

Hm. Fixed is for hardware components. Seeing FW version reported as
fixed seems counter intuitive.  You probably want "running"?

> 			    "fw_status": "0x1",

I don't think this is the right interface to report status-like
information.  Perhaps devlink health reporters?

> 			    "fw_heartbeat": "0x716ce",

Ditto, perhaps best to report it in health stuff?

> 			    "asic_type": "0x0",
> 			    "asic_rev": "0x0"

These seem like legit "fixed" versions 👍

> 			}
> 		    }
> 		}
> 	    }
> 	}
> 
> Signed-off-by: Shannon Nelson <snelson@pensando.io>

Isn't this a new patch? Perhaps you'd be best off upstreaming the
first batch of support and add features later? It'd be easier on
reviewers so we don't have to keep re-checking the first 16 patches..

^ permalink raw reply

* Re: [PATCH v2 net-next 1/3] tc-testing: Add JSON verification to tdc
From: Lucas Bates @ 2019-07-09  1:17 UTC (permalink / raw)
  To: Alexander Aring
  Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim,
	Cong Wang, Jiri Pirko, Marcelo Ricardo Leitner, Vlad Buslov,
	Davide Caratti, kernel
In-Reply-To: <20190708172458.syopc3bvvkjb3sxv@x220t>

On Mon, Jul 8, 2019 at 1:25 PM Alexander Aring <aring@mojatatu.com> wrote:
> > Unless I'm off-base here?
>
> yes you need to know some python, complex code can be hidden by some
> helper functionality I guess.
>
> I have no problem to let this patch in, it will not harm anything...
I think I'm going to pull it for the moment - I started thinking about
the patch today and I think it needs more testing against larger
amounts of data.

> Maybe I work on a matchEval and show some examples... in a human
> readable way you can even concatenate bool expressions in combinations
> with helpers.
>
> I just was curious, so I might add the matchEval or something to show
> this approach.

Go for it, I think you have a much better grasp on the use of eval
than I do - and it could be very useful for test cases.

^ permalink raw reply

* Re: [PATCH net v2] Validate required parameters in inet6_validate_link_af
From: Stefan Lippers-Hollmann @ 2019-07-09  1:11 UTC (permalink / raw)
  To: David Miller; +Cc: maximmi, jakub.kicinski, kuznet, yoshfuji, netdev, leonro
In-Reply-To: <20190522.120748.42244348495685617.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 8074 bytes --]

Hi

On 2019-05-22, David Miller wrote:
> From: Maxim Mikityanskiy <maximmi@mellanox.com>
> Date: Tue, 21 May 2019 06:40:04 +0000
>
> > inet6_set_link_af requires that at least one of IFLA_INET6_TOKEN or
> > IFLA_INET6_ADDR_GET_MODE is passed. If none of them is passed, it
> > returns -EINVAL, which may cause do_setlink() to fail in the middle of
> > processing other commands and give the following warning message:
> >
> >   A link change request failed with some changes committed already.
> >   Interface eth0 may have been left with an inconsistent configuration,
> >   please check.
> >
> > Check the presence of at least one of them in inet6_validate_link_af to
> > detect invalid parameters at an early stage, before do_setlink does
> > anything. Also validate the address generation mode at an early stage.
> >
> > Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
>
> Applied, thank you.

After updating from kernel 5.1.16 to 5.2, I noticed that my
systemd-networkd (241-5, Debian/unstable) managed bridges didn't
come up and needed a manual "ip link set dev br-lan up" to get
configured. Bisecting between v5.1 and v5.2 pointed to this
patch and reverting just this change from v5.2 fixes the issue
for me again.

$ git bisect start
# good: [e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd] Linux 5.1
git bisect good e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd
# bad: [46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28] Merge tag 'for-linus-20190706' of git://git.kernel.dk/linux-block
git bisect bad 46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28
# good: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
git bisect good a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
# good: [22c58fd70ca48a29505922b1563826593b08cc00] Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect good 22c58fd70ca48a29505922b1563826593b08cc00
# good: [61939b12dc24d0ac958020f261046c35a16e0c48] block: print offending values when cloned rq limits are exceeded
git bisect good 61939b12dc24d0ac958020f261046c35a16e0c48
# bad: [3510955b327176fd4cbab5baa75b449f077722a2] mm/list_lru.c: fix memory leak in __memcg_init_list_lru_node
git bisect bad 3510955b327176fd4cbab5baa75b449f077722a2
# bad: [30d1d92a888d03681b927c76a35181b4eed7071f] Merge tag 'nds32-for-linux-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux
git bisect bad 30d1d92a888d03681b927c76a35181b4eed7071f
# bad: [dbde71df810c62e72e2aa6d88a0686a6092956cd] Merge tag 'tty-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect bad dbde71df810c62e72e2aa6d88a0686a6092956cd
# bad: [100f6d8e09905c59be45b6316f8f369c0be1b2d8] net: correct zerocopy refcnt with udp MSG_MORE
git bisect bad 100f6d8e09905c59be45b6316f8f369c0be1b2d8
# bad: [4ca6dee5220fe2377bf12b354ef85978425c9ec7] dpaa2-eth: Make constant 64-bit long
git bisect bad 4ca6dee5220fe2377bf12b354ef85978425c9ec7
# bad: [b5730061d1056abf317caea823b94d6e12b5b4f6] cxgb4: offload VLAN flows regardless of VLAN ethtype
git bisect bad b5730061d1056abf317caea823b94d6e12b5b4f6
# bad: [c1e85c6ce57ef1eb73966152993a341c8123a8ea] net: macb: save/restore the remaining registers and features
git bisect bad c1e85c6ce57ef1eb73966152993a341c8123a8ea
# bad: [f42c104f2ec94a9255a835cd4cd1bd76279d4d06] Documentation: add TLS offload documentation
git bisect bad f42c104f2ec94a9255a835cd4cd1bd76279d4d06
# bad: [d008b3d2be4b00267e7af5c21269e7af4f65c6e2] mISDN: Fix indenting in dsp_cmx.c
git bisect bad d008b3d2be4b00267e7af5c21269e7af4f65c6e2
# bad: [40a1578d631a8ac1cf0ef797c435114107747859] ocelot: Dont allocate another multicast list, use __dev_mc_sync
git bisect bad 40a1578d631a8ac1cf0ef797c435114107747859
# bad: [7dc2bccab0ee37ac28096b8fcdc390a679a15841] Validate required parameters in inet6_validate_link_af
git bisect bad 7dc2bccab0ee37ac28096b8fcdc390a679a15841
# first bad commit: [7dc2bccab0ee37ac28096b8fcdc390a679a15841] Validate required parameters in inet6_validate_link_af

While I originally noticed this issue on real hardware (r8169, e1000,
e1000e, e100, alx) and multiple systems with a slightly complex bridge
setup, I can reproduce it with a very basic configuration under kvm
(upon which all the tests below are based):

$ cat /etc/systemd/network/20-wired.network
[Match]
Name=ens4

[Network]
DHCP=yes

(same results with just DHCP=ipv4)

With the above systemd-networkd configuration, the system comes up
without network access:

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff

# networkctl | cat -
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     unmanaged
  2 ens4             ether              off         configuring

2 links listed.

Manually enabling the interface does help:

# ip link set dev ens4 up

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 172.23.6.0/14 brd 172.23.255.255 scope global dynamic ens4
       valid_lft 43199sec preferred_lft 43199sec
    inet6 2003:xxxx:xxxx:xxxx::197/128 scope global tentative dynamic noprefixroute
       valid_lft 13809sec preferred_lft 1209sec
    inet6 fdxx:xxxx:xxxx::197/128 scope global tentative noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fdxx:xxxx:xxxx:0:216:3eff:fe00:0/64 scope global tentative mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2003:xxxx:xxxx:xxxx:216:3eff:fe00:0/64 scope global tentative dynamic mngtmpaddr noprefixroute
       valid_lft 13809sec preferred_lft 1209sec
    inet6 fe80::216:3eff:fe00:0/64 scope link
       valid_lft forever preferred_lft forever

# networkctl | cat -
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     unmanaged
  2 ens4             ether              routable    configured

2 links listed.

A quick test of upgrading all systemd packages to 242-2 from
Debian/experimental shows the same issue; Debian 10/ buster (stable)
is shipping with systemd 241-5.

DHCPv4 is served by a recent OpenWrt/ master snapshot on ipq8065/ nbg6817
(ARMv7), using dnsmasq 2.80-13 and odhcpd-ipv6only 2019-05-17-41a74cba-3
covering DHCPv6 and prefix delegation.

Attached are xz compressed versions of the kernel configuration (amd64),
dmesg and journalctl output.

The Debian/unstable VM was started with qemu-kvm 1:3.1+dfsg-8 on a
Debian/unstable host running kernel 5.2 with this patch reverted:

$ QEMU_AUDIO_DRV=pa qemu-system-x86_64 \
	-machine accel=kvm:tcg \
	-monitor stdio \
	-rtc base=localtime \
	-cpu qemu64,+vmx \
	-smp 3 \
	-m 4096 \
	-device virtio-gpu-pci \
	-device virtio-net-pci,mac=00:16:3E:00:00:00,netdev=tap-br-lan0 \
		-netdev tap,ifname=tap-br-lan0,script=no,id=tap-br-lan0 \
	-device AC97 \
	-drive file=/srv/storage/vm/linux.qcow2.img,if=none,discard=unmap,index=0,media=disk,id=hd0 \
		-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd0 \
	-usb \
		-device usb-tablet \
		-device usb-ehci,id=ehci \
		-device nec-usb-xhci,id=xhci \
	-device virtio-rng-pci \
	-boot menu=on

Regards
	Stefan Lippers-Hollmann

[-- Attachment #2: config.xz --]
[-- Type: application/x-xz, Size: 40048 bytes --]

[-- Attachment #3: dmesg.xz --]
[-- Type: application/x-xz, Size: 10116 bytes --]

[-- Attachment #4: journalctl.xz --]
[-- Type: application/x-xz, Size: 14536 bytes --]

^ permalink raw reply

* Re: [PATCH] net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC
From: Jiangfeng Xiao @ 2019-07-09  1:07 UTC (permalink / raw)
  To: David Miller
  Cc: yisen.zhuang, salil.mehta, dingtianhong, robh+dt, mark.rutland,
	netdev, devicetree, linux-kernel, leeyou.li, xiekunxun,
	jianping.liu, nixiaoming
In-Reply-To: <20190708.111833.1002341757593028886.davem@davemloft.net>



On 2019/7/9 2:18, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sun, 07 Jul 2019 22:18:05 -0700 (PDT)
> 
>> From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
>> Date: Fri, 5 Jul 2019 14:10:03 +0800
>>
>>> HI13X1 changed the offsets and bitmaps for tx_desc
>>> registers in the same peripheral device on different
>>> models of the hip04_eth.
>>>
>>> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
>>
>> Applied.
> 
> Actually I didn't apply this because I can't see that HI13X1_GMAC
> kconfig knob anywhere in the tree at all.
> 

Thank you for your guidance, I made a mistake, for which I am
sincerely sorry for wasting your time.

I will submit the correct one again.
I will not make this low-level mistake again.

Thanks,
Jiangfeng Xiao




^ permalink raw reply

* Re: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-07-09  0:27 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Matteo Croce,
	Florian Westphal
In-Reply-To: <20190702121357.65f9b0b4@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

Hi all,

On Tue, 2 Jul 2019 12:13:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/ipv4/devinet.c
> 
> between commit:
> 
>   2e6054636816 ("ipv4: don't set IPv6 only flags to IPv4 addresses")
> 
> from the net tree and commit:
> 
>   2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc net/ipv4/devinet.c
> index c5ebfa199794,137d1892395d..000000000000
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@@ -473,11 -482,10 +487,13 @@@ static int __inet_insert_ifa(struct in_
>   	ifa->ifa_flags &= ~IFA_F_SECONDARY;
>   	last_primary = &in_dev->ifa_list;
>   
>  +	/* Don't set IPv6 only flags to IPv4 addresses */
>  +	ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
>  +
> - 	for (ifap = &in_dev->ifa_list; (ifa1 = *ifap) != NULL;
> - 	     ifap = &ifa1->ifa_next) {
> + 	ifap = &in_dev->ifa_list;
> + 	ifa1 = rtnl_dereference(*ifap);
> + 
> + 	while (ifa1) {
>   		if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
>   		    ifa->ifa_scope <= ifa1->ifa_scope)
>   			last_primary = &ifa1->ifa_next;


I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the devicetree tree with the net-next tree
From: Stephen Rothwell @ 2019-07-09  0:15 UTC (permalink / raw)
  To: Rob Herring, David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Heiner Kallweit, Maxime Ripard
In-Reply-To: <20190628145626.49859e33@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

Hi all,

On Fri, 28 Jun 2019 14:56:26 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the devicetree tree got a conflict in:
> 
>   Documentation/devicetree/bindings/net/ethernet.txt
> 
> between commit:
> 
>   79b647a0c0d5 ("dt-bindings: net: document new usxgmii phy mode")
> 
> from the net-next tree and commit:
> 
>   4e7a33bff7d7 ("dt-bindings: net: Add YAML schemas for the generic Ethernet options")
> 
> from the devicetree tree.
> 
> I fixed it up (the latter seems to include the change made by the former,
> so I just used the latter) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* pull-request: bpf-next 2019-07-09
From: Daniel Borkmann @ 2019-07-09  0:13 UTC (permalink / raw)
  To: davem; +Cc: daniel, ast, netdev, bpf

Hi David,

The following pull-request contains BPF updates for your *net-next* tree.

The main changes are:

1) Lots of libbpf improvements: i) addition of new APIs to attach BPF
   programs to tracing entities such as {k,u}probes or tracepoints,
   ii) improve specification of BTF-defined maps by eliminating the
   need for data initialization for some of the members, iii) addition
   of a high-level API for setting up and polling perf buffers for
   BPF event output helpers, all from Andrii.

2) Add "prog run" subcommand to bpftool in order to test-run programs
   through the kernel testing infrastructure of BPF, from Quentin.

3) Improve verifier for BPF sockaddr programs to support 8-byte stores
   for user_ip6 and msg_src_ip6 members given clang tends to generate
   such stores, from Stanislav.

4) Enable the new BPF JIT zero-extension optimization for further
   riscv64 ALU ops, from Luke.

5) Fix a bpftool json JIT dump crash on powerpc, from Jiri.

6) Fix an AF_XDP race in generic XDP's receive path, from Ilya.

7) Various smaller fixes from Ilya, Yue and Arnd.

Please consider pulling these changes from:

  git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git

Thanks a lot!

----------------------------------------------------------------

The following changes since commit c4cde5804d512a2f8934017dbf7df642dfbdf2ad:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next (2019-07-04 12:48:21 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git 

for you to fetch changes up to bf0bdd1343efbbf65b4d53aef1fce14acbd79d50:

  xdp: fix race on generic receive path (2019-07-09 01:43:26 +0200)

----------------------------------------------------------------
Andrii Nakryiko (19):
      libbpf: make libbpf_strerror_r agnostic to sign of error
      libbpf: introduce concept of bpf_link
      libbpf: add ability to attach/detach BPF program to perf event
      libbpf: add kprobe/uprobe attach API
      libbpf: add tracepoint attach API
      libbpf: add raw tracepoint attach API
      selftests/bpf: switch test to new attach_perf_event API
      selftests/bpf: add kprobe/uprobe selftests
      selftests/bpf: convert existing tracepoint tests to new APIs
      libbpf: capture value in BTF type info for BTF-defined map defs
      selftests/bpf: add __uint and __type macro for BTF-defined maps
      selftests/bpf: convert selftests using BTF-defined maps to new syntax
      selftests/bpf: convert legacy BPF maps to BTF-defined ones
      libbpf: add perf buffer API
      libbpf: auto-set PERF_EVENT_ARRAY size to number of CPUs
      selftests/bpf: test perf buffer API
      tools/bpftool: switch map event_pipe to libbpf's perf_buffer
      libbpf: add perf_buffer_ prefix to README
      selftests/bpf: fix test_attach_probe map definition

Arnd Bergmann (1):
      bpf: avoid unused variable warning in tcp_bpf_rtt()

Daniel Borkmann (4):
      Merge branch 'bpf-libbpf-link-trace'
      Merge branch 'bpf-libbpf-int-btf-map'
      Merge branch 'bpf-libbpf-perf-rb-api'
      Merge branch 'bpf-sockaddr-wide-store'

Ilya Leoshkevich (1):
      selftests/bpf: fix test_reuseport_array on s390

Ilya Maximets (1):
      xdp: fix race on generic receive path

Jiri Olsa (1):
      tools: bpftool: Fix json dump crash on powerpc

Luke Nelson (1):
      bpf, riscv: Enable zext optimization for more RV64G ALU ops

Quentin Monnet (2):
      tools: bpftool: add "prog run" subcommand to test-run programs
      tools: bpftool: add completion for bpftool prog "loadall"

Stanislav Fomichev (5):
      selftests/bpf: fix test_align liveliness expectations
      selftests/bpf: add test_tcp_rtt to .gitignore
      bpf: allow wide (u64) aligned stores for some fields of bpf_sock_addr
      bpf: sync bpf.h to tools/
      selftests/bpf: add verifier tests for wide stores

YueHaibing (1):
      bpf: cgroup: Fix build error without CONFIG_NET

 arch/riscv/net/bpf_jit_comp.c                      |  16 +-
 include/linux/filter.h                             |   6 +
 include/net/tcp.h                                  |   4 +-
 include/net/xdp_sock.h                             |   2 +
 include/uapi/linux/bpf.h                           |   6 +-
 kernel/bpf/cgroup.c                                |   4 +
 net/core/filter.c                                  |  22 +-
 net/xdp/xsk.c                                      |  31 +-
 tools/bpf/bpftool/Documentation/bpftool-prog.rst   |  34 +
 tools/bpf/bpftool/bash-completion/bpftool          |  35 +-
 tools/bpf/bpftool/jit_disasm.c                     |  11 +-
 tools/bpf/bpftool/main.c                           |  29 +
 tools/bpf/bpftool/main.h                           |   1 +
 tools/bpf/bpftool/map_perf_ring.c                  | 201 ++---
 tools/bpf/bpftool/prog.c                           | 348 ++++++++-
 tools/include/linux/sizes.h                        |  48 ++
 tools/include/uapi/linux/bpf.h                     |   6 +-
 tools/lib/bpf/README.rst                           |   3 +-
 tools/lib/bpf/libbpf.c                             | 822 ++++++++++++++++++++-
 tools/lib/bpf/libbpf.h                             |  70 ++
 tools/lib/bpf/libbpf.map                           |  12 +-
 tools/lib/bpf/str_error.c                          |   2 +-
 tools/testing/selftests/bpf/.gitignore             |   1 +
 tools/testing/selftests/bpf/bpf_helpers.h          |   3 +
 .../selftests/bpf/prog_tests/attach_probe.c        | 166 +++++
 .../testing/selftests/bpf/prog_tests/perf_buffer.c | 100 +++
 .../selftests/bpf/prog_tests/stacktrace_build_id.c |  55 +-
 .../bpf/prog_tests/stacktrace_build_id_nmi.c       |  31 +-
 .../selftests/bpf/prog_tests/stacktrace_map.c      |  43 +-
 .../bpf/prog_tests/stacktrace_map_raw_tp.c         |  15 +-
 tools/testing/selftests/bpf/progs/bpf_flow.c       |  28 +-
 .../selftests/bpf/progs/get_cgroup_id_kern.c       |  26 +-
 tools/testing/selftests/bpf/progs/netcnt_prog.c    |  20 +-
 tools/testing/selftests/bpf/progs/pyperf.h         |  90 +--
 .../selftests/bpf/progs/socket_cookie_prog.c       |  13 +-
 .../selftests/bpf/progs/sockmap_verdict_prog.c     |  48 +-
 tools/testing/selftests/bpf/progs/strobemeta.h     |  68 +-
 .../selftests/bpf/progs/test_attach_probe.c        |  52 ++
 tools/testing/selftests/bpf/progs/test_btf_newkv.c |  13 +-
 .../selftests/bpf/progs/test_get_stack_rawtp.c     |  39 +-
 .../testing/selftests/bpf/progs/test_global_data.c |  37 +-
 tools/testing/selftests/bpf/progs/test_l4lb.c      |  65 +-
 .../selftests/bpf/progs/test_l4lb_noinline.c       |  65 +-
 .../testing/selftests/bpf/progs/test_map_in_map.c  |  30 +-
 tools/testing/selftests/bpf/progs/test_map_lock.c  |  26 +-
 tools/testing/selftests/bpf/progs/test_obj_id.c    |  12 +-
 .../testing/selftests/bpf/progs/test_perf_buffer.c |  25 +
 .../bpf/progs/test_select_reuseport_kern.c         |  67 +-
 .../selftests/bpf/progs/test_send_signal_kern.c    |  26 +-
 .../selftests/bpf/progs/test_sock_fields_kern.c    |  78 +-
 tools/testing/selftests/bpf/progs/test_spin_lock.c |  36 +-
 .../selftests/bpf/progs/test_stacktrace_build_id.c |  55 +-
 .../selftests/bpf/progs/test_stacktrace_map.c      |  52 +-
 .../testing/selftests/bpf/progs/test_tcp_estats.c  |  13 +-
 .../testing/selftests/bpf/progs/test_tcpbpf_kern.c |  26 +-
 .../selftests/bpf/progs/test_tcpnotify_kern.c      |  28 +-
 tools/testing/selftests/bpf/progs/test_xdp.c       |  26 +-
 tools/testing/selftests/bpf/progs/test_xdp_loop.c  |  26 +-
 .../selftests/bpf/progs/test_xdp_noinline.c        |  81 +-
 .../testing/selftests/bpf/progs/xdp_redirect_map.c |  12 +-
 tools/testing/selftests/bpf/progs/xdping_kern.c    |  12 +-
 tools/testing/selftests/bpf/test_align.c           |  16 +-
 tools/testing/selftests/bpf/test_maps.c            |  21 +-
 tools/testing/selftests/bpf/test_queue_stack_map.h |  30 +-
 tools/testing/selftests/bpf/test_sockmap_kern.h    | 110 +--
 tools/testing/selftests/bpf/test_verifier.c        |  17 +-
 tools/testing/selftests/bpf/verifier/wide_store.c  |  36 +
 67 files changed, 2490 insertions(+), 1062 deletions(-)
 create mode 100644 tools/include/linux/sizes.h
 create mode 100644 tools/testing/selftests/bpf/prog_tests/attach_probe.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_buffer.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_attach_probe.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_perf_buffer.c
 create mode 100644 tools/testing/selftests/bpf/verifier/wide_store.c

^ permalink raw reply

* Re: [PATCH bpf v2] xdp: fix race on generic receive path
From: Daniel Borkmann @ 2019-07-09  0:13 UTC (permalink / raw)
  To: Ilya Maximets, netdev
  Cc: linux-kernel, bpf, xdp-newbies, David S. Miller,
	Björn Töpel, Magnus Karlsson, Jonathan Lemon,
	Jakub Kicinski, Alexei Starovoitov
In-Reply-To: <20190703120916.19973-1-i.maximets@samsung.com>

On 07/03/2019 02:09 PM, Ilya Maximets wrote:
> Unlike driver mode, generic xdp receive could be triggered
> by different threads on different CPU cores at the same time
> leading to the fill and rx queue breakage. For example, this
> could happen while sending packets from two processes to the
> first interface of veth pair while the second part of it is
> open with AF_XDP socket.
> 
> Need to take a lock for each generic receive to avoid race.
> 
> Fixes: c497176cb2e4 ("xsk: add Rx receive functions and poll support")
> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>

Applied, thanks!

^ permalink raw reply

* Re: [PATCH bpf-next] selftests/bpf: fix test_reuseport_array on s390
From: Daniel Borkmann @ 2019-07-09  0:12 UTC (permalink / raw)
  To: Ilya Leoshkevich, bpf, netdev
In-Reply-To: <20190703115034.53984-1-iii@linux.ibm.com>

On 07/03/2019 01:50 PM, Ilya Leoshkevich wrote:
> Fix endianness issue: passing a pointer to 64-bit fd as a 32-bit key
> does not work on big-endian architectures. So cast fd to 32-bits when
> necessary.
> 
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>

Applied, thanks!

^ permalink raw reply

* Re: [PATCH bpf-next v3 1/6] xsk: replace ndo_xsk_async_xmit with ndo_xsk_wakeup
From: Daniel Borkmann @ 2019-07-08 23:40 UTC (permalink / raw)
  To: Magnus Karlsson, bjorn.topel, ast, netdev, brouer
  Cc: bpf, bruce.richardson, ciara.loftus, jakub.kicinski, xiaolong.ye,
	qi.z.zhang, maximmi, sridhar.samudrala, kevin.laatz,
	ilias.apalodimas, kiran.patil, axboe, maciej.fijalkowski,
	maciejromanfijalkowski, intel-wired-lan
In-Reply-To: <1562244134-19069-2-git-send-email-magnus.karlsson@intel.com>

On 07/04/2019 02:42 PM, Magnus Karlsson wrote:
> This commit replaces ndo_xsk_async_xmit with ndo_xsk_wakeup. This new
> ndo provides the same functionality as before but with the addition of
> a new flags field that is used to specifiy if Rx, Tx or both should be
> woken up. The previous ndo only woke up Tx, as implied by the
> name. The i40e and ixgbe drivers (which are all the supported ones)
> are updated with this new interface.
> 
> This new ndo will be used by the new need_wakeup functionality of XDP
> sockets that need to be able to wake up both Rx and Tx driver
> processing.
> 
> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c          |  5 +++--
>  drivers/net/ethernet/intel/i40e/i40e_xsk.c           |  7 ++++---
>  drivers/net/ethernet/intel/i40e/i40e_xsk.h           |  2 +-
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c        |  5 +++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h |  2 +-
>  drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c         |  4 ++--
>  drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c  |  2 +-
>  drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.h  |  2 +-
>  drivers/net/ethernet/mellanox/mlx5/core/en_main.c    |  2 +-
>  include/linux/netdevice.h                            | 14 ++++++++++++--
>  net/xdp/xdp_umem.c                                   |  3 +--
>  net/xdp/xsk.c                                        |  3 ++-
>  12 files changed, 32 insertions(+), 19 deletions(-)

Looks good, but given driver changes to support the AF_XDP need_wakeup
feature are quite trivial, is there a reason that you updated mlx5 here
but not for the actual support such that all three in-tree drivers are
supported?

Thanks,
Daniel

^ permalink raw reply

* Re: [PATCH net-next v2 0/3] net: Multipath hashing on inner L3
From: David Miller @ 2019-07-08 23:37 UTC (permalink / raw)
  To: ssuryaextr; +Cc: netdev, idosch, nikolay, dsahern
In-Reply-To: <20190706145519.13488-1-ssuryaextr@gmail.com>

From: Stephen Suryaputra <ssuryaextr@gmail.com>
Date: Sat,  6 Jul 2019 10:55:16 -0400

> This series extends commit 363887a2cdfe ("ipv4: Support multipath
> hashing on inner IP pkts for GRE tunnel") to include support when the
> outer L3 is IPv6 and to consider the case where the inner L3 is
> different version from the outer L3, such as IPv6 tunneled by IPv4 GRE
> or vice versa. It also includes kselftest scripts to test the use cases.
> 
> v2: Clarify the commit messages in the commits in this series to use the
>     term tunneled by IPv4 GRE or by IPv6 GRE so that it's clear which
>     one is the inner and which one is the outer (per David Miller).

Series applied, thanks.

^ permalink raw reply

* Re: [PATCH] net: pasemi: fix an use-after-free in pasemi_mac_phy_init()
From: David Miller @ 2019-07-08 23:33 UTC (permalink / raw)
  To: wen.yang99
  Cc: linux-kernel, xue.zhihong, wang.yi59, cheng.shengyu, tglx, mcgrof,
	mpe, netdev
In-Reply-To: <1562387021-951-1-git-send-email-wen.yang99@zte.com.cn>

From: Wen Yang <wen.yang99@zte.com.cn>
Date: Sat, 6 Jul 2019 12:23:41 +0800

> The phy_dn variable is still being used in of_phy_connect() after the
> of_node_put() call, which may result in use-after-free.
> 
> Fixes: 1dd2d06c0459 ("net: Rework pasemi_mac driver to use of_mdio infrastructure")
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>

Applied.

^ permalink raw reply

* Re: [PATCH] net: axienet: fix a potential double free in axienet_probe()
From: David Miller @ 2019-07-08 23:32 UTC (permalink / raw)
  To: wen.yang99
  Cc: linux-kernel, xue.zhihong, wang.yi59, cheng.shengyu, anirudh,
	John.Linn, michal.simek, hancock, netdev, linux-arm-kernel
In-Reply-To: <1562384321-46727-1-git-send-email-wen.yang99@zte.com.cn>

From: Wen Yang <wen.yang99@zte.com.cn>
Date: Sat, 6 Jul 2019 11:38:41 +0800

> There is a possible use-after-free issue in the axienet_probe():
> 
> 1701:	np = of_parse_phandle(pdev->dev.of_node, "axistream-connected", 0);
> 1702:   if (np) {
> ...
> 1787:		of_node_put(np); ---> released here
> 1788:		lp->eth_irq = platform_get_irq(pdev, 0);
> 1789:	} else {
> ...
> 1801:	}
> 1802:	if (IS_ERR(lp->dma_regs)) {
> ...
> 1805:		of_node_put(np); ---> double released here
> 1806:		goto free_netdev;
> 1807:	}
> 
> We solve this problem by removing the unnecessary of_node_put().
> 
> Fixes: 28ef9ebdb64c ("net: axienet: make use of axistream-connected attribute optional")
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>

Applied to net-next

^ permalink raw reply

* Re: [RFC PATCH net-next 0/6] tc-taprio offload for SJA1105 DSA
From: Vinicius Costa Gomes @ 2019-07-08 23:28 UTC (permalink / raw)
  To: Vladimir Oltean, f.fainelli, vivien.didelot, andrew, davem,
	vedang.patel, richardcochran
  Cc: weifeng.voon, jiri, m-karicheri2, Jose.Abreu, ilias.apalodimas,
	netdev, Vladimir Oltean
In-Reply-To: <20190707172921.17731-1-olteanv@gmail.com>

Hi Vladimir,

Vladimir Oltean <olteanv@gmail.com> writes:

> Using Vinicius Costa Gomes' configuration interface for 802.1Qbv (later
> resent by Voon Weifeng for the stmmac driver), I am submitting for
> review a draft implementation of this offload for a DSA switch.
>
> I don't want to insist too much on the hardware specifics of SJA1105
> which isn't otherwise very compliant to the IEEE spec.
>
> In order to be able to test with Vedang Patel's iproute2 patch for
> taprio offload (https://www.spinics.net/lists/netdev/msg573072.html)
> I had to actually revert the txtime-assist branch as it had changed the
> iproute2 interface.

Now, that Vedang's work was merged, I will send a rebased version of
the taprio offload series (also taking your feedback into account, see
below).

>
> In terms of impact for DSA drivers, I would like to point out that:
>
> - Maybe somebody should pre-populate qopt->cycle_time in case the user
>   does not provide one. Otherwise each driver needs to iterate over the
>   GCL once, just to set the cycle time (right now stmmac does as
> well).

Very fair, this should be very easy to do from taprio side.

>
> - Configuring the switch over SPI cannot apparently be done from this
>   ndo_setup_tc callback because it runs in atomic context. I also have
>   some downstream patches to offload tc clsact matchall with mirred
>   action, but in that case it looks like the atomic context restriction
>   does not apply.
>
> - I had to copy the struct tc_taprio_qopt_offload to driver private
>   memory because a static config needs to be constructed every time a
>   change takes place, and there are up to 4 switch ports that may take a
>   TAS configuration. I have created a private
>   tc_taprio_qopt_offload_copy() helper for this - I don't know whether
>   it's of any help in the general case.

If everyone needs to do this, perhaps we can think of something else,
one first idea is that taprio builds this configuration and gives
ownership of it to the driver, but we would need to add _ref()/_unref()
(or similar) helpers to the qdisc/driver API.

>
> There is more to be done however. The TAS needs to be integrated with
> the PTP driver. This is because with a PTP clock source, the base time
> is written dynamically to the PTPSCHTM (PTP schedule time) register and
> must be a time in the future. Then the "real" base time of each port's
> TAS config can be offset by at most ~50 ms (the DELTA field from the
> Schedule Entry Points Table) relative to PTPSCHTM.
> Because base times in the past are completely ignored by this hardware,
> we need to decide if it's ok behaviorally for a driver to "roll" a past
> base time into the immediate future by incrementally adding the cycle
> time (so the phase doesn't change).

That's another good piece of information. My understanding from reading
section 8.6.9.1.1 from the IEEE 802.1Q-2018 spec, is that it's ok:

	"""
	CycleStartTime = (OperBaseTime + N*OperCycleTime)
	where N is the smallest integer for which the relation:
	CycleStartTime >= CurrentTime
	would be TRUE.
	"""

> If it is, then decide by how long in
> the future it is ok to do so. Or alternatively, is it preferable if the
> driver errors out if the user-supplied base time is in the past and the
> hardware doesn't like it? But even then, there might be fringe cases
> when the base time becomes a past PTP time right as the driver tries to
> apply the config.

This fringe case is interesting. I don't know how to handle it well. The
first idea that comes to mind is for the driver to add a integer number
of cycles so there's enough time to apply the config. But this I think
will be different for every driver, no?

> Also applying a tc-taprio offload to a second SJA1105 switch port will
> inevitably need to roll the first port's (now past) base time into an
> equivalent future time.
> All of this is going to be complicated even further by the fact that
> resetting the switch (to apply the tc-taprio offload) makes it reset its
> PTP time.

This is going to be complicated indeed.


Thanks a lot,
--
Vinicius

^ permalink raw reply

* Re: [PATCH] sunrpc/cache: remove the exporting of cache_seq_next
From: J. Bruce Fields @ 2019-07-08 23:23 UTC (permalink / raw)
  To: Denis Efremov
  Cc: Trond Myklebust, Chuck Lever, Anna Schumaker, David S. Miller,
	linux-nfs, netdev, linux-kernel
In-Reply-To: <20190708161423.31006-1-efremov@linux.com>

Makes sense, thanks; apply for 5.3.--b.

On Mon, Jul 08, 2019 at 07:14:23PM +0300, Denis Efremov wrote:
> The function cache_seq_next is declared static and marked
> EXPORT_SYMBOL_GPL, which is at best an odd combination. Because the
> function is not used outside of the net/sunrpc/cache.c file it is
> defined in, this commit removes the EXPORT_SYMBOL_GPL() marking.
> 
> Fixes: d48cf356a130 ("SUNRPC: Remove non-RCU protected lookup")
> Signed-off-by: Denis Efremov <efremov@linux.com>
> ---
>  net/sunrpc/cache.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index 66fbb9d2fba7..6f1528f271ee 100644
> --- a/net/sunrpc/cache.c
> +++ b/net/sunrpc/cache.c
> @@ -1375,7 +1375,6 @@ static void *cache_seq_next(struct seq_file *m, void *p, loff_t *pos)
>  				hlist_first_rcu(&cd->hash_table[hash])),
>  				struct cache_head, cache_list);
>  }
> -EXPORT_SYMBOL_GPL(cache_seq_next);
>  
>  void *cache_seq_start_rcu(struct seq_file *m, loff_t *pos)
>  	__acquires(RCU)
> -- 
> 2.21.0

^ permalink raw reply

* Re: [ovs-dev] [PATCH net-next] net: openvswitch: do not update max_headroom if new headroom is equal to old headroom
From: Gregory Rose @ 2019-07-08 23:22 UTC (permalink / raw)
  To: David Miller, ap420073; +Cc: dev, netdev, Pravin Shelar
In-Reply-To: <87bfb355-9ddf-c27b-c160-b3028a945a22@gmail.com>



On 7/8/2019 4:18 PM, Gregory Rose wrote:
> On 7/8/2019 4:08 PM, David Miller wrote:
>> From: Taehee Yoo <ap420073@gmail.com>
>> Date: Sat,  6 Jul 2019 01:08:09 +0900
>>
>>> When a vport is deleted, the maximum headroom size would be changed.
>>> If the vport which has the largest headroom is deleted,
>>> the new max_headroom would be set.
>>> But, if the new headroom size is equal to the old headroom size,
>>> updating routine is unnecessary.
>>>
>>> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
>> I'm not so sure about the logic here and I'd therefore like an OVS 
>> expert
>> to review this.
>
> I'll review and test it and get back.  Pravin may have input as well.
>

Err, adding Pravin.

- Greg

> Thanks,
>
> - Greg
>
>> Thanks.
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox