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
> > > b/drivers/net/ethernet/intel/e
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
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
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
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.
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 ("n
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 "Submittin
to the 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
Hi,
2014-03-14, 12:05:01 -0400, Valdis Kletnieks wrote:
> Surprisingly enough, this hasn't seemed to have bitten many Linux people yet,
> Google only finds a BSD thread (where the same ACPICA code is in use):
>
> http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817
I was about to report th
Hi,
2014-03-18, 00:50:04 +, Zheng, Lv wrote:
> Hi, Sabrina and Valdis
>
> Could you give this patch a try to see if this patch is working?
>
> Thanks and best regards
> -Lv
I applied the two patches. The laptop boots and there is no ACPI
error in the logs, both with auto-serialization enabl
2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> >
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box. See below for an alternative.
>
> Urgh, I see, we call the idle arch_cpu_idle() callback
2014-03-24, 20:11:12 +0200, Mika Westerberg wrote:
> On Mon, Mar 24, 2014 at 08:00:33PM +0200, Mika Westerberg wrote:
> > On Mon, Mar 24, 2014 at 04:49:44PM +0100, Sabrina Dubroca wrote:
> > > Hi,
> > >
> > > With next-20140324, I get the BUG below when I
2014-03-25, 09:25:30 +0200, Mika Westerberg wrote:
> On Mon, Mar 24, 2014 at 07:31:11PM +0100, Sabrina Dubroca wrote:
> > > Actually gpiolib seems to handle ->dev as optional. Can you try this patch
> > > instead? Thanks.
> > >
> > > diff --git a/drivers/
gt; [] bus_for_each_dev+0x47/0x80
> [] driver_attach+0x1e/0x20
> [] ? __device_attach+0x40/0x40
> [] bus_add_driver+0x157/0x230
> [] driver_register+0x59/0xe0
> ...
>
> Fix this by checking chip->dev pointer against NULL first. Also we can now
> remove redundant check in a
c
[1.749469] [] x86_64_start_reservations+0x2a/0x2c
[1.749470] [] x86_64_start_kernel+0x169/0x178
[1.749471] ---[ end trace d478ba7c30908d4d ]---
--
Sabrina Dubroca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
2014-02-04, 13:20:54 +1000, Dave Airlie wrote:
> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca wrote:
> > When I boot 3.14-rc1 in qemu, I get the trace below. The console stops
> > updating and I don't get a login prompt. I can login, but I can't see
> > what I&#x
2014-02-05, 14:50:18 +1000, Dave Airlie wrote:
> On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca wrote:
> > 2014-02-04, 13:20:54 +1000, Dave Airlie wrote:
> >> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca
> >> wrote:
> >> > When I boot 3.14-rc1 in q
Hello,
2014-08-21, 18:08:09 +0200, Radim Krčmář wrote:
> Tracepoint for dynamic PLE window, fired on every potential change.
>
> Signed-off-by: Radim Krčmář
> ---
> arch/x86/kvm/trace.h | 30 ++
> arch/x86/kvm/vmx.c | 10 --
> arch/x86/kvm/x86.c | 1 +
>
2014-08-19, 13:06:07 -0400, valdis.kletni...@vt.edu wrote:
> On Sat, 16 Aug 2014 20:27:01 -0700, Hugh Dickins said:
> > Can we safely revert your 8b37e1bef5a6 ("leds: convert blink timer to
> > workqueue"), or have there been other changes which now depend upon it?
>
> I suspect there's something
Hello,
Since next-20140823:
# hdparm -B 200 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0xc8 (200)
HDIO_DRIVE_CMD failed: Bad address
APM_level = 128
It looks like before commit 2cada584b200 ("block: cleanup error
handling in sg_io"), we had ret = 0 before entering t
ad address
APM_level = 128
Signed-off-by: Sabrina Dubroca
Fixes: 2cada584b200 ("block: cleanup error handling in sg_io")
---
block/scsi_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 5dd477bfb4bc..9b8eaeca6a79 100644
--- a/bloc
the same
> tree with this patch on top of it boots without warning. Soo...
>
> Tested-By: Valdis Kletnieks
Same for me.
Tested-by: Sabrina Dubroca
Thanks,
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
2014-08-26, 22:02:08 +0200, Sabrina Dubroca wrote:
> [...]
>
> Tested-by: Sabrina Dubroca
Forgot to mention, this applies to both versions of the patch.
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
Hello,
While fuzzing with trinity on next-20140827, I ran into this:
[ 2059.161014] BUG: sleeping function called from invalid context at
arch/x86/mm/fault.c:1177
[ 2059.162968] in_atomic(): 0, irqs_disabled(): 1, pid: 3225, name: trinity-c0
[ 2059.163142] INFO: lockdep is turned off.
[ 2059.163
2014-08-29, 11:14:48 -0700, Cong Wang wrote:
> On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala wrote:
> > [ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
> > [ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+
> > #30
> > [ 77.299039] Hardware name: Boc
2014-08-29, 15:54:48 -0700, Cong Wang wrote:
> [...]
>
> You are absolutely right here.
>
> Can I have your Signed-off-by and Tested-by before sending the patch
> formally?
>
> Thanks!
Sure:
Signed-off-by: Sabrina Dubroca
Tested-by: Sabrina Dubroca
Thanks,
--
S
Hello,
2014-08-30, 03:51:29 +0200, Hannes Frederic Sowa wrote:
> Hi Sabrina,
>
> [...]
>
> Sorry, just had time to look at this.
>
> The reason is not to have list corruption but that the calls down to
> ndo_set_rx_mode expect rtnl to be locked by the drivers. Filter lists
> are locked by addr_
2014-08-30, 12:58:21 +0200, Sabrina Dubroca wrote:
>- pndisc_constructor, called from pneigh_lookup -- pneigh_lookup
> has ASSERT_RTNL(), but pneigh_lookup is called from ip6_forward and
> ndisc_recv_na
Ah, these have creat = 0, so it's fine. I missed that earlier.
(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.
This patch moves ASSERT_RTNL() up a level in the call stack.
Signed-off-by: Cong Wang
Signed-off-by: Sabrina Dubroca
Reported-by: Tommi Rantala
---
I included Cong's Signed-off-by for the first part of the patch,
I
(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.
This patch moves ASSERT_RTNL() up a level in the call stack.
Signed-off-by: Cong Wang
Signed-off-by: Sabrina Dubroca
Reported-by: Tommi Rantala
---
As was said earlier, this should go in stable.
v2:
- based on net
- keep
Hello,
2014-08-24, 23:56:03 +0900, Akinobu Mita wrote:
> Replace memblock_find_in_range() and memblock_reserve() with
> memblock_alloc_range().
>
> Signed-off-by: Akinobu Mita
> Cc: linux...@kvack.org
This patch is included in linux-next, and when I boot next-20140901,
on a 32-bit build, I get
commit e22b886a8a43b ("sched/wait: Add might_sleep() checks") included
in today's linux-next added a check that fires on e1000 with netpoll:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:104
in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
no locks held by sys
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:
> > >
Hello,
[adding Jeremiah Mahler to CC]
2014-11-27, 14:53:47 +1100, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in
> fs/fs-writeback.c between commit ef7fdf5e8c87 ("vfs: add support for a
> lazytime mount option") from the ext4 tree and commit 9
Hello, sorry for the delay.
2014-10-29, 20:36:03 +0100, Peter Zijlstra wrote:
> On Wed, Oct 29, 2014 at 07:33:00PM +0100, Thomas Gleixner wrote:
> > Yuck. No. You are just papering over the problem.
> >
> > What happens if you add 'threadirqs' to the kernel command line? Or if
> > the interrupt l
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 @ms
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 ld-2.21.
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 PM
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 emerg
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 ma
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 'akpm-
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
[1.259
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:
> >
> > 5dc5218840e
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,
> > > >
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
> &
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]
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 p
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 u
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-
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
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_l
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 hap
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
> > h
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
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 (wi
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
> Aut
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).
> >
> > A
>
> 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
>
> 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
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 *q
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
> --- a/net/rxrp
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 skb_copy_datagram_msg()
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
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
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
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
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
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
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
--- a
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
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 b
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 u
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 teste
ned-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
t;)
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/aes
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 specif
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,
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
> > >
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 net_
79 matches
Mail list logo
