hould
>make it cleaner to extend the output format for dumping
>policies for all the commands at once in the future.
Great, thanks :)
Reviewed-by: Johannes Berg
johannes
From: Johannes Berg
If userspace doesn't complete the policy dump, we leak the
allocated state. Fix this.
Fixes: d07dcf9aadd6 ("netlink: add infrastructure to expose policies to
userspace")
Signed-off-by: Johannes Berg
---
Found this while looking at Jakub's series and
From: Johannes Berg
Since moving the call to this to a dump start() handler we no
longer need this to deal with being called after having been
called already. Since that is the preferred way of doing things
anyway, remove the code necessary for that and simply return
the pointer (or an ERR_PTR
From: Johannes Berg
We'll need this later for the per-op policy index dump.
Signed-off-by: Johannes Berg
---
net/netlink/genetlink.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
From: Johannes Berg
The maxtype is really an integral part of the policy, and while we
haven't gotten into a situation yet where this happens, it seems
that some developer might eventually have two places pointing to
identical policies, with different maxattr to exclude some attrs
in one o
From: Johannes Berg
Rework the policy dump code a bit to support adding multiple
policies to a single dump, in order to e.g. support per-op
policies in generic netlink.
Signed-off-by: Johannes Berg
---
include/net/netlink.h | 62 +++--
net/netlink
Hi,
So ... Jakub added per-op policy retrieval, so you could retrieve the
policy for a single op.
This then adds - as discussed - support for dumping *everything*, which
has basically first an [op] -> [policy-idx] mapping, followed by all the
policies. When a single op is requested, you get a con
From: Johannes Berg
Add support for per-op policy dumping. The data is pretty much
as before, except that now the assumption that the policy with
index 0 is "the" policy no longer holds - you now need to look
at the new CTRL_ATTR_OP_POLICY attribute which is a nested attr
containi
cfg80211: regulatory: remove a bogus initialization
Felix Fietkau (1):
mac80211: fix regression in sta connection monitor
Johannes Berg (6):
mac80211_hwsim: fix typo in kernel-doc
mac80211: fix some missing kernel-doc
wireless: radiotap: fix some kernel-doc
mac80211: fix
Newer kernels can dump per-op policies, so print out the new
mapping attribute to indicate which op has which policy.
Signed-off-by: Johannes Berg
---
genl/ctrl.c| 10 ++
include/uapi/linux/genetlink.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/genl
On Fri, 2020-10-02 at 07:29 -0700, David Ahern wrote:
> On 10/2/20 3:26 AM, Johannes Berg wrote:
> > diff --git a/genl/ctrl.c b/genl/ctrl.c
> > index 68099fe97f1a..c62212b40fa3 100644
> > --- a/genl/ctrl.c
> > +++ b/genl/ctrl.c
> > @@ -162,6 +162,16 @@ static int
On Fri, 2020-10-02 at 07:40 -0700, Jakub Kicinski wrote:
> > I suppose you could make an argument that only some attrs might be
> > accepted in doit and somewhat others in dumpit, or perhaps none in
> > dumpit because filtering wasn't implemented?
>
> Right? Feels like it goes against our strict
> > Or just give them both? I mean, in many (most?) cases they're anyway
> > going to be the same, so with the patches I posted you could just give
> > them the two different policy indexes, and they can be the same?
>
> Ah, I missed your posting!
Huh, I even CC'ed you I think?
https://lore.ke
On Fri, 2020-10-02 at 08:03 -0700, Jakub Kicinski wrote:
> > Huh, I even CC'ed you I think?
>
> I filter stuff which is to:netdev cc:me and get to it when I read the
> ML. There's too much of it.
Ah, ok :)
> > Yeah, that'd work. I'd probably wonder if we shouldn't do
> >
> > [OP_POLICY]
> >
On Fri, 2020-10-02 at 08:09 -0700, Jakub Kicinski wrote:
> On Fri, 02 Oct 2020 17:04:11 +0200 Johannes Berg wrote:
> > > > Yeah, that'd work. I'd probably wonder if we shouldn't do
> > > >
> > > > [OP_POLICY]
> > > > [OP] ->
On Fri, 2020-10-02 at 08:25 -0700, Jakub Kicinski wrote:
>
> > I suppose, I thought you wanted to change it to have separate dump/do
> > policies? Whatever you like there, I don't really care much :)
>
> I just want to make the uAPI future-proof for now.
Yeah, makes sense.
> At a quick look eth
On Fri, 2020-10-02 at 08:29 -0700, Jakub Kicinski wrote:
> On Fri, 2 Oct 2020 09:46:04 +0200 Johannes Berg wrote:
> > From: Johannes Berg
> >
> > If userspace doesn't complete the policy dump, we leak the
> > allocated state. Fix this.
> >
> > Fixes
On Fri, 2020-10-02 at 11:01 -0700, David Ahern wrote:
>
> does not have to be in the kernel. Usability is important.
Yeah I completely agree with you. I'm just not sure we _can_ here, since
we don't have the domain-specific details.
In a way, I'm really just more or less considering the 'genl' s
On Fri, 2020-10-02 at 08:31 -0700, Jakub Kicinski wrote:
> On Fri, 2 Oct 2020 11:09:40 +0200 Johannes Berg wrote:
> > From: Johannes Berg
> >
> > Since moving the call to this to a dump start() handler we no
> > longer need this to deal with being called after hav
On Fri, 2020-10-02 at 08:39 -0700, Jakub Kicinski wrote:
>
> > - ctx->state = netlink_policy_dump_start(op.policy, op.maxattr);
> > - if (IS_ERR(ctx->state))
> > - return PTR_ERR(ctx->state);
> > - return 0;
> > + return netlink_policy_dump_add_policy(&ctx->state, op.policy,
> >
Oh, and ...
> > +/**
> > + * netlink_policy_dump_add_policy - add a policy to the dump
> > + * @pstate: state to add to, may be reallocated, must be %NULL the first
> > time
> > + * @policy: the new policy to add to the dump
> > + * @maxtype: the new policy's max attr type
> > + *
> > + * Returns
On Fri, 2020-10-02 at 08:09 -0700, Jakub Kicinski wrote:
> On Fri, 02 Oct 2020 17:04:11 +0200 Johannes Berg wrote:
> > > > Yeah, that'd work. I'd probably wonder if we shouldn't do
> > > >
> > > > [OP_POLICY]
> > > > [OP] ->
On Fri, 2020-10-02 at 13:37 -0700, Jakub Kicinski wrote:
>
> I guess it's because of the volume of messages this would cause.
There's actually been a large cleanup, so it wouldn't be too bad.
I had really just suspected tooling/build system issues, you know which
C files you're compiling, but no
On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
>
> My thinking was that until kernel actually start using separate dump
> policies user space can assume policy 0 is relevant. But yeah, merging
> your changes first would probably be best.
Works for me. I have it based on yours. Just upda
On Fri, 2020-10-02 at 22:59 +0200, Johannes Berg wrote:
> On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
> > My thinking was that until kernel actually start using separate dump
> > policies user space can assume policy 0 is relevant. But yeah, merging
> > you
From: Johannes Berg
Add support for per-op policy dumping. The data is pretty much
as before, except that now the assumption that the policy with
index 0 is "the" policy no longer holds - you now need to look
at the new CTRL_ATTR_OP_POLICY attribute which is a nested attr
(ind
ke it cleaner to extend the output format for dumping
policies for all the commands at once in the future.
Signed-off-by: Jakub Kicinski
Link: https://lore.kernel.org/r/20201001225933.1373426-11-k...@kernel.org
Signed-off-by: Johannes Berg
---
include/uapi/linux/genetlink.h | 1 +
net/ne
From: Johannes Berg
We'll need this later for the per-op policy index dump.
Reviewed-by: Jakub Kicinski
Signed-off-by: Johannes Berg
---
net/netlink/genetlink.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/net/netlink/genetlink.c
Newer kernels can dump per-op policies, so print out the new
mapping attribute to indicate which op has which policy.
v2:
* print out both do/dump policy idx
v3:
* fix userspace API which renumbered after patch rebasing
Signed-off-by: Johannes Berg
---
genl/ctrl.c| 27
From: Johannes Berg
Rework the policy dump code a bit to support adding multiple
policies to a single dump, in order to e.g. support per-op
policies in generic netlink.
v2:
- move kernel-doc to implementation [Jakub]
- squash the first patch to not flip-flop on the prototype
[Jakub
From: Johannes Berg
The maxtype is really an integral part of the policy, and while we
haven't gotten into a situation yet where this happens, it seems
that some developer might eventually have two places pointing to
identical policies, with different maxattr to exclude some attrs
in one o
Hi,
Here's a respin, now including Jakub's patch last so that it will
do the right thing from the start.
The first patch remains the same, of course; the others have mostly
some rebasing going on, except for the actual export patch (patch 4)
which is adjusted per Jakub's review comments about exp
On Mon, 2020-10-05 at 08:57 -0700, Jakub Kicinski wrote:
>
> @@ -783,6 +799,9 @@ static const struct genl_ops ethtool_genl_ops[] = {
> .start = ethnl_default_start,
> .dumpit = ethnl_default_dumpit,
> .done = ethnl_default_done,
> + .policy
On Mon, 2020-10-05 at 08:57 -0700, Jakub Kicinski wrote:
>
> @@ -47,19 +61,16 @@ int ethnl_parse_header_dev_get(struct ethnl_req_info
> *req_info,
> NL_SET_ERR_MSG(extack, "request header missing");
> return -EINVAL;
> }
> + /* Use most permissive header poli
bits there in ethtool, using the cookie.
Just pointing out you lost it now. I'm not sure I like using the cookie,
that seems a bit strange, but we could easily define a different attr?
OTOH, one can always query the policy export too (which hopefully got
wired up) so it wouldn't really matter much.
Either way is fine with me on both of these points.
Reviewed-by: Johannes Berg
Thanks!
johannes
On Mon, 2020-10-05 at 12:16 -0700, Jakub Kicinski wrote:
> On Mon, 05 Oct 2020 20:56:29 +0200 Johannes Berg wrote:
> > On Mon, 2020-10-05 at 08:57 -0700, Jakub Kicinski wrote:
> > > @@ -783,6 +799,9 @@ static const struct genl_ops ethtool_genl_ops[] = {
>
On Mon, 2020-10-05 at 12:22 -0700, Jakub Kicinski wrote:
> > > + if (value & ~(u64)pt->mask) {
> > > + NL_SET_ERR_MSG_ATTR(extack, nla, "reserved bit set");
> > > + return -EINVAL;
> >
> > You had an export of the valid bits there in ethtool, using the cookie.
> > Just pointing
On Mon, 2020-10-05 at 12:25 -0700, Jakub Kicinski wrote:
> On Mon, 05 Oct 2020 20:58:57 +0200 Johannes Berg wrote:
> > On Mon, 2020-10-05 at 08:57 -0700, Jakub Kicinski wrote:
> > > @@ -47,19 +61,16 @@ int ethnl_parse_header_dev_get(struct ethnl_req_inf
On Mon, 2020-10-05 at 21:28 +0200, Michal Kubecek wrote:
> > > + if (value & ~(u64)pt->mask) {
> > > + NL_SET_ERR_MSG_ATTR(extack, nla, "reserved bit set");
> > > + return -EINVAL;
> >
> > You had an export of the valid bits there in ethtool, using the cookie.
> > Just pointing ou
On Mon, 2020-10-05 at 12:31 -0700, Jakub Kicinski wrote:
> Yea, I think we're both confused. Agreed with the above.
>
> Are you suggesting:
>
> const struct nla_policy policy[/* no size */] = {
> [HEADER]= NLA_POLICY(...)
> [OTHER_ATTR]= NLA_POLICY(...)
> };
>
> extern c
On Mon, 2020-10-05 at 12:34 -0700, Jakub Kicinski wrote:
> > > My thinking is that there are no known uses of the cookie, it'd only
Ahh. I completely misinterpreted the word "uses" here - you meant, I
think (now), "uses of the cookie in the way that it was done in ethtool
before". I read over thi
On Mon, 2020-10-05 at 12:41 -0700, Jakub Kicinski wrote:
> > Now you can freely add any attributes, and, due to strict validation,
> > anything not specified in the policy will be rejected, whether by being
> > out of range (> maxattr) or not specified (NLA_UNSPEC).
>
> 100%, but in ethtool polic
On Mon, 2020-10-05 at 12:40 -0700, Jakub Kicinski wrote:
> > I would totally support doing that here in the general validation code,
> > but (again) don't really think NLMSGERR_ATTR_COOKIE is an appropriate
> > attribute for it.
>
> Hm. Perhaps we can do a partial policy dump into the extack?
Hm
On Mon, 2020-10-05 at 21:53 +0200, Johannes Berg wrote:
> On Mon, 2020-10-05 at 12:40 -0700, Jakub Kicinski wrote:
>
> > > I would totally support doing that here in the general validation code,
> > > but (again) don't really think NLMSGERR_ATTR_COOKIE is an appro
On Tue, 2018-11-20 at 19:14 -0800, Cody Schuffelen wrote:
>
> +config VIRT_WIFI
> + bool "Wifi wrapper for ethernet drivers"
The built bot complaint is most likely because of this being bool rather
than tristate (CFG80211=m, VIRT_WIFI=y, I guess, didn't check), I
thought this was because of t
On Tue, 2018-10-23 at 12:58 +0200, Gustavo A. R. Silva wrote:
> On 10/23/18 10:59 AM, Gustavo A. R. Silva wrote:
> >
> > On 10/23/18 9:01 AM, Johannes Berg wrote:
> > > On Tue, 2018-10-23 at 02:13 +0200, Gustavo A. R. Silva wrote:
> > > > In preparation to e
On Thu, 2019-01-24 at 19:05 +0100, Mathieu Malaterre wrote:
> During refactor in commit 9e478066eae4 ("mac80211: fix MU-MIMO
> follow-MAC mode") a new struct 'action' was declared with packed
> attribute as:
>
> struct {
> struct ieee80211_hdr_3addr hdr;
> u8 category;
>
On Thu, 2019-01-24 at 19:14 +0100, Mathieu Malaterre wrote:
> > I'm not sure this will work on all platforms, didn't something like
> > alpha pad out u8's to u32 when not requiring packing?
>
> I was not aware of that.
TBH, I'm not actually sure about that. Pure hearsay. If anyone knows,
I'd lik
From: Johannes Berg
In typical cases, there's no need to pass both the maxattr
and the policy array pointer, as the maxattr should just be
ARRAY_SIZE(policy) - 1. Therefore, to be less error prone,
just remove the maxattr argument from the default macros
and deduce the size accordingly.
cfg80211: reg: remove warn_on for a normal case
cfg80211: extend range deviation for DMG
Johannes Berg (2):
mac80211_hwsim: check that n_limits makes sense
nl80211: fix NLA_POLICY_NESTED() arguments
Mathieu Malaterre (1):
mac80211: Add attribute aligned(2) to
On Fri, 2019-01-25 at 11:04 -0800, David Miller wrote:
>
> > Dave, it looks like we're the only users of this right now,
> > so let me know if you'd prefer I take it through my tree.
> > Also, this conflicts with the fix I just made to the place
> > where I got it wrong, but obviously the resoluti
Back a long time ago, I already fixed a few of these by passing
the size of the struct ifreq to do_sock_ioctl(). However, Robert
found more cases, and now it won't be as simple because we'd have
to pass that down all the way to e.g. bond_do_ioctl() which isn't
really feasible.
Therefore, restore t
From: Johannes Berg
As reported by Robert O'Callahan in
https://bugzilla.kernel.org/show_bug.cgi?id=202273
reverting the previous changes in this area broke
the SIOCGIFNAME ioctl in compat again (I'd previously
fixed it after his previous report of breakage in
https://bugzilla.
From: Johannes Berg
This reverts commit bf4405737f9f ("kill dev_ifsioc()").
This wasn't really unused as implied by the original commit,
it still handles the copy to/from user differently, and the
commit thus caused issues such as
https://bugzilla.kernel.org/show_bug.cgi?id=199
From: Johannes Berg
This reverts commit 1cebf8f143c2 ("socket: fix struct ifreq
size in compat ioctl"), it's a bugfix for another commit that
I'll revert next.
This is not a 'perfect' revert, I'm keeping some coding style
intact rather than revert to the stat
From: Johannes Berg
Same story as before, these use struct ifreq and thus need
to be read with the shorter version to not cause faults.
Cc: sta...@vger.kernel.org
Fixes: f92d4fc95341 ("kill bond_ioctl()")
Signed-off-by: Johannes Berg
---
net/socket.c | 8
1 file changed, 4
On Sat, 2019-01-26 at 17:29 +, Al Viro wrote:
>
> I disagree with solution. Look at what's happening here:
>
> > + uifr = compat_alloc_user_space(sizeof(*uifr));
> > + if (copy_in_user(uifr, uifr32, sizeof(*uifr32)))
> > + return -EFAULT;
>
> an enlarged copy is made.
Yes, th
On Sat, 2019-01-26 at 18:45 +0100, Johannes Berg wrote:
>
> Yes and no. It *sometimes* (actually rarely, since we don't really have
> dev_ioctls that much, afaict) hits this, but it could also just hit
Actually, no, I'm wrong. We do mostly hit dev_ioctl(), since that's th
On Sat, 2019-01-26 at 18:49 +0100, Johannes Berg wrote:
> On Sat, 2019-01-26 at 18:45 +0100, Johannes Berg wrote:
> >
> > Yes and no. It *sometimes* (actually rarely, since we don't really have
> > dev_ioctls that much, afaict) hits this, but it could also just hit
&g
From: Johannes Berg
Digging through the ioctls with Al because of the previous
patches, we found that on 64-bit decnet's dn_dev_ioctl()
is wrong, because struct ifreq::ifr_ifru is actually 24
bytes (not 16 as expected from struct sockaddr) due to the
ifru_map and ifru_settings members.
Cl
On Mon, 2019-01-28 at 11:22 -0800, David Miller wrote:
> I see some back and forth between you and Al, where do we stand at
> this point?
I don't really know. I think neither of us _likes_ this code, in
particular the whole copy_in_user() thing is quite a mess. The
copy_in_user() also means that
ional condition,
needs to rerun the checks after that condition changes
Felix Fietkau (1):
mac80211: ensure that mgmt tx skbs have tailroom for encryption
Johannes Berg (1):
cfg80211: call disconnect_wk when AP stops
to indicate missing/inaccurate tx A-MPDU
length
Gustavo A. R. Silva (1):
cfg80211: mark expected switch fall-throughs
Johannes Berg (5):
mac80211: remove unused variable
Merge remote-tracking branch 'net-next/master' into mac80211-next
netlink: reduce NLA_PO
From: Johannes Berg
When an rhashtabl walk is done from irq/bh context, we rightfully
get a lockdep complaint saying that we could get a (soft-)IRQ in
the middle of a rehash. This happened e.g. in mac80211 as it does
a walk in soft-irq context.
Fix this by using irq-safe locking here. We don&#
On Tue, 2019-02-05 at 15:37 +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> When an rhashtabl walk is done from irq/bh context, we rightfully
> get a lockdep complaint saying that we could get a (soft-)IRQ in
> the middle of a rehash. This happened e.g. in mac80211 as it d
From: Johannes Berg
When an rhashtable walk is done from softirq context, we rightfully
get a lockdep complaint saying that we could get a softirq in the
middle of a rehash, and thus deadlock on &ht->lock. This happened
e.g. in mac80211 as it does a walk in softirq context.
Fix this b
e used it internally
before returning SKB
----
Johannes Berg (1):
nl80211: fix memory leak if validate_pae_over_nl80211() fails
Sara Sharon (2):
mac80211: fix a kernel panic when TXing after TXQ teardown
mac8021
0211_hwsim: allow configurable cipher types
mac80211_hwsim: fixes kernel crash during mac80211_hwsim init
mac80211_hwsim: fix overwriting of if_combination
Johannes Berg (17):
cfg80211: tracing: avoid 'idx' variable
mac80211: tracing: avoid 'idx' variable
duplicate detection
Felix Fietkau (2):
mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext
mac80211: fix reordering of buffered broadcast packets
Johannes Berg (2):
cfg80211/mac80211: fix FTM settings across CSA
mac80211: fix CSA beacon allocation size
Jouni
This adds nested policy validation, which lets you specify the
nested attribute type, e.g. NLA_NESTED with sub-policy, or the
new NLA_NESTED_ARRAY with sub-sub-policy.
Changes in v2:
* move setting the bad attr pointer/message into validate_nla()
* remove the recursion patch since that's no lon
From: Johannes Berg
Now that we have a validation_data pointer, and the len field in
the policy is unused for NLA_NESTED, we can allow using them both
to have nested validation. This can be nice in code, although we
still have to use nla_parse_nested() or similar which would also
take a policy
From: Johannes Berg
This unifies the code between nla_parse() which sets the bad
attribute pointer and an error message, and nla_validate()
which only sets the bad attribute pointer.
It also cleans up the code for NLA_REJECT and paves the way
for nested policy validation, as it will allow us to
From: Johannes Berg
Sometimes nested netlink attributes are just used as arrays, with
the nla_type() of each not being used; we have this in nl80211 and
e.g. NFTA_SET_ELEM_LIST_ELEMENTS.
Add the ability to validate this type of message directly in the
policy, by adding the type NLA_NESTED_ARRAY
From: Johannes Berg
This isn't used anywhere, so we might as well get rid of it.
Reviewed-by: David Ahern
Signed-off-by: Johannes Berg
---
include/net/netlink.h | 2 --
lib/nlattr.c | 11 ---
2 files changed, 13 deletions(-)
diff --git a/include/net/netlink.h b/includ
From: Johannes Berg
The validation data is only used within the policy that
should usually already be const, and isn't changed in any
code that uses it. Therefore, make the validation_data
pointer const.
While at it, remove the duplicate variable in the bitfield
validation that I'd
From: Johannes Berg
Fix a simple typo: attribuets -> attributes
Signed-off-by: Johannes Berg
---
include/net/netlink.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index ddabc832febc..69866f5a97f2 100644
--- a/include/
On Wed, 2018-09-26 at 10:21 -0700, David Miller wrote:
> From: Johannes Berg
> Date: Wed, 26 Sep 2018 11:15:29 +0200
>
> > This adds nested policy validation, which lets you specify the
> > nested attribute type, e.g. NLA_NESTED with sub-policy, or the
> > new NL
t_core()
Bob Copeland (1):
mac80211: fix pending queue hang due to TX_DROP
Felix Fietkau (1):
mac80211: allocate TXQs for active monitor interfaces
Johannes Berg (1):
mac80211: TDLS: fix skb queue/priority assignment
Jouni Malinen (1):
cfg80211: Address some corner cas
> This interface wasn't designed for use in softirq contexts.
Well, it clearly was used there. You even gave it a gfp_t argument in
rhashtable_walk_init(), so you can't really claim it wasn't designed for
this. I see now that it's ignored, but still?
> Could you please show me who is doing this
On Fri, 2019-02-08 at 05:48 +0800, Herbert Xu wrote:
> On Thu, Feb 07, 2019 at 02:50:54PM +0100, Johannes Berg wrote:
> >
> > > This interface wasn't designed for use in softirq contexts.
> >
> > Well, it clearly was used there. You even gave it a gfp_t argumen
80211: Fix FTM per burst maximum value
Ilan Peer (1):
mac80211: Fix Tx aggregation session tear down with ITXQs
Johannes Berg (5):
cfg80211: pmsr: fix MAC address setting
cfg80211: pmsr: fix abort locking
mac80211: call drv_ibss_join() on restart
cfg80211: pmsr: r
On Tue, 2019-02-12 at 10:43 -0800, David Miller wrote:
> Herbert and Johannes, I need some guidance.
>
> It seems Herbert wants the softirq usage of rhashtables removed,
Well, specifically of rhashtable walkers. I can only concede that he's
right in that a hashtable walk during softirq (or even
Thanks for the heads-up, Randy. We'd seen separate build bot reports on
this as well.
> ERROR: "__umoddi3" [net/wireless/cfg80211.ko] undefined!
> ERROR: "__umoddi3" [net/mac80211/mac80211.ko] undefined!
Should be fixed as of yesterday, let me know if it reappears.
johannes
On Wed, 2019-02-13 at 22:38 +0800, Herbert Xu wrote:
> Hi:
>
> The first two patches in this series are bug fixes and should be
> backported to stable.
>
> They fixes a number of issues with the use of the rhashtable API
> in mac80211. First of all it converts the use of rashtable walks over
> t
On Wed, 2019-02-13 at 22:39 +0800, Herbert Xu wrote:
> + if (ret != -EEXIST)
> return ERR_PTR(ret);
Surely that should still be "if (ret && ret != -EEXIST)" otherwise you
return for the success case too? or "else if"?
I'd probably say we should combine all those ifs into somethi
> The first two patches in this series are bug fixes and should be
> backported to stable.
>
> They fixes a number of issues with the use of the rhashtable API
> in mac80211. First of all it converts the use of rashtable walks over
> to a simple linked list. This is because an rhashtable walk is
On Thu, 2019-02-14 at 21:15 -0500, Sasha Levin wrote:
> From: Chaitanya Tata
>
> [ Upstream commit 93183bdbe73bbdd03e9566c8dc37c9d06b0d0db6 ]
>
> Recently, DMG frequency bands have been extended till 71GHz, so extend
> the range check till 20GHz (45-71GHZ), else some channels will be marked
> as
Hi Dave,
It's clear things are winding down, this is basically just the stuff
from Herbert that we've been discussing. I threw in a simple error
path fix, mostly because it's simple :-)
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit f9b
ot;)
Acked-by: Herbert Xu
Signed-off-by: Wei Yongjun
Signed-off-by: Johannes Berg
---
Dave, can you take this directly? I see little value in sending a
pull request for this one patch (but if you prefer can do so.)
---
net/mac80211/mesh_pathtbl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
+netdev
Hi,
> Sorry to write to you directly, I'm not sure if I should CC some
> public lists, please feel free to add them if that's the right way to
> do.
I think it is, adding netdev.
> I would like to add back the alx WoL feature which is reverted by you
> 5 years ago, and we have some disc
Hi Dave,
Just another handful of fixes as we wind down towards the
merge window.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 6caf9fb3bda17df59de4ed6ed4950c43ca1361e3:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf (20
On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote:
> fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table
> instead of all 17 arguments by value.
> dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table'
> defined with very similar yet subtly different fields and offse
an (1):
mac80211: add api to set CSA counter in mac80211
Haim Dreyfuss (1):
nl80211: Add wmm rule attribute to NL80211_CMD_GET_WIPHY dump command
Ilan Peer (1):
mac80211: Support adding duration for prepare_tx() callback
Johannes Berg (9):
mac80211: rename rtap_vendor_spac
mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
Johannes Berg (3):
nl80211: don't expose wdev->ssid for most interfaces
cfg80211: initialize regulatory keys/database later
mac80211: properly free requested-but-not-started TX agg sessions
Kees Cook (2):
On Tue, 2017-11-21 at 20:17 +0900, David Miller wrote:
> From: Johannes Berg
> Date: Mon, 20 Nov 2017 17:06:44 +0100
>
> > ssh://korg/pub/scm/linux/kernel/git/jberg/mac80211.git
> > tags/mac80211-for-davem-2017-11-20
>
> That's an awesome URL, but I don't
On Wed, 2017-11-22 at 19:29 +0100, Arend van Spriel wrote:
> + Johannes
>
> >>> BUG_ON(!sig->digest);
> BUG_ON(!sig->s);
I *think* this is the same bug that was reported before, then this
should fix it:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=d7be10
On Wed, 2017-11-22 at 15:07 -0800, Florian Fainelli wrote:
> On 11/22/2017 10:42 AM, Johannes Berg wrote:
> > On Wed, 2017-11-22 at 19:29 +0100, Arend van Spriel wrote:
> > > + Johannes
> > >
> > > >>> BUG_ON(!sig->digest);
> > >
On Thu, 2017-11-23 at 09:47 -0800, Florian Fainelli wrote:
> Absolutely, please find it enclosed.
Thanks.
This is a bit odd. I didn't think the most likely reason is that you
have
CONFIG_CRYPTO_SHA256=m
but everything else built-in. Thus, when loading the certificate,
there's no way to calcula
metric for RANN frame
Johannes Berg (2):
cfg80211: select CRYPTO_SHA256 if needed
mac80211: use QoS NDP for AP probing
Sara Sharon (1):
mac80211: tear down RX aggregations first
drivers/net/wireless/ath/ath9k/channel.c | 2 +-
drivers/net/wireless/st/cw1200/sta.c | 4 ++
From: Johannes Berg
This reverts commit d6f295e9def0; some userspace (in the case
we noticed it's wpa_supplicant), is relying on the current
error code to determine that a fixed name interface already
exists.
Reported-by: Jouni Malinen
Signed-off-by: Johannes Berg
---
net/core/dev.
401 - 500 of 1980 matches
Mail list logo
