* Re: kernel BUG at net/rxrpc/local_object.c:LINE!
From: David Howells @ 2019-07-31 14:30 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: dhowells, syzbot, Eric Biggers, David Miller, linux-afs, LKML,
netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+YjdV8CqX5=PzKsHnLsJOzsydqiq3igYDm_=nSdmFo2YQ@mail.gmail.com>
Dmitry Vyukov <dvyukov@google.com> wrote:
> Re bisection, I don't know if there are some more subtle things as
> play (you are in the better position to judge that), but bisection log
> looks good, it tracked the target crash throughout and wasn't
> distracted by any unrelated bugs, etc. So I don't see any obvious
> reasons to not trust it.
Can you turn on:
echo 1 > /sys/kernel/debug/tracing/events/rxrpc/rxrpc_local/enable
and capture the trace log at the point it crashes?
David
^ permalink raw reply
* Re: kernel BUG at net/rxrpc/local_object.c:LINE!
From: Dmitry Vyukov @ 2019-07-31 14:46 UTC (permalink / raw)
To: David Howells
Cc: syzbot, Eric Biggers, David Miller, linux-afs, LKML, netdev,
syzkaller-bugs
In-Reply-To: <20330.1564583454@warthog.procyon.org.uk>
On Wed, Jul 31, 2019 at 4:30 PM David Howells <dhowells@redhat.com> wrote:
>
> Dmitry Vyukov <dvyukov@google.com> wrote:
>
> > Re bisection, I don't know if there are some more subtle things as
> > play (you are in the better position to judge that), but bisection log
> > looks good, it tracked the target crash throughout and wasn't
> > distracted by any unrelated bugs, etc. So I don't see any obvious
> > reasons to not trust it.
>
> Can you turn on:
>
> echo 1 > /sys/kernel/debug/tracing/events/rxrpc/rxrpc_local/enable
>
> and capture the trace log at the point it crashes?
Please send a patch for testing that enables this tracing
unconditionally. This should have the same effect. There is no way to
hook into a middle of the automated process and arbitrary tune things.
^ permalink raw reply
* [PATCH] peak_usb: Fix info-leaks to USB devices
From: Tomas Bortoli @ 2019-07-31 14:54 UTC (permalink / raw)
To: wg, mkl, linux-can
Cc: davem, gregkh, alexios.zavras, tglx, allison, netdev,
linux-kernel, syzkaller, Tomas Bortoli
Uninitialized Kernel memory can leak to USB devices.
Fix by using kzalloc() instead of kmalloc() on the affected buffers.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+d6a5a1a3657b596ef132@syzkaller.appspotmail.com
Reported-by: syzbot+513e4d0985298538bf9b@syzkaller.appspotmail.com
---
Crash logs:
1.
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x7ef/0x1f50 drivers/usb/core/urb.c:405
CPU: 0 PID: 3359 Comm: kworker/0:2 Not tainted 5.2.0-rc4+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x191/0x1f0 lib/dump_stack.c:113
kmsan_report+0x162/0x2d0 mm/kmsan/kmsan.c:611
kmsan_internal_check_memory+0x974/0xa80 mm/kmsan/kmsan.c:705
kmsan_handle_urb+0x28/0x40 mm/kmsan/kmsan_hooks.c:617
usb_submit_urb+0x7ef/0x1f50 drivers/usb/core/urb.c:405
usb_start_wait_urb+0x143/0x410 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x49f/0x7f0 drivers/usb/core/message.c:156
pcan_usb_pro_send_req+0x26b/0x3e0 drivers/net/can/usb/peak_usb/pcan_usb_pro.c:336
pcan_usb_fd_drv_loaded drivers/net/can/usb/peak_usb/pcan_usb_fd.c:460 [inline]
pcan_usb_fd_init+0x16ee/0x1900 drivers/net/can/usb/peak_usb/pcan_usb_fd.c:885
peak_usb_create_dev drivers/net/can/usb/peak_usb/pcan_usb_core.c:809 [inline]
peak_usb_probe+0x1416/0x1b20 drivers/net/can/usb/peak_usb/pcan_usb_core.c:907
usb_probe_interface+0xd19/0x1310 drivers/usb/core/driver.c:361
really_probe+0x1344/0x1d90 drivers/base/dd.c:513
driver_probe_device+0x1ba/0x510 drivers/base/dd.c:670
__device_attach_driver+0x5b8/0x790 drivers/base/dd.c:777
bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
__device_attach+0x489/0x750 drivers/base/dd.c:843
device_initial_probe+0x4a/0x60 drivers/base/dd.c:890
2.
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x7ef/0x1f50 /drivers/usb/core/urb.c:405
CPU: 1 PID: 3814 Comm: kworker/1:2 Not tainted 5.2.0+ #15
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack /lib/dump_stack.c:77 [inline]
dump_stack+0x191/0x1f0 /lib/dump_stack.c:113
kmsan_report+0x162/0x2d0 /mm/kmsan/kmsan_report.c:109
kmsan_internal_check_memory+0x974/0xa80 /mm/kmsan/kmsan.c:551
kmsan_handle_urb+0x28/0x40 /mm/kmsan/kmsan_hooks.c:621
usb_submit_urb+0x7ef/0x1f50 /drivers/usb/core/urb.c:405
usb_start_wait_urb+0x143/0x410 /drivers/usb/core/message.c:58
usb_internal_control_msg /drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x49f/0x7f0 /drivers/usb/core/message.c:156
pcan_usb_pro_send_req /drivers/net/can/usb/peak_usb/pcan_usb_pro.c:336 [inline]
pcan_usb_pro_drv_loaded /drivers/net/can/usb/peak_usb/pcan_usb_pro.c:504 [inline]
pcan_usb_pro_init+0x1319/0x1720 /drivers/net/can/usb/peak_usb/pcan_usb_pro.c:894
peak_usb_create_dev /drivers/net/can/usb/peak_usb/pcan_usb_core.c:809 [inline]
peak_usb_probe+0x1416/0x1b20 /drivers/net/can/usb/peak_usb/pcan_usb_core.c:907
usb_probe_interface+0xd19/0x1310 /drivers/usb/core/driver.c:361
really_probe+0x1344/0x1d90 /drivers/base/dd.c:513
driver_probe_device+0x1ba/0x510 /drivers/base/dd.c:670
__device_attach_driver+0x5b8/0x790 /drivers/base/dd.c:777
bus_for_each_drv+0x28e/0x3b0 /drivers/base/bus.c:454
__device_attach+0x489/0x750 /drivers/base/dd.c:843
device_initial_probe+0x4a/0x60 /drivers/base/dd.c:890
bus_probe_device+0x131/0x390 /drivers/base/bus.c:514
device_add+0x25b5/0x2df0 /drivers/base/core.c:2111
usb_set_configuration+0x309f/0x3710 /drivers/usb/core/message.c:2027
generic_probe+0xe7/0x280 /drivers/usb/core/generic.c:210
usb_probe_device+0x146/0x200 /drivers/usb/core/driver.c:266
really_probe+0x1344/0x1d90 /drivers/base/dd.c:513
driver_probe_device+0x1ba/0x510 /drivers/base/dd.c:670
__device_attach_driver+0x5b8/0x790 /drivers/base/dd.c:777
bus_for_each_drv+0x28e/0x3b0 /drivers/base/bus.c:454
__device_attach+0x489/0x750 /drivers/base/dd.c:843
device_initial_probe+0x4a/0x60 /drivers/base/dd.c:890
bus_probe_device+0x131/0x390 /drivers/base/bus.c:514
device_add+0x25b5/0x2df0 /drivers/base/core.c:2111
usb_new_device+0x23e5/0x2fb0 /drivers/usb/core/hub.c:2534
hub_port_connect /drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change /drivers/usb/core/hub.c:5204 [inline]
port_event /drivers/usb/core/hub.c:5350 [inline]
hub_event+0x5853/0x7320 /drivers/usb/core/hub.c:5432
process_one_work+0x1572/0x1f00 /kernel/workqueue.c:2269
worker_thread+0x111b/0x2460 /kernel/workqueue.c:2415
kthread+0x4b5/0x4f0 /kernel/kthread.c:256
ret_from_fork+0x35/0x40 /arch/x86/entry/entry_64.S:355
Uninit was created at:
kmsan_save_stack_with_flags /mm/kmsan/kmsan.c:187 [inline]
kmsan_internal_poison_shadow+0x53/0xa0 /mm/kmsan/kmsan.c:146
kmsan_slab_alloc+0xaa/0x120 /mm/kmsan/kmsan_hooks.c:175
slab_alloc_node /mm/slub.c:2771 [inline]
slab_alloc /mm/slub.c:2780 [inline]
kmem_cache_alloc_trace+0x873/0xa50 /mm/slub.c:2797
kmalloc /./include/linux/slab.h:547 [inline]
pcan_usb_pro_drv_loaded /drivers/net/can/usb/peak_usb/pcan_usb_pro.c:497 [inline]
pcan_usb_pro_init+0xe96/0x1720 /drivers/net/can/usb/peak_usb/pcan_usb_pro.c:894
peak_usb_create_dev /drivers/net/can/usb/peak_usb/pcan_usb_core.c:809 [inline]
peak_usb_probe+0x1416/0x1b20 /drivers/net/can/usb/peak_usb/pcan_usb_core.c:907
usb_probe_interface+0xd19/0x1310 /drivers/usb/core/driver.c:361
really_probe+0x1344/0x1d90 /drivers/base/dd.c:513
driver_probe_device+0x1ba/0x510 /drivers/base/dd.c:670
__device_attach_driver+0x5b8/0x790 /drivers/base/dd.c:777
bus_for_each_drv+0x28e/0x3b0 /drivers/base/bus.c:454
__device_attach+0x489/0x750 /drivers/base/dd.c:843
device_initial_probe+0x4a/0x60 /drivers/base/dd.c:890
bus_probe_device+0x131/0x390 /drivers/base/bus.c:514
device_add+0x25b5/0x2df0 /drivers/base/core.c:2111
usb_set_configuration+0x309f/0x3710 /drivers/usb/core/message.c:2027
generic_probe+0xe7/0x280 /drivers/usb/core/generic.c:210
usb_probe_device+0x146/0x200 /drivers/usb/core/driver.c:266
really_probe+0x1344/0x1d90 /drivers/base/dd.c:513
driver_probe_device+0x1ba/0x510 /drivers/base/dd.c:670
__device_attach_driver+0x5b8/0x790 /drivers/base/dd.c:777
bus_for_each_drv+0x28e/0x3b0 /drivers/base/bus.c:454
__device_attach+0x489/0x750 /drivers/base/dd.c:843
device_initial_probe+0x4a/0x60 /drivers/base/dd.c:890
bus_probe_device+0x131/0x390 /drivers/base/bus.c:514
device_add+0x25b5/0x2df0 /drivers/base/core.c:2111
usb_new_device+0x23e5/0x2fb0 /drivers/usb/core/hub.c:2534
hub_port_connect /drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change /drivers/usb/core/hub.c:5204 [inline]
port_event /drivers/usb/core/hub.c:5350 [inline]
hub_event+0x5853/0x7320 /drivers/usb/core/hub.c:5432
process_one_work+0x1572/0x1f00 /kernel/workqueue.c:2269
worker_thread+0x111b/0x2460 /kernel/workqueue.c:2415
kthread+0x4b5/0x4f0 /kernel/kthread.c:256
ret_from_fork+0x35/0x40 /arch/x86/entry/entry_64.S:355
Bytes 2-15 of 16 are uninitialized
Memory access of size 16 starts at ffff8881030286e0
==================================================================
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 2 +-
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
index 34761c3a6286..47cc1ff5b88e 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
@@ -841,7 +841,7 @@ static int pcan_usb_fd_init(struct peak_usb_device *dev)
goto err_out;
/* allocate command buffer once for all for the interface */
- pdev->cmd_buffer_addr = kmalloc(PCAN_UFD_CMD_BUFFER_SIZE,
+ pdev->cmd_buffer_addr = kzalloc(PCAN_UFD_CMD_BUFFER_SIZE,
GFP_KERNEL);
if (!pdev->cmd_buffer_addr)
goto err_out_1;
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index 178bb7cff0c1..53cb2f72bdd0 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
@@ -494,7 +494,7 @@ static int pcan_usb_pro_drv_loaded(struct peak_usb_device *dev, int loaded)
u8 *buffer;
int err;
- buffer = kmalloc(PCAN_USBPRO_FCT_DRVLD_REQ_LEN, GFP_KERNEL);
+ buffer = kzalloc(PCAN_USBPRO_FCT_DRVLD_REQ_LEN, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
--
2.11.0
^ permalink raw reply related
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: David Ahern @ 2019-07-31 15:13 UTC (permalink / raw)
To: Eric Dumazet, David Miller, dvyukov, netdev, fw, i.maximets,
edumazet, linux-kernel, syzkaller-bugs
In-Reply-To: <20190731025722.GE687@sol.localdomain>
On 7/30/19 8:57 PM, Eric Biggers wrote:
> syzbot finds a lot of security bugs, and security bugs are important. And the
> bugs are still there regardless of whether they're reported by human or bot.
>
> Also, there *are* bugs being fixed because of these reminders; some subsystem
> maintainers have even fixed all the bugs in their subsystem. But I can
> understand that for subsystems with a lot of open bug reports it's overwhelming.
>
> What I'll try doing next time (if there *is* a next time; it isn't actually my
> job to do any of this, I just care about the security and reliability of
> Linux...) is for subsystems with lots of open bug reports, only listing the ones
> actually seen in the last week or so, and perhaps also spending some more time
> manually checking those bugs. That should cut down the noise a lot.
I don't think anyone questions the overall value of syzbot. It's the
maintenance of bug reports that needs refining.
As an example, this one:
https://syzkaller.appspot.com/bug?id=079bd8408abd95b492f127edf0df44ddc09d9405
was in reality a very short-lived bug in net-next but because bpf-next
managed to merge net-next in the small time window, the bug life seems
more extended that it apparently was (fuzzy words since we do not know
which commit fixed it).
Also, there is inconsistency with the report. It shows a bisected commit of:
commit f40b6ae2b612446dc970d7b51eeec47bd1619f82
Author: David Ahern <dsahern@gmail.com>
Date: Thu May 23 03:27:55 2019 +0000
ipv6: Move pcpu cached routes to fib6_nh
yet the report shows an entry in net tree on April 27. Even the net
instance on June 14 is questionable given that the above commit is only
in net-next on June 14.
Taking all of those references out and there are 2 'real', unique
reports - the linux-next on May 31 and the net-next on June 5.
Given that nothing has appeared in the last 8 weeks it seems clear to me
that this bug has been fixed we just don't know by which commit.
If there is a way to reduce to some of that information or even to have
a button on that console that says 'apparently fixed' and close it would
be a help.
^ permalink raw reply
* Re: kernel BUG at net/rxrpc/local_object.c:LINE!
From: David Howells @ 2019-07-31 15:19 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: dhowells, syzbot, Eric Biggers, David Miller, linux-afs, LKML,
netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+Y4cRgaRPJ_gz_53k85inDKq+X+bWmOTv1gPLo=Yod1=A@mail.gmail.com>
Dmitry Vyukov <dvyukov@google.com> wrote:
> Please send a patch for testing that enables this tracing
> unconditionally. This should have the same effect. There is no way to
> hook into a middle of the automated process and arbitrary tune things.
I don't know how to do that off hand. Do you have an example?
Anyway, I think rxrpc_local_processor() is broken with respect to refcounting
as it gets scheduled when usage==0, but that doesn't stop it being rescheduled
again by a network packet before it manages to close the UDP socket.
David
^ permalink raw reply
* Re: [PATCH net 0/2] mlxsw: Two small fixes
From: David Miller @ 2019-07-31 15:24 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw, idosch
In-Reply-To: <20190731063315.9381-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Wed, 31 Jul 2019 09:33:13 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Patch #1 from Jiri fixes the error path of the module initialization
> function. Found during manual code inspection.
>
> Patch #2 from Petr further reduces the default shared buffer pool sizes
> in order to work around a problem that was originally described in
> commit e891ce1dd2a5 ("mlxsw: spectrum_buffers: Reduce pool size on
> Spectrum-2").
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] drop_monitor: Add missing uAPI file to MAINTAINERS file
From: David Miller @ 2019-07-31 15:27 UTC (permalink / raw)
To: idosch; +Cc: netdev, nhorman, idosch
In-Reply-To: <20190731063819.10001-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Wed, 31 Jul 2019 09:38:19 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Fixes: 6e43650cee64 ("add maintainer for network drop monitor kernel service")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* RE: [PATCH net-next v4 0/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-31 15:30 UTC (permalink / raw)
To: David Miller
Cc: andrew@lunn.ch, robh+dt@kernel.org, Leo Li, Alexandru Marginean,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190730.095344.401137621326119500.davem@davemloft.net>
>-----Original Message-----
>From: David Miller <davem@davemloft.net>
>Sent: Tuesday, July 30, 2019 7:54 PM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: andrew@lunn.ch; robh+dt@kernel.org; Leo Li <leoyang.li@nxp.com>;
>Alexandru Marginean <alexandru.marginean@nxp.com>;
>netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
>kernel@lists.infradead.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH net-next v4 0/4] enetc: Add mdio bus driver for the PCIe
>MDIO endpoint
>
>From: David Miller <davem@davemloft.net>
>Date: Tue, 30 Jul 2019 09:44:36 -0700 (PDT)
>
>> From: Claudiu Manoil <claudiu.manoil@nxp.com>
>> Date: Tue, 30 Jul 2019 12:45:15 +0300
>>
>>> First patch fixes a sparse issue and cleans up accessors to avoid
>>> casting to __iomem.
>>> Second patch just registers the PCIe endpoint device containing
>>> the MDIO registers as a standalone MDIO bus driver, to allow
>>> an alternative way to control the MDIO bus. The same code used
>>> by the ENETC ports (eth controllers) to manage MDIO via local
>>> registers applies and is reused.
>>>
>>> Bindings are provided for the new MDIO node, similarly to ENETC
>>> port nodes bindings.
>>>
>>> Last patch enables the ENETC port 1 and its RGMII PHY on the
>>> LS1028A QDS board, where the MDIO muxing configuration relies
>>> on the MDIO support provided in the first patch.
>> ...
>>
>> Series applied, thank you.
>
>Actually this doesn't compile, I had to revert:
>
Sorry, I overlooked the module part. Turns out I have to define a separate
module for this driver (mdio), refactor common code between the mdio module
and the enetc-pf module, clean up the Makefile... and do more checks.
^ permalink raw reply
* Re: kernel BUG at net/rxrpc/local_object.c:LINE!
From: Dmitry Vyukov @ 2019-07-31 15:31 UTC (permalink / raw)
To: David Howells
Cc: syzbot, Eric Biggers, David Miller, linux-afs, LKML, netdev,
syzkaller-bugs
In-Reply-To: <22318.1564586386@warthog.procyon.org.uk>
On Wed, Jul 31, 2019 at 5:19 PM David Howells <dhowells@redhat.com> wrote:
>
> Dmitry Vyukov <dvyukov@google.com> wrote:
>
> > Please send a patch for testing that enables this tracing
> > unconditionally. This should have the same effect. There is no way to
> > hook into a middle of the automated process and arbitrary tune things.
>
> I don't know how to do that off hand. Do you have an example?
Few messages above I asked it to test:
https://groups.google.com/d/msg/syzkaller-bugs/gEnZkmEWf1s/r2_X_KVQAQAJ
Basically, git repo + branch + patch. Here are the docs:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
> Anyway, I think rxrpc_local_processor() is broken with respect to refcounting
> as it gets scheduled when usage==0, but that doesn't stop it being rescheduled
> again by a network packet before it manages to close the UDP socket.
>
> David
^ permalink raw reply
* Re: [PATCH] net: ethernet: et131x: Use GFP_KERNEL instead of GFP_ATOMIC when allocating tx_ring->tcb_ring
From: David Miller @ 2019-07-31 15:36 UTC (permalink / raw)
To: christophe.jaillet
Cc: mark.einon, willy, f.fainelli, andrew, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20190731073842.16948-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed, 31 Jul 2019 09:38:42 +0200
> There is no good reason to use GFP_ATOMIC here. Other memory allocations
> are performed with GFP_KERNEL (see other 'dma_alloc_coherent()' below and
> 'kzalloc()' in 'et131x_rx_dma_memory_alloc()')
>
> Use GFP_KERNEL which should be enough.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: ag71xx: Slighly simplify code in 'ag71xx_rings_init()'
From: David Miller @ 2019-07-31 15:38 UTC (permalink / raw)
To: christophe.jaillet
Cc: jcliburn, chris.snook, netdev, linux-kernel, kernel-janitors
In-Reply-To: <08fbcfe0f913644fe538656221a15790a1a83f1d.1564560130.git.christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed, 31 Jul 2019 10:06:38 +0200
> A few lines above, we have:
> tx_size = BIT(tx->order);
>
> So use 'tx_size' directly to be consistent with the way 'rx->descs_cpu' and
> 'rx->descs_dma' are computed below.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 2/2] net: ag71xx: Use GFP_KERNEL instead of GFP_ATOMIC in 'ag71xx_rings_init()'
From: David Miller @ 2019-07-31 15:39 UTC (permalink / raw)
To: christophe.jaillet
Cc: jcliburn, chris.snook, netdev, linux-kernel, kernel-janitors
In-Reply-To: <75ee52ae065ce9cb1f32d88939b166773316dc45.1564560130.git.christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed, 31 Jul 2019 10:06:48 +0200
> There is no need to use GFP_ATOMIC here, GFP_KERNEL should be enough.
> The 'kcalloc()' just a few lines above, already uses GFP_KERNEL.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied to 'net'
^ permalink raw reply
* [PATCH net] net: dsa: mv88e6xxx: drop adjust_link to enabled phylink
From: Hubert Feurstein @ 2019-07-31 15:42 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Hubert Feurstein, Andrew Lunn, Vivien Didelot, Florian Fainelli,
David S. Miller
We have to drop the adjust_link callback in order to finally migrate to
phylink.
Otherwise we get the following warning during startup:
"mv88e6xxx 2188000.ethernet-1:10: Using legacy PHYLIB callbacks. Please
migrate to PHYLINK!"
The warning is generated in the function dsa_port_link_register_of in
dsa/port.c:
int dsa_port_link_register_of(struct dsa_port *dp)
{
struct dsa_switch *ds = dp->ds;
if (!ds->ops->adjust_link)
return dsa_port_phylink_register(dp);
dev_warn(ds->dev,
"Using legacy PHYLIB callbacks. Please migrate to PHYLINK!\n");
[...]
}
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 366f70bfe055..37e8babd035f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -27,7 +27,6 @@
#include <linux/platform_data/mv88e6xxx.h>
#include <linux/netdevice.h>
#include <linux/gpio/consumer.h>
-#include <linux/phy.h>
#include <linux/phylink.h>
#include <net/dsa.h>
@@ -482,30 +481,6 @@ static int mv88e6xxx_phy_is_internal(struct dsa_switch *ds, int port)
return port < chip->info->num_internal_phys;
}
-/* We expect the switch to perform auto negotiation if there is a real
- * phy. However, in the case of a fixed link phy, we force the port
- * settings from the fixed link settings.
- */
-static void mv88e6xxx_adjust_link(struct dsa_switch *ds, int port,
- struct phy_device *phydev)
-{
- struct mv88e6xxx_chip *chip = ds->priv;
- int err;
-
- if (!phy_is_pseudo_fixed_link(phydev) &&
- mv88e6xxx_phy_is_internal(ds, port))
- return;
-
- mv88e6xxx_reg_lock(chip);
- err = mv88e6xxx_port_setup_mac(chip, port, phydev->link, phydev->speed,
- phydev->duplex, phydev->pause,
- phydev->interface);
- mv88e6xxx_reg_unlock(chip);
-
- if (err && err != -EOPNOTSUPP)
- dev_err(ds->dev, "p%d: failed to configure MAC\n", port);
-}
-
static void mv88e6065_phylink_validate(struct mv88e6xxx_chip *chip, int port,
unsigned long *mask,
struct phylink_link_state *state)
@@ -4755,7 +4730,6 @@ static int mv88e6xxx_port_egress_floods(struct dsa_switch *ds, int port,
static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
.get_tag_protocol = mv88e6xxx_get_tag_protocol,
.setup = mv88e6xxx_setup,
- .adjust_link = mv88e6xxx_adjust_link,
.phylink_validate = mv88e6xxx_validate,
.phylink_mac_link_state = mv88e6xxx_link_state,
.phylink_mac_config = mv88e6xxx_mac_config,
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] myri10ge: remove unneeded variable
From: David Miller @ 2019-07-31 15:44 UTC (permalink / raw)
To: dingxiang; +Cc: christopher.lee, netdev, linux-kernel
In-Reply-To: <1564563226-13367-1-git-send-email-dingxiang@cmss.chinamobile.com>
From: Ding Xiang <dingxiang@cmss.chinamobile.com>
Date: Wed, 31 Jul 2019 16:53:46 +0800
> "error" is unneeded,just return 0
>
> Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next 0/2] mlxsw: Test coverage for DSCP leftover fix
From: David Miller @ 2019-07-31 15:47 UTC (permalink / raw)
To: petrm; +Cc: netdev, idosch
In-Reply-To: <cover.1564568595.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Wed, 31 Jul 2019 10:30:25 +0000
> This patch set fixes some global scope pollution issues in the DSCP tests
> (in patch #1), and then proceeds (in patch #2) to add a new test for
> checking whether, after DSCP prioritization rules are removed from a port,
> DSCP rewrites consistently to zero, instead of the last removed rule still
> staying in effect.
Series applied.
^ permalink raw reply
* Re: next/master build: 221 builds: 11 failed, 210 passed, 13 errors, 1174 warnings (next-20190731)
From: David Miller @ 2019-07-31 15:48 UTC (permalink / raw)
To: gregkh
Cc: broonie, andrew, f.fainelli, hkallweit1, willy, devel, netdev,
linux-next, linux-arm-kernel, kernel-build-reports
In-Reply-To: <20190731113522.GA3426@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Wed, 31 Jul 2019 13:35:22 +0200
> On Wed, Jul 31, 2019 at 12:24:41PM +0100, Mark Brown wrote:
>> On Wed, Jul 31, 2019 at 04:07:41AM -0700, kernelci.org bot wrote:
>>
>> Today's -next fails to build an ARM allmodconfig due to:
>>
>> > allmodconfig (arm, gcc-8) ― FAIL, 1 error, 40 warnings, 0 section mismatches
>> >
>> > Errors:
>> > drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of function 'writeq'; did you mean 'writel'? [-Werror=implicit-function-declaration]
>>
>> as a result of the changes that introduced:
>>
>> WARNING: unmet direct dependencies detected for MDIO_OCTEON
>> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=m] && MDIO_BUS [=m] && 64BIT && HAS_IOMEM [=y] && OF_MDIO [=m]
>> Selected by [m]:
>> - OCTEON_ETHERNET [=m] && STAGING [=y] && (CAVIUM_OCTEON_SOC && NETDEVICES [=y] || COMPILE_TEST [=y])
>>
>> which is triggered by the staging OCTEON_ETHERNET driver which misses a
>> 64BIT dependency but added COMPILE_TEST in 171a9bae68c72f2
>> (staging/octeon: Allow test build on !MIPS).
>
> A patch was posted for this, but it needs to go through the netdev tree
> as that's where the offending patches are coming from.
I didn't catch that, was netdev CC:'d?
^ permalink raw reply
* Re: [PATCH 0/8] netfilter fixes for net
From: David Miller @ 2019-07-31 15:50 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190731115157.27020-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 31 Jul 2019 13:51:49 +0200
> The following patchset contains Netfilter fixes for your net tree:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks.
^ permalink raw reply
* pull-request: mac80211-next 2019-07-31
From: Johannes Berg @ 2019-07-31 15:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
There's a fair number of changes here, so I thought I'd get them out.
I've included two Intel driver cleanups because Luca is on vacation,
I'm covering for him, and doing it all in one tree let me merge all
of the patches at once (including mac80211 that depends on that);
Kalle is aware.
Also, though this isn't very interesting yet, I've started looking at
weaning the wireless subsystem off the RTNL for all operations, as it
can cause significant lock contention, especially with slow USB devices.
The real patches for that are some way off, but one preparation here is
to use generic netlink's parallel_ops=true, to avoid trading one place
with contention for another in the future, and to avoid adding more
genl_family_attrbuf() usage (since that's no longer possible with the
parallel_ops setting).
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 00c33afbf9dd06f77a2f15117cd4bdc2a54b51d7:
net: mvneta: use devm_platform_ioremap_resource() to simplify code (2019-07-25 17:28:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2019-07-31
for you to fetch changes up to f39b07fdfb688724fedabf5507e15eaf398f2500:
mac80211: HE STA disassoc due to QOS NULL not sent (2019-07-31 13:26:41 +0200)
----------------------------------------------------------------
We have a reasonably large number of changes:
* lots more HE (802.11ax) support, particularly things
relevant for the the AP side, but also mesh support
* debugfs cleanups from Greg
* some more work on extended key ID
* start using genl parallel_ops, as preparation for
weaning ourselves off RTNL and getting parallelism
* various other changes all over
----------------------------------------------------------------
Alexander Wetzel (3):
mac80211_hwsim: Extended Key ID API update
mac80211: Simplify Extended Key ID API
mac80211: AMPDU handling for rekeys with Extended Key ID
Ard Biesheuvel (1):
lib80211: use crypto API ccm(aes) transform for CCMP processing
Christophe JAILLET (1):
mac80211_hwsim: Fix a typo in the name of function 'mac80211_hswim_he_capab()'
Colin Ian King (1):
mac80211: add missing null return check from call to ieee80211_get_sband
Denis Kenzior (2):
nl80211: document uapi for CMD_FRAME_WAIT_CANCEL
nl80211: Include wiphy address setup in NEW_WIPHY
Emmanuel Grumbach (1):
mac80211: pass the vif to cancel_remain_on_channel
Erik Stromdahl (1):
mac80211: add tx dequeue function for process context
Greg Kroah-Hartman (4):
iwlwifi: dvm: no need to check return value of debugfs_create functions
iwlwifi: mvm: remove unused .remove_sta_debugfs callback
mac80211: remove unused and unneeded remove_sta_debugfs callback
cfg80211: no need to check return value of debugfs_create functions
Johannes Berg (6):
cfg80211: clean up cfg80211_inform_single_bss_frame_data()
cfg80211: don't parse MBSSID if transmitting BSS isn't created
cfg80211: give all multi-BSSID BSS entries the same timestamp
mac80211_hwsim: fill boottime_ns in netlink RX path
cfg80211: use parallel_ops for genl
nl80211: add strict start type
John Crispin (10):
mac80211: add support for parsing ADDBA_EXT IEs
mac80211: add xmit rate to struct ieee80211_tx_status
mac80211: propagate struct ieee80211_tx_status into ieee80211_tx_monitor()
mac80211: add struct ieee80211_tx_status support to ieee80211_add_tx_radiotap_header
mac80211: HE: add Spatial Reuse element parsing support
mac80211: fix ieee80211_he_oper_size() comment
mac80211: propagate HE operation info into bss_conf
mac80211: add support for the ADDBA extension element
cfg80211: add support for parsing OBBS_PD attributes
mac80211: allow setting spatial reuse parameters from bss_conf
Karthikeyan Periyasamy (1):
mac80211: reject zero MAC address in add station
Lorenzo Bianconi (1):
mac80211: add IEEE80211_KEY_FLAG_GENERATE_MMIE to ieee80211_key_flags
Michael Vassernis (1):
cfg80211: fix dfs channels remain DFS_AVAILABLE after ch_switch
Sergey Matyukevich (2):
cfg80211: refactor cfg80211_bss_update
cfg80211: fix duplicated scan entries after channel switch
Shay Bar (1):
mac80211: HE STA disassoc due to QOS NULL not sent
Sven Eckelmann (1):
mac80211: implement HE support for mesh
drivers/net/wireless/ath/ath10k/mac.c | 3 +-
drivers/net/wireless/ath/ath9k/main.c | 3 +-
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 29 +--
drivers/net/wireless/intel/iwlwifi/dvm/rs.h | 4 -
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 5 -
drivers/net/wireless/mac80211_hwsim.c | 20 +-
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 3 +-
drivers/net/wireless/ti/wlcore/main.c | 3 +-
include/linux/ieee80211.h | 63 ++++-
include/net/cfg80211.h | 15 ++
include/net/mac80211.h | 53 ++++-
include/uapi/linux/nl80211.h | 31 ++-
net/mac80211/agg-rx.c | 72 +++++-
net/mac80211/cfg.c | 7 +-
net/mac80211/debugfs.c | 3 +-
net/mac80211/driver-ops.h | 8 +-
net/mac80211/he.c | 39 ++++
net/mac80211/ht.c | 2 +-
net/mac80211/ieee80211_i.h | 17 +-
net/mac80211/key.c | 16 +-
net/mac80211/main.c | 18 +-
net/mac80211/mesh.c | 62 +++++
net/mac80211/mesh.h | 4 +
net/mac80211/mesh_plink.c | 12 +-
net/mac80211/mlme.c | 7 +-
net/mac80211/offchannel.c | 5 +-
net/mac80211/rate.h | 9 -
net/mac80211/sta_info.c | 1 -
net/mac80211/status.c | 180 +++++++++++++--
net/mac80211/trace.h | 7 +-
net/mac80211/tx.c | 5 +-
net/mac80211/util.c | 60 +++++
net/mac80211/wpa.c | 6 +-
net/wireless/Kconfig | 2 +
net/wireless/core.c | 17 +-
net/wireless/core.h | 2 +
net/wireless/lib80211_crypt_ccmp.c | 197 +++++++---------
net/wireless/nl80211.c | 182 ++++++++++++---
net/wireless/scan.c | 269 ++++++++++++++--------
40 files changed, 1070 insertions(+), 374 deletions(-)
^ permalink raw reply
* Re: pull-request: mac80211 2019-07-31
From: David Miller @ 2019-07-31 15:51 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190731124933.19420-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 31 Jul 2019 14:49:32 +0200
> We have few fixes, most importantly probably the NETIF_F_LLTX revert,
> we thought we were now more layered like VLAN or such since we do all
> of the queue control internally, but it caused problems, evidently not.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: [PATCH] net: mediatek: Drop unneeded dependency on NET_VENDOR_MEDIATEK
From: David Miller @ 2019-07-31 15:53 UTC (permalink / raw)
To: geert+renesas
Cc: nbd, john, sean.wang, nelson.chang, matthias.bgg, netdev,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20190731131202.16749-1-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed, 31 Jul 2019 15:12:02 +0200
> The whole block is protected by "if NET_VENDOR_MEDIATEK", so there is
> no need for individual driver config symbols to duplicate this
> dependency.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied.
^ permalink raw reply
* Re: [PATCH v2] isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack
From: David Miller @ 2019-07-31 15:54 UTC (permalink / raw)
To: juliana.rodrigueiro; +Cc: isdn, netdev, thomas.jarosch
In-Reply-To: <2432092.e6oL0QVcq9@rocinante.m.i2n>
From: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
Date: Wed, 31 Jul 2019 15:17:23 +0200
> Since linux 4.9 it is not possible to use buffers on the stack for DMA transfers.
>
> During usb probe the driver crashes with "transfer buffer is on stack" message.
>
> This fix k-allocates a buffer to be used on "read_reg_atomic", which is a macro
> that calls "usb_control_msg" under the hood.
>
> Kernel 4.19 backtrace:
...
> Signed-off-by: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/tls: prevent skb_orphan() from leaking TLS plain text with offload
From: Willem de Bruijn @ 2019-07-31 15:57 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David Miller, Network Development, oss-drivers, Eric Dumazet,
borisp, aviadye, davejwatson, John Fastabend, Daniel Borkmann,
Cong Wang, Florian Westphal, Alexei Starovoitov
In-Reply-To: <20190730211258.13748-1-jakub.kicinski@netronome.com>
On Tue, Jul 30, 2019 at 5:13 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> sk_validate_xmit_skb() and drivers depend on the sk member of
> struct sk_buff to identify segments requiring encryption.
> Any operation which removes or does not preserve the original TLS
> socket such as skb_orphan() or skb_clone() will cause clear text
> leaks.
>
> Make the TCP socket underlying an offloaded TLS connection
> mark all skbs as decrypted, if TLS TX is in offload mode.
> Then in sk_validate_xmit_skb() catch skbs which have no socket
> (or a socket with no validation) and decrypted flag set.
>
> Note that CONFIG_SOCK_VALIDATE_XMIT, CONFIG_TLS_DEVICE and
> sk->sk_validate_xmit_skb are slightly interchangeable right now,
> they all imply TLS offload. The new checks are guarded by
> CONFIG_TLS_DEVICE because that's the option guarding the
> sk_buff->decrypted member.
>
> Second, smaller issue with orphaning is that it breaks
> the guarantee that packets will be delivered to device
> queues in-order. All TLS offload drivers depend on that
> scheduling property. This means skb_orphan_partial()'s
> trick of preserving partial socket references will cause
> issues in the drivers. We need a full orphan, and as a
> result netem delay/throttling will cause all TLS offload
> skbs to be dropped.
>
> Reusing the sk_buff->decrypted flag also protects from
> leaking clear text when incoming, decrypted skb is redirected
> (e.g. by TC).
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> I'm sending this for net-next because of lack of confidence
> in my own abilities. It should apply cleanly to net... :)
>
> Documentation/networking/tls-offload.rst | 9 --------
> include/net/sock.h | 28 +++++++++++++++++++++++-
> net/core/skbuff.c | 3 +++
> net/core/sock.c | 22 ++++++++++++++-----
> net/ipv4/tcp.c | 4 +++-
> net/ipv4/tcp_output.c | 3 +++
> net/tls/tls_device.c | 2 ++
> 7 files changed, 55 insertions(+), 16 deletions(-)
> Redirects leak clear text
> -------------------------
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 228db3998e46..90f3f552c789 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -814,6 +814,7 @@ enum sock_flags {
> SOCK_TXTIME,
> SOCK_XDP, /* XDP is attached */
> SOCK_TSTAMP_NEW, /* Indicates 64 bit timestamps always */
> + SOCK_CRYPTO_TX_PLAIN_TEXT, /* Generate skbs with decrypted flag set */
> };
>
> #define SK_FLAGS_TIMESTAMP ((1UL << SOCK_TIMESTAMP) | (1UL << SOCK_TIMESTAMPING_RX_SOFTWARE))
> @@ -2480,8 +2481,26 @@ static inline bool sk_fullsock(const struct sock *sk)
> return (1 << sk->sk_state) & ~(TCPF_TIME_WAIT | TCPF_NEW_SYN_RECV);
> }
>
> +static inline void sk_set_tx_crypto(const struct sock *sk, struct sk_buff *skb)
nit: skb_.. instead of sk_.. ?
> +{
> +#ifdef CONFIG_TLS_DEVICE
> + skb->decrypted = sock_flag(sk, SOCK_CRYPTO_TX_PLAIN_TEXT);
> +#endif
> +}
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0b788df5a75b..9e92684479b9 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3794,6 +3794,9 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
>
> skb_reserve(nskb, headroom);
> __skb_put(nskb, doffset);
> +#ifdef CONFIG_TLS_DEVICE
> + nskb->decrypted = head_skb->decrypted;
> +#endif
decrypted is between header_start and headers_end, so
__copy_skb_header just below should take care of this?
> diff --git a/net/core/sock.c b/net/core/sock.c
> index d57b0cc995a0..b0c10b518e65 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1992,6 +1992,22 @@ void skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
> }
> EXPORT_SYMBOL(skb_set_owner_w);
>
> +static bool can_skb_orphan_partial(const struct sk_buff *skb)
> +{
> +#ifdef CONFIG_TLS_DEVICE
> + /* Drivers depend on in-order delivery for crypto offload,
> + * partial orphan breaks out-of-order-OK logic.
> + */
> + if (skb->decrypted)
> + return false;
> +#endif
> +#ifdef CONFIG_INET
> + if (skb->destructor == tcp_wfree)
> + return true;
> +#endif
> + return skb->destructor == sock_wfree;
> +}
> +
Just insert the skb->decrypted check into skb_orphan_partial for less
code churn?
I also think that this is an independent concern from leaking plain
text, so perhaps could be a separate patch.
^ permalink raw reply
* Re: [PATCH net v2] ipvs: Improve robustness to the ipvs sysctl
From: hujunwei @ 2019-07-31 15:58 UTC (permalink / raw)
To: Julian Anastasov
Cc: wensong, horms, pablo, kadlec, Florian Westphal, davem,
netdev@vger.kernel.org, lvs-devel, netfilter-devel, coreteam,
Mingfangsen, wangxiaogang3, xuhanbing
In-Reply-To: <alpine.LFD.2.21.1907302226340.4897@ja.home.ssi.bg>
Hello, Julian
On 2019/7/31 3:29, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 30 Jul 2019, hujunwei wrote:
>
>> From: Junwei Hu <hujunwei4@huawei.com>
>>
>> The ipvs module parse the user buffer and save it to sysctl,
>> then check if the value is valid. invalid value occurs
>> over a period of time.
>> Here, I add a variable, struct ctl_table tmp, used to read
>> the value from the user buffer, and save only when it is valid.
>> I delete proc_do_sync_mode and use extra1/2 in table for the
>> proc_dointvec_minmax call.
>>
>> Fixes: f73181c8288f ("ipvs: add support for sync threads")
>> Signed-off-by: Junwei Hu <hujunwei4@huawei.com>
>
> Looks good to me, thanks!
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
>
> BTW, why ip_vs_zero_all everywhere? Due to old git version?
>
I will update the git version and send the patch v3.
Regards,
Junwei
^ permalink raw reply
* Re: pull-request: mac80211-next 2019-07-31
From: David Miller @ 2019-07-31 16:00 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190731155057.23035-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 31 Jul 2019 17:50:56 +0200
> There's a fair number of changes here, so I thought I'd get them out.
> I've included two Intel driver cleanups because Luca is on vacation,
> I'm covering for him, and doing it all in one tree let me merge all
> of the patches at once (including mac80211 that depends on that);
> Kalle is aware.
>
> Also, though this isn't very interesting yet, I've started looking at
> weaning the wireless subsystem off the RTNL for all operations, as it
> can cause significant lock contention, especially with slow USB devices.
> The real patches for that are some way off, but one preparation here is
> to use generic netlink's parallel_ops=true, to avoid trading one place
> with contention for another in the future, and to avoid adding more
> genl_family_attrbuf() usage (since that's no longer possible with the
> parallel_ops setting).
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
I'm sure people like Florian Westphal will also appreciate your RTNL
elimination work...
^ permalink raw reply
* Re: next/master build: 221 builds: 11 failed, 210 passed, 13 errors, 1174 warnings (next-20190731)
From: Greg KH @ 2019-07-31 16:00 UTC (permalink / raw)
To: David Miller
Cc: devel, andrew, f.fainelli, kernel-build-reports, netdev, willy,
broonie, linux-next, linux-arm-kernel, hkallweit1
In-Reply-To: <20190731.084824.2244928058443049.davem@davemloft.net>
On Wed, Jul 31, 2019 at 08:48:24AM -0700, David Miller wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Wed, 31 Jul 2019 13:35:22 +0200
>
> > On Wed, Jul 31, 2019 at 12:24:41PM +0100, Mark Brown wrote:
> >> On Wed, Jul 31, 2019 at 04:07:41AM -0700, kernelci.org bot wrote:
> >>
> >> Today's -next fails to build an ARM allmodconfig due to:
> >>
> >> > allmodconfig (arm, gcc-8) ― FAIL, 1 error, 40 warnings, 0 section mismatches
> >> >
> >> > Errors:
> >> > drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of function 'writeq'; did you mean 'writel'? [-Werror=implicit-function-declaration]
> >>
> >> as a result of the changes that introduced:
> >>
> >> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> >> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=m] && MDIO_BUS [=m] && 64BIT && HAS_IOMEM [=y] && OF_MDIO [=m]
> >> Selected by [m]:
> >> - OCTEON_ETHERNET [=m] && STAGING [=y] && (CAVIUM_OCTEON_SOC && NETDEVICES [=y] || COMPILE_TEST [=y])
> >>
> >> which is triggered by the staging OCTEON_ETHERNET driver which misses a
> >> 64BIT dependency but added COMPILE_TEST in 171a9bae68c72f2
> >> (staging/octeon: Allow test build on !MIPS).
> >
> > A patch was posted for this, but it needs to go through the netdev tree
> > as that's where the offending patches are coming from.
>
> I didn't catch that, was netdev CC:'d?
Nope, just you :(
I'll resend it now and cc: netdev.
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox