> I am not sure it matters - if I understood your reply, there is no
> valid use case to change the frequency in that mode (and all that
> code should be removed);
All of wext *is* being removed - slowly :)
It's not longer default in the kernel configuration now.
IIRC, there actually was a
On Mon, 2017-01-09 at 16:25 +0100, michael-dev wrote:
> Am 09.01.2017 13:15, schrieb Johannes Berg:
> > > That is bridge fdb entries (need to) expire so the bridge might
> > > "forget" a still-connected station not sending but only consuming
> > > broadcast
> > Looks better, but
> >
> > > +static struct work_struct rfkill_any_work;
> >
> > At least on module exit you need to cancel this work.
>
> It is cancelled in rfkill_any_led_trigger_unregister(). It seemed
> fitting to do it this way as rfkill_any_work is initialized in
>
On Fri, 2017-01-06 at 16:27 -0500, David Miller wrote:
> From: Johannes Berg <johan...@sipsolutions.net>
> Date: Fri, 6 Jan 2017 13:37:20 +0100
>
> > Here's another fix for something I noticed while reviewing the code
> in
> > a new suggested patch that added
On Thu, 2017-01-05 at 15:38 +0100, Jorge Ramirez wrote:
> do you mean this?
>
> [jramirez@igloo ~ (debian-qcom-dragonboard410c-16.09-local $)]$ git
> diff
> diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
> index a4e8af3..c56bac5 100644
> --- a/net/wireless/wext-sme.c
> +++
> > A host SHOULD silently discard a datagram that is received via
> > a link-layer broadcast (see Section 2.4) but does not specify
> > an IP multicast or broadcast destination address.
>
> This example is the other way round. It specifies how the IP
> destination
On Mon, 2017-01-09 at 12:44 +0100, M. Braun wrote:
> Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> > Does it make sense to implement the two in separate layers though?
> >
> > Clearly, this part needs to be implemented in the bridge layer due
> > to
> > the
> - Handle the global mutex properly when rfkill_set_{hw,sw}_state()
> or
> rfkill_set_states() is called from within an rfkill callback. v2
> always tried to lock the global mutex in such a case, which led
> to a
> deadlock when an rfkill driver called one of the above functions
>
)
A single fix to avoid loading an skb->cb pointer too early.
----
Johannes Berg (1):
mac80211: initialize fast-xmit 'info' later
net/mac80211/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Johannes Berg <johannes.b...@intel.com>
There are no users of this ("vrfkill") in the tree, so it's just
dead code - remove it.
This also isn't really how rfkill is supposed to be used - it's
intended as a signalling mechanism to/from the device, which the
driver (and pa
> My understanding is it is generally felt that using the regulator
> enable GPIO commonly found on WiFi chips for rfkill is an abuse of
> rfkill as it is more that just an RF disable. From a DT standpoint,
> this seems like creating a binding for what a Linux driver wants.
> Instead, I think
On Mon, 2017-01-02 at 16:01 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.b...@intel.com>
>
> There are no users of this ("vrfkill") in the tree, so it's just
> dead code - remove it.
>
> This also isn't really how rfkill is supposed to be used
On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:
> Actually, I do not quite understand that remark in the mac80211
> multicast-to-unicast patch. IP should not care about the ethernet
> header?
But it does, for example RFC 1122 states:
When a host sends a datagram to a link-layer
On Sat, 2017-01-07 at 15:55 +0100, Linus Lüssing wrote:
> On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> > Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> > >
> > > > The bridge layer can use IGMP snooping to ensure that the
> > > > mu
> The bridge layer can use IGMP snooping to ensure that the multicast
> stream is only transmitted to clients that are actually a member of
> the group. Can the mac80211 feature do the same?
No, it'll convert the packet for all clients that are behind that
netdev. But that's an argument for
On Fri, 2017-01-06 at 07:07 +0100, Michał Kępień wrote:
> Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-
> any,
> which may be useful on laptops with a single "radio LED" and multiple
> radio transmitters. The trigger is meant to turn a LED on whenever
> there is at least
)
Another single fix, to correctly handle destruction of a
single netlink socket having ownership of multiple objects
(scheduled scan requests and interfaces.)
Johannes Berg (1):
nl80211: fix sched scan netlink socket owner
On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> > I wonder if MAC80211 should be doing IGMP snooping and not bridge
> > in this environment.
>
> In the long term, yes. For now, not quite sure.
There's no "for now" in
> Just to ensure things get cleaned up properly, as of now it looks
> like you only reverted patch 2/2 of my v2 and Arnd's fix to patch
> 1/2, not patch 1/2 itself.
Oops. I've fixed that up to only revert your patch - I wanted the
revert in the tree to document the issue, rather than just
Hi Mike,
Thanks for the report. I'm sorry I missed this in review - obviously we
can't call something that acquires the mutex from rfkill_set_sw_state()
which clearly states, in the documentation:
* This function can be called in any context, even from within rfkill
* callbacks.
I've reverted
On Fri, 2017-03-24 at 18:06 -0700, Matthias Kaehlcke wrote:
> __ieee80211_amsdu_copy_frag intentionally initializes a pointer to
> array[-1] to increment it later to valid values. clang rightfully
> generates an array-bounds warning on the initialization statement.
> Work around this by
> > > - const skb_frag_t *frag = >frags[-1];
> > > + const skb_frag_t *frag = >frags[0];
[...]
> > > + frag--;
> >
> > Isn't it just a question of time until the compiler will see
> > through this trick and warn about it?
>
> Frag is incremented again before being accessed, so there is nothing
inue;
D'oh. I don't know how that ended up in there, tbh.
Acked-by: Johannes Berg <johan...@sipsolutions.net>
johannes
Hi Sven,
> But I could be completely wrong about it. It would therefore be
> interesting for me to know who would be responsible to start the
> queues when ieee80211_do_open rejected it for IBSS.
Well, once ieee80211_offchannel_return() is called, that should do the
needful and end up in
> if (local->ops->wake_tx_queue)
> return;
>
> evaluates to true. The rest rest of the function is therefore always
> skipped for ath9k.
Ahh, yes, ok.
> Removing this is enough to fix the problem. And now you will propably
> say "hey, this is not my code". And this is the
From: Johannes Berg <johannes.b...@intel.com>
Sowmini pointed out Dmitry's RTNL deadlock report to me, and it turns out
to be perfectly accurate - there are various error paths that miss unlock
of the RTNL.
To fix those, change the locking a bit to not be conditional in all
On Wed, 2017-03-15 at 14:59 -0700, David Miller wrote:
> From: Johannes Berg <johan...@sipsolutions.net>
> Date: Wed, 15 Mar 2017 14:29:13 +0100
>
> > From: Johannes Berg <johannes.b...@intel.com>
> >
> > Sowmini pointed out Dmitry's RTNL de
On Thu, 2017-03-16 at 11:18 -0700, David Miller wrote:
> From: Johannes Berg <johan...@sipsolutions.net>
> Date: Thu, 16 Mar 2017 10:51:55 +0100
>
> > Here's the pull request you were waiting for. I went through all my
> > pending patches but only this on
Hi all,
Occasionally - we just had another case - people want to hook into
packets received and processed by the mac80211 stack, but because they
don't need all of them (e.g. not data packets), even adding a monitor
interface and bringing it up has too high a cost because SKBs need to
be prepared
deadlocks (2017-03-16 10:30:03 +0100)
Just a single fix, for the RTNL locking issues.
Johannes Berg (1):
nl80211: fix dumpit error path RTNL deadlocks
net
> Attach at just above the driver, before it ever gets to
> stations/vdevs, and ignore radiotap headers and/or add special
> processing for metadata like rx-info?
That'd be a different feature, perhaps more like XDP.
There anyway is no radiotap header at that point, but not changing
whether or
On Thu, 2017-03-09 at 10:34 +0100, ondrej.lyso...@seznam.cz wrote:
> From: Ondřej Lysoněk
>
> Use setup_timer() and setup_deferrable_timer() to set the data and
> function timer fields. It makes the code cleaner and will allow for
> easier change of the timer struct
From: Johannes Berg <johannes.b...@intel.com>
The error message here should mention 'ctx' since the context
is now more generic than just an skb.
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Johannes Berg <johannes.b...@intel.com>
There's no need to have struct bpf_prog_type_list since
it just contains a list_head, the type, and the ops
pointer. Since the types are densely packed and not
actually dynamically registered, it's much easier and
smaller to have an array of typ
From: Johannes Berg <johannes.b...@intel.com>
There's no need to have struct bpf_map_type_list since
it just contains a list_head, the type, and the ops
pointer. Since the types are densely packed and not
actually dynamically registered, it's much easier and
smaller to have an array of typ
On Tue, 2017-04-04 at 19:26 +0200, Daniel Borkmann wrote:
> > if (regs[BPF_REG_6].type != PTR_TO_CTX) {
> > - verbose("at the time of BPF_LD_ABS|IND R6 !=
> > pointer to skb\n");
> > + verbose("at the time of BPF_LD_ABS|IND R6 !=
> > pointer to ctx\n");
> >
Oops, I really meant to send these as RFC more than anything, because I
don't really understand why it's done that way :)
FWIW, the bloat-o-meter looks similar in both cases, like this:
add/remove: 0/11 grow/shrink: 9/1 up/down: 145/-365 (-220)
function old
On Mon, 2017-04-10 at 09:35 -0600, David Ahern wrote:
> > Do you have any better ideas?
>
> NETLINK_F_CAP_ACK and NETLINK_F_EXT_ACK should be incompatible -- if
> one is set the other can not be set. CAP_ACK means abbreviate the
> response and EXT_ACK means give me more data.
So you mean if I
On Mon, 2017-04-10 at 09:26 -0600, David Ahern wrote:
> On 4/8/17 2:24 PM, Johannes Berg wrote:
> > @@ -2300,14 +2332,35 @@ void netlink_ack(struct sk_buff *in_skb,
> > struct nlmsghdr *nlh, int err)
> > NLMSG_ERROR, payload, 0);
> >
On Mon, 2017-04-10 at 17:40 +0200, Johannes Berg wrote:
>
> Another thought: if we add a new flag that indicates "message has
> been capped", which we introduce in this same patch, then we can
> disentangle this more easily, right?
>
> Adding a new flag for &quo
On Tue, 2017-04-11 at 13:42 -0400, David Miller wrote:
> > Then, the library needs to be extended to enable this handling to
> > modify the way it needs to handle errors, together with the
> > setsockopt().
So I'd tend to agree, but
* it was easy to solve this, with the flags I added
* the
, to avoid crash
Arend Van Spriel (1):
cfg80211: check rdev resume callback only for registered wiphy
Johannes Berg (1):
mac80211: unconditionally start new netdev queues with iTXQ support
net/mac80211/iface.c | 3
From: Johannes Berg <johannes.b...@intel.com>
Since dev_change_xdp_fd() is only used in rtnetlink, which must
be built-in, there's no reason to export dev_change_xdp_fd().
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
---
net/core/dev.c | 1 -
1 file changed, 1 deletion(-)
From: Johannes Berg <johannes.b...@intel.com>
Add a new program type for wifi monitor interfaces. This program
type can
* access __sk_buff, but only skb->len
* call bpf_skb_load_bytes()
The program type is only enabled when something selects the new
Kconfig symbol WANT_BPF_WIFIM
From: Johannes Berg <johannes.b...@intel.com>
Add the necessary hooks for running monitor filter programs
in mac80211's RX path, before a frame is handed off to a
monitor interface. If the frame isn't accepted then this
will save the overhead of creating a new SKB and building
the radiotap
From: Johannes Berg <johannes.b...@intel.com>
Some people have suggested that the nl80211 API to look at
management frames should be extended to allow multiple
registrations, in order to allow applications other than
the usual controllers (wpa_supplicant/hostapd) to look out
for frame
On Tue, 2017-04-11 at 13:06 +0200, Daniel Borkmann wrote:
>
> There are instructions to convert endianess, see __bpf_prog_run(),
> the ALU_END_TO_BE, ALU_END_TO_LE labels for details. There's a
> BPF_ENDIAN() macro used in the test suite and other places.
Are these hooked up to llvm intrinsics
On Wed, 2017-04-12 at 09:06 -0600, David Ahern wrote:
>
> There was a discussion about side effects of adding strings (bloat,
> internationalization). Should ATTR_MSG be removed until that is
> ironed out? Leaving it in suggests it is ok to start adding strings.
I really do want the strings;
On Wed, 2017-04-12 at 11:22 -0400, David Miller wrote:
> From: Johannes Berg <johan...@sipsolutions.net>
> Date: Wed, 12 Apr 2017 16:29:07 +0200
>
> > On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
> >>
> >> struct ieee80211_if_mntr {
> >>
From: Johannes Berg <johannes.b...@intel.com>
This is an add-on to the previous patch that passes
the extended ACK structure where it's already available
by existing genl_info or extack function arguments.
This was done with this spatch (with some manual
adjustment of inden
From: Johannes Berg <johannes.b...@intel.com>
Pass the new extended ACK reporting struct to all of the
generic netlink parsing functions. For now, pass NULL in
almost all callers (except for some in the core.)
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
---
crypto/c
From: Johannes Berg <johannes.b...@intel.com>
Add the base infrastructure and UAPI for netlink extended ACK
reporting. All "manual" calls to netlink_ack() pass NULL for
now and thus don't get extended ACK reporting.
Big thanks goes to Pablo Neira Ayuso for not only bringing up
From: Johannes Berg <johannes.b...@intel.com>
Pass the extended ACK reporting struct down from generic
netlink to the families, using the existing struct
genl_info for simplicity.
Also add support to set the extended ACK information from
generic netlink users.
Signed-off-by: Johanne
From: Johannes Berg <johannes.b...@intel.com>
Now that we have extended error reporting and a new message format
for netlink ACK messages, also extend this to be able to return
arbitrary cookie data on success.
This will allow, for example, nl80211 to not send an extra message
for c
Changes since v4:
* use __NLMSGERR_ATTR_MAX instead of NUM_NLMSGERR_ATTRS
On Wed, 2017-04-12 at 15:17 +0200, Jiri Pirko wrote:
> Wed, Apr 12, 2017 at 02:34:07PM CEST, johan...@sipsolutions.net
> wrote:
> > From: Johannes Berg <johannes.b...@intel.com>
> >
> > Pass the new extended ACK reporting struct to all of the
>
> Johannes, I
> > } else {
> > flags |= NLM_F_CAPPED;
> > +
> > + if (nlk->flags & NETLINK_F_EXT_ACK &&
> > + extack && extack->cookie_len)
> > + tlvlen += nla_total_size(extack-
> > >cookie_len);
> > }
> >
>
> Now I see why you have "if (tlvlen)"
On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.b...@intel.com>
>
> Add a new program type for wifi monitor interfaces. This program
> type can
> * access __sk_buff, but only skb->len
> * call bpf_skb_load_bytes()
>
>
On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
>
> struct ieee80211_if_mntr {
> u32 flags;
>
[...]
+ bool deliver;
That's ... broken for multi-queue RX. I haven't really found a good
other way to do it. The best way will likely be to copy the SKB the
first time
On Wed, 2017-04-12 at 11:19 -0400, David Miller wrote:
>
> > Instead it may make more sense to just have a "wifi_info(skb,
> info)"
> > function you can call, e.g. with a structure that has various
> fields
> > and flags to see which you care about.
>
> I would advise against this, let the
From: Johannes Berg <johannes.b...@intel.com>
It's rather confusing that the netlink message flags are
numbered 1, 2, 4, 8, 16, 32, , 0x100. Make that
more understandable by numbering the lower ones with hex
constants as well.
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote:
> Clang raises a warning about the expression 'strlen(CONFIG_XXX)'
> being
> used in a logical operation. Clangs' builtin strlen function resolves
> the
> expression to a constant at compile time, which causes clang to
> generate
> a
On Thu, 2017-04-06 at 12:24 -0700, Matthias Kaehlcke wrote:
> I agree that the code looks worse :( I hoped to find a fix using a
> preprocessor condition but wasn't successful.
It's actually easy - just remove the 'default ""' from Kconfig, and
then the symbol won't be defined at all if it
On Thu, 2017-04-06 at 15:42 -0700, Matthias Kaehlcke wrote:
>
> Thanks, it would also require to move the initialization of
> ieee80211_default_rc_algo into an ifdef. If you can live with such a
> solution I'm happy to change it.
I think that'd be something I can live with, yeah.
> > git
> > If you just don't want to list things multiple times how about:
> >
> > linux/bpf_verifiers.h:
> > BPF_VERIFIER(BPF_PROG_TYPE_SOCKET_FILTER, sk_filter_prog_ops)
> > BPF_VERIFIER(BPF_PROG_TYPE_SCHED_CLS, tc_cls_prog_ops)
> > ...
> >
> > Then in bpf.h:
> >
> > #define BPF_VERIFIER(TYPE_VAL,
> perhaps I misunderstand something, but nla_parse suggests attribute
> type can not be 0:
[...]
Yes, some - very few - families still insist on using attribute 0,
perhaps parsing by hand or so. Like you say though, the entire
infrastructure makes that hard and undesirable, so I don't really see
> @@ -2300,14 +2332,35 @@ void netlink_ack(struct sk_buff *in_skb, struct
> nlmsghdr *nlh, int err)
rep = __nlmsg_put(skb, NETLINK_CB(in_skb).portid, nlh->nlmsg_seq,
> NLMSG_ERROR, payload, 0);
> errmsg = nlmsg_data(rep);
> errmsg->error = err;
This
I thought a little bit more about the part of reporting the broken and
missing attributes, and I'm not sure I'm entirely happy with that part.
For reporting broken attributes, I think the pointer is really the best
thing we can do - adding the attribute number in addition to that would
seem to be
Here's a respin, with davem's suggestion incorporated.
bloat-o-meter output is long because I gave things some consistent
names, but the summary is:
add/remove: 19/61 grow/shrink: 4/3 up/down: 728/-1354 (-626)
johannes
From: Johannes Berg <johannes.b...@intel.com>
There's no need to have struct bpf_prog_type_list since
it just contains a list_head, the type, and the ops
pointer. Since the types are densely packed and not
actually dynamically registered, it's much easier and
smaller to have an array of typ
From: Johannes Berg <johannes.b...@intel.com>
There's no need to have struct bpf_map_type_list since
it just contains a list_head, the type, and the ops
pointer. Since the types are densely packed and not
actually dynamically registered, it's much easier and
smaller to have an array of typ
Here's a simple iw patch that shows the error message string:
--- a/iw.c
+++ b/iw.c
@@ -62,6 +62,10 @@ static int nl80211_init(struct nl80211_state *state)
nl_socket_set_buffer_size(state->nl_sock, 8192, 8192);
+ /* try to set NETLINK_EXT_ACK to 1 (ignore errors) */
+ err
From: Johannes Berg <johannes.b...@intel.com>
Pass the new extended ACK reporting struct to all of the
generic netlink parsing functions. For now, pass NULL in
almost all callers (except for some in the core.)
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
---
crypto/c
From: Johannes Berg <johannes.b...@intel.com>
Add the base infrastructure and UAPI for netlink
extended ACK reporting. All "manual" calls to
netlink_ack() pass NULL for now and thus don't
get extended ACK reporting.
Big thanks goes to Pablo Neira Ayuso for not only
bringing up
From: Johannes Berg <johannes.b...@intel.com>
Pass the extended ACK reporting struct down from
generic netlink to the families, using the existing
struct genl_info for simplicity.
Also add support to set the extended ACK information
from generic netlink users.
Signed-off-by: Johanne
From: Johannes Berg <johannes.b...@intel.com>
This is an add-on to the previous patch that passes
the extended ACK structure where it's already available
by existing genl_info or extack function arguments.
This was done with this spatch (with some manual
adjustment of inden
From: Johannes Berg <johannes.b...@intel.com>
Now that we have extended error reporting and a new message format
for netlink ACK messages, also extend this to be able to return
arbitrary cookie data on success.
This will allow, for example, nl80211 to not send an extra message
for c
Changes since v1:
* credit Pablo and Jamal
* incorporate suggestion from David Ahern
* fix compilation in decnet
On Sat, 2017-04-08 at 20:40 +0200, Jiri Pirko wrote:
> > I think I'll leave it like this - if anyone really wants to say
> > "attribute 0 is missing" then we can add a flag later... The UAPI
> > does
> > take this into account by not including the attribute at all if the
> > data is invalid, so 0
On Sat, 2017-04-08 at 14:50 -0400, David Ahern wrote:
> On 4/8/17 1:48 PM, Johannes Berg wrote:
> > From: Johannes Berg <johannes.b...@intel.com>
> >
> > Pass the new extended ACK reporting struct to all of the
> > generic netlink parsing functions. For now, pa
From: Johannes Berg <johannes.b...@intel.com>
This is an add-on to the previous patch that passes
the extended ACK structure where it's already available
by existing genl_info or extack function arguments.
This was done with this spatch (with some manual
adjustment of inden
From: Johannes Berg <johannes.b...@intel.com>
Pass the extended ACK reporting struct down from
generic netlink to the families, using the existing
struct genl_info for simplicity.
Also add support to set the extended ACK information
from generic netlink users.
Signed-off-by: Johanne
On Sat, 2017-04-08 at 20:34 +0200, Jiri Pirko wrote:
> nla_total_size(sizeof(u32));
> > + if (extack &&
> > + (extack->missing_attr || extack-
> > >bad_attr))
>
> Attr could be 0, right? I know that on the most of the places 0 is
> UNSPEC, but I'm pretty
On Sat, 2017-04-08 at 14:36 -0400, David Ahern wrote:
>
> I think v3 is in your future ...
>
> /home/dsa/kernel-4.git/include/linux/netlink.h:78:12: error:
> ‘NETLINK_MAX_COOKIE_LEN’ undeclared here (not in a function)
> u8 cookie[NETLINK_MAX_COOKIE_LEN];
> ^
>
> it's defined in
From: Johannes Berg <johannes.b...@intel.com>
Now that we have extended error reporting and a new message format
for netlink ACK messages, also extend this to be able to return
arbitrary cookie data on success.
This will allow, for example, nl80211 to not send an extra message
for c
From: Johannes Berg <johannes.b...@intel.com>
Add the base infrastructure and UAPI for netlink
extended ACK reporting. All "manual" calls to
netlink_ack() pass NULL for now and thus don't
get extended ACK reporting.
Big thanks goes to Pablo Neira Ayuso for not only
bringing up
From: Johannes Berg <johannes.b...@intel.com>
Pass the new extended ACK reporting struct to all of the
generic netlink parsing functions. For now, pass NULL in
almost all callers (except for some in the core.)
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
---
crypto/c
Changes since v2:
* add NUM_NLMSGERR_ATTRS, NLMSGERR_ATTR_MAX
* fix cookie length to 20 (sha-1 length)
* move struct members for cookie to patch 3 where they should be
* another cleanup suggested by David Ahern
johannes
On Tue, 2017-04-11 at 08:59 +0200, Pablo Neira Ayuso wrote:
> CAP_ACK means: trim off the payload that the netlink error message
> is embedding, just like ICMP error does.
>
> What is exactly your concern? If the user explicitly requests this
> via socket option for this socket, then we're
From: Johannes Berg <johannes.b...@intel.com>
Pass the extended ACK reporting struct down from
generic netlink to the families, using the existing
struct genl_info for simplicity.
Also add support to set the extended ACK information
from generic netlink users.
Signed-off-by: Johanne
From: Johannes Berg <johannes.b...@intel.com>
Pass the new extended ACK reporting struct to all of the
generic netlink parsing functions. For now, pass NULL in
almost all callers (except for some in the core.)
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
---
crypto/c
From: Johannes Berg <johannes.b...@intel.com>
Now that we have extended error reporting and a new message format
for netlink ACK messages, also extend this to be able to return
arbitrary cookie data on success.
This will allow, for example, nl80211 to not send an extra message
for c
On Tue, 2017-04-11 at 09:19 +0200, Jiri Pirko wrote:
>
> > + NUM_NLMSGERR_ATTRS,
>
> According to the rest of the uapi, this should be rather named:
> __NLMSGERR_ATTR_MAX
nl80211 uses NUM_ so I guess that's a matter of convention, but I can
change that I guess.
> > if (err
From: Johannes Berg <johannes.b...@intel.com>
This is an add-on to the previous patch that passes
the extended ACK structure where it's already available
by existing genl_info or extack function arguments.
This was done with this spatch (with some manual
adjustment of inden
From: Johannes Berg <johannes.b...@intel.com>
Add the base infrastructure and UAPI for netlink
extended ACK reporting. All "manual" calls to
netlink_ack() pass NULL for now and thus don't
get extended ACK reporting.
Big thanks goes to Pablo Neira Ayuso for not only
bringing up
Changes since v3:
* Add NLM_F_CAPPED and NLM_F_ACK_TLVS flags, to allow entirely
stateless parsing of the ACK messages by looking at the new
flags. Need to check NLM_F_ACK_TLVS first, since capping can
be done in kernels before this patchset without setting the
flag.
* Remove
On Mon, 2017-04-10 at 14:36 -0700, Matthias Kaehlcke wrote:
> Ping, any feedback on this patch?
You didn't cc linux-wireless, so it fell through the cracks ... I'll
try to remember it when I merge later.
johannes
From: Johannes Berg <johannes.b...@intel.com>
It took me quite some time to figure out how this was linked,
so in order to save the next person the effort of finding it
add a comment in __bpf_prog_run() that indicates what exactly
determines that a program can access the ctx == skb.
Sign
On Sat, 2017-04-08 at 20:07 -0700, David Miller wrote:
> +static int generic_xdp_install(struct net_device *dev, struct
> netdev_xdp *xdp)
> +{
> + struct bpf_prog *new = xdp->prog;
> + int ret = 0;
> +
> + switch (xdp->command) {
> + case XDP_SETUP_PROG: {
> +
On Sun, 2017-04-09 at 08:25 +0200, Johannes Berg wrote:
> That would also let you use rcu_assign_pointer() which seems like the
> right thing to do here, along with marking the xdp_prog pointer as
> __rcu? That'd also let you use rcu_dereference() instead of
> READ_ONCE() whic
1101 - 1200 of 1516 matches
Mail list logo