Re: eBPF - little-endian load instructions?

> Yeah, you shouldn't need anything special. I did add that, yes. > In case the wifi progs have their own BPF program type, I wouldn't > even add it to may_access_skb() to not further encourage LD_ABS/IND > usage. F.e. lwt BPF programs are not hooked up there either. Interesting, ok. I still

eBPF - little-endian load instructions?

Hi, Looking at (e)BPF for wifi, I notice that everything is big endian in loads from the frame - and wifi is all little endian. Obviously, this can be worked around by doing byte-loads and swapping in the program, but it'll be more efficient to not do that. Do you think it's possible to add

Re: eBPF - little-endian load instructions?

> Are you working with an skb at that point in time in wifi? Yes. > There are > 3 different ways of accessing skb data, see [1] slide 7 - 10. The BPF > LD_ABS/IND instructions were carried over from cBPF and are the only > ones that convert to host endianess. It can be used in eBPF as well, >

Re: [PATCH net-next v4 1/5] netlink: extended ACK reporting

On Tue, 2017-04-11 at 10:13 +0200, Jiri Pirko wrote: > Tue, Apr 11, 2017 at 09:29:18AM CEST, johan...@sipsolutions.net > wrote: > > 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

Re: [PATCH net-next v3 2/2] bpf: remove struct bpf_map_type_list

0-day found a linking problem with this, I'll resubmit later. johannes

[PATCH net-next v4 2/2] bpf: remove struct bpf_map_type_list

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

[PATCH net-next v4 1/2] bpf: remove struct bpf_prog_type_list

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

Re: [PATCH v2] mac80211: Fix clang warning about constant operand in logical operation

On Thu, 2017-04-06 at 16:31 -0700, Matthias Kaehlcke wrote: > When clang detects a non-boolean constant in a logical operation it > generates a 'constant-logical-operand' warning. In > ieee80211_try_rate_control_ops_get() the result of strlen( str>) > is used in a logical operation, clang resolves

Re: [PATCH v3 net-next RFC] Generic XDP

On Wed, 2017-04-12 at 21:20 -0700, Alexei Starovoitov wrote: > > + if (skb_linearize(skb)) > > + goto do_drop; > > when we discussed supporting jumbo frames in XDP, the idea > was that the program would need to look at first 3+k bytes only > and the rest of the packet will be in

Re: [RFC 3/3] mac80211: support bpf monitor filter

> @@ -551,6 +551,9 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t > priv_data_len, >      NL80211_FEATURE_FULL_AP_CLIENT_STATE; >   wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_FILS_STA); >   > + if (IS_ENABLED(CONFIG_BPF_WIFIMON)) > +

Re: eBPF - little-endian load instructions?

On Wed, 2017-04-12 at 20:08 -0700, Alexei Starovoitov wrote: > it's really llvm bug that i need fix. It's plain broken > to generate what effectively is nop insn for march=bpfeb > My only excuse that when that code was written llvm had only > march=bpfel. > bpfeb was added much later. So I'm

Re: eBPF - little-endian load instructions?

On Fri, 2017-04-14 at 11:42 -0700, Alexei Starovoitov wrote: > bpf takes endianness of the cpu it runs on. Ok, so then things are actually not as difficult as I thought. > if we said that bpf 32-bit load insn is little endian, it would have > screwed up all big-endian archs and the other way

Re: [PATCH 1/5] netlink: extended ACK reporting

On Thu, 2017-04-13 at 16:05 +0200, Nicolas Dichtel wrote: > Sure. It was just to mention that attribute 0 exists somewhere. > The other 0 attribute is OVS_TUNNEL_KEY_ATTR_ID. That looks like some really awkward hand-grown parsing - with all these "struct ovs_len_tbl" looking almost like a

[PATCH net] mac80211: reject ToDS broadcast data frames

From: Johannes Berg <johannes.b...@intel.com> AP/AP_VLAN modes don't accept any real 802.11 multicast data frames, but since they do need to accept broadcast management frames the same is currently permitted for data frames. This opens a security problem because such frames would be dec

