Re: [PATCH 1/4] bpf: account for freed JIT allocations in arch code

On Mon, 19 Nov 2018 at 02:37, Daniel Borkmann wrote: > > On 11/17/2018 07:57 PM, Ard Biesheuvel wrote: > > Commit ede95a63b5e84 ("bpf: add bpf_jit_limit knob to restrict unpriv > > allocations") added a call to bpf_jit_uncharge_modmem() to the routine > > bpf

Re: [PATCH net v2 0/3] Bugfix for the netsec driver

(+ Florian) On 23 October 2018 at 08:24, wrote: > From: Masahisa Kojima > > This patch series include bugfix for the netsec ethernet > controller driver, fix the problem in interface down/up. > > changes in v2: > - change the place to perform the PHY power down > - use the MACROs defiend in

Re: [PATCH 1/1] net: socionext: clear rx irq correctly

gt; This lead the napi rx handler being constantly called while no packets > needed processing and ksoftirq getting 100% cpu usage. Issue one mmio read > to clear the irq correcty after processing packets > > Signed-off-by: Ilias Apalodimas > Reported-by: Ard Biesheuvel Tested-by:

Re: [RFC PATCH] skb: Define NET_IP_ALIGN based on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS

(+ Arnd but really) On 4 October 2018 at 19:43, Ard Biesheuvel wrote: > (+ Arnd, Russell, Catalin, Will) > > On 4 October 2018 at 19:36, Ben Hutchings > wrote: >> NET_IP_ALIGN is supposed to be defined as 0 if DMA writes to an >> unaligned buffer would be more e

Re: [RFC PATCH] skb: Define NET_IP_ALIGN based on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS

(+ Arnd, Russell, Catalin, Will) On 4 October 2018 at 19:36, Ben Hutchings wrote: > NET_IP_ALIGN is supposed to be defined as 0 if DMA writes to an > unaligned buffer would be more expensive than CPU access to unaligned > header fields, and otherwise defined as 2. > > Currently only ppc64 and

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

On Wed, 26 Sep 2018 at 17:50, Jason A. Donenfeld wrote: > > On Wed, Sep 26, 2018 at 5:45 PM Jason A. Donenfeld wrote: > > So what you have in mind is something like calling simd_relax() every > > 4096 bytes or so? > > That was actually pretty easy, putting together both of your suggestions: > >

Re: Oops running iptables -F OUTPUT

On 28 August 2018 at 15:56, Ard Biesheuvel wrote: > Hello Andreas, Nick, > > On 28 August 2018 at 06:06, Nicholas Piggin wrote: >> On Mon, 27 Aug 2018 19:11:01 +0200 >> Andreas Schwab wrote: >> >>> I'm getting this Oops when running iptables -F OUTPUT: >

Re: Oops running iptables -F OUTPUT

Hello Andreas, Nick, On 28 August 2018 at 06:06, Nicholas Piggin wrote: > On Mon, 27 Aug 2018 19:11:01 +0200 > Andreas Schwab wrote: > >> I'm getting this Oops when running iptables -F OUTPUT: >> >> [ 91.139409] Unable to handle kernel paging request for data at address >> 0xd001fff12f34

Re: [PATCH] net: netsec: reduce DMA mask to 40 bits

t;> Jassi Brar <jaswinder.si...@linaro.org> wrote: >>> >>>> On 25 May 2018 at 18:20, Ard Biesheuvel <ard.biesheu...@linaro.org> >>>> wrote: >>>> > The netsec network controller IP can drive 64 address bits for DMA, >>>&

[PATCH] net: netsec: reduce DMA mask to 40 bits

isa.koj...@linaro.org> Cc: Ilias Apalodimas <ilias.apalodi...@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- Please cc to -stable (v4.16+) drivers/net/ethernet/socionext/netsec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dr

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

On 21 January 2018 at 16:13, Andrew Lunn wrote: >> Right. So if you need to have some additional "parameters" with the >> connection, then I suppose you may want to go with the GenericSerialBus >> route. However, looking at the sample device tree description: >> >>

Re: [PATCH] [net-next] net: netsec: use dma_addr_t for storing dma address

or consistently, consistency > I'm changing the variable name as well, to clarify that this is a DMA > address. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- > drivers/net/ethernet/socionext/netsec.c |

