On Fri, 9 Apr 2021 at 05:03, Jason A. Donenfeld wrote:
>
> On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote:
> > On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote:
> > > Since it's just a normal module library, you can simply do this in the
> > > module_init function, r
u128_xor() takes pointers to quantities that are assumed to be at least
64-bit aligned, which is not guaranteed to be the case in the smp_c1()
routine. So switch to crypto_xor() instead.
Signed-off-by: Ard Biesheuvel
---
net/bluetooth/smp.c | 5 ++---
1 file changed, 2 insertions(+), 3
On Tue, 8 Dec 2020 at 14:25, David Howells wrote:
>
> I wonder - would it make sense to reserve two arrays of scatterlist structs
> and a mutex per CPU sufficient to map up to 1MiB of pages with each array
> while the krb5 service is in use?
>
> That way sunrpc could, say, grab the mutex, map the
On Mon, 7 Dec 2020 at 15:15, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > > I wonder if it would help if the input buffer and output buffer didn't
> > > have to correspond exactly in usage - ie. the output buffer could be used
> > > at a slower r
On Mon, 7 Dec 2020 at 13:02, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > > Yeah - the problem with that is that for sunrpc, we might be dealing with
> > > 1MB
> > > plus bits of non-contiguous pages, requiring >8K of scatterlist elements
> >
On Fri, 4 Dec 2020 at 18:19, David Howells wrote:
>
> Ard Biesheuvel wrote:
>
> > The tricky thing with CTS is that you have to ensure that the final
> > full and partial blocks are presented to the crypto driver as one
> > chunk, or it won't be able to perfo
On Fri, 4 Dec 2020 at 17:52, David Howells wrote:
>
> Bruce Fields wrote:
>
> > OK, I guess I don't understand the question. I haven't thought about
> > this code in at least a decade. What's an auxilary cipher? Is this a
> > question about why we're implementing something, or how we're
> > im
On Tue, 17 Nov 2020 at 10:47, Antonio Quartulli wrote:
>
> Hi,
>
>
> On 17/11/2020 09:31, Ard Biesheuvel wrote:
> > If you are going back to the drawing board with in-kernel acceleration
> > for OpenVPN, I strongly suggest to:
> > a) either stick to one im
On Tue, 17 Nov 2020 at 03:45, Antonio Quartulli wrote:
>
> From: Antonio Quartulli
>
> The current interface limits the nonce 64bit, however, new users
> may want to specify a 96bit nonce, as dictated by the
> AEAD_CHACHA20_POLY1305 construction in RFC7539 Section 2.8.
>
> This patch changes the
On Sat, 14 Nov 2020 at 01:40, Andrew Lunn wrote:
>
> > One question that still has not been answered is how many actual
> > platforms were fixed by backporting Realtek's follow up fix to
> > -stable. My suspicion is none. That by itself should be enough
> > justification to revert the backport of
On Fri, 13 Nov 2020 at 23:43, Andrew Lunn wrote:
>
> Hi Arnd
>
> > Something of that sort. I also see a similar patch in KSZ9031
> > now, see 7dd8f0ba88fc ("arm: dts: imx6qdl-udoo: fix rgmii phy-mode
> > for ksz9031 phy")
> >
> > As this exact mismatch between rgmii and rgmii-id mode is apparently
On Fri, 30 Oct 2020 at 04:22, Alexei Starovoitov
wrote:
>
> On Thu, Oct 29, 2020 at 05:28:11PM -0700, Nick Desaulniers wrote:
> >
> > We already know that -fno-asynchronous-unwind-tables get dropped,
> > hence this patch.
>
> On arm64 only. Not on x86
>
> > And we know -fomit-frame-pointer or
> >
On Thu, 29 Oct 2020 at 21:35, Segher Boessenkool
wrote:
>
> On Wed, Oct 28, 2020 at 10:57:45PM -0400, Arvind Sankar wrote:
> > On Wed, Oct 28, 2020 at 04:20:01PM -0700, Alexei Starovoitov wrote:
> > > All compilers have bugs. Kernel has bugs. What can go wrong?
>
> Heh.
>
> > +linux-toolchains. GC
On Thu, 29 Oct 2020 at 15:39, Andrew Lunn wrote:
>
> > What about reverting the realtek PHY commit from stable?
> > As Ard said it doesn't really fix anything (usage wise) and causes a bunch
> > of
> > problems.
> >
> > If I understand correctly we have 3 options:
> > 1. 'Hack' the drivers in st
voitov
Cc: Daniel Borkmann
Cc: Peter Zijlstra (Intel)
Cc: Geert Uytterhoeven
Cc: Kees Cook
Ard Biesheuvel (2):
bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
bpf: move interpreter into separate source file
include/linux/compiler-gcc.h | 2 -
include/linux/compile
On Wed, 28 Oct 2020 at 00:04, Daniel Borkmann wrote:
>
> On 10/27/20 9:57 PM, Ard Biesheuvel wrote:
> > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
> > function scope
On Wed, 28 Oct 2020 at 09:11, Peter Zijlstra wrote:
>
> On Tue, Oct 27, 2020 at 04:11:27PM -0700, Nick Desaulniers wrote:
> > On Tue, Oct 27, 2020 at 4:04 PM Daniel Borkmann
> > wrote:
> > >
> > > On 10/27/20 9:57 PM, Ard Biesheuvel wrote:
> > > >
On Wed, 28 Oct 2020 at 07:51, Ard Biesheuvel wrote:
>
> On Wed, 28 Oct 2020 at 00:04, Daniel Borkmann wrote:
> >
> > On 10/27/20 9:57 PM, Ard Biesheuvel wrote:
> > > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > > ___bpf_prog_r
On Wed, 28 Oct 2020 at 23:59, Alexei Starovoitov
wrote:
>
> On Wed, Oct 28, 2020 at 11:15:04PM +0100, Ard Biesheuvel wrote:
> > On Wed, 28 Oct 2020 at 22:39, Alexei Starovoitov
> > wrote:
> > >
> > > On Wed, Oct 28, 2020 at 06:15:05PM +0100, Ard Biesheuvel w
On Wed, 28 Oct 2020 at 22:39, Alexei Starovoitov
wrote:
>
> On Wed, Oct 28, 2020 at 06:15:05PM +0100, Ard Biesheuvel wrote:
> > Commit 3193c0836 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
>
prog_run()")
Link:
https://lore.kernel.org/lkml/CAMuHMdUg0WJHEcq6to0-eODpXPOywLot6UD2=gfhpzoj_hc...@mail.gmail.com/
Signed-off-by: Ard Biesheuvel
---
include/linux/compiler-gcc.h | 2 --
include/linux/compiler_types.h | 4
kernel/bpf/Makefile| 6 +-
kernel/bpf/core.c
To reduce the impact of disabling certain compiler optimizations that
are only needed for the interpreter, move it into its own source file,
and apply the compiler command line override only to this file.
Signed-off-by: Ard Biesheuvel
---
include/linux/filter.h | 1 +
kernel/bpf/Makefile
On Tue, 27 Oct 2020 at 23:03, Nick Desaulniers wrote:
>
> On Tue, Oct 27, 2020 at 2:50 PM Ard Biesheuvel wrote:
> >
> > On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers
> > wrote:
> > >
> > > On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers wrote:
>
> On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
> >
> > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to
Nick Desaulniers
Cc: Arvind Sankar
Cc: Randy Dunlap
Cc: Josh Poimboeuf
Cc: Thomas Gleixner
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Peter Zijlstra (Intel)
Cc: Geert Uytterhoeven
Cc: Kees Cook
Fixes: 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_r
On Sun, 25 Oct 2020 at 15:29, Andrew Lunn wrote:
>
> On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
> > >
> > > > However, that leaves the question why bbc4d71d63549bcd was backported,
>
On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
>
> > However, that leaves the question why bbc4d71d63549bcd was backported,
> > although I understand why the discussion is a bit trickier there. But
> > if it did not fix a regression, only broken code that never worked in
> > the first place, I a
On Tue, 20 Oct 2020 at 14:49, Andrew Lunn wrote:
>
> > I hope Andrew is fine with the current changes
>
> Yes, i'm O.K. with it.
Thanks
> Making phy-mode optional would just make the
> driver more uniform with others.
>
Making phy-mode optional is fine with me, but I think it would belong
in a
On Sun, 18 Oct 2020 at 22:32, Ilias Apalodimas
wrote:
>
> On Sun, Oct 18, 2020 at 07:52:18PM +0200, Andrew Lunn wrote:
> > > --- a/Documentation/devicetree/bindings/net/socionext-netsec.txt
> > > +++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt
> > > @@ -30,7 +30,9 @@ Optional prop
asami Hiramatsu
Cc: Andrew Lunn
Cc: Willy Liu
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Masahisa Kojima
Cc: Serge Semin
Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver")
Signed-off-by: Ard Biesheuvel
---
Related discussion here:
https://lore.ker
On Sun, 18 Oct 2020 at 12:35, Ard Biesheuvel wrote:
>
> On Sun, 18 Oct 2020 at 01:02, Andrew Lunn wrote:
> >
> > On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote:
> > > (cc'ing some folks who may care about functional networking on SynQuacer)
>
On Sun, 18 Oct 2020 at 01:02, Andrew Lunn wrote:
>
> On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote:
> > (cc'ing some folks who may care about functional networking on SynQuacer)
> >
> > On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
> > >
(cc'ing some folks who may care about functional networking on SynQuacer)
On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
>
> > So we can fix this firmware by just setting phy-mode to the empty
> > string, right?
>
> I've never actually tried it, but i think so. There are no DT files
> actually
On Sat, 17 Oct 2020 at 20:27, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 08:11:24PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> > >
> > > > I have tried this, and it seems to fix the issue. I will send out a
> &
On Sat, 17 Oct 2020 at 20:11, Ard Biesheuvel wrote:
>
> On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> >
> > > I have tried this, and it seems to fix the issue. I will send out a
> > > patch against the netsec driver.
> >
> > Please also fix the firm
On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
>
> > I have tried this, and it seems to fix the issue. I will send out a
> > patch against the netsec driver.
>
> Please also fix the firmware so it does not pass rgmii.
>
> If there are pure DT systems, which do require phy-mode to be used, we
> w
On Sat, 17 Oct 2020 at 18:14, Ilias Apalodimas
wrote:
>
> Hi Ard,
>
> On Sat, Oct 17, 2020 at 05:18:16PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
> > >
> > > On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrot
On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
> > >
> > > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > > >
On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > Hello all,
> >
> > I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> > connectivity.
>
> Hi Ard
>
> Please coul
Hello all,
I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
connectivity. This box has a on-SoC socionext 'netsec' network
controller wired to a Realtek 80211e PHY, and this was working without
problems until the following commit was merged
commit bbc4d71d63549bcd003a430de18a
On Sat, 29 Aug 2020 at 18:43, J. Bruce Fields wrote:
>
> This code is rarely if ever used, and there are pending patches to
> remove it completely, so I don't think it's worth trying to fix a rare
> memory leak at this point.
>
> --b.
>
FYI I just submitted v3 of my series removing this code to t
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6
eless/iwd.git/commit/?id=1db8a85a60c64523
[1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2
[2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 10 ++
crypto/arc4.c | 10
nly
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
Acked-by: J. Bruce Fields
---
include/l
Drop some bogus Kconfig selects that are not entirely accurate, and
unnecessary to begin with, since the same Kconfig options also select
LIB80211 features that already imply the selected functionality (AES
for CCMP, ARC4 and ECB for TKIP)
Signed-off-by: Ard Biesheuvel
---
drivers/net/wireless
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192u/Kconfig | 1
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index d8aec5153b21..8c8e17d5fb20 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7
lds"
Cc: Chuck Lever
Cc: Eric Biggers
Cc: Arnd Bergmann
Cc: linux-cry...@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Ard Biesheuvel (7):
staging/rtl8192e: switch to RC4 library interface
staging/rtl8192u: switch to RC4 library
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6
Drop some bogus Kconfig selects that are not entirely accurate, and
unnecessary to begin with, since the same Kconfig options also select
LIB80211 features that already imply the selected functionality (AES
for CCMP, ARC4 and ECB for TKIP)
Signed-off-by: Ard Biesheuvel
---
drivers/net/wireless
On Mon, 24 Aug 2020 at 15:35, Herbert Xu wrote:
>
> On Mon, Aug 24, 2020 at 03:30:01PM +0200, Ard Biesheuvel wrote:
> >
> > +config CRYPTO_USER_ENABLE_OBSOLETE
> > + bool "Enable obsolete cryptographic algorithms for userspace"
> > + d
eless/iwd.git/commit/?id=1db8a85a60c64523
[1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2
[2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 10 ++
crypto/arc4.c | 10
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index d8aec5153b21..8c8e17d5fb20 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192u/Kconfig | 1
nly
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
Acked-by: J. Bruce Fields
---
include/l
driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Ard Biesheuvel (7):
staging/rtl8192e: switch to RC4 library interface
staging/rtl8192u: switch to RC4 library interface
SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
crypto: n2 - remove ecb(arc4) support
crypto: bcm-iproc - remove ecb(arc4) suppo
On Sat, 25 Jul 2020 at 10:06, Ard Biesheuvel wrote:
>
> On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote:
> >
> > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote:
> > >
> > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
> > > >
> >
On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote:
>
> On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote:
> >
> > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
> > >
> > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
> > > >
>
On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
> >
> > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
> > >
> > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
> > >
> &
On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
> >
> > [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
> >
> > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> > > Remove t
On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
>
> [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
>
> On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
> > a maintenance pe
.@driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Ard Biesheuvel (7):
staging/rtl8192e: switch to RC4 library interface
staging/rtl8192u: switch to RC4 library interface
SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
crypto: remove ARC4 support from the skcipher API
crypto: n2 -
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192u/Kconfig | 1 +
drivers/staging/rtl8192u
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 21 +--
crypto/testmgr.c | 7 ---
crypto/testmgr.h | 62
3 files changed, 1 insertion(+), 89 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index ba0b7702f2e9..72828c4acd3a 100644
--- a/crypto/tcrypt.c
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 6a828bbecea4..c347e58cd9a1 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers/staging/rtl8192e
we have in the tree, we can safely drop this code now
it no longer has any users.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 12
crypto/Makefile | 1 -
crypto/arc4.c| 76
nly
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
---
include/linux/sunrpc/gss_k
On Thu, 25 Jun 2020 at 21:16, David Miller wrote:
>
> From: Ard Biesheuvel
> Date: Thu, 25 Jun 2020 09:18:16 +0200
>
> > The skcipher API dynamically instantiates the transformation object
> > on request that implements the requested algorithm optimally on the
> >
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc:
Fixes: 28c5107aa904e ("net: phy: mscc: macsec support")
Reviewed-by: Eric Biggers
Signed-off-by: Ard Biesheuvel
---
v2:
- select CRYPTO_LIB_AES only if MACSEC is enabled
- add Eric's R-b
drivers/net/phy/Kconfig
On Wed, 24 Jun 2020 at 18:32, Eric Biggers wrote:
>
> On Wed, Jun 24, 2020 at 03:34:27PM +0200, Ard Biesheuvel wrote:
> > The skcipher API dynamically instantiates the transformation object on
> > request that implements the requested algorithm optimally on the given
> >
Kallweit
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc:
Fixes: 28c5107aa904e ("net: phy: mscc: macsec support")
Signed-off-by: Ard Biesheuvel
---
drivers/net/phy/Kconfig| 3 +-
drivers/net/phy/mscc/mscc_macsec.c | 40 +---
2 files changed,
On Thu, 18 Jul 2019 at 16:52, Jassi Brar wrote:
>
> On Thu, 18 Jul 2019 at 09:38, Ilias Apalodimas
> wrote:
> >
> > Add myself to maintainers since i provided the XDP and page_pool
> > implementation
> >
> Yes, please.
>
> Acked-by: Jassi Brar
>
Acked-by: Ard Biesheuvel
t; looping over the function.
> Since it has no performance penalty let's remove that and simplify the Rx
> path a bit
>
> Signed-off-by: Ilias Apalodimas
Acked-by: Ard Biesheuvel
> ---
> drivers/net/ethernet/socionext/netsec.c | 11 ++-
> 1 file changed, 2 inser
the
> value is not correctly initialized the device won't have any available
> descriptors
>
> Fixes: 35e07d23473972b8876f98bcfc631ebcf779e870 ("net: socionext: remove mmio
> reads on Tx")
>
> Signed-off-by: Ilias Apalodimas
Acked-by: Ard Biesheuvel
>
napi variant of the call is supposed to be used under softirq context
> only
>
Helpful, thanks. In general, commit logs need to describe *why* you do
something, since *what* you do is usually obvious from the patch
itself, but why you do it isn't.
With the above clarification added
On Thu, 18 Apr 2019 at 11:27, Ilias Apalodimas
wrote:
>
> Use netdev_alloc_frag during the Rx ring setup instead napi_alloc_frag
>
Why?
> Fixes: 4acb20b46214 ("net: socionext: different approach on DMA")
> Signed-off-by: Ilias Apalodimas
> ---
> drivers/net/ethernet/socionext/netsec.c | 11 +++
On Thu, 28 Feb 2019 at 16:14, Robin Murphy wrote:
>
> Hi Ard,
>
> On 28/02/2019 14:16, Ard Biesheuvel wrote:
> > (+ Catalin)
> >
> > On Tue, 19 Feb 2019 at 16:08, Ilias Apalodimas
> > wrote:
> >>
> >> On Tue, Feb 19, 2019 at 12:08:42AM +0100
(+ Catalin)
On Tue, 19 Feb 2019 at 16:08, Ilias Apalodimas
wrote:
>
> On Tue, Feb 19, 2019 at 12:08:42AM +0100, Ard Biesheuvel wrote:
> > It turns out that the IP checksumming code is still exercised often,
> > even though one might expect that modern NICs with checksum offlo
On Wed, 27 Feb 2019 at 11:02, Marc Zyngier wrote:
>
> + Lorenzo
>
> Hi Brian,
>
> On 26/02/2019 23:28, Brian Norris wrote:
> > + others
> >
> > Hi Marc,
> >
> > Thanks for the series. I have a few bits of history to add to this, and
> > some comments.
> >
> > On Sun, Feb 24, 2019 at 02:04:22PM +00
On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote:
>
> Hi Ard,
>
> On 25/02/2019 12:45, Ard Biesheuvel wrote:
> > On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote:
> >>
> >> For quite some time, I wondered why the PCI mwifiex device built in my
> >&
On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote:
>
> For quite some time, I wondered why the PCI mwifiex device built in my
> Chromebook was unable to use the good old legacy interrupts. But as MSIs
> were working fine, I never really bothered investigating. I finally had a
> look, and the result
size > 64 bytes, in order to reduce the number of branches
and improve performance on cores with deep pipelines.
On Cortex-A57, this implementation is on par with Lingyan's NEON
implementation, and roughly 7x as fast as the generic C code.
Cc: "huanglingyan (A)"
Signed-off-
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote:
>
> On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > > Variables declared in a switch statement before any case statements
> > > cannot be initialized, so move all instances out of the
On Fri, 21 Dec 2018 at 20:57, Edgecombe, Rick P
wrote:
>
> On Fri, 2018-12-21 at 18:25 +0100, Ard Biesheuvel wrote:
> > On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski
> > wrote:
> > > > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel <
> > > > ard.biesh
On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski wrote:
>
> > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel
> > wrote:
> >
> >> On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote:
> >>
> >> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote:
>
> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> wrote:
> >
> > This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPECIAL_PERMS, for
> > enabling vfree operations to immediately clear executable TLB entries to
> > freed
> > pages, and
On Fri, 14 Dec 2018 at 12:18, Ilias Apalodimas
wrote:
>
> On Fri, Dec 14, 2018 at 11:59:00AM +0100, Ard Biesheuvel wrote:
> > On Fri, 14 Dec 2018 at 09:59, Ilias Apalodimas
> > wrote:
> > >
> > > Currently the driver issues 2 mmio reads to figure out the num
On Fri, 14 Dec 2018 at 09:59, Ilias Apalodimas
wrote:
>
> Currently the driver issues 2 mmio reads to figure out the number of
> transmitted packets and clean them. We can get rid of the expensive
> reads since BIT 31 of the Tx descriptor can be used for that.
> We can also remove the budget count
On Thu, 6 Dec 2018 at 20:30, Will Deacon wrote:
>
> On Thu, Dec 06, 2018 at 08:23:20PM +0100, Ard Biesheuvel wrote:
> > On Thu, 6 Dec 2018 at 20:21, Andy Lutomirski wrote:
> > >
> > > On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel
> > > wrote:
> >
On Thu, 6 Dec 2018 at 20:21, Andy Lutomirski wrote:
>
> On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel
> wrote:
> >
> > On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski wrote:
> > >
>
> > > That’s not totally nuts. Do we ever have code that expects __v
On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski wrote:
>
> > On Dec 5, 2018, at 11:29 PM, Ard Biesheuvel
> > wrote:
> >
> >> On Thu, 6 Dec 2018 at 00:16, Andy Lutomirski wrote:
> >>
> >>> On Wed, Dec 5, 2018 at 3:41 AM Will Deacon wrote:
&g
> > > such
> > > > > > > as executable.
> > > > > >
> > > > > > So I am trying to finish my patch-set for preventing transient W+X
> > > > > > mappings
> > > > > > from taking space, by handling
On Mon, 3 Dec 2018 at 13:49, Will Deacon wrote:
>
> On Fri, Nov 30, 2018 at 08:20:06PM +0100, Ard Biesheuvel wrote:
> > On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote:
> > >
> > > On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:
> > > >
On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote:
>
> On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:
> > The arm64 module region is a 128 MB region that is kept close to
> > the core kernel, in order to ensure that relative branches are
> > always in
c: Daniel Borkmann
Cc: Alexei Starovoitov
Cc: Rick Edgecombe
Cc: Eric Dumazet
Cc: Jann Horn
Cc: Kees Cook
Cc: Jessica Yu
Cc: Arnd Bergmann
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: "David S. Miller"
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.ke
By default, BPF uses module_alloc() to allocate executable memory,
but this is not necessary on all arches and potentially undesirable
on some of them.
So break out the module_alloc() and module_memfree() calls into __weak
functions to allow them to be overridden in arch code.
Signed-off-by: Ard
1 - 100 of 203 matches
Mail list logo