This series contains some generic netlink improvements, making
the API safer to use, and making the function pointers in the
family struct safer by allowing it to be __ro_after_init.
The first patch, introducing genl_family_attrbuf(), just ensures
that the users of family->attrbuf aren't actually
From: Johannes Berg
Now genl_register_family() is the only thing (other than the
users themselves, perhaps, but I didn't find any doing that)
writing to the family struct.
In all families that I found, genl_register_family() is only
called from __init functions (some indirectly, in which
From: Johannes Berg
Instead of providing macros/inline functions to initialize
the families, make all users initialize them statically and
get rid of the macros.
This reduces the kernel code size by about 1.6k on x86-64
(with allyesconfig).
Signed-off-by: Johannes Berg
---
drivers/acpi
From: Johannes Berg
Static family IDs have never really been used, the only
use case was the workaround I introduced for those users
that assumed their family ID was also their multicast
group ID.
Additionally, because static family IDs would never be
reserved by the generic netlink code, using
From: Johannes Berg
This helper function allows family implementations to access
their family's attrbuf. This gets rid of the attrbuf usage
in families, and also adds locking validation, since it's not
valid to use the attrbuf with parallel_ops or outside of the
dumpit callback.
Sig
From: Johannes Berg
Since generic netlink family IDs are small integers, allocated
densely, IDR is an ideal match for lookups. Replace the existing
hand-written hash-table with IDR for allocation and lookup.
This lets the families only be written to once, during register,
since the list_head
tu in p80211netdev, remove wlan_change_mtu
> - set min/max_mtu in net/mac80211/iface.c and remove ieee80211_change_mtu
For the mac80211 part,
Acked-by: Johannes Berg
Dave, I'm assuming you'll pick this up, but if you prefer not to I can
also coordinate with Kalle to take this through our trees.
johannes
On Wed, 2016-10-19 at 08:59 -0700, Ben Greear wrote:
>
> Do you actually expect performance regressions? I'll be complaining
> if so, but will test first :)
I think we can expect this to use a bit more CPU time, but unless
you're very tight on that you probably shouldn't expect any throughput
di
On Tue, 2016-10-18 at 22:33 -0400, Jarod Wilson wrote:
> - set max_mtu in wil6210 driver
> - set max_mtu in atmel driver
> - set min/max_mtu in cisco airo driver, remove airo_change_mtu
> - set min/max_mtu in ipw2100/ipw2200 drivers, remove
> libipw_change_mtu
> - set min/max_mtu in p80211netdev, r
On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:
> On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
> >
> >
> > Annoyingly, all this complication with scatterlists etc is for
> > doing
> > asynchronous crypto via DMA capable crypto accelerators, and the
> > networking code (ips
> > I guess we should do the same in net/mac80211/iface.c?
>
> Yeah. I thought I'd located all places this needed to happen, but
> obviously not. I'll get this added and do another sweep for others I
> might have missed.
No worries. I can also do it if you prefer, just wanted to ask :)
johannes
On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:
>
> > Hmm. Is it really worth having a per-CPU variable for each possible
> > key? You could have a large number of those (typically three when
> > you're a client on an AP, and 1 + 1 for each client when you're the
> > AP).
2 + 1 for each
On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote:
>
> + aead_req = *this_cpu_ptr(ccmp->reqs);
> + if (!aead_req) {
> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
> + if (!aead_req)
> + return -ENOMEM;
> + *this_cpu_
nner
MAC addresses properly to prevent controlled port bypass
Ard Biesheuvel (1):
mac80211: move struct aead_req off the stack
Johannes Berg (4):
mac80211: discard multicast and 4-addr A-MSDUs
cfg80211: let i
On Mon, 2016-10-17 at 15:05 +0100, Ard Biesheuvel wrote:
> From: Johannes Berg
That really ought to have been you - I think I may have lost that by
accident. I'll change it.
> In addition, take care not to put any of our own stack allocations
> into
> scatterlists. This involv
> Indeed. And it keeps the clutter inside the aes_xxx.c files, which
> could easily be updated in the future to use some auxdata feature if
> it ever materializes.
>
> I think it would help this code, but also the ESP code you pointed
> out, to have some kind of 'ordered synchronous' CRYPTO_xxx f
On Mon, 2016-10-17 at 14:06 +0100, Ard Biesheuvel wrote:
>
> Actually, while I think it will be worthwhile going forward to
> implement such an 'auxiliary data' feature in a generic way, I still
> think we should address the issue at hand without too much
> complication.
>
> If we pedal back to t
> > Well, if your other patch to make it OK to be on-stack would be
> > applied instead, this wouldn't make much sense either :)
> >
>
> Yes but that one only fixes ccm not gcm
Yes, but we can do the same for GCM, no?
> > In this particular patch, we could reduce the size of the struct,
> > bu
On Mon, 2016-10-17 at 00:39 +0200, Linus Lüssing wrote:
> For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the
> more modern, netlink based driver instead of wext.
Makes sense, applied.
> Actually, I wasn't even able to make a connection with the
> configuration
> files and infor
On Mon, 2016-10-17 at 10:30 +0100, Ard Biesheuvel wrote:
> Yes. But as I replied, setting the req size is not supported atm,
> although it is reasonable to demand a way to allocate additional data
> in the request specifically for this issue. So let's proceed with the
> aead_request_alloc/free pat
> Apologies for going back and forth on this, but it appears there may
> be another way to deal with this.
>
> First of all, we only need this handling for the authenticated data,
Are you sure b_0/j_0 aren't needed? We pass those
to aead_request_set_crypt(), and I wasn't sure what that really di
From: Johannes Berg
As the stack can (on x86-64) now be virtually mapped rather than
using "normal" kernel memory, Sergey noticed mac80211 isn't using
the SG APIs correctly by putting on-stack buffers into SG tables.
This leads to kernel crashes.
Fix this by allocating t
[snip]
Sorry, this went out by mistake.
johannes
From: Johannes Berg
Some crypto implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of private data in their struct aead_req.
This means these data structures cannot live in the vmalloc area, which
means that they cannot live on the stack (with
From: Johannes Berg
As the stack can (on x86-64) now be virtually mapped rather than
using "normal" kernel memory, Sergey noticed mac80211 isn't using
the SG APIs correctly by putting on-stack buffers into SG tables.
This leads to kernel crashes.
Fix this by allocating a bit of
From: Johannes Berg
Some crypto implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of private data in their struct aead_req.
This means these data structures cannot live in the vmalloc area, which
means that they cannot live on the stack (with
On Mon, 2016-10-17 at 08:50 +0100, Ard Biesheuvel wrote:
> I just realised that patch should probably use
> aead_request_alloc/aead_request_free [and drop the memset]. That also
> fixes the latent bug where the alignment of the req ctx is not take
> into account.
Good point, I'll fix that up.
>
From: Johannes Berg
Some crypto implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of private data in their struct aead_req.
This means these data structures cannot live in the vmalloc area, which
means that they cannot live on the stack (with
On Mon, 2016-10-17 at 08:37 +0100, Ard Biesheuvel wrote:
>
> Could we get a statement first whether it is supported to allocate
> aead_req (and other crypto req structures) on the stack?
Well, we haven't heard from Herbert :)
> If not, then
> we have our work cut out for us. But if it is, I'd r
On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote:
> The CCM code goes out of its way to perform the CTR encryption of the
> MAC using the subordinate CTR driver. To this end, it tweaks the
> input and output scatterlists so the aead_req 'odata' and/or
> 'auth_tag' fields [which may live on t
>
> Is the aad[] actually reused? I would assume it only affects the mac
> on encryption, and the verification on decryption but I don't think
> we actually need it back from the crypto routines.
I don't think it's reused.
> Exactly what you said above :-) My patch only touches CCM but as you
>
On Fri, 2016-10-14 at 14:13 +0100, Ard Biesheuvel wrote:
>
> > But if we allocate things anyway, is it worth expending per-CPU
> > buffers on these?
>
> Ehmm, maybe not. I could spin a v2 that allocates a bigger buffer,
> and copies aad[] into it as well
Copies in/out, I guess. Also there's B_0/
On Fri, 2016-10-14 at 15:10 +0200, Johannes Berg wrote:
> >
> > So use kzalloc
>
> Do we really need kzalloc()? We have things on the stack right now,
> and don't initialize, so surely we don't really need to zero things?
Err, never mind, I'm an idiot
> So use kzalloc
Do we really need kzalloc()? We have things on the stack right now, and
don't initialize, so surely we don't really need to zero things?
> This only addresses one half of the problem. The other problem, i.e.,
> the fact that the aad[] array lives on the stack of the caller, is
>
> So why is the performance hit acceptable for ESP but not for WPA? We
> could easily implement the same thing, i.e.,
> kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it
> on the stack
Yeah, maybe we should. It's likely a much bigger allocation, but I
don't actually know if th
On Fri, 2016-10-14 at 10:21 +0100, Ard Biesheuvel wrote:
> It is annotated with a TODO, though :-)
>
> 38320c70d282b (Herbert Xu 2008-01-28 19:35:05
> -0800 41)
> * TODO: Use spare space in skb for this where possible.
I saw that, but I don't think generally there will be spare s
On Fri, 2016-10-14 at 17:39 +0900, Sergey Senozhatsky wrote:
>
> given that we have a known issue shouldn't VMAP_STACK be
> disabled for now, or would you rather prefer to mark MAC80211
> as incompatible: "depends on CFG80211 && !VMAP_STACK"?
Yeah. It's a bit complicated by the fact that most peo
On Fri, 2016-10-14 at 10:05 +0100, Ard Biesheuvel wrote:
>
> Indeed. And the decrypt path does the same for auth_tag[].
Hadn't gotten that far, due to the BUG_ON() in CONFIG_DEBUG_SG in the
encrypt path :)
> But that still means there are two separate problems here, one which
> affects the WPA c
On Fri, 2016-10-14 at 09:47 +0100, Ard Biesheuvel wrote:
>
> Do you have a reference for the sg_set_buf() call on odata?
> crypto/ccm.c does not seem to have it (afaict),
It's indirect - crypto_ccm_encrypt() calls crypto_ccm_init_crypt()
which does it.
> and the same problem
> does not exist in
For reference, this was my patch moving the mac80211 buffers to percpu.
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7663c28ba353..c3709ddf71e9 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -29,6 +29,8 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead
On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote:
> > I assume the stack buffer itself is not the problem here, but aad,
> > which is allocated on the stack one frame up.
> > Do we really need to revert the whole patch to fix that?
>
> Ah never mind, this is about 'odata'. Apologies, shoul
> 1. revert that patch (doing so would need some major adjustments now,
> since it's pretty old and a number of new things were added in the
> meantime)
This it will have to be, I guess.
> 2. allocate a per-CPU buffer for all the things that we put on the
> stack and use
On Thu, 2016-10-13 at 14:49 -0700, Andy Lutomirski wrote:
>
> It's failing before that. With CONFIG_VMAP_STACK=y, the stack may
> not be physically contiguous and can't be used for DMA, so putting it
> in a scatterlist is bogus in general, and the crypto code mostly
> wants a scatterlist.
I see,
On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
>
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_s
On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
> In a pinch, I have these patches sitting around:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> https://git.kernel.org/cgit/linux/kernel/git/luto/lin
> > Can you elaborate on how exactly it kills your system?
>
> the last time I saw it it was a NULL deref at
> ieee80211_aes_ccm_decrypt.
Hm. I was expecting something within the crypto code would cause the
crash, this seems strange.
Anyway, I'm surely out of my depth wrt. the actual cause. Som
On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote:
> This patch adds filtering for multicast data packets on AP_VLAN
> interfaces
>
[...]
Applied patches 1 and 2 for now, I'll look at the others again later.
johannes
Hi,
Sorry - I meant to look into this yesterday but forgot.
> Andy, can this be related to CONFIG_VMAP_STACK?
I think it is.
> > current -git kills my system.
Can you elaborate on how exactly it kills your system?
> > adding
> >
> > if (!virt_addr_valid(&aad[2])) {
> > WARN_
> *
> + * @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Multicast packets
> should be
> + * send out as unicast to all stations.
You should document what type of attribute is expected. You probably
wanted a flag attribute, but ...
> + [NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .typ
On Thu, 2016-10-06 at 13:53 +0200, michael-dev wrote:
> Am 05.10.2016 13:58, schrieb Johannes Berg:
> >
> >
> > Anyway, perhaps this needs to change to take DMS/per-station into
> > account?
> >
> > Then again, this kind of setting - global multicast-to-
On Wed, 2016-10-05 at 13:40 +0200, michael-dev wrote:
> Am 05.10.2016 12:19, schrieb Johannes Berg:
> >
> > >
> > > on both ends. Furthermore, I've seen a few mobile phone stations
> > > locally that indicate qos support but won't complete DHCP i
+netdev
> IEEE802.11-2012 proposes directed multicast service (DMS) using A-
> MSDU frames and a station initiated control protocol. It has the
> advantage that the station can recover the destination multicast mac
> address, but it is not backward compatible with non QOS stations and
> does not e
rt NAN function match
David Spinadel (1):
cfg80211: Add support for static WEP in the driver
Johannes Berg (3):
cfg80211: add checks for beacon rate, extend to mesh
cfg80211: wext: really don't store non-WEP keys
Merge remote-tracking branch 'net-next/master' into m
On Mon, 2016-10-03 at 01:54 -0400, David Miller wrote:
>
> Could you please look into this and send me a new pull request with
> the conflicts resolved?
>
Sure, will do (tomorrow, we have a holiday today).
Would you prefer I send you the merge resolution for your tree, or just
pull in net for a
_nan_func and rm_nan_func
mac80211: Add API to report NAN function match
David Spinadel (1):
cfg80211: Add support for static WEP in the driver
Johannes Berg (2):
cfg80211: add checks for beacon rate, extend to mesh
cfg80211: wext: really don't store non-WEP keys
Pedersen, T
> > I kinda see the logic here - we really don't need to queue as much
> > if we can't possibly transmit it out quickly - but it seems to me
> > we should also throw in some kind of limit that's relative to the
> > amount of memory you have on the system?
>
> Yes, ideally. That goes for FQ-CoDel
> + tmp = krealloc(buf->begin, size, GFP_KERNEL | GFP_DMA);
> + if (tmp) {
>
I think that check is inverted?
johannes
On Fri, 2016-09-23 at 21:59 +0200, Toke Høiland-Jørgensen wrote:
> Small devices can run out of memory from queueing too many packets.
> If VHT is not supported by the PHY, having more than 4 MBytes of
> total queue in the TXQ intermediate queues is not needed, and so we
> can safely limit the memo
On Mon, 2016-09-19 at 13:03 +0200, Johannes Berg wrote:
> On Mon, 2016-09-19 at 18:58 +0800, Herbert Xu wrote:
> >
> > v3 fixes a bug in the remove path that causes the element count
> > to decrease when it shouldn't, leading to a gigantic hash table
> > when it
On Mon, 2016-09-19 at 18:58 +0800, Herbert Xu wrote:
> v3 fixes a bug in the remove path that causes the element count
> to decrease when it shouldn't, leading to a gigantic hash table
> when it underflows.
>
Ok, with the BUG_ON() thrown in, this works in the test that was
failing before. I'll run
On Mon, 2016-09-19 at 18:48 +0800, Herbert Xu wrote:
> On Mon, Sep 19, 2016 at 12:10:27PM +0200, Johannes Berg wrote:
> >
> > Btw, for debug I put
> >
> > BUG_ON(atomic_read(&ht->nelems) < 0);
> >
> > after the atomic_dec() in __rhashtable_remov
Btw, for debug I put
BUG_ON(atomic_read(&ht->nelems) < 0);
after the atomic_dec() in __rhashtable_remove_fast_one(). That makes
the kernel crash instantly on the buggy code, and I just have to run a
single test ("wpas_ctrl_interface_add_many") to get there.
johannes
On Mon, 2016-09-19 at 12:02 +0200, Johannes Berg wrote:
> On Mon, 2016-09-19 at 11:54 +0200, Johannes Berg wrote:
> >
> > >
> > >
> > > The stack trace is useless, but my other annotation showed that
> > > the
> > > table's nelems
On Mon, 2016-09-19 at 11:54 +0200, Johannes Berg wrote:
> >
> > The stack trace is useless, but my other annotation showed that the
> > table's nelems *underflowed* to -1, so now the worker will continue
> > to try to grow it forever.
> >
>
> And
> The stack trace is useless, but my other annotation showed that the
> table's nelems *underflowed* to -1, so now the worker will continue
> to try to grow it forever.
>
And this *was* actually a case of duplication, afaict, since it was
multiple virtual interfaces on the same device all connec
On Mon, 2016-09-19 at 17:34 +0800, Herbert Xu wrote:
> On Mon, Sep 19, 2016 at 11:27:24AM +0200, Johannes Berg wrote:
> >
> >
> > I have a feeling there's a bug with ht->nelems, since the crash is
> > always in the grow worker, but I haven't quite put my
On Mon, 2016-09-19 at 17:34 +0800, Herbert Xu wrote:
> On Mon, Sep 19, 2016 at 11:27:24AM +0200, Johannes Berg wrote:
> >
> >
> > I have a feeling there's a bug with ht->nelems, since the crash is
> > always in the grow worker, but I haven't quite put my
On Mon, 2016-09-19 at 11:27 +0200, Johannes Berg wrote:
> >
> I have a feeling there's a bug with ht->nelems, since the crash is
> always in the grow worker, but I haven't quite put my finger on it
> yet.
>
Btw, I should not actually get into the duplicate case here.
johannes
> What does your test suite actually do? Is it something that I
> can run without special hardware?
Yes, it's pretty simple - it spins up a number of VMs with hwsim and
just runs a lot of tests:
https://w1.fi/cgit/hostap/tree/tests/hwsim
I've attached a kernel .config you can use for it.
I'm r
On Mon, 2016-09-19 at 16:40 +0800, Herbert Xu wrote:
> I've tested the rhlist code with test_rhashtable but I haven't
> tested the mac80211 conversion. So please give it a go and see
> if it still works.
This is still running out of memory on my test suite.
Somehow I don't see kmemleak kicking
> > I take that back. I think it's leaking memory - my tests never used
> > to run out of memory, but now they eventually do.
>
> > I'll try to figure out more.
>
> Interesting. The kernel test robot found a bug in the insertion
> slowpath where we end up inserting without taking the inner spin
> Yes, it's passing all the wpa_supplicant tests, so
>
> Acked-by: Johannes Berg
>
I take that back. I think it's leaking memory - my tests never used to
run out of memory, but now they eventually do.
I'll try to figure out more.
johannes
lot Herbert!
> I've tested the rhlist code with test_rhashtable but I haven't
> tested the mac80211 conversion. So please give it a go and see
> if it still works.
Yes, it's passing all the wpa_supplicant tests, so
Acked-by: Johannes Berg
I assume you want at least the f
11: clarify the requirements of .disconnect()
mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE
Johannes Berg (21):
mac80211: add support for radiotap timestamp field
mac80211: send delBA on unexpected BlockAck data frames
mac80211: send delBA on unexpected B
se drivers
* check return value of skb_linearize()
----
Johannes Berg (2):
mac80211: check skb_linearize() return value
mac80211: reject TSPEC TIDs (TSIDs) for aggregation
net/mac80211/agg-rx.c | 8 +++-
net/mac80211/ag
, fixing a copy/paste bug (from myself)
Felix Fietkau (2):
mac80211: fix tim recalculation after PS response
mac80211: fix sequence number assignment for PS response frames
Johannes Berg (1):
nl80211: validate num
On Wed, 2016-08-31 at 00:35 +0530, Bhaktipriya Shridhar wrote:
> The workqueue "cfg80211_wq" is involved in cleanup, scan and event
> related
> works. It queues multiple work items &rdev->event_work,
> &rdev->dfs_update_channels_wk,
> &wiphy_to_rdev(request->wiphy)->scan_done_wk,
> &wiphy_to_rdev(w
not have to depend on it for it
Arik Nemtsov (1):
mac80211: TDLS: don't require beaconing for AP BW
Johannes Berg (1):
Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel"
Linus L
On Fri, 2016-08-19 at 22:02 +0200, Linus Lüssing wrote:
> This allows modules using this function (currently: batman-adv) to
> compile even if cfg80211 is not built at all, thus relaxing
> dependencies.
>
Err, excuse the earlier empty email - editing mixup.
I've applied this and will send it to 4
On Fri, 2016-08-19 at 22:02 +0200, Linus Lüssing wrote:
> This allows modules using this function (currently: batman-adv) to
> compile even if cfg80211 is not built at all, thus relaxing
> dependencies.
johannes
> struct ethtool_wolinfo {
> __u32 cmd;
> __u32 supported;
> __u32 wolopts;
> __u8sopass[SOPASS_MAX]; // 6, actually
> };
>
> we could do
>
> struct ethtool_wolinfo {
> __u32 cmd;
> __u32 supported;
> __u32 wolopts;
>
> If we want to go down this route, probably the only option is to add
> __attribute__((pack)) those structs to just have no padding at all,
> thus breaking uapi.
>
We could also spell out the padding bytes as reserved, i.e. instead of
struct ethtool_wolinfo {
__u32 cmd;
__u32
1: remove skb header offset mangling in ieee80211_build_hdr
Johannes Berg (1):
nl80211: explicitly check enum nl80211_mesh_power_mode
Maxim Altshul (2):
mac80211: mesh: Add support for HW RC implementation
mac80211: call get_expected_throughput only after adding station
Pur
From: Johannes Berg
Pass the correct type __wsum to csum_sub() and csum_add(). This doesn't
really change anything since __wsum really *is* __be32, but removes the
address space warnings from sparse.
Cc: Eric Dumazet
Fixes: 34ae6a1aa054 ("ipv6: update skb->csum when CE mark
On Thu, 2016-08-11 at 23:26 +0200, Eric Dumazet wrote:
> On Thu, 2016-08-11 at 12:04 +0200, Johannes Berg wrote:
> >
> > From: Johannes Berg
> >
> > Use the correct type for these manipulations, which is __wsum,
> > instead of using __be32. This doesn't r
On Tue, 2016-07-19 at 08:36 -0400, Bob Copeland wrote:
> On Wed, Jul 13, 2016 at 02:45:25PM +0300, Yaniv Machani wrote:
> >
> > When a packet is received for transmission,
> > a PREQ frame is sent to resolve the appropriate path to the desired
> > destination.
> > After path was established, any s
On Mon, 2016-08-08 at 10:06 +0300, Yaniv Machani wrote:
> From: Meirav Kama
>
> MP received data frames from another MP. Frames are forwarded
> from Rx to Tx to be transmitted to a third MP.
> Upon cloning the skb, the tx_info was zeroed, and the
> hw_queue wasn't set correctly, causing frames to
From: Johannes Berg
Use the correct type for these manipulations, which is __wsum,
instead of using __be32. This doesn't really change anything
since __wsum really *is* __be32, but removes the address space
warnings from sparse.
Cc: Eric Dumazet
Fixes: 34ae6a1aa054 ("ipv6: update
On Fri, 2016-08-05 at 14:32 +0200, Johannes Berg wrote:
> Hi Dave,
>
> Here's a first set of fixes for the current cycle. See the tag
> message
> for more information.
>
> I'll probably have a follow-up fix for the real problem in mac80211
> that caused the cra
Hi Dave,
Here's a first set of fixes for the current cycle. See the tag message
for more information.
I'll probably have a follow-up fix for the real problem in mac80211
that caused the crash later, but for now we have this patch and it
makes sense and fixes the crash, even if the behaviour isn't
On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote:
> On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote:
> >
> > Hm. Would you rather allocate a separate head entry for the
> > hashtable,
> > or chain the entries?
>
> My plan is to build support
On Fri, 2016-08-05 at 12:08 +0200, Julia Lawall wrote:
>
> Can I do the same for:
>
> if (of_property_read_bool(np, "phy-clk-valid"))
> pdata->check_phy_clk_valid = 1;
> else
> pdata->check_phy_clk_valid = 0;
>
> The type is not bool, but:
>
> inc
> - if (of_get_property(pdev->dev.of_node,
> - "little-endian", NULL))
> + if (of_property_read_bool(pdev->dev.of_node, "little-
> endian"))
> priv->is_little_endian = true;
> else
> priv->is_little_endian = false;
>
Perhaps, whil
> So I'm going to fix this by consolidating identical objects into
> a single rhashtable entry which also lets us get rid of the
> insecure_elasticity setting.
Hm. Would you rather allocate a separate head entry for the hashtable,
or chain the entries?
(Luckily) the colliding key case practicall
On Wed, 2016-08-03 at 11:51 +0900, Masashi Honma wrote:
> On 2016年08月02日 16:27, Johannes Berg wrote:
> > This explicitly configures *HT capability* though - that's even the
> > name of the parameter. If you enable HT40 in the capability, the
> > resulting BSS might still
On Wed, 2016-07-13 at 14:44 +0300, Yaniv Machani wrote:
> From: Maital Hahn
>
> Some drivers (e.g. wl18xx) expect that the last stage in the
> de-initialization process will be stopping the beacons, similar to AP
> flow.
> Update ieee80211_stop_mesh() flow accordingly.
> As peers can be removed d
On Wed, 2016-07-13 at 14:57 +0300, Yaniv Machani wrote:
> From: Meirav Kama
>
> Upon forwarding frames from Rx to Tx in mesh, driver clones the skb.
> It zeros the tx_info and doesn't set hw_queue correctly. It then
> enqueues
> the frame in queue 0 (VOICE) instead of the correct queue.
> Upon re
On Sun, 2016-07-17 at 19:55 +0100, Colin King wrote:
> From: Colin Ian King
>
> The switch on chandef->width is missing a break on the
> NL8211_CHAN_WIDTH_80P80 case; currently we get a WARN_ON when
> center_freq2 is non-zero because of the missing break.
>
Applied, thanks.
johannes
On Tue, 2016-08-02 at 11:59 +0900, Masashi Honma wrote:
> >
> > On 2016年08月01日 19:03, Johannes Berg wrote:
> > >
> > > But why is that behaviour *correct*? We still support 40 MHz
> > > bandwidth
> > > things, we just don't use them if we
On Fri, 2016-07-22 at 14:26 +0900, Masashi Honma wrote:
> On 2016年07月14日 05:07, Yaniv Machani wrote:
> > +
> > + /* if channel width is 20MHz - configure HT capab
> > accordingly*/
> > + if (sdata->vif.bss_conf.chandef.width ==
> > NL80211_CHAN_WIDTH_20) {
> > + cap &= ~IEEE80211_HT_C
901 - 1000 of 1980 matches
Mail list logo
