* Re: [15/16] hostap: convert hostap_cmd_queue.usecnt from atomic_t to refcount_t
From: Kalle Valo @ 2017-05-22 15:24 UTC (permalink / raw)
To: Elena Reshetova
Cc: gregkh, peterz, matanb, paulus, Elena Reshetova, nbd, linux-rdma,
saeedm, ganeshgr, Hans Liljestrand, David Windsor, keescook, j,
ajk, leonro, matthias.bgg, linux-hams, linux-arm-kernel, blogic,
netdev, yishaih, linux-wireless, linux-kernel, linux-ppp
In-Reply-To: <1490691403-4016-16-git-send-email-elena.reshetova@intel.com>
Elena Reshetova <elena.reshetova@intel.com> wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
2 patches applied to wireless-drivers-next.git, thanks.
552aa585faff hostap: convert hostap_cmd_queue.usecnt from atomic_t to refcount_t
0aeffa7041d8 orinoco_usb: convert request_context.refcount from atomic_t to refcount_t
--
https://patchwork.kernel.org/patch/9648427/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [15/16] hostap: convert hostap_cmd_queue.usecnt from atomic_t to refcount_t
From: Kalle Valo @ 2017-05-22 15:24 UTC (permalink / raw)
To: Elena Reshetova
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-hams-u79uwXL29TY76Z2rM5mHXA,
linux-ppp-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ganeshgr-ut6Up61K2wZBDgjK7y7TUQ, nbd-p3rKhJxN3npAfugRpC6u6w,
blogic-p3rKhJxN3npAfugRpC6u6w,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
yishaih-VPRAkNaXOzVWk0Htik3J/w, saeedm-VPRAkNaXOzVWk0Htik3J/w,
matanb-VPRAkNaXOzVWk0Htik3J/w, leonro-VPRAkNaXOzVWk0Htik3J/w,
ajk-iz34hMvxm2Hmj42eshorlhS11BummzK+,
paulus-eUNUBHrolfbYtjvyW6yDsg, j, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
keescook-F7+t8E8rja9g9hUCZPvPmw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Elena Reshetova,
Hans Liljestrand, David Windsor
In-Reply-To: <1490691403-4016-16-git-send-email-elena.reshetova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Elena Reshetova <elena.reshetova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova <elena.reshetova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Hans Liljestrand <ishkamiel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: David Windsor <dwindsor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2 patches applied to wireless-drivers-next.git, thanks.
552aa585faff hostap: convert hostap_cmd_queue.usecnt from atomic_t to refcount_t
0aeffa7041d8 orinoco_usb: convert request_context.refcount from atomic_t to refcount_t
--
https://patchwork.kernel.org/patch/9648427/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv4] wlcore: add wl1285 compatible
From: Sebastian Reichel @ 2017-05-22 15:21 UTC (permalink / raw)
To: Kalle Valo
Cc: David Miller, tony-4v6yS6AI5VpBDgjK7y7TUQ,
marcel-kz+m5ild9QBg9hUCZPvPmw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87wp99t0hj.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
Hi,
On Mon, May 22, 2017 at 05:44:24PM +0300, Kalle Valo wrote:
> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> > From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > Date: Mon, 22 May 2017 12:28:20 +0300
> >
> >> Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> writes:
> >>
> >>> Motorola Droid 4 uses a WL1285C. With differences between the
> >>> chips not being public let's add explicit binding for wl1285
> >>> instead of relying on wl1283 being very similar.
> >>>
> >>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>> Acked-by: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >>> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> >>> Signed-off-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> >>> ---
> >>> Hi Dave,
> >>>
> >>> I previously send this in two patches, but its hard to apply without
> >>> requiring multiple kernel releases (the driver must be updated before
> >>> the DTS change). Since the actual change is not very complex Marcel
> >>> Holtmann & Tony Lindgren suggested, that I send this directly to you
> >>> in a single patch for inclusion into 4.12. This also means, that the
> >>> remaining series can be queued normally for 4.13.
> >>
> >> I noticed that Dave set this patch to Awaiting Upstream state on his
> >> patchwork:
> >>
> >> https://patchwork.ozlabs.org/patch/759042/
> >>
> >> Which makes me suspect that he is waiting me to apply this (as I
> >> normally apply wlcore patches). Dave, should I actually take this patch?
> >> What do you prefer?
> >
> > Anything that touches wireless drivers I defer to you, yes.
>
> Thanks, I'll take it then. Not sure why Sebastian was suggested to
> submit this patch via your tree in the first place.
>
> https://patchwork.kernel.org/patch/9713645/
Thanks. The idea was to get into early 4.12-rc to avoid merge
conflicts in the droid 4 *.dts during 4.13 cycle. This strategy
obviously failed :)
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v4] brcmfmac: btcoex: replace init_timer with setup_timer
From: Kalle Valo @ 2017-05-22 15:19 UTC (permalink / raw)
To: Xie Qirong
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel, Xie Qirong
In-Reply-To: <20170512093259.28479-1-cheerx1994@gmail.com>
Xie Qirong <cheerx1994@gmail.com> wrote:
> setup_timer.cocci suggested the following improvement:
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c:383:1-11: Use
> setup_timer function for function on line 384.
>
> The combination of init_timer and setting up the data and function field
> manually is equivalent to calling setup_timer(). This is an api
> consolidation only and improves readability.
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Xie Qirong <cheerx1994@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
6572e5f72d01 brcmfmac: btcoex: replace init_timer with setup_timer
--
https://patchwork.kernel.org/patch/9723793/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [patch net-next RFC] net: sched: cls_api: make reclassify return all the way back to the original tp
From: Jiri Pirko @ 2017-05-22 15:09 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
With the introduction of chain goto action, the reclassification would
cause the re-iteration of the actual chain. But it perhaps makes more
sense to restart the whole thing. Thoughts?
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_api.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 01a8b8b..89fbb35 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -300,7 +300,8 @@ int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
__be16 protocol = tc_skb_protocol(skb);
#ifdef CONFIG_NET_CLS_ACT
const int max_reclassify_loop = 4;
- const struct tcf_proto *old_tp = tp;
+ const struct tcf_proto *orig_tp = tp;
+ const struct tcf_proto *first_tp;
int limit = 0;
reclassify:
@@ -315,9 +316,10 @@ int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
err = tp->classify(skb, tp, res);
#ifdef CONFIG_NET_CLS_ACT
if (unlikely(err == TC_ACT_RECLASSIFY && !compat_mode)) {
+ first_tp = orig_tp;
goto reset;
} else if (unlikely(TC_ACT_EXT_CMP(err, TC_ACT_GOTO_CHAIN))) {
- old_tp = res->goto_tp;
+ first_tp = res->goto_tp;
goto reset;
}
#endif
@@ -335,7 +337,7 @@ int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
return TC_ACT_SHOT;
}
- tp = old_tp;
+ tp = first_tp;
protocol = tc_skb_protocol(skb);
goto reclassify;
#endif
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] kernel: bpf: remove dead code
From: Daniel Borkmann @ 2017-05-22 14:52 UTC (permalink / raw)
To: David Miller, garsilva; +Cc: ast, netdev, linux-kernel
In-Reply-To: <20170522.103800.1354089494827582585.davem@davemloft.net>
On 05/22/2017 04:38 PM, David Miller wrote:
> From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
> Date: Mon, 22 May 2017 09:07:46 -0500
>
>> Execution cannot reach NET_IP_ALIGN inside the following statement:
>> ip_align = strict ? 2 : NET_IP_ALIGN
>>
>> Addresses-Coverity-ID: 1409762
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>> ---
>> NOTE: variable ip_align could also be removed and use value 2 directly.
>
> Incorrect.
>
> Some platforms define NET_IP_ALIGN to zero, so the code must remain
> as is.
In the check_pkt_ptr_alignment(), when !strict you would already
return earlier from that function.
So, above test in ip_align will always give 2, meaning technically
the patch is correct, although hard-coded value less clean.
Perhaps something like the below to keep intentions more clear (and
it will get resolved during compile time anyway ...):
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a098d95..3cf1d60 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2297,8 +2297,10 @@ static inline int pskb_network_may_pull(struct sk_buff *skb, unsigned int len)
* Since this trade off varies between architectures, we allow NET_IP_ALIGN
* to be overridden.
*/
+#define NET_IP_ALIGN_DEFAULT 2
+
#ifndef NET_IP_ALIGN
-#define NET_IP_ALIGN 2
+#define NET_IP_ALIGN NET_IP_ALIGN_DEFAULT
#endif
/*
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 1eddb71..61f6aaa 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -812,7 +812,7 @@ static int check_pkt_ptr_alignment(const struct bpf_reg_state *reg,
* we force this to 2 which is universally what architectures use
* when they don't set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
*/
- ip_align = strict ? 2 : NET_IP_ALIGN;
+ ip_align = NET_IP_ALIGN ? : NET_IP_ALIGN_DEFAULT;
if ((ip_align + reg_off + off) % size != 0) {
verbose("misaligned packet access off %d+%d+%d size %d\n",
ip_align, reg_off, off, size);
^ permalink raw reply related
* Re: [PATCH] kernel: bpf: remove dead code
From: Gustavo A. R. Silva @ 2017-05-22 14:51 UTC (permalink / raw)
To: David Miller; +Cc: ast, daniel, netdev, linux-kernel
In-Reply-To: <20170522.103800.1354089494827582585.davem@davemloft.net>
Hi David,
Quoting David Miller <davem@davemloft.net>:
> From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
> Date: Mon, 22 May 2017 09:07:46 -0500
>
>> Execution cannot reach NET_IP_ALIGN inside the following statement:
>> ip_align = strict ? 2 : NET_IP_ALIGN
>>
>> Addresses-Coverity-ID: 1409762
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>> ---
>> NOTE: variable ip_align could also be removed and use value 2 directly.
>
> Incorrect.
>
> Some platforms define NET_IP_ALIGN to zero, so the code must remain
> as is.
The following piece of code at kernel/bpf/verifier.c:798 is preventing
value NET_IP_ALIGN to be stored in variable ip_align when _strict_ is
false:
798 if (!strict || size == 1)
799 return 0;
Thanks
^ permalink raw reply
* Re: [RFC net-next PATCH 3/5] net: introduce XDP driver features interface
From: Jesper Dangaard Brouer @ 2017-05-22 14:49 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev, brouer
In-Reply-To: <5920E62B.3040201@iogearbox.net>
On Sun, 21 May 2017 02:58:19 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 05/20/2017 09:53 AM, Jesper Dangaard Brouer wrote:
> > On Fri, 19 May 2017 19:13:29 +0200
> > Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> >> On 05/18/2017 05:41 PM, Jesper Dangaard Brouer wrote:
> >>> There is a fundamental difference between normal eBPF programs
> >>> and (XDP) eBPF programs getting attached in a driver. For normal
> >>> eBPF programs it is easy to add a new bpf feature, like a bpf
> >>> helper, because is it strongly tied to the feature being
> >>> available in the current core kernel code. When drivers invoke a
> >>> bpf_prog, then it is not sufficient to simply relying on whether
> >>> a bpf_helper exists or not. When a driver haven't implemented a
> >>> given feature yet, then it is possible to expose uninitialized
> >>> parts of xdp_buff. The driver pass in a pointer to xdp_buff,
> >>> usually "allocated" on the stack, which must not be exposed.
> >>
> >> When xdp_buff is being extended, then we should at least zero
> >> initialize all in-tree users that don't support or populate this
> >> field, thus that it's not uninitialized memory. Better would be
> >> to have a way to reject the prog in the first place until it's
> >> implemented (but further comments on feature bits below).
> >
> > Going down a path where we need to zero out the xdp_buff looks a lot
> > like the sk_buff zeroing, which is the top perf cost associated with
> > SKBs see[1]. XDP is is about not repeating the same issue we had with
> > the SKB...
>
> But if we agree on implementing a certain feature that requires to
> add a new member, then basic requirement should be that it needs to
> be implementable by all XDP enabled drivers, so that users eventually
> don't need to worry which driver they run to access a XDP feature.
> In that case, zeroing that member until it gets properly implemented
> is just temporary (and could be an incentive perhaps).
>
> > [1] https://prototype-kernel.readthedocs.io/en/latest/blogposts/xdp25_eval_generic_xdp_tx.html#analyzing-build-skb-and-memset
> >
> >>> Only two user visible NETIF_F_XDP_* net_device feature flags are
> >>> exposed via ethtool (-k) seen as "xdp" and "xdp-partial".
> >>> The "xdp-partial" is detected when there is not feature equality
> >>> between kernel and driver, and a netdev_warn is given.
> >>
> >> I think having something like a NETIF_F_XDP_BIT for ethtool to
> >> indicate support as "xdp" is quite useful. Avoids having to grep
> >> the kernel tree for ndo_xdp callback. ;) A "xdp-partial" would
> >> still be unclear/confusing to the user whether his program loads
> >> or doesn't which is the only thing a user (or some loading infra)
> >> cares about eventually, so one still needs to go trying to load
> >> the XDP code to see whether that fails for the native case.
> >
> > Good that we agree on usefulness of the NETIF_F_XDP_BIT. The
> > "xdp-partial" or "xdp-challenged" is an early indication to the user
> > that they should complain to the vendor. I tried to keep it simple
> > towards the user. Do you think every feature bit should be exposed to
> > userspace?
>
> That would potentially require us to go down that path and expose
> feature bits for everything, even something as silly as new flags
> for a specific helper that requires some sort of additional support.
> We probably rather want to keep such thing in the kernel for now
> and potentially reject loads instead.
>
> >>> The idea is that XDP_DRV_* feature bits define a contract between
> >>> the driver and the kernel, giving a reliable way to know that XDP
> >>> features a driver promised to implement. Thus, knowing what bpf
> >>> side features are safe to allow.
> >>>
> >>> There are 3 levels of features: "required", "devel" and "optional".
> >>>
> >>> The motivation is pushing driver vendors forward to support all
> >>> the new XDP features. Once a given feature bit is moved into
> >>> the "required" features, the kernel will reject loading XDP
> >>> program if feature isn't implemented by driver. Features under
> >>> developement, require help from the bpf infrastrucure to detect
> >>> when a given helper or direct-access is used, using a bpf_prog
> >>> bit to mark a need for the feature, and pulling in this bit in
> >>> the xdp_features_check(). When all drivers have implemented
> >>> a "devel" feature, it can be moved to the "required" feature and
> >>
> >> The problem is that once you add bits markers to bpf_prog like we
> >> used to do in the past, then as you do in patch 4/5 with the
> >> xdp_rxhash_needed bit, they will need to be turned /on/ unconditionally
> >> when a prog has tail calls.
> >
> > Yes, with tail calls, we have to enable all features. But that is a
> > good thing, as it forces vendors to quickly implement all features.
> > And it is no different from moving a feature into the "required" bits,
> > once all drivers implement it. It is only a limitation for tail calls,
> > and something we can fix later (for handling this for tail calls).
>
> But the issue I pointed out with this approach is that XDP programs
> using tail calls will suddenly break and get rejected from one
> version to another.
>
> That's basically breaking the contract we have today where it must
> be guaranteed that older programs keep working on newer kernels,
> exactly the same with uapi. Breaking user programs is a no-go,
> not a good thing at all (it will hurt users and they move on with
> something else). So it's not something we can 'fix' at some later
> point in time; such feature detection would need to consider this
> from day 1.
This is a very good point Daniel, that older program should be able to
run. But this will only happen when tail calls are in-use, and NIC
vendors don't keep their drivers up-to-date. Creating a strong
incentive for drivers implementing all XDP features (which you have
argue for). Still I see your point.
> > BPF have some nice features of evaluating the input program
> > "load-time", which is what I'm taking advantage of as an optimization
> > here (let use this nice bpf property). It is only tail calls that
> > cannot evaluate this "load-time". Thus, if you care about tail calls,
> > supporting intermediate features, we could later fix that by adding a
> > runtime feature check in the case of tail calls.
How do we move forward from here?
Let me try to restate the problem: There is a general disconnect
between bpf and what XDP drivers support.
The bpf model (AFAIK) is that your bpf program will get rejected when
loading your bpf_prog. This happens if you are using a bpf_helper or
direct-ctx-access which is not supported/avail in the kernel. Right??
(This also happens for tail-call programs, right?) (I do like this
model of failing the program when the feature is not avail).
I guess, new bpf features are discovered by looking at uapi/bpf.h and
then try to use the feature, and see if your program loads.
The disconnect is that when writing XDP-bpf programs, then you will
not get any feedback when you are calling a bpf-helper that the XDP
driver doesn't support. The XDP bpf-program loads and can happily run
calling core-kernel XDP helpers. Now, how will the XDP program author
know that his call to the helper is valid?
For rxhash, we could init the fields to zero (in drivers not
supporting it), but how will the XDP bpf_prog author know whether or
not a NIC driver supports XDP-rxhash? (I guess, he could write a XDP
program, that sets the XDP software hash, and then add a match via TC
meta match or another cls_bpf program that read the skb->hash value,
to see if changing the rxhash works... it seem clumpsy)
For xdp_adjust_head, it was even-worse, as a boundry check against
data_end with e.g. zero is no boundry, and would allow unbounded
memory access from the xdp.data_end pointer. We actually have
released kernels with this bug, which can be triggered with a bpf
tail-call.
I just did a quick check on linux-stable.git for v4.10.17 and it looks
like commit c2002f983767 ("bpf: fix checking xdp_adjust_head on tail
calls") is missing, meaning drivers nfp, mlx5, nfp and virtio_net is
likely subject to the adjust_head unbounded memory access bug via tail
calls. I really wish we had a reliable way of avoiding these kind of
bpf vs. XDP-driver mismatches.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
p.s. Remember, to verify if a driver supports adjust_head, grep after
"data_hard_start" in the driver code... which is also quite strange
for users to know.
^ permalink raw reply
* Re: [PATCH net-next 00/20] net: dsa: distribute switch events
From: Andrew Lunn @ 2017-05-22 14:48 UTC (permalink / raw)
To: David Miller; +Cc: vivien.didelot, netdev, linux-kernel, kernel, f.fainelli
In-Reply-To: <20170522.104557.1244582147577060590.davem@davemloft.net>
On Mon, May 22, 2017 at 10:45:57AM -0400, David Miller wrote:
> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Date: Fri, 19 May 2017 17:00:35 -0400
>
> > DSA is by nature the support for a switch fabric, which can be composed
> > of a single, or multiple interconnected Ethernet switch chips.
> >
> > The current DSA core behavior is to identify the slave port targeted by
> > a request (e.g. adding a VLAN entry), and program the switch chip to
> > which it belongs accordingly.
> >
> > This is problematic in a multi-chip environment, since all chips of a
> > fabric must be aware of most configuration changes. Here are some
> > concrete examples in a 3-chip environment:
> ...
> > This patch series uses the notification chain introduced for bridging,
> > to notify not only bridge, but switchdev attributes and objects events
> > to all switch chips of the fabric.
>
> Andrew or Florian, can I get a review?
Yes, it is on my TODO list for today/tomorrow.
Andrew
^ permalink raw reply
* Re: RDS: TCP: Delete an error message for a failed memory allocation in rds_tcp_init_net()
From: Sowmini Varadhan @ 2017-05-22 14:46 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-rdma, netdev, rds-devel, kernel-janitors, David S. Miller,
Santosh Shilimkar, LKML
In-Reply-To: <1e1a5d08-34a7-1b88-80ac-c650c4ae76cf@users.sourceforge.net>
> Do you find information from a Linux allocation failure report sufficient
> for such an use case?
yes, I suppose that would cover the needed cases.
Your change looks good to me.
Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
^ permalink raw reply
* [patch net-next] net: sched: cls_matchall: fix null pointer dereference
From: Jiri Pirko @ 2017-05-22 14:46 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, mlxsw, colin.king, yotamg
From: Jiri Pirko <jiri@mellanox.com>
Since the head is guaranteed by the check above to be null, the call_rcu
would explode. Remove the previously logically dead code that was made
logically very much alive and kicking.
Fixes: 985538eee06f ("net/sched: remove redundant null check on head")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_matchall.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index dee469f..51859b8 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -203,7 +203,6 @@ static int mall_change(struct net *net, struct sk_buff *in_skb,
*arg = (unsigned long) head;
rcu_assign_pointer(tp->root, new);
- call_rcu(&head->rcu, mall_destroy_rcu);
return 0;
err_replace_hw_filter:
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 00/20] net: dsa: distribute switch events
From: David Miller @ 2017-05-22 14:45 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170519210055.9366-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Fri, 19 May 2017 17:00:35 -0400
> DSA is by nature the support for a switch fabric, which can be composed
> of a single, or multiple interconnected Ethernet switch chips.
>
> The current DSA core behavior is to identify the slave port targeted by
> a request (e.g. adding a VLAN entry), and program the switch chip to
> which it belongs accordingly.
>
> This is problematic in a multi-chip environment, since all chips of a
> fabric must be aware of most configuration changes. Here are some
> concrete examples in a 3-chip environment:
...
> This patch series uses the notification chain introduced for bridging,
> to notify not only bridge, but switchdev attributes and objects events
> to all switch chips of the fabric.
Andrew or Florian, can I get a review?
I audited the slave-->port transformations and they all look
good.
^ permalink raw reply
* Re: [PATCH v3 net-next 2/5] phy: micrel: add Microchip KSZ 9477 Switch PHY support
From: Andrew Lunn @ 2017-05-22 14:44 UTC (permalink / raw)
To: Woojung.Huh
Cc: f.fainelli, vivien.didelot, sergei.shtylyov, netdev, davem,
UNGLinuxDriver
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40A80CF8@CHN-SV-EXMX02.mchp-main.com>
On Mon, May 22, 2017 at 02:38:39PM +0000, Woojung.Huh@microchip.com wrote:
> > > Signed-off-by: Woojung Huh <Woojung.Huh@microchip.com>
> > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> >
> > Signed-off-by? I didn't contribute any code. It probably should be
> >
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Andrew,
>
> Your reply on 5/13 was with "Signed-off" :)
O.K. My error then. Please feel free at ask me, if you think something
i say is wrong...
> Will change to "Reviewed-by" in next patch.
Thanks.
Andrew
^ permalink raw reply
* Re: [PATCHv4] wlcore: add wl1285 compatible
From: Kalle Valo @ 2017-05-22 14:44 UTC (permalink / raw)
To: David Miller
Cc: sebastian.reichel, sre, tony, marcel, robh+dt, linux-wireless,
linux-omap, linux-kernel, netdev
In-Reply-To: <20170522.103010.1779800840743690143.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Mon, 22 May 2017 12:28:20 +0300
>
>> Sebastian Reichel <sebastian.reichel@collabora.co.uk> writes:
>>
>>> Motorola Droid 4 uses a WL1285C. With differences between the
>>> chips not being public let's add explicit binding for wl1285
>>> instead of relying on wl1283 being very similar.
>>>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
>>> ---
>>> Hi Dave,
>>>
>>> I previously send this in two patches, but its hard to apply without
>>> requiring multiple kernel releases (the driver must be updated before
>>> the DTS change). Since the actual change is not very complex Marcel
>>> Holtmann & Tony Lindgren suggested, that I send this directly to you
>>> in a single patch for inclusion into 4.12. This also means, that the
>>> remaining series can be queued normally for 4.13.
>>
>> I noticed that Dave set this patch to Awaiting Upstream state on his
>> patchwork:
>>
>> https://patchwork.ozlabs.org/patch/759042/
>>
>> Which makes me suspect that he is waiting me to apply this (as I
>> normally apply wlcore patches). Dave, should I actually take this patch?
>> What do you prefer?
>
> Anything that touches wireless drivers I defer to you, yes.
Thanks, I'll take it then. Not sure why Sebastian was suggested to
submit this patch via your tree in the first place.
https://patchwork.kernel.org/patch/9713645/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] net: fec: add post PHY reset delay DT property
From: Andrew Lunn @ 2017-05-22 14:43 UTC (permalink / raw)
To: Quentin Schulz
Cc: fugang.duan-3arQi8VN3Tc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <f667da6e-d300-ec79-cc49-3808d9758a99-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, May 22, 2017 at 04:00:47PM +0200, Quentin Schulz wrote:
> Hi Andrew
>
> On 22/05/2017 15:57, Andrew Lunn wrote:
> > On Mon, May 22, 2017 at 11:15:17AM +0200, Quentin Schulz wrote:
> >> Some PHY require to wait for a bit after the reset GPIO has been
> >> toggled. This adds support for the DT property `phy-reset-post-delay`
> >> which gives the delay in milliseconds to wait after reset.
> >>
> >> If the DT property is not given, no delay is observed. Post reset delay
> >> greater than 1000ms are invalid and are default to 1ms.
> >
> > Hi Quentin
> >
> > If it is invalid, please return -EINVAL.
> >
>
> Just copying the wording and behavior of phy-reset-duration. Should we
> then change the behavior of phy-reset-duration as well to return -EINVAL
> in that case or I just leave both as is?
No, you cannot change phy-reset-duration. There could be device tree
blobs out in the wild with invalid phy-reset-duration which silently
get converted to 1000ms by the code. You cannot break them.
However, you can prevent new additions which add invalid
phy-reset-post-delay.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v3 net-next 2/5] phy: micrel: add Microchip KSZ 9477 Switch PHY support
From: Woojung.Huh @ 2017-05-22 14:38 UTC (permalink / raw)
To: andrew
Cc: f.fainelli, vivien.didelot, sergei.shtylyov, netdev, davem,
UNGLinuxDriver
In-Reply-To: <20170522143249.GD29447@lunn.ch>
> > Signed-off-by: Woojung Huh <Woojung.Huh@microchip.com>
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> Signed-off-by? I didn't contribute any code. It probably should be
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew,
Your reply on 5/13 was with "Signed-off" :)
Will change to "Reviewed-by" in next patch.
Woojung
^ permalink raw reply
* Re: [PATCH] kernel: bpf: remove dead code
From: David Miller @ 2017-05-22 14:38 UTC (permalink / raw)
To: garsilva; +Cc: ast, daniel, netdev, linux-kernel
In-Reply-To: <20170522140746.GA10113@embeddedgus>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Mon, 22 May 2017 09:07:46 -0500
> Execution cannot reach NET_IP_ALIGN inside the following statement:
> ip_align = strict ? 2 : NET_IP_ALIGN
>
> Addresses-Coverity-ID: 1409762
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
> ---
> NOTE: variable ip_align could also be removed and use value 2 directly.
Incorrect.
Some platforms define NET_IP_ALIGN to zero, so the code must remain
as is.
^ permalink raw reply
* Re: RDS: TCP: Delete an error message for a failed memory allocation in rds_tcp_init_net()
From: SF Markus Elfring @ 2017-05-22 14:32 UTC (permalink / raw)
To: Sowmini Varadhan, linux-rdma, netdev, rds-devel, kernel-janitors
Cc: David S. Miller, Santosh Shilimkar, LKML
In-Reply-To: <20170522142651.GA29434@oracle.com>
>> Omit an extra message for a memory allocation failure in this function.
>
> The change itself is harmless, but I'm curious about the "extra"
> part: "extra" from what? If this happens, hopefully this will be logged
> somewhere? Note that this type of (infrequent) logging noise is useful
> in some cases, e.g., with 8ce675ff, when one is trying to do the
> post-mortem of where things first went wrong.
Do you find information from a Linux allocation failure report sufficient
for such an use case?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v3 net-next 2/5] phy: micrel: add Microchip KSZ 9477 Switch PHY support
From: Andrew Lunn @ 2017-05-22 14:32 UTC (permalink / raw)
To: Woojung.Huh
Cc: f.fainelli, vivien.didelot, sergei.shtylyov, netdev, davem,
UNGLinuxDriver
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40A7C02D@CHN-SV-EXMX02.mchp-main.com>
On Fri, May 19, 2017 at 10:57:15PM +0000, Woojung.Huh@microchip.com wrote:
> From: Woojung Huh <Woojung.Huh@microchip.com>
>
> Adding Microchip 9477 Phy included in KSZ9477 Switch.
>
> Signed-off-by: Woojung Huh <Woojung.Huh@microchip.com>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by? I didn't contribute any code. It probably should be
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v3 net-next 3/5] dsa: add DSA switch driver for Microchip KSZ9477
From: Andrew Lunn @ 2017-05-22 14:31 UTC (permalink / raw)
To: Woojung.Huh
Cc: f.fainelli, vivien.didelot, sergei.shtylyov, netdev, davem,
UNGLinuxDriver
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40A7C023@CHN-SV-EXMX02.mchp-main.com>
On Fri, May 19, 2017 at 10:57:12PM +0000, Woojung.Huh@microchip.com wrote:
> +static struct {
> + int index;
> + char string[ETH_GSTRING_LEN];
Hi Woojung
Since you need to respin for the skb_put_padto(), please make this
const.
> +static int get_vlan_table(struct dsa_switch *ds, u16 vid, u32 *vlan_table)
> +{
> + struct ksz_device *dev = ds->priv;
> + u8 data;
> + int timeout = 1000;
> +
> + ksz_write16(dev, REG_SW_VLAN_ENTRY_INDEX__2, vid & VLAN_INDEX_M);
> + ksz_write8(dev, REG_SW_VLAN_CTRL, VLAN_READ | VLAN_START);
> +
> + /* wait to be cleared */
> + data = 0;
> + do {
> + ksz_read8(dev, REG_SW_VLAN_CTRL, &data);
> + if (!(data & VLAN_START))
> + break;
> + usleep_range(1, 10);
> + } while (timeout-- > 0);
> +
> + if (!timeout)
> + return -ETIMEDOUT;
> +
> + ksz_read32(dev, REG_SW_VLAN_ENTRY__4, &vlan_table[0]);
> + ksz_read32(dev, REG_SW_VLAN_ENTRY_UNTAG__4, &vlan_table[1]);
> + ksz_read32(dev, REG_SW_VLAN_ENTRY_PORTS__4, &vlan_table[2]);
> +
> + ksz_write8(dev, REG_SW_VLAN_CTRL, 0);
> +
> + return 0;
> +}
> +
> +static int set_vlan_table(struct dsa_switch *ds, u16 vid, u32 *vlan_table)
> +{
> + struct ksz_device *dev = ds->priv;
> + u8 data;
> + int timeout = 1000;
> +
> + ksz_write32(dev, REG_SW_VLAN_ENTRY__4, vlan_table[0]);
> + ksz_write32(dev, REG_SW_VLAN_ENTRY_UNTAG__4, vlan_table[1]);
> + ksz_write32(dev, REG_SW_VLAN_ENTRY_PORTS__4, vlan_table[2]);
> +
> + ksz_write16(dev, REG_SW_VLAN_ENTRY_INDEX__2, vid & VLAN_INDEX_M);
> + ksz_write8(dev, REG_SW_VLAN_CTRL, VLAN_START | VLAN_WRITE);
> +
> + do {
> + ksz_read8(dev, REG_SW_VLAN_CTRL, &data);
> + if (!(data & VLAN_START))
> + break;
> + usleep_range(1, 10);
> + } while (timeout-- > 0);
> +
> + if (!timeout)
> + return -ETIMEDOUT;
> +
> + ksz_write8(dev, REG_SW_VLAN_CTRL, 0);
> +
> + mutex_lock(&dev->vlancache_mutex);
Humm. I think this is wrong. Shouldn't you hold the mutex while you
change the hardware as well as the cache. Otherwise there is a risk
your cache could be different to the hardware when you get a race
between two threads?
> +
> + /* update vlan cache table */
> + dev->vlan_cache[vid].table[0] = vlan_table[0];
> + dev->vlan_cache[vid].table[1] = vlan_table[1];
> + dev->vlan_cache[vid].table[2] = vlan_table[2];
> +
> + mutex_unlock(&dev->vlancache_mutex);
> +
> + return 0;
> +}
Andrew
^ permalink raw reply
* Re: [PATCHv4] wlcore: add wl1285 compatible
From: David Miller @ 2017-05-22 14:30 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ,
sre-DgEjT+Ai2ygdnm+yROfE0A, tony-4v6yS6AI5VpBDgjK7y7TUQ,
marcel-kz+m5ild9QBg9hUCZPvPmw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8737bx5jgr.fsf-5ukZ45wKbUHoml4zekdYB16hYfS7NtTn@public.gmane.org>
From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Date: Mon, 22 May 2017 12:28:20 +0300
> Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> writes:
>
>> Motorola Droid 4 uses a WL1285C. With differences between the
>> chips not being public let's add explicit binding for wl1285
>> instead of relying on wl1283 being very similar.
>>
>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Acked-by: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
>> ---
>> Hi Dave,
>>
>> I previously send this in two patches, but its hard to apply without
>> requiring multiple kernel releases (the driver must be updated before
>> the DTS change). Since the actual change is not very complex Marcel
>> Holtmann & Tony Lindgren suggested, that I send this directly to you
>> in a single patch for inclusion into 4.12. This also means, that the
>> remaining series can be queued normally for 4.13.
>
> I noticed that Dave set this patch to Awaiting Upstream state on his
> patchwork:
>
> https://patchwork.ozlabs.org/patch/759042/
>
> Which makes me suspect that he is waiting me to apply this (as I
> normally apply wlcore patches). Dave, should I actually take this patch?
> What do you prefer?
Anything that touches wireless drivers I defer to you, yes.
^ permalink raw reply
* Re: [PATCH 3/3] RDS: TCP: Delete an error message for a failed memory allocation in rds_tcp_init_net()
From: Sowmini Varadhan @ 2017-05-22 14:26 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g, David S. Miller,
Santosh Shilimkar, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5d523cf8-1540-e704-2301-a5e0205cb536-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
On (05/22/17 16:13), SF Markus Elfring wrote:
>
> Omit an extra message for a memory allocation failure in this function.
The change itself is harmless, but I'm curious about the "extra"
part: "extra" from what? If this happens, hopefully this will be logged
somewhere? Note that this type of (infrequent) logging noise is useful
in some cases, e.g., with 8ce675ff, when one is trying to do the
post-mortem of where things first went wrong.
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* network performance degradation in virtio_net in 4.12-rc
From: Mikulas Patocka @ 2017-05-22 14:25 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang; +Cc: kvm, virtualization, netdev
Hi
I see severe network performance degradation with the kernels 4.12-rc1 and
4.12-rc2 in the network virtio driver. Download rate drops down to about
100kB/s.
I bisected it and it is caused by patch
d85b758f72b05a774045545f24d70980e3e9aac4 ("virtio_net: fix support for
small rings"). When I revert this patch, the problem goes away.
The host is Debian Jessie with kernel 4.4.62, the guest is Debian Sid with
kernel 4.12-rc.
Mikulas
^ permalink raw reply
* Re: vhost/scsi: Delete error messages for failed memory allocations in five functions
From: SF Markus Elfring @ 2017-05-22 14:21 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: kvm, Michael S. Tsirkin, netdev, kernel-janitors, LKML,
virtualization
In-Reply-To: <20170522140935.GB1021@stefanha-x1.localdomain>
> No objection from me but please make sure to keep vq_err().
How long should I wait before I may dare to send another variant for the
discussed update suggestion?
Which commit message would be acceptable then for this update step?
Regards,
Markus
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2017-05-22 14:17 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, mlichvar, willemb
In-Reply-To: <20170522134300.0bfd175a@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 May 2017 13:43:00 +1000
> Hi Dave,
>
> On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Mon, 22 May 2017 11:16:05 +1000
>>
>> > After merging the net-next tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> >
>> > net/socket.c: In function 'put_ts_pktinfo':
>> > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
>> > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
>> > ^
>> > Caused by commit
>> >
>> > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>> >
>> > This probably broke every architecture that has its own
>> > arch/<arch>/include/uapi/asm/socket.h that does not include
>> > include/uapi/asm-generic/socket.h :-(
>> >
>> > I have used the net-next tree from next-20170519 for today.
>>
>> I've just pushed the following, thanks for the report:
>
> Looks good except:
>
>> diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
>> index 5147018..784b871 100644
>> --- a/arch/parisc/include/uapi/asm/socket.h
>> +++ b/arch/parisc/include/uapi/asm/socket.h
>> @@ -97,4 +97,6 @@
>>
>> #define SO_COOKIE 0x4032
>>
>> +#define SCM_TIMESTAMPING_PKTINFO 58
>
> Does this need to be 0x4033 (or something)?
Good catch, I'll fix this up!
^ 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