* Re: [PATCH net] tcp: Reset bytes_acked and bytes_received when disconnecting
From: David Miller @ 2019-07-09 2:30 UTC (permalink / raw)
To: cpaasch; +Cc: netdev, edumazet
In-Reply-To: <20190706231307.98483-1-cpaasch@apple.com>
From: Christoph Paasch <cpaasch@apple.com>
Date: Sat, 06 Jul 2019 16:13:07 -0700
> If an app is playing tricks to reuse a socket via tcp_disconnect(),
> bytes_acked/received needs to be reset to 0. Otherwise tcp_info will
> report the sum of the current and the old connection..
>
> Cc: Eric Dumazet <edumazet@google.com>
> Fixes: 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info")
> Fixes: bdd1f9edacb5 ("tcp: add tcpi_bytes_received to tcp_info")
> Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [net-next] bonding: fix value exported by Netlink for peer_notif_delay
From: David Miller @ 2019-07-09 2:30 UTC (permalink / raw)
To: vincent; +Cc: j.vosburgh, vfalico, andy, netdev
In-Reply-To: <20190706210108.15293-1-vincent@bernat.ch>
From: Vincent Bernat <vincent@bernat.ch>
Date: Sat, 6 Jul 2019 23:01:08 +0200
> IFLA_BOND_PEER_NOTIF_DELAY was set to the value of downdelay instead
> of peer_notif_delay. After this change, the correct value is exported.
>
> Fixes: 07a4ddec3ce9 ("bonding: add an option to specify a delay between peer notifications")
> Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 13/19] ionic: Add initial ethtool support
From: Andrew Lunn @ 2019-07-09 2:27 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev
In-Reply-To: <20190708192532.27420-14-snelson@pensando.io>
> +static int ionic_get_module_eeprom(struct net_device *netdev,
> + struct ethtool_eeprom *ee,
> + u8 *data)
> +{
> + struct lif *lif = netdev_priv(netdev);
> + struct ionic_dev *idev = &lif->ionic->idev;
> + struct xcvr_status *xcvr;
> + u32 len;
> +
> + /* copy the module bytes into data */
> + xcvr = &idev->port_info->status.xcvr;
> + len = min_t(u32, sizeof(xcvr->sprom), ee->len);
> + memcpy(data, xcvr->sprom, len);
Hi Shannon
This also looks odd. Where is the call into the firmware to get the
eeprom contents? Even though it is called 'eeprom', the data is not
static. It contains real time diagnostic values, temperature, transmit
power, receiver power, voltages etc.
> +
> + dev_dbg(&lif->netdev->dev, "notifyblock eid=0x%llx link_status=0x%x link_speed=0x%x link_down_cnt=0x%x\n",
> + lif->info->status.eid,
> + lif->info->status.link_status,
> + lif->info->status.link_speed,
> + lif->info->status.link_down_count);
> + dev_dbg(&lif->netdev->dev, " port_status id=0x%x status=0x%x speed=0x%x\n",
> + idev->port_info->status.id,
> + idev->port_info->status.status,
> + idev->port_info->status.speed);
> + dev_dbg(&lif->netdev->dev, " xcvr status state=0x%x phy=0x%x pid=0x%x\n",
> + xcvr->state, xcvr->phy, xcvr->pid);
> + dev_dbg(&lif->netdev->dev, " port_config state=0x%x speed=0x%x mtu=0x%x an_enable=0x%x fec_type=0x%x pause_type=0x%x loopback_mode=0x%x\n",
> + idev->port_info->config.state,
> + idev->port_info->config.speed,
> + idev->port_info->config.mtu,
> + idev->port_info->config.an_enable,
> + idev->port_info->config.fec_type,
> + idev->port_info->config.pause_type,
> + idev->port_info->config.loopback_mode);
It is a funny place to have all the debug code.
Andrew
^ permalink raw reply
* Re: [PATCH] coallocate socket_wq with socket itself
From: David Miller @ 2019-07-09 2:25 UTC (permalink / raw)
To: viro; +Cc: netdev
In-Reply-To: <20190705191416.GL17978@ZenIV.linux.org.uk>
From: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri, 5 Jul 2019 20:14:16 +0100
> socket->wq is assign-once, set when we are initializing both
> struct socket it's in and struct socket_wq it points to. As the
> matter of fact, the only reason for separate allocation was the
> ability to RCU-delay freeing of socket_wq. RCU-delaying the
> freeing of socket itself gets rid of that need, so we can just
> fold struct socket_wq into the end of struct socket and simplify
> the life both for sock_alloc_inode() (one allocation instead of
> two) and for tun/tap oddballs, where we used to embed struct socket
> and struct socket_wq into the same structure (now - embedding just
> the struct socket).
>
> Note that reference to struct socket_wq in struct sock does remain
> a reference - that's unchanged.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH] sockfs: switch to ->free_inode()
From: David Miller @ 2019-07-09 2:25 UTC (permalink / raw)
To: viro; +Cc: netdev
In-Reply-To: <20190705191322.GK17978@ZenIV.linux.org.uk>
From: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri, 5 Jul 2019 20:13:22 +0100
> we do have an RCU-delayed part there already (freeing the wq),
> so it's not like the pipe situation; moreover, it might be
> worth considering coallocating wq with the rest of struct sock_alloc.
> ->sk_wq in struct sock would remain a pointer as it is, but
> the object it normally points to would be coallocated with
> struct socket...
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Applied.
^ permalink raw reply
* Re: pull-request: bpf-next 2019-07-09
From: David Miller @ 2019-07-09 2:15 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev, bpf
In-Reply-To: <20190709001351.8848-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 9 Jul 2019 02:13:51 +0200
> The following pull-request contains BPF updates for your *net-next* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Pulled, thanks Daniel.
^ permalink raw reply
* Re: [PATCH v3 net-next 13/19] ionic: Add initial ethtool support
From: Andrew Lunn @ 2019-07-09 2:14 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev
In-Reply-To: <20190708192532.27420-14-snelson@pensando.io>
> +static int ionic_set_pauseparam(struct net_device *netdev,
> + struct ethtool_pauseparam *pause)
> +{
> + struct lif *lif = netdev_priv(netdev);
> + struct ionic *ionic = lif->ionic;
> + struct ionic_dev *idev = &lif->ionic->idev;
> +
> + u32 requested_pause;
> + u32 cur_autoneg;
> + int err;
> +
> + cur_autoneg = idev->port_info->config.an_enable ? AUTONEG_ENABLE :
> + AUTONEG_DISABLE;
> + if (pause->autoneg != cur_autoneg) {
> + netdev_info(netdev, "Please use 'ethtool -s ...' to change autoneg\n");
> + return -EOPNOTSUPP;
> + }
> +
> + /* change both at the same time */
> + requested_pause = PORT_PAUSE_TYPE_LINK;
> + if (pause->rx_pause)
> + requested_pause |= IONIC_PAUSE_F_RX;
> + if (pause->tx_pause)
> + requested_pause |= IONIC_PAUSE_F_TX;
> +
> + if (requested_pause == idev->port_info->config.pause_type)
> + return 0;
> +
> + idev->port_info->config.pause_type = requested_pause;
> +
> + mutex_lock(&ionic->dev_cmd_lock);
> + ionic_dev_cmd_port_pause(idev, requested_pause);
> + err = ionic_dev_cmd_wait(ionic, devcmd_timeout);
> + mutex_unlock(&ionic->dev_cmd_lock);
> + if (err)
> + return err;
Hi Shannon
I've no idea what the firmware black box is doing, but this looks
wrong.
pause->autoneg is about if the results of auto-neg should be used or
not. If false, just configure the MAC with the pause settings and you
are done. If the interface is being forced, so autoneg in general is
disabled, just configure the MAC and you are done.
If pause->autoneg is true and the interface is using auto-neg as a
whole, you pass the pause values to the PHY for it to advertise and
trigger an auto-neg. Once autoneg has completed, and the resolved
settings are available, the MAC is configured with the resolved
values.
Looking at this code, i don't see any difference between configuring
the MAC or configuring the PHY. I would expect pause->autoneg to be
part of requested_pause somehow, so the firmware knows what is should
do.
Andrew
^ permalink raw reply
* Re: [EXT] [PATCH net-next 07/16] qlge: Deduplicate rx buffer queue management
From: Benjamin Poirier @ 2019-07-09 2:10 UTC (permalink / raw)
To: Manish Chopra; +Cc: GR-Linux-NIC-Dev, netdev@vger.kernel.org
In-Reply-To: <DM6PR18MB2697AC678152A26AC676A1B2ABFD0@DM6PR18MB2697.namprd18.prod.outlook.com>
On 2019/06/27 10:02, Manish Chopra wrote:
> > while (curr_idx != clean_idx) {
> > - lbq_desc = &rx_ring->lbq[curr_idx];
> > + struct qlge_bq_desc *lbq_desc = &rx_ring-
> > >lbq.queue[curr_idx];
> >
> > if (lbq_desc->p.pg_chunk.offset == last_offset)
> > - pci_unmap_page(qdev->pdev, lbq_desc-
> > >p.pg_chunk.map,
> > + pci_unmap_page(qdev->pdev, lbq_desc->dma_addr,
> > ql_lbq_block_size(qdev),
> > PCI_DMA_FROMDEVICE);
>
> In this patch, lbq_desc->dma_addr points to offset in the page. So unmapping is broken within this patch.
> Would have been nicer to fix this in the same patch although it might have been taken care in next patches probably.
>
Indeed, thanks. The same applies in ql_get_curr_lchunk().
Replaced with the following for v2:
+ pci_unmap_page(qdev->pdev, lbq_desc->dma_addr -
+ last_offset, ql_lbq_block_size(qdev),
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next v2 4/4] qed*: Add devlink support for configuration attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-09 2:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem@davemloft.net, netdev@vger.kernel.org, Michal Kalderon,
Ariel Elior, Jiri Pirko
In-Reply-To: <20190708144706.46ad7a50@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Tuesday, July 9, 2019 3:17 AM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Michal Kalderon
> <mkalderon@marvell.com>; Ariel Elior <aelior@marvell.com>; Jiri Pirko
> <jiri@resnulli.us>
> Subject: Re: [EXT] Re: [PATCH net-next v2 4/4] qed*: Add devlink support for
> configuration attributes.
>
> On Mon, 8 Jul 2019 02:31:15 +0000, Sudarsana Reddy Kalluru wrote:
> > > > > > + Type: u8
> > > > > > + Configuration mode: Permanent
> > > > > > +
> > > > > > +dcbx_mode [PORT, DRIVER-SPECIFIC]
> > > > > > + Configure DCBX mode for the device.
> > > > > > + Supported dcbx modes are,
> > > > > > + Disabled(0), IEEE(1), CEE(2) and
> > > > > > Dynamic(3)
> > > > > > + Type: u8
> > > > > > + Configuration mode: Permanent
> > > > >
> > > > > Why is this a permanent parameter?
> > > > >
> > > > This specifies the dcbx_mode to be configured in non-volatile memory.
> > > > The value is persistent and is used in the next load of OS or the mfw.
> > >
> > > And it can't be changed at runtime?
> >
> > Run time dcbx params are not affected via this interface, it only
> > updates config on permanent storage of the port.
>
> IOW it affects the defaults after boot? It'd be preferable to have the DCB
> uAPI handle "persistent"/default settings if that's the case.
Yes, it's effective after the reboot. Thanks for your suggestion.
^ permalink raw reply
* 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
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