Re: [PATCH v3 net-next RFC] Generic XDP

On Thu, 2017-04-13 at 11:37 -0400, David Miller wrote: > If the capability is variable, it must be communicated to the user > somehow at program load time. > > We are consistently finding that there is this real need to > communicate XDP capabilities, or somehow verify that the needs > of an XDP

Re: [PATCH 1/5] netlink: extended ACK reporting

On Thu, 2017-04-13 at 15:27 +0200, Nicolas Dichtel wrote: > > > 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 > > why we need to

Re: [PATCH v3 net-next RFC] Generic XDP

On Thu, 2017-04-13 at 16:01 -0400, David Miller wrote: > From: Johannes Berg <johan...@sipsolutions.net> > Date: Thu, 13 Apr 2017 21:22:21 +0200 > > > OTOH, it might depend on the frame data itself, if the program does > > something like > >  > > xdp-&

Re: __sk_buff.data_end

On Thu, 2017-04-20 at 16:46 +0200, Daniel Borkmann wrote: > > Hmm. I don't see what "somewhere else" I could possibly have > > though, given that I want the (kernel-side) context to be "struct > > sk_buff *" to allow the skb helpers? > > I have not enough context on the wireless side, perhaps

Re: __sk_buff.data_end

On Thu, 2017-04-20 at 16:28 +0200, Daniel Borkmann wrote: > > I see what you mean now. Yes, that's fine. We already do something > similar essentially with skb->ifindex access already (skb->dev + > dev->ifindex), f.e.: > > [...] > case offsetof(struct __sk_buff, ifindex): >

Re: __sk_buff.data_end

On Thu, 2017-04-20 at 16:10 +0200, Daniel Borkmann wrote: > > I think this would be a rather more complex operation on the BPF > side, it would need changes from LLVM (which assumes initial ctx sits > in r1), verifier for tracking this ctx2, all the way down to JITs > plus some way to handle 1

Re: eBPF - little-endian load instructions?

On Wed, 2017-04-12 at 09:58 -0700, Alexei Starovoitov wrote: > > > Are these hooked up to llvm intrinsics or so? If not, can I do that > > through some kind of inline asm statement? > > llvm doesn't support bpf inline asm yet. Ok. > > In the samples, I only see people doing > > > > #define

__sk_buff.data_end

Hi Alexei, Daniel, I'm looking at adding the __wifi_sk_buff I talked about, and I notice that it uses CB space to store data_end. Unfortunately, in a lot of cases, we don't have any CB space to spare in wifi. Is there any way to generate a series of instructions that instead does the necessary

Re: __sk_buff.data_end

On Wed, 2017-04-19 at 23:31 +0200, Johannes Berg wrote: > Hi Alexei, Daniel, > > I'm looking at adding the __wifi_sk_buff I talked about, and I notice > that it uses CB space to store data_end. Unfortunately, in a lot of > cases, we don't have any CB space to spare in wifi. I g

Re: __sk_buff.data_end

On Thu, 2017-04-20 at 02:01 +0200, Daniel Borkmann wrote: > > Yeah, should work as well for the 32 bit archs, on 64 bit we > have this effectively already: Right. [...] > Can you elaborate on why this works for mac80211? It uses cb > only up to that point from where you invoke the prog? No,

Re: __sk_buff.data_end

On Thu, 2017-04-20 at 02:38 +0200, Daniel Borkmann wrote: > > Since wifi skbs have only eth in headlen, there is not much > > pointing adding support for data/data_end to wifi. > > Just use ld_abs/ld_ind instructions and load_bytes() helper. > > Afaik, the ld_abs/ld_ind are not an option due to

Re: __sk_buff.data_end

On Wed, 2017-04-19 at 17:12 -0700, Alexei Starovoitov wrote: > > also didn't we discuss that wifi has crazy non-linear skb? Not always, depends on the driver. But also, you have to remember that this filter would be before the conversion to Ethernet header. Right now, when packets enter the

Re: [PATCH] nl80211: fix enumeration type