Re: [PATCH] [net-next] net: socionext: include linux/io.h to fix build

is. This is the same issue spotted by kbuild test robot. Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- > drivers/net/ethernet/socionext/netsec.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ethernet/socionext/netsec.c > b/dr

Re: [PATCHv5 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec

er.si...@linaro.org> > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- > .../devicetree/bindings/net/socionext-netsec.txt | 53 > ++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/so

Re: [PATCHv4 2/3] net: socionext: Add Synquacer NetSec driver

On 23 December 2017 at 15:01, Jassi Brar <jassisinghb...@gmail.com> wrote: > On Sat, Dec 23, 2017 at 4:09 PM, Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: >> On 23 December 2017 at 05:45, <jassisinghb...@gmail.com> wrote: >>> From:

Re: [PATCHv4 2/3] net: socionext: Add Synquacer NetSec driver

On 23 December 2017 at 05:45, <jassisinghb...@gmail.com> wrote: > From: Jassi Brar <jaswinder.si...@linaro.org> > > This driver adds support for Socionext "netsec" IP Gigabit > Ethernet + PHY IP used in the Synquacer SC2A11 SoC. > > Signed-off-by: A

Re: [PATCHv3 2/3] net: socionext: Add Synquacer NetSec driver

Hi Jassi, On 21 December 2017 at 12:11, <jassisinghb...@gmail.com> wrote: > From: Jassi Brar <jaswinder.si...@linaro.org> > > This driver adds support for Socionext "netsec" IP Gigabit > Ethernet + PHY IP used in the Synquacer SC2A11 SoC. > > Si

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

On 18 December 2017 at 10:17, Marcin Wojtas wrote: > Hi, > > This patchset introduces ACPI support in mvpp2 and mvmdio drivers. > First three patches introduce fwnode helpers for obtaining PHY > information from nodes and also MDIO fwnode API for registering > the bus with its

Re: [PATCHv2 2/3] net: socionext: Add Synquacer NetSec driver

Hi Jassi, On 12 December 2017 at 17:15, <jassisinghb...@gmail.com> wrote: > From: Jassi Brar <jaswinder.si...@linaro.org> > > This driver adds support for Socionext "netsec" IP Gigabit > Ethernet + PHY IP used in the Synquacer SC2A11 SoC. > > Si

Re: [PATCH net-next resubmit 1/2] net: phy: core: remove now uneeded disabling of interrupts

On 4 December 2017 at 15:50, David Miller <da...@davemloft.net> wrote: > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Date: Mon, 4 Dec 2017 15:46:55 + > >> On 4 December 2017 at 15:24, David Miller <da...@davemloft.net> wrote: >>> From: Heine

Re: [PATCH net-next resubmit 1/2] net: phy: core: remove now uneeded disabling of interrupts

oved the comment >> explaining why interrupts need to be temporarily disabled. >> >> On my system phy interrupt mode works fine with this patch. >> However I may miss something, especially in the context of shared phy >> interrupts, therefore I'd appreciate if more peop

Re: [PATCH 3/3] MAINTAINERS: Add entry for Socionext ethernet driver

On 30 November 2017 at 16:13, <jassisinghb...@gmail.com> wrote: > From: Jassi Brar <jaswinder.si...@linaro.org> > > Add entry for the Socionext Netsec controller driver and DT bindings. > > Signed-off-by: Jassi Brar <jaswinder.si...@linaro.org> Acked-by: Ard Bies

Re: [PATCH 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec

er.si...@linaro.org> > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> No need to keep my signoff here: if you are posting the patch, your signoff should come last. (Authorship is no factor here, only the path taken by the patch from the author/copyright holder to the

Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver

On 30 November 2017 at 17:58, David Miller <da...@davemloft.net> wrote: > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Date: Thu, 30 Nov 2017 17:48:44 + > >> On 30 November 2017 at 17:42, David Miller <da...@davemloft.net> wrote: >>> From:

Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver

On 30 November 2017 at 17:42, David Miller <da...@davemloft.net> wrote: > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Date: Thu, 30 Nov 2017 17:37:27 + > >> Well, the whole point of using memremap() instead of ioremap() is that >> the region has memory

Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver

(+ Dan, Will) On 30 November 2017 at 17:29, David Miller wrote: > From: jassisinghb...@gmail.com > Date: Thu, 30 Nov 2017 21:43:16 +0530 > >> + priv->eeprom_base = devm_memremap(>dev, eeprom_res->start, >> +

Re: [PATCH RfC 1/2] net: phy: core: remove now uneeded disabling of interrupts

;> Since net-next is closed at the moment, that should allow us to give >> this some good amount of testing. >> >> Thanks >> >>> >>> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> For the record Acked-by: Ard Biesheuvel <ard.biesheu..

[RFC PATCH] phy: don't disable and re-enable interrupts in oneshot threaded handler

the disable_irq/enable_irq, and rely on the fact that the interrupt remains masked already. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/net/phy/phy.c | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/net/phy/phy.c b/drivers/n

Re: [QUESTION] poor TX performance on new GbE driver

On 22 October 2017 at 20:38, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Sun, 2017-10-22 at 20:14 +0100, Ard Biesheuvel wrote: >> Hello all, >> >> I am working on upstreaming a network driver for a Socionext SoC, and >> I am having some trouble f

Re: [QUESTION] poor TX performance on new GbE driver

On 22 October 2017 at 20:27, Florian Fainelli <f.faine...@gmail.com> wrote: > On 10/22/2017 12:14 PM, Ard Biesheuvel wrote: >> Hello all, >> >> I am working on upstreaming a network driver for a Socionext SoC, and >> I am having some trouble figuring out why my T

[QUESTION] poor TX performance on new GbE driver

Hello all, I am working on upstreaming a network driver for a Socionext SoC, and I am having some trouble figuring out why my TX performance is horrible when booting a Debian Stretch rootfs, while booting a Ubuntu 17.04 rootfs works absolutely fine. Note that this is using the exact same kernel

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On 19 October 2017 at 11:57, David Miller <da...@davemloft.net> wrote: > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Date: Wed, 18 Oct 2017 16:45:15 +0100 > >> Even though calling dql_completed() with a count that exceeds the >> queued count is a serious

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On 18 October 2017 at 19:45, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-10-18 at 18:57 +0100, Ard Biesheuvel wrote: >> On 18 October 2017 at 17:29, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wr

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On 18 October 2017 at 17:29, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: >> Even though calling dql_completed() with a count that exceeds the >> queued count is a serious error, it still does not justify bringing >

[PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

Even though calling dql_completed() with a count that exceeds the queued count is a serious error, it still does not justify bringing down the entire kernel with a BUG_ON(). So relax it to a WARN_ON() instead. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --

Re: [PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down

On 6 April 2017 at 13:29, Alexei Starovoitov wrote: > On Wed, Apr 05, 2017 at 09:17:25PM +0100, David Howells wrote: >> From: Chun-Yi Lee >> >> There are some bpf functions can be used to read kernel memory: >> bpf_probe_read, bpf_probe_write_user and

Re: [PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

On 8 February 2017 at 07:00, Johannes Berg wrote: > This looks strange to me: > >> +static int aes_s2v(struct crypto_shash *tfm, >> size_t num_elem, const u8 *addr[], size_t len[], >> u8 *v) >> { >> - u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE]; >> +

[PATCH v3 2/2] mac80211: aes-cmac: switch to shash CMAC driver

efficient and more secure implementations, especially on platforms where SIMD ciphers have a considerable setup cost. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_cmac.c | 126 net/mac80211/aes_cmac.h | 11 +- net/mac80211/key.h | 2

[PATCH v3 0/2] mac80211: use crypto shash for AES cmac

- replace compound literal zero vectors with explicitly defined ones - drop a redundant memcpy() in #2 Ard Biesheuvel (2): mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher mac80211: aes-cmac: switch to shash CMAC driver net/mac80211/Kconfig | 1 + net/mac80211

[PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

usually expose the cipher API. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/Kconfig | 1 + net/mac80211/aes_cmac.h | 4 -- net/mac80211/fils_aead.c | 74 +--- 3 files changed, 34 insertions(+), 45 deletions(-) diff --git a/net/mac80211/Kco

Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac

On 6 February 2017 at 10:01, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Sun, Feb 05, 2017 at 03:23:26PM +0000, Ard Biesheuvel wrote: >> NOTE: Jouni has been so kind to test patch #2, and confirmed that it is >> working. >> I have not tested patch #1 myse

Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

On 6 February 2017 at 08:47, Johannes Berg wrote: > >> { >> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE]; >> + struct shash_desc *desc; >> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)] >> CRYPTO_MINALIGN_ATTR; I realised we have a more idiomatic

[PATCH v2 2/2] mac80211: aes-cmac: switch to shash CMAC driver

efficient and more secure implementations, especially on platforms where SIMD ciphers have considerable setup time. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_cmac.c | 130 +--- net/mac80211/aes_cmac.h | 11 +- net/mac80211/key.h | 2

[PATCH v2 0/2] mac80211: use crypto shash for AES cmac

. I have not tested patch #1 myself, mainly because the test methodology requires downloading Ubuntu installer images, and I am currently on a metered 3G connection (and will be for another couple of weeks) Ard Biesheuvel (2): mac80211: fils_aead: Use crypto api CMAC shash rather

[PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

usually expose the cipher API. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/Kconfig | 1 + net/mac80211/aes_cmac.h | 4 -- net/mac80211/fils_aead.c | 74 +--- 3 files changed, 35 insertions(+), 44 deletions(-) diff --git a/net/mac80211/Kco

Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

On 4 February 2017 at 14:39, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Sat, Feb 04, 2017 at 02:24:36PM +0000, Ard Biesheuvel wrote: >> There is another issue I spotted: the skcipher you allocate may be of >> the async variant, which may return from skcipher_encrypt()

Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

On 4 February 2017 at 11:35, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Fri, Feb 03, 2017 at 09:55:36PM +0000, Ard Biesheuvel wrote: >> OK, that looks like something I could figure out how to use. But are >> you saying the CMAC code is never called in practice? &

Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

On 3 February 2017 at 21:47, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Fri, Feb 03, 2017 at 07:25:53PM +0000, Ard Biesheuvel wrote: >> The mac80211 aes_cmac code reimplements the CMAC algorithm based on the >> core AES cipher, which is rather restrictive in how

[RFC PATCH 2/2] mac80211: aes-cmac: switch to shash CMAC driver

efficient and more secure implementations, especially on platforms where SIMD ciphers have considerable setup time. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/Kconfig| 1 + net/mac80211/aes_cmac.c | 137 +--- net/mac80211/aes_cmac.h | 11 +

[RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

no idea how I would go about testing this code, but I am on a mission to remove as many dependencies on the generic AES cipher as I can. Ard Biesheuvel (2): mac80211: fils_aead: clone shared CMAC functions into private version mac80211: aes-cmac: switch to shash CMAC driver net/mac80211/Kconfig

[RFC PATCH 1/2] mac80211: fils_aead: clone shared CMAC functions into private version

-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_cmac.h | 4 -- net/mac80211/fils_aead.c | 68 2 files changed, 68 insertions(+), 4 deletions(-) diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h index c827e1d5de8b..3702041f44fd 100644 ---

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On 26 December 2016 at 07:57, Herbert Xu wrote: > On Sat, Dec 24, 2016 at 09:57:53AM -0800, Andy Lutomirski wrote: >> >> I actually do use incremental hashing later on. BPF currently >> vmallocs() a big temporary buffer just so it can fill it and hash it. >> I

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

, and the base layer was already a huge improvement compared to the open coded implementations of the SHA boilerplate. > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Signed-off-by: Andy Lutomirski <l...@kernel.org> >

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 19 October 2016 at 08:43, Johannes Berg <johan...@sipsolutions.net> wrote: > 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 complicati

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On 18 October 2016 at 15:24, Johannes Berg <johan...@sipsolutions.net> wrote: > 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

[RFC PATCH 0/2] mac80211: aes_ccm: cache AEAD request allocations per CPU

did not suffer from the API violation issue in the first place) Ard Biesheuvel (2): mac80211: aes_ccm: prepare key struct for storing context data mac80211: aes_ccm: cache AEAD request structures per CPU net/mac80211/aes_ccm.c | 80 +--- net/mac80211/aes_ccm.h | 16 ++-- net

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On 18 October 2016 at 15:16, Johannes Berg <johan...@sipsolutions.net> wrote: > On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote: >> >> + aead_req = *this_cpu_ptr(ccmp->reqs); >> + if (!aead_req) { >> + aead_req = kzall

[RFC PATCH 1/2] mac80211: aes_ccm: prepare key struct for storing context data

As a prepatory change to allow per CPU caching of request structures, refactor the key allocation routine so we can access per key data beyond the core AEAD transform easily. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_ccm.c | 35 +++

[RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

, and so we can simply keep a cached aead_request structure per CPU, and deallocate all of them when deallocating the AEAD transform. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_ccm.c | 49 ++-- net/mac80211/key.h | 1 + 2 files chang

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 17 October 2016 at 18:08, Andy Lutomirski <l...@amacapital.net> wrote: > On Mon, Oct 17, 2016 at 12:37 AM, Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: >> On 17 October 2016 at 08:28, Johannes Berg <johan...@sipsolutions.net> wrote: >>> On Sat, 20

[PATCH v4] mac80211: move struct aead_req off the stack

ed-off-by: Johannes Berg <johannes.b...@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_ccm.c | 46 +--- net/mac80211/aes_ccm.h | 8 ++-- net/mac80211/aes_cmac.c | 5 +-- net/mac80211/aes_cmac.h | 2 + net/mac802

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 14:16, Johannes Berg <johan...@sipsolutions.net> wrote: > 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,

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 11:02, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > > >> On 17 Oct 2016, at 10:54, Johannes Berg <johan...@sipsolutions.net> wrote: >> >> >>>> Well, if your other patch to make it OK to be on-stack would be >>&g

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> On 17 Oct 2016, at 10:54, Johannes Berg wrote: > > >>> 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

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> On 17 Oct 2016, at 10:35, Johannes Berg <johan...@sipsolutions.net> wrote: > >> 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 dema

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> On 17 Oct 2016, at 10:35, Johannes Berg <johan...@sipsolutions.net> wrote: > >> 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 dema

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 10:23, Johannes Berg wrote: > >> 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

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 10:14, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 17 October 2016 at 09:33, Johannes Berg <johan...@sipsolutions.net> wrote: >> From: Johannes Berg <johannes.b...@intel.com> >> >> As the stack can (on x86-64) now be virtua

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> the SG APIs correctly by putting on-stack buffers into SG tables. > This leads to kernel crashes. > > Fix this by allocating the extra fields dynamically on the fly as > needed, using a kmem cache. > > I used per-CPU memory in a previous iteration of this patch, but > A

Re: [PATCH v3] mac80211: move struct aead_req off the stack

but that was missing error handling and GCM/GMAC) > > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > Signed-off-by: Johannes Berg <johannes.b...@intel.com> > --- > v3: remove superfluous aead_request_set_tfm() calls Reviewe

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 17 October 2016 at 08:47, Johannes Berg <johan...@sipsolutions.net> wrote: > 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?

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 17 October 2016 at 08:28, Johannes Berg <johan...@sipsolutions.net> wrote: > 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 th

[PATCH] crypto: ccm - avoid scatterlist for MAC encryption

, and record it in the aead_req private context so we can apply it to the MAC in cypto_ccm_auth_mac(). This greatly simplifies the scatterlist manipulation, and no longer requires scatterlists to refer to buffers that may live on the stack. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

> On 14 Oct 2016, at 14:46, Johannes Berg wrote: > > >> >> 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

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

> On 14 Oct 2016, at 14:42, David Laight <david.lai...@aculab.com> wrote: > > From: Of Ard Biesheuvel >> Sent: 14 October 2016 14:41 >> PCI devices that are 64-bit DMA capable should set the coherent >> DMA mask as well as the streaming DMA mask. On some ar

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

> On 14 Oct 2016, at 14:42, David Laight<david.lai...@aculab.com> wrote: > > From: Of Ard Biesheuvel >> Sent: 14 October 2016 14:41 >> PCI devices that are 64-bit DMA capable should set the coherent >> DMA mask as well as the streaming DMA mask. On some ar

[PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

, BIOS 10:53:24 Oct 13 2016 on systems without memory that is 32-bit addressable by PCI devices. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- v2: dropped the hunk that sets the coherent DMA mask to DMA_BIT_MASK(32), which is unnecessary given that it is the default drive

Re: [PATCH] r8169: set coherent DMA mask as well as streaming DMA mask

On 14 October 2016 at 14:34, David Miller <da...@davemloft.net> wrote: > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Date: Fri, 14 Oct 2016 14:32:24 +0100 > >> On 14 October 2016 at 14:31, David Miller <da...@davemloft.net> wrote: >>> From:

Re: [PATCH] r8169: set coherent DMA mask as well as streaming DMA mask

On 14 October 2016 at 14:31, David Miller <da...@davemloft.net> wrote: > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Date: Fri, 14 Oct 2016 12:39:30 +0100 > >> PCI devices that are 64-bit DMA capable should set the coherent >> DMA mask as well a

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

On 14 October 2016 at 14:15, Johannes Berg <johan...@sipsolutions.net> wrote: > 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 n

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

On 14 October 2016 at 14:10, 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? > >> This only addresses one half of the problem. The

[PATCH] mac80211: aes_ccm: move struct aead_req off the stack

. This pattern already exists in the IPsec ESP driver, but in the future, we may need to improve upon this by either moving the request into the SKB, or using a slab cache to allocate/free the data structures. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- This only address

[PATCH] r8169: set coherent DMA mask as well as streaming DMA mask

, BIOS 10:53:24 Oct 13 2016 on systems without memory that is 32-bit addressable by PCI devices. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/net/ethernet/realtek/r8169.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/r

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 11:00, Johannes Berg wrote: > >> 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,

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 10:25, Johannes Berg <johan...@sipsolutions.net> wrote: > 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

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 10:10, Johannes Berg <johan...@sipsolutions.net> wrote: > 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_DEB

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 09:55, Johannes Berg <johan...@sipsolutions.net> wrote: > 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), > > I

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 09:42, Johannes Berg <johan...@sipsolutions.net> wrote: > 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. &g

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 09:39, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 14 October 2016 at 09:28, Johannes Berg <johan...@sipsolutions.net> wrote: >> >>>1. revert that patch (doing so would need some major adjustments now, >>> since it'

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 09:28, Johannes Berg wrote: > >>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. > >>

[PATCH v2] r8169: default to 64-bit DMA on recent PCIe chips

Dual Address Cycle to be set, make that conditional on the device type as well. Cc: Realtek linux nic maintainers <nic_s...@realtek.com> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- This is a followup to 'r8169: default to 64-bit DMA on systems without memory be

Re: [PATCH] r8169: default to 64-bit DMA on recent PCIe chips

On 14 May 2016 at 12:41, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > The current logic around the 'use_dac' module parameter prevents the > r81969 driver from being loadable on 64-bit systems without any RAM > below 4 GB when the parameter is left at its default value. &

[PATCH] r8169: default to 64-bit DMA on recent PCIe chips

Dual Address Cycle to be set, make that conditional on the device type as well. Cc: Realtek linux nic maintainers <nic_s...@realtek.com> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- This is a followup to 'r8169: default to 64-bit DMA on systems without memory be

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

On 12 May 2016 at 16:09, Francois Romieu <rom...@fr.zoreil.com> wrote: >> On 12 May 2016 at 01:58, David Miller <da...@davemloft.net> wrote: >> > From: Ard Biesheuvel <ard.biesheu...@linaro.org> >> > Date: Wed, 11 May 2016 09:47:49 +0200 > [...] &

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

On 12 May 2016 at 01:58, David Miller <da...@davemloft.net> wrote: > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Date: Wed, 11 May 2016 09:47:49 +0200 > >> The current logic around the 'use_dac' module parameter prevents the >> r81969 driver from being loada

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

On 11 May 2016 at 22:31, Francois Romieu <rom...@fr.zoreil.com> wrote: > Ard Biesheuvel <ard.biesheu...@linaro.org> : >> The current logic around the 'use_dac' module parameter prevents the >> r81969 driver from being loadable on 64-bit systems without any RAM >&

[PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

, but only if setting a 32-bit DMA mask has failed earlier. This should prevent any regressions like the ones caused by previous attempts to change this code. Cc: Realtek linux nic maintainers <nic_s...@realtek.com> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/