* [net-next v2 6/8] i40e: Log info when PF is entering and leaving Allmulti mode.
From: Jeff Kirsher @ 2019-08-05 18:54 UTC (permalink / raw)
To: davem
Cc: Czeslaw Zagorski, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190805185459.12846-1-jeffrey.t.kirsher@intel.com>
From: Czeslaw Zagorski <czeslawx.zagorski@intel.com>
Add log when PF is entering and leaving allmulti mode. The
change of PF state is visible in dmesg now. Without this commit,
entering and leaving allmulti mode is not logged in dmesg.
Signed-off-by: Czeslaw Zagorski <czeslawx.zagorski@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 423a4820af4c..6d456e579314 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -2530,6 +2530,10 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
vsi_name,
i40e_stat_str(hw, aq_ret),
i40e_aq_str(hw, hw->aq.asq_last_status));
+ } else {
+ dev_info(&pf->pdev->dev, "%s is %s allmulti mode.\n",
+ vsi->netdev->name,
+ cur_multipromisc ? "entering" : "leaving");
}
}
--
2.21.0
^ permalink raw reply related
* [net-next v2 7/8] i40e: verify string count matches even on early return
From: Jeff Kirsher @ 2019-08-05 18:54 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190805185459.12846-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Similar to i40e_get_ethtool_stats, add a goto to verify that the data
pointer for the strings lines up with the expected stats count. This
helps ensure that bugs are not introduced when adding stats.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index ceca57a261dc..01e4615b1b4b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -2342,7 +2342,7 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
}
if (vsi != pf->vsi[pf->lan_vsi] || pf->hw.partition_id != 1)
- return;
+ goto check_data_pointer;
i40e_add_stat_strings(&data, i40e_gstrings_veb_stats);
@@ -2354,6 +2354,7 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
for (i = 0; i < I40E_MAX_USER_PRIORITY; i++)
i40e_add_stat_strings(&data, i40e_gstrings_pfc_stats, i);
+check_data_pointer:
WARN_ONCE(data - p != i40e_get_stats_count(netdev) * ETH_GSTRING_LEN,
"stat strings count mismatch!");
}
--
2.21.0
^ permalink raw reply related
* [net-next v2 3/8] i40e: don't report link up for a VF who hasn't enabled queues
From: Jeff Kirsher @ 2019-08-05 18:54 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190805185459.12846-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Commit d3d657a90850 ("i40e: update VFs of link state after
GET_VF_RESOURCES") modified the PF driver to notify a VF of
its link status immediately after it requests resources.
This was intended to fix reporting on VF drivers, so that they would
properly report link status.
However, some older VF drivers do not respond well to receiving a link
up notification before queues are enabled. This can cause their state
machine to think that it is safe to send traffic. This results in a Tx
hang on the VF.
More recent versions of the old i40evf and all versions of iavf are
resilient to these early link status messages. However, if a VM happens
to run an older version of the VF driver, this can be problematic.
Record whether the PF has actually enabled queues for the VF. When
reporting link status, always report link down if the queues aren't
enabled. In this way, the VF driver will never receive a link up
notification until after its queues are enabled.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 13 ++++++++++++-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 1 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 02b09a8ad54c..12f04f36e357 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -55,7 +55,12 @@ static void i40e_vc_notify_vf_link_state(struct i40e_vf *vf)
pfe.event = VIRTCHNL_EVENT_LINK_CHANGE;
pfe.severity = PF_EVENT_SEVERITY_INFO;
- if (vf->link_forced) {
+
+ /* Always report link is down if the VF queues aren't enabled */
+ if (!vf->queues_enabled) {
+ pfe.event_data.link_event.link_status = false;
+ pfe.event_data.link_event.link_speed = 0;
+ } else if (vf->link_forced) {
pfe.event_data.link_event.link_status = vf->link_up;
pfe.event_data.link_event.link_speed =
(vf->link_up ? VIRTCHNL_LINK_SPEED_40GB : 0);
@@ -65,6 +70,7 @@ static void i40e_vc_notify_vf_link_state(struct i40e_vf *vf)
pfe.event_data.link_event.link_speed =
i40e_virtchnl_link_speed(ls->link_speed);
}
+
i40e_aq_send_msg_to_vf(hw, abs_vf_id, VIRTCHNL_OP_EVENT,
0, (u8 *)&pfe, sizeof(pfe), NULL);
}
@@ -2364,6 +2370,8 @@ static int i40e_vc_enable_queues_msg(struct i40e_vf *vf, u8 *msg)
}
}
+ vf->queues_enabled = true;
+
error_param:
/* send the response to the VF */
return i40e_vc_send_resp_to_vf(vf, VIRTCHNL_OP_ENABLE_QUEUES,
@@ -2385,6 +2393,9 @@ static int i40e_vc_disable_queues_msg(struct i40e_vf *vf, u8 *msg)
struct i40e_pf *pf = vf->pf;
i40e_status aq_ret = 0;
+ /* Immediately mark queues as disabled */
+ vf->queues_enabled = false;
+
if (!test_bit(I40E_VF_STATE_ACTIVE, &vf->vf_states)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h
index f65cc0c16550..7164b9bb294f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h
@@ -99,6 +99,7 @@ struct i40e_vf {
unsigned int tx_rate; /* Tx bandwidth limit in Mbps */
bool link_forced;
bool link_up; /* only valid if VF link is forced */
+ bool queues_enabled; /* true if the VF queues are enabled */
bool spoofchk;
u16 num_mac;
u16 num_vlan;
--
2.21.0
^ permalink raw reply related
* [net-next v2 0/8][pull request] 40GbE Intel Wired LAN Driver Updates 2019-08-05
From: Jeff Kirsher @ 2019-08-05 18:54 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to i40e driver only.
Dmitrii adds missing statistic counters for VEB and VEB TC's.
Slawomir adds support for logging the "Disable Firmware LLDP" flag
option and its current status.
Jake fixes an issue where VF's being notified of their link status
before their queues are enabled which was causing issues. So always
report link status down when the VF queues are not enabled. Also adds
future proofing when statistics are added or removed by adding checks to
ensure the data pointer for the strings lines up with the expected
statistics count.
Czeslaw fixes the advertised mode reported in ethtool for FEC, where the
"None BaseR RS" was always being displayed no matter what the mode it
was in. Also added logging information when the PF is entering or
leaving "allmulti" (or promiscuous) mode. Fixed up the logging logic
for VF's when leaving multicast mode to not include unicast as well.
v2: drop Aleksandr's patch (previously patch #2 in the series) to
display the VF MAC address that is set by the VF while community
feedback is addressed.
The following are changes since commit a9e21bea1f815c2ec917ecc0efe0a7049c825d5b:
][next] selftests: nettest: fix spelling mistake: "potocol" -> "protocol"
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Czeslaw Zagorski (3):
i40e: Update visual effect for advertised FEC mode.
i40e: Log info when PF is entering and leaving Allmulti mode.
i40e: Remove unicast log when VF is leaving multicast mode.
Dmitrii Golovanov (1):
i40e: fix incorrect ethtool statistics veb and veb.tc_
Jacob Keller (2):
i40e: don't report link up for a VF who hasn't enabled queues
i40e: verify string count matches even on early return
Jeff Kirsher (1):
i40e: fix code comments
Slawomir Laba (1):
i40e: Log disable-fw-lldp flag change by ethtool
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
.../net/ethernet/intel/i40e/i40e_ethtool.c | 74 +++++++++++--------
drivers/net/ethernet/intel/i40e/i40e_main.c | 11 ++-
.../ethernet/intel/i40e/i40e_virtchnl_pf.c | 54 +++++++++-----
.../ethernet/intel/i40e/i40e_virtchnl_pf.h | 1 +
5 files changed, 90 insertions(+), 51 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH net 0/2] flow_offload hardware priority fixes
From: Jakub Kicinski @ 2019-08-05 19:04 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, marcelo.leitner, jiri, wenxu,
saeedm, paulb, gerlitz.or
In-Reply-To: <20190803070854.zb3nvwj4ubx2mzy6@salvia>
On Sat, 3 Aug 2019 09:08:54 +0200, Pablo Neira Ayuso wrote:
> The idea is that every subsystem (ethtool, tc, nf) sets up/binds its
> own flow_block object. And each flow_block object has its own priority
> range space. So whatever priority the user specifies only applies to
> the specific subsystem.
Right, okay so that part is pretty obvious but thanks for spelling it
out.
Are you also agreeing that priorities of blocks, not rules within
a block are dictated by the order of processing within the kernel?
IOW TC blocks are _always_ before nft blocks?
> Drivers still need to be updated to support for more than one
> flow_block/subsystem binding at this stage though.
^ permalink raw reply
* Re: [PATCH] tools: bpftool: fix reading from /proc/config.gz
From: Jakub Kicinski @ 2019-08-05 19:06 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Peter Wu, Alexei Starovoitov, Daniel Borkmann, netdev,
Stanislav Fomichev, Quentin Monnet
In-Reply-To: <20190805152936.GE4544@mini-arch>
On Mon, 5 Aug 2019 08:29:36 -0700, Stanislav Fomichev wrote:
> On 08/05, Peter Wu wrote:
> > /proc/config has never existed as far as I can see, but /proc/config.gz
> > is present on Arch Linux. Execute an external gunzip program to avoid
> > linking to zlib and rework the option scanning code since a pipe is not
> > seekable. This also fixes a file handle leak on some error paths.
> Thanks for doing that! One question: why not link against -lz instead?
> With fork/execing gunzip you're just hiding this dependency.
>
> You can add something like this to the Makefile:
> ifeq ($(feature-zlib),1)
> CLFAGS += -DHAVE_ZLIB
> endif
>
> And then conditionally add support for config.gz. Thoughts?
+1
^ permalink raw reply
* Re: [PATCH iproute2-next] rdma: Add driver QP type string
From: David Ahern @ 2019-08-05 19:08 UTC (permalink / raw)
To: Gal Pressman, Stephen Hemminger; +Cc: netdev, linux-rdma, Leon Romanovsky
In-Reply-To: <20190804080756.58364-1-galpress@amazon.com>
On 8/4/19 2:07 AM, Gal Pressman wrote:
> RDMA resource tracker now tracks driver QPs as well, add driver QP type
> string to qp_types_to_str function.
"now" means which kernel release? Leon: should this be in master or -next?
>
> Signed-off-by: Gal Pressman <galpress@amazon.com>
> ---
> rdma/res.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/rdma/res.c b/rdma/res.c
> index ef863f142eca..97a7b9640185 100644
> --- a/rdma/res.c
> +++ b/rdma/res.c
> @@ -148,9 +148,11 @@ const char *qp_types_to_str(uint8_t idx)
> "UC", "UD", "RAW_IPV6",
> "RAW_ETHERTYPE",
> "UNKNOWN", "RAW_PACKET",
> - "XRC_INI", "XRC_TGT" };
> + "XRC_INI", "XRC_TGT",
> + [0xFF] = "DRIVER",
> + };
>
> - if (idx < ARRAY_SIZE(qp_types_str))
> + if (idx < ARRAY_SIZE(qp_types_str) && qp_types_str[idx])
> return qp_types_str[idx];
> return "UNKNOWN";
> }
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Alexei Starovoitov @ 2019-08-05 19:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Song Liu, Kees Cook, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Lorenz Bauer, Jann Horn, Greg KH,
Linux API, LSM List
In-Reply-To: <CALCETrXX-Jeb4wiQuL6FUai4wNMmMiUxuLLh_Lb9mT7h=0GgAw@mail.gmail.com>
On Mon, Aug 05, 2019 at 10:23:10AM -0700, Andy Lutomirski wrote:
>
> I refreshed the branch again. I had a giant hole in my previous idea
> that we could deprivilege program loading: some BPF functions need
> privilege. Now I have a changelog comment to that effect and a patch
> that sketches out a way to addressing this.
>
> I don't think I'm going to have time soon to actually get any of this
> stuff mergeable, and it would be fantastic if you or someone else who
> likes working of bpf were to take this code and run with it. Feel
> free to add my Signed-off-by, and I'd be happy to help review.
Thanks a lot for working on patches and helping us with the design!
Can you resend the patches to the mailing list?
It's kinda hard to reply/review to patches that are somewhere in the web.
I'm still trying to understand the main idea.
If I'm reading things correctly:
patch 1 "add access permissions to bpf fds"
just passes the flags ?
patch 2 "Don't require mknod() permission to pin an object"
makes sense in isolation.
patch 3 "Allow creating all program types without privilege"
is not right.
patch 4 "Add a way to mark functions as requiring privilege"
is an interesting idea, but I don't think it helps that much.
So the main thing we're trying to solve with augmented bpf syscall
and/or /dev/bpf is to be able to use root-only features of bpf when
trused process already dropped root permissions.
These features include bpf2bpf calls, bounded loops, special maps (like LPM), etc.
Attaching to a cgroup already has file based permission checks.
The user needs to open cgroup directory to attach.
acls on cgroup dir can already be used to prevent attaching to
certain parts of cgroup hierarchy.
It seems this discussion is centered around making /dev/bpf to
let unpriv (and not trusted) users (humans) to do bpf.
That's not quite the case.
It's a good use case, but not the one we're after at the moment.
In our enviroment bpftrace, bpftool, all bcc tools are pre-installed
and the users (humans) can simply 'sudo' to run them.
Adding suid bit to installed bpftool binary is doable, but there is no need.
'sudo' works just fine.
What we need is to drop privileges sooner in daemons like systemd.
Container management daemon runs in the nested containers.
These trusted daemons need to have access to full bpf, but they
don't want to be root all the time.
They cannot flip back and forth via seteuid to root every time they
need to do bpf.
Hence the idea is to have a file that this daemon can open,
then drop privileges and still keep doing bpf things because FD is held.
Outer container daemon can pass this /dev/bpf's FD to inner daemon, etc.
This /dev/bpf would be accessible to root only.
There is no desire to open it up to non-root.
It seems there is concern that /dev/bpf is unnecessary special.
How about we combine bpffs and /dev/bpf ideas?
Like we can have a special file name in bpffs.
The root would do 'touch /sys/fs/bpf/privileges' and it would behave
just like /dev/bpf, but now it can be in any bpffs directory and acls
to bpffs mount would work as-is.
CAP_BPF is also good idea. I think for the enviroment where untrusted
and unprivileged users want to run 'bpftrace' that would be perfect mechanism.
getcap /bin/bpftrace would have cap_bpf, cap_kprobe and whatever else.
Sort of like /bin/ping.
But I don't see how cap_bpf helps to solve our trusted root daemon problem.
imo open ("/sys/fs/bpf/privileges") and pass that FD into bpf syscall
is the only viable mechanism.
Note the verifier does very different amount of work for unpriv vs root.
It does speculative execution analysis, pointer leak checks for unpriv.
So we gotta pass special flag to the verifier to make it act like it's
loading a program for root.
^ permalink raw reply
* [PATCH net-next] ibmveth: Allow users to update reported speed and duplex
From: Thomas Falcon @ 2019-08-05 19:24 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Thomas Falcon
Reported ethtool link settings for the ibmveth driver are currently
hardcoded and no longer reflect the actual capabilities of supported
hardware. There is no interface designed for retrieving this information
from device firmware nor is there any way to update current settings
to reflect observed or expected link speeds.
To avoid confusion, initially define speed and duplex as unknown and
allow the user to alter these settings to match the expected
capabilities of underlying hardware if needed. This update would allow
the use of configurations that rely on certain link speed settings,
such as LACP. This patch is based on the implementation in virtio_net.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmveth.c | 83 ++++++++++++++++++++++++++++----------
drivers/net/ethernet/ibm/ibmveth.h | 3 ++
2 files changed, 64 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
index d654c23..77af9c2 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -712,31 +712,68 @@ static int ibmveth_close(struct net_device *netdev)
return 0;
}
-static int netdev_get_link_ksettings(struct net_device *dev,
- struct ethtool_link_ksettings *cmd)
+static bool
+ibmveth_validate_ethtool_cmd(const struct ethtool_link_ksettings *cmd)
{
- u32 supported, advertising;
-
- supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
- SUPPORTED_FIBRE);
- advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
- ADVERTISED_FIBRE);
- cmd->base.speed = SPEED_1000;
- cmd->base.duplex = DUPLEX_FULL;
- cmd->base.port = PORT_FIBRE;
- cmd->base.phy_address = 0;
- cmd->base.autoneg = AUTONEG_ENABLE;
-
- ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
- supported);
- ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
- advertising);
+ struct ethtool_link_ksettings diff1 = *cmd;
+ struct ethtool_link_ksettings diff2 = {};
+
+ diff2.base.port = PORT_OTHER;
+ diff1.base.speed = 0;
+ diff1.base.duplex = 0;
+ diff1.base.cmd = 0;
+ diff1.base.link_mode_masks_nwords = 0;
+ ethtool_link_ksettings_zero_link_mode(&diff1, advertising);
+
+ return !memcmp(&diff1.base, &diff2.base, sizeof(diff1.base)) &&
+ bitmap_empty(diff1.link_modes.supported,
+ __ETHTOOL_LINK_MODE_MASK_NBITS) &&
+ bitmap_empty(diff1.link_modes.advertising,
+ __ETHTOOL_LINK_MODE_MASK_NBITS) &&
+ bitmap_empty(diff1.link_modes.lp_advertising,
+ __ETHTOOL_LINK_MODE_MASK_NBITS);
+}
+
+static int ibmveth_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct ibmveth_adapter *adapter = netdev_priv(dev);
+ u32 speed;
+ u8 duplex;
+
+ speed = cmd->base.speed;
+ duplex = cmd->base.duplex;
+ /* don't allow custom speed and duplex */
+ if (!ethtool_validate_speed(speed) ||
+ !ethtool_validate_duplex(duplex) ||
+ !ibmveth_validate_ethtool_cmd(cmd))
+ return -EINVAL;
+ adapter->speed = speed;
+ adapter->duplex = duplex;
return 0;
}
-static void netdev_get_drvinfo(struct net_device *dev,
- struct ethtool_drvinfo *info)
+static int ibmveth_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct ibmveth_adapter *adapter = netdev_priv(dev);
+
+ cmd->base.speed = adapter->speed;
+ cmd->base.duplex = adapter->duplex;
+ cmd->base.port = PORT_OTHER;
+
+ return 0;
+}
+
+static void ibmveth_init_link_settings(struct ibmveth_adapter *adapter)
+{
+ adapter->duplex = DUPLEX_UNKNOWN;
+ adapter->speed = SPEED_UNKNOWN;
+}
+
+static void ibmveth_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *info)
{
strlcpy(info->driver, ibmveth_driver_name, sizeof(info->driver));
strlcpy(info->version, ibmveth_driver_version, sizeof(info->version));
@@ -965,12 +1002,13 @@ static void ibmveth_get_ethtool_stats(struct net_device *dev,
}
static const struct ethtool_ops netdev_ethtool_ops = {
- .get_drvinfo = netdev_get_drvinfo,
+ .get_drvinfo = ibmveth_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_strings = ibmveth_get_strings,
.get_sset_count = ibmveth_get_sset_count,
.get_ethtool_stats = ibmveth_get_ethtool_stats,
- .get_link_ksettings = netdev_get_link_ksettings,
+ .get_link_ksettings = ibmveth_get_link_ksettings,
+ .set_link_ksettings = ibmveth_set_link_ksettings
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@ -1647,6 +1685,7 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
adapter->netdev = netdev;
adapter->mcastFilterSize = *mcastFilterSize_p;
adapter->pool_config = 0;
+ ibmveth_init_link_settings(adapter);
netif_napi_add(netdev, &adapter->napi, ibmveth_poll, 16);
diff --git a/drivers/net/ethernet/ibm/ibmveth.h b/drivers/net/ethernet/ibm/ibmveth.h
index 4e9bf34..db96c88 100644
--- a/drivers/net/ethernet/ibm/ibmveth.h
+++ b/drivers/net/ethernet/ibm/ibmveth.h
@@ -162,6 +162,9 @@ struct ibmveth_adapter {
u64 tx_send_failed;
u64 tx_large_packets;
u64 rx_large_packets;
+ /* Ethtool settings */
+ u8 duplex;
+ u32 speed;
};
/*
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH bpf-next 1/2] selftests/bpf: add loop test 4
From: Andrii Nakryiko @ 2019-08-05 19:45 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Networking, bpf, Kernel Team
In-Reply-To: <20190802233344.863418-2-ast@kernel.org>
On Sat, Aug 3, 2019 at 8:19 PM Alexei Starovoitov <ast@kernel.org> wrote:
>
> Add a test that returns a 'random' number between [0, 2^20)
> If state pruning is not working correctly for loop body the number of
> processed insns will be 2^20 * num_of_insns_in_loop_body and the program
> will be rejected.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> .../bpf/prog_tests/bpf_verif_scale.c | 1 +
> tools/testing/selftests/bpf/progs/loop4.c | 23 +++++++++++++++++++
> 2 files changed, 24 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/progs/loop4.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
> index b4be96162ff4..757e39540eda 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
> @@ -71,6 +71,7 @@ void test_bpf_verif_scale(void)
>
> { "loop1.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
> { "loop2.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
> + { "loop4.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
>
> /* partial unroll. 19k insn in a loop.
> * Total program size 20.8k insn.
> diff --git a/tools/testing/selftests/bpf/progs/loop4.c b/tools/testing/selftests/bpf/progs/loop4.c
> new file mode 100644
> index 000000000000..3e7ee14fddbd
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/loop4.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2019 Facebook
> +#include <linux/sched.h>
> +#include <linux/ptrace.h>
> +#include <stdint.h>
> +#include <stddef.h>
> +#include <stdbool.h>
> +#include <linux/bpf.h>
> +#include "bpf_helpers.h"
> +
> +char _license[] SEC("license") = "GPL";
> +
> +SEC("socket")
> +int combinations(volatile struct __sk_buff* skb)
> +{
> + int ret = 0, i;
> +
> +#pragma nounroll
> + for (i = 0; i < 20; i++)
> + if (skb->len)
> + ret |= 1 << i;
So I think the idea is that because verifier shouldn't know whether
skb->len is zero or not, then you have two outcomes on every iteration
leading to 2^20 states, right?
But I'm afraid that verifier can eventually be smart enough (if it's
not already, btw), to figure out that ret can be either 0 or ((1 <<
21) - 1), actually. If skb->len is put into separate register, then
that register's bounds will be established on first loop iteration as
either == 0 on one branch or (0, inf) on another branch, after which
all subsequent iterations will not branch at all (one or the other
branch will be always taken).
It's also possible that LLVM/Clang is smart enough already to figure
this out on its own and optimize loop into.
if (skb->len) {
for (i = 0; i < 20; i++)
ret |= 1 << i;
}
So two complains:
1. Let's obfuscate this a bit more, e.g., with testing (skb->len &
(1<<i)) instead, so that result really depends on actual length of the
packet.
2. Is it possible to somehow turn off this precision tracking (e.g.,
running not under root, maybe?) and see that this same program fails
in that case? That way we'll know test actually validates what we
think it validates.
Thoughts?
> + return ret;
> +}
> --
> 2.20.0
>
^ permalink raw reply
* [net] ixgbe: fix possible deadlock in ixgbe_service_task()
From: Jeff Kirsher @ 2019-08-05 20:04 UTC (permalink / raw)
To: davem; +Cc: Taehee Yoo, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
From: Taehee Yoo <ap420073@gmail.com>
ixgbe_service_task() calls unregister_netdev() under rtnl_lock().
But unregister_netdev() internally calls rtnl_lock().
So deadlock would occur.
Fixes: 59dd45d550c5 ("ixgbe: firmware recovery mode")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712d6529..3386e752e458 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7898,9 +7898,7 @@ static void ixgbe_service_task(struct work_struct *work)
}
if (ixgbe_check_fw_error(adapter)) {
if (!test_bit(__IXGBE_DOWN, &adapter->state)) {
- rtnl_lock();
unregister_netdev(adapter->netdev);
- rtnl_unlock();
}
ixgbe_service_event_complete(adapter);
return;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH bpf-next 1/2] selftests/bpf: add loop test 4
From: Yonghong Song @ 2019-08-05 20:04 UTC (permalink / raw)
To: Andrii Nakryiko, Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Networking, bpf, Kernel Team
In-Reply-To: <CAEf4Bzb==_gzT78_oN7AfiGHrqGXdYK+oEamkxpfEjP5fzr_UA@mail.gmail.com>
On 8/5/19 12:45 PM, Andrii Nakryiko wrote:
> On Sat, Aug 3, 2019 at 8:19 PM Alexei Starovoitov <ast@kernel.org> wrote:
>>
>> Add a test that returns a 'random' number between [0, 2^20)
>> If state pruning is not working correctly for loop body the number of
>> processed insns will be 2^20 * num_of_insns_in_loop_body and the program
>> will be rejected.
>>
>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>> ---
>> .../bpf/prog_tests/bpf_verif_scale.c | 1 +
>> tools/testing/selftests/bpf/progs/loop4.c | 23 +++++++++++++++++++
>> 2 files changed, 24 insertions(+)
>> create mode 100644 tools/testing/selftests/bpf/progs/loop4.c
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
>> index b4be96162ff4..757e39540eda 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
>> @@ -71,6 +71,7 @@ void test_bpf_verif_scale(void)
>>
>> { "loop1.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
>> { "loop2.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
>> + { "loop4.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
>>
>> /* partial unroll. 19k insn in a loop.
>> * Total program size 20.8k insn.
>> diff --git a/tools/testing/selftests/bpf/progs/loop4.c b/tools/testing/selftests/bpf/progs/loop4.c
>> new file mode 100644
>> index 000000000000..3e7ee14fddbd
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/progs/loop4.c
>> @@ -0,0 +1,23 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2019 Facebook
>> +#include <linux/sched.h>
>> +#include <linux/ptrace.h>
>> +#include <stdint.h>
>> +#include <stddef.h>
>> +#include <stdbool.h>
>> +#include <linux/bpf.h>
>> +#include "bpf_helpers.h"
>> +
>> +char _license[] SEC("license") = "GPL";
>> +
>> +SEC("socket")
>> +int combinations(volatile struct __sk_buff* skb)
>> +{
>> + int ret = 0, i;
>> +
>> +#pragma nounroll
>> + for (i = 0; i < 20; i++)
>> + if (skb->len)
>> + ret |= 1 << i;
>
> So I think the idea is that because verifier shouldn't know whether
> skb->len is zero or not, then you have two outcomes on every iteration
> leading to 2^20 states, right?
>
> But I'm afraid that verifier can eventually be smart enough (if it's
> not already, btw), to figure out that ret can be either 0 or ((1 <<
> 21) - 1), actually. If skb->len is put into separate register, then
> that register's bounds will be established on first loop iteration as
> either == 0 on one branch or (0, inf) on another branch, after which
> all subsequent iterations will not branch at all (one or the other
> branch will be always taken).
>
> It's also possible that LLVM/Clang is smart enough already to figure
> this out on its own and optimize loop into.
>
>
> if (skb->len) {
> for (i = 0; i < 20; i++)
> ret |= 1 << i;
> }
We have
volatile struct __sk_buff* skb
So from the source code, skb->len could be different for each
iteration. The compiler cannot do the above optimization.
>
>
> So two complains:
>
> 1. Let's obfuscate this a bit more, e.g., with testing (skb->len &
> (1<<i)) instead, so that result really depends on actual length of the
> packet.
> 2. Is it possible to somehow turn off this precision tracking (e.g.,
> running not under root, maybe?) and see that this same program fails
> in that case? That way we'll know test actually validates what we
> think it validates.
>
> Thoughts?
>
>> + return ret;
>> +}
>> --
>> 2.20.0
>>
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: Saeed Mahameed @ 2019-08-05 20:06 UTC (permalink / raw)
To: hslester96@gmail.com, leon@kernel.org
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CANhBUQ0tUTXQKq__zvhNCUxXTFfDyr2xKF+Cwupod9xmvSrw2A@mail.gmail.com>
On Mon, 2019-08-05 at 14:55 +0800, Chuhong Yuan wrote:
> On Mon, Aug 5, 2019 at 2:13 PM Leon Romanovsky <leon@kernel.org>
> wrote:
> > On Sun, Aug 04, 2019 at 10:44:47PM +0800, Chuhong Yuan wrote:
> > > On Sun, Aug 4, 2019 at 8:59 PM Leon Romanovsky <leon@kernel.org>
> > > wrote:
> > > > On Sat, Aug 03, 2019 at 12:48:28AM +0800, Chuhong Yuan wrote:
> > > > > refcount_t is better for reference counters since its
> > > > > implementation can prevent overflows.
> > > > > So convert atomic_t ref counters to refcount_t.
> > > >
> > > > I'm not thrilled to see those automatic conversion patches,
> > > > especially
> > > > for flows which can't overflow. There is nothing wrong in using
> > > > atomic_t
> > > > type of variable, do you have in mind flow which will cause to
> > > > overflow?
> > > >
> > > > Thanks
> > >
> > > I have to say that these patches are not done automatically...
> > > Only the detection of problems is done by a script.
> > > All conversions are done manually.
> >
> > Even worse, you need to audit usage of atomic_t and replace there
> > it can overflow.
> >
> > > I am not sure whether the flow can cause an overflow.
> >
> > It can't.
> >
> > > But I think it is hard to ensure that a data path is impossible
> > > to have problems in any cases including being attacked.
> >
> > It is not data path, and I doubt that such conversion will be
> > allowed
> > in data paths without proving that no performance regression is
> > introduced.
> > > So I think it is better to do this minor revision to prevent
> > > potential risk, just like we have done in mlx5/core/cq.c.
> >
> > mlx5/core/cq.c is a different beast, refcount there means actual
> > users
> > of CQ which are limited in SW, so in theory, they have potential
> > to be overflown.
> >
> > It is not the case here, there your are adding new port.
> > There is nothing wrong with atomic_t.
> >
>
> Thanks for your explanation!
> I will pay attention to this point in similar cases.
> But it seems that the semantic of refcount is not always as clear as
> here...
>
Semantically speaking, there is nothing wrong with moving to refcount_t
in the case of vxlan ports.. it also seems more accurate and will
provide the type protection, even if it is not necessary. Please let me
know what is the verdict here, i can apply this patch to net-next-mlx5.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH net 1/2] net/tls: partially revert fix transition through disconnect with close
From: David Miller @ 2019-08-05 20:15 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, oss-drivers, edumazet, davejwatson, borisp, aviadye,
john.fastabend, daniel
In-Reply-To: <20190801213602.19634-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 1 Aug 2019 14:36:01 -0700
> Looks like we were slightly overzealous with the shutdown()
> cleanup. Even though the sock->sk_state can reach CLOSED again,
> socket->state will not got back to SS_UNCONNECTED once
> connections is ESTABLISHED. Meaning we will see EISCONN if
> we try to reconnect, and EINVAL if we try to listen.
>
> Only listen sockets can be shutdown() and reused, but since
> ESTABLISHED sockets can never be re-connected() or used for
> listen() we don't need to try to clean up the ULP state early.
>
> Fixes: 32857cf57f92 ("net/tls: fix transition through disconnect with close")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net 2/2] selftests/tls: add a litmus test for the socket reuse through shutdown
From: David Miller @ 2019-08-05 20:16 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, oss-drivers, edumazet, davejwatson, borisp, aviadye,
john.fastabend, daniel
In-Reply-To: <20190801213602.19634-2-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 1 Aug 2019 14:36:02 -0700
> Make sure that shutdown never works, and at the same time document how
> I tested to came to the conclusion that currently reuse is not possible.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: Fix unbalanced rcu locking in rt6_update_exception_stamp_rt
From: David Miller @ 2019-08-05 20:17 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20190801213635.9278-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Thu, 1 Aug 2019 14:36:35 -0700
> From: David Ahern <dsahern@gmail.com>
>
> The nexthop path in rt6_update_exception_stamp_rt needs to call
> rcu_read_unlock if it fails to find a fib6_nh match rather than
> just returning.
>
> Fixes: e659ba31d806 ("ipv6: Handle all fib6_nh in a nexthop in exception handling")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: have a single rcu unlock point in __ip6_rt_update_pmtu
From: David Miller @ 2019-08-05 20:18 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20190801221808.18321-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Thu, 1 Aug 2019 15:18:08 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Simplify the unlock path in __ip6_rt_update_pmtu by using a
> single point where rcu_read_unlock is called.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] gve: Fix case where desc_cnt and data_cnt can get out of sync
From: David Miller @ 2019-08-05 20:19 UTC (permalink / raw)
To: csully; +Cc: netdev, sagis
In-Reply-To: <20190801230731.142536-1-csully@google.com>
From: Catherine Sullivan <csully@google.com>
Date: Thu, 1 Aug 2019 16:07:31 -0700
> desc_cnt and data_cnt should always be equal. In the case of a dropped
> packet desc_cnt was still getting updated (correctly), data_cnt
> was not. To eliminate this bug and prevent it from recurring this
> patch combines them into one ring level cnt.
>
> Signed-off-by: Catherine Sullivan <csully@google.com>
> Reviewed-by: Sagi Shahar <sagis@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] selftests: Add l2tp tests
From: David Miller @ 2019-08-05 20:20 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20190801235421.8344-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Thu, 1 Aug 2019 16:54:21 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Add IPv4 and IPv6 l2tp tests. Current set is over IP and with
> IPsec.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> ---
> The ipsec tests expose a netdev refcount leak that I have not had
> time to track down, but the tests themselves are good.
Don't you need to add this to the Makefile too?
^ permalink raw reply
* Re: [PATCH net-next] cnic: Explicitly initialize all reference counts to 0.
From: David Miller @ 2019-08-05 20:22 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, hslester96, rmody, GR-Linux-NIC-Dev
In-Reply-To: <1564726671-7094-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 2 Aug 2019 02:17:51 -0400
> The driver is relying on zero'ed allocated memory and does not
> explicitly call atomic_set() to initialize the ref counts to 0. Add
> these atomic_set() calls so that it will be more straight forward
> to convert atomic ref counts to refcount_t.
>
> Reported-by: Chuhong Yuan <hslester96@gmail.com>
> Cc: Rasesh Mody <rmody@marvell.com>
> Cc: <GR-Linux-NIC-Dev@marvell.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/smc: do not schedule tx_work in SMC_CLOSED state
From: David Miller @ 2019-08-05 20:24 UTC (permalink / raw)
To: kgraul; +Cc: netdev, linux-s390, gor, heiko.carstens, raspl, ubraun
In-Reply-To: <20190802081638.56207-1-kgraul@linux.ibm.com>
From: Karsten Graul <kgraul@linux.ibm.com>
Date: Fri, 2 Aug 2019 10:16:38 +0200
> From: Ursula Braun <ubraun@linux.ibm.com>
>
> The setsockopts options TCP_NODELAY and TCP_CORK may schedule the
> tx worker. Make sure the socket is not yet moved into SMC_CLOSED
> state (for instance by a shutdown SHUT_RDWR call).
>
> Reported-by: syzbot+92209502e7aab127c75f@syzkaller.appspotmail.com
> Reported-by: syzbot+b972214bb803a343f4fe@syzkaller.appspotmail.com
> Fixes: 01d2f7e2cdd31 ("net/smc: sockopts TCP_NODELAY and TCP_CORK")
> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
> Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net/smc: avoid fallback in case of non-blocking connect
From: David Miller @ 2019-08-05 20:25 UTC (permalink / raw)
To: kgraul; +Cc: netdev, linux-s390, gor, heiko.carstens, raspl, ubraun
In-Reply-To: <20190802084750.5518-1-kgraul@linux.ibm.com>
From: Karsten Graul <kgraul@linux.ibm.com>
Date: Fri, 2 Aug 2019 10:47:50 +0200
> From: Ursula Braun <ubraun@linux.ibm.com>
>
> FASTOPEN is not possible with SMC. sendmsg() with msg_flag MSG_FASTOPEN
> triggers a fallback to TCP if the socket is in state SMC_INIT.
> But if a nonblocking connect is already started, fallback to TCP
> is no longer possible, even though the socket may still be in state
> SMC_INIT.
> And if a nonblocking connect is already started, a listen() call
> does not make sense.
>
> Reported-by: syzbot+bd8cc73d665590a1fcad@syzkaller.appspotmail.com
> Fixes: 50717a37db032 ("net/smc: nonblocking connect rework")
> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
> Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [patch 1/1] drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case
From: David Miller @ 2019-08-05 20:31 UTC (permalink / raw)
To: arnaud.patard; +Cc: netdev, andrew
In-Reply-To: <20190802083310.772136040@rtp-net.org>
From: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Date: Fri, 02 Aug 2019 10:32:40 +0200
> Orion5.x systems are still using machine files and not device-tree.
> Commit 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be
> specified for orion-mdio") has replaced devm_clk_get() with of_clk_get(),
> leading to a oops at boot and not working network, as reported in
> https://lists.debian.org/debian-arm/2019/07/msg00088.html and possibly in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712.
>
> Link: https://lists.debian.org/debian-arm/2019/07/msg00088.html
> Fixes: 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net v4] net: bridge: move default pvid init/deinit to NETDEV_REGISTER/UNREGISTER
From: David Miller @ 2019-08-05 20:33 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, bridge, michael-dev
In-Reply-To: <20190802105736.26767-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Fri, 2 Aug 2019 13:57:36 +0300
> Most of the bridge device's vlan init bugs come from the fact that its
> default pvid is created at the wrong time, way too early in ndo_init()
> before the device is even assigned an ifindex. It introduces a bug when the
> bridge's dev_addr is added as fdb during the initial default pvid creation
> the notification has ifindex/NDA_MASTER both equal to 0 (see example below)
> which really makes no sense for user-space[0] and is wrong.
> Usually user-space software would ignore such entries, but they are
> actually valid and will eventually have all necessary attributes.
> It makes much more sense to send a notification *after* the device has
> registered and has a proper ifindex allocated rather than before when
> there's a chance that the registration might still fail or to receive
> it with ifindex/NDA_MASTER == 0. Note that we can remove the fdb flush
> from br_vlan_flush() since that case can no longer happen. At
> NETDEV_REGISTER br->default_pvid is always == 1 as it's initialized by
> br_vlan_init() before that and at NETDEV_UNREGISTER it can be anything
> depending why it was called (if called due to NETDEV_REGISTER error
> it'll still be == 1, otherwise it could be any value changed during the
> device life time).
>
> For the demonstration below a small change to iproute2 for printing all fdb
> notifications is added, because it contained a workaround not to show
> entries with ifindex == 0.
> Command executed while monitoring: $ ip l add br0 type bridge
> Before (both ifindex and master == 0):
> $ bridge monitor fdb
> 36:7e:8a:b3:56:ba dev * vlan 1 master * permanent
>
> After (proper br0 ifindex):
> $ bridge monitor fdb
> e6:2a:ae:7a:b7:48 dev br0 vlan 1 master br0 permanent
>
> v4: move only the default pvid init/deinit to NETDEV_REGISTER/UNREGISTER
> v3: send the correct v2 patch with all changes (stub should return 0)
> v2: on error in br_vlan_init set br->vlgrp to NULL and return 0 in
> the br_vlan_bridge_event stub when bridge vlans are disabled
>
> [0] https://bugzilla.kernel.org/show_bug.cgi?id=204389
>
> Reported-by: michael-dev <michael-dev@fami-braun.de>
> Fixes: 5be5a2df40f0 ("bridge: Add filtering support for default_pvid")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH net-next] net: delete "register" keyword
From: Alexey Dobriyan @ 2019-08-05 20:34 UTC (permalink / raw)
To: davem; +Cc: netdev, lvs-devel
Delete long obsoleted "register" keyword.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/ethernet/apple/bmac.c | 4 ++--
drivers/net/slip/slhc.c | 30 +++++++++++++++---------------
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++--
net/netfilter/ipvs/ip_vs_lblcr.c | 4 ++--
4 files changed, 21 insertions(+), 21 deletions(-)
--- a/drivers/net/ethernet/apple/bmac.c
+++ b/drivers/net/ethernet/apple/bmac.c
@@ -815,8 +815,8 @@ static int reverse6[64] = {
static unsigned int
crc416(unsigned int curval, unsigned short nxtval)
{
- register unsigned int counter, cur = curval, next = nxtval;
- register int high_crc_set, low_data_set;
+ unsigned int counter, cur = curval, next = nxtval;
+ int high_crc_set, low_data_set;
/* Swap bytes */
next = ((next & 0x00FF) << 8) | (next >> 8);
--- a/drivers/net/slip/slhc.c
+++ b/drivers/net/slip/slhc.c
@@ -91,8 +91,8 @@ static unsigned short pull16(unsigned char **cpp);
struct slcompress *
slhc_init(int rslots, int tslots)
{
- register short i;
- register struct cstate *ts;
+ short i;
+ struct cstate *ts;
struct slcompress *comp;
if (rslots < 0 || rslots > 255 || tslots < 0 || tslots > 255)
@@ -206,7 +206,7 @@ pull16(unsigned char **cpp)
static long
decode(unsigned char **cpp)
{
- register int x;
+ int x;
x = *(*cpp)++;
if(x == 0){
@@ -227,14 +227,14 @@ int
slhc_compress(struct slcompress *comp, unsigned char *icp, int isize,
unsigned char *ocp, unsigned char **cpp, int compress_cid)
{
- register struct cstate *ocs = &(comp->tstate[comp->xmit_oldest]);
- register struct cstate *lcs = ocs;
- register struct cstate *cs = lcs->next;
- register unsigned long deltaS, deltaA;
- register short changes = 0;
+ struct cstate *ocs = &(comp->tstate[comp->xmit_oldest]);
+ struct cstate *lcs = ocs;
+ struct cstate *cs = lcs->next;
+ unsigned long deltaS, deltaA;
+ short changes = 0;
int hlen;
unsigned char new_seq[16];
- register unsigned char *cp = new_seq;
+ unsigned char *cp = new_seq;
struct iphdr *ip;
struct tcphdr *th, *oth;
__sum16 csum;
@@ -486,11 +486,11 @@ slhc_compress(struct slcompress *comp, unsigned char *icp, int isize,
int
slhc_uncompress(struct slcompress *comp, unsigned char *icp, int isize)
{
- register int changes;
+ int changes;
long x;
- register struct tcphdr *thp;
- register struct iphdr *ip;
- register struct cstate *cs;
+ struct tcphdr *thp;
+ struct iphdr *ip;
+ struct cstate *cs;
int len, hdrlen;
unsigned char *cp = icp;
@@ -543,7 +543,7 @@ slhc_uncompress(struct slcompress *comp, unsigned char *icp, int isize)
switch(changes & SPECIALS_MASK){
case SPECIAL_I: /* Echoed terminal traffic */
{
- register short i;
+ short i;
i = ntohs(ip->tot_len) - hdrlen;
thp->ack_seq = htonl( ntohl(thp->ack_seq) + i);
thp->seq = htonl( ntohl(thp->seq) + i);
@@ -637,7 +637,7 @@ slhc_uncompress(struct slcompress *comp, unsigned char *icp, int isize)
int
slhc_remember(struct slcompress *comp, unsigned char *icp, int isize)
{
- register struct cstate *cs;
+ struct cstate *cs;
unsigned ihl;
unsigned char index;
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -262,7 +262,7 @@ static inline unsigned int
ip_vs_svc_hashkey(struct netns_ipvs *ipvs, int af, unsigned int proto,
const union nf_inet_addr *addr, __be16 port)
{
- register unsigned int porth = ntohs(port);
+ unsigned int porth = ntohs(port);
__be32 addr_fold = addr->ip;
__u32 ahash;
@@ -493,7 +493,7 @@ static inline unsigned int ip_vs_rs_hashkey(int af,
const union nf_inet_addr *addr,
__be16 port)
{
- register unsigned int porth = ntohs(port);
+ unsigned int porth = ntohs(port);
__be32 addr_fold = addr->ip;
#ifdef CONFIG_IP_VS_IPV6
--- a/net/netfilter/ipvs/ip_vs_lblcr.c
+++ b/net/netfilter/ipvs/ip_vs_lblcr.c
@@ -160,7 +160,7 @@ static void ip_vs_dest_set_eraseall(struct ip_vs_dest_set *set)
/* get weighted least-connection node in the destination set */
static inline struct ip_vs_dest *ip_vs_dest_set_min(struct ip_vs_dest_set *set)
{
- register struct ip_vs_dest_set_elem *e;
+ struct ip_vs_dest_set_elem *e;
struct ip_vs_dest *dest, *least;
int loh, doh;
@@ -209,7 +209,7 @@ static inline struct ip_vs_dest *ip_vs_dest_set_min(struct ip_vs_dest_set *set)
/* get weighted most-connection node in the destination set */
static inline struct ip_vs_dest *ip_vs_dest_set_max(struct ip_vs_dest_set *set)
{
- register struct ip_vs_dest_set_elem *e;
+ struct ip_vs_dest_set_elem *e;
struct ip_vs_dest *dest, *most;
int moh, doh;
^ 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