Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure

2019-08-20, 12:01:40 +0200, Antoine Tenart wrote: > So it seems the ability to enable or disable the offloading on a given > interface is the main missing feature. I'll add that, however I'll > probably (at least at first): > > - Have the interface to be fully offloaded or fully handled in s/w

Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure

2019-08-13, 16:18:40 +, Igor Russkikh wrote: > On 13.08.2019 16:17, Andrew Lunn wrote: > > On Tue, Aug 13, 2019 at 10:58:17AM +0200, Antoine Tenart wrote: > >> I think this question is linked to the use of a MACsec virtual interface > >> when using h/w offloading. The starting point for me was

Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure

2019-08-13, 18:28:23 +0200, Andrew Lunn wrote: > > 1) With current implementation it's impossible to install SW macsec engine > > onto > > the device which supports HW offload. That could be a strong limitation in > > cases when user sees HW macsec offload is broken or work differently, and > >

Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure

2019-08-13, 10:58:17 +0200, Antoine Tenart wrote: > Hi Igor, > > On Sat, Aug 10, 2019 at 01:20:32PM +, Igor Russkikh wrote: > > On 08.08.2019 17:05, Antoine Tenart wrote: > > > > > The Rx and TX handlers are modified to take in account the special case > > > were the MACsec transformation

Re: linux-next: Signed-off-by missing for commits in the net-next tree

2018-12-10, 14:35:00 +0100, Andrew Lunn wrote: > > The problem here is the '--' delimiter, Andrew should have either > > used nothing or something else. > > I picked -- because it was not --- ! > > Anyway, lesson learned. But i kind of expect it will happen again to > others, since the

Re: linux-next: Signed-off-by missing for commits in the net-next tree

2018-12-09, 22:49:07 +0100, Andrew Lunn wrote: > On Sun, Dec 09, 2018 at 10:33:10PM +0100, Heiner Kallweit wrote: > > On 09.12.2018 22:11, Andrew Lunn wrote: > > > On Mon, Dec 10, 2018 at 08:00:45AM +1100, Stephen Rothwell wrote: > > >> Hi all, > > >> > > >> Commits > > >> > > >> dc9d38cec71c

Re: Regression with 5dcd8400884c ("macsec: missing dev_put() on error in macsec_newlink()")

Hello Laura, 2018-04-14, 10:56:55 -0700, Laura Abbott wrote: > Hi, > > Fedora got a bug report of a regression when trying to remove the > the macsec module (https://bugzilla.redhat.com/show_bug.cgi?id=1566410). > I did a bisect and found > > commit 5dcd8400884cc4a043a6d4617e042489e5d566a9 >

Re: Regression with 5dcd8400884c ("macsec: missing dev_put() on error in macsec_newlink()")

Hello Laura, 2018-04-14, 10:56:55 -0700, Laura Abbott wrote: > Hi, > > Fedora got a bug report of a regression when trying to remove the > the macsec module (https://bugzilla.redhat.com/show_bug.cgi?id=1566410). > I did a bisect and found > > commit 5dcd8400884cc4a043a6d4617e042489e5d566a9 >

Re: [PATCH] net: ipv4: avoid unused variable warning for sysctl

other variables like it, to avoid the harmless > warning. > > Fixes: c7272c2f1229 ("net: ipv4: don't allow setting net.ipv4.route.min_pmtu > below 68") > Signed-off-by: Arnd Bergmann <a...@arndb.de> Crap. Thanks, and sorry for the mess. Acked-by: Sabrina Dubroca <s...@queasysnail.net> -- Sabrina

Re: [PATCH] net: ipv4: avoid unused variable warning for sysctl

other variables like it, to avoid the harmless > warning. > > Fixes: c7272c2f1229 ("net: ipv4: don't allow setting net.ipv4.route.min_pmtu > below 68") > Signed-off-by: Arnd Bergmann Crap. Thanks, and sorry for the mess. Acked-by: Sabrina Dubroca -- Sabrina

[PATCH crypto] crypto: aesni - add wrapper for generic gcm(aes)

) Reported-by: Ilya Lesokhin <il...@mellanox.com> Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> Reviewed-by: Stefano Brivio <sbri...@redhat.com> --- arch/x86/crypto/aesni-intel_glue.c | 66 +++--- 1 file changed, 54 insertions(+), 12 deletions(-)

[PATCH crypto] crypto: aesni - add wrapper for generic gcm(aes)

) Reported-by: Ilya Lesokhin Signed-off-by: Sabrina Dubroca Reviewed-by: Stefano Brivio --- arch/x86/crypto/aesni-intel_glue.c | 66 +++--- 1 file changed, 54 insertions(+), 12 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-in

