* Re: [PATCH net-next 0/7] Devlink health updates
From: Jiri Pirko @ 2019-01-25 9:19 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: David Miller, netdev@vger.kernel.org, Jiri Pirko, Saeed Mahameed,
Moshe Shemesh
In-Reply-To: <8ba329b5-f550-2c3e-08d7-1094fbe4e6fb@mellanox.com>
Fri, Jan 25, 2019 at 10:16:16AM CET, eranbe@mellanox.com wrote:
>
>
>On 1/25/2019 8:08 AM, David Miller wrote:
>> From: Jiri Pirko <jiri@resnulli.us>
>> Date: Tue, 22 Jan 2019 17:58:21 +0100
>>
>>> Tue, Jan 22, 2019 at 04:57:17PM CET, eranbe@mellanox.com wrote:
>>>> This patchset fixes some comments that were received for the devlink
>>>> health series, mostly around the devlink health buffers API.
>>>>
>>>> It offers a new devlink<->driver API for passing health dump and diagnose info.
>>>> As part of this patchset, the new API is developed and integrated into the
>>>> devlink health and mlx5e TX reporter.
>>>> Also, added some helpers together with the new API, which reduce the code
>>>> required by the driver to fill dump and diagnose significantly.
>>>>
>>>> Eventually, it also deletes the old API.
>>>>
>>>> In addition, it includes some small fixes in the devlink and mlx5e TX reporter.
>>>
>>> Okay, just leaving, going to review this tomorrow. I would much rather
>>> review the patchset from the beginning, not this incremental patchset.
>>> It changes a lot of things, deprecating api what was just introduced.
>>> Review nightmare :/
>>>
>>> Could we do revert, repost? For my health sakes :)
>>
>> Eran are you ok with the revert?
>
>Dave, thanks for your consideration.
>
>During the review of this fixes series with Jiri yesterday, we reached
>to a conclusion that it would be cleaner to revert and re-post it again.
>I thought I shall submit a revert patchset, but if just remove it, it
>would be better, I guess.
>
>Jiri,
>I will probably be able to provide a new version with fixed comments
>from here soon next week.
Good. Thanks!
>
>>
>> I'll do it once I have Eran's confirmation.
>
>Note that you will also have to revert ARM compilation fix which was
>accepted on top.
>https://patchwork.ozlabs.org/patch/1029047/
>
>Thanks.
^ permalink raw reply
* [PATCH net-next v2 2/2] net: dsa: mv88e6xxx: Add suspend to RAM support
From: Miquel Raynal @ 2019-01-25 9:55 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller
Cc: netdev, linux-kernel, Thomas Petazzoni, Gregory Clement,
Antoine Tenart, Maxime Chevallier, Nadav Haklai, Miquel Raynal
In-Reply-To: <20190125095507.29334-1-miquel.raynal@bootlin.com>
Bring S2RAM support to the mv88e6xxx DSA driver.
The content of the *_irq_poll() helper is moved in *_do_irq_poll() so
that that the function can be called from the ->resume() callback
without using the *work pointer.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Changes since v1:
=================
* Added the logic to replay rules.
* Did not add any port_disable/enable() calls as this will be taken
care of by Vivien's patches.
drivers/net/dsa/mv88e6xxx/chip.c | 89 ++++++++++++++++++++++++++++++--
1 file changed, 86 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 428177f80abd..e83c02aaca49 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -547,15 +547,21 @@ static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
return err;
}
+static void mv88e6xxx_do_irq_poll(struct mv88e6xxx_chip *chip)
+{
+ mv88e6xxx_g1_irq_thread_work(chip);
+
+ kthread_queue_delayed_work(chip->kworker, &chip->irq_poll_work,
+ msecs_to_jiffies(100));
+}
+
static void mv88e6xxx_irq_poll(struct kthread_work *work)
{
struct mv88e6xxx_chip *chip = container_of(work,
struct mv88e6xxx_chip,
irq_poll_work.work);
- mv88e6xxx_g1_irq_thread_work(chip);
- kthread_queue_delayed_work(chip->kworker, &chip->irq_poll_work,
- msecs_to_jiffies(100));
+ mv88e6xxx_do_irq_poll(chip);
}
static int mv88e6xxx_irq_poll_setup(struct mv88e6xxx_chip *chip)
@@ -4855,6 +4861,82 @@ static const void *pdata_device_get_match_data(struct device *dev)
return NULL;
}
+static int __maybe_unused mv88e6xxx_suspend(struct device *dev)
+{
+ struct dsa_switch *ds = dev_get_drvdata(dev);
+ struct mv88e6xxx_chip *chip = ds->priv;
+
+ kthread_cancel_delayed_work_sync(&chip->irq_poll_work);
+
+ return dsa_switch_suspend(ds);
+}
+
+static int __maybe_unused mv88e6xxx_resume(struct device *dev)
+{
+ struct dsa_switch *ds = dev_get_drvdata(dev);
+ struct mv88e6xxx_chip *chip = ds->priv;
+ struct mv88e6xxx_rule *rule;
+ int ret;
+
+ mv88e6xxx_phy_init(chip);
+
+ mutex_lock(&chip->reg_lock);
+ ret = mv88e6xxx_switch_reset(chip);
+ mutex_unlock(&chip->reg_lock);
+ if (ret) {
+ dev_err(dev, "Failed to reset the switch\n");
+ return ret;
+ }
+
+ ret = mv88e6xxx_setup(ds);
+ if (ret) {
+ dev_err(dev, "Failed to setup the switch\n");
+ return ret;
+ }
+
+ mv88e6xxx_do_irq_poll(chip);
+
+ list_for_each_entry(rule, &chip->rules, node) {
+ switch (rule->type) {
+ case FDB_RULE:
+ ret = _mv88e6xxx_port_fdb_add(chip, rule->port,
+ rule->params.db.addr,
+ rule->params.db.vid);
+ break;
+ case MDB_RULE:
+ ret = _mv88e6xxx_port_mdb_add(chip, rule->port,
+ rule->params.db.addr,
+ rule->params.db.vid);
+ break;
+ case VLAN_RULE:
+ ret = _mv88e6xxx_port_vlan_add(chip, rule->port,
+ &rule->params.vlan);
+ break;
+ case BRIDGE_RULE:
+ ret = _mv88e6xxx_port_bridge_join(chip, rule->port,
+ rule->params.br);
+ break;
+ case CC_BRIDGE_RULE:
+ ret = _mv88e6xxx_crosschip_bridge_join(chip,
+ rule->params.crosschip.dev,
+ rule->port,
+ rule->params.crosschip.br);
+ break;
+ default:
+ dev_warn(chip->dev, "Unknown rule type (%d)\n",
+ rule->type);
+ continue;
+ }
+
+ if (ret)
+ dev_warn(chip->dev, "Cannot re-apply rule\n");
+ }
+
+ return dsa_switch_resume(ds);
+}
+
+static SIMPLE_DEV_PM_OPS(mv88e6xxx_pm_ops, mv88e6xxx_suspend, mv88e6xxx_resume);
+
static int mv88e6xxx_probe(struct mdio_device *mdiodev)
{
struct dsa_mv88e6xxx_pdata *pdata = mdiodev->dev.platform_data;
@@ -5041,6 +5123,7 @@ static struct mdio_driver mv88e6xxx_driver = {
.mdiodrv.driver = {
.name = "mv88e6085",
.of_match_table = mv88e6xxx_of_match,
+ .pm = &mv88e6xxx_pm_ops,
},
};
--
2.19.1
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Miquel Raynal @ 2019-01-25 9:55 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller
Cc: netdev, linux-kernel, Thomas Petazzoni, Gregory Clement,
Antoine Tenart, Maxime Chevallier, Nadav Haklai, Miquel Raynal
In-Reply-To: <20190125095507.29334-1-miquel.raynal@bootlin.com>
The user might apply a specific switch configuration, with specific
forwarding rules, VLAN, bridges, etc.
During suspend to RAM the switch power will be turned off and the
switch will lost its configuration. In an attempt to bring S2RAM
support to the mv88e6xxx DSA, let's first save these rules in a
per-chip list thanks to the mv88e6xxx_add/del_xxx_rule()
helpers. These helpers are then called from various callbacks:
* mv88e6xxx_port_fdb_add/del()
* mv88e6xxx_port_mdb_add/del()
* mv88e6xxx_port_vlan_add/del()
* mv88e6xxx_port_bridge_join/leave()
* mv88e6xxx_crosschip_bridge_join/leave()
To avoid recursion problems when replaying the rules, the content of
the above *_add()/*_join() callbacks has been moved in separate
helpers with a '_' prefix. Hence, each callback just calls the
corresponding helper and the corresponding *_add_xxx_rule().
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Changes since v1:
=================
* New patch: saves the forwarding/vlan/bridge rules when they are
applied in a list. This way in the second patch when adding S2RAM
support, we just need to replay these rules.
drivers/net/dsa/mv88e6xxx/chip.c | 270 +++++++++++++++++++++++++++----
drivers/net/dsa/mv88e6xxx/chip.h | 33 ++++
2 files changed, 271 insertions(+), 32 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 8a517d8fb9d1..428177f80abd 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -52,6 +52,111 @@ static void assert_reg_lock(struct mv88e6xxx_chip *chip)
}
}
+static void mv88e6xxx_add_rule(struct mv88e6xxx_chip *chip, int port,
+ enum mv88e6xxx_rule_type type,
+ const unsigned char *addr, u16 vid,
+ const struct switchdev_obj_port_vlan *vlan,
+ int dev, struct net_device *br)
+{
+ struct mv88e6xxx_rule *rule;
+
+ rule = kzalloc(sizeof(*rule), GFP_KERNEL);
+ if (!rule)
+ return;
+
+ rule->port = port;
+ rule->type = type;
+ switch (type) {
+ case FDB_RULE:
+ case MDB_RULE:
+ ether_addr_copy(rule->params.db.addr, addr);
+ rule->params.db.vid = vid;
+ break;
+ case VLAN_RULE:
+ rule->params.vlan = *vlan;
+ break;
+ case BRIDGE_RULE:
+ rule->params.br = br;
+ break;
+ case CC_BRIDGE_RULE:
+ rule->params.crosschip.dev = dev;
+ rule->params.crosschip.br = br;
+ break;
+ }
+
+ list_add_tail(&rule->node, &chip->rules);
+}
+
+static void mv88e6xxx_del_rule(struct mv88e6xxx_chip *chip, int port,
+ enum mv88e6xxx_rule_type type,
+ const unsigned char *addr, u16 vid,
+ const struct switchdev_obj_port_vlan *vlan,
+ int dev, struct net_device *br)
+{
+ struct mv88e6xxx_rule *rule, *next;
+
+ list_for_each_entry_safe(rule, next, &chip->rules, node) {
+ if (rule->port != port || rule->type != type)
+ continue;
+
+ switch (type) {
+ case FDB_RULE:
+ case MDB_RULE:
+ if (!memcmp(rule->params.db.addr, addr, ETH_ALEN) &&
+ rule->params.db.vid == vid)
+ goto found;
+ break;
+ case VLAN_RULE:
+ if (rule->params.vlan.flags == vlan->flags &&
+ rule->params.vlan.vid_begin == vlan->vid_begin &&
+ rule->params.vlan.vid_end == vlan->vid_end)
+ goto found;
+ break;
+ case BRIDGE_RULE:
+ if (rule->params.br == br)
+ goto found;
+ break;
+ case CC_BRIDGE_RULE:
+ if (rule->params.crosschip.br == br &&
+ rule->params.crosschip.dev == dev)
+ goto found;
+ break;
+ default:
+ dev_warn(chip->dev, "Unknown rule type\n");
+ break;
+ }
+ }
+
+ dev_info(chip->dev, "Cannot delete rule: not found\n");
+
+ return;
+
+found:
+ list_del(&rule->node);
+ kfree(rule);
+}
+
+#define mv88e6xxx_add_fdb_rule(chip, port, addr, vid) \
+ mv88e6xxx_add_rule(chip, port, FDB_RULE, addr, vid, NULL, 0, NULL)
+#define mv88e6xxx_del_fdb_rule(chip, port, addr, vid) \
+ mv88e6xxx_del_rule(chip, port, FDB_RULE, addr, vid, NULL, 0, NULL)
+#define mv88e6xxx_add_mdb_rule(chip, port, addr, vid) \
+ mv88e6xxx_add_rule(chip, port, MDB_RULE, addr, vid, NULL, 0, NULL)
+#define mv88e6xxx_del_mdb_rule(chip, port, addr, vid) \
+ mv88e6xxx_del_rule(chip, port, MDB_RULE, addr, vid, NULL, 0, NULL)
+#define mv88e6xxx_add_vlan_rule(chip, port, vlan) \
+ mv88e6xxx_add_rule(chip, port, VLAN_RULE, NULL, 0, vlan, 0, NULL)
+#define mv88e6xxx_del_vlan_rule(chip, port, vlan) \
+ mv88e6xxx_del_rule(chip, port, VLAN_RULE, NULL, 0, vlan, 0, NULL)
+#define mv88e6xxx_add_bridge_rule(chip, port, br) \
+ mv88e6xxx_add_rule(chip, port, BRIDGE_RULE, NULL, 0, NULL, 0, br)
+#define mv88e6xxx_del_bridge_rule(chip, port, br) \
+ mv88e6xxx_del_rule(chip, port, BRIDGE_RULE, NULL, 0, NULL, 0, br)
+#define mv88e6xxx_add_cc_bridge_rule(chip, port, dev, br) \
+ mv88e6xxx_add_rule(chip, port, CC_BRIDGE_RULE, NULL, 0, NULL, dev, br)
+#define mv88e6xxx_del_cc_bridge_rule(chip, port, dev, br) \
+ mv88e6xxx_del_rule(chip, port, CC_BRIDGE_RULE, NULL, 0, NULL, dev, br)
+
/* The switch ADDR[4:1] configuration pins define the chip SMI device address
* (ADDR[0] is always zero, thus only even SMI addresses can be strapped).
*
@@ -1674,8 +1779,8 @@ static int mv88e6xxx_broadcast_setup(struct mv88e6xxx_chip *chip, u16 vid)
return 0;
}
-static int _mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
- u16 vid, u8 member)
+static int __mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
+ u16 vid, u8 member)
{
struct mv88e6xxx_vtu_entry vlan;
int err;
@@ -1693,19 +1798,19 @@ static int _mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
return mv88e6xxx_broadcast_setup(chip, vid);
}
-static void mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
+static int _mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
const struct switchdev_obj_port_vlan *vlan)
{
- struct mv88e6xxx_chip *chip = ds->priv;
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
u8 member;
u16 vid;
+ int err;
if (!chip->info->max_vid)
- return;
+ return -EINVAL;
- if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
+ if (dsa_is_dsa_port(chip->ds, port) || dsa_is_cpu_port(chip->ds, port))
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED;
else if (untagged)
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNTAGGED;
@@ -1714,16 +1819,37 @@ static void mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
mutex_lock(&chip->reg_lock);
- for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid)
- if (_mv88e6xxx_port_vlan_add(chip, port, vid, member))
- dev_err(ds->dev, "p%d: failed to add VLAN %d%c\n", port,
- vid, untagged ? 'u' : 't');
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
+ err = __mv88e6xxx_port_vlan_add(chip, port, vid, member);
+ if (err) {
+ dev_err(chip->dev, "p%d: failed to add VLAN %d%c\n",
+ port, vid, untagged ? 'u' : 't');
+ goto out;
+ }
+ }
- if (pvid && mv88e6xxx_port_set_pvid(chip, port, vlan->vid_end))
- dev_err(ds->dev, "p%d: failed to set PVID %d\n", port,
- vlan->vid_end);
+ if (pvid) {
+ err = mv88e6xxx_port_set_pvid(chip, port, vlan->vid_end);
+ if (err)
+ dev_err(chip->dev, "p%d: failed to set PVID %d\n",
+ port, vlan->vid_end);
+ }
+out:
mutex_unlock(&chip->reg_lock);
+
+ return err;
+}
+
+static void mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_vlan *vlan)
+{
+ struct mv88e6xxx_chip *chip = ds->priv;
+
+ if (_mv88e6xxx_port_vlan_add(chip, port, vlan))
+ return;
+
+ mv88e6xxx_add_vlan_rule(chip, port, vlan);
}
static int _mv88e6xxx_port_vlan_del(struct mv88e6xxx_chip *chip,
@@ -1769,6 +1895,8 @@ static int mv88e6xxx_port_vlan_del(struct dsa_switch *ds, int port,
if (!chip->info->max_vid)
return -EOPNOTSUPP;
+ mv88e6xxx_del_vlan_rule(chip, port, vlan);
+
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_port_get_pvid(chip, port, &pvid);
@@ -1793,10 +1921,9 @@ static int mv88e6xxx_port_vlan_del(struct dsa_switch *ds, int port,
return err;
}
-static int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
- const unsigned char *addr, u16 vid)
+static int _mv88e6xxx_port_fdb_add(struct mv88e6xxx_chip *chip, int port,
+ const unsigned char *addr, u16 vid)
{
- struct mv88e6xxx_chip *chip = ds->priv;
int err;
mutex_lock(&chip->reg_lock);
@@ -1807,12 +1934,29 @@ static int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
return err;
}
+static int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid)
+{
+ struct mv88e6xxx_chip *chip = ds->priv;
+ int err;
+
+ err = _mv88e6xxx_port_fdb_add(chip, port, addr, vid);
+ if (err)
+ return err;
+
+ mv88e6xxx_add_fdb_rule(chip, port, addr, vid);
+
+ return 0;
+}
+
static int mv88e6xxx_port_fdb_del(struct dsa_switch *ds, int port,
const unsigned char *addr, u16 vid)
{
struct mv88e6xxx_chip *chip = ds->priv;
int err;
+ mv88e6xxx_del_fdb_rule(chip, port, addr, vid);
+
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_port_db_load_purge(chip, port, addr, vid,
MV88E6XXX_G1_ATU_DATA_STATE_UNUSED);
@@ -1945,31 +2089,68 @@ static int mv88e6xxx_bridge_map(struct mv88e6xxx_chip *chip,
return 0;
}
+static int _mv88e6xxx_port_bridge_join(struct mv88e6xxx_chip *chip, int port,
+ struct net_device *br)
+{
+ int err;
+
+ mutex_lock(&chip->reg_lock);
+ err = mv88e6xxx_bridge_map(chip, br);
+ mutex_unlock(&chip->reg_lock);
+
+ return err;
+}
+
static int mv88e6xxx_port_bridge_join(struct dsa_switch *ds, int port,
struct net_device *br)
{
struct mv88e6xxx_chip *chip = ds->priv;
int err;
- mutex_lock(&chip->reg_lock);
- err = mv88e6xxx_bridge_map(chip, br);
- mutex_unlock(&chip->reg_lock);
+ err = _mv88e6xxx_port_bridge_join(chip, port, br);
+ if (err)
+ return err;
- return err;
+ mv88e6xxx_add_bridge_rule(chip, port, br);
+
+ return 0;
}
static void mv88e6xxx_port_bridge_leave(struct dsa_switch *ds, int port,
struct net_device *br)
{
struct mv88e6xxx_chip *chip = ds->priv;
+ int err;
+
+ mv88e6xxx_del_bridge_rule(chip, port, br);
mutex_lock(&chip->reg_lock);
- if (mv88e6xxx_bridge_map(chip, br) ||
- mv88e6xxx_port_vlan_map(chip, port))
+ err = mv88e6xxx_bridge_map(chip, br);
+ if (!err)
+ err = mv88e6xxx_port_vlan_map(chip, port);
+
+ if (err)
dev_err(ds->dev, "failed to remap in-chip Port VLAN\n");
+
mutex_unlock(&chip->reg_lock);
}
+static int _mv88e6xxx_crosschip_bridge_join(struct mv88e6xxx_chip *chip,
+ int dev, int port,
+ struct net_device *br)
+{
+ int err;
+
+ if (!mv88e6xxx_has_pvt(chip))
+ return 0;
+
+ mutex_lock(&chip->reg_lock);
+ err = mv88e6xxx_pvt_map(chip, dev, port);
+ mutex_unlock(&chip->reg_lock);
+
+ return err;
+}
+
static int mv88e6xxx_crosschip_bridge_join(struct dsa_switch *ds, int dev,
int port, struct net_device *br)
{
@@ -1979,11 +2160,13 @@ static int mv88e6xxx_crosschip_bridge_join(struct dsa_switch *ds, int dev,
if (!mv88e6xxx_has_pvt(chip))
return 0;
- mutex_lock(&chip->reg_lock);
- err = mv88e6xxx_pvt_map(chip, dev, port);
- mutex_unlock(&chip->reg_lock);
+ err = _mv88e6xxx_crosschip_bridge_join(chip, dev, port, br);
+ if (err)
+ return err;
- return err;
+ mv88e6xxx_add_cc_bridge_rule(chip, port, dev, br);
+
+ return 0;
}
static void mv88e6xxx_crosschip_bridge_leave(struct dsa_switch *ds, int dev,
@@ -1994,6 +2177,8 @@ static void mv88e6xxx_crosschip_bridge_leave(struct dsa_switch *ds, int dev,
if (!mv88e6xxx_has_pvt(chip))
return;
+ mv88e6xxx_del_cc_bridge_rule(chip, port, dev, br);
+
mutex_lock(&chip->reg_lock);
if (mv88e6xxx_pvt_map(chip, dev, port))
dev_err(ds->dev, "failed to remap cross-chip Port VLAN\n");
@@ -4534,17 +4719,34 @@ static int mv88e6xxx_port_mdb_prepare(struct dsa_switch *ds, int port,
return 0;
}
+static int _mv88e6xxx_port_mdb_add(struct mv88e6xxx_chip *chip, int port,
+ const unsigned char *addr, u16 vid)
+{
+ int err;
+
+ mutex_lock(&chip->reg_lock);
+ err = mv88e6xxx_port_db_load_purge(chip, port, addr, vid,
+ MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC);
+ mutex_unlock(&chip->reg_lock);
+
+ if (err)
+ dev_err(chip->dev,
+ "p%d: failed to load multicast MAC address\n", port);
+
+ return err;
+}
+
static void mv88e6xxx_port_mdb_add(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_mdb *mdb)
{
struct mv88e6xxx_chip *chip = ds->priv;
+ int err;
- mutex_lock(&chip->reg_lock);
- if (mv88e6xxx_port_db_load_purge(chip, port, mdb->addr, mdb->vid,
- MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC))
- dev_err(ds->dev, "p%d: failed to load multicast MAC address\n",
- port);
- mutex_unlock(&chip->reg_lock);
+ err = _mv88e6xxx_port_mdb_add(chip, port, mdb->addr, mdb->vid);
+ if (err)
+ return;
+
+ mv88e6xxx_add_mdb_rule(chip, port, mdb->addr, mdb->vid);
}
static int mv88e6xxx_port_mdb_del(struct dsa_switch *ds, int port,
@@ -4553,6 +4755,8 @@ static int mv88e6xxx_port_mdb_del(struct dsa_switch *ds, int port,
struct mv88e6xxx_chip *chip = ds->priv;
int err;
+ mv88e6xxx_del_mdb_rule(chip, port, mdb->addr, mdb->vid);
+
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_port_db_load_purge(chip, port, mdb->addr, mdb->vid,
MV88E6XXX_G1_ATU_DATA_STATE_UNUSED);
@@ -4766,6 +4970,8 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
if (err)
goto out_mdio;
+ INIT_LIST_HEAD(&chip->rules);
+
return 0;
out_mdio:
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index f9ecb7872d32..b5c8d6a8d9e7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -203,6 +203,36 @@ struct mv88e6xxx_port {
int serdes_irq;
};
+enum mv88e6xxx_rule_type {
+ FDB_RULE,
+ MDB_RULE,
+ VLAN_RULE,
+ BRIDGE_RULE,
+ CC_BRIDGE_RULE,
+};
+
+struct mv88e6xxx_db_rule {
+ u8 addr[ETH_ALEN];
+ u16 vid;
+};
+
+struct mv88e6xxx_br_rule {
+ int dev;
+ struct net_device *br;
+};
+
+struct mv88e6xxx_rule {
+ int port;
+ enum mv88e6xxx_rule_type type;
+ union {
+ struct mv88e6xxx_db_rule db;
+ struct switchdev_obj_port_vlan vlan;
+ struct net_device *br;
+ struct mv88e6xxx_br_rule crosschip;
+ } params;
+ struct list_head node;
+};
+
struct mv88e6xxx_chip {
const struct mv88e6xxx_info *info;
@@ -285,6 +315,9 @@ struct mv88e6xxx_chip {
/* Array of port structures. */
struct mv88e6xxx_port ports[DSA_MAX_PORTS];
+
+ /* List of bridging rules to recover at resume */
+ struct list_head rules;
};
struct mv88e6xxx_bus_ops {
--
2.19.1
^ permalink raw reply related
* [PATCH net-next v2 0/2] mv88e6xxx DSA suspend to RAM support
From: Miquel Raynal @ 2019-01-25 9:55 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller
Cc: netdev, linux-kernel, Thomas Petazzoni, Gregory Clement,
Antoine Tenart, Maxime Chevallier, Nadav Haklai, Miquel Raynal
After a first attempt of bringing S2RAM support to the DSA switch, it
has been reported that a part of the configuration was lost during the
cycle. This second version adds a first patch that saves the rules in
a per-chip list when they are applied, so that in the second patch we
bring S2RAM support by also re-applying these rules.
Bridging is set up on the EspressoBin with the below commands (thanks
to Andrew):
ip link set eth0 up
ip link add name br0 type bridge
ip link set br0 up
ip link set lan0 up
ip link set lan0 master br0
ip link set lan1 up
ip link set lan1 master br0
Static forwarding entries are added:
bridge fdb add 00:42:42:42:42:42 dev lan0
bridge fdb add 00:24:24:24:24:24 dev lan1
Dumping the switch entries gives:
# bridge fdb show
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:ff:06:e2:95 dev eth0 self permanent
dc:0b:34:87:7f:27 dev lan0 br0
d4:81:d7:4f:a1:0d dev lan0 br0
f0:ad:4e:06:e2:95 dev lan0 vlan 1 br0 permanent
f0:ad:4e:06:e2:95 dev lan0 br0 permanent
00:42:42:42:42:42 dev lan0 self static
d4:81:d7:4f:a1:0d dev lan0 self
dc:0b:34:87:7f:27 dev lan0 self
00:0a:35:00:01:22 dev lan1 br0
00:0a:35:00:01:22 dev lan1 self
00:24:24:24:24:24 dev lan1 self static
33:33:00:00:00:01 dev br0 self permanent
01:00:5e:00:00:01 dev br0 self permanent
33:33:ff:00:2a:68 dev br0 self permanent
After a S2RAM cycle, the bridge and the static entries have been restored.
mv88e6085 d0032004.mdio-mii:01 lan0: configuring for phy/ link mode
mv88e6085 d0032004.mdio-mii:01 lan1: configuring for phy/ link mode
mv88e6085 d0032004.mdio-mii:01 lan1: Link is Up - 1Gbps/Full - flow control rx/tx
mv88e6085 d0032004.mdio-mii:01 lan0: Link is Up - 1Gbps/Full - flow control rx/tx
# bridge fdb show
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:ff:06:e2:95 dev eth0 self permanent
9c:93:4e:26:e4:54 dev lan0 br0
d4:81:d7:45:de:60 dev lan0 br0
dc:0b:34:87:7f:27 dev lan0 br0
d4:81:d7:4f:a1:0d dev lan0 br0
f0:ad:4e:06:e2:95 dev lan0 vlan 1 br0 permanent
f0:ad:4e:06:e2:95 dev lan0 br0 permanent
00:42:42:42:42:42 dev lan0 self static
d4:81:d7:4f:a1:0d dev lan0 self
00:0a:35:00:01:22 dev lan1 br0
00:0a:35:00:01:22 dev lan1 self
00:24:24:24:24:24 dev lan1 self static
33:33:00:00:00:01 dev br0 self permanent
01:00:5e:00:00:01 dev br0 self permanent
33:33:ff:00:2a:68 dev br0 self permanent
An iperf test running over the whole cycle gives:
1.00-2.00 sec 81.7 MBytes 685 Mbits/sec
2.00-3.00 sec 81.8 MBytes 687 Mbits/sec
3.00-4.00 sec 81.8 MBytes 685 Mbits/sec
4.00-5.00 sec 81.7 MBytes 686 Mbits/sec
5.00-6.00 sec 81.5 MBytes 683 Mbits/sec
6.00-7.00 sec 81.6 MBytes 685 Mbits/sec
7.00-8.00 sec 81.5 MBytes 684 Mbits/sec
8.00-9.00 sec 81.7 MBytes 685 Mbits/sec
9.00-10.00 sec 81.5 MBytes 684 Mbits/sec
10.00-11.00 sec 81.6 MBytes 684 Mbits/sec
11.00-12.00 sec 81.5 MBytes 683 Mbits/sec
macb e000b000.ethernet eth0: link down
12.00-13.00 sec 19.5 MBytes 164 Mbits/sec
13.00-14.00 sec 0.00 Bytes 0.00 bits/sec
14.00-15.00 sec 0.00 Bytes 0.00 bits/sec
15.00-16.00 sec 0.00 Bytes 0.00 bits/sec
16.00-17.00 sec 0.00 Bytes 0.00 bits/sec
17.00-18.00 sec 0.00 Bytes 0.00 bits/sec
18.00-19.00 sec 0.00 Bytes 0.00 bits/sec
19.00-20.00 sec 0.00 Bytes 0.00 bits/sec
20.00-21.00 sec 0.00 Bytes 0.00 bits/sec
21.00-22.00 sec 0.00 Bytes 0.00 bits/sec
22.00-23.00 sec 0.00 Bytes 0.00 bits/sec
macb e000b000.ethernet eth0: link up (1000/Full)
23.00-24.00 sec 0.00 Bytes 0.00 bits/sec
24.00-25.00 sec 0.00 Bytes 0.00 bits/sec
25.00-26.00 sec 18.6 MBytes 156 Mbits/sec
26.00-27.00 sec 81.5 MBytes 684 Mbits/sec
27.00-28.00 sec 81.6 MBytes 684 Mbits/sec
28.00-29.00 sec 81.5 MBytes 684 Mbits/sec
29.00-30.00 sec 81.5 MBytes 683 Mbits/sec
30.00-31.00 sec 81.6 MBytes 685 Mbits/sec
31.00-32.00 sec 81.6 MBytes 684 Mbits/sec
32.00-33.00 sec 81.4 MBytes 683 Mbits/sec
33.00-34.00 sec 81.4 MBytes 683 Mbits/sec
33.00-34.00 sec 81.4 MBytes 683 Mbits/sec
I hope everything has been restored correctly, please let me know if
you spot anything else that is missing.
Thanks,
Miquèl
Miquel Raynal (2):
net: dsa: mv88e6xxx: Save switch rules
net: dsa: mv88e6xxx: Add suspend to RAM support
drivers/net/dsa/mv88e6xxx/chip.c | 359 ++++++++++++++++++++++++++++---
drivers/net/dsa/mv88e6xxx/chip.h | 33 +++
2 files changed, 357 insertions(+), 35 deletions(-)
--
2.19.1
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-25 9:59 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190124235857.xyb5xx2ufr6x5mbt@ast-mbp.dhcp.thefacebook.com>
On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > > - on architectures that don't support queued_spin_lock trivial lock is used.
> > > Note that arch_spin_lock cannot be used, since not all archs agree that
> > > zero == unlocked and sizeof(arch_spinlock_t) != sizeof(__u32).
> >
> > I really don't much like direct usage of qspinlock; esp. not as a
> > surprise.
> >
> > Why does it matter if 0 means unlocked; that's what
> > __ARCH_SPIN_LOCK_UNLOCKED is for.
> >
> > I get the sizeof(__u32) thing, but why not key off of that?
>
> what do you mean by 'key off of that' ?
> to use arch_spinlock_t instead of qspinlock ?
> That was my first attempt, but then I painfully found that
> its size on parisc is 16 bytes and we're not going to penalize bpf
> to waste that much space because of single architecture.
> sizeof(arch_spinlock_t) can be 1 byte too (on sparc).
PowerPC has 8 bytes for some config options IIRC.
> That would fit in __u32, but I figured it's cleaner to use qspinlock
> on all archs that support it and dumb_spin_lock on archs that dont.
>
> Another option is use to arch_spinlock_t when its sizeof==4
That's what I meant.
> and use dumb_spin_lock otherwise.
> It's doable, but imo still less clean than using qspinlock
> due to zero init. Since zero init is a lot less map work
> that zero inits all elements already.
>
> If arch_spinlock_t is used than at map init time we would need to
> walk all elements and do __ARCH_SPIN_LOCK_UNLOCKED assignment
> (and maps can have millions of elements).
> Not horrible, but 100% waste of cycles for x86/arm64 where qspinlock
> is used. Such waste can be workaround further by doing ugly
> #idef __ARCH_SPIN_LOCK_UNLOCKED == 0 -> don't do init loop.
> And then add another #ifdef for archs with sizeof(arch_spinlock_t)!=4
> to keep zero init for all map types that support bpf_spin_lock
> via dumb_spin_lock.
> Clearly at that point we're getting into ugliness everywhere.
> Hence I've used qspinlock directly.
OK; I see.. but do these locks really have enough contention to run into
trouble with the simple test-and-set lock?
[ I tried to propose a simple ticket lock, but then realized the virt
archs (s390,powerpc,etc.) would hate that and deleted everything again
]
Argh, what a mess..
^ permalink raw reply
* Re: [PATCH iproute2-next] Introduce ip-brctl shell script
From: Stefano Brivio @ 2019-01-25 10:04 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: David Ahern, Phil Sutter, Eric Garver, Tomas Dolezal,
Stephen Hemminger, Lennert Buytenhek, netdev
In-Reply-To: <800cb3d3-c749-3f36-83ea-0375e67fbd33@cumulusnetworks.com>
Hi Nik,
On Wed, 23 Jan 2019 17:09:42 +0200
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> IMO the effort should be towards improving iproute2 to be
> easier to use and more intuitive. We should be pushing people to use
> the new tools instead of trying to find workarounds to keep the old
> tools alive.
Indeed, it's not my intent here to push anybody to do anything.
However, if you think there's some value in familiarising users with
ip-link, we could, very easily with this script, print (perhaps on
standard error?) the equivalent ip-link commands for any brctl command
issued by the user. It's a couple of lines on top of this patch,
because I'm already doing exactly that -- calculating equivalent
ip-link commands. Something like:
# brctl stp br0 on
You might want to: "ip link set br0 type bridge stp_state 1"
What do you think?
> I do like to idea of deprecating bridge-utils, but I
> think it should be done via improving ip/bridge enough to be pleasant
> to use.
My observation is that brctl is simply a different tool, not as generic
as ip-link, and hence I find it acceptable and understandable that
users (just as I do, I'll admit) feel more comfortable with it for some
specific tasks.
It's not a matter of syntax, ip-link is device-oriented and brctl is
bridge-oriented. If you want to show a list of bridges and basic
information about enslaved ports, 'brctl show' will do this for you.
With ip-link, you'll need to iterate over devices, and list ports and
information for each of them, while getting a significant amount of
unwanted information in the process. However, getting ip-link to do
something different would make it a different tool.
> We will have to maintain this compatibility layer forever if
> it gets accepted and we'll never get rid of brctl this way.
I see this a bit differently: we're not getting rid of bridge-utils
simply because it makes little sense to do so. It's been several years
now that ip-link is able to access and set all the information and
states brctl uses, but this didn't make brctl obsolete, in practice.
However, getting rid of bridge-utils means bridge-utils doesn't need to
be maintained, and I guess that's the reason you're advocating that.
This is the very reason behind this script: it's smaller and simpler
than bridge-utils, and I think we can reasonably assume it's going to
need almost no maintenance, being a rather dumb implementation.
--
Stefano
^ permalink raw reply
* Re: [PATCH iproute2-next] Introduce ip-brctl shell script
From: Stefano Brivio @ 2019-01-25 10:05 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Nikolay Aleksandrov, David Ahern, Phil Sutter, Eric Garver,
Tomas Dolezal, Stephen Hemminger, Lennert Buytenhek, netdev
In-Reply-To: <CAJieiUhEzff7ukTpoch5bRkL-9Rc5pe1PibNjRcqput7JxFOWQ@mail.gmail.com>
Hi Roopa,
On Wed, 23 Jan 2019 08:33:27 -0800
Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On Wed, Jan 23, 2019 at 7:09 AM Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>
> > Hi,
> > IMO the effort should be towards improving iproute2 to be
> > easier to use and more intuitive. We should be pushing people to
> > use the new tools instead of trying to find workarounds to keep the
> > old tools alive. I do like to idea of deprecating bridge-utils, but
> > I think it should be done via improving ip/bridge enough to be
> > pleasant to use. We will have to maintain this compatibility layer
> > forever if it gets accepted and we'll never get rid of brctl this
> > way.
>
> +1, we should move people away from brtcl. there is enough confusion
> among users looking at bridge attributes.,
>
> ip -d link show
> bridge -d link show
> brctl
Why is this confusing? One can simply pick the most appropriate tool.
> Adding a 4th one to the list is not going to ease the confusion.
Why do you say I'm adding a fourth (I guess) tool? I'm replacing the
third one.
> We should try to make the 'ip -d link show and bridge -d link show'
> outputs better. Any suggestions there from people will be useful.
To be honest, I don't see any problem with them -- they just do
different things.
--
Stefano
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-25 10:09 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190124235857.xyb5xx2ufr6x5mbt@ast-mbp.dhcp.thefacebook.com>
On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > So clearly this map stuff is shared between bpf proglets, otherwise
> > there would not be a need for locking. But what happens if one is from
> > task context and another from IRQ context?
> >
> > I don't see a local_irq_save()/restore() anywhere. What avoids the
> > trivial lock inversion?
>
> > and from NMI ...
>
> progs are not preemptable and map syscall accessors have bpf_prog_active counters.
> So nmi/kprobe progs will not be running when syscall is running.
> Hence dead lock is not possible and irq_save is not needed.
What about the progs that run from SoftIRQ ? Since that bpf_prog_active
thing isn't inside BPF_PROG_RUN() what is to stop say:
reuseport_select_sock()
...
BPF_PROG_RUN()
bpf_spin_lock()
<IRQ>
...
BPF_PROG_RUN()
bpf_spin_lock() // forever more
</IRQ>
Unless you stick that bpf_prog_active stuff inside BPF_PROG_RUN itself,
I don't see how you can fundamentally avoid this happening (now or in
the future).
^ permalink raw reply
* [PATCH] r8169: Load MAC address from device tree if present
From: Thierry Reding @ 2019-01-25 10:18 UTC (permalink / raw)
To: David S. Miller
Cc: Heiner Kallweit, Realtek linux nic maintainers, netdev,
devicetree, linux-kernel
From: Thierry Reding <treding@nvidia.com>
If the system was booted using a device tree and if the device tree
contains a MAC address, use it instead of reading one from the EEPROM.
This is useful in situations where the EEPROM isn't properly programmed
or where the firmware wants to override the existing MAC address.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Based on net-next.
drivers/net/ethernet/realtek/r8169.c | 35 +++++++++++++++++-----------
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f574b6b557f9..fd9edd643ca5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6957,6 +6957,21 @@ static int rtl_alloc_irq(struct rtl8169_private *tp)
return pci_alloc_irq_vectors(tp->pci_dev, 1, 1, flags);
}
+static void rtl_read_mac_address(struct rtl8169_private *tp,
+ u8 mac_addr[ETH_ALEN])
+{
+ /* Get MAC address */
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_35 ... RTL_GIGA_MAC_VER_38:
+ case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
+ *(u32 *)&mac_addr[0] = rtl_eri_read(tp, 0xe0, ERIAR_EXGMAC);
+ *(u16 *)&mac_addr[4] = rtl_eri_read(tp, 0xe4, ERIAR_EXGMAC);
+ break;
+ default:
+ break;
+ }
+}
+
DECLARE_RTL_COND(rtl_link_list_ready_cond)
{
return RTL_R8(tp, MCU) & LINK_LIST_RDY;
@@ -7148,6 +7163,7 @@ static int rtl_get_ether_clk(struct rtl8169_private *tp)
static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
+ u8 mac_addr[ETH_ALEN] __aligned(4);
struct rtl8169_private *tp;
struct net_device *dev;
int chipset, region, i;
@@ -7252,20 +7268,13 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
- /* Get MAC address */
- switch (tp->mac_version) {
- u8 mac_addr[ETH_ALEN] __aligned(4);
- case RTL_GIGA_MAC_VER_35 ... RTL_GIGA_MAC_VER_38:
- case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
- *(u32 *)&mac_addr[0] = rtl_eri_read(tp, 0xe0, ERIAR_EXGMAC);
- *(u16 *)&mac_addr[4] = rtl_eri_read(tp, 0xe4, ERIAR_EXGMAC);
+ /* get MAC address */
+ if (eth_platform_get_mac_address(&pdev->dev, mac_addr))
+ rtl_read_mac_address(tp, mac_addr);
+
+ if (is_valid_ether_addr(mac_addr))
+ rtl_rar_set(tp, mac_addr);
- if (is_valid_ether_addr(mac_addr))
- rtl_rar_set(tp, mac_addr);
- break;
- default:
- break;
- }
for (i = 0; i < ETH_ALEN; i++)
dev->dev_addr[i] = RTL_R8(tp, MAC0 + i);
--
2.19.1
^ permalink raw reply related
* [RFC] Loading BTF and pretty printing maps with bpftool
From: Arnaldo Carvalho de Melo @ 2019-01-25 10:20 UTC (permalink / raw)
To: Martin Lau
Cc: Yonghong Song, Song Liu, Andrii Nakryiko, Alexei Starovoitov,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
Hi,
Trying to get BTF to beautify some maps in augmented_raw_syscalls.o,
something is not working, these are the steps, maybe writing them down
will help me to find the problem :-)
So in tools/perf/examples/bpf/augmented_raw_syscalls.c I have
the "syscalls" map, where I'll store details about what 'perf trace'
wants augmented_raw_syscalls.o hooked to raw_syscalls:sys_{enter,exit}:
It looks like:
----
struct syscall {
bool enabled;
};
bpf_map(syscalls, ARRAY, int, struct syscall, 512);
----
That 'struct syscall' will grow to have more per-syscall setup details,
like how many bytes to copy from the 'write' syscall 'buf' argument to
show in the strace-like output, etc.
For now its just to tell what syscalls are enabled.
That 'bpf_map' helper is in tools/perf/include/bpf/bpf.h, and its there
to make map definitions more compact, and to provide a point where we
can, transparently, add the annotations needed for the libbpf BTF
annotations, i.e. it expands to:
---------------------
#define bpf_map(name, _type, type_key, type_val, _max_entries) \
struct bpf_map SEC("maps") name = { \
.type = BPF_MAP_TYPE_##_type, \
.key_size = sizeof(type_key), \
.value_size = sizeof(type_val), \
.max_entries = _max_entries, \
}; \
struct ____btf_map_##name { \
type_key key; \
type_val value; \
}; \
struct ____btf_map_##name __attribute__((section(".maps." #name), used)) \
____btf_map_##name = { }
---------------------
The __btf_map_ I got from tools/testing/selftests/bpf/bpf_helpers.h,
from the BPF_ANNOTATE_KV_PAIR macro that Martin introduced.
So, now when I build a BPF .o file using the above, I get:
# head -3 ~/.perfconfig
[llvm]
dump-obj = true
clang-opt = -g
#
# perf record -e /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.c sleep 0.1
LLVM: dumping /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.023 MB perf.data ]
[root@quaco ~]# clang --version
clang version 7.0.1 (Fedora 7.0.1-1.fc29)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
#
# file /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), with debug_info, not stripped
#
# readelf -SW /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
There are 32 section headers, starting at offset 0x2758:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .strtab STRTAB 0000000000000000 002582 0001d1 00 0 0 1
[ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4
[ 3] raw_syscalls:sys_enter PROGBITS 0000000000000000 000040 0001d0 00 AX 0 0 8
[ 4] .relraw_syscalls:sys_enter REL 0000000000000000 001c38 000030 10 31 3 8
[ 5] raw_syscalls:sys_exit PROGBITS 0000000000000000 000210 0000c0 00 AX 0 0 8
[ 6] .relraw_syscalls:sys_exit REL 0000000000000000 001c68 000020 10 31 5 8
[ 7] maps PROGBITS 0000000000000000 0002d0 000054 00 WA 0 0 4
[ 8] .maps.__augmented_syscalls__ PROGBITS 0000000000000000 000324 000008 00 WA 0 0 4
[ 9] .maps.syscalls PROGBITS 0000000000000000 00032c 000008 00 WA 0 0 4
[10] .maps.pids_filtered PROGBITS 0000000000000000 000334 000008 00 WA 0 0 4
[11] license PROGBITS 0000000000000000 00033c 000004 00 WA 0 0 1
[12] version PROGBITS 0000000000000000 000340 000004 00 WA 0 0 4
[13] .debug_str PROGBITS 0000000000000000 000344 000320 01 MS 0 0 1
[14] .debug_loc PROGBITS 0000000000000000 000664 0001a0 00 0 0 1
[15] .rel.debug_loc REL 0000000000000000 001c88 0001e0 10 31 14 8
[16] .debug_abbrev PROGBITS 0000000000000000 000804 000167 00 0 0 1
[17] .debug_info PROGBITS 0000000000000000 00096b 0004c4 00 0 0 1
[18] .rel.debug_info REL 0000000000000000 001e68 000650 10 31 17 8
[19] .debug_ranges PROGBITS 0000000000000000 000e2f 000030 00 0 0 1
[20] .rel.debug_ranges REL 0000000000000000 0024b8 000040 10 31 19 8
[21] .debug_macinfo PROGBITS 0000000000000000 000e5f 000001 00 0 0 1
[22] .debug_pubnames PROGBITS 0000000000000000 000e60 00016b 00 0 0 1
[23] .rel.debug_pubnames REL 0000000000000000 0024f8 000010 10 31 22 8
[24] .debug_pubtypes PROGBITS 0000000000000000 000fcb 00016e 00 0 0 1
[25] .rel.debug_pubtypes REL 0000000000000000 002508 000010 10 31 24 8
[26] .debug_frame PROGBITS 0000000000000000 001140 000040 00 0 0 8
[27] .rel.debug_frame REL 0000000000000000 002518 000040 10 31 26 8
[28] .debug_line PROGBITS 0000000000000000 001180 0002a5 00 0 0 1
[29] .rel.debug_line REL 0000000000000000 002558 000020 10 31 28 8
[30] .llvm_addrsig LOOS+0xfff4c03 0000000000000000 002578 00000a 00 E 31 0 1
[31] .symtab SYMTAB 0000000000000000 001428 000810 18 1 76 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
p (processor specific)
#
# readelf -sW /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
Symbol table '.symtab' contains 86 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 NOTYPE LOCAL DEFAULT 13
2: 000000000000002a 0 NOTYPE LOCAL DEFAULT 13
3: 000000000000006f 0 NOTYPE LOCAL DEFAULT 13
4: 0000000000000075 0 NOTYPE LOCAL DEFAULT 13
5: 000000000000008c 0 NOTYPE LOCAL DEFAULT 13
6: 0000000000000091 0 NOTYPE LOCAL DEFAULT 13
7: 000000000000009e 0 NOTYPE LOCAL DEFAULT 13
8: 00000000000000a7 0 NOTYPE LOCAL DEFAULT 13
9: 00000000000000b2 0 NOTYPE LOCAL DEFAULT 13
10: 00000000000000be 0 NOTYPE LOCAL DEFAULT 13
11: 00000000000000c8 0 NOTYPE LOCAL DEFAULT 13
12: 00000000000000d6 0 NOTYPE LOCAL DEFAULT 13
13: 00000000000000e0 0 NOTYPE LOCAL DEFAULT 13
14: 00000000000000e8 0 NOTYPE LOCAL DEFAULT 13
15: 000000000000010b 0 NOTYPE LOCAL DEFAULT 13
16: 000000000000010f 0 NOTYPE LOCAL DEFAULT 13
17: 0000000000000113 0 NOTYPE LOCAL DEFAULT 13
18: 0000000000000119 0 NOTYPE LOCAL DEFAULT 13
19: 000000000000011f 0 NOTYPE LOCAL DEFAULT 13
20: 0000000000000123 0 NOTYPE LOCAL DEFAULT 13
21: 000000000000012c 0 NOTYPE LOCAL DEFAULT 13
22: 0000000000000141 0 NOTYPE LOCAL DEFAULT 13
23: 0000000000000149 0 NOTYPE LOCAL DEFAULT 13
24: 000000000000014f 0 NOTYPE LOCAL DEFAULT 13
25: 0000000000000154 0 NOTYPE LOCAL DEFAULT 13
26: 000000000000015c 0 NOTYPE LOCAL DEFAULT 13
27: 000000000000016a 0 NOTYPE LOCAL DEFAULT 13
28: 0000000000000184 0 NOTYPE LOCAL DEFAULT 13
29: 0000000000000193 0 NOTYPE LOCAL DEFAULT 13
30: 0000000000000199 0 NOTYPE LOCAL DEFAULT 13
31: 00000000000001a2 0 NOTYPE LOCAL DEFAULT 13
32: 00000000000001a7 0 NOTYPE LOCAL DEFAULT 13
33: 00000000000001bb 0 NOTYPE LOCAL DEFAULT 13
34: 00000000000001c4 0 NOTYPE LOCAL DEFAULT 13
35: 00000000000001dd 0 NOTYPE LOCAL DEFAULT 13
36: 00000000000001e8 0 NOTYPE LOCAL DEFAULT 13
37: 00000000000001fc 0 NOTYPE LOCAL DEFAULT 13
38: 000000000000020b 0 NOTYPE LOCAL DEFAULT 13
39: 000000000000021d 0 NOTYPE LOCAL DEFAULT 13
40: 000000000000022f 0 NOTYPE LOCAL DEFAULT 13
41: 0000000000000236 0 NOTYPE LOCAL DEFAULT 13
42: 0000000000000246 0 NOTYPE LOCAL DEFAULT 13
43: 000000000000024b 0 NOTYPE LOCAL DEFAULT 13
44: 000000000000024f 0 NOTYPE LOCAL DEFAULT 13
45: 0000000000000259 0 NOTYPE LOCAL DEFAULT 13
46: 0000000000000262 0 NOTYPE LOCAL DEFAULT 13
47: 0000000000000267 0 NOTYPE LOCAL DEFAULT 13
48: 0000000000000278 0 NOTYPE LOCAL DEFAULT 13
49: 000000000000028f 0 NOTYPE LOCAL DEFAULT 13
50: 000000000000029a 0 NOTYPE LOCAL DEFAULT 13
51: 00000000000002a3 0 NOTYPE LOCAL DEFAULT 13
52: 00000000000002b6 0 NOTYPE LOCAL DEFAULT 13
53: 00000000000002ba 0 NOTYPE LOCAL DEFAULT 13
54: 00000000000002c7 0 NOTYPE LOCAL DEFAULT 13
55: 00000000000002d6 0 NOTYPE LOCAL DEFAULT 13
56: 00000000000002df 0 NOTYPE LOCAL DEFAULT 13
57: 00000000000002e4 0 NOTYPE LOCAL DEFAULT 13
58: 00000000000002ed 0 NOTYPE LOCAL DEFAULT 13
59: 0000000000000300 0 NOTYPE LOCAL DEFAULT 13
60: 0000000000000304 0 NOTYPE LOCAL DEFAULT 13
61: 0000000000000316 0 NOTYPE LOCAL DEFAULT 13
62: 0000000000000178 0 NOTYPE LOCAL DEFAULT 3 LBB0_11
63: 00000000000001c0 0 NOTYPE LOCAL DEFAULT 3 LBB0_12
64: 00000000000000e0 0 NOTYPE LOCAL DEFAULT 3 LBB0_6
65: 00000000000000f0 0 NOTYPE LOCAL DEFAULT 3 LBB0_7
66: 00000000000000f8 0 NOTYPE LOCAL DEFAULT 3 LBB0_8
67: 00000000000000b0 0 NOTYPE LOCAL DEFAULT 5 LBB1_3
68: 0000000000000000 0 SECTION LOCAL DEFAULT 3
69: 0000000000000000 0 SECTION LOCAL DEFAULT 5
70: 0000000000000000 0 SECTION LOCAL DEFAULT 14
71: 0000000000000000 0 SECTION LOCAL DEFAULT 16
72: 0000000000000000 0 SECTION LOCAL DEFAULT 17
73: 0000000000000000 0 SECTION LOCAL DEFAULT 19
74: 0000000000000000 0 SECTION LOCAL DEFAULT 26
75: 0000000000000000 0 SECTION LOCAL DEFAULT 28
76: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 8 ____btf_map___augmented_syscalls__
77: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 10 ____btf_map_pids_filtered
78: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 9 ____btf_map_syscalls
79: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 7 __augmented_syscalls__
80: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 11 _license
81: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 12 _version
82: 0000000000000038 0 NOTYPE GLOBAL DEFAULT 7 pids_filtered
83: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 3 sys_enter
84: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 5 sys_exit
85: 000000000000001c 0 NOTYPE GLOBAL DEFAULT 7 syscalls
#
So so far it seems the __btf annotation is there, etc, we need now to
have the BTF there, so I'm using pahole for that:
# readelf -SW /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o | grep -i btf
# pahole -J /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
# readelf -SW /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o | grep -i btf
readelf: /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o: Warning: possibly corrupt ELF header - it has a non-zero program header offset, but no program headers
[32] .BTF PROGBITS 0000000000000000 002835 000664 00 0 0 1
#
And if I use pahole to load that .BTF info:
# pahole -F btf /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
struct bpf_map {
unsigned int type; /* 0 4 */
unsigned int key_size; /* 4 4 */
unsigned int value_size; /* 8 4 */
unsigned int max_entries; /* 12 4 */
unsigned int map_flags; /* 16 4 */
unsigned int inner_map_idx; /* 20 4 */
unsigned int numa_node; /* 24 4 */
/* size: 28, cachelines: 1, members: 7 */
/* last cacheline: 28 bytes */
};
struct ____btf_map___augmented_syscalls__ {
int key; /* 0 4 */
u32 value; /* 4 4 */
/* size: 8, cachelines: 1, members: 2 */
/* last cacheline: 8 bytes */
};
struct ____btf_map_syscalls {
int key; /* 0 4 */
struct syscall value; /* 4 1 */
/* size: 8, cachelines: 1, members: 2 */
/* padding: 3 */
/* last cacheline: 8 bytes */
};
struct syscall {
bool enabled; /* 0 1 */
/* size: 1, cachelines: 1, members: 1 */
/* last cacheline: 1 bytes */
};
struct ____btf_map_pids_filtered {
pid_t key; /* 0 4 */
bool value; /* 4 1 */
/* size: 8, cachelines: 1, members: 2 */
/* padding: 3 */
/* last cacheline: 8 bytes */
};
struct syscall_enter_args {
long long unsigned int common_tp_fields; /* 0 8 */
long int syscall_nr; /* 8 8 */
long unsigned int args[6]; /* 16 48 */
/* size: 64, cachelines: 1, members: 3 */
};
struct augmented_filename {
unsigned int size; /* 0 4 */
int reserved; /* 4 4 */
char value[256]; /* 8 256 */
/* size: 264, cachelines: 5, members: 3 */
/* last cacheline: 8 bytes */
};
struct syscall_exit_args {
long long unsigned int common_tp_fields; /* 0 8 */
long int syscall_nr; /* 8 8 */
long int ret; /* 16 8 */
/* size: 24, cachelines: 1, members: 3 */
/* last cacheline: 24 bytes */
};
#
So, yes, the BTF there seems ok.
Now lets try to use this with 'perf trace':
[root@quaco ~]# perf trace -e *sleep sleep 1s
nanosleep(0x7ffdacc934c0, NULL) = 0
[root@quaco ~]#
So it is working, setting up that augmented_raw_syscalls.o into the
raw_syscalls:sys_enter, with the "syscalls" map with just the array
slots for "clock_nanosleep" and "nanosleep" to be with ".enabled =
true".
If I do it again with a 100h sleep, so that it stays there and we can
observe the maps using bpftool, we get:
# bpftool version
bpftool v5.0.0-rc3
#
# bpftool prog | tail -6
309: tracepoint name sys_enter tag 819967866022f1e1 gpl
loaded_at 2019-01-25T11:05:41+0100 uid 0
xlated 528B jited 381B memlock 4096B map_ids 200,199,198
310: tracepoint name sys_exit tag c1bd85c092d6e4aa gpl
loaded_at 2019-01-25T11:05:41+0100 uid 0
xlated 256B jited 191B memlock 4096B map_ids 200,199
#
And the maps:
# bpftool map | tail -6
198: perf_event_array name __augmented_sys flags 0x0
key 4B value 4B max_entries 8 memlock 4096B
199: array name syscalls flags 0x0
key 4B value 1B max_entries 512 memlock 8192B
200: hash name pids_filtered flags 0x0
key 4B value 1B max_entries 64 memlock 8192B
#
So, dumping the entries for those entries:
[root@quaco ~]# egrep sleep /tmp/build/perf/arch/x86/include/generated/asm/syscalls_64.c
[35] = "nanosleep",
[230] = "clock_nanosleep",
[root@quaco ~]#
Looking at just the open and nanosleep:
# bpftool map dump id 199 | grep "value: 01"
key: 23 00 00 00 value: 01
key: e6 00 00 00 value: 01
#
# bpftool map lookup id 199 key 35
Error: key expected 4 bytes got 1
#
# bpftool map lookup id 199 key 35 00 00 00
key: 23 00 00 00 value: 01
# bpftool map lookup id 199 key 230 00 00 00
key: e6 00 00 00 value: 01
#
I thought it was that --pretty option, so I tried:
# bpftool map --pretty lookup id 199 key 230 00 00 00
{
"key": ["0xe6","0x00","0x00","0x00"
],
"value": ["0x01"
]
}
#
Not yet...
# perf ftrace perf trace -e *sleep sleep 1 > /tmp/perf.trace.ftrace.output
nanosleep(0x7ffec0262650, NULL) = 0
#
# grep btf /tmp/perf.trace.ftrace.output
7) 1.818 us | } /* __btf_verifier_log */
7) | __btf_verifier_log() {
7) 3.753 us | } /* btf_verifier_log_member */
7) 0.125 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | __btf_verifier_log() {
7) 0.136 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | __btf_verifier_log() {
7) 0.139 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | __btf_verifier_log() {
7) + 34.984 us | } /* btf_struct_check_meta */
#
so there was some btf processing, I got a lot of:
CPU:7 [LOST 1130 EVENTS]
So probably a lot more happened, filtering a bit more:
[root@quaco ~]# perf ftrace -G '*btf*' perf trace -e *sleep sleep 1 > /tmp/perf.trace.ftrace.output
nanosleep(0x7ffc7f8927f0, NULL) = 0
[root@quaco ~]#
[root@quaco ~]# grep btf /tmp/perf.trace.ftrace.output | wc -l
260
[root@quaco ~]#
The full contents, filtering out ftrace output for interrupts:
7) | bpf_btf_load() {
7) | capable() {
7) | ns_capable_common() {
7) | security_capable() {
7) 0.105 us | cap_capable();
7) | selinux_capable() {
7) 0.138 us | cred_has_capability();
7) 0.355 us | }
7) 0.969 us | }
7) 1.260 us | }
7) 1.527 us | }
7) | btf_new_fd() {
7) | kmem_cache_alloc_trace() {
7) | _cond_resched() {
7) 0.098 us | rcu_all_qs();
7) 0.294 us | }
7) 0.102 us | should_failslab();
7) 0.172 us | memcg_kmem_put_cache();
7) 1.351 us | }
7) | kmem_cache_alloc_trace() {
7) | _cond_resched() {
7) 0.099 us | rcu_all_qs();
7) 0.300 us | }
7) 0.100 us | should_failslab();
7) 0.313 us | memcg_kmem_put_cache();
7) 1.178 us | }
7) | kvmalloc_node() {
7) | __kmalloc_node() {
7) 0.104 us | kmalloc_slab();
7) | _cond_resched() {
7) 0.102 us | rcu_all_qs();
7) 0.315 us | }
7) 0.100 us | should_failslab();
7) 0.099 us | memcg_kmem_put_cache();
7) 1.150 us | }
7) 1.340 us | }
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.128 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.896 us | }
7) 0.101 us | btf_sec_info_cmp();
7) | btf_struct_check_meta() {
7) 0.135 us | btf_name_valid_identifier.isra.12();
7) 0.109 us | __btf_verifier_log_type();
7) 0.107 us | btf_name_valid_identifier.isra.12();
7) 0.108 us | btf_verifier_log_member();
7) 0.150 us | btf_name_valid_identifier.isra.12();
7) 0.118 us | btf_verifier_log_member();
7) 0.143 us | btf_name_valid_identifier.isra.12();
7) 0.102 us | btf_verifier_log_member();
7) 0.133 us | btf_name_valid_identifier.isra.12();
7) 0.099 us | btf_verifier_log_member();
7) 0.112 us | btf_name_valid_identifier.isra.12();
7) 0.101 us | btf_verifier_log_member();
7) 0.135 us | btf_name_valid_identifier.isra.12();
7) 0.096 us | btf_verifier_log_member();
7) 0.118 us | btf_name_valid_identifier.isra.12();
7) 0.098 us | btf_verifier_log_member();
7) 3.642 us | }
7) | kvmalloc_node() {
7) | __kmalloc_node() {
7) 0.112 us | kmalloc_slab();
7) | _cond_resched() {
7) 0.100 us | rcu_all_qs();
7) 0.296 us | }
7) 0.099 us | should_failslab();
7) 0.102 us | memcg_kmem_put_cache();
7) 1.145 us | }
7) 1.553 us | }
7) | kvfree() {
7) 0.108 us | kfree();
7) 0.304 us | }
7) | btf_int_check_meta() {
7) 0.100 us | __btf_verifier_log_type();
7) 0.315 us | }
7) | btf_struct_check_meta() {
7) 0.244 us | btf_name_valid_identifier.isra.12();
7) 0.102 us | __btf_verifier_log_type();
7) 0.110 us | btf_name_valid_identifier.isra.12();
7) 0.103 us | btf_verifier_log_member();
7) 0.129 us | btf_name_valid_identifier.isra.12();
7) 0.099 us | btf_verifier_log_member();
7) 1.498 us | }
7) | btf_int_check_meta() {
7) 0.101 us | __btf_verifier_log_type();
7) 0.296 us | }
7) | btf_ref_type_check_meta() {
7) 0.107 us | btf_name_valid_identifier.isra.12();
7) 0.099 us | __btf_verifier_log_type();
7) 0.512 us | }
7) | btf_ref_type_check_meta() {
7) 0.112 us | btf_name_valid_identifier.isra.12();
7) 0.101 us | __btf_verifier_log_type();
7) 0.526 us | }
7) | btf_struct_check_meta() {
7) 0.136 us | btf_name_valid_identifier.isra.12();
7) 0.097 us | __btf_verifier_log_type();
7) 0.108 us | btf_name_valid_identifier.isra.12();
7) 0.101 us | btf_verifier_log_member();
7) 0.104 us | btf_name_valid_identifier.isra.12();
7) 0.102 us | btf_verifier_log_member();
7) 1.355 us | }
7) | btf_struct_check_meta() {
7) 0.135 us | btf_name_valid_identifier.isra.12();
7) 0.101 us | __btf_verifier_log_type();
7) 0.115 us | btf_name_valid_identifier.isra.12();
7) 0.104 us | btf_verifier_log_member();
7) 0.960 us | }
7) | btf_ref_type_check_meta() {
7) 0.107 us | btf_name_valid_identifier.isra.12();
7) 0.101 us | __btf_verifier_log_type();
7) 0.516 us | }
7) | btf_int_check_meta() {
7) 0.102 us | __btf_verifier_log_type();
7) 0.311 us | }
7) | btf_struct_check_meta() {
7) 0.153 us | btf_name_valid_identifier.isra.12();
7) 0.103 us | __btf_verifier_log_type();
7) 0.107 us | btf_name_valid_identifier.isra.12();
7) 0.110 us | btf_verifier_log_member();
7) 0.108 us | btf_name_valid_identifier.isra.12();
7) 0.102 us | btf_verifier_log_member();
7) 1.380 us | }
7) | btf_ref_type_check_meta() {
7) 0.118 us | btf_name_valid_identifier.isra.12();
7) 0.101 us | __btf_verifier_log_type();
7) 0.514 us | }
7) | btf_ref_type_check_meta() {
7) 0.156 us | btf_name_valid_identifier.isra.12();
7) 0.103 us | __btf_verifier_log_type();
7) 0.552 us | }
7) | btf_array_check_meta() {
7) 0.102 us | __btf_verifier_log_type();
7) 0.296 us | }
7) | btf_int_check_meta() {
7) 0.098 us | __btf_verifier_log_type();
7) 0.299 us | }
7) | btf_int_check_meta() {
7) 0.098 us | __btf_verifier_log_type();
7) 0.305 us | }
7) | kvmalloc_node() {
7) | __kmalloc_node() {
7) 0.118 us | kmalloc_slab();
7) | _cond_resched() {
7) 0.104 us | rcu_all_qs();
7) 0.302 us | }
7) 0.101 us | should_failslab();
7) 0.219 us | memcg_kmem_put_cache();
7) 1.421 us | }
7) 1.617 us | }
7) | kvfree() {
7) 0.125 us | kfree();
7) 0.313 us | }
7) | btf_ref_type_check_meta() {
7) 0.104 us | __btf_verifier_log_type();
7) 0.311 us | }
7) 0.109 us | btf_verifier_log();
7) | kvfree() {
7) 0.107 us | kfree();
7) 0.296 us | }
7) 0.212 us | kfree();
7) | btf_free() {
7) | kvfree() {
7) 0.182 us | kfree();
7) 0.366 us | } /* kvfree */
7) | kvfree() {
7) 0.104 us | kfree();
7) 0.291 us | }
7) | kvfree() {
7) 0.100 us | kfree();
7) 0.287 us | }
7) | kvfree() {
7) 0.109 us | kfree();
7) 0.298 us | }
7) 0.106 us | kfree();
7) 1.923 us | }
7) + 29.419 us | }
7) + 49.743 us | }
7) | bpf_btf_load() {
7) | capable() {
7) | ns_capable_common() {
7) | security_capable() {
7) 0.100 us | cap_capable();
7) | selinux_capable() {
7) 0.109 us | cred_has_capability();
7) 0.317 us | }
7) 0.750 us | }
7) 0.955 us | }
7) 1.150 us | }
7) | btf_new_fd() {
7) | kmem_cache_alloc_trace() {
7) | _cond_resched() {
7) 0.098 us | rcu_all_qs();
7) 0.290 us | }
7) 0.097 us | should_failslab();
7) 0.108 us | memcg_kmem_put_cache();
7) 0.934 us | }
7) | kmem_cache_alloc_trace() {
7) | _cond_resched() {
7) 0.101 us | rcu_all_qs();
7) 0.294 us | }
7) 0.099 us | should_failslab();
7) 0.099 us | memcg_kmem_put_cache();
7) 0.914 us | }
7) | kvmalloc_node() {
7) | __kmalloc_node() {
7) 0.110 us | kmalloc_slab();
7) | _cond_resched() {
7) 0.110 us | rcu_all_qs();
7) 0.313 us | }
7) 0.104 us | should_failslab();
7) 0.102 us | memcg_kmem_put_cache();
7) 1.158 us | }
7) 6.526 us | }
7) | __check_object_size() {
7) 0.114 us | check_stack_object();
7) 0.109 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.736 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.193 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.836 us | }
7) 1.569 us | }
7) 1.877 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.212 us | check_stack_object();
7) 0.176 us | __virt_addr_valid();
7) 0.112 us | __check_heap_object();
7) 1.031 us | }
7) 1.380 us | }
7) 1.584 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.101 us | check_stack_object();
7) 0.108 us | __virt_addr_valid();
7) 0.198 us | __check_heap_object();
7) 1.012 us | }
7) 1.347 us | }
7) 1.549 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.719 us | }
7) 1.082 us | }
7) 1.283 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.107 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.728 us | }
7) 1.056 us | }
7) 1.258 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.243 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.916 us | }
7) 1.276 us | }
7) 1.495 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.715 us | }
7) 1.268 us | }
7) 1.529 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.723 us | }
7) 1.038 us | }
7) 1.236 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.210 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.940 us | }
7) 1.342 us | }
7) 1.638 us | }
7) 0.114 us | btf_sec_info_cmp();
7) | btf_struct_check_meta() {
7) 0.139 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.112 us | __check_heap_object();
7) 0.765 us | }
7) 1.704 us | }
7) 1.905 us | }
7) | btf_struct_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.106 us | check_stack_object();
7) 0.105 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.728 us | }
7) 1.249 us | }
7) 1.461 us | } /* btf_verifier_log */
7) 1.652 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.108 us | check_stack_object();
7) 0.105 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.909 us | }
7) 1.279 us | }
7) 1.477 us | }
7) 5.584 us | }
7) 0.124 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.121 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.741 us | }
7) 1.350 us | }
7) 1.547 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.195 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.893 us | }
7) 1.336 us | }
7) 1.537 us | }
7) 3.393 us | }
7) 0.126 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.270 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 1.021 us | }
7) 1.528 us | }
7) 1.718 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.128 us | __check_heap_object();
7) 0.726 us | }
7) 1.131 us | }
7) 1.420 us | }
7) 3.471 us | }
7) 0.135 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.123 us | __virt_addr_valid();
7) 0.123 us | __check_heap_object();
7) 0.864 us | }
7) 1.393 us | }
7) 1.681 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.107 us | __check_heap_object();
7) 0.720 us | }
7) 0.975 us | }
7) 1.192 us | }
7) 3.354 us | }
7) 0.153 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.106 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.780 us | }
7) 1.302 us | } /* bpf_verifier_vlog */
7) 1.608 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.253 us | check_stack_object();
7) 0.201 us | __virt_addr_valid();
7) 0.137 us | __check_heap_object();
7) 1.191 us | }
7) 1.444 us | }
7) 1.662 us | }
7) 3.567 us | }
7) 0.124 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.106 us | check_stack_object();
7) 0.122 us | __virt_addr_valid();
7) 0.143 us | __check_heap_object();
7) 0.781 us | }
7) 1.307 us | }
7) 1.533 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.105 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.729 us | }
7) 1.062 us | }
7) 1.417 us | }
7) 3.249 us | }
7) 0.272 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.107 us | __virt_addr_valid();
7) 0.128 us | __check_heap_object();
7) 0.747 us | }
7) 1.362 us | }
7) 1.779 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.200 us | check_stack_object();
7) 0.112 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.823 us | }
7) 1.170 us | }
7) 1.504 us | }
7) 3.771 us | }
7) 0.140 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.099 us | __virt_addr_valid();
7) 0.130 us | __check_heap_object();
7) 0.768 us | }
7) 1.354 us | }
7) 1.691 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.100 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.733 us | }
7) 1.154 us | }
7) 1.353 us | }
7) 3.399 us | }
7) + 33.519 us | }
7) | kvmalloc_node() {
7) | __kmalloc_node() {
7) 0.109 us | kmalloc_slab();
7) | _cond_resched() {
7) 0.129 us | rcu_all_qs();
7) 0.427 us | }
7) 0.216 us | should_failslab();
7) 0.100 us | memcg_kmem_put_cache();
7) 1.461 us | }
7) 1.694 us | }
7) | kvfree() {
7) 0.104 us | kfree();
7) 0.295 us | }
7) | btf_int_check_meta() {
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.112 us | __check_heap_object();
7) 0.814 us | }
7) 1.530 us | }
7) 1.723 us | }
7) | btf_int_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.783 us | }
7) 1.719 us | }
7) 1.991 us | }
7) 2.343 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.101 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.231 us | __check_heap_object();
7) 0.970 us | }
7) 1.409 us | }
7) 1.630 us | }
7) 6.140 us | }
7) 6.476 us | }
7) | btf_struct_check_meta() {
7) 0.189 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.101 us | check_stack_object();
7) 0.295 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 1.144 us | }
7) 1.673 us | }
7) 2.189 us | }
7) | btf_struct_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.130 us | __virt_addr_valid();
7) 0.229 us | __check_heap_object();
7) 1.106 us | }
7) 1.684 us | }
7) 1.891 us | }
7) 2.084 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.159 us | __virt_addr_valid();
7) 0.111 us | __check_heap_object();
7) 1.046 us | }
7) 1.342 us | }
7) 1.542 us | }
7) 6.222 us | }
7) 0.119 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.101 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.137 us | __check_heap_object();
7) 0.944 us | }
7) 1.407 us | }
7) 1.604 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.100 us | check_stack_object();
7) 0.130 us | __virt_addr_valid();
7) 0.315 us | __check_heap_object();
7) 1.106 us | } /* __check_object_size */
7) 1.354 us | }
7) 1.765 us | }
7) 3.673 us | }
7) 0.122 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.250 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.988 us | }
7) 1.441 us | }
7) 1.641 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.135 us | check_stack_object();
7) 0.225 us | __virt_addr_valid();
7) 0.136 us | __check_heap_object();
7) 1.149 us | }
7) 1.402 us | }
7) 1.622 us | }
7) 3.579 us | }
7) + 14.613 us | }
7) | btf_int_check_meta() {
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.132 us | __virt_addr_valid();
7) 0.288 us | __check_heap_object();
7) 1.112 us | }
7) 1.580 us | }
7) 1.781 us | }
7) | btf_int_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.138 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 1.131 us | }
7) 1.712 us | }
7) 1.983 us | }
7) 2.350 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.105 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.911 us | }
7) 1.170 us | }
7) 1.368 us | }
7) 6.101 us | }
7) 6.406 us | }
7) | btf_ref_type_check_meta() {
7) 0.206 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.163 us | __check_heap_object();
7) 0.869 us | }
7) 1.361 us | }
7) 1.655 us | }
7) | btf_ref_type_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.101 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.744 us | }
7) 1.180 us | }
7) 1.501 us | }
7) 1.691 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.148 us | check_stack_object();
7) 0.337 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 1.138 us | }
7) 1.389 us | }
7) 1.605 us | }
7) 5.530 us | }
7) 6.215 us | }
7) | btf_ref_type_check_meta() {
7) 0.104 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.861 us | }
7) 1.413 us | }
7) 1.611 us | }
7) | btf_ref_type_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.128 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.846 us | }
7) 1.172 us | }
7) 1.409 us | }
7) 1.676 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.158 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 1.040 us | }
7) 1.292 us | }
7) 1.510 us | }
7) 5.320 us | }
7) 5.788 us | }
7) | btf_struct_check_meta() {
7) 0.253 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.107 us | __virt_addr_valid();
7) 0.427 us | __check_heap_object();
7) 1.042 us | }
7) 1.597 us | }
7) 1.986 us | }
7) | btf_struct_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.111 us | __check_heap_object();
7) 0.761 us | }
7) 1.306 us | }
7) 1.503 us | }
7) 1.721 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.932 us | }
7) 1.177 us | }
7) 1.417 us | }
7) 5.809 us | }
7) 0.109 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.172 us | __check_heap_object();
7) 0.948 us | }
7) 1.411 us | }
7) 1.609 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.189 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.919 us | }
7) 1.170 us | }
7) 1.401 us | }
7) 3.498 us | }
7) 0.125 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.107 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.766 us | }
7) 1.341 us | }
7) 1.600 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.147 us | check_stack_object();
7) 0.105 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.864 us | }
7) 1.261 us | }
7) 1.478 us | }
7) 3.695 us | }
7) + 14.434 us | }
7) | btf_struct_check_meta() {
7) 0.129 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.239 us | __check_heap_object();
7) 0.958 us | }
7) 1.426 us | }
7) 1.689 us | }
7) | btf_struct_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.101 us | check_stack_object();
7) 0.121 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 1.070 us | }
7) 1.473 us | }
7) 1.879 us | }
7) 2.103 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.107 us | __check_heap_object();
7) 0.908 us | }
7) 1.159 us | }
7) 1.385 us | }
7) 5.993 us | }
7) 0.138 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.107 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.770 us | }
7) 1.337 us | }
7) 1.668 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.131 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.111 us | __check_heap_object();
7) 0.839 us | }
7) 1.179 us | }
7) 1.444 us | }
7) 3.474 us | }
7) + 10.523 us | }
7) | btf_ref_type_check_meta() {
7) 0.113 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.106 us | check_stack_object();
7) 0.125 us | __virt_addr_valid();
7) 0.132 us | __check_heap_object();
7) 0.818 us | }
7) 1.293 us | }
7) 1.621 us | }
7) | btf_ref_type_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.154 us | __check_heap_object();
7) 0.938 us | }
7) 1.256 us | }
7) 1.459 us | }
7) 1.745 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.806 us | }
7) 1.193 us | }
7) 1.391 us | }
7) 5.251 us | }
7) 5.892 us | }
7) | btf_int_check_meta() {
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.107 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.111 us | __check_heap_object();
7) 0.913 us | }
7) 1.579 us | }
7) 1.896 us | }
7) | btf_int_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.247 us | check_stack_object();
7) 0.115 us | __virt_addr_valid();
7) 0.373 us | __check_heap_object();
7) 1.185 us | }
7) 1.847 us | }
7) 2.228 us | }
7) 2.577 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.123 us | __virt_addr_valid();
7) 0.112 us | __check_heap_object();
7) 0.797 us | }
7) 1.098 us | }
7) 1.297 us | }
7) 6.422 us | }
7) 6.683 us | }
7) | btf_struct_check_meta() {
7) 0.144 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.182 us | __virt_addr_valid();
7) 0.122 us | __check_heap_object();
7) 0.910 us | }
7) 1.417 us | }
7) 1.619 us | }
7) | btf_struct_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.134 us | check_stack_object();
7) 0.262 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 1.061 us | }
7) 1.414 us | }
7) 1.615 us | }
7) 1.921 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.234 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.221 us | __check_heap_object();
7) 1.134 us | }
7) 1.389 us | }
7) 1.607 us | }
7) 5.555 us | }
7) 0.108 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.107 us | __check_heap_object();
7) 0.920 us | }
7) 1.487 us | }
7) 1.686 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.276 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.943 us | }
7) 1.196 us | }
7) 1.398 us | }
7) 3.526 us | }
7) 0.113 us | btf_name_valid_identifier.isra.12();
7) | btf_verifier_log_member() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.723 us | }
7) 1.174 us | }
7) 1.453 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.332 us | __check_heap_object();
7) 1.019 us | }
7) 1.479 us | }
7) 1.750 us | }
7) 3.808 us | }
7) + 13.995 us | }
7) | btf_ref_type_check_meta() {
7) 0.125 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.136 us | check_stack_object();
7) 0.102 us | __virt_addr_valid();
7) 0.107 us | __check_heap_object();
7) 0.861 us | }
7) 1.449 us | }
7) 1.673 us | }
7) | btf_ref_type_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.101 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.728 us | }
7) 1.084 us | }
7) 1.436 us | }
7) 1.623 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.100 us | check_stack_object();
7) 0.101 us | __virt_addr_valid();
7) 0.135 us | __check_heap_object();
7) 0.870 us | }
7) 1.118 us | }
7) 1.397 us | }
7) 5.199 us | }
7) 5.621 us | }
7) | btf_ref_type_check_meta() {
7) 0.366 us | btf_name_valid_identifier.isra.12();
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.106 us | check_stack_object();
7) 0.263 us | __virt_addr_valid();
7) 0.112 us | __check_heap_object();
7) 1.007 us | }
7) 1.518 us | }
7) 1.719 us | }
7) | btf_ref_type_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.294 us | __virt_addr_valid();
7) 0.110 us | __check_heap_object();
7) 0.959 us | }
7) 1.268 us | }
7) 1.470 us | }
7) 1.755 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.112 us | __check_heap_object();
7) 0.882 us | }
7) 1.157 us | }
7) 1.360 us | }
7) 5.297 us | }
7) 5.996 us | }
7) | btf_array_check_meta() {
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.234 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.850 us | }
7) 1.322 us | }
7) 1.517 us | }
7) | btf_array_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.103 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.938 us | }
7) 1.438 us | }
7) 1.636 us | }
7) 1.901 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.202 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.137 us | __check_heap_object();
7) 1.067 us | }
7) 1.323 us | }
7) 1.543 us | }
7) 5.507 us | }
7) 5.894 us | }
7) | btf_int_check_meta() {
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.150 us | __virt_addr_valid();
7) 0.111 us | __check_heap_object();
7) 1.007 us | }
7) 1.675 us | }
7) 1.905 us | }
7) | btf_int_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.104 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.322 us | __check_heap_object();
7) 0.981 us | }
7) 1.503 us | }
7) 1.705 us | }
7) 1.907 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.104 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.722 us | }
7) 1.257 us | }
7) 1.638 us | }
7) 5.861 us | }
7) 6.055 us | }
7) | btf_int_check_meta() {
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.105 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.145 us | __check_heap_object();
7) 0.866 us | }
7) 1.356 us | }
7) 1.623 us | }
7) | btf_int_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.102 us | check_stack_object();
7) 0.101 us | __virt_addr_valid();
7) 0.244 us | __check_heap_object();
7) 0.909 us | }
7) 1.438 us | }
7) 1.675 us | }
7) 1.937 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.240 us | check_stack_object();
7) 0.129 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 1.029 us | }
7) 1.326 us | }
7) 1.671 us | }
7) 5.772 us | }
7) 5.981 us | }
7) | kvmalloc_node() {
7) | __kmalloc_node() {
7) 0.103 us | kmalloc_slab();
7) | _cond_resched() {
7) 0.265 us | rcu_all_qs();
7) 0.460 us | }
7) 0.099 us | should_failslab();
7) 0.102 us | memcg_kmem_put_cache();
7) 1.276 us | }
7) 1.490 us | }
7) | kvfree() {
7) 0.119 us | kfree();
7) 0.304 us | }
7) | btf_ref_type_check_meta() {
7) | __btf_verifier_log_type() {
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.103 us | check_stack_object();
7) 0.100 us | __virt_addr_valid();
7) 0.109 us | __check_heap_object();
7) 0.746 us | }
7) 1.210 us | }
7) 1.407 us | }
7) | btf_ref_type_log() {
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.097 us | check_stack_object();
7) 0.101 us | __virt_addr_valid();
7) 0.107 us | __check_heap_object();
7) 0.707 us | }
7) 1.013 us | }
7) 1.210 us | }
7) 1.402 us | }
7) | __btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.101 us | check_stack_object();
7) 0.115 us | __virt_addr_valid();
7) 0.108 us | __check_heap_object();
7) 0.737 us | }
7) 0.990 us | }
7) 1.188 us | }
7) 4.405 us | }
7) 4.608 us | }
7) | btf_verifier_log() {
7) | bpf_verifier_vlog() {
7) | __check_object_size() {
7) 0.107 us | check_stack_object();
7) 0.106 us | __virt_addr_valid();
7) 0.112 us | __check_heap_object();
7) 0.744 us | }
7) 1.545 us | }
7) 1.745 us | }
7) | kvfree() {
7) 0.106 us | kfree();
7) 0.296 us | }
7) 0.120 us | kfree();
7) | btf_free() {
7) | kvfree() {
7) 0.115 us | kfree();
7) 0.298 us | }
7) | kvfree() {
7) 0.103 us | kfree();
7) 0.291 us | }
7) | kvfree() {
7) 0.097 us | kfree();
7) 0.281 us | }
7) | kvfree() {
7) 0.113 us | kfree();
7) 0.300 us | }
7) 0.103 us | kfree();
7) 1.870 us | }
7) ! 194.466 us | }
7) ! 195.945 us | }
Looking at 'perf trace -vv' the only messages that seem to have come
from libbpf are:
INFO: nothing to config for map syscalls
INFO: nothing to config for map pids_filtered
So, what am I missing?
- Arnaldo
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-25 10:23 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190124235857.xyb5xx2ufr6x5mbt@ast-mbp.dhcp.thefacebook.com>
On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > And this would again be the moment where I go pester you about the BPF
> > memory model :-)
>
> hehe :)
> How do you propose to define it in a way that it applies to all archs
> and yet doesn't penalize x86 ?
> "Assume minimum execution ordering model" the way kernel does
> unfortunately is not usable, since bpf doesn't have a luxury
> of using nice #defines that convert into nops on x86.
Why not? Surely the JIT can fix it up? That is, suppose you were to have
smp_rmb() as a eBPF instruction then the JIT (which knows what
architecture it is targeting) can simply avoid emitting instructions for
it.
Similarly; could something like this not also help with the spinlock
thing? Use that generic test-and-set thing for the interpreter, but
provide a better implementation in the JIT?
^ permalink raw reply
* Re: [PATCH] net: macb: Apply RXUBR workaround only to versions with errata
From: Nicolas.Ferre @ 2019-01-25 10:28 UTC (permalink / raw)
To: harini.katakam, davem, Claudiu.Beznea, brandon.streiff
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux
In-Reply-To: <1548337111-31184-1-git-send-email-harini.katakam@xilinx.com>
On 24/01/2019 at 14:38, Harini Katakam wrote:
> The interrupt handler contains a workaround for RX hang applicable
> to Zynq and AT91 only. Subsequent versions do not need this
AT91RM9200 only. It's not the case for other AT91 SoCs (reading errata
list for them).
That being said I have to add a patch for making this perfectly clear in
the comment just above the flag's test.
> workaround. This workaround unecessarily resets RX whenever RX used
Typo: unnecessarily
> bit read is observed, which can be often under heavy traffic. Hence
> introduce an CAPS mask and a check to enable this workaround.
Nack for this one, see below...
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
> ---
> Changes from RFC:
> - Use CAPS mask instead introducing and errata field.
> - Use check only on RX reset part; ISR should still be cleared.
>
> drivers/net/ethernet/cadence/macb.h | 1 +
> drivers/net/ethernet/cadence/macb_main.c | 16 ++++++++++------
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index 3d45f4c..2b412fa 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -643,6 +643,7 @@
> #define MACB_CAPS_JUMBO 0x00000020
> #define MACB_CAPS_GEM_HAS_PTP 0x00000040
> #define MACB_CAPS_BD_RD_PREFETCH 0x00000080
> +#define MACB_CAPS_NEEDS_RSTONUBR 0x00000100
> #define MACB_CAPS_FIFO_MODE 0x10000000
> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
> #define MACB_CAPS_SG_DISABLED 0x40000000
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 66cc792..0bda1cd 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -1416,10 +1416,12 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
> * section 16.7.4 for details.
> */
> if (status & MACB_BIT(RXUBR)) {
> - ctrl = macb_readl(bp, NCR);
> - macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
> - wmb();
> - macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
> + if (bp->caps & MACB_CAPS_NEEDS_RSTONUBR) {
> + ctrl = macb_readl(bp, NCR);
> + macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
> + wmb();
> + macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
> + }
As this interrupt routine is not doing anything else than just being
called now, what about just removing the use of this status bit for
platforms which don't need this RX reset?
> if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
> queue_writel(queue, ISR, MACB_BIT(RXUBR));
> @@ -3864,7 +3866,8 @@ static int at91ether_init(struct platform_device *pdev)
> }
>
> static const struct macb_config at91sam9260_config = {
> - .caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
> + .caps = MACB_CAPS_USRIO_HAS_CLKEN |
> + MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII | MACB_CAPS_NEEDS_RSTONUBR,
> .clk_init = macb_clk_init,
> .init = macb_init,
Actually it seems not the proper configuration structure to modify: You
must change the emac_config instead.
> };
> @@ -3928,7 +3931,8 @@ static const struct macb_config zynqmp_config = {
> };
>
> static const struct macb_config zynq_config = {
> - .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_NO_GIGABIT_HALF,
> + .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_NO_GIGABIT_HALF |
> + MACB_CAPS_NEEDS_RSTONUBR,
> .dma_burst_length = 16,
> .clk_init = macb_clk_init,
> .init = macb_init,
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [patch iproute2] libnetlink: linkdump_req: AF_PACKET family also expects ext_filter_mask
From: Chris Mi @ 2019-01-25 10:37 UTC (permalink / raw)
To: netdev; +Cc: dsahern, chrism
Without this fix, the VF info can't be showed using command
"ip link".
146: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 24:8a:07:ad:78:52 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 02:25:d0:12:01:01, spoof checking off, link-state auto, trust off, query_rss off
vf 1 MAC 02:25:d0:12:01:02, spoof checking off, link-state auto, trust off, query_rss off
Fixes: d97b16b2c906 ("libnetlink: linkdump_req: Only AF_UNSPEC family expects an ext_filter_mask")
Signed-off-by: Chris Mi <chrism@mellanox.com>
---
lib/libnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 110f47b..3beb434 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -476,7 +476,7 @@ int rtnl_linkdump_req_filter(struct rtnl_handle *rth, int family,
int rtnl_linkdump_req_filter_fn(struct rtnl_handle *rth, int family,
req_filter_fn_t filter_fn)
{
- if (family == AF_UNSPEC) {
+ if (family == AF_UNSPEC || family == AF_PACKET) {
struct {
struct nlmsghdr nlh;
struct ifinfomsg ifm;
--
2.7.5
^ permalink raw reply related
* [PATCH] net/rose: fix NULL ax25_cb kernel panic
From: Dmitry Vyukov @ 2019-01-25 10:46 UTC (permalink / raw)
To: f6bvp, davem, linux-hams, netdev
Cc: Dmitry Vyukov, syzbot+1a2c456a1ea08fa5b5f7, Ralf Baechle,
linux-kernel
From: Bernard Pidoux <f6bvp@free.fr>
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Testing:
Built kernel with CONFIG_ROSE=y.
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Bernard Pidoux <f6bvp@free.fr>
Cc: linux-hams@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/rose/rose_route.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 77e9f85a2c92..f2ff21d7df08 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -850,6 +850,7 @@ void rose_link_device_down(struct net_device *dev)
/*
* Route a frame to an appropriate AX.25 connection.
+ * A NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -867,6 +868,10 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
--
2.20.1.495.gaa96b0ce6b-goog
^ permalink raw reply related
* Re: [PATCH] net: macb: Apply RXUBR workaround only to versions with errata
From: Harini Katakam @ 2019-01-25 11:03 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Harini Katakam, David Miller, Claudiu Beznea, Brandon Streiff,
netdev, linux-kernel, Michal Simek
In-Reply-To: <e9c3ae69-a0cb-3862-c01d-d8d1fc3c68e8@microchip.com>
Hi Nicolas,
On Fri, Jan 25, 2019 at 3:58 PM <Nicolas.Ferre@microchip.com> wrote:
>
> On 24/01/2019 at 14:38, Harini Katakam wrote:
> > The interrupt handler contains a workaround for RX hang applicable
> > to Zynq and AT91 only. Subsequent versions do not need this
>
> AT91RM9200 only. It's not the case for other AT91 SoCs (reading errata
> list for them).
>
> That being said I have to add a patch for making this perfectly clear in
> the comment just above the flag's test.
>
> > workaround. This workaround unecessarily resets RX whenever RX used
>
> Typo: unnecessarily
>
> > bit read is observed, which can be often under heavy traffic. Hence
> > introduce an CAPS mask and a check to enable this workaround.
>
> Nack for this one, see below...
Thanks for the review. I dint realize it was AT91RM9200, hence I edited
the wrong config structure. Will fix.
<snip>
> > if (status & MACB_BIT(RXUBR)) {
> > - ctrl = macb_readl(bp, NCR);
> > - macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
> > - wmb();
> > - macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
> > + if (bp->caps & MACB_CAPS_NEEDS_RSTONUBR) {
> > + ctrl = macb_readl(bp, NCR);
> > + macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
> > + wmb();
> > + macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
> > + }
>
> As this interrupt routine is not doing anything else than just being
> called now, what about just removing the use of this status bit for
> platforms which don't need this RX reset?
OK, sure I'll try that. I left the interrupt enabled just in case there were
other users performing an action/using this interrupt.
Regards,
Harini
^ permalink raw reply
* RE: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
From: Fabrizio Castro @ 2019-01-25 11:33 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Wolfgang Grandegger, Marc Kleine-Budde,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
David S. Miller, Magnus Damm, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-can@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20190124100123.a2gvucnnwrxibulf@verge.net.au>
Hello Simon,
Thank you for your feedback!
> From: Simon Horman <horms@verge.net.au>
> Sent: 24 January 2019 10:01
> Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
>
> On Wed, Jan 23, 2019 at 12:18:45PM +0000, Fabrizio Castro wrote:
> > Hello Geert,
> >
> > Thank you for your feedback!
> >
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 23 January 2019 12:08
> > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > >
> > > Hi Fabrizio,
> > >
> > > On Wed, Jan 23, 2019 at 1:01 PM Fabrizio Castro
> > > <fabrizio.castro@bp.renesas.com> wrote:
> > > > > From: Simon Horman <horms@verge.net.au>
> > > > > Sent: 23 January 2019 11:38
> > > > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > > > >
> > > > > On Wed, Jan 23, 2019 at 10:51:23AM +0100, Simon Horman wrote:
> > > > > > On Fri, Jan 18, 2019 at 01:13:53PM +0100, Simon Horman wrote:
> > > > > > > On Thu, Jan 17, 2019 at 02:54:15PM +0000, Fabrizio Castro wrote:
> > > > > > > > According to the latest information, clkp2 is available on RZ/G2.
> > > > > > > > Modify CAN0 and CAN1 nodes accordingly.
> > > > > > > >
> > > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > > > > > Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
> > >
> > > > > > Thanks again, applied for v5.1.
> > > > >
> > > > > Sorry, I was a little hasty there.
> > > > >
> > > > > This patch depends on the presence of R8A774A1_CLK_CANFD which
> > > > > (rightly) is added in a different patch in this series which is to
> > > > > go upstream via a different tree.
> > > > >
> > > > > I have dropped this patch for now. I think there are two solution to this
> > > > > problem.
> > > > >
> > > > > 1. Provide a version of this patch which uses a numeric index instead of
> > > > > R8A774A1_CLK_CANFD. And then, once R8A774A1_CLK_CANFD is present in an
> > > > > RC release provide a patch to switch to using R8A774A1_CLK_CANFD.
> > > > >
> > > > > 2. Defer this patch until R8A774A1_CLK_CANFD is present in an RC release.
> > > >
> > > > Yeah, my personal preference is solution 2.
> > >
> > > Note that solution 2 will probably defer the DT patch to v5.2.
> >
> > Yeah, my understanding is that even if we chose solution 1 we would still
> > need to be waiting for v5.2 for the patch to switch to using
> > R8A774A1_CLK_CANFD to appear in a rc, therefore I think solution 2 is
> > fine.
>
> Your understanding is the same as mine.
>
> I do seem some slight value in option 1 in terms of getting the change,
> less the minor issue of using an index rather than a symbol, upstream
> earlier. But I do not feel strongly about this.
>
> I am marking this patch as deferred. Please repost or otherwise ping me
> when you would like to revisit this topic.
Thank you. Will do.
Fab
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [net-next PATCH] MAINTAINERS: Add entry for XDP core code
From: Jesper Dangaard Brouer @ 2019-01-25 12:02 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Daniel Borkmann, Jakub Kicinski,
Alexei Starovoitov, Jesper Dangaard Brouer
Add myself as a maintainer for these parts, as I'm responsible
for adding most of this.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a0245fd1b09a..f66297853df7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16686,6 +16686,15 @@ T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/tuners/tuner-xc2028.*
+XDP
+M: Jesper Dangaard Brouer <hawk@kernel.org>
+L: netdev@vger.kernel.org
+L: xdp-newbies@vger.kernel.org
+F: net/core/xdp.c
+F: include/net/xdp.h
+F: kernel/bpf/devmap.c
+F: kernel/bpf/cpumap.c
+
XDP SOCKETS (AF_XDP)
M: Björn Töpel <bjorn.topel@intel.com>
M: Magnus Karlsson <magnus.karlsson@intel.com>
^ permalink raw reply related
* Re: WoL broken in r8169.c since kernel 4.19
From: Marc Haber @ 2019-01-25 12:02 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev@vger.kernel.org
In-Reply-To: <6ae02156-8903-70fd-675f-a5aee9c452b4@gmail.com>
On Fri, Jan 25, 2019 at 07:49:56AM +0100, Heiner Kallweit wrote:
> thanks a lot for the detailed analysis. That this ethtool sequence
>
> ethtool -s <if> wol d
> ethtool -s <if> wol g
>
> helps makes me think that the following patch should help too.
> Could you please test?
That patch didn't apply cleanly because the rtl_init_one in kernel
4.20.4 is missing the INIT_WORK call at this place.
And it doesn't change the behavior, the two ethtool calls are needed so
that the host wakes up from suspend to ram on a magic packet.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: marvell 6190 NAT performance
From: Marek Behún @ 2019-01-25 12:09 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev, Russell King
In-Reply-To: <ea329d29-36eb-0eec-666f-1cc12940b16f@gmail.com>
On Thu, 24 Jan 2019 13:31:24 -0800
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 1/24/19 12:26 PM, Marek Behun wrote:
> > Hello,
> >
> > I am encountering strange performance issue when benchmarking NAT
> > performance on Armada 3720 with Marvell 88e6190 switch.
> >
> > Download speed (from internet, via Armada 3720 NAT, via switch to
> > LAN device) is ~750mbps and the CPU running on 100% (mostly in
> > ksoftirq). Upload speed is ~250mbps.
> >
> > When the LAN device is connected to A3720 directly (via SFP), the
> > speeds are both ~1000mbps.
>
> OK and that presumably uses the second Ethernet MAC on the SoC right?
SFP port uses the same Ethernet MAC as switch.
eth0 is used for wan, eth1 is either connected to a SFP cage or to a
switch chip.
> >
> > I realize that packing/unpacking packets with Marvell header for the
> > switch takes some time, but is such a performance drop expected?
>
> If you run perf top/record you would be able to see that pretty
> quickly, I would not think that processing of the Marvell DSA tag
> would incur such a high penalty though since the packets are already
> hot in D$ by the time we get to mangle them for the DSA network
> devices.
>
> How about pure (non-NAT) IP routing? How about just bridging between
> WAN and LAN?
I will try to do various benchmarks and send the results.
Marek
^ permalink raw reply
* [PATCH] net: phy: at803x: Use helpers to access MMD PHY registers
From: Carlo Caione @ 2019-01-25 12:35 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, netdev, linux-kernel; +Cc: Carlo Caione
Libphy provides a standard set of helpers to access the MMD PHY
registers. Use those instead of relying on custom driver-specific
functions.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
---
drivers/net/phy/at803x.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index f9432d053a22..23ba76f8d950 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -39,9 +39,6 @@
#define AT803X_LOC_MAC_ADDR_0_15_OFFSET 0x804C
#define AT803X_LOC_MAC_ADDR_16_31_OFFSET 0x804B
#define AT803X_LOC_MAC_ADDR_32_47_OFFSET 0x804A
-#define AT803X_MMD_ACCESS_CONTROL 0x0D
-#define AT803X_MMD_ACCESS_CONTROL_DATA 0x0E
-#define AT803X_FUNC_DATA 0x4003
#define AT803X_REG_CHIP_CONFIG 0x1f
#define AT803X_BT_BX_REG_SEL 0x8000
@@ -168,16 +165,9 @@ static int at803x_set_wol(struct phy_device *phydev,
if (!is_valid_ether_addr(mac))
return -EINVAL;
- for (i = 0; i < 3; i++) {
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
- AT803X_DEVICE_ADDR);
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
- offsets[i]);
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
- AT803X_FUNC_DATA);
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
- mac[(i * 2) + 1] | (mac[(i * 2)] << 8));
- }
+ for (i = 0; i < 3; i++)
+ phy_write_mmd(phydev, AT803X_DEVICE_ADDR, offsets[i],
+ mac[(i * 2) + 1] | (mac[(i * 2)] << 8));
value = phy_read(phydev, AT803X_INTR_ENABLE);
value |= AT803X_INTR_ENABLE_WOL;
--
2.19.1
^ permalink raw reply related
* FW: lock dep issue
From: Ruhl, Michael J @ 2019-01-25 12:58 UTC (permalink / raw)
To: intel-wired-lan@osuosl.org, netdev@vger.kernel.org
In-Reply-To: <1EF4DF93-8A2A-41A0-BC2A-7604B59875A4@intel.com>
Hi,
While running a 5.0.0.rc1 kernel with the LOCKDEP debug configuration turned on, and I saw this LOCKDEP error:
--
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
in_atomic(): 1, irqs_disabled(): 0, pid: 2583, name: sadc
2 locks held by sadc/2583:
#0: 00000000e5ef963c (&p->lock){+.+.}, at: seq_read+0x3c/0x3a0
#1: 00000000f89a2b22 (rcu_read_lock){....}, at: dev_seq_start+0x5/0x110
CPU: 29 PID: 2583 Comm: sadc Tainted: G W I 5.0.0-rc1+ #2
Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
Call Trace:
dump_stack+0x78/0xb3
___might_sleep+0x22d/0x250
__mutex_lock+0x56/0x910
? _raw_spin_unlock+0x24/0x30
? deactivate_slab.isra.73+0x5b2/0x6f0
? igb_get_stats64+0x29/0xf0
? seq_read+0x305/0x3a0
? set_track+0x6d/0x1a0
igb_get_stats64+0x29/0xf0
dev_get_stats+0x74/0x130
dev_seq_printf_stats+0x34/0x120
? __lock_acquire+0x69a/0x1160
dev_seq_show+0x10/0x30
seq_read+0x266/0x3a0
proc_reg_read+0x3c/0x70
__vfs_read+0x36/0x190
vfs_read+0x9b/0x150
ksys_read+0x55/0xc0
do_syscall_64+0x60/0x210
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f650013ec00
Code: 0b 31 c0 48 83 c4 08 e9 be fe ff ff 48 8d 3d 17 b9 09 00 e8 52 8a 02 00 66 90 83 3d 9d c3 2d 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 4e cc 01 00 48 89 04 24
RSP: 002b:00007fffed163aa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 0000000001f6b8b0 RCX: 00007f650013ec00
RDX: 0000000000000400 RSI: 00007f650084a000 RDI: 0000000000000003
RBP: 00007f65004123a0 R08: ffffffffffffffff R09: 0000000000000000
R10: 0000000000000022 R11: 0000000000000246 R12: 00007f6500411858
R13: 0000000000000d70 R14: 0000000000000d70 R15: 00007f6500411858
--
I saw this on the console while not doing anything on the system (i.e. no test were running, or any overt network work).
Since this didn't seem like a good thing I thought I would drop this note.
If you need any more information, please let me know.
Thanks,
Mike
^ permalink raw reply
* pull-request: mac80211 2019-01-25
From: Johannes Berg @ 2019-01-25 13:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here are 8 fixes for the current cycle, nothing that seems out of
the ordinary.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 8a7fa0c35027d1a3ec3c3e8612800a1b4738e3c3:
Merge tag 'mlx5-fixes-2019-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2019-01-18 18:23:23 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2019-01-25
for you to fetch changes up to 93183bdbe73bbdd03e9566c8dc37c9d06b0d0db6:
cfg80211: extend range deviation for DMG (2019-01-25 10:18:51 +0100)
----------------------------------------------------------------
Just a few small fixes:
* avoid trying to operate TDLS when not connection,
this is not valid and led to issues
* count TTL-dropped frames in mesh better
* deal with new WiGig channels in regulatory code
* remove a WARN_ON() that can trigger due to benign
races during device/driver registration
* fix nested netlink policy maxattrs (syzkaller)
* fix hwsim n_limits (syzkaller)
* propagate __aligned(2) to a surrounding struct
* return proper error in virt_wifi error path
----------------------------------------------------------------
Balaji Pothunoori (1):
mac80211: don't initiate TDLS connection if station is not associated to AP
Bob Copeland (1):
mac80211: fix miscounting of ttl-dropped frames
Chaitanya Tata (2):
cfg80211: reg: remove warn_on for a normal case
cfg80211: extend range deviation for DMG
Johannes Berg (2):
mac80211_hwsim: check that n_limits makes sense
nl80211: fix NLA_POLICY_NESTED() arguments
Mathieu Malaterre (1):
mac80211: Add attribute aligned(2) to struct 'action'
Wei Yongjun (1):
virt_wifi: fix error return code in virt_wifi_newlink()
drivers/net/wireless/mac80211_hwsim.c | 5 +++++
drivers/net/wireless/virt_wifi.c | 4 +++-
net/mac80211/cfg.c | 4 ++++
net/mac80211/rx.c | 6 ++++--
net/wireless/nl80211.c | 2 +-
net/wireless/reg.c | 13 +++++++++----
6 files changed, 26 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 2/6] net/sched: flower: add support for matching on ConnTrack
From: Simon Horman @ 2019-01-25 13:37 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Guy Shattah, Aaron Conole, John Hurley, Justin Pettit,
Gregory Rose, Eelco Chaudron, Flavio Leitner, Florian Westphal,
Jiri Pirko, Rashid Khan, Sushil Kulkarni, Andy Gospodarek,
Roi Dayan, Yossi Kuperman, Or Gerlitz, Rony Efraim,
davem@davemloft.net, netdev
In-Reply-To: <6c976cc538f1f565b74bd2c750639af91a93adc1.1548285996.git.mleitner@redhat.com>
Hi Marcelo,
On Fri, Jan 25, 2019 at 12:32:31AM -0200, Marcelo Ricardo Leitner wrote:
> Hook on flow dissector's new interface on ConnTrack from previous patch.
>
> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> ---
> include/uapi/linux/pkt_cls.h | 9 +++++++++
> net/sched/cls_flower.c | 33 +++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
>
> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> index 95d0db2a8350dffb1dd20816591f3b179913fb2e..ba1f3bc01b2fdfd810e37a2b3853a1da1f838acf 100644
> --- a/include/uapi/linux/pkt_cls.h
> +++ b/include/uapi/linux/pkt_cls.h
> @@ -490,6 +490,15 @@ enum {
> TCA_FLOWER_KEY_PORT_DST_MIN, /* be16 */
> TCA_FLOWER_KEY_PORT_DST_MAX, /* be16 */
>
> + TCA_FLOWER_KEY_CT_ZONE, /* u16 */
> + TCA_FLOWER_KEY_CT_ZONE_MASK, /* u16 */
> + TCA_FLOWER_KEY_CT_STATE, /* u8 */
> + TCA_FLOWER_KEY_CT_STATE_MASK, /* u8 */
With the corresponding flow dissector patch this API is
exposing the contents of an instance of enum ip_conntrack_info
as an ABI for conntrack state.
I believe (after getting similar review for my geneve options macthing
patches for flower) that this exposes implementation details as an ABI
to a degree that is not desirable.
My suggested would be to define, say in the form of named bits,
an ABI, that describes the state information that is exposed.
These bits may not correspond directly to the implementation of
ip_conntrack_info.
I think there should also be some consideration of if a mask makes
sense for the state as, f.e. in the implementation of enum
ip_conntrack_info not all bit combinations are valid.
> + TCA_FLOWER_KEY_CT_MARK, /* u32 */
> + TCA_FLOWER_KEY_CT_MARK_MASK, /* u32 */
> + TCA_FLOWER_KEY_CT_LABEL, /* 128 bits */
> + TCA_FLOWER_KEY_CT_LABEL_MASK, /* 128 bits */
> +
> __TCA_FLOWER_MAX,
> };
...
^ permalink raw reply
* Re: [PATCH 3/7] net/ethernet: Add parse_protocol header_ops support
From: Willem de Bruijn @ 2019-01-25 13:52 UTC (permalink / raw)
To: Maxim Mikityanskiy
Cc: David S. Miller, Saeed Mahameed, Willem de Bruijn, Jason Wang,
Eric Dumazet, netdev@vger.kernel.org, Eran Ben Elisha,
Tariq Toukan
In-Reply-To: <AM6PR05MB5879042EACDF22EC71830577D19B0@AM6PR05MB5879.eurprd05.prod.outlook.com>
> > > > > diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> > > > > index 2c0af7b00715..e2f3b21cd72a 100644
> > > > > --- a/include/linux/etherdevice.h
> > > > > +++ b/include/linux/etherdevice.h
> > > > > @@ -44,6 +44,7 @@ int eth_header_cache(const struct neighbour *neigh,
> > > > struct hh_cache *hh,
> > > > > __be16 type);
> > > > > void eth_header_cache_update(struct hh_cache *hh, const struct
> > net_device
> > > > *dev,
> > > > > const unsigned char *haddr);
> > > > > +__be16 eth_header_parse_protocol(const struct sk_buff *skb);
> > > >
> > > > Does not need to be exposed in the header file or exported.
> > >
> > > Are you sure? All the other Ethernet header_ops callbacks are exported
> > > and declared in the header. I'm not sure about the reason why it is done
> > > in such a way, but my guess is that it will be useful if some driver
> > > decides to replace one callback in header_ops but to use the default
> > > ones for the rest of callbacks.
> >
> > I don't exactly follow this. But I think that many are exported
> > because Ethernet is so common that of these are also called directly
> > instead of through header_ops. Looking at other header_ops
> > implementations, or other such callback structs, shows many examples
> > where the members are static local functions.
>
> Yes, they are called directly indeed, but not all of them. E.g.,
> eth_header_parse is never called directly. On the other hand, look at
> drivers/net/macvlan.c:
>
> static const struct header_ops macvlan_hard_header_ops = {
> .create = macvlan_hard_header,
> .parse = eth_header_parse,
> .cache = eth_header_cache,
> .cache_update = eth_header_cache_update,
> };
>
> This is exactly what I am talking about. In order to support it,
> eth_header_parse_protocol needs to be exported. BTW, we should consider
> adding it to macvlan_hard_header_ops, ipvlan_header_ops and all other
> such structures.
Very good point. Okay, export it is then.
^ permalink raw reply
* Re: [PATCH RFC 0/3] Support fraglist GRO/GSO
From: Willem de Bruijn @ 2019-01-25 13:57 UTC (permalink / raw)
To: Steffen Klassert
Cc: Network Development, Willem de Bruijn, Paolo Abeni,
Jason A. Donenfeld
In-Reply-To: <20190125081417.GU3581@gauss3.secunet.de>
On Fri, Jan 25, 2019 at 3:14 AM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
>
> On Mon, Jan 14, 2019 at 12:09:22PM -0500, Willem de Bruijn wrote:
> > On Mon, Jan 14, 2019 at 7:50 AM Steffen Klassert
> > <steffen.klassert@secunet.com> wrote:
> > > On Sun, Dec 23, 2018 at 08:15:40PM -0500, Willem de Bruijn wrote:
> > > >
> > > > I would prefer to split the patch that adds UDP GRO on the forwarding
> > > > path into one that enables it for existing GRO (the hack you refer to
> > > > above) and a second one to optionally convert to listified processing.
> > >
> > > The hack was to skip the socket lookup. While that was ok for a
> > > forwarding test, it will affect the local receive path of course.
> > >
> > > Currently, I check if there is a GRO capable socket. If yes,
> > > do standard GRO. If no, do listified GRO regardless if packets
> > > are going to be forwarded or locally received. So UDP GRO is
> > > always on with this.
> >
> > I understand. What I suggest is to split into two: enable GRO on the
> > forwarding path independently from converting the method to listified
> > GRO.
>
> Ok, will do that in the next patchset.
>
> > > We would need to do an early route lookup to check if the packets
> > > are going to be forwarded or locally received. The current patchset
> > > does not implement this, but could be done. Maybe doing a route
> > > lookup based on some static key that will be enabled when forwarding
> > > on the receiving device is enabled.
> > >
> > > But even if the route lookup tell us that the packet should go the
> > > forwarding path, netfilter (bpfilter?) could reroute the packet.
> > > If we do an early route lookup, it would be good to have some early
> > > netfilter (bpfilter?) too, so that we can know which path the packets
> > > go. In this case we could do listified GRO even for TCP, if we can
> > > know that we have to do software segmentation later on.
> > >
> > > Btw. do we already have hardware that can do UDP LSO?
> >
> > Yes, mlx5
> >
> > I don't think that the route lookup is needed. If listified is cheaper
> > for local delivery, too, then we can make that the default unless a
> > device is active with h/w offload and ip forwarding is enabled. If it
> > isn't, then use it iff ip forwarding is enabled. I think it's fine to
> > mispredict between the two in edge cases with netfilter mangling, as
> > long as all paths can correctly handle both types of GRO packets.
>
> I'd need at least a route lookup for my usecase, because listified
> GRO is always cheaper when a xfrm transformation is needed (even for
> TCP). In this case is software GSO needed. So I'd need to either have
> an early route lookup or maybe some early ingress hook where a route
> lookup could be imlemented in.
Could you use a similar system wide approach as what we discussed
previous wrt hardware offload? Use listified only if (forwarding is enabled
and no device is registered that implements h/w segmentation offload) or
any path requires xfrm transformation (?).
> > > >
> > > > For both existing UDP GRO and listified, we should verify that this is
> > > > not a potential DoS vector before enabling by default.
> > >
> > > Yes, but should'nt this be the same as with TCP GRO?
> >
> > That is by now well-tested. I don't think we can simply assume
> > equivalence for UDP, also because that is easier to spoof.
>
> What would be a good test for this? I played with masscan
> and hping3, but did not notice any differences between
> net-next and net-next + UDP GRO patches.
That's a good indication. Anything that can send Mpps that will
get coalesced will do, so depending on pkt rate those may very
well be sufficient. Else pktgen.ko is interesting, as it explicitly
has an option to repeat send the same prepared skb.
^ 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