ANNOUNCE: Netdev 2.1 update Mar 03

[Jamal Hadi Salim]

The tech committee has accepted a new workshop on
Network Performance chaired by Alexander Duyck

Some details:
--
The network performance performance workshop is a follow-up of several 
mailing list threads on the netdev mailing list as well as presentations 
at Netdev 1.2. We want to discuss the progress made on various efforts 
to enable better performance through enabling new features in the 
kernel, and changing existing APIs to better enable the drivers to 
handle the ever increasing workloads.


This is an opportunity to bring together the various network device 
vendors to discuss what has worked and what hasn't in terms of enabling 
better performance in the Linux kernel ecosystem.


Topics for the session would include:

Implementing page based receive paths and page recycling and/or reuse
Zero-copy using AF_PACKET to accelerate user-space networking
Recent changes to enable better use of build_skb and XDP
Batching of Tx and Rx workloads
Kernel memory optimizations
-

Alex will be posting a lot more details and agenda items by
the conference time.

cheers,
jamal

Re: [PATCH 4.12 V2] brcmfmac: move brcmf_txcomplete function to fwsignal.c

[Franky Lin]

Hi Rafal,

On Thu, Mar 2, 2017 at 10:38 PM, Rafał Miłecki  wrote:
> From: Rafał Miłecki 
>
> This function is called by USB and SDIO only, both using BCDC & FW
> Signalling. Move it out of core.c to make this file more generic and
> allow making fwsignal optional in the future.

Same with the brcmf_txflowblock patch, it would be better to wrap
fwsignal in bcdc
as a protocol feature. I am preparing a train to do that for these two
functions along
with others. Hopefully we will post them next week after internal review.

Again, sorry for the stall on this.

Thanks,
Franky

> Signed-off-by: Rafał Miłecki 
> ---
> V2: Make code with this patch compile when not based on top of (to be dropped)
> [PATCH 4.12] brcmfmac: get rid of brcmf_txflowblock helper function
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h |  3 ---
>  .../net/wireless/broadcom/brcm80211/brcmfmac/core.c| 18 
> --
>  .../wireless/broadcom/brcm80211/brcmfmac/fwsignal.c| 18 
> ++
>  .../wireless/broadcom/brcm80211/brcmfmac/fwsignal.h|  9 +
>  .../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c|  3 ++-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  3 ++-
>  6 files changed, 31 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index 76693df34742..059e40fdc3d5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -232,9 +232,6 @@ void brcmf_dev_reset(struct device *dev);
>  /* Indication from bus module to change flow-control state */
>  void brcmf_txflowblock(struct device *dev, bool state);
>
> -/* Notify the bus has transferred the tx packet to firmware */
> -void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
> -
>  /* Configure the "global" bus state used by upper layers */
>  void brcmf_bus_change_state(struct brcmf_bus *bus, enum brcmf_bus_state 
> state);
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 2f2f3a5ad86a..45ed24049b37 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -393,24 +393,6 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct 
> sk_buff *txp, bool success)
> brcmu_pkt_buf_free_skb(txp);
>  }
>
> -void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success)
> -{
> -   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> -   struct brcmf_pub *drvr = bus_if->drvr;
> -   struct brcmf_if *ifp;
> -
> -   /* await txstatus signal for firmware if active */
> -   if (brcmf_fws_fc_active(drvr->fws)) {
> -   if (!success)
> -   brcmf_fws_bustxfail(drvr->fws, txp);
> -   } else {
> -   if (brcmf_proto_hdrpull(drvr, false, txp, ))
> -   brcmu_pkt_buf_free_skb(txp);
> -   else
> -   brcmf_txfinalize(ifp, txp, success);
> -   }
> -}
> -
>  static void brcmf_ethtool_get_drvinfo(struct net_device *ndev,
> struct ethtool_drvinfo *info)
>  {
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> index 5f1a5929cb30..07f0b3cfd59c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> @@ -2445,6 +2445,24 @@ bool brcmf_fws_fc_active(struct brcmf_fws_info *fws)
> return fws->fcmode != BRCMF_FWS_FCMODE_NONE;
>  }
>
> +void brcmf_fws_txcomplete(struct device *dev, struct sk_buff *txp, bool 
> success)
> +{
> +   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> +   struct brcmf_pub *drvr = bus_if->drvr;
> +   struct brcmf_if *ifp;
> +
> +   /* await txstatus signal for firmware if active */
> +   if (brcmf_fws_fc_active(drvr->fws)) {
> +   if (!success)
> +   brcmf_fws_bustxfail(drvr->fws, txp);
> +   } else {
> +   if (brcmf_proto_hdrpull(drvr, false, txp, ))
> +   brcmu_pkt_buf_free_skb(txp);
> +   else
> +   brcmf_txfinalize(ifp, txp, success);
> +   }
> +}
> +
>  void brcmf_fws_bustxfail(struct brcmf_fws_info *fws, struct sk_buff *skb)
>  {
> u32 hslot;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
> index 96df66073b2a..d534164785de 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
> @@ -18,6 +18,10 @@
>  #ifndef FWSIGNAL_H_
>  

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

[Peter Zijlstra]

On Fri, Mar 03, 2017 at 03:49:38PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote:
> > Right. The main purpose is to read/write _ONCE_. You can assume a somewhat
> > atomic access for sizes <= word size. And there are certainly places that
> > rely on that. But the *ONCE thing is mostly used for things where we used
> > barrier() 10 years ago.
> 
> A lot of code relies on READ/WRITE_ONCE() to generate single
> instructions for naturally aligned machined word sized loads/stores
> (something GCC used to guarantee, but does no longer IIRC).
> 
> So much so that I would say its a bug if READ/WRITE_ONCE() doesn't
> generate a single instruction under those conditions.
> 
> However, every time I've tried to introduce stricter
> semantics/primitives to verify things Linus hated it.

See here for the last attempt:

  https://marc.info/?l=linux-virtualization=148007765918101=2

RE: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[David Laight]

From: Andrey Ryabinin
> Sent: 03 March 2017 13:50
...
> noinline_iff_kasan might be a better name.  noinline_for_kasan gives the 
> impression
> that we always noinline function for the sake of kasan, while 
> noinline_iff_kasan
> clearly indicates that function is noinline only if kasan is used.

noinline_if_stackbloat

David

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[Andrey Ryabinin]

On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
> When CONFIG_KASAN is set, we can run into some code that uses incredible
> amounts of kernel stack:
> 
> drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes 
> is larger than 2048 bytes [-Werror=frame-larger-than=]
> drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 
> 94000 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
> 
> This happens when a sanitizer uses stack memory each time an inline function
> gets called. This introduces a new annotation for those functions to make
> them either 'inline' or 'noinline' dependning on the CONFIG_KASAN symbol.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  include/linux/compiler.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index f8110051188f..56b90897a459 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile 
> void *p, void *res, int s
>   */
>  #define noinline_for_stack noinline
>  
> +/*
> + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when
> + * one function gets inlined many times and each instance requires a stack
> + * ckeck.
> + */
> +#ifdef CONFIG_KASAN
> +#define noinline_for_kasan noinline __maybe_unused


noinline_iff_kasan might be a better name.  noinline_for_kasan gives the 
impression
that we always noinline function for the sake of kasan, while noinline_iff_kasan
clearly indicates that function is noinline only if kasan is used.

> +#else
> +#define noinline_for_kasan inline
> +#endif
> +
>  #ifndef __always_inline
>  #define __always_inline inline
>  #endif
> 

Re: [PATCH] cfg80211: support 4-way handshake offloading for WPA/WPA2-PSK

[Arend Van Spriel]

On 3-3-2017 13:21, Johannes Berg wrote:
> On Tue, 2017-02-28 at 12:06 +0100, Arend Van Spriel wrote:
>> On 21-2-2017 12:46, Johannes Berg wrote:
>>>
>> Would this work for you? We should have wpa_supplicant
>> support
>> too, but need to ask Andrei to look at that.

 Forgot to reply to this. Yes, this will work. Can come up with
 wpa_supp changes.
>>>
>>> No, we have them. Just need to see where they are :)
>>
>> Found anything ? :-p
> 
> Sorry, got too busy with other stuff.
> 
> +Andrei, can you send out the patches from Avi in wpa_s for doing the
> 4-way-HS offload (as an RFC)?
> 
> Arend, wait a bit - he's travelling now I think.

Having a day off today so I can wait. Actually made the WPA-PSK change
myself in wpa_supplicant. It is working with brcmfmac. I did not look at
1X yet as I do not have a radius server up and running.

Regards,
Arend

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

[Peter Zijlstra]

On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote:
> Right. The main purpose is to read/write _ONCE_. You can assume a somewhat
> atomic access for sizes <= word size. And there are certainly places that
> rely on that. But the *ONCE thing is mostly used for things where we used
> barrier() 10 years ago.

A lot of code relies on READ/WRITE_ONCE() to generate single
instructions for naturally aligned machined word sized loads/stores
(something GCC used to guarantee, but does no longer IIRC).

So much so that I would say its a bug if READ/WRITE_ONCE() doesn't
generate a single instruction under those conditions.

However, every time I've tried to introduce stricter
semantics/primitives to verify things Linus hated it.

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 4:22 PM, Andrey Ryabinin  wrote:
> On 03/03/2017 05:54 PM, Arnd Bergmann wrote:
>> On Fri, Mar 3, 2017 at 3:20 PM, Andrey Ryabinin  
>> wrote:
>>> On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
>>>
>>> This is kinda radical solution.
>>> Wouldn't be better to just increase -Wframe-larger-than for this driver 
>>> through Makefile?
>>
>> I thought about it too, and decided for disabling the driver entirely
>> since I suspected that
>> not only the per-function stack frame is overly large here but also
>> depth of the call chain,
>> which would then lead us to hiding an actual stack overflow.
>>
>
> No one complained so far ;)
> Disabling the driver like you did will throw it out from allmodconfig so it 
> will receive less compile-testing.

Good point, I'll add a driver specific flag then and leave it there.

>> Note that this driver is almost certainly broken, it hasn't seen any
>> updates other than
>> style and compile-warning fixes in 10 years and doesn't support any of
>> the hardware
>> introduced since 2002 (the company still makes PCIe ISDN adapters, but
>> the driver
>> only supports legacy PCI versions and older buses).
>
> Which means that it's unlikely that someone will run this driver with KASAN
and trigger stack overflow (if it's really possible).

True.

   Arnd

Re: [PATCH] cfg80211: support 4-way handshake offloading for WPA/WPA2-PSK

[Arend Van Spriel]

On 3-3-2017 13:20, Johannes Berg wrote:
> On Thu, 2017-02-23 at 16:26 +0530, Jithu Jance wrote:
>> On Thu, Feb 23, 2017 at 4:10 PM, Arend Van Spriel
>>  wrote:
>>>
>>> Ehm. Looking at the code in wpa_supplicant_event_assoc() it would
>>> be
>>> better to use NL80211_CMD_EAPOL_PORT_VALID event to cover both
>>> WPA/WPA2-PSK and 8021X.
>>
>> Yes. IMHO, the assoc/reassoc ind should move the state to
>> WPA_ASSOCIATED and a separate event like
>> NL80211_CMD_EAPOL_PORT_VALID/AUTHORIZED should move the connection
>> state to WPA_COMPLETED.
> 
> That seems reasonable.
> 
> Avi just looked also at distinguishing if/when fresh 1X authentication
> is required, particularly with roaming. For that, he's suggesting to
> add a flag AUTHORIZED to the ROAMED event.
> 
> We could, possibly, have a PORT_AUTHORIZED event for that as well, but
> it'd be more complicated, since then you'd have to wait for that and if
> it doesn't come time out - or we'd need a "PORT_UNAUTHORIZED" or
> "PLEASE_START_1X" instead? None of that really seems like such a great
> idea.
> 
> Perhaps instead it'd make sense to instead include the new AUTHORIZED
> flag in the CONNECT_RESULT as well, if authorized? I basically see 3
> valid cases:
> 
>  * connection successful with authorized port
>  * connection successful with need for 1X handshake (non-offloaded)
>  * connection failed
> 
> Why should we have the case of
>  * association successful but 4-way-HS failed
> 
> separately?

I suppose there is no functional behavior that needs to done upon
association regardless 4-way HS result, ie. obtaining assoc ie info is
only useful if 4-way HS succeeds. I agree using the flag should be
sufficient.

Regards,
Arend

Re: [PATCH 26/26] kasan: rework Kconfig settings

[Andrey Ryabinin]

On 03/02/2017 07:38 PM, Arnd Bergmann wrote:

> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 97d62c2da6c2..27c838c40a36 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -216,10 +216,9 @@ config ENABLE_MUST_CHECK
>  config FRAME_WARN
>   int "Warn for stack frames larger than (needs gcc 4.4)"
>   range 0 8192
> - default 0 if KASAN
> - default 2048 if GCC_PLUGIN_LATENT_ENTROPY
> + default 3072 if KASAN_EXTRA
>   default 1024 if !64BIT
> - default 2048 if 64BIT
> + default 1280 if 64BIT

This looks unrelated. Also, it means that now we have 1280 with KASAN=y && 
KASAN_EXTRA=n.
Judging from changelog I assume that this hunk slipped here from the follow up 
series.

>   help
> Tell gcc to warn at build time for stack frames larger than this.
> Setting this too low will cause a lot of warnings.
> @@ -499,7 +498,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT
>  
>  config DEBUG_SLAB
>   bool "Debug slab memory allocations"
> - depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
> + depends on DEBUG_KERNEL && SLAB && !KMEMCHECK && !KASAN
>   help
> Say Y here to have the kernel do limited verification on memory
> allocation as well as poisoning memory on free to catch use of freed
> @@ -511,7 +510,7 @@ config DEBUG_SLAB_LEAK
>  
>  config SLUB_DEBUG_ON
>   bool "SLUB debugging on by default"
> - depends on SLUB && SLUB_DEBUG && !KMEMCHECK
> + depends on SLUB && SLUB_DEBUG && !KMEMCHECK && !KASAN

Why? SLUB_DEBUG_ON works with KASAN.

>   default n
>   help
> Boot with debugging on by default. SLUB boots by default with

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

[Andrey Ryabinin]

On 03/03/2017 05:54 PM, Arnd Bergmann wrote:
> On Fri, Mar 3, 2017 at 3:20 PM, Andrey Ryabinin  
> wrote:
>>
>>
>> On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
>>> When CONFIG_KASAN is enabled, we have several functions that use rather
>>> large kernel stacks, e.g.
>>>
>>> drivers/isdn/hardware/eicon/message.c: In function 'group_optimization':
>>> drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame size of 
>>> 864 bytes is larger than 500 bytes [-Wframe-larger-than=]
>>> drivers/isdn/hardware/eicon/message.c: In function 'add_b1':
>>> drivers/isdn/hardware/eicon/message.c:7925:1: warning: the frame size of 
>>> 1008 bytes is larger than 500 bytes [-Wframe-larger-than=]
>>> drivers/isdn/hardware/eicon/message.c: In function 'add_b23':
>>> drivers/isdn/hardware/eicon/message.c:8551:1: warning: the frame size of 
>>> 928 bytes is larger than 500 bytes [-Wframe-larger-than=]
>>> drivers/isdn/hardware/eicon/message.c: In function 'sig_ind':
>>> drivers/isdn/hardware/eicon/message.c:6113:1: warning: the frame size of 
>>> 2112 bytes is larger than 500 bytes [-Wframe-larger-than=]
>>>
>>> To be on the safe side, and to enable a lower frame size warning limit, 
>>> let's
>>> just mark this driver as broken when KASAN is in use. I have tried to reduce
>>> the stack size as I did with dozens of other drivers, but failed to come up
>>> with a good solution for this one.
>>>
>>
>> This is kinda radical solution.
>> Wouldn't be better to just increase -Wframe-larger-than for this driver 
>> through Makefile?
> 
> I thought about it too, and decided for disabling the driver entirely
> since I suspected that
> not only the per-function stack frame is overly large here but also
> depth of the call chain,
> which would then lead us to hiding an actual stack overflow.
> 

No one complained so far ;)
Disabling the driver like you did will throw it out from allmodconfig so it 
will receive less compile-testing.


> Note that this driver is almost certainly broken, it hasn't seen any
> updates other than
> style and compile-warning fixes in 10 years and doesn't support any of
> the hardware
> introduced since 2002 (the company still makes PCIe ISDN adapters, but
> the driver
> only supports legacy PCI versions and older buses).