[PATCH crypto] crypto: aesni - fix typo in generic_gcmaes_decrypt

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> Reviewed-by: Stefano Brivio <sbri...@redhat.com> --- arch/x86/crypto/aesni-intel_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c index 3bf3

[PATCH crypto] crypto: aesni - fix typo in generic_gcmaes_decrypt

Signed-off-by: Sabrina Dubroca Reviewed-by: Stefano Brivio --- arch/x86/crypto/aesni-intel_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c index 3bf3dcf29825..8981ed1eb7ad 100644 --- a/arch/x86/cr

[PATCH] tracing/kprobes: allow to create probe with a module name starting with a digit

for this command to work: perf probe -m 8021q -a vlan_gro_receive Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- kernel/trace/trace_kprobe.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kp

[PATCH] tracing/kprobes: allow to create probe with a module name starting with a digit

for this command to work: perf probe -m 8021q -a vlan_gro_receive Signed-off-by: Sabrina Dubroca --- kernel/trace/trace_kprobe.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index c129fca6ec99

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-05-15, 21:18:35 +0800, Dave Young wrote: > On 05/15/17 at 01:10pm, Sabrina Dubroca wrote: > > 2017-05-15, 16:37:40 +0800, Dave Young wrote: > > > diff --git a/arch/x86/platform/efi/efi-bgrt.c > > > b/arch/x86/platform/efi/efi-bgrt.c > > > index 04ca876.

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-05-15, 21:18:35 +0800, Dave Young wrote: > On 05/15/17 at 01:10pm, Sabrina Dubroca wrote: > > 2017-05-15, 16:37:40 +0800, Dave Young wrote: > > > diff --git a/arch/x86/platform/efi/efi-bgrt.c > > > b/arch/x86/platform/efi/efi-bgrt.c > > > index 04ca876.

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-05-15, 16:37:40 +0800, Dave Young wrote: > Hi, > > Thanks for the report. > On 05/14/17 at 01:18am, Sabrina Dubroca wrote: > > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > > > From: Dave Young <dyo...@redhat.com> > > > > > > Before

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-05-15, 16:37:40 +0800, Dave Young wrote: > Hi, > > Thanks for the report. > On 05/14/17 at 01:18am, Sabrina Dubroca wrote: > > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > > > From: Dave Young > > > > > > Before invoking the arch

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > From: Dave Young > > Before invoking the arch specific handler, efi_mem_reserve() reserves > the given memory region through memblock. > > efi_bgrt_init() will call efi_mem_reserve() after mm_init(), at which > time memblock

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > From: Dave Young > > Before invoking the arch specific handler, efi_mem_reserve() reserves > the given memory region through memblock. > > efi_bgrt_init() will call efi_mem_reserve() after mm_init(), at which > time memblock is dead and should

Re: [PATCH v9 3/3] printk: fix double printing with earlycon

Hi Aleksey, 2017-04-05, 23:20:00 +0300, Aleksey Makarov wrote: > If a console was specified by ACPI SPCR table _and_ command line > parameters like "console=ttyAMA0" _and_ "earlycon" were specified, > then log messages appear twice. > > The root cause is that the code traverses the list of

Re: [PATCH v9 3/3] printk: fix double printing with earlycon

Hi Aleksey, 2017-04-05, 23:20:00 +0300, Aleksey Makarov wrote: > If a console was specified by ACPI SPCR table _and_ command line > parameters like "console=ttyAMA0" _and_ "earlycon" were specified, > then log messages appear twice. > > The root cause is that the code traverses the list of

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote: > This is a defense-in-depth measure in response to bugs like > 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While > we're at it, we also limit the amount of recursion this function is > allowed to do. Not actually providing a

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote: > This is a defense-in-depth measure in response to bugs like > 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While > we're at it, we also limit the amount of recursion this function is > allowed to do. Not actually providing a

[PATCH 1/7] crypto: aesni: make non-AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_asm.S

[PATCH 1/7] crypto: aesni: make non-AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 169 +- 1 file

[PATCH 2/7] crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_asm.S | 62 ++- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 605726

[PATCH 2/7] crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 62 ++- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 605726aaf0a2..16627fec80b2 100644

[PATCH 6/7] crypto: aesni: make AVX2 AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S

[PATCH 6/7] crypto: aesni: make AVX2 AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index 7230808a7cef..faecb1518bf8

[PATCH 4/7] crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S

[PATCH 4/7] crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index a73117c84904..ee6283120f83

[PATCH 7/7] crypto: aesni: add generic gcm(aes)

Now that the asm side of things can support all the valid lengths of ICV and all lengths of associated data, provide the glue code to expose a generic gcm(aes) crypto algorithm. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_glue.c

[PATCH 7/7] crypto: aesni: add generic gcm(aes)

Now that the asm side of things can support all the valid lengths of ICV and all lengths of associated data, provide the glue code to expose a generic gcm(aes) crypto algorithm. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_glue.c | 208 - 1

[PATCH 5/7] crypto: aesni: make AVX2 AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.

[PATCH 5/7] crypto: aesni: make AVX2 AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 85 ++-- 1 file

[PATCH 3/7] crypto: aesni: make AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.S

[PATCH 3/7] crypto: aesni: make AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 122 ++- 1 file

[PATCH 0/7] crypto: aesni: provide generic gcm(aes)

6.3Gbps). Sabrina Dubroca (7): crypto: aesni: make non-AVX AES-GCM work with any aadlen crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len crypto: aesni: make AVX AES-GCM work with any aadlen crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len crypto: aesni

[PATCH 0/7] crypto: aesni: provide generic gcm(aes)

6.3Gbps). Sabrina Dubroca (7): crypto: aesni: make non-AVX AES-GCM work with any aadlen crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len crypto: aesni: make AVX AES-GCM work with any aadlen crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len crypto: aesni

Re: [PATCH] iov_iter: don't revert if csum error