On Wed, 2017-04-19 at 23:55 -0700, Stefan Agner wrote: > Use type enum nl80211_rate_info for bitrate information. This fixes > a warning when compiling with clang: >   warning: implicit conversion from enumeration type 'enum > nl80211_rate_info' >   to different enumeration type 'enum

Re: [PATCH 1/1] cfg80211: add return value validation

This is not a cfg80211 patch, please resend with the correct subject. Thanks, johannes

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

On Mon, 2017-03-06 at 13:25 +0100, Johannes Berg wrote: > On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote: > > From: Ondřej Lysoněk <ondrej.lyso...@seznam.cz> > > > > Use setup_timer() and setup_deferrable_timer() to set the data and > > function timer

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

> Not really. This is one of assignments for students I lead, so this > is done by hand every end of winter semester (Note the From line.) You really should teach them about coccinelle then :-) > > Care to send a patch for that one too? > > I am just a forwarder, he received this request too,

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby 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 internals. Btw,

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby 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 internals.

Re: Removing GENL_ID_GENERATE breaks userspace API

On Thu, 2017-03-02 at 17:50 +0100, Marcel Holtmann wrote: > Hi Johannes, > > you have removed GENL_ID_GENERATE in 4.10, but that is actually > breaking userspace API. > > commit a07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5 > Author: Johannes Berg <johannes.b...@intel.com>

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 12:55 -0700, David Miller wrote: > > One idea.  We use the macro thing to generate a "netlink.pot" file > and then some userland tree can contain the latest netlink.pot and > the translations. Right. For the record - since we just talked about it - I was thinking of putting

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:45 +0200, Pablo Neira Ayuso wrote: > > We only need to store the pointer to the attribute in the error > container structure. We can calculate the offset from nl_err() by > pasing the skbuff as parameter there, right? Ah, that's a good point, we could store the nlattr

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 12:43 -0700, David Miller wrote: > > I have no strong opinions about string length. > > In my opinion, I would like to believe that if someone tried to get a > networking patch applied that emitted a rediculously long string then > we would give them feedback about how that

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote: > On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote: > [...] > > Heh. I think I really want to solve - at least partially - > > nla_parse() > > to see that it can be done this way. It'd be nice t

[RFC 3/3] nl80211: add a few extended error strings

From: Johannes Berg <johannes.b...@intel.com> Signed-off-by: Johannes Berg <johannes.b...@intel.com> --- net/wireless/nl80211.c | 33 ++--- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/net/wireless/nl80211.c b/net/wireless/nl8

[RFC 1/3] netlink: extended error reporting

From: Johannes Berg <johannes.b...@intel.com> Signed-off-by: Johannes Berg <johannes.b...@intel.com> --- crypto/crypto_user.c | 3 +- drivers/infiniband/core/netlink.c | 3 +- drivers/scsi/scsi_netlink.c | 2 +- include/linux/netlink.h | 10 ++-

[RFC 0/3] netlink: extended error reporting

So this is my first draft of what we'd talked about at netconf. I'm not super happy with the way we have to pass the extended error struct, but I don't see a way to implement reporting any dynamic information (like error offsets) in any other way. Alexander Shishkin had a nice way of reporting

[RFC 2/3] genetlink: pass extended error report down

From: Johannes Berg <johannes.b...@intel.com> Signed-off-by: Johannes Berg <johannes.b...@intel.com> --- include/net/genetlink.h | 27 +++ net/netlink/genetlink.c | 6 -- 2 files changed, 31 insertions(+), 2 deletions(-) diff --git a/include/net/g

[PATCH v2 1/2] bpf: remove struct bpf_prog_type_list

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

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:02 +0200, Pablo Neira Ayuso wrote: > > > I'm tempted to apply this as-is just to show that person that > > things do in fact happen eventually :-) > > We can just send follow up patches to refine, I think it's a good > start, Johannes? I guess we can. Like I just

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 11:53 -0700, David Miller wrote: > > Alexander Shishkin had a nice way of reporting static extended > > error data, but that isn't really suitable for reporting the > > offset or even reporting the broken attribute from nla_parse(). > >  > > Speaking of nla_parse(), that'll

