> 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
> 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,
>
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
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 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
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
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>
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>
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>
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>
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
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 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);
> >
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 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
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
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
> @@ -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
> 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
> > 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,
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
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: {
> +
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
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 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
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: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
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
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
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
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>
---
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
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]
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 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
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
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
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
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
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,
> +
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"
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
>
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
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
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
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
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
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
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
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
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 ++-
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
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
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
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
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 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
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>
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 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");
> >
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
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(-)
, 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
> 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
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
> > > - 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
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
inue;
D'oh. I don't know how that ended up in there, tbh.
Acked-by: Johannes Berg <johan...@sipsolutions.net>
johannes
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
> 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
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
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
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
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
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 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,
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.
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
> 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,
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>
.
Johannes Berg (1):
average: change to declare precision, not factor
drivers/net/virtio_net.c| 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 2 +-
include/linux/average.h | 61
Johannes Berg (3):
mac80211: fix packet statistics for fast-RX
mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length
mac80211: use driver-indicated transmitter STA only for data frames
Matt Chen (1):
mac80211: flush delayed work when entering suspend
Sara Sharon (3
> > Chosen colors are questionable. Best solution would be also allow
> user to
> > redefine colors, like ls does with LS_COLORS or grep with
> GREP_COLORS. But that
> > is maybe overkill.
>
> I think you may have posted this to the wrong mailing list.
Actually, it seems to just be missing the
From: Johannes Berg <johannes.b...@intel.com>
Declaring the factor is counter-intuitive, and people are prone
to using small(-ish) values even when that makes no sense.
Change the DECLARE_EWMA() macro to take the fractional precision,
in bits, rather than a factor, and update all users.
301 - 400 of 1516 matches
Mail list logo