Which means that it's unlikely that someone will run this driver with KASAN and 
trigger stack overflow (if it's really possible).

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 3:33 PM, Alexander Potapenko  wrote:
> On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann  wrote:
>> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko  
>> wrote:
>>
>> Would KMSAN also force local variables to be non-overlapping the way that
>> asan-stack=1 and -fsanitize-address-use-after-scope do? As I understood it,
>> KMSAN would add extra code for maintaining the uninit bits, but in an example
>> like this
> The thing is that KMSAN (and other tools that insert heavyweight
> instrumentation) may cause heavy register spilling which will also
> blow up the stack frames.

In that case, I would expect a mostly distinct set of functions to have large
stack frames with KMSAN, compared to the ones that need
noinline_for_kasan. In most cases I patched, the called inline function is
actually trivial, but invoked many times from the same caller.

 Arnd

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 3:20 PM, Andrey Ryabinin  wrote:
>
>
> On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
>> When CONFIG_KASAN is enabled, we have several functions that use rather
>> large kernel stacks, e.g.
>>
>> drivers/isdn/hardware/eicon/message.c: In function 'group_optimization':
>> drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame size of 
>> 864 bytes is larger than 500 bytes [-Wframe-larger-than=]
>> drivers/isdn/hardware/eicon/message.c: In function 'add_b1':
>> drivers/isdn/hardware/eicon/message.c:7925:1: warning: the frame size of 
>> 1008 bytes is larger than 500 bytes [-Wframe-larger-than=]
>> drivers/isdn/hardware/eicon/message.c: In function 'add_b23':
>> drivers/isdn/hardware/eicon/message.c:8551:1: warning: the frame size of 928 
>> bytes is larger than 500 bytes [-Wframe-larger-than=]
>> drivers/isdn/hardware/eicon/message.c: In function 'sig_ind':
>> drivers/isdn/hardware/eicon/message.c:6113:1: warning: the frame size of 
>> 2112 bytes is larger than 500 bytes [-Wframe-larger-than=]
>>
>> To be on the safe side, and to enable a lower frame size warning limit, let's
>> just mark this driver as broken when KASAN is in use. I have tried to reduce
>> the stack size as I did with dozens of other drivers, but failed to come up
>> with a good solution for this one.
>>
>
> This is kinda radical solution.
> Wouldn't be better to just increase -Wframe-larger-than for this driver 
> through Makefile?

I thought about it too, and decided for disabling the driver entirely
since I suspected that
not only the per-function stack frame is overly large here but also
depth of the call chain,
which would then lead us to hiding an actual stack overflow.

Note that this driver is almost certainly broken, it hasn't seen any
updates other than
style and compile-warning fixes in 10 years and doesn't support any of
the hardware
introduced since 2002 (the company still makes PCIe ISDN adapters, but
the driver
only supports legacy PCI versions and older buses).

Arnd

Re: [PATCH 26/26] kasan: rework Kconfig settings

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 3:51 PM, Andrey Ryabinin  wrote:
>
>
> On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
>
>>
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 97d62c2da6c2..27c838c40a36 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -216,10 +216,9 @@ config ENABLE_MUST_CHECK
>>  config FRAME_WARN
>>   int "Warn for stack frames larger than (needs gcc 4.4)"
>>   range 0 8192
>> - default 0 if KASAN
>> - default 2048 if GCC_PLUGIN_LATENT_ENTROPY
>> + default 3072 if KASAN_EXTRA
>>   default 1024 if !64BIT
>> - default 2048 if 64BIT
>> + default 1280 if 64BIT
>
> This looks unrelated. Also, it means that now we have 1280 with KASAN=y && 
> KASAN_EXTRA=n.
> Judging from changelog I assume that this hunk slipped here from the follow 
> up series.

Right, this slipped in by accident, I've already fixed it up locally.

>>   help
>> Tell gcc to warn at build time for stack frames larger than this.
>> Setting this too low will cause a lot of warnings.
>> @@ -499,7 +498,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT
>>
>>  config DEBUG_SLAB
>>   bool "Debug slab memory allocations"
>> - depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
>> + depends on DEBUG_KERNEL && SLAB && !KMEMCHECK && !KASAN
>>   help
>> Say Y here to have the kernel do limited verification on memory
>> allocation as well as poisoning memory on free to catch use of freed
>> @@ -511,7 +510,7 @@ config DEBUG_SLAB_LEAK
>>
>>  config SLUB_DEBUG_ON
>>   bool "SLUB debugging on by default"
>> - depends on SLUB && SLUB_DEBUG && !KMEMCHECK
>> + depends on SLUB && SLUB_DEBUG && !KMEMCHECK && !KASAN
>
> Why? SLUB_DEBUG_ON works with KASAN.

Ok, will fix. I wrongly guessed that kmemcheck and kasan had the
same reason for the two dependencies here.

Arnd

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[Alexander Potapenko]

On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann  wrote:
> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko  wrote:
>> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin  
>> wrote:
>
 @@ -416,6 +416,17 @@ static __always_inline void 
 __write_once_size(volatile void *p, void *res, int s
   */
  #define noinline_for_stack noinline

 +/*
 + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when
 + * one function gets inlined many times and each instance requires a stack
 + * ckeck.
 + */
 +#ifdef CONFIG_KASAN
 +#define noinline_for_kasan noinline __maybe_unused
>>>
>>>
>>> noinline_iff_kasan might be a better name.  noinline_for_kasan gives the 
>>> impression
>>> that we always noinline function for the sake of kasan, while 
>>> noinline_iff_kasan
>>> clearly indicates that function is noinline only if kasan is used.
>
> Fine with me. I actually tried to come up with a name that implies that the
> symbol is actually "inline" (or even __always_inline_ without KASAN, but
> couldn't think of any good name for it.
>
>> FWIW we may be facing the same problem with other compiler-based
>> tools, e.g. KMSAN (which isn't there yet).
>> So it might be better to choose a macro name that doesn't use the name 
>> "KASAN".
>> E.g. noinline_iff_memtool (or noinline_iff_memory_tool if that's not too 
>> long).
>> WDYT?
>
> Would KMSAN also force local variables to be non-overlapping the way that
> asan-stack=1 and -fsanitize-address-use-after-scope do? As I understood it,
> KMSAN would add extra code for maintaining the uninit bits, but in an example
> like this
The thing is that KMSAN (and other tools that insert heavyweight
instrumentation) may cause heavy register spilling which will also
blow up the stack frames.
> int f(int *);
> static inline __attribute__((always_inline)) int g(void)
> {
> int i;
> f();
> return i;
> }
> int f(void)
> {
>  return g()+g()+g()+g();
> }
>
> each of the four copies of 'i' could have the same location on the stack
> and get marked uninitialized again before calling f(). We only need
> noinline_for_kasan (whatever we end up calling that) for compiler
> features that force each instance of 'i' to have its own stack redzone.
>
>  Arnd



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko  wrote:
> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin  
> wrote:

>>> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile 
>>> void *p, void *res, int s
>>>   */
>>>  #define noinline_for_stack noinline
>>>
>>> +/*
>>> + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when
>>> + * one function gets inlined many times and each instance requires a stack
>>> + * ckeck.
>>> + */
>>> +#ifdef CONFIG_KASAN
>>> +#define noinline_for_kasan noinline __maybe_unused
>>
>>
>> noinline_iff_kasan might be a better name.  noinline_for_kasan gives the 
>> impression
>> that we always noinline function for the sake of kasan, while 
>> noinline_iff_kasan
>> clearly indicates that function is noinline only if kasan is used.

Fine with me. I actually tried to come up with a name that implies that the
symbol is actually "inline" (or even __always_inline_ without KASAN, but
couldn't think of any good name for it.

> FWIW we may be facing the same problem with other compiler-based
> tools, e.g. KMSAN (which isn't there yet).
> So it might be better to choose a macro name that doesn't use the name 
> "KASAN".
> E.g. noinline_iff_memtool (or noinline_iff_memory_tool if that's not too 
> long).
> WDYT?

Would KMSAN also force local variables to be non-overlapping the way that
asan-stack=1 and -fsanitize-address-use-after-scope do? As I understood it,
KMSAN would add extra code for maintaining the uninit bits, but in an example
like this

int f(int *);
static inline __attribute__((always_inline)) int g(void)
{
int i;
f();
return i;
}
int f(void)
{
 return g()+g()+g()+g();
}

each of the four copies of 'i' could have the same location on the stack
and get marked uninitialized again before calling f(). We only need
noinline_for_kasan (whatever we end up calling that) for compiler
features that force each instance of 'i' to have its own stack redzone.

 Arnd

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

[Andrey Ryabinin]

On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
> When CONFIG_KASAN is enabled, we have several functions that use rather
> large kernel stacks, e.g.
> 
> drivers/isdn/hardware/eicon/message.c: In function 'group_optimization':
> drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame size of 864 
> bytes is larger than 500 bytes [-Wframe-larger-than=]
> drivers/isdn/hardware/eicon/message.c: In function 'add_b1':
> drivers/isdn/hardware/eicon/message.c:7925:1: warning: the frame size of 1008 
> bytes is larger than 500 bytes [-Wframe-larger-than=]
> drivers/isdn/hardware/eicon/message.c: In function 'add_b23':
> drivers/isdn/hardware/eicon/message.c:8551:1: warning: the frame size of 928 
> bytes is larger than 500 bytes [-Wframe-larger-than=]
> drivers/isdn/hardware/eicon/message.c: In function 'sig_ind':
> drivers/isdn/hardware/eicon/message.c:6113:1: warning: the frame size of 2112 
> bytes is larger than 500 bytes [-Wframe-larger-than=]
> 
> To be on the safe side, and to enable a lower frame size warning limit, let's
> just mark this driver as broken when KASAN is in use. I have tried to reduce
> the stack size as I did with dozens of other drivers, but failed to come up
> with a good solution for this one.
> 

This is kinda radical solution.
Wouldn't be better to just increase -Wframe-larger-than for this driver through 
Makefile?



> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/isdn/hardware/eicon/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/isdn/hardware/eicon/Kconfig 
> b/drivers/isdn/hardware/eicon/Kconfig
> index 6082b6a5ced3..b64496062421 100644
> --- a/drivers/isdn/hardware/eicon/Kconfig
> +++ b/drivers/isdn/hardware/eicon/Kconfig
> @@ -31,6 +31,7 @@ config ISDN_DIVAS_PRIPCI
>  
>  config ISDN_DIVAS_DIVACAPI
>   tristate "DIVA CAPI2.0 interface support"
> + depends on !KASAN || BROKEN
>   help
> You need this to provide the CAPI interface
> for DIVA Server cards.
> 

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[Alexander Potapenko]

On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin  wrote:
>
>
> On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
>> When CONFIG_KASAN is set, we can run into some code that uses incredible
>> amounts of kernel stack:
>>
>> drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes 
>> is larger than 2048 bytes [-Werror=frame-larger-than=]
>> drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 
>> 94000 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>> drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
>> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
>>
>> This happens when a sanitizer uses stack memory each time an inline function
>> gets called. This introduces a new annotation for those functions to make
>> them either 'inline' or 'noinline' dependning on the CONFIG_KASAN symbol.
>>
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  include/linux/compiler.h | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> index f8110051188f..56b90897a459 100644
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile 
>> void *p, void *res, int s
>>   */
>>  #define noinline_for_stack noinline
>>
>> +/*
>> + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when
>> + * one function gets inlined many times and each instance requires a stack
>> + * ckeck.
>> + */
>> +#ifdef CONFIG_KASAN
>> +#define noinline_for_kasan noinline __maybe_unused
>
>
> noinline_iff_kasan might be a better name.  noinline_for_kasan gives the 
> impression
> that we always noinline function for the sake of kasan, while 
> noinline_iff_kasan
> clearly indicates that function is noinline only if kasan is used.
FWIW we may be facing the same problem with other compiler-based
tools, e.g. KMSAN (which isn't there yet).
So it might be better to choose a macro name that doesn't use the name "KASAN".
E.g. noinline_iff_memtool (or noinline_iff_memory_tool if that's not too long).
WDYT?
>> +#else
>> +#define noinline_for_kasan inline
>> +#endif
>> +
>>  #ifndef __always_inline
>>  #define __always_inline inline
>>  #endif
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kasan-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kasan-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kasan-dev/7e7a62de-3b79-6044-72fa-4ade418953d1%40virtuozzo.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Re: [PATCH 4.12] bcma: drop unneeded check for CONFIG_OF_IRQ

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 11:33 AM, Rafał Miłecki  wrote:
> From: Rafał Miłecki 
>
> We already have the same check in bcma_of_get_irq which really calls
> symbols available with CONFIG_OF_IRQ only. It appears this duplicated
> check was accidentally added in commit c58d900cc96a ("bcma: fix building
> without OF_IRQ"). The rest of code in bcma_of_fill_device should work
> fine without CONFIG_OF_IRQ.
>
> Signed-off-by: Rafał Miłecki 

Acked-by: Arnd Bergmann 

Re: [RFC] cfg80211: Add support for FILS shared key authentication offload

[Johannes Berg]

>  struct cfg80211_pmksa {
>   const u8 *bssid;
>   const u8 *pmkid;
> + const u8 *pmk;
> + size_t pmk_len;
> + const u8 *ssid;
> + size_t ssid_len;
> + u16 cache_id;
>  };

So how does that work - from a flow perspective?

> +void cfg80211_connect_done(struct net_device *dev, const u8 *bssid,
> +    struct cfg80211_bss *bss, const u8
> *req_ie,
> +    size_t req_ie_len, const u8 *resp_ie,
> +    size_t resp_ie_len, const u8 *fils_kek,
> +    size_t fils_kek_len, bool
> update_erp_seq_num,
> +    u16 fils_erp_seq_num, const u8 *pmk,
> size_t pmk_len,
> +    const u8 *pmkid, int status, gfp_t gfp,
> +    enum nl80211_timeout_reason
> timeout_reason);

Ouch. Please declare most of those (perhaps other than dev) as a
structure and pass a pointer here.

Also, why require the BSSID when BSS is set? Seems you could say one or
the other.

Also, what do you need the PMK for? If you have all of this stuff
offloaded, why does the host need to know the PMK?

> @@ -227,6 +227,13 @@ struct cfg80211_event {
>   size_t req_ie_len;
>   size_t resp_ie_len;
>   struct cfg80211_bss *bss;
> + const u8 *kek;
> + size_t kek_len;
> + bool update_erp_seq_num;
> + u16 fils_erp_seq_num;
> + const u8 *pmk;
> + size_t pmk_len;
> + const u8 *pmkid;
>   int status; /* -1 = failed; 0..65535 =
> status code */
>   enum nl80211_timeout_reason timeout_reason;
>   } cr;

Could probably use the new struct from cfg80211.h that I asked to add
here then.


Other than that, most of the patch seems mechanical - I think it'd be
good to have a DOC: section or so somewhere (nl80211.h?) that explains
how this is intended to be used? I've already migrated the
documentation to the new rst/sphinx format so we can generate it nicely
and that would be a good addition - I'll probably do some more
additions too.

johannes

Re: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Johannes Berg]

> There is a field, no_80211_encap, added to ieee80211_tx_info:control
> to mark if the 802.11 encapsulation is offloaded to driver.

Why is that needed? Since you have a separate TX path (ndo_start_xmit),
wouldn't it make more sense to call into a drv_tx_8023() or something
like that instead?

> There is also a new callback for tx completion status indication
> to handle data frames using 802.11 encap offload.

Maybe you could just use _noskb?

Haven't really looked at the rest all that much, few comments:

 * not sure you're handling non-linear frames right, are you assuming
   the driver can handle them? probably a fair assumption, but should
   be documented
 * you seem to also be assuming that the driver not only does all
   encryption in HW (which is obviously needed) but also does all the
   key lookups etc. - also seems fair, but also should be documented
 * similarly for a lot of other (all?) fields in tx_info
 * you seem to be assuming that if encap offload is supported then it's
   also *desired* for AP/VLAN and client interfaces, if not 4-addr.
   This seems ... probably about right, but if drivers don't always
   support it? Or support it in more cases? Perhaps we can move the
   SUPPORTS_80211_ENCAP flag into a VIF flag instead, so they can do it
   more fine-grained?

johannes

Re: [RFCv2 1/2] mac80211: Add provision for 802.11 encap offload

[Johannes Berg]

On Fri, 2017-03-03 at 17:03 +0530, mpubb...@qti.qualcomm.com wrote:
> From: Vasanthakumar Thiagarajan 
> 
> Drivers can have the capability to offload 802.11 encap
> to firmware or hardware for data frames. This patch adds a new
> hw_flag for driver to advertise the offload support.
> Transmit path offloading 802.11 header (including cipher headers)
> encap for data frames will be implemented in a separate patch.
> 
> Drivers advertising this capability should also implement other
> functionalities which deal with 802.11 frame format like below
> 
> - Hardware encryption
> - Aggregation of A-MSDU offload
> - Fragmentation offload

Not much point in having this as a separate patch, but this
documentation paragraph should move into the documentation for the new
flag in mac80211.h

johannes

Re: [PATCH] cfg80211: support 4-way handshake offloading for WPA/WPA2-PSK

[Johannes Berg]

On Thu, 2017-02-23 at 16:26 +0530, Jithu Jance wrote:
> On Thu, Feb 23, 2017 at 4:10 PM, Arend Van Spriel
>  wrote:
> > 
> > Ehm. Looking at the code in wpa_supplicant_event_assoc() it would
> > be
> > better to use NL80211_CMD_EAPOL_PORT_VALID event to cover both
> > WPA/WPA2-PSK and 8021X.
> 
> Yes. IMHO, the assoc/reassoc ind should move the state to
> WPA_ASSOCIATED and a separate event like
> NL80211_CMD_EAPOL_PORT_VALID/AUTHORIZED should move the connection
> state to WPA_COMPLETED.

That seems reasonable.

Avi just looked also at distinguishing if/when fresh 1X authentication
is required, particularly with roaming. For that, he's suggesting to
add a flag AUTHORIZED to the ROAMED event.

We could, possibly, have a PORT_AUTHORIZED event for that as well, but
it'd be more complicated, since then you'd have to wait for that and if
it doesn't come time out - or we'd need a "PORT_UNAUTHORIZED" or
"PLEASE_START_1X" instead? None of that really seems like such a great
idea.

Perhaps instead it'd make sense to instead include the new AUTHORIZED
flag in the CONNECT_RESULT as well, if authorized? I basically see 3
valid cases:

 * connection successful with authorized port
 * connection successful with need for 1X handshake (non-offloaded)
 * connection failed

Why should we have the case of
 * association successful but 4-way-HS failed

separately?

johannes

Re: [PATCH v2] mac80211: mesh - always do every discovery retry

[Chun-Yeow Yeoh]

>
> Yes, that is a real issue. We are planning on doing some further work in
> this area to  try to minimize the explosions that can be seen with PREQs in
> larger networks while balancing the need for reliability.
>
> Path discovery
>> should stop once the path is established. By attempting 2nd, 3rd or 4th
>> doesn't guarantee the next path will be "good".
>
> It doesn't guarantee anything of course but it does raise the probability
> that the right path will be found. For example take four nodes in a ring
> where the A-B, B-C, C-D links are all good but the A-D link is poor. Poor
> enough that the higher data rates are hosed for that link but the basic rate
> used by management frames is relatively unaffected. If we assume that the
> reliability of management frames is 90% then in order for A to route to D it
> needs to get a PREQ to D and a PREP back. It has two options 1) for A-D the
> reliability will be 0.9^2 = 81% 2) for A-B-C-D the reliability will be 0.9^6
> = 53%.

What is round trip delay between A-D compared to A-B-C-D? 1 hop away
the throughput is reduced by half. Also if you have more nodes using
longer path, you consume more airtime leads to really bad network
performance, especially when B, C, or even D wants to start initial
data transmission.

> This isn't a good situation because it makes it much too easy for routing to
> pick a *really* bad path. And we have seen reliability improvements with
> this patch.
>
> We have already made changes to dial way back on the number of PREQs sent
> out so this patch made quite a bit of sense for us. In the default
> configuration where PREQs go out every 4s I don't think we have a good
> solution: picking a bad path, even for 4s, can be a horrible user experience

Reduce dot11MeshHWMPpreqMinInterval to send out more PREQ in your network.

> but PREQ volumes quickly start consuming too much airtime as network sizes
> increase.

One way of improving the path is either enhancing the airtime link
metric by considering the factor that you mentioned in or else
introducing vendor-specific path metric. Sending more broadcast frames
over the network won't be a good solution.

---
Chun-Yeow

Re: [PATCH 00/26] bring back stack frame warning with KASAN

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 1:25 PM, Alexander Potapenko  wrote:
> On Thu, Mar 2, 2017 at 5:38 PM, Arnd Bergmann  wrote:
>> It took a long while to get this done, but I'm finally ready
>> to send the first half of the KASAN stack size patches that
>> I did in response to the kernelci.org warnings.
>>
>> As before, it's worth mentioning that things are generally worse
>> with gcc-7.0.1 because of the addition of -fsanitize-address-use-after-scope
>> that are not present on kernelci, so my randconfig testing found
>> a lot more than kernelci did.
>>
>> The main areas are:
>>
>> - READ_ONCE/WRITE_ONCE cause problems in lots of code
>> - typecheck() causes huge problems in a few places
>> - I'm introducing "noinline_for_kasan" and use it in a lot
>>   of places that suffer from inline functions with local variables
>>   - netlink, as used in various parts of the kernel
>>   - a number of drivers/media drivers
>>   - a handful of wireless network drivers
>> - kmemcheck conflicts with -fsanitize-address-use-after-scope
>>
>> This series lets us add back a stack frame warning for 3072 bytes
>> with -fsanitize-address-use-after-scope, or 2048 bytes without it.
>>
>> I have a follow-up series that further reduces the stack frame
>> warning limit to 1280 bytes for all 64-bit architectures, and
>> 1536 bytes with basic KASAN support (no -fsanitize-address-use-after-scope).
>> For now, I'm only posting the first half, in order to keep
>> it (barely) reviewable.
>
> Can you please elaborate on why do you need this? Are you trying to
> squeeze KASAN into some embedded device?
> Noinlines sprayed over the codebase are hard to maintain, and certain
> compiler changes may cause bloated stack frames in other places.
> Maybe it should be enough to just increase the stack frame limit in
> KASAN builds, as Dmitry suggested previously?

The current state of mainline has doubled the kernel stack size with
KASAN, and completely turned off the warning for per-function
stack frames. In some cases, this is completely broken as we have
functions that exceed even the 32kb per-thread stacks by themselves,
so I want to turn on the warning again and fix all the outliers.

The hard part is deciding what size is reasonable for a given function,
as smaller limits cause more harmless warnings while larger limits
can hide more actual problems. Before running into the KASAN
problem, I had already determined that we can lower the warning
limit for 64-bit architectures from 2048 bytes to 1280 with just
a handful of patches that are generally a good cleanup anyway.

This led me to picking three separate warning limits, based on
what I found reasonable to work around in the code:

3072 bytes with -fsanitize-address-use-after-scope
1536 bytes with KASAN but without -fsanitize-address-use-after-scope
1280 bytes on 64-bit without KASAN
1024 bytes on 32-bit architectures

If we use higher limits, the patch series will get a bit shorter. For
the limits above, I needed a total of 51 patches, while this shorter
series of 26 patches has slightly laxer limits:

3072 bytes with -fsanitize-address-use-after-scope
2048 bytes on 64-bit architectures with or without KASAN, but
  without  -fsanitize-address-use-after-scope
1024 bytes on 32-bit architectures

The individual patches should list the highest frame size I ran
into, so I can try to reduce the number of patches if you have
a suggestion for a different set of limits.

   Arnd

[PATCH] mac80211: Use setup_timer instead of init_timer

[Jiri Slaby]

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.

Signed-off-by: Ondřej Lysoněk 
Signed-off-by: Jiri Slaby 
Cc: Johannes Berg 
Cc: "David S. Miller" 
Cc: 
Cc: 
---
 net/mac80211/agg-rx.c | 12 ++--
 net/mac80211/agg-tx.c | 12 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 4456559cb056..1b7a4daf283c 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -357,14 +357,14 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
spin_lock_init(_agg_rx->reorder_lock);
 
/* rx timer */
-   tid_agg_rx->session_timer.function = sta_rx_agg_session_timer_expired;
-   tid_agg_rx->session_timer.data = (unsigned long)>timer_to_tid[tid];
-   init_timer_deferrable(_agg_rx->session_timer);
+   setup_deferrable_timer(_agg_rx->session_timer,
+  sta_rx_agg_session_timer_expired,
+  (unsigned long)>timer_to_tid[tid]);
 
/* rx reorder timer */
-   tid_agg_rx->reorder_timer.function = sta_rx_agg_reorder_timer_expired;
-   tid_agg_rx->reorder_timer.data = (unsigned long)>timer_to_tid[tid];
-   init_timer(_agg_rx->reorder_timer);
+   setup_timer(_agg_rx->reorder_timer,
+   sta_rx_agg_reorder_timer_expired,
+   (unsigned long)>timer_to_tid[tid]);
 
/* prepare reordering buffer */
tid_agg_rx->reorder_buf =
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 45319cc01121..60e2a62f7bef 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -670,14 +670,14 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta 
*pubsta, u16 tid,
tid_tx->timeout = timeout;
 
/* response timer */
-   tid_tx->addba_resp_timer.function = sta_addba_resp_timer_expired;
-   tid_tx->addba_resp_timer.data = (unsigned long)>timer_to_tid[tid];
-   init_timer(_tx->addba_resp_timer);
+   setup_timer(_tx->addba_resp_timer,
+   sta_addba_resp_timer_expired,
+   (unsigned long)>timer_to_tid[tid]);
 
/* tx timer */
-   tid_tx->session_timer.function = sta_tx_agg_session_timer_expired;
-   tid_tx->session_timer.data = (unsigned long)>timer_to_tid[tid];
-   init_timer_deferrable(_tx->session_timer);
+   setup_deferrable_timer(_tx->session_timer,
+  sta_tx_agg_session_timer_expired,
+  (unsigned long)>timer_to_tid[tid]);
 
/* assign a dialog token */
sta->ampdu_mlme.dialog_token_allocator++;
-- 
2.12.0

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

[Christian Borntraeger]

On 03/02/2017 10:45 PM, Arnd Bergmann wrote:
> On Thu, Mar 2, 2017 at 8:00 PM, Christian Borntraeger
>  wrote:
>> On 03/02/2017 06:55 PM, Arnd Bergmann wrote:
>>> On Thu, Mar 2, 2017 at 5:51 PM, Christian Borntraeger
>>>  wrote:
 On 03/02/2017 05:38 PM, Arnd Bergmann wrote:
>
> This attempts a rewrite of the two macros, using a simpler implementation
> for the most common case of having a naturally aligned 1, 2, 4, or (on
> 64-bit architectures) 8  byte object that can be accessed with a single
> instruction.  For these, we go back to a volatile pointer dereference
> that we had with the ACCESS_ONCE macro.

 We had changed that back then because gcc 4.6 and 4.7 had a bug that could
 removed the volatile statement on aggregate types like the following one

 union ipte_control {
 unsigned long val;
 struct {
 unsigned long k  : 1;
 unsigned long kh : 31;
 unsigned long kg : 32;
 };
 };

 See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

 If I see that right, your __ALIGNED_WORD(x)
 macro would say that for above structure  sizeof(x) == sizeof(long)) is 
 true,
 so it would fall back to the old volatile cast and might reintroduce the
 old compiler bug?
>>
>> Oh dear, I should double check my sentences in emails before sending...anyway
>> the full story is referenced in
>>
>> commit 60815cf2e05057db5b78e398d9734c493560b11e
>> Merge tag 'for-linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux
>> which has a pointer to
>> http://marc.info/?i=54611D86.4040306%40de.ibm.com
>> which contains the full story.
> 
> Ok, got it. So I guess the behavior of forcing aligned accesses on aligned
> data is accidental, and allowing non-power-of-two arguments is also not
> the main purpose.


Right. The main purpose is to read/write _ONCE_. You can assume a somewhat
atomic access for sizes <= word size. And there are certainly places that
rely on that. But the *ONCE thing is mostly used for things where we used
barrier() 10 years ago.


 Maybe we could just bail out on new compilers if we get
> either of those? That might catch code that accidentally does something
> that is inherently non-atomic or that causes a trap when the intention was
> to have a simple atomic access.

I think Linus stated that its ok to assume that the compiler is smart enough 
to uses a single instruction to access aligned and properly sized scalar types
for *ONCE.

Back then when I changed ACCESS_ONCE there were many places that did use it
for non-atomic, > word size accesses. For example on some architectures a pmd_t
is a typedef to an array, for which there is no way to read that atomically.
So the focus must be on the "ONCE" part.

If some code uses a properly aligned, word sized object we can also assume 
atomic access. If the access is not properly sized/aligned we do not get
atomicity, but we do get the "ONCE".
But adding a check for alignment/size would break the compilation of some
code.

Re: [PATCH 00/26] bring back stack frame warning with KASAN

[Alexander Potapenko]

On Thu, Mar 2, 2017 at 5:38 PM, Arnd Bergmann  wrote:
> It took a long while to get this done, but I'm finally ready
> to send the first half of the KASAN stack size patches that
> I did in response to the kernelci.org warnings.
>
> As before, it's worth mentioning that things are generally worse
> with gcc-7.0.1 because of the addition of -fsanitize-address-use-after-scope
> that are not present on kernelci, so my randconfig testing found
> a lot more than kernelci did.
>
> The main areas are:
>
> - READ_ONCE/WRITE_ONCE cause problems in lots of code
> - typecheck() causes huge problems in a few places
> - I'm introducing "noinline_for_kasan" and use it in a lot
>   of places that suffer from inline functions with local variables
>   - netlink, as used in various parts of the kernel
>   - a number of drivers/media drivers
>   - a handful of wireless network drivers
> - kmemcheck conflicts with -fsanitize-address-use-after-scope
>
> This series lets us add back a stack frame warning for 3072 bytes
> with -fsanitize-address-use-after-scope, or 2048 bytes without it.
>
> I have a follow-up series that further reduces the stack frame
> warning limit to 1280 bytes for all 64-bit architectures, and
> 1536 bytes with basic KASAN support (no -fsanitize-address-use-after-scope).
> For now, I'm only posting the first half, in order to keep
> it (barely) reviewable.
Can you please elaborate on why do you need this? Are you trying to
squeeze KASAN into some embedded device?
Noinlines sprayed over the codebase are hard to maintain, and certain
compiler changes may cause bloated stack frames in other places.
Maybe it should be enough to just increase the stack frame limit in
KASAN builds, as Dmitry suggested previously?
> Both series are tested with many hundred randconfig builds on both
> x86 and arm64, which are the only architectures supporting KASAN.
>
> Arnd
>
>  [PATCH 01/26] compiler: introduce noinline_for_kasan annotation
>  [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
>  [PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro
>  [PATCH 04/26] tty: kbd: reduce stack size with KASAN
>  [PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan
>  [PATCH 06/26] rocker: mark rocker_tlv_put_* functions as
>  [PATCH 07/26] brcmsmac: reduce stack size with KASAN
>  [PATCH 08/26] brcmsmac: make some local variables 'static const' to
>  [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy
>  [PATCH 10/26] brcmsmac: reindent split functions
>  [PATCH 11/26] rtlwifi: reduce stack usage for KASAN
>  [PATCH 12/26] wl3501_cs: reduce stack size for KASAN
>  [PATCH 13/26] rtl8180: reduce stack size for KASAN
>  [PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access
>  [PATCH 15/26] [media] tuners: i2c: reduce stack usage for
>  [PATCH 16/26] [media] i2c: adv7604: mark register access as
>  [PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN
>  [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN
>  [PATCH 19/26] [media] r820t: mark register functions as
>  [PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce
>  [PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN
>  [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with
>  [PATCH 23/26] mtd: cfi: reduce stack size with KASAN
>  [PATCH 24/26] ocfs2: reduce stack size with KASAN
>  [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan
>  [PATCH 26/26] kasan: rework Kconfig settings
>
>  arch/x86/include/asm/switch_to.h |2 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c   |2 +-
>  drivers/gpu/drm/i915/gvt/mmio.h  |   17 +-
>  drivers/isdn/hardware/eicon/Kconfig  |1 +
>  drivers/media/dvb-frontends/ascot2e.c|3 +-
>  drivers/media/dvb-frontends/cxd2841er.c  |4 +-
>  drivers/media/dvb-frontends/drx39xyj/drxj.c  |   14 +-
>  drivers/media/dvb-frontends/helene.c |4 +-
>  drivers/media/dvb-frontends/horus3a.c|2 +-
>  drivers/media/dvb-frontends/itd1000.c|2 +-
>  drivers/media/dvb-frontends/mt312.c  |2 +-
>  drivers/media/dvb-frontends/si2165.c |   14 +-
>  drivers/media/dvb-frontends/stb0899_drv.c|2 +-
>  drivers/media/dvb-frontends/stb6100.c|2 +-
>  drivers/media/dvb-frontends/stv0367.c|2 +-
>  drivers/media/dvb-frontends/stv090x.c|2 +-
>  drivers/media/dvb-frontends/stv6110.c|2 +-
>  drivers/media/dvb-frontends/stv6110x.c   |2 +-
>  drivers/media/dvb-frontends/tda8083.c|2 +-
>  

Re: [PATCH] cfg80211: support 4-way handshake offloading for WPA/WPA2-PSK

[Johannes Berg]

On Tue, 2017-02-28 at 12:06 +0100, Arend Van Spriel wrote:
> On 21-2-2017 12:46, Johannes Berg wrote:
> > 
> > > > > Would this work for you? We should have wpa_supplicant
> > > > > support
> > > > > too, but need to ask Andrei to look at that.
> > > 
> > > Forgot to reply to this. Yes, this will work. Can come up with
> > > wpa_supp changes.
> > 
> > No, we have them. Just need to see where they are :)
> 
> Found anything ? :-p

Sorry, got too busy with other stuff.

+Andrei, can you send out the patches from Avi in wpa_s for doing the
4-way-HS offload (as an RFC)?

Arend, wait a bit - he's travelling now I think.

Thanks,
johannes

[RFCv2 1/2] mac80211: Add provision for 802.11 encap offload

[mpubbise]

From: Vasanthakumar Thiagarajan 

Drivers can have the capability to offload 802.11 encap
to firmware or hardware for data frames. This patch adds a new
hw_flag for driver to advertise the offload support.
Transmit path offloading 802.11 header (including cipher headers)
encap for data frames will be implemented in a separate patch.

Drivers advertising this capability should also implement other
functionalities which deal with 802.11 frame format like below

- Hardware encryption
- Aggregation of A-MSDU offload
- Fragmentation offload

Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Manikanta Pubbisetty 
---
 include/net/mac80211.h |4 
 net/mac80211/debugfs.c |1 +
 2 files changed, 5 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 3edb469..0239b7d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2049,6 +2049,9 @@ struct ieee80211_txq {
  * The stack will not do fragmentation.
  * The callback for @set_frag_threshold should be set as well.
  *
+ * @IEEE80211_HW_SUPPORTS_80211_ENCAP: Hardware/driver supports 802.11
+ * encap for data frames.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2091,6 +2094,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_TX_FRAG_LIST,
IEEE80211_HW_REPORTS_LOW_ACK,
IEEE80211_HW_SUPPORTS_TX_FRAG,
+   IEEE80211_HW_SUPPORTS_80211_ENCAP,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 5fae001..b97ffb4 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -211,6 +211,7 @@ static ssize_t reset_write(struct file *file, const char 
__user *user_buf,
FLAG(TX_FRAG_LIST),
FLAG(REPORTS_LOW_ACK),
FLAG(SUPPORTS_TX_FRAG),
+   FLAG(SUPPORTS_80211_ENCAP),
 #undef FLAG
 };
 
-- 
1.7.9.5

[RFC] cfg80211: Add support for FILS shared key authentication offload

[Jouni Malinen]

From: "Kanchanapally, Vidyullatha" 

Enhance nl80211 and cfg80211 connect request and response APIs to
support FILS shared key authentication Offload. The new nl80211
attributes can be used to provide additional information to the driver
to establish a FILS connection. Also enhance the set/del PMKSA to allow
support for adding and deleting PMKSA based on FILS cache identifier.

Add a new feature flag that drivers can use to advertize support for
FILS shared key authentication and association in station mode when
using their own SME.

Signed-off-by: Vidyullatha Kanchanapally 
Signed-off-by: Jouni Malinen 
---
 include/linux/ieee80211.h|   9 
 include/net/cfg80211.h   | 115 +++
 include/uapi/linux/nl80211.h |  48 --
 net/wireless/core.h  |  12 -
 net/wireless/mlme.c  |   1 +
 net/wireless/nl80211.c   |  89 ++---
 net/wireless/nl80211.h   |   5 +-
 net/wireless/sme.c   |  64 ++--
 net/wireless/util.c  |   4 ++
 9 files changed, 311 insertions(+), 36 deletions(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 22bf067..51e2748 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1723,6 +1723,9 @@ enum ieee80211_statuscode {
WLAN_STATUS_REJECT_DSE_BAND = 96,
WLAN_STATUS_DENIED_WITH_SUGGESTED_BAND_AND_CHANNEL = 99,
WLAN_STATUS_DENIED_DUE_TO_SPECTRUM_MANAGEMENT = 103,
+   /* 802.11ai */
+   WLAN_STATUS_FILS_AUTHENTICATION_FAILURE = 108,
+   WLAN_STATUS_UNKNOWN_AUTHENTICATION_SERVER = 109,
 };
 
 
@@ -2104,6 +2107,12 @@ enum ieee80211_key_len {
 #define FILS_NONCE_LEN 16
 #define FILS_MAX_KEK_LEN   64
 
+#define FILS_ERP_MAX_USERNAME_LEN  16
+#define FILS_ERP_MAX_REALM_LEN 253
+#define FILS_ERP_MAX_RRK_LEN   64
+
+#define PMK_MAX_LEN48
+
 /* Public action codes */
 enum ieee80211_pub_actioncode {
WLAN_PUB_ACTION_EXT_CHANSW_ANN = 4,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 86c12f8..a5009d0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2073,6 +2073,17 @@ struct cfg80211_bss_selection {
  * the BSSID of the current association, i.e., to the value that is
  * included in the Current AP address field of the Reassociation Request
  * frame.
+ * @fils_erp_username: EAP re-authentication protocol (ERP) username part of 
the
+ * NAI. This is used to refer to the keys used in ERP, i.e., rRK and rIK.
+ * @fils_erp_username_len: Length of @fils_erp_username in octets.
+ * @fils_erp_realm: EAP re-authentication protocol (ERP) realm part of NAI. 
This
+ * specifies the domain name of ER server.
+ * @fils_erp_realm_len: Length of @fils_erp_realm in octets.
+ * @fils_erp_sequence_num: The start sequence number to be used in the next ERP
+ * message.
+ * @fils_erp_rrk: ERP re-authentication Root Key (rRK) used to derive 
additional
+ * keys in FILS.
+ * @fils_erp_rrk_len: Length of @fils_erp_rrk in octets.
  */
 struct cfg80211_connect_params {
struct ieee80211_channel *channel;
@@ -2098,6 +2109,13 @@ struct cfg80211_connect_params {
bool pbss;
struct cfg80211_bss_selection bss_select;
const u8 *prev_bssid;
+   const u8 *fils_erp_username;
+   size_t fils_erp_username_len;
+   const u8 *fils_erp_realm;
+   size_t fils_erp_realm_len;
+   u16 fils_erp_sequence_num;
+   const u8 *fils_erp_rrk;
+   size_t fils_erp_rrk_len;
 };
 
 /**
@@ -2137,11 +2155,24 @@ enum wiphy_params_flags {
  * caching.
  *
  * @bssid: The AP's BSSID.
- * @pmkid: The PMK material itself.
+ * @pmkid: The identifer to refer a PMKSA.
+ * @pmk: The PMK for the PMKSA identified by @pmkid. This is used for key
+ * derivation by a FILS STA. Otherwise, %NULL.
+ * @pmk_len: Length of the @pmk. The length of @pmk can differ depending on
+ * the hash algorithm used to generate this.
+ * @ssid: SSID to specify the ESS within which a PMKSA is valid.
+ * @ssid_len: Length of the @ssid in octets.
+ * @cache_id: Unsigned 16 bit identifier advertized by an AP identifying the
+ * scope of PMKSA. This is valid only if @ssid_len is non-zero.
  */
 struct cfg80211_pmksa {
const u8 *bssid;
const u8 *pmkid;
+   const u8 *pmk;
+   size_t pmk_len;
+   const u8 *ssid;
+   size_t ssid_len;
+   u16 cache_id;
 };
 
 /**
@@ -5136,6 +5167,60 @@ static inline void cfg80211_testmode_event(struct 
sk_buff *skb, gfp_t gfp)
 #endif
 
 /**
+ * cfg80211_connect_done - notify cfg80211 of connection result
+ *
+ * @dev: network device
+ * @bssid: the BSSID of the AP
+ * @bss: entry of bss to which STA got connected to, can be obtained
+ * through cfg80211_get_bss (may be %NULL)
+ * @req_ie: association request IEs (maybe 

[RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[mpubbise]

From: Vasanthakumar Thiagarajan 

Driver (or hw) supporting 802.11 encapsulation offload
for data frames can make use of this new xmit path.

This patch defines new ndo_ops, all these callbacks are same as
ieee80211_dataif_ops other than ndo_start_xmit() which does
minimal processing leaving 802.11 encap related to driver.

This patch makes netdev_ops registration based on the
driver/hardware capability for 802.11 encap offload and interface type.

There is a field, no_80211_encap, added to ieee80211_tx_info:control
to mark if the 802.11 encapsulation is offloaded to driver.
There is also a new callback for tx completion status indication
to handle data frames using 802.11 encap offload.

Currently ath10k fw is capable of doing 802.11 encapsulation offload
and with the corresponding driver changes, 802.11 encap offload
might improve performance.

Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Manikanta Pubbisetty 
---
 include/net/mac80211.h |   26 +-
 net/mac80211/cfg.c |9 ++
 net/mac80211/ieee80211_i.h |   11 +++
 net/mac80211/iface.c   |   72 +++
 net/mac80211/key.c |3 +
 net/mac80211/status.c  |   82 ++
 net/mac80211/tx.c  |  207 +++-
 7 files changed, 405 insertions(+), 5 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 0239b7d..b9e74b3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -921,7 +921,12 @@ struct ieee80211_tx_info {
};
struct ieee80211_key_conf *hw_key;
u32 flags;
-   /* 4 bytes free */
+   /* XXX: This frame is not encapsulated with 802.11
+* header. Should this be added to %IEEE80211_TX_CTRL_*
+* flags?.
+*/
+   bool no_80211_encap;
+   /* 3 bytes free */
} control;
struct {
u64 cookie;
@@ -4265,6 +4270,25 @@ void ieee80211_tx_status_irqsafe(struct ieee80211_hw *hw,
 struct sk_buff *skb);
 
 /**
+ * ieee80211_tx_status_8023 - transmit status callback for 802.3 frame format
+ *
+ * Call this function for all transmitted data frames after their transmit
+ * completion. This callback should only be called for data frames which
+ * are are using driver's (or hardware's) offload capability of encap/decap
+ * 802.11 frames.
+ *
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other.
+ *
+ * @hw: the hardware the frame was transmitted by
+ * @vif: the interface for which the frame was transmitted
+ * @skb: the frame that was transmitted, owned by mac80211 after this call
+ */
+void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct sk_buff *skb);
+
+/**
  * ieee80211_report_low_ack - report non-responding station
  *
  * When operating in AP-mode, call this function to report a non-responding
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 9c7490c..e1c6f3e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -129,6 +129,9 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
}
}
 
+   if (!ieee80211_sdata_running(sdata))
+   ieee80211_if_check_80211_encap_offl(sdata);
+
return 0;
 }
 
@@ -2273,6 +2276,12 @@ static int ieee80211_set_wiphy_params(struct wiphy 
*wiphy, u32 changed)
if (changed & WIPHY_PARAM_FRAG_THRESHOLD) {
ieee80211_check_fast_xmit_all(local);
 
+   if (ieee80211_iface_uses_80211_encap_offl(local))
+   return -EINVAL;
+
+   if (!local->ops->set_frag_threshold)
+   return -EINVAL;
+
err = drv_set_frag_threshold(local, wiphy->frag_threshold);
 
if (err) {
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 0e71843..1618806 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -966,6 +966,8 @@ struct ieee80211_sub_if_data {
} debugfs;
 #endif
 
+   bool data_80211_encap_offloaded;
+
/* must be last, dynamically sized area in this! */
struct ieee80211_vif vif;
 };
@@ -1696,6 +1698,8 @@ int ieee80211_if_add(struct ieee80211_local *local, const 
char *name,
 struct vif_params *params);
 int ieee80211_if_change_type(struct ieee80211_sub_if_data *sdata,
 enum nl80211_iftype type);
+void ieee80211_if_check_80211_encap_offl(struct ieee80211_sub_if_data *sdata);
+bool ieee80211_iface_uses_80211_encap_offl(struct ieee80211_local *local);
 void 

[RFCv2 0/2] Add new transmit data path for ethernet frame format

[mpubbise]

From: Manikanta Pubbisetty 

This patch set adds a new transmit data path to offload 802.11 header
encap to driver/hardware. Drivers having support for ieee80211
header encap and other offload functionalities which can't be done
before encap can make use of this new data path. Currently it is
implemented for STA and AP interface type, this can be extend other
interface types like adhoc.

This patchset only adds support for tx in ethernet frame format
and receive can happen in 802.11 format with existing rx framework.

With ath10k driver changes using this new Tx/Rx path, 10 - 15%
CPU usage and upto ~20Mbps TCP performance improvements are
observed with this ethernet data path.

Vasanthakumar Thiagarajan (2):
  mac80211: Add provision for 802.11 encap offload
  mac80211: Implement data xmit for 802.11 encap offload

V2:
 * 802.11 decap offload is removed from the patchset
 * Code changes as per review comments of v1.

 include/net/mac80211.h |   30 ++-
 net/mac80211/cfg.c |9 ++
 net/mac80211/debugfs.c |1 +
 net/mac80211/ieee80211_i.h |   10 +++
 net/mac80211/iface.c   |   72 +++
 net/mac80211/key.c |3 +
 net/mac80211/status.c  |   79 +
 net/mac80211/tx.c  |  207 +++-
 8 files changed, 406 insertions(+), 5 deletions(-)

-- 
1.7.9.5

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

[Arnd Bergmann]

On Fri, Mar 3, 2017 at 9:26 AM, Christian Borntraeger
 wrote:
> On 03/02/2017 10:45 PM, Arnd Bergmann wrote:
>> Ok, got it. So I guess the behavior of forcing aligned accesses on aligned
>> data is accidental, and allowing non-power-of-two arguments is also not
>> the main purpose.
>
>
> Right. The main purpose is to read/write _ONCE_. You can assume a somewhat
> atomic access for sizes <= word size. And there are certainly places that
> rely on that. But the *ONCE thing is mostly used for things where we used
> barrier() 10 years ago.

Ok

>
>  Maybe we could just bail out on new compilers if we get
>> either of those? That might catch code that accidentally does something
>> that is inherently non-atomic or that causes a trap when the intention was
>> to have a simple atomic access.
>
> I think Linus stated that its ok to assume that the compiler is smart enough
> to uses a single instruction to access aligned and properly sized scalar types
> for *ONCE.
>
> Back then when I changed ACCESS_ONCE there were many places that did use it
> for non-atomic, > word size accesses. For example on some architectures a 
> pmd_t
> is a typedef to an array, for which there is no way to read that atomically.
> So the focus must be on the "ONCE" part.
>
> If some code uses a properly aligned, word sized object we can also assume
> atomic access. If the access is not properly sized/aligned we do not get
> atomicity, but we do get the "ONCE".
> But adding a check for alignment/size would break the compilation of some
> code.

So what should be the expected behavior for objects that have a smaller
alignment? E.g. this structure

struct fourbytes {
   char bytes[4];
} __packed;

when passed into the current READ_ONCE() will be accessed with
a 32-bit load, while reading it with

struct fourbytes local = *(volatile struct fourbytes *)voidpointer;

on architectures like ARMv5 or lower will turn into four single-byte
reads to avoid an alignment trap when the pointer is actually
unaligned.

I can see arguments for and against either behavior, but what should
I do when modifying it for newer compilers? The possible options
that I see are

- keep assuming that the pointer will be aligned at runtime
  and doesn't trap
- use the regular gcc behavior and do byte-accesses on those
  architectures that otherwise might trap
- add a runtime alignment check to do atomic accesses whenever
  possible, but never trap
- fail the build

 Arnd

[PATCH 4.12] bcma: drop unneeded check for CONFIG_OF_IRQ

[Rafał Miłecki]

From: Rafał Miłecki 

We already have the same check in bcma_of_get_irq which really calls
symbols available with CONFIG_OF_IRQ only. It appears this duplicated
check was accidentally added in commit c58d900cc96a ("bcma: fix building
without OF_IRQ"). The rest of code in bcma_of_fill_device should work
fine without CONFIG_OF_IRQ.

Signed-off-by: Rafał Miłecki 
Cc: Arnd Bergmann 
---
 drivers/bcma/main.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 2da7fe1d20a7..e6986c7608f1 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -201,9 +201,6 @@ static void bcma_of_fill_device(struct device *parent,
 {
struct device_node *node;
 
-   if (!IS_ENABLED(CONFIG_OF_IRQ))
-   return;
-
node = bcma_of_find_child_device(parent, core);
if (node)
core->dev.of_node = node;
-- 
2.11.0

[PATCH 4.12 1/2] bcma: use helper function to set core dev's parent

[Rafał Miłecki]

From: Rafał Miłecki 

A tiny code deduplication thanks to the bcma_bus_get_host_dev.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 12da68ec48ba..4f88821c1b2a 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -242,17 +242,16 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
bcma_device *core)
core->dev.release = bcma_release_core_dev;
core->dev.bus = _bus_type;
dev_set_name(>dev, "bcma%d:%d", bus->num, core->core_index);
+   core->dev.parent = bcma_bus_get_host_dev(bus);
 
switch (bus->hosttype) {
case BCMA_HOSTTYPE_PCI:
-   core->dev.parent = >host_pci->dev;
core->dma_dev = >host_pci->dev;
core->irq = bus->host_pci->irq;
break;
case BCMA_HOSTTYPE_SOC:
if (IS_ENABLED(CONFIG_OF) && bus->host_pdev) {
core->dma_dev = >host_pdev->dev;
-   core->dev.parent = >host_pdev->dev;
if (core->dev.parent)
bcma_of_fill_device(core->dev.parent, core);
} else {
-- 
2.11.0

[PATCH 4.12 2/2] bcma: fill core OF info independently of bus type

[Rafał Miłecki]

From: Rafał Miłecki 

PCI devices can be described in DT as well so we should always execute
relevant code. This will make bcma e.g. set of_node for cores described
in DT.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 4f88821c1b2a..2da7fe1d20a7 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -243,6 +243,8 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
bcma_device *core)
core->dev.bus = _bus_type;
dev_set_name(>dev, "bcma%d:%d", bus->num, core->core_index);
core->dev.parent = bcma_bus_get_host_dev(bus);
+   if (core->dev.parent)
+   bcma_of_fill_device(core->dev.parent, core);
 
switch (bus->hosttype) {
case BCMA_HOSTTYPE_PCI:
@@ -252,8 +254,6 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
bcma_device *core)
case BCMA_HOSTTYPE_SOC:
if (IS_ENABLED(CONFIG_OF) && bus->host_pdev) {
core->dma_dev = >host_pdev->dev;
-   if (core->dev.parent)
-   bcma_of_fill_device(core->dev.parent, core);
} else {
core->dev.dma_mask = >dev.coherent_dma_mask;
core->dma_dev = >dev;
-- 
2.11.0

Re: Hostapd de-auth connected clients

[ravin goyal]

Hi, I think I need to mention the hardware specification
I was first trying on banana pi m2+ which has WLAN chip AP6212(ampak)
here is the link to it: http://linux-sunxi.org/Wifi#Ampak
I tried both raspbian and debian jessie on it both distros has
wireless driver bcmhd linked to the wifi chip.
Both these distros has flaws in its wireless driver when it comes to
run hostapd on it.

Then I tired on orange pi zero running debian jessie and its wifi
chipset is XR819 and wlan driver is xradio_wlan
http://linux-sunxi.org/Wifi#Allwinner

This driver seems to be working fine with hostapd so far.
I hope the confusion is clear now.

Regards,
Ravin

On 2 March 2017 at 18:07, Arend Van Spriel  wrote:
> + linux-wireless
>
> On 2-3-2017 10:28, ravin goyal wrote:
>> Hi Arend
>>
>> Thanks, I will certainly try with brcmfmac if you say so.
>> Currently I am testing hostapd on orange pi zero board running debian
>> jessie and its wlan driver is xradio_wlan and it is working fine.
>> I don't know why raspbian and debian have introduced bcmdhd for WLAN
>> in their distros.
>> I have filed bug on raspbian but received on response yet.
>
> Now it gets confusing. From what I found xradio_wlan is for some
> Allwinner flavor based on ST/Ericsson chipset with sdio id 0020:2281.
> That would not be a device that bcmdhd would try to bind to.
>
> Regards,
> Arend
>
>> Regards
>> Ravin
>>
>> On 1 March 2017 at 18:59, Arend Van Spriel  
>> wrote:
>>> On 28-2-2017 23:28, Jouni Malinen wrote:
 On Tue, Feb 28, 2017 at 04:06:48PM +0530, ravin goyal wrote:
> I am sharing link to recent debug log related to de-auth messages in
> hostapd, I hope it might help to figure out what's really happening
> and to know whether it is due to driver or hostapd.
>
> Please take a look at this.
>
> link to log file: https://clbin.com/0flGD

 It looks like number of the disconnections in the two logs are triggered
 by station inactivity check:

 1488275056.529235: wlan0: Station 00:73:8d:43:87:2e has been inactive too 
 long: 308 sec, max allowed: 300
 1488275056.529389:   Polling STA
 1488275056.529457: nl80211: send_mlme - da= 00:73:8d:43:87:2e noack=0 
 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x248 (WLAN_FC_STYPE_NULLFUNC) 
 nlmode=3
 1488275056.529574: nl80211: Use bss->freq=2442
 1488275056.529634: nl80211: CMD_FRAME freq=2442 wait=0 no_cck=0 no_ack=0 
 offchanok=0
 1488275056.529711: CMD_FRAME - hexdump(len=24): 48 02 00 00 00 73 8d 43 87 
 2e 02 1a 11 f5 47 06 02 1a 11 f5 47 06 00 00
 1488275056.530129: nl80211: Frame command failed: ret=-22 (Invalid 
 argument) (freq=2442 wait=0)
 1488275056.530231: nl80211_send_null_frame: Failed to send poll frame
 1488275056.530295: ap_handle_timer: register ap_handle_timer timeout for 
 00:73:8d:43:87:2e (1 seconds - AP_DISASSOC_DELAY)


 This code should not have been triggered at all if the driver reported
 activity in the expected way, so I'm assuming the driver does not
 support that.. And then it does not support sending out the poll frame
 to check whether the STA is still there.

 You might be able to work around this by setting a significantly larger
 ap_max_inactivity value in hostapd.conf, but for a proper fix, someone
 more familiar with the particular driver would need to take a look at
 what's happening and why the driver does not indicate station activity.
>>>
>>> I would suggest trying brcmfmac instead of bcmdhd. The bcmdhd is
>>> specifically for Android and verification is done on Android targets.
>>> Not saying your problems will be gone, but at least you can ask me for help.
>>>
>>> Regards,
>>> Arend