2017-04-28, 20:48:45 +0800, Ding Tianhong wrote: > The patch 3278682 (make skb_copy_datagram_msg() et.al. preserve > ->msg_iter on error) will revert the iov buffer if copy to iter > failed, but it looks no need to revert for csum error, so fix it. > > Fixes: 3278682 ("make

Re: [PATCH] iov_iter: don't revert if csum error

2017-04-28, 20:48:45 +0800, Ding Tianhong wrote: > The patch 3278682 (make skb_copy_datagram_msg() et.al. preserve > ->msg_iter on error) will revert the iov buffer if copy to iter > failed, but it looks no need to revert for csum error, so fix it. > > Fixes: 3278682 ("make

Re: [PATCH v6 3/5] rxrpc: check return value of skb_to_sgvec always

2017-04-25, 20:47:32 +0200, Jason A. Donenfeld wrote: > Signed-off-by: Jason A. Donenfeld > --- > net/rxrpc/rxkad.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c > index 4374e7b9c7bf..dcf46c9c3ece

Re: [PATCH v6 3/5] rxrpc: check return value of skb_to_sgvec always

2017-04-25, 20:47:32 +0200, Jason A. Donenfeld wrote: > Signed-off-by: Jason A. Donenfeld > --- > net/rxrpc/rxkad.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c > index 4374e7b9c7bf..dcf46c9c3ece 100644 > ---

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-27, 11:21:51 +0200, Jason A. Donenfeld wrote: > However, perhaps there's the chance that fraglist skbs having > separate fraglists are actually forbidden? Is this the case? Hmm, I think this can actually happen: /* net/ipv4/ip_fragment.c */ static int ip_frag_reasm(struct ipq

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-27, 11:21:51 +0200, Jason A. Donenfeld wrote: > However, perhaps there's the chance that fraglist skbs having > separate fraglists are actually forbidden? Is this the case? Hmm, I think this can actually happen: /* net/ipv4/ip_fragment.c */ static int ip_frag_reasm(struct ipq

Re: [PATCH v2] macsec: dynamically allocate space for sglist

> > Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> > Cc: Sabrina Dubroca <s...@queasysnail.net> > Cc: secur...@kernel.org > Cc: sta...@vger.kernel.org Acked-by: Sabrina Dubroca <s...@queasysnail.net> Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.

Re: [PATCH v2] macsec: dynamically allocate space for sglist

> > Signed-off-by: Jason A. Donenfeld > Cc: Sabrina Dubroca > Cc: secur...@kernel.org > Cc: sta...@vger.kernel.org Acked-by: Sabrina Dubroca Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Fixes: CVE-2017-7477 David, this fix is essentially equiv

Re: [PATCH] macsec: dynamically allocate space for sglist

> > Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> > Cc: Sabrina Dubroca <s...@queasysnail.net> > Cc: secur...@kernel.org > Cc: sta...@vger.kernel.org > --- > drivers/net/macsec.c | 25 - > 1 file changed, 20 insertions(+), 5 delet

Re: [PATCH] macsec: dynamically allocate space for sglist

> > Signed-off-by: Jason A. Donenfeld > Cc: Sabrina Dubroca > Cc: secur...@kernel.org > Cc: sta...@vger.kernel.org > --- > drivers/net/macsec.c | 25 - > 1 file changed, 20 insertions(+), 5 deletions(-) > > diff --git a/drivers/n

Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec

2017-04-25, 17:08:28 +0200, Jason A. Donenfeld wrote: > Hi Sabrina, > > On Tue, Apr 25, 2017 at 4:53 PM, Sabrina Dubroca <s...@queasysnail.net> wrote: > > Ugh, good catch :/ > > > > AFAICT this patch doesn't really help, because NETIF_F_FRAGLIST > > do

Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec

2017-04-25, 17:08:28 +0200, Jason A. Donenfeld wrote: > Hi Sabrina, > > On Tue, Apr 25, 2017 at 4:53 PM, Sabrina Dubroca wrote: > > Ugh, good catch :/ > > > > AFAICT this patch doesn't really help, because NETIF_F_FRAGLIST > > doesn't get tested in

Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec

2017-04-21, 23:14:48 +0200, Jason A. Donenfeld wrote: > While this may appear as a humdrum one line change, it's actually quite > important. An sk_buff stores data in three places: > > 1. A linear chunk of allocated memory in skb->data. This is the easiest >one to work with, but it precludes

Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec

2017-04-21, 23:14:48 +0200, Jason A. Donenfeld wrote: > While this may appear as a humdrum one line change, it's actually quite > important. An sk_buff stores data in three places: > > 1. A linear chunk of allocated memory in skb->data. This is the easiest >one to work with, but it precludes

Re: net/xfrm: stack-out-of-bounds in xfrm_state_find

2017-04-20, 19:30:27 +0200, Andrey Konovalov wrote: > On Thu, Apr 20, 2017 at 6:47 PM, Andrey Konovalov > wrote: > > Hi, > > > > I've got the following error report while fuzzing the kernel with syzkaller. > > > > On linux-next commit

Re: net/xfrm: stack-out-of-bounds in xfrm_state_find

2017-04-20, 19:30:27 +0200, Andrey Konovalov wrote: > On Thu, Apr 20, 2017 at 6:47 PM, Andrey Konovalov > wrote: > > Hi, > > > > I've got the following error report while fuzzing the kernel with syzkaller. > > > > On linux-next commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > > >

Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers

2016-10-18, 22:33:33 -0400, Jarod Wilson wrote: [...] > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c > index 309311b..b5f125c 100644 > --- a/drivers/firewire/net.c > +++ b/drivers/firewire/net.c > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, > struct

Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers

2016-10-18, 22:33:33 -0400, Jarod Wilson wrote: [...] > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c > index 309311b..b5f125c 100644 > --- a/drivers/firewire/net.c > +++ b/drivers/firewire/net.c > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, > struct

Re: [PATCH net-next 4/6] net: use core MTU range checking in core net infra

2016-10-19, 10:40:06 -0400, Jarod Wilson wrote: > On Wed, Oct 19, 2016 at 03:55:29PM +0200, Sabrina Dubroca wrote: > > 2016-10-18, 22:33:31 -0400, Jarod Wilson wrote: > > > geneve: > > > - Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu > > >

Re: [PATCH net-next 4/6] net: use core MTU range checking in core net infra

2016-10-19, 10:40:06 -0400, Jarod Wilson wrote: > On Wed, Oct 19, 2016 at 03:55:29PM +0200, Sabrina Dubroca wrote: > > 2016-10-18, 22:33:31 -0400, Jarod Wilson wrote: > > > geneve: > > > - Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu > > >

Re: [PATCH net-next 4/6] net: use core MTU range checking in core net infra

2016-10-18, 22:33:31 -0400, Jarod Wilson wrote: > geneve: > - Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu > - This one isn't quite as straight-forward as others, could use some > closer inspection and testing > > macvlan: > - set min/max_mtu > > tun: > - set min/max_mtu,

Re: [PATCH net-next 4/6] net: use core MTU range checking in core net infra

2016-10-18, 22:33:31 -0400, Jarod Wilson wrote: > geneve: > - Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu > - This one isn't quite as straight-forward as others, could use some > closer inspection and testing > > macvlan: > - set min/max_mtu > > tun: > - set min/max_mtu,

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

2016-07-28, 07:43:55 +0200, Eric Dumazet wrote: > On Wed, 2016-07-27 at 14:38 -0700, Jeff Kirsher wrote: > > On Tue, 2016-07-26 at 11:14 +0200, Eric Dumazet wrote: > > > Could you try this ? > > > > > > diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c > > >

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

2016-07-28, 07:43:55 +0200, Eric Dumazet wrote: > On Wed, 2016-07-27 at 14:38 -0700, Jeff Kirsher wrote: > > On Tue, 2016-07-26 at 11:14 +0200, Eric Dumazet wrote: > > > Could you try this ? > > > > > > diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c > > >

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

Hello, 2016-04-27, 17:14:44 -0700, Ben Greear wrote: > On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote: > > Hi Ben, > > > > On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote: > > > On Wed, 2016-04-27 at 08:59 -0700, Ben Greear wrote: > > > > On 04/26/2016 04:02 PM, Ben Hutchings wrote: > >

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

Hello, 2016-04-27, 17:14:44 -0700, Ben Greear wrote: > On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote: > > Hi Ben, > > > > On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote: > > > On Wed, 2016-04-27 at 08:59 -0700, Ben Greear wrote: > > > > On 04/26/2016 04:02 PM, Ben Hutchings wrote: > >

Re: [PATCH v3 3/3] netconsole: implement extended console support

Hi Tejun, 2015-05-04, 16:04:56 -0400, Tejun Heo wrote: [...] > +/** > + * send_ext_msg_udp - send extended log message to target > + * @nt: target to send message to > + * @msg: extended log message to send > + * @msg_len: length of message > + * > + * Transfer extended log @msg to @nt. If

Re: [PATCH v3 3/3] netconsole: implement extended console support

Hi Tejun, 2015-05-04, 16:04:56 -0400, Tejun Heo wrote: [...] +/** + * send_ext_msg_udp - send extended log message to target + * @nt: target to send message to + * @msg: extended log message to send + * @msg_len: length of message + * + * Transfer extended log @msg to @nt. If @msg is

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete "struct pt_regs"

2015-02-26, 14:54:33 +0100, Denys Vlasenko wrote: > On Thu, Feb 26, 2015 at 1:11 PM, Denys Vlasenko > wrote: > > On Thu, Feb 26, 2015 at 10:55 AM, Denys Vlasenko > > wrote: > >> On Wed, Feb 25, 2015 at 10:59 PM, Andy Lutomirski > >> wrote: > >> In addition to my previous tests, I ran my home

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete struct pt_regs

2015-02-26, 14:54:33 +0100, Denys Vlasenko wrote: On Thu, Feb 26, 2015 at 1:11 PM, Denys Vlasenko vda.li...@googlemail.com wrote: On Thu, Feb 26, 2015 at 10:55 AM, Denys Vlasenko vda.li...@googlemail.com wrote: On Wed, Feb 25, 2015 at 10:59 PM, Andy Lutomirski l...@amacapital.net wrote:

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete "struct pt_regs"

2015-02-25, 23:40:55 +0100, Sabrina Dubroca wrote: > I can run some userspace programs, but I have no idea what would be > helpful. > I can also try booting a real machine with archlinux/systemd tomorrow. I got a good boot out of kernels that normally fail. I booted systemd's emerge

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete "struct pt_regs"

2015-02-25, 13:59:06 -0800, Andy Lutomirski wrote: > On Wed, Feb 25, 2015 at 1:28 PM, Denys Vlasenko wrote: > > On 02/25/2015 09:10 PM, Andy Lutomirski wrote: > >> On Wed, Feb 25, 2015 at 11:59 AM, Andrey Wagin wrote: > >>> 2015-02-25 21:42 GMT+03:00 Denys Vlasenko : > On 02/25/2015 01:37

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete "struct pt_regs"

Hello, I'm seeing the same symptoms on next-2015022{4,5}, also with systemd in a VM: traps: fsck[99] general protection ip:7fccb2401270 sp:7fffea3b8938 error:0 in libc-2.21.so[7fccb2349000+199000] traps: systemd-cgroups[100] general protection ip:7fdd8ff784f8 sp:7ffcf6e27ad8 error:0 in

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete struct pt_regs

Hello, I'm seeing the same symptoms on next-2015022{4,5}, also with systemd in a VM: traps: fsck[99] general protection ip:7fccb2401270 sp:7fffea3b8938 error:0 in libc-2.21.so[7fccb2349000+199000] traps: systemd-cgroups[100] general protection ip:7fdd8ff784f8 sp:7ffcf6e27ad8 error:0 in

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete struct pt_regs

2015-02-25, 13:59:06 -0800, Andy Lutomirski wrote: On Wed, Feb 25, 2015 at 1:28 PM, Denys Vlasenko dvlas...@redhat.com wrote: On 02/25/2015 09:10 PM, Andy Lutomirski wrote: On Wed, Feb 25, 2015 at 11:59 AM, Andrey Wagin ava...@gmail.com wrote: 2015-02-25 21:42 GMT+03:00 Denys Vlasenko

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete struct pt_regs

2015-02-25, 23:40:55 +0100, Sabrina Dubroca wrote: I can run some userspace programs, but I have no idea what would be helpful. I can also try booting a real machine with archlinux/systemd tomorrow. I got a good boot out of kernels that normally fail. I booted systemd's emergency shell

Re: linux-next: Tree for Feb 13

2015-02-13, 16:56:15 +1100, Stephen Rothwell wrote: > Hi all, > > Please do not add any material destined for v3.21 to your linux-next > included trees until after v3.20-rc1 has been released. > > Changes since 20150212: Hi Stephen, Your conflict resolution in 8fe7fba50596 "Merge branch

Re: linux-next: Tree for Feb 13

2015-02-13, 16:56:15 +1100, Stephen Rothwell wrote: Hi all, Please do not add any material destined for v3.21 to your linux-next included trees until after v3.20-rc1 has been released. Changes since 20150212: Hi Stephen, Your conflict resolution in 8fe7fba50596 Merge branch

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 21:28:33 +, Al Viro wrote: > On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote: > > ok case (putname commented out): > > > > user_path_at_empty lookup usr flags 0x0 > > path_lookupat: calling path_init 'usr' flags=40 > > path_init: link_path_walk() returned 0 > >

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 13:03:20 -0800, Guenter Roeck wrote: > On 01/21/2015 12:06 PM, Al Viro wrote: > >On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote: > >>On 01/21/2015 10:29 AM, Al Viro wrote: > >>>On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote: > Another data point

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 16:39:12 +0100, Thierry Reding wrote: > On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote: > > On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote: > > > On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote: > > > > 2015-

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 04:36:38 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: > > With this patch: > > > > sys_mkdir .:40775 returned -17 > > sys_mkdir usr:40775 returned 0 > > sys_mkdir usr/lib:40775 returned 0 > > sys_mkdir usr/share:40755 returned 0 > > sys_mkdir

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 16:39:12 +0100, Thierry Reding wrote: On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote: On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote: On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote: 2015-01-21, 04:36:38 +, Al Viro wrote

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 13:03:20 -0800, Guenter Roeck wrote: On 01/21/2015 12:06 PM, Al Viro wrote: On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote: On 01/21/2015 10:29 AM, Al Viro wrote: On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote: Another data point (though I have no

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 21:28:33 +, Al Viro wrote: On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote: ok case (putname commented out): user_path_at_empty lookup usr flags 0x0 path_lookupat: calling path_init 'usr' flags=40 path_init: link_path_walk() returned 0 path_lookupat:

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-21, 04:36:38 +, Al Viro wrote: On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote: With this patch: sys_mkdir .:40775 returned -17 sys_mkdir usr:40775 returned 0 sys_mkdir usr/lib:40775 returned 0 sys_mkdir usr/share:40755 returned 0 sys_mkdir

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 23:17:25 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote: > > doesn't look at _anything_ other than name->name other than for > > audit_inode(). > > And name->name is apparently the same. > > > > It looks like something ends up buggering name->name in

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 21:58:31 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: > > > [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 > > [1.539704] fn_lookup bsg 0, 88001f718000 bsg > > [1.540559]

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 21:02:03 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: > > > printk(KERN_ERR "fn_lookup %s %d\n", name, retval); > > > > and I get: > > > > [1.618558] fn_lookup bsg/0:0:0:0 -2 > &

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 19:54:32 +, Al Viro wrote: > On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote: > > 2015-01-20, 12:39:08 -0500, Paul Moore wrote: > > > On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote: > > > > Hello, > > > >

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 12:39:08 -0500, Paul Moore wrote: > On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote: > > Hello, > > > > Today's linux-next doesn't boot on my qemu VM: > > ... > > > I bisected it down to: > > > > 5dc5218840e1 fs: cre

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

Hello, Today's linux-next doesn't boot on my qemu VM: [1.248357] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK0 PQ: 0 ANSI: 5 [1.255899] sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB) [1.258333] sd 0:0:0:0: [sda] Write Protect is off [

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

Hello, Today's linux-next doesn't boot on my qemu VM: [1.248357] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK0 PQ: 0 ANSI: 5 [1.255899] sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB) [1.258333] sd 0:0:0:0: [sda] Write Protect is off [

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 12:39:08 -0500, Paul Moore wrote: On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote: Hello, Today's linux-next doesn't boot on my qemu VM: ... I bisected it down to: 5dc5218840e1 fs: create proper filename objects using getname_kernel() I

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 21:02:03 +, Al Viro wrote: On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote: printk(KERN_ERR fn_lookup %s %d\n, name, retval); and I get: [1.618558] fn_lookup bsg/0:0:0:0 -2 [1.619437] fn_lookup bsg 0 [1.620236] fn_lookup bsg/0:0:0:0 -2

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 21:58:31 +, Al Viro wrote: On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote: [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0 [1.539704] fn_lookup bsg 0, 88001f718000 bsg [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 23:17:25 +, Al Viro wrote: On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote: doesn't look at _anything_ other than name-name other than for audit_inode(). And name-name is apparently the same. It looks like something ends up buggering name-name in process, but

Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs

2015-01-20, 19:54:32 +, Al Viro wrote: On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote: 2015-01-20, 12:39:08 -0500, Paul Moore wrote: On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote: Hello, Today's linux-next doesn't boot on my qemu VM

  1   2   >