[PATCH v2 2/2] bpf: remove struct bpf_map_type_list

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

Re: [PATCH v2 1/2] bpf: remove struct bpf_prog_type_list

So two things about this, and they apply to the other patch as well: > +extern const struct bpf_verifier_ops sk_filter_prog_ops; > +extern const struct bpf_verifier_ops tc_cls_act_prog_ops; > +extern const struct bpf_verifier_ops xdp_prog_ops; > +extern const struct bpf_verifier_ops

Re: [RFC 2/3] genetlink: pass extended error report down

On Fri, 2017-04-07 at 11:37 -0700, Ben Greear wrote: > > I guess the error string must be constant and always available in > memory in this implementation? Yes. > I think it would be nice to dynamically create strings (malloc, > snprintf, etc) and have the err_str logic free it when done? We

Re: [RFC] netlink: send exterr cookie on success

On Sat, 2017-04-08 at 11:28 -0400, Jiri Benc wrote: > Perhaps the structure should be named just "netlink_ext" or so? It > seems it'll pick up some non-error related usage, such as the cookies > here or, in the future, flags indicating how the message should be > parsed. Fair point, I'll call it

[PATCH 3/5] netlink: allow sending extended ACK with cookie on success

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

[PATCH 1/5] netlink: extended ACK reporting

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. Signed-off-by: Johannes Berg <johannes.b...@intel.com> ---

[PATCH 4/5] netlink: pass extended ACK struct to parsing functions

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

[PATCH 0/5] extended netlink ACK reporting

Hi, After testing and fixing the ack message length calculation, this now works. The UAPI changes are like before - the ACK message format becomes [nlmsg header] [ack header] [request nlmsg header] [request nlmsg body (already optional) - length aligned] [extended ACK TLVs - this is NEW]

[PATCH 5/5] netlink: pass extended ACK struct where available

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

[PATCH 2/5] genetlink: pass extended ACK report down

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

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 12:20 -0700, David Miller wrote: > But what it lacks fundamentally is context.  Therefore it can't be > used to provide the offset or the bad attribute number.  So it can't > meet our requirements. Yes, it doesn't address the requirements here, and in a sense I suspect this

Re: [RFC 1/3] netlink: extended error reporting

