* [PATCH iproute] devlink: replace print macros with functions
From: Stephen Hemminger @ 2019-06-26 16:20 UTC (permalink / raw)
To: arkadis; +Cc: netdev, Stephen Hemminger
Using functions is safer than macros, and printing is not performance
critical.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
devlink/devlink.c | 62 ++++++++++++++++++++++++++++++++---------------
1 file changed, 42 insertions(+), 20 deletions(-)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 559f624e3666..4e277f7b0bc3 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -11,6 +11,7 @@
#include <stdio.h>
#include <stdlib.h>
+#include <stdarg.h>
#include <string.h>
#include <stdbool.h>
#include <unistd.h>
@@ -48,32 +49,53 @@
#define HEALTH_REPORTER_TIMESTAMP_FMT_LEN 80
static int g_new_line_count;
-
-#define pr_err(args...) fprintf(stderr, ##args)
-#define pr_out(args...) \
- do { \
- if (g_indent_newline) { \
- fprintf(stdout, "%s", g_indent_str); \
- g_indent_newline = false; \
- } \
- fprintf(stdout, ##args); \
- g_new_line_count = 0; \
- } while (0)
-
-#define pr_out_sp(num, args...) \
- do { \
- int ret = fprintf(stdout, ##args); \
- if (ret < num) \
- fprintf(stdout, "%*s", num - ret, ""); \
- g_new_line_count = 0; \
- } while (0)
-
static int g_indent_level;
static bool g_indent_newline;
+
#define INDENT_STR_STEP 2
#define INDENT_STR_MAXLEN 32
static char g_indent_str[INDENT_STR_MAXLEN + 1] = "";
+static void __attribute__((format(printf, 1, 2)))
+pr_err(const char *fmt, ...)
+{
+ va_list ap;
+
+ va_start(ap, fmt);
+ vfprintf(stderr, fmt, ap);
+ va_end(ap);
+}
+
+static void __attribute__((format(printf, 1, 2)))
+pr_out(const char *fmt, ...)
+{
+ va_list ap;
+
+ if (g_indent_newline) {
+ printf("%s", g_indent_str);
+ g_indent_newline = false;
+ }
+ va_start(ap, fmt);
+ vprintf(fmt, ap);
+ va_end(ap);
+ g_new_line_count = 0;
+}
+
+static void __attribute__((format(printf, 2, 3)))
+pr_out_sp(unsigned int num, const char *fmt, ...)
+{
+ va_list ap;
+ int ret;
+
+ va_start(ap, fmt);
+ ret = vprintf(fmt, ap);
+ va_end(ap);
+
+ if (ret < num)
+ printf("%*s", num - ret, "");
+ g_new_line_count = 0; \
+}
+
static void __pr_out_indent_inc(void)
{
if (g_indent_level + INDENT_STR_STEP > INDENT_STR_MAXLEN)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v2 3/4] net: sched: em_ipt: keep the user-specified nfproto and use it
From: Eyal Birger @ 2019-06-26 16:18 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev, roopa, pablo, xiyou.wangcong, davem, jiri, jhs
In-Reply-To: <20190626155615.16639-4-nikolay@cumulusnetworks.com>
Hi Nik,
On Wed, 26 Jun 2019 18:56:14 +0300
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> For NFPROTO_UNSPEC xt_matches there's no way to restrict the matching
> to a specific family, in order to do so we record the user-specified
> family and later enforce it while doing the match.
>
> v2: adjust changes to missing patch, was patch 04 in v1
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> net/sched/em_ipt.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
..snip..
> @@ -182,8 +195,8 @@ static int em_ipt_match(struct sk_buff *skb,
> struct tcf_ematch *em, const struct em_ipt_match *im = (const void
> *)em->data; struct xt_action_param acpar = {};
> struct net_device *indev = NULL;
> - u8 nfproto = im->match->family;
> struct nf_hook_state state;
> + u8 nfproto = im->nfproto;
Maybe I'm missing something now - but it's not really clear to me now
why keeping im->nfproto would be useful:
If NFPROTO_UNSPEC was provided by userspace then the actual nfproto used
will be taken from the packet, and if NFPROTO_IPV4/IPV6 was specified
from userspace then it will equal im->match->family.
Is there any case where the resulting nfproto would differ as a result
of this patch?
Otherwise the patchset looks excellent to me.
Thanks!
Eyal.
^ permalink raw reply
* Re: [PATCH net-next 13/18] ionic: Add initial ethtool support
From: Jakub Kicinski @ 2019-06-26 16:18 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev
In-Reply-To: <4ffa2c70-9ae7-15eb-3b21-34148de89b44@pensando.io>
On Wed, 26 Jun 2019 09:07:29 -0700, Shannon Nelson wrote:
> On 6/25/19 4:54 PM, Jakub Kicinski wrote:
> > On Thu, 20 Jun 2019 13:24:19 -0700, Shannon Nelson wrote:
> >> + running = test_bit(LIF_UP, lif->state);
> >> + if (running)
> >> + ionic_stop(netdev);
> >> +
> >> + lif->ntxq_descs = ring->tx_pending;
> >> + lif->nrxq_descs = ring->rx_pending;
> >> +
> >> + if (running)
> >> + ionic_open(netdev);
> >> + clear_bit(LIF_QUEUE_RESET, lif->state);
> >> + running = test_bit(LIF_UP, lif->state);
> >> + if (running)
> >> + ionic_stop(netdev);
> >> +
> >> + lif->nxqs = ch->combined_count;
> >> +
> >> + if (running)
> >> + ionic_open(netdev);
> >> + clear_bit(LIF_QUEUE_RESET, lif->state);
> > I think we'd rather see the drivers allocate/reserve the resources
> > first, and then perform the configuration once they are as sure as
> > possible it will succeed :( I'm not sure it's a hard requirement,
> > but I think certainly it'd be nice in new drivers.
> I think I know what you mean, but I suspect it depends upon which
> resources. I think the point of the range checking already being done
> covers what the driver is pretty sure it can handle, as early on it went
> through some sizing work to figure out the max queues, interrupts,
> filters, etc.
Yes, hopefully those don't fail.
> If we're looking at memory resources, then it may be a little harder:
> should we try to allocate a whole new set of buffers before dropping
> what we have, straining memory resources even more, or do we try to
> extend or contract what we currently have, a little more complex
> depending on layout?
>
> Interesting...
Indeed. I think whichever is simpler :) Either way we get shorter
traffic disruption and avoid the risk of "half up" interfaces..
^ permalink raw reply
* Re: [PATCH] bonding: Always enable vlan tx offload
From: mirq-linux @ 2019-06-26 16:13 UTC (permalink / raw)
To: YueHaibing
Cc: davem, sdf, jianbol, jiri, willemb, sdf, jiri, j.vosburgh,
vfalico, andy, linux-kernel, netdev
In-Reply-To: <20190626080844.20796-1-yuehaibing@huawei.com>
On Wed, Jun 26, 2019 at 04:08:44PM +0800, YueHaibing wrote:
> We build vlan on top of bonding interface, which vlan offload
> is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
> BOND_XMIT_POLICY_ENCAP34.
>
> Because vlan tx offload is off, vlan tci is cleared and skb push
> the vlan header in validate_xmit_vlan() while sending from vlan
> devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
> get information from protocol headers encapsulated within vlan,
> because 'nhoff' is points to IP header, so bond hashing is based
> on layer 2 info, which fails to distribute packets across slaves.
>
> This patch always enable bonding's vlan tx offload, pass the vlan
> packets to the slave devices with vlan tci, let them to handle
> vlan implementation.
[...]
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 407f4095a37a..799fc38c5c34 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -4320,12 +4320,12 @@ void bond_setup(struct net_device *bond_dev)
> bond_dev->features |= NETIF_F_NETNS_LOCAL;
>
> bond_dev->hw_features = BOND_VLAN_FEATURES |
> - NETIF_F_HW_VLAN_CTAG_TX |
> NETIF_F_HW_VLAN_CTAG_RX |
> NETIF_F_HW_VLAN_CTAG_FILTER;
>
> bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
> bond_dev->features |= bond_dev->hw_features;
> + bond_dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
> }
>
> /* Destroy a bonding device.
>
I can see that bonding driver uses dev_queue_xmit() to pass packets to
slave links, but I can't see where in the path it does software fallback
for devices without HW VLAN tagging. Generally drivers that don't ever
do VLAN offload also ignore vlan_tci presence. Am I missing something
here?
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [bpf-next v2 08/10] bpf: Implement bpf_prog_test_run for perf event programs
From: Stanislav Fomichev @ 2019-06-26 16:12 UTC (permalink / raw)
To: Krzesimir Nowak
Cc: netdev, Alban Crequy, Iago López Galeiras,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, linux-kernel, bpf
In-Reply-To: <CAGGp+cE3m1+ZWFBmjTgKFEHYVJ-L1dE=+iVUXvXCxWAxRG9YTA@mail.gmail.com>
On 06/26, Krzesimir Nowak wrote:
> On Tue, Jun 25, 2019 at 10:12 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
> >
> > On 06/25, Krzesimir Nowak wrote:
> > > As an input, test run for perf event program takes struct
> > > bpf_perf_event_data as ctx_in and struct bpf_perf_event_value as
> > > data_in. For an output, it basically ignores ctx_out and data_out.
> > >
> > > The implementation sets an instance of struct bpf_perf_event_data_kern
> > > in such a way that the BPF program reading data from context will
> > > receive what we passed to the bpf prog test run in ctx_in. Also BPF
> > > program can call bpf_perf_prog_read_value to receive what was passed
> > > in data_in.
> > >
> > > Signed-off-by: Krzesimir Nowak <krzesimir@kinvolk.io>
> > > ---
> > > kernel/trace/bpf_trace.c | 107 ++++++++++++++++++
> > > .../bpf/verifier/perf_event_sample_period.c | 8 ++
> > > 2 files changed, 115 insertions(+)
> > >
> > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > > index c102c240bb0b..2fa49ea8a475 100644
> > > --- a/kernel/trace/bpf_trace.c
> > > +++ b/kernel/trace/bpf_trace.c
> > > @@ -16,6 +16,8 @@
> > >
> > > #include <asm/tlb.h>
> > >
> > > +#include <trace/events/bpf_test_run.h>
> > > +
> > > #include "trace_probe.h"
> > > #include "trace.h"
> > >
> > > @@ -1160,7 +1162,112 @@ const struct bpf_verifier_ops perf_event_verifier_ops = {
> > > .convert_ctx_access = pe_prog_convert_ctx_access,
> > > };
> > >
> > > +static int pe_prog_test_run(struct bpf_prog *prog,
> > > + const union bpf_attr *kattr,
> > > + union bpf_attr __user *uattr)
> > > +{
> > > + void __user *ctx_in = u64_to_user_ptr(kattr->test.ctx_in);
> > > + void __user *data_in = u64_to_user_ptr(kattr->test.data_in);
> > > + u32 data_size_in = kattr->test.data_size_in;
> > > + u32 ctx_size_in = kattr->test.ctx_size_in;
> > > + u32 repeat = kattr->test.repeat;
> > > + u32 retval = 0, duration = 0;
> > > + int err = -EINVAL;
> > > + u64 time_start, time_spent = 0;
> > > + int i;
> > > + struct perf_sample_data sample_data = {0, };
> > > + struct perf_event event = {0, };
> > > + struct bpf_perf_event_data_kern real_ctx = {0, };
> > > + struct bpf_perf_event_data fake_ctx = {0, };
> > > + struct bpf_perf_event_value value = {0, };
> > > +
> > > + if (ctx_size_in != sizeof(fake_ctx))
> > > + goto out;
> > > + if (data_size_in != sizeof(value))
> > > + goto out;
> > > +
> > > + if (copy_from_user(&fake_ctx, ctx_in, ctx_size_in)) {
> > > + err = -EFAULT;
> > > + goto out;
> > > + }
> > Move this to net/bpf/test_run.c? I have a bpf_ctx_init helper to deal
> > with ctx input, might save you some code above wrt ctx size/etc.
>
> My impression about net/bpf/test_run.c was that it was a collection of
> helpers for test runs of the network-related BPF programs, because
> they are so similar to each other. So kernel/trace/bpf_trace.c looked
> like an obvious place for the test_run implementation since other perf
> trace BPF stuff was already there.
Maybe net/bpf/test_run.c should be renamed to kernel/bpf/test_run.c?
> And about bpf_ctx_init - looks useful as it seems to me that it
> handles the scenario where the size of the ctx struct grows, but still
> allows passing older version of the struct (thus smaller) from
> userspace for compatibility. Maybe that checking and copying part of
> the function could be moved into some non-static helper function, so I
> could use it and still skip the need for allocating memory for the
> context?
You can always make bpf_ctx_init non-static and export it.
But, again, consider adding your stuff to the net/bpf/test_run.c
and exporting only pe_prog_test_run. That way you can reuse
bpf_ctx_init and bpf_test_run.
Why do you care about memory allocation though? It's a one time
operation and doesn't affect the performance measurements.
> > > + if (copy_from_user(&value, data_in, data_size_in)) {
> > > + err = -EFAULT;
> > > + goto out;
> > > + }
> > > +
> > > + real_ctx.regs = &fake_ctx.regs;
> > > + real_ctx.data = &sample_data;
> > > + real_ctx.event = &event;
> > > + perf_sample_data_init(&sample_data, fake_ctx.addr,
> > > + fake_ctx.sample_period);
> > > + event.cpu = smp_processor_id();
> > > + event.oncpu = -1;
> > > + event.state = PERF_EVENT_STATE_OFF;
> > > + local64_set(&event.count, value.counter);
> > > + event.total_time_enabled = value.enabled;
> > > + event.total_time_running = value.running;
> > > + /* make self as a leader - it is used only for checking the
> > > + * state field
> > > + */
> > > + event.group_leader = &event;
> > > +
> > > + /* slightly changed copy pasta from bpf_test_run() in
> > > + * net/bpf/test_run.c
> > > + */
> > > + if (!repeat)
> > > + repeat = 1;
> > > +
> > > + rcu_read_lock();
> > > + preempt_disable();
> > > + time_start = ktime_get_ns();
> > > + for (i = 0; i < repeat; i++) {
> > Any reason for not using bpf_test_run?
>
> Two, mostly. One was that it is a static function and my code was
> elsewhere. Second was that it does some cgroup storage setup and I'm
> not sure if the perf event BPF program needs that.
You can always make it non-static.
Regarding cgroup storage: do we care? If you can see it affecting
your performance numbers, then yes, but you can try to measure to see
if it gives you any noticeable overhead. Maybe add an argument to
bpf_test_run to skip cgroup storage stuff?
> > > + retval = BPF_PROG_RUN(prog, &real_ctx);
> > > +
> > > + if (signal_pending(current)) {
> > > + err = -EINTR;
> > > + preempt_enable();
> > > + rcu_read_unlock();
> > > + goto out;
> > > + }
> > > +
> > > + if (need_resched()) {
> > > + time_spent += ktime_get_ns() - time_start;
> > > + preempt_enable();
> > > + rcu_read_unlock();
> > > +
> > > + cond_resched();
> > > +
> > > + rcu_read_lock();
> > > + preempt_disable();
> > > + time_start = ktime_get_ns();
> > > + }
> > > + }
> > > + time_spent += ktime_get_ns() - time_start;
> > > + preempt_enable();
> > > + rcu_read_unlock();
> > > +
> > > + do_div(time_spent, repeat);
> > > + duration = time_spent > U32_MAX ? U32_MAX : (u32)time_spent;
> > > + /* end of slightly changed copy pasta from bpf_test_run() in
> > > + * net/bpf/test_run.c
> > > + */
> > > +
> > > + if (copy_to_user(&uattr->test.retval, &retval, sizeof(retval))) {
> > > + err = -EFAULT;
> > > + goto out;
> > > + }
> > > + if (copy_to_user(&uattr->test.duration, &duration, sizeof(duration))) {
> > > + err = -EFAULT;
> > > + goto out;
> > > + }
> > Can BPF program modify fake_ctx? Do we need/want to copy it back?
>
> Reading the pe_prog_is_valid_access function tells me that it's not
> possible - the only type of valid access is read. So maybe I should be
> stricter about the requirements for the data_out and ctx_out sizes
> (should be zero or return -EINVAL).
Yes, better to explicitly prohibit anything that we don't support.
> > > + err = 0;
> > > +out:
> > > + trace_bpf_test_finish(&err);
> > > + return err;
> > > +}
> > > +
> > > const struct bpf_prog_ops perf_event_prog_ops = {
> > > + .test_run = pe_prog_test_run,
> > > };
> > >
> > > static DEFINE_MUTEX(bpf_event_mutex);
> > > diff --git a/tools/testing/selftests/bpf/verifier/perf_event_sample_period.c b/tools/testing/selftests/bpf/verifier/perf_event_sample_period.c
> > > index 471c1a5950d8..16e9e5824d14 100644
> > > --- a/tools/testing/selftests/bpf/verifier/perf_event_sample_period.c
> > > +++ b/tools/testing/selftests/bpf/verifier/perf_event_sample_period.c
> > This should probably go in another patch.
>
> Yeah, I was wondering about it. These changes are here to avoid
> breaking the tests, since perf event program can actually be run now
> and the test_run for perf event required certain sizes for ctx and
> data.
You need to make sure the context is optional, that way you don't break
any existing tests out in the wild and can move those changes to
another patch.
> So, I will either move them to a separate patch or rework the test_run
> for perf event to accept the size between 0 and sizeof(struct
> something), so the changes in tests maybe will not be necessary.
>
> >
> > > @@ -13,6 +13,8 @@
> > > },
> > > .result = ACCEPT,
> > > .prog_type = BPF_PROG_TYPE_PERF_EVENT,
> > > + .ctx_len = sizeof(struct bpf_perf_event_data),
> > > + .data_len = sizeof(struct bpf_perf_event_value),
> > > },
> > > {
> > > "check bpf_perf_event_data->sample_period half load permitted",
> > > @@ -29,6 +31,8 @@
> > > },
> > > .result = ACCEPT,
> > > .prog_type = BPF_PROG_TYPE_PERF_EVENT,
> > > + .ctx_len = sizeof(struct bpf_perf_event_data),
> > > + .data_len = sizeof(struct bpf_perf_event_value),
> > > },
> > > {
> > > "check bpf_perf_event_data->sample_period word load permitted",
> > > @@ -45,6 +49,8 @@
> > > },
> > > .result = ACCEPT,
> > > .prog_type = BPF_PROG_TYPE_PERF_EVENT,
> > > + .ctx_len = sizeof(struct bpf_perf_event_data),
> > > + .data_len = sizeof(struct bpf_perf_event_value),
> > > },
> > > {
> > > "check bpf_perf_event_data->sample_period dword load permitted",
> > > @@ -56,4 +62,6 @@
> > > },
> > > .result = ACCEPT,
> > > .prog_type = BPF_PROG_TYPE_PERF_EVENT,
> > > + .ctx_len = sizeof(struct bpf_perf_event_data),
> > > + .data_len = sizeof(struct bpf_perf_event_value),
> > > },
> > > --
> > > 2.20.1
> > >
>
>
>
> --
> Kinvolk GmbH | Adalbertstr.6a, 10999 Berlin | tel: +491755589364
> Geschäftsführer/Directors: Alban Crequy, Chris Kühl, Iago López Galeiras
> Registergericht/Court of registration: Amtsgericht Charlottenburg
> Registernummer/Registration number: HRB 171414 B
> Ust-ID-Nummer/VAT ID number: DE302207000
^ permalink raw reply
* Re: [PATCH bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Song Liu @ 2019-06-26 16:10 UTC (permalink / raw)
To: Lorenz Bauer
Cc: Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team
In-Reply-To: <CACAyw9-MAXOsAz7DnCBq+32yc575TEiwm_6P-3KWKmZWmAqUfg@mail.gmail.com>
> On Jun 26, 2019, at 8:26 AM, Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> On Wed, 26 Jun 2019 at 16:19, Song Liu <songliubraving@fb.com> wrote:
>>> I know nothing about the scheduler, so pardon my ignorance. Does
>>> TASK_BPF_FLAG_PERMITTED apply per user-space process, or per thread?
>>
>> It is per thread. clone() also clears the bit. I will make it more
>> clear int the commit log.
>
> In that case this is going to be very hard if not impossible to use
> from languages that
> don't allow controlling threads, aka Go. I'm sure there are other
> examples as well.
>
> Is it possible to make this per-process instead?
We can probably use CLONE_THREAD flag to differentiate clone() and
fork(). I need to read it more carefully to determine whether this is
accurate and safe.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH 2/2] net: stmmac: Fix crash observed if PHY does not support EEE
From: David Miller @ 2019-06-26 16:11 UTC (permalink / raw)
To: jonathanh
Cc: peppe.cavallaro, alexandre.torgue, joabreu, netdev, linux-kernel,
linux-tegra
In-Reply-To: <20190626102322.18821-2-jonathanh@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Wed, 26 Jun 2019 11:23:22 +0100
> If the PHY does not support EEE mode, then a crash is observed when the
> ethernet interface is enabled. The crash occurs, because if the PHY does
> not support EEE, then although the EEE timer is never configured, it is
> still marked as enabled and so the stmmac ethernet driver is still
> trying to update the timer by calling mod_timer(). This triggers a BUG()
> in the mod_timer() because we are trying to update a timer when there is
> no callback function set because timer_setup() was never called for this
> timer.
>
> The problem is caused because we return true from the function
> stmmac_eee_init(), marking the EEE timer as enabled, even when we have
> not configured the EEE timer. Fix this by ensuring that we return false
> if the PHY does not support EEE and hence, 'eee_active' is not set.
>
> Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: stmmac: Fix possible deadlock when disabling EEE support
From: David Miller @ 2019-06-26 16:10 UTC (permalink / raw)
To: jonathanh
Cc: peppe.cavallaro, alexandre.torgue, joabreu, netdev, linux-kernel,
linux-tegra
In-Reply-To: <20190626102322.18821-1-jonathanh@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Wed, 26 Jun 2019 11:23:21 +0100
> When stmmac_eee_init() is called to disable EEE support, then the timer
> for EEE support is stopped and we return from the function. Prior to
> stopping the timer, a mutex was acquired but in this case it is never
> released and so could cause a deadlock. Fix this by releasing the mutex
> prior to returning from stmmax_eee_init() when stopping the EEE timer.
>
> Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
When targetting net-next for a set of changes, make this explicit and clear
by saying "[PATCH net-next ...] ..." in your Subject lines in the future.
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: fix suspicious RCU usage in rt6_dump_route()
From: David Miller @ 2019-06-26 16:08 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, sbrivio, dsahern
In-Reply-To: <20190626100528.218097-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 26 Jun 2019 03:05:28 -0700
> syzbot reminded us that rt6_nh_dump_exceptions() needs to be called
> with rcu_read_lock()
>
> net/ipv6/route.c:1593 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
...
> Fixes: 1e47b4837f3b ("ipv6: Dump route exceptions if requested")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Stefano Brivio <sbrivio@redhat.com>
> Cc: David Ahern <dsahern@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv4: fix suspicious RCU usage in fib_dump_info_fnhe()
From: David Miller @ 2019-06-26 16:08 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, sbrivio, dsahern, syzkaller
In-Reply-To: <20190626100450.217106-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 26 Jun 2019 03:04:50 -0700
> sysbot reported that we lack appropriate rcu_read_lock()
> protection in fib_dump_info_fnhe()
>
> net/ipv4/route.c:2875 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
...
> Fixes: ee28906fd7a1 ("ipv4: Dump route exceptions if requested")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Stefano Brivio <sbrivio@redhat.com>
> Cc: David Ahern <dsahern@gmail.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied, we can adjust the 'err' initialization or whatever as a followup.
^ permalink raw reply
* Re: [PATCH net-next 13/18] ionic: Add initial ethtool support
From: Shannon Nelson @ 2019-06-26 16:07 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625165412.0e1206ce@cakuba.netronome.com>
On 6/25/19 4:54 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:19 -0700, Shannon Nelson wrote:
>> + running = test_bit(LIF_UP, lif->state);
>> + if (running)
>> + ionic_stop(netdev);
>> +
>> + lif->ntxq_descs = ring->tx_pending;
>> + lif->nrxq_descs = ring->rx_pending;
>> +
>> + if (running)
>> + ionic_open(netdev);
>> + clear_bit(LIF_QUEUE_RESET, lif->state);
>> + running = test_bit(LIF_UP, lif->state);
>> + if (running)
>> + ionic_stop(netdev);
>> +
>> + lif->nxqs = ch->combined_count;
>> +
>> + if (running)
>> + ionic_open(netdev);
>> + clear_bit(LIF_QUEUE_RESET, lif->state);
> I think we'd rather see the drivers allocate/reserve the resources
> first, and then perform the configuration once they are as sure as
> possible it will succeed :( I'm not sure it's a hard requirement,
> but I think certainly it'd be nice in new drivers.
I think I know what you mean, but I suspect it depends upon which
resources. I think the point of the range checking already being done
covers what the driver is pretty sure it can handle, as early on it went
through some sizing work to figure out the max queues, interrupts,
filters, etc.
If we're looking at memory resources, then it may be a little harder:
should we try to allocate a whole new set of buffers before dropping
what we have, straining memory resources even more, or do we try to
extend or contract what we currently have, a little more complex
depending on layout?
Interesting...
sln
^ permalink raw reply
* [PATCH] team: Always enable vlan tx offload
From: YueHaibing @ 2019-06-26 16:03 UTC (permalink / raw)
To: davem, sdf, jianbol, jiri, mirq-linux, willemb, sdf, jiri,
j.vosburgh, vfalico, andy
Cc: linux-kernel, netdev, YueHaibing
In-Reply-To: <20190624135007.GA17673@nanopsycho>
We should rather have vlan_tci filled all the way down
to the transmitting netdevice and let it do the hw/sw
vlan implementation.
Suggested-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/team/team.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index b48006e7fa2f..a8bb25341bed 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2128,12 +2128,12 @@ static void team_setup(struct net_device *dev)
dev->features |= NETIF_F_NETNS_LOCAL;
dev->hw_features = TEAM_VLAN_FEATURES |
- NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_CTAG_RX |
NETIF_F_HW_VLAN_CTAG_FILTER;
dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
dev->features |= dev->hw_features;
+ dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
}
static int team_newlink(struct net *src_net, struct net_device *dev,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next] can: dev: call netif_carrier_off() in register_candev()
From: David Miller @ 2019-06-26 16:03 UTC (permalink / raw)
To: rasmus.villemoes
Cc: willemdebruijn.kernel, wg, mkl, Rasmus.Villemoes, linux-can,
netdev, linux-kernel
In-Reply-To: <ff8160d4-3357-9b4f-1840-bbe46195da5a@prevas.dk>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date: Wed, 26 Jun 2019 09:31:39 +0000
> Perhaps I've misunderstood when to use the net-next prefix - is that
> only for things that should be applied directly to the net-next
> tree?
Yes, it is.
^ permalink raw reply
* Re: [PATCH net-next 00/11] net: hns3: some code optimizations & bugfixes
From: David Miller @ 2019-06-26 15:59 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <573582a3-23fc-8591-f71b-af977ed6fd0e@huawei.com>
From: tanhuazhong <tanhuazhong@huawei.com>
Date: Wed, 26 Jun 2019 15:44:05 +0800
> Hi, david, has this patchset merged into net-next, why I cannot see it
> after pulling net-next? Or is there some problem about this patchset I
> have missed?
Sorry, I forgot to push it out from my laptop while traveling.
It should be there now.
^ permalink raw reply
* pull-request: wireless-drivers-next 2019-06-26
From: Kalle Valo @ 2019-06-26 15:59 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next for 5.3, more info below. Please let
me know if there are any problems.
Kalle
The following changes since commit f4aa80129ff71909380ee0bde8be36c5cc031d4c:
cxgb4: Make t4_get_tp_e2c_map static (2019-05-26 22:16:26 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2019-06-26
for you to fetch changes up to e5db0ad7563c38b7b329504836c9a64ae025a47a:
airo: switch to skcipher interface (2019-06-25 08:12:20 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 5.3
First set of patches for 5.3, but not that many patches this time.
This pull request fails to compile with the tip tree due to
ktime_get_boot_ns() API changes there. It should be easy for Linus to
fix it in p54 driver once he pulls this, an example resolution here:
https://lkml.kernel.org/r/20190625160432.533aa140@canb.auug.org.au
Major changes:
airo
* switch to use skcipher interface
p54
* support boottime in scan results
rtw88
* add fast xmit support
* add random mac address on scan support
rt2x00
* add software watchdog to detect hangs, it's disabled by default
----------------------------------------------------------------
Ahmad Masri (1):
wil6210: fix overwriting max_assoc_sta module param
Alagu Sankar (3):
ath10k: htt: don't use txdone_fifo with SDIO
ath10k: htt: support MSDU ids with SDIO
ath10k: add initialization of HTC header
Alan Stern (1):
p54usb: Fix race between disconnect and firmware loading
Alexei Avshalom Lazar (1):
wil6210: fix _desc access in __wil_tx_vring_tso
Anilkumar Kolli (1):
ath: DFS JP domain W56 fixed pulse type 3 RADAR detection
Ard Biesheuvel (1):
airo: switch to skcipher interface
Arend van Spriel (6):
brcm80211: switch common header files to using SPDX license identifier
brcmutil: switch source files to using SPDX license identifier
brcmsmac: switch phy source files to using SPDX license identifier
brcmfmac: switch source files to using SPDX license identifier
brcmfmac: use separate Kconfig file for brcmfmac
brcm80211: select WANT_DEV_COREDUMP conditionally for brcmfmac
Arnd Bergmann (1):
wireless: carl9170: fix clang build warning
Balaji Pothunoori (1):
ath10k: rx_duration update for fw_stats debugfs entry
Brandon Huang (1):
ath10k: Fix the tx stats bytes & packets parsing
Brian Norris (2):
mwifiex: drop 'set_consistent_dma_mask' log message
mwifiex: print PCI mmap with %pK
Chien-Hsun Liao (2):
rtw88: 8822c: add rf write protection when switching channel
rtw88: 8822c: update channel and bandwidth BB setting
Chin-Yen Lee (1):
rtw88: add beacon function setting
Christian Lamparter (3):
p54: fix crash during initialization
p54: Support boottime in scan results
p54: remove dead branch in op_conf_tx callback
Colin Ian King (5):
ath6kl: remove redundant check of status != 0
libertas: fix spelling mistake "Donwloading" -> "Downloading"
rtlwifi: remove redundant assignment to variable badworden
rtlwifi: remove redundant assignment to variable k
rtlwifi: rtl8188ee: remove redundant assignment to rtstatus
Dan Carpenter (1):
ath6kl: add some bounds checking
Dedy Lansky (3):
wil6210: add printout of platform capabilities
wil6210: enhancements for descriptor and status ring debugfs
wil6210: check rx_buff_mgmt before accessing it
Erik Stromdahl (1):
ath10k: sdio: add missing error check
Govind Singh (2):
ath10k: Move board id and fw version logging to info level
ath10k: Modify CE4 src buffer entries to 2048 for WCN3990
Greg Kroah-Hartman (2):
iwlegacy: 3945: no need to check return value of debugfs_create functions
iwlegacy: 4965: no need to check return value of debugfs_create functions
Gustavo A. R. Silva (6):
ath6kl: debug: Use struct_size() helper
ath6kl: wmi: use struct_size() helper
wil6210: fix potential out-of-bounds read
ath10k: Use struct_size() helper
ath10k: coredump: use struct_size() helper
qtnfmac: Use struct_size() in kzalloc()
Jia-Ju Bai (1):
b43: Avoid possible double calls to b43_one_core_detach()
Kalle Valo (3):
ath10k: initialise struct ath10k_bus params to zero
ath10k: fix use-after-free on SDIO data frames
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Larry Finger (4):
rtlwifi: rtl8821ae: Remove unused GET_XXX and SET_XXX descriptor macros
rtlwifi: rtl8821ae: Replace local bit manipulation macros
rtlwifi: rtl8821ae: Convert macros that set descriptor
rtlwifi: rtl8821ae: Convert inline routines to little-endian words
Lorenzo Bianconi (2):
mt7601u: do not schedule rx_tasklet when the device has been disconnected
mt7601u: fix possible memory leak when the device is disconnected
Maharaja Kennadyrajan (2):
ath10k: Extended the HTT stats support to retrieve Mu-MIMO related stats
ath10k: Added support to reset HTT stats in debugfs
Maya Erez (4):
wil6210: fix spurious interrupts in 3-msi
wil6210: add support for multiple sections in brd file
wil6210: fix missed MISC mbox interrupt
wil6210: remove HALP for Talyn devices
Michael Buesch (1):
ssb/gpio: Remove unnecessary WARN_ON from driver_gpio
Neo Jou (1):
brcmfmac: use strlcpy() instead of strcpy()
Ping-Ke Shih (5):
rtlwifi: 8192de: Reduce indentation and fix coding style
rtlwifi: 8192de: make tables to be 'static const'
rtlwifi: 8192de: Fix used uninitialized variables in power tracking
rtlwifi: 8192de: use le32 to access cckswing tables
rtlwifi: rtl8192cu: fix error handle when usb probe failed
Pradeep kumar Chitrapu (1):
ath10k: fix incorrect multicast/broadcast rate setting
Rakesh Pillai (1):
ath10k: Fix encoding for protected management frames
Sharvari Harisangam (1):
mwifiex: update set_mac_address logic
Stanislaw Gruszka (7):
rt2x00: allow to specify watchdog interval
rt2800: add helpers for reading dma done index
rt2800: initial watchdog implementation
rt2800: add pre_reset_hw callback
rt2800: do not nullify initialization vector data
rt2x00: add restart hw
rt2800: do not enable watchdog by default
Surabhi Vishnoi (4):
ath10k: Fix the wrong value of enums for wmi tlv stats id
ath10k: Add wmi tlv vdev subtype for mesh in WCN3990
ath10k: Do not send probe response template for mesh
ath10k: Add wmi tlv service map for mesh 11s
Sven Eckelmann (1):
ath9k: Differentiate between max combined and per chain power
Swati Kushwaha (1):
mwifiex: ignore processing invalid command response
Tim Schumacher (1):
ath9k: Check for errors when reading SREV register
Toke Høiland-Jørgensen (1):
ath9k: Don't trust TX status TID number when reporting airtime
Tomislav Požega (2):
ath: drop duplicated define
ath9k: drop redundant code in ar9003_hw_set_channel
Tzu-En Huang (1):
rtw88: fix typo rtw_writ16_set
Weitao Hou (1):
brcmfmac: fix typos in code comments
Wen Gong (9):
ath10k: sdio: workaround firmware UART pin configuration bug
ath10k: don't disable interrupts in ath10k_sdio_remove()
ath10k: add struct for high latency PN replay protection
ath10k: add handler for HTT_T2H_MSG_TYPE_SEC_IND event
ath10k: add PN replay protection for high latency devices
ath10k: add fragmentation handler for high latency devices
ath10k: enable QCA6174 hw3.2 SDIO hardware
ath10k: change swap mail box config for UTF mode of SDIO
ath10k: add peer id check in ath10k_peer_find_by_id
Yan-Hsuan Chuang (10):
rtw88: pci: use ieee80211_ac_numbers instead of 0-3
rtw88: pci: check if queue mapping exceeds size of ac_to_hwq
rtw88: more descriptions about LPS
rtw88: add fast xmit support
rtw88: add support for random mac scan
rtw88: 8822c: disable rx clock gating before counter reset
rtw88: 8822c: use more accurate ofdm fa counting
rtw88: power on again if it was already on
rtw88: restore DACK results to save time
rtw88: rsvd page should go though management queue
Yingying Tang (1):
ath10k: Check tx_stats before use it
YueHaibing (4):
ath9k: Remove some set but not used variables
rtlwifi: rtl8821ae: Remove set but not used variables 'cur_txokcnt' and 'b_last_is_cur_rdl_state'
rtlwifi: btcoex: Remove set but not used variable 'len' and 'asso_type_v2'
rtlwifi: btcoex: remove unused function exhalbtc_stack_operation_notify
drivers/net/wireless/ath/ath10k/ahb.c | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 48 +-
drivers/net/wireless/ath/ath10k/core.h | 12 +-
drivers/net/wireless/ath/ath10k/coredump.c | 4 +-
drivers/net/wireless/ath/ath10k/debug.c | 50 +-
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 7 +
drivers/net/wireless/ath/ath10k/htc.c | 1 +
drivers/net/wireless/ath/ath10k/htt.h | 60 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 387 ++++++++++-
drivers/net/wireless/ath/ath10k/htt_tx.c | 29 +-
drivers/net/wireless/ath/ath10k/hw.h | 6 +
drivers/net/wireless/ath/ath10k/mac.c | 14 +-
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
drivers/net/wireless/ath/ath10k/qmi.c | 15 +-
drivers/net/wireless/ath/ath10k/sdio.c | 18 +-
drivers/net/wireless/ath/ath10k/snoc.c | 4 +-
drivers/net/wireless/ath/ath10k/txrx.c | 3 +
drivers/net/wireless/ath/ath10k/usb.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 28 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 12 +
drivers/net/wireless/ath/ath10k/wmi.c | 37 +-
drivers/net/wireless/ath/ath10k/wmi.h | 7 +-
drivers/net/wireless/ath/ath6kl/debug.c | 3 +-
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 3 -
drivers/net/wireless/ath/ath6kl/wmi.c | 13 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 24 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 40 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 18 +-
drivers/net/wireless/ath/carl9170/mac.c | 2 +-
drivers/net/wireless/ath/carl9170/rx.c | 2 +-
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
drivers/net/wireless/ath/regd.h | 1 -
drivers/net/wireless/ath/wil6210/cfg80211.c | 4 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 70 +-
drivers/net/wireless/ath/wil6210/fw.h | 11 +-
drivers/net/wireless/ath/wil6210/fw_inc.c | 148 +++--
drivers/net/wireless/ath/wil6210/interrupt.c | 67 +-
drivers/net/wireless/ath/wil6210/main.c | 18 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 2 +
drivers/net/wireless/ath/wil6210/rx_reorder.c | 2 +-
drivers/net/wireless/ath/wil6210/txrx.c | 26 +-
drivers/net/wireless/ath/wil6210/txrx_edma.c | 10 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 33 +-
drivers/net/wireless/ath/wil6210/wmi.c | 14 +-
drivers/net/wireless/broadcom/b43/main.c | 7 +-
drivers/net/wireless/broadcom/brcm80211/Kconfig | 52 +-
drivers/net/wireless/broadcom/brcm80211/Makefile | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/Kconfig | 50 ++
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/btcoex.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/btcoex.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 13 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 13 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/chip.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/chip.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 15 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.h | 16 +-
.../broadcom/brcm80211/brcmfmac/commonring.c | 16 +-
.../broadcom/brcm80211/brcmfmac/commonring.h | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/debug.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/debug.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/dmi.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 13 +-
.../broadcom/brcm80211/brcmfmac/firmware.c | 13 +-
.../broadcom/brcm80211/brcmfmac/firmware.h | 13 +-
.../broadcom/brcm80211/brcmfmac/flowring.c | 16 +-
.../broadcom/brcm80211/brcmfmac/flowring.h | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/fwil.c | 15 +-
.../wireless/broadcom/brcm80211/brcmfmac/fwil.h | 13 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 13 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 13 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.h | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 16 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/of.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/of.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.h | 16 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 13 +-
.../broadcom/brcm80211/brcmfmac/tracepoint.c | 13 +-
.../broadcom/brcm80211/brcmfmac/tracepoint.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/vendor.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/vendor.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_hal.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_int.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_lcn.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_radio.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phyreg_n.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_n.h | 13 +-
.../wireless/broadcom/brcm80211/brcmutil/Makefile | 13 +-
.../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 13 +-
.../wireless/broadcom/brcm80211/brcmutil/utils.c | 13 +-
.../broadcom/brcm80211/include/brcm_hw_ids.h | 13 +-
.../broadcom/brcm80211/include/brcmu_d11.h | 13 +-
.../broadcom/brcm80211/include/brcmu_utils.h | 13 +-
.../broadcom/brcm80211/include/brcmu_wifi.h | 13 +-
.../broadcom/brcm80211/include/chipcommon.h | 13 +-
.../net/wireless/broadcom/brcm80211/include/defs.h | 13 +-
.../net/wireless/broadcom/brcm80211/include/soc.h | 13 +-
drivers/net/wireless/cisco/Kconfig | 2 +
drivers/net/wireless/cisco/airo.c | 57 +-
drivers/net/wireless/intel/iwlegacy/3945-rs.c | 14 +-
drivers/net/wireless/intel/iwlegacy/3945.h | 3 -
drivers/net/wireless/intel/iwlegacy/4965-rs.c | 31 +-
drivers/net/wireless/intel/iwlegacy/common.h | 4 -
drivers/net/wireless/intersil/p54/main.c | 9 +-
drivers/net/wireless/intersil/p54/p54usb.c | 43 +-
drivers/net/wireless/intersil/p54/txrx.c | 11 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 27 +-
drivers/net/wireless/marvell/mwifiex/main.c | 6 +-
drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 5 +-
drivers/net/wireless/mediatek/mt7601u/dma.c | 54 +-
drivers/net/wireless/mediatek/mt7601u/tx.c | 4 +-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 96 ++-
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 11 +
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 31 +
drivers/net/wireless/ralink/rt2x00/rt2800mmio.h | 2 +
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 3 +
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 3 +
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 11 +
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 10 +
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 35 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 10 +-
drivers/net/wireless/ralink/rt2x00/rt2x00link.c | 15 +-
drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 6 +
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 35 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 1 -
.../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/efuse.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/dm.c | 695 ++++++++++----------
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 253 ++++----
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 708 +++++++++++----------
drivers/net/wireless/realtek/rtlwifi/usb.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
drivers/net/wireless/realtek/rtw88/hci.h | 2 +-
drivers/net/wireless/realtek/rtw88/mac.c | 8 +-
drivers/net/wireless/realtek/rtw88/mac80211.c | 32 +
drivers/net/wireless/realtek/rtw88/main.c | 10 +-
drivers/net/wireless/realtek/rtw88/main.h | 11 +
drivers/net/wireless/realtek/rtw88/pci.c | 10 +-
drivers/net/wireless/realtek/rtw88/phy.c | 13 +-
drivers/net/wireless/realtek/rtw88/rtw8822c.c | 436 ++++++++++++-
drivers/net/wireless/realtek/rtw88/rtw8822c.h | 23 +
drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
drivers/ssb/driver_gpio.c | 6 -
181 files changed, 2885 insertions(+), 2322 deletions(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig
^ permalink raw reply
* [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems
From: Ivan Khoronzhuk @ 2019-06-26 15:59 UTC (permalink / raw)
To: bjorn.topel, magnus.karlsson, davem
Cc: ast, daniel, hawk, john.fastabend, netdev, bpf, xdp-newbies,
linux-kernel, Ivan Khoronzhuk
Use kmap instead of page_address as it's not always in low memory.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
net/xdp/xdp_umem.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 9c6de4f114f8..d3c1411420fd 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -169,6 +169,14 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
}
}
+static void xdp_umem_unmap_pages(struct xdp_umem *umem)
+{
+ unsigned int i;
+
+ for (i = 0; i < umem->npgs; i++)
+ kunmap(umem->pgs[i]);
+}
+
static void xdp_umem_unpin_pages(struct xdp_umem *umem)
{
unsigned int i;
@@ -210,6 +218,7 @@ static void xdp_umem_release(struct xdp_umem *umem)
xsk_reuseq_destroy(umem);
+ xdp_umem_unmap_pages(umem);
xdp_umem_unpin_pages(umem);
kfree(umem->pages);
@@ -372,7 +381,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
}
for (i = 0; i < umem->npgs; i++)
- umem->pages[i].addr = page_address(umem->pgs[i]);
+ umem->pages[i].addr = kmap(umem->pgs[i]);
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 3/4] net: sched: em_ipt: keep the user-specified nfproto and use it
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
For NFPROTO_UNSPEC xt_matches there's no way to restrict the matching to a
specific family, in order to do so we record the user-specified family
and later enforce it while doing the match.
v2: adjust changes to missing patch, was patch 04 in v1
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index fd7f5b288c31..ce91f3cea0bd 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -21,6 +21,7 @@
struct em_ipt_match {
const struct xt_match *match;
u32 hook;
+ u8 nfproto;
u8 match_data[0] __aligned(8);
};
@@ -115,6 +116,7 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
struct em_ipt_match *im = NULL;
struct xt_match *match;
int mdata_len, ret;
+ u8 nfproto;
ret = nla_parse_deprecated(tb, TCA_EM_IPT_MAX, data, data_len,
em_ipt_policy, NULL);
@@ -125,6 +127,16 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
!tb[TCA_EM_IPT_MATCH_DATA] || !tb[TCA_EM_IPT_NFPROTO])
return -EINVAL;
+ nfproto = nla_get_u8(tb[TCA_EM_IPT_NFPROTO]);
+ switch (nfproto) {
+ case NFPROTO_IPV4:
+ case NFPROTO_IPV6:
+ case NFPROTO_UNSPEC:
+ break;
+ default:
+ return -EINVAL;
+ }
+
match = get_xt_match(tb);
if (IS_ERR(match)) {
pr_err("unable to load match\n");
@@ -140,6 +152,7 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
im->match = match;
im->hook = nla_get_u32(tb[TCA_EM_IPT_HOOK]);
+ im->nfproto = nfproto;
nla_memcpy(im->match_data, tb[TCA_EM_IPT_MATCH_DATA], mdata_len);
ret = check_match(net, im, mdata_len);
@@ -182,8 +195,8 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
const struct em_ipt_match *im = (const void *)em->data;
struct xt_action_param acpar = {};
struct net_device *indev = NULL;
- u8 nfproto = im->match->family;
struct nf_hook_state state;
+ u8 nfproto = im->nfproto;
int ret;
switch (tc_skb_protocol(skb)) {
@@ -231,7 +244,7 @@ static int em_ipt_dump(struct sk_buff *skb, struct tcf_ematch *em)
return -EMSGSIZE;
if (nla_put_u8(skb, TCA_EM_IPT_MATCH_REVISION, im->match->revision) < 0)
return -EMSGSIZE;
- if (nla_put_u8(skb, TCA_EM_IPT_NFPROTO, im->match->family) < 0)
+ if (nla_put_u8(skb, TCA_EM_IPT_NFPROTO, im->nfproto) < 0)
return -EMSGSIZE;
if (nla_put(skb, TCA_EM_IPT_MATCH_DATA,
im->match->usersize ?: im->match->matchsize,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 4/4] net: sched: em_ipt: add support for addrtype matching
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
Allow em_ipt to use addrtype for matching. Restrict the use only to
revision 1 which has IPv6 support. Since it's a NFPROTO_UNSPEC xt match
we use the user-specified nfproto for matching, in case it's unspecified
both v4/v6 will be matched by the rule.
v2: no changes, was patch 5 in v1
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index ce91f3cea0bd..b08d87bd120b 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -72,11 +72,25 @@ static int policy_validate_match_data(struct nlattr **tb, u8 mrev)
return 0;
}
+static int addrtype_validate_match_data(struct nlattr **tb, u8 mrev)
+{
+ if (mrev != 1) {
+ pr_err("only addrtype match revision 1 supported");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct em_ipt_xt_match em_ipt_xt_matches[] = {
{
.match_name = "policy",
.validate_match_data = policy_validate_match_data
},
+ {
+ .match_name = "addrtype",
+ .validate_match_data = addrtype_validate_match_data
+ },
{}
};
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 2/4] net: sched: em_ipt: set the family based on the packet if it's unspecified
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
Set the family based on the packet if it's unspecified otherwise
protocol-neutral matches will have wrong information (e.g. NFPROTO_UNSPEC).
In preparation for using NFPROTO_UNSPEC xt matches.
v2: set the nfproto only when unspecified
Suggested-by: Eyal Birger <eyal.birger@gmail.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 64dbafe4e94c..fd7f5b288c31 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -182,6 +182,7 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
const struct em_ipt_match *im = (const void *)em->data;
struct xt_action_param acpar = {};
struct net_device *indev = NULL;
+ u8 nfproto = im->match->family;
struct nf_hook_state state;
int ret;
@@ -189,10 +190,14 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
case htons(ETH_P_IP):
if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
return 0;
+ if (nfproto == NFPROTO_UNSPEC)
+ nfproto = NFPROTO_IPV4;
break;
case htons(ETH_P_IPV6):
if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
return 0;
+ if (nfproto == NFPROTO_UNSPEC)
+ nfproto = NFPROTO_IPV6;
break;
default:
return 0;
@@ -203,7 +208,7 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
if (skb->skb_iif)
indev = dev_get_by_index_rcu(em->net, skb->skb_iif);
- nf_hook_state_init(&state, im->hook, im->match->family,
+ nf_hook_state_init(&state, im->hook, nfproto,
indev ?: skb->dev, skb->dev, NULL, em->net, NULL);
acpar.match = im->match;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 1/4] net: sched: em_ipt: match only on ip/ipv6 traffic
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
Restrict matching only to ip/ipv6 traffic and make sure we can use the
headers, otherwise matches will be attempted on any protocol which can
be unexpected by the xt matches. Currently policy supports only ipv4/6.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 243fd22f2248..64dbafe4e94c 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -185,6 +185,19 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
struct nf_hook_state state;
int ret;
+ switch (tc_skb_protocol(skb)) {
+ case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ return 0;
+ break;
+ case htons(ETH_P_IPV6):
+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ return 0;
+ break;
+ default:
+ return 0;
+ }
+
rcu_read_lock();
if (skb->skb_iif)
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 0/4] em_ipt: add support for addrtype
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
Hi,
We would like to be able to use the addrtype from tc for ACL rules and
em_ipt seems the best place to add support for the already existing xt
match. The biggest issue is that addrtype revision 1 (with ipv6 support)
is NFPROTO_UNSPEC and currently em_ipt can't differentiate between v4/v6
if such xt match is used because it passes the match's family instead of
the user-specified one. The first 3 patches make em_ipt match only on IP
traffic (currently both policy and addrtype recognize such traffic
only) and make it pass the actual packet's protocol instead of the xt
match family when it's unspecified. They also add support for NFPROTO_UNSPEC
xt matches. The last patch allows to add addrtype rules via em_ipt.
v2: change patch 02 to set the nfproto only when unspecified and drop
patch 04 from v1 (Eyal Birger)
Thank you,
Nikolay Aleksandrov
Nikolay Aleksandrov (4):
net: sched: em_ipt: match only on ip/ipv6 traffic
net: sched: em_ipt: set the family based on the packet if it's
unspecified
net: sched: em_ipt: keep the user-specified nfproto and use it
net: sched: em_ipt: add support for addrtype matching
net/sched/em_ipt.c | 49 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 47 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH net-next 12/18] ionic: Add async link status check and basic stats
From: Shannon Nelson @ 2019-06-26 15:54 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625164713.00ecc9aa@cakuba.netronome.com>
On 6/25/19 4:47 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:18 -0700, Shannon Nelson wrote:
>> + /* filter out the no-change cases */
>> + if ((link_up && netif_carrier_ok(netdev)) ||
>> + (!link_up && !netif_carrier_ok(netdev)))
> nit: these are both bools, you can compare them:
>
> if (link_up == netif_carrier_ok(netdev))
>
>> + return;
Yep - thanks.
sln
^ permalink raw reply
* Re: [PATCH net-next 11/18] ionic: Add Rx filter and rx_mode nod support
From: Shannon Nelson @ 2019-06-26 15:53 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625164456.606dd40a@cakuba.netronome.com>
On 6/25/19 4:44 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:17 -0700, Shannon Nelson wrote:
>> Add the Rx filtering and rx_mode NDO callbacks. Also add
>> the deferred work thread handling needed to manage the filter
>> requests otuside of the netif_addr_lock spinlock.
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
>> static int ionic_vlan_rx_kill_vid(struct net_device *netdev, __be16 proto,
>> u16 vid)
>> {
>> - netdev_info(netdev, "%s: stubbed\n", __func__);
>> + struct lif *lif = netdev_priv(netdev);
>> + struct ionic_admin_ctx ctx = {
>> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
>> + .cmd.rx_filter_del = {
>> + .opcode = CMD_OPCODE_RX_FILTER_DEL,
>> + .lif_index = cpu_to_le16(lif->index),
>> + },
>> + };
>> + struct rx_filter *f;
>> + int err;
>> +
>> + spin_lock_bh(&lif->rx_filters.lock);
>> +
>> + f = ionic_rx_filter_by_vlan(lif, vid);
>> + if (!f) {
>> + spin_unlock_bh(&lif->rx_filters.lock);
>> + return -ENOENT;
>> + }
>> +
>> + netdev_dbg(netdev, "rx_filter del VLAN %d (id %d)\n", vid,
>> + le32_to_cpu(ctx.cmd.rx_filter_del.filter_id));
>> +
>> + ctx.cmd.rx_filter_del.filter_id = cpu_to_le32(f->filter_id);
>> + ionic_rx_filter_free(lif, f);
>> + spin_unlock_bh(&lif->rx_filters.lock);
>> +
>> + err = ionic_adminq_post_wait(lif, &ctx);
>> + if (err)
>> + return err;
>>
>> return 0;
> nit: return directly?
Sure.
>
>> }
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.h b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
>> index 8129fa20695a..c3ecf1df9c2c 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_lif.h
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
>> @@ -60,6 +60,29 @@ struct qcq {
>> #define napi_to_qcq(napi) container_of(napi, struct qcq, napi)
>> #define napi_to_cq(napi) (&napi_to_qcq(napi)->cq)
>>
>> +enum deferred_work_type {
>> + DW_TYPE_RX_MODE,
>> + DW_TYPE_RX_ADDR_ADD,
>> + DW_TYPE_RX_ADDR_DEL,
>> + DW_TYPE_LINK_STATUS,
>> + DW_TYPE_LIF_RESET,
>> +};
>> +
>> +struct deferred_work {
> If you don't mind prefixing these structures with ionic_ that'd be
> great. I'm worried deferred_work is too close to delayed_work..
Yes.
>
>> + struct list_head list;
>> + enum deferred_work_type type;
>> + union {
>> + unsigned int rx_mode;
>> + u8 addr[ETH_ALEN];
>> + };
>> +};
>> +
>> +struct deferred {
>> + spinlock_t lock; /* lock for deferred work list */
>> + struct list_head list;
>> + struct work_struct work;
>> +};
^ permalink raw reply
* Re: [PATCH net-next 10/18] ionic: Add management of rx filters
From: Shannon Nelson @ 2019-06-26 15:52 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625163729.617346e0@cakuba.netronome.com>
On 6/25/19 4:37 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:16 -0700, Shannon Nelson wrote:
>> +int ionic_rx_filter_save(struct lif *lif, u32 flow_id, u16 rxq_index,
>> + u32 hash, struct ionic_admin_ctx *ctx)
>> +{
>> + struct device *dev = lif->ionic->dev;
>> + struct hlist_head *head;
>> + struct rx_filter *f;
>> + unsigned int key;
>> +
>> + f = devm_kzalloc(dev, sizeof(*f), GFP_KERNEL);
>> + if (!f)
>> + return -ENOMEM;
>> +
>> + f->flow_id = flow_id;
>> + f->filter_id = le32_to_cpu(ctx->comp.rx_filter_add.filter_id);
>> + f->rxq_index = rxq_index;
>> + memcpy(&f->cmd, &ctx->cmd, sizeof(f->cmd));
>> +
>> + INIT_HLIST_NODE(&f->by_hash);
>> + INIT_HLIST_NODE(&f->by_id);
>> +
>> + switch (le16_to_cpu(f->cmd.match)) {
>> + case RX_FILTER_MATCH_VLAN:
>> + key = le16_to_cpu(f->cmd.vlan.vlan) & RX_FILTER_HLISTS_MASK;
>> + break;
>> + case RX_FILTER_MATCH_MAC:
>> + key = *(u32 *)f->cmd.mac.addr & RX_FILTER_HLISTS_MASK;
>> + break;
>> + case RX_FILTER_MATCH_MAC_VLAN:
>> + key = le16_to_cpu(f->cmd.mac_vlan.vlan) & RX_FILTER_HLISTS_MASK;
>> + break;
>> + default:
> I know you use devm_kzalloc() but can't this potentially keep arbitrary
> amounts of memory held until the device is removed (and it's the entire
> device not just a LIF)?
Yes, but we're freeing this memory when objects are deleted. We're
trying to be tidy with our allocations, but used devm_kzalloc to be more
sure that things went away when the device did.
>
>> + return -ENOTSUPP;
> EOPNOTSUPP, please do not use ENOTSUPP in the drivers. It's a high
> error code, unknown to libc. We should use EOPNOTSUPP or EINVAL.
Sure.
>
>> + }
^ permalink raw reply
* [PATCH net 1/2] net/smc: hold conns_lock before calling smc_lgr_register_conn()
From: Ursula Braun @ 2019-06-26 15:47 UTC (permalink / raw)
To: davem
Cc: netdev, linux-s390, gor, heiko.carstens, raspl, kgraul, ubraun,
zhp, yuehaibing
In-Reply-To: <20190626154750.46127-1-ubraun@linux.ibm.com>
From: Huaping Zhou <zhp@smail.nju.edu.cn>
After smc_lgr_create(), the newly created link group is added
to smc_lgr_list, thus is accessible from other context.
Although link group creation is serialized by
smc_create_lgr_pending, the new link group may still be accessed
concurrently. For example, if ib_device is no longer active,
smc_ib_port_event_work() will call smc_port_terminate(), which
in turn will call __smc_lgr_terminate() on every link group of
this device. So conns_lock is required here.
Signed-off-by: Huaping Zhou <zhp@smail.nju.edu.cn>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/smc_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index 2d2850adc2a3..4ca50ddf8d16 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -652,7 +652,10 @@ int smc_conn_create(struct smc_sock *smc, struct smc_init_info *ini)
rc = smc_lgr_create(smc, ini);
if (rc)
goto out;
+ lgr = conn->lgr;
+ write_lock_bh(&lgr->conns_lock);
smc_lgr_register_conn(conn); /* add smc conn to lgr */
+ write_unlock_bh(&lgr->conns_lock);
}
conn->local_tx_ctrl.common.type = SMC_CDC_MSG_TYPE;
conn->local_tx_ctrl.len = SMC_WR_TX_SIZE;
--
2.17.1
^ permalink raw reply related
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