On Fri, 2017-04-07 at 20:26 +0200, Johannes Berg wrote: > > + if (nlk->flags & NETLINK_F_EXT_ACK) { > + if (exterr && exterr->msg) > + WARN_ON(nla_put_string(skb, > NLMSGERR_ATTR_MSG, > +

[RFC] netlink: send exterr cookie on success

From: Johannes Berg <johannes.b...@intel.com> This is for Jamal, it allows the subsystem to return an arbitrary cookie to identify a new object/operation, perhaps to delete or cancel it later. This is actually something we use a lot in wifi too, though I'm not sure how we could do the ba

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:21 +0200, Pablo Neira Ayuso wrote: > > For my usecases in netfilter, the attributes and an specific error > code should be enough to figure out what is wrong. Will not need > strings. Fair enough. > BTW, we may not have an offset, eg. EINVAL because of missing >

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:27 +0200, Pablo Neira Ayuso wrote: > > > Also another way to look at this is that we're providing a lot of > > new power and expressability.  So even if only one aspect of the > > new error reporting is used it's a positive step forward. True. > > So allow offset "0"

pull-request: mac80211 2017-04-18

supporting this - iwlwifi. ---- Johannes Berg (1): mac80211: fix MU-MIMO follow-MAC mode net/mac80211/rx.c | 65 --- 1 file changed, 47 insertions(+), 18 deletions(-)

Re: [PATCH] nl80211: Fix enum type of variable in nl80211_put_sta_rate()

On Mon, 2017-04-17 at 15:59 -0700, Matthias Kaehlcke wrote: > rate_flg is of type 'enum nl80211_attrs', however it is assigned with > 'enum nl80211_rate_info' values. Change the type of rate_flg > accordingly. Applied this, and the other two patches you had (IBSS enum and array- bounds) johannes

Re: [RFC 1/3] bpf/wireless: add wifimon program type

On Fri, 2017-04-14 at 11:51 -0700, Alexei Starovoitov wrote: > > so today only 'len' field is needed, Correct, the other __sk_buff fields don't apply. It's more of an XDP model (with data/data_end), but as the SKB might be non-linear at this point I prefer to have the SKB so that skb data

Re: [RFC 1/3] bpf/wireless: add wifimon program type

So actually, come to think of it ... > > The mapping in samples/bpf/bpf_helpers.h, for example, for > > mentioned > > bpf_skb_load_bytes() would also work out of the box, since it takes > > a > > void *ctx as an argument, so you can just pass the __wifi_sk_buff > > pointer as ctx there from

pull-request: mac80211-next 2017-04-18

-hwsim: remove dmesg spam about get-survey. Johannes Berg (24): cfg80211: combine two nested ifs into a single condition ieee80211: rename CCFS1/CCFS2 to CCFS0/CCFS1 mac80211: remove local pointer from rate_ctrl_ref cfg80211: refactor cfg80211_calculate_bitrate

Re: [PATCH 1/5] netlink: extended ACK reporting

On Thu, 2017-04-13 at 14:44 -0700, Joe Stringer wrote (something that never made it to the list, due to HTML formatting) > > I think that OVS was doing some more elaborate validation than most > users, so over time we picked up a bunch of extra parsing code that > layers on top of nla_parse(). I

Re: [RFC 1/3] bpf/wireless: add wifimon program type

On Tue, 2017-04-18 at 12:58 +0200, Daniel Borkmann wrote: > > Note that for skbs the data / data_end model (aka direct read / > write) is also supported. There's also a bpf_skb_pull_data() helper > that pulls in data from non-linear parts if necessary (f.e. if data / > data_end test in the

Re: [PATCH v3 net-next RFC] Generic XDP

On Fri, 2017-04-14 at 12:41 -0700, Alexei Starovoitov wrote: > > ahh. i thought all drivers do at least copy-break (256) bytes We do copy-break, but that's only applicable when there's no non-linear data left afterwards :) > or copy > get_headlen or build_skb the whole thing. > Since wireless

pull-request: mac80211 2017-07-07

Hi Dave, Just got a set of fixes in from Jouni/QCA, all netlink validation fixes. I assume they ran some kind of checker, but I don't know what kind :) Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit

Re: [RFC 1/4] netlink: make extended ACK setting NULL-friendly

On Tue, 2017-04-25 at 13:53 -0700, Jakub Kicinski wrote: > On Tue, 25 Apr 2017 10:13:34 +0200, Johannes Berg wrote: > > On Tue, 2017-04-25 at 01:06 -0700, Jakub Kicinski wrote: > > > > > +#define NL_SET_ERR_MSG(extack, msg) do { \ > > > + struct n

Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()

> @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn, > struct wcn36xx_dxe_ch *ch) >   info = IEEE80211_SKB_CB(ctl->skb); >   if (!(info->flags & > IEEE80211_TX_CTL_REQ_TX_STATUS)) { >   /* Keep frame until TX

pull-request: mac80211-next 2017-04-28

in ieee80211_frame_acked Felix Fietkau (3): mac80211: make rate control tx status API more extensible mac80211: move ieee80211_tx_status_noskb below ieee80211_tx_status mac80211: add ieee80211_tx_status_ext Johannes Berg (8): mac80211: rewrite monitor mode delivery logic

Re: [RFC 1/4] netlink: make extended ACK setting NULL-friendly

On Tue, 2017-04-25 at 01:06 -0700, Jakub Kicinski wrote: > +#define NL_SET_ERR_MSG(extack, msg) do { \ > + struct netlink_ext_ack *_extack = (extack); \ > + static const char _msg[] = (msg); \ > + \ > +

Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.

On Sun, 2017-05-14 at 16:14 -0600, David Ahern wrote: > On 5/14/17 3:00 PM, Johannes Berg wrote: > > On Sat, 2017-05-13 at 19:29 +0200, Jan Moskyto Matejka wrote: > > > > > > > When adding a route to the skb, track whether it contains at > > > > least

Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.

On Sat, 2017-05-13 at 19:29 +0200, Jan Moskyto Matejka wrote: > > > When adding a route to the skb, track whether it contains at least > > 1 > > route. If not, it means the next route in the dump is larger than > > the > > given buffer. Detect this condition and error out of the dump - > >

Re: [PATCH] wil6210: Replace five seq_puts() calls by seq_putc()

On Tue, 2017-05-09 at 09:50 +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 8 May 2017 22:22:04 +0200 > > Five single characters (line breaks) should be put into a sequence. > Thus use the corresponding function "seq_putc". Please stop, this

Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()

On Wed, 2017-05-17 at 22:05 -0700, Bjorn Andersson wrote: > > It seems very important to a lot of people... I get blinking, I guess, but I don't get toggling for every packet :) The throughput thing we did in iwlwifi seems like a so much better idea. Not that it really matters for this

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote: > > > Now for N900 case there is a similar scenario > > > alhtough it has additional requirement to go to user-space due to > > > need to use a proprietary library to obtain the NVS calibration > > > data. My thought: Why should

Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()

On Thu, 2017-05-04 at 13:13 +, Kalle Valo wrote: > > > > This code intentionally checked if TX status was requested, and > > > if not then it doesn't go to the effort of building it. > > > > > > > What I'm finding puzzling is the fact that the only caller of > > ieee80211_led_tx() is

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On Wed, 2017-05-17 at 15:21 +0200, Pali Rohár wrote: > On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote: > > On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote: > > > > > > In fact, why should the *driver* care either? IOW - why should > > > > &quo

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote: > > In fact, why should the *driver* care either? IOW - why should > > "request_firmware_prefer_user()" even exist? > > There are default/example NVS data, which are stored in /lib/firmware > and installed by linux-firmware package. [...] Oh,

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote: > * Ben Greear [17.05.2017 11:51]: > > I have been keeping an 'iw events' program running with a perl > > script gathering its > > output and post-processing it.  This has been working for several > > years on 4.7

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote: > > In rt2x00 driver we use poor convention in other kind of registers > accessors like bbp, mac, eeprom. I dislike to changing only rfcsr > accessors and leaving others in the old way. And changing all > accessors would be massive and

Re: [PATCH v7 0/5] skb_to_sgvec hardening

On Tue, 2017-05-09 at 15:50 +0200, Jason A. Donenfeld wrote: > The recent bug with macsec and historical one with virtio have > indicated that letting skb_to_sgvec trounce all over an sglist > without checking the length is probably a bad idea. And it's not > necessary either: an sglist already

Re: [RFC] separate SIOCGIFCONF from the rest of dev_ioctl()

On Mon, 2017-06-26 at 18:40 +0100, Al Viro wrote: > Only two of dev_ioctl() callers may pass SIOCGIFCONF to it. > Separating that codepath from the rest of dev_ioctl() allows both > to simplify dev_ioctl() itself (all other cases work with struct > ifreq *) > *and* seriously simplify the

Re: [PATCH net-next v3 1/6] vxlan: refactor verification and application of configuration

On Fri, 2017-06-23 at 12:13 +0200, Matthias Schiffer wrote: > > I was told the extended netlink error facilities were not ready yet, > has that changed since the last release? Yes, the facility is in the kernel tree now. > Anyways, I will gladly work on improving the error handling if > someone

Re: [UBSAN] iwlmvm's iwl_mvm_enable_txq accesses IEEE80211_INVAL_HW_QUEUE

On Fri, 2017-06-23 at 09:48 +0200, Jiri Slaby wrote: > > mac80211_queue is 255 which is IEEE80211_INVAL_HW_QUEUE, so it should > not be worked with at all. Funny you should find this today :-) > The invalid queue is hopefully handled in ieee80211_check_queues > after > drv_add_interface in

Re: [PATCH net-next v3 1/6] vxlan: refactor verification and application of configuration

On Fri, 2017-06-23 at 14:02 +0200, Matthias Schiffer wrote: > > It seems though that rtnl_link_ops.newlink/changelink don't allow > passing the extack yet... how do we proceed here? Treewide change > (maybe by someone who knows their Coccinelle-fu?), or would the > introduction of new versions of

Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi

Hi Arend, Sorry, I forgot that the original message wasn't Cc'ed to the wireless list, only netdev. > +++ b/net/wireless/scan.c > @@ -322,9 +322,7 @@ static void cfg80211_del_sched_scan_req(struct > cfg80211_regi >  { > struct cfg80211_sched_scan_request *pos; > > -   ASSERT_RTNL();

Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi

On Tue, 2017-05-23 at 09:19 +0200, Arend Van Spriel wrote: > > > WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_rtnl_is_held()); > > Thought about something like this after sending the email. So there > are two call sites. One for scheduled scan results notification and > one in scheduled

pull-request: mac80211 2017-05-23

Hi Dave, I have just two fixes here, one of the scheduled scan issue that Sander Eikelenboom found, and the other properly makes mesh more strictly check its extension headers. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit

Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi

On Mon, 2017-05-22 at 12:36 +0200, Sander Eikelenboom wrote: > Hi, > > I encountered this splat with 4.12-RC2. Ugh, yeah, I should've seen that in the review. Arend, please take a look at this. cfg80211_sched_scan_results() cannot sleep, so you can't rtnl_lock() in there. Looks like you can

Re: [RFC] skbuff: introduce skb_put_zero()

On Thu, 2017-05-25 at 13:01 -0400, David Miller wrote: > From: Johannes Berg <johan...@sipsolutions.net> > Date: Wed, 24 May 2017 09:07:47 +0200 > > > From: Johannes Berg <johannes.b...@intel.com> > >  > > This pattern was introduced a number of times i

Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.

On Mon, 2017-05-22 at 18:09 +0200, Enric Balletbo i Serra wrote: > The IEEE80211_SCAN_RESULT_EXPIRE value was modified several times in > the > past. Initially was set at 10 seconds (2a51931192), then increased at > 15 > seconds (09f97e0fc4) and finally to 30 seconds (f9616e0f88) to cover > the >

Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.

> Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and > create its own list?  Given that the kernel provides the information > userspace needs to figure out the age of a particular BSS, it doesn't > seem like there needs to be a kernel tunable for this.  Userspace can > already

Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.

On Mon, 2017-05-22 at 18:19 +0200, Johannes Berg wrote: > > I'm not really all that convinced that we really need this - > userspace should just be using the flush thing more often, and then > it doesn't really matter. > > However, maybe that doesn't really matter all that

[RFC] skbuff: introduce skb_put_zero()

From: Johannes Berg <johannes.b...@intel.com> This pattern was introduced a number of times in mac80211 just now, and since it's present in a number of other places it makes sense to add a little helper for it. The transformations of all code were done with the following spatch: @@ identi

Re: [net-wireless-orinoco] question about potential null pointer dereference

Hi, > The issue here is that line 56 implies that pointer tfm_michael > might be NULL. If this is the case, there is a potential NULL > pointer dereference at line 52 once pointer tfm_michael is > indirectly dereferenced inside macro SHASH_DESC_ON_STACK(). > > My question is if there is any

Re: [PATCH v2] mac80211: Invoke TX LED in more code paths

On Sat, 2017-05-27 at 14:59 -0700, Bjorn Andersson wrote: > ieee80211_tx_status() is only one of the possible ways a driver can > report a handled packet, some drivers call this for every packet > while > others calls it rarely or never. > > In order to invoke the TX LED in the non-status

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

On Wed, 2017-05-17 at 08:22 -0700, Ben Greear wrote: > > I saw it exactly once so far, and it happened overnight, > but we have not been doing a lot of work with the 4.9 kernel until > recently. > > I don't think there were many messages on this system, and certainly > others have run much

pull-request: mac80211 2017-06-02

callback races by setting bits instead of allocating and queueing an skb Johannes Berg (2): mac80211: fix TX aggregation start/stop callback race mac80211: fix dropped counter in multiqueue RX net/mac80211/agg-tx.c

<    8   9   10   11   12   13   14   15   16   >