* Re: [RFC PATCH iproute2-next] System specification health API
From: Eran Ben Elisha @ 2018-09-16 10:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Simon Horman,
Alexander Duyck, Andrew Lunn, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <20180913103604.0ef868f4@cakuba.netronome.com>
On 9/13/2018 8:36 PM, Jakub Kicinski wrote:
> On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote:
>> The health spec is targeted for Real Time Alerting, in order to know when
>> something bad had happened to a PCI device
>
> By spec you mean some standards body spec you implement or this
> proposal is a spec?
This proposal is a spec
>
>> - Provide alert debug information
>> - Self healing
>> - If problem needs vendor support, provide a way to gather all needed debugging
>> information.
>>
>> The health contains sensors which sense for malfunction. Once sensor triggered,
>> actions such as logs and correction can be taken.
>> Sensors are sensing the health state and can trigger correction action.
>>
>> The sensors are divided into the following groups
>> - Hardware sensor - a sensor which is triggered by the device due to
>> malfunction.
>> - Software sensor - a sensor which is triggered by the software due to
>> malfunction.
>> Both group of sensors can be triggered due to error event or due to a periodic check.
>>
>> Actions are the way to handle sensor events. Action can be in one of the
>> following groups:
>> - Dump - SW trace, SW dump, HW trace, HW dump
>> - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
>> Actions can be performed by SW or HW.
>>
>> User is allowed to enable or disable sensors and sensor2action mapping.
>>
>> This RFC man page patch describes the suggested API of devlink-health in order
>> to control sensors and actions.
>
> I like the idea of configuring response to events like this, although
> I'm not sure the name sensor is appropriate here - perhaps exception or
> error would be better?
I was trying to avoid the negativity description. Have it called sensor
to avoid restricting the API for errors / exceptions only. I got the
same type of comment from Andrew as well devlink-health->devlink-bug.
But if other vendors driver developers don't see it can be expanded to
sensor which are not errors, then I guess we can refactor the names.
Are there going to be values reported?
It depends on the sensor. If it has data that would help in the debug,
then I assume yes, via the dumps.
>
> I'm not so sure about HW sensors in relation to existing HWMON
> infrastructure... I assume you're targeting things like say some HW
> engine/block reporting it encountered an error? Sounds good, too.
yes, exactly.
>
> Are the actions all envisioned to be performed by the driver?
> Firmware? Hardware? I guess that distinction can be added later.
> For FW/HW actions we would go back to the problem of persistence of
> the setting since it was only implemented for params :S
The problem is not with FW action, the problem is when you try to set
sensor2action mapping for the FW/HW. this will need persistence
configuration mode. Sensor2action in SW shall be run-time mode (at least
as a start).
But it sound as this need some more tuning, to make it clear.
>
> Is the dump option going to tie back into region snapshots?
>
no necessarily, dumping SW objects as well can be helpful
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] man: Add devlink health man page
From: Eran Ben Elisha @ 2018-09-16 9:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Jakub Kicinski,
Simon Horman, Alexander Duyck, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <20180913151252.GC23892@lunn.ch>
On 9/13/2018 6:12 PM, Andrew Lunn wrote:
>>>>>> devlink health sensor set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
>>>>>> Sets TX_COMP_ERROR sensor parameters for a specific device.
>
>>>> This is what I had in mind:
>>>> 1. command interface error
>>>> 2. command interface timeout
>>>> 3. stuck TX queue (like tx_timeout)
>>>> 4. stuck TX completion queue (driver did not process packets in a reasonable
>>>> time period)
>>>> 5. stuck RX queue
>>>> 6. RX completion error
>>>> 7. TX completion error
>>>> 8. HW / FW catastrophic error report
>>>> 9. completion queue overrun
>
>> Such issues do exist in production environment, and need to be handled even
>> if root cause is a bug which will be fixed in latest release. My feature
>> should help developers / administrator to control and recover their live
>> systems, by auto correction and logging support.
>> Goal is:
>> - Provide alert debug information
>> - Self healing
>> - If problem needs vendor support, provide a way to gather all needed
>> debugging information.
>
> So maybe you have the wrong name for this. Health is nice in terms of
> Marketing, but we are actually talking about bug recovery.
The way I see it, this feature is responsible for the health of the
system from the pci/xxxx perspective.
I though about devlink-recover for example, but I really wouldn't like
to limit the feature to be called after one of its actions. The same for
devlink-bug, which highlights only part of the range of capabilities
(sensor).
My work is currently focused on error reporting and recovery, but I
wouldn't like to see the API limited for "bugs" only.
Eran
>
> devlink bug sensor set pci/0000:01:00.0 name command_interface_error action reset off action dump on
> devlink bug sensor set pci/0000:01:00.0 name command_interface_timeout action reset off action dump on
> devlink bug sensor set pci/0000:01:00.0 name transmit_completion_error action reset off action dump on
> devlink bug sensor set pci/0000:01:00.0 name completion_queue_overrun action reset off action dump on
>
> seems a lot more understandable than:
>
> devlink health set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
>
> Andrew
>
^ permalink raw reply
* [PATCH] net: dsa: remove redundant null pointer check before put_device
From: zhong jiang @ 2018-09-16 13:45 UTC (permalink / raw)
To: davem, f.fainelli, andrew; +Cc: vivien.didelot, netdev, linux-kernel
put_device has taken the null pinter check into account. So it is
safe to remove the duplicated check before put_device.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/dsa/legacy.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/dsa/legacy.c b/net/dsa/legacy.c
index 42a7b85..8aa92b0 100644
--- a/net/dsa/legacy.c
+++ b/net/dsa/legacy.c
@@ -392,8 +392,7 @@ static void dsa_of_free_platform_data(struct dsa_platform_data *pd)
}
/* Drop our reference to the MDIO bus device */
- if (pd->chip[i].host_dev)
- put_device(pd->chip[i].host_dev);
+ put_device(pd->chip[i].host_dev);
}
kfree(pd->chip);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH] net: dsa: remove redundant null pointer check before of_node_put
From: zhong jiang @ 2018-09-16 13:22 UTC (permalink / raw)
To: davem; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
of_node_put has taken the null pointer check into account. So it is
safe to remove the duplicated check before of_node_put.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/dsa/bcm_sf2.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index e0066ad..1fc27e1 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -465,8 +465,7 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
static void bcm_sf2_mdio_unregister(struct bcm_sf2_priv *priv)
{
mdiobus_unregister(priv->slave_mii_bus);
- if (priv->master_mii_dn)
- of_node_put(priv->master_mii_dn);
+ of_node_put(priv->master_mii_dn);
}
static u32 bcm_sf2_sw_get_phy_flags(struct dsa_switch *ds, int port)
--
1.7.12.4
^ permalink raw reply related
* [PATCH] net: usb: remove redundant null pointer check before of_node_put
From: zhong jiang @ 2018-09-16 13:20 UTC (permalink / raw)
To: davem; +Cc: woojung.huh, UNGLinuxDriver, netdev, linux-usb, linux-kernel
of_node_put has taken the null pointer check into account. So it is
safe to remove the duplicated check before of_node_put.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/usb/lan78xx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 3ce3c66..34ca0ee 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1835,8 +1835,7 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
ret = of_mdiobus_register(dev->mdiobus, node);
- if (node)
- of_node_put(node);
+ of_node_put(node);
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
--
1.7.12.4
^ permalink raw reply related
* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: David Arendt @ 2018-09-16 12:38 UTC (permalink / raw)
To: Maciej S. Szmigiero; +Cc: linux-kernel, nic_swsd, netdev
In-Reply-To: <6c14f6d0-ea61-b8e6-57a2-940d32330ed2@maciej.szmigiero.name>
Hi,
I have applied the patch one hour ago. So far there are no problems but
because sometimes the problems only appeared after a few hours, I will
only definitively know tomorrow if the patch helped or not.
If not, I will try bisecting the problem.
For information here the differences from ethtool between the working
driver from 4.17.14 and the patched one fom 4.18.8:
--- working.txt 2018-09-16 14:14:00.544376935 +0200
+++ patched.txt 2018-09-16 14:20:09.445660915 +0200
@@ -5,2 +5,2 @@
-0x10: Dump Tally Counter Command 0xf900c000 0x00000007
-0x20: Tx Normal Priority Ring Addr 0xf3aa7000 0x00000007
+0x10: Dump Tally Counter Command 0xf9260000 0x00000007
+0x20: Tx Normal Priority Ring Addr 0xebb73000 0x00000007
@@ -17 +17 @@
-0x40: Tx Configuration 0x4f000f80
+0x40: Tx Configuration 0x4f000f00
@@ -31,2 +31,2 @@
-0x64: TBI control and status 0x17ffff01
-0x68: TBI Autonegotiation advertisement (ANAR) 0xf70c
+0x64: TBI control and status 0x00000000
+0x68: TBI Autonegotiation advertisement (ANAR) 0x0000
@@ -35 +35 @@
-0x84: PM wakeup frame 0 0x04000000 0x7c5b5c95
+0x84: PM wakeup frame 0 0x04000000 0x710b8deb
@@ -57 +57 @@
-0xE4: Rx Ring Addr 0xf3b64000 0x00000007
+0xE4: Rx Ring Addr 0xef9f0000 0x00000007
Thanks in advance,
David Arendt
On 9/16/18 1:54 AM, Maciej S. Szmigiero wrote:
> [ I've added Realtek Linux NIC and netdev mailing lists to CC ]
>
> Hi David,
>
> On 15.09.2018 23:23, David Arendt wrote:
>> Hi,
>>
>> just a follow up:
>>
>> In kernel 4.18.8 the behaviour is different.
>>
>> The network is not reachable a number of times, but restarting to be
>> reachable by itself before it finally is no longer reachable at all.
>>
>> Here the logging output:
>>
>> Sep 15 17:44:43 server kernel: NETDEV WATCHDOG: enp3s0 (r8169): transmit
>> queue 0 timed out
>> Sep 15 17:44:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:10:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:12:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:13:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:14:48 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:20:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:34:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:43:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:46:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 19:00:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>>
>> From 17:44 ro 18:46 the network is recovering automatically. After the
>> up from 19:00, the network is no longer reachable without any additional
>> message.
>>
>> If looking at ifconfig, the counter for TX packets is incrementing, the
>> counter for RX packets not.
>>
>> Here again the driver from 4.17.14 is working flawlessly.
> Could you please try this patch on top of 4.18.8:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f74dd480cf4e31e12971c58a1d832044db945670
>
> In my case the problem fixed by the above commit was only limited to
> bad TX performance but my r8169 NIC models were different from what
> you have.
>
> If this does not help then try bisecting the issue
> (maybe limited to drivers/net/ethernet/realtek/r8169.c to save time).
> If the NIC dies after a heavy load it might be possible to generate
> such load quickly by in-kernel pktgen.
>
> If that's not possible then at please least compare NIC register
> values displayed by "ethtool -d enp3s0" between working and
> non-working kernels.
>
>> Thanks in advance,
>> David Arendt
> Maciej
>
>>
>> On 9/4/18 8:19 AM, David Arendt wrote:
>>> Hi,
>>>
>>> When using kernel 4.18.5 the Realtek 8111G network adapter stops
>>> responding under high system load.
>>>
>>> Dmesg is showing no errors.
>>>
>>> Sometimes an ifconfig enp3s0 down followed by an ifconfig enp3s0 up is
>>> enough for the network adapter to restart responding. Sometimes a reboot
>>> is necessary.
>>>
>>> When copying r8169.c from 4.17.14 to the 4.18.5 kernel, networking works
>>> perfectly stable on 4.18.5 so the problem seems r8169.c related.
>>>
>>> Here the output from lshw:
>>>
>>> *-pci:2
>>> description: PCI bridge
>>> product: 8 Series/C220 Series Chipset Family PCI Express
>>> Root Port #3
>>> vendor: Intel Corporation
>>> physical id: 1c.2
>>> bus info: pci@0000:00:1c.2
>>> version: d5
>>> width: 32 bits
>>> clock: 33MHz
>>> capabilities: pci pciexpress msi pm normal_decode
>>> bus_master cap_list
>>> configuration: driver=pcieport
>>> resources: irq:18 ioport:d000(size=4096)
>>> memory:f7300000-f73fffff ioport:f2100000(size=1048576)
>>> *-network
>>> description: Ethernet interface
>>> product: RTL8111/8168/8411 PCI Express Gigabit Ethernet
>>> Controller
>>> vendor: Realtek Semiconductor Co., Ltd.
>>> physical id: 0
>>> bus info: pci@0000:03:00.0
>>> logical name: enp3s0
>>> version: 0c
>>> serial: <hidden>
>>> size: 1Gbit/s
>>> capacity: 1Gbit/s
>>> width: 64 bits
>>> clock: 33MHz
>>> capabilities: pm msi pciexpress msix vpd bus_master
>>> cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt
>>> 1000bt-fd autonegotiation
>>> configuration: autonegotiation=on broadcast=yes
>>> driver=r8169 driverversion=2.3LK-NAPI duplex=full
>>> firmware=rtl8168g-2_0.0.1 02/06/13 latency=0 link=yes multicast=yes
>>> port=MII speed=1Gbit/s
>>> resources: irq:18 ioport:d000(size=256)
>>> memory:f7300000-f7300fff memory:f2100000-f2103fff
>>>
>>> Thanks in advance for looking into this,
>>>
>>> David Arendt
>>>
>>>
^ permalink raw reply
* KMSAN: uninit-value in ip_rcv_core
From: syzbot @ 2018-09-16 11:03 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 42a037ca8d9d kmsan: update README.md to reference LLVM r34..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=1089adea400000
kernel config: https://syzkaller.appspot.com/x/.config?x=3431f03869413153
dashboard link: https://syzkaller.appspot.com/bug?extid=2e406a9ac75bb71d4b7a
compiler: clang version 8.0.0 (trunk 339414)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12d6d421400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13fdeb7a400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2e406a9ac75bb71d4b7a@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KMSAN: uninit-value in ip_rcv_core+0xabd/0x1160 net/ipv4/ip_input.c:464
CPU: 1 PID: 4270 Comm: syz-executor158 Not tainted 4.19.0-rc1+ #42
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x14b/0x190 lib/dump_stack.c:113
kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
__msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
ip_rcv_core+0xabd/0x1160 net/ipv4/ip_input.c:464
ip_rcv+0xbb/0x6d0 net/ipv4/ip_input.c:521
__netif_receive_skb_one_core net/core/dev.c:4892 [inline]
__netif_receive_skb net/core/dev.c:5002 [inline]
process_backlog+0x752/0x10b0 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x723/0x19d0 net/core/dev.c:6294
__do_softirq+0x562/0x948 kernel/softirq.c:292
do_softirq_own_stack+0x49/0x80 arch/x86/entry/entry_64.S:1055
</IRQ>
do_softirq kernel/softirq.c:336 [inline]
__local_bh_enable_ip+0x119/0x150 kernel/softirq.c:189
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:723 [inline]
__dev_queue_xmit+0x35a8/0x3ab0 net/core/dev.c:3830
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3836
packet_snd net/packet/af_packet.c:2925 [inline]
packet_sendmsg+0x80ff/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x441149
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffebf721a18 EFLAGS: 00000286 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441149
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100
R10: 0000000000000100 R11: 0000000000000286 R12: 00000000004020b0
R13: 0000000000402140 R14: 0000000000000000 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:271 [inline]
kmsan_internal_chain_origin+0x128/0x210 mm/kmsan/kmsan.c:573
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:482
iptunnel_xmit+0xa3c/0xd50 net/ipv4/ip_tunnel_core.c:85
ip_tunnel_xmit+0x33e1/0x3750 net/ipv4/ip_tunnel.c:778
__gre_xmit net/ipv4/ip_gre.c:449 [inline]
ipgre_xmit+0xdcf/0xeb0 net/ipv4/ip_gre.c:703
__netdev_start_xmit include/linux/netdevice.h:4287 [inline]
netdev_start_xmit include/linux/netdevice.h:4296 [inline]
xmit_one net/core/dev.c:3217 [inline]
dev_hard_start_xmit+0x5df/0xc20 net/core/dev.c:3233
__dev_queue_xmit+0x2f35/0x3ab0 net/core/dev.c:3803
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3836
packet_snd net/packet/af_packet.c:2925 [inline]
packet_sendmsg+0x80ff/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181
kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2719 [inline]
__kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4352
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:996 [inline]
alloc_skb_with_frags+0x1d0/0xac0 net/core/skbuff.c:5276
sock_alloc_send_pskb+0xb47/0x1170 net/core/sock.c:2082
packet_alloc_skb net/packet/af_packet.c:2779 [inline]
packet_snd net/packet/af_packet.c:2870 [inline]
packet_sendmsg+0x6599/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: mlx5_core: null pointer dereference in mlx5_accel_tls_device_caps() (net-next kernel)
From: Saeed Mahameed @ 2018-09-16 5:04 UTC (permalink / raw)
To: mkubecek; +Cc: Linux Netdev List, Saeed Mahameed, Leon Romanovsky
In-Reply-To: <20180914212021.GD3876@unicorn.suse.cz>
On Fri, Sep 14, 2018 at 2:20 PM Michal Kubecek <mkubecek@suse.cz> wrote:
>
> I just encountered a null pointer dereference on mlx5_core module
> initialization while booting net-next kernel (based on commit
> ee4fccbee7d3) on an aarch64 machine:
>
Hi Michal, the issue was introduced last kernel cycle, due to
790af90c00d2 ("net/mlx5e: TLS, build TLS netdev from capabilities")
they should have checked for device TLS presence before reading TLS
capabilities.
I am preparing a fix already,
Thanks a lot for the report.
> [ 12.021971] iommu: Adding device 0000:01:00.0 to group 3
> [ 12.022925] mlx5_core 0000:01:00.0: firmware version: 12.17.2020
> [ 12.022954] mlx5_core 0000:01:00.0: 63.008 Gb/s available PCIe bandwidth (8 GT/s x8 link)
> [ 12.068709] Adding 98830144k swap on /dev/sda4. Priority:-2 extents:1 across:98830144k FS
> [ 12.347571] (0000:01:00.0): E-Switch: Total vports 9, per vport: max uc(1024) max mc(16384)
> [ 12.351962] mlx5_core 0000:01:00.0: Port module event: module 0, Cable plugged
> [ 12.366306] mlx5_core 0000:01:00.0: MLX5E: StrdRq(0) RqSz(1024) StrdSz(128) RxCqeCmprss(0)
> [ 12.366741] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
> [ 12.374603] Mem abort info:
> [ 12.377368] ESR = 0x96000004
> [ 12.380406] Exception class = DABT (current EL), IL = 32 bits
> [ 12.386357] SET = 0, FnV = 0
> [ 12.389347] EA = 0, S1PTW = 0
> [ 12.392471] Data abort info:
> [ 12.395343] ISV = 0, ISS = 0x00000004
> [ 12.399156] CM = 0, WnR = 0
> [ 12.402108] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
> [ 12.408711] [0000000000000050] pgd=0000000000000000
> [ 12.413567] Internal error: Oops: 96000004 [#1] SMP
> [ 12.418427] Modules linked in: fat mlx5_core(+) ipmi_ssif(+) aes_ce_blk crypto_simd cryptd aes_ce_cipher crc32_ce crct10dif_ce ghash_ce aes_arm64 sha2_ce sha256_arm64 sha1_ce ipmi_devintf ipmi_msghandler sbsa_gwdt tls mlxfw devlink at803x qcom_emac btrfs libcrc32c xor zlib_deflate raid6_pq ahci_platform libahci_platform hdma hdma_mgmt i2c_qup sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs
> [ 12.454800] CPU: 40 PID: 742 Comm: systemd-udevd Not tainted 4.19.0-rc3-ethnl.15-default #1
> [ 12.463131] Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 5.13 12/12/2012
> [ 12.473722] pstate: 60400005 (nZCv daif +PAN -UAO)
> [ 12.478559] pc : mlx5_accel_tls_device_caps+0x28/0x38 [mlx5_core]
> [ 12.484598] lr : mlx5e_tls_build_netdev+0x24/0x98 [mlx5_core]
> [ 12.490301] sp : ffff000021873a30
> [ 12.493599] x29: ffff000021873a30 x28: ffff2a72560a7940
> [ 12.498895] x27: ffff2a7256df6000 x26: ffff2a71a0fed650
> [ 12.504190] x25: 0000000000000000 x24: ffff92c7f2b988c0
> [ 12.509485] x23: ffff92c7fe01c0c0 x22: ffff2a71a0fcfa70
> [ 12.514780] x21: ffff92c7f2b808c0 x20: ffff92c7f741c110
> [ 12.520075] x19: ffff92c7f2b988c0 x18: ffff0000218739b0
> [ 12.525370] x17: 0000000000000000 x16: ffff2a725625ade0
> [ 12.530665] x15: 0000000029818ed4 x14: 00000000d47aab07
> [ 12.535961] x13: 8a24000000000000 x12: 0000000000000000
> [ 12.541256] x11: 0000000000000000 x10: 0000000000000000
> [ 12.546551] x9 : 0000000000000000 x8 : 0000000000000000
> [ 12.551846] x7 : 0000000000000000 x6 : ffff92c8159dc910
> [ 12.557141] x5 : 0000000000000400 x4 : ffff7e4b205a20c7
> [ 12.562436] x3 : 0000000000000000 x2 : ffff2a725625ae1c
> [ 12.567731] x1 : 00000000ab078a24 x0 : 0000000000000000
> [ 12.573027] Process systemd-udevd (pid: 742, stack limit = 0x(____ptrval____))
> [ 12.580232] Call trace:
> [ 12.582688] mlx5_accel_tls_device_caps+0x28/0x38 [mlx5_core]
> [ 12.588419] mlx5e_build_nic_netdev+0x27c/0x348 [mlx5_core]
> [ 12.593974] mlx5e_nic_init+0x1a0/0x258 [mlx5_core]
> [ 12.598835] mlx5e_create_netdev+0x74/0x118 [mlx5_core]
> [ 12.604043] mlx5e_add+0xf0/0x2c0 [mlx5_core]
> [ 12.608384] mlx5_add_device+0x88/0x1a8 [mlx5_core]
> [ 12.613246] mlx5_register_interface+0x78/0xb0 [mlx5_core]
> [ 12.618713] mlx5e_init+0x24/0x30 [mlx5_core]
> [ 12.623052] init+0x88/0xa0 [mlx5_core]
> [ 12.626850] do_one_initcall+0x54/0x200
> [ 12.630667] do_init_module+0x64/0x1d8
> [ 12.634401] load_module+0x1480/0x1510
> [ 12.638132] __se_sys_finit_module+0xc8/0xd8
> [ 12.642385] __arm64_sys_finit_module+0x24/0x30
> [ 12.646901] el0_svc_common+0x7c/0x118
> [ 12.650631] el0_svc_handler+0x38/0x78
> [ 12.654364] el0_svc+0x8/0xc
> [ 12.657229] Code: d503201f f97c7e60 f9400bf3 a8c27bfd (f9402800)
> [ 12.663306] ---[ end trace 57e772dd3cf718f1 ]---
>
> The function looks like this:
>
> ------------------------------------------------------------------------
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 68 {
> 0x0000000000058230 <+0>: stp x29, x30, [sp, #-32]!
> 0x0000000000058234 <+4>: mov x29, sp
> 0x0000000000058238 <+8>: str x19, [sp, #16]
> 0x000000000005823c <+12>: mov x19, x0
> 0x0000000000058240 <+16>: mov x0, x30
>
> drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.h:
> 68 return mdev->fpga->tls->caps;
> 0x0000000000058244 <+20>: add x19, x19, #0x38, lsl #12
>
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 68 {
> 0x0000000000058248 <+24>: bl 0x58248
> <mlx5_accel_tls_device_caps+24>
>
> drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.h:
> 68 return mdev->fpga->tls->caps;
> 0x000000000005824c <+28>: ldr x0, [x19, #30968]
>
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 70 }
> 0x0000000000058250 <+32>: ldr x19, [sp, #16]
> 0x0000000000058254 <+36>: ldp x29, x30, [sp], #32
>
> drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.h:
> 68 return mdev->fpga->tls->caps;
> 0x0000000000058258 <+40>: ldr x0, [x0, #80]
>
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 70 }
> 0x000000000005825c <+44>: ldr w0, [x0, #20]
> 0x0000000000058260 <+48>: ret
> ------------------------------------------------------------------------
>
> so IIUC mdev->fpga is null (offset of tls in struct mlx5_fpga_device is
> indeed 80 = 0x50).
>
> The NIC is
>
> Model: "Mellanox MT27700 Family [ConnectX-4]"
> Vendor: pci 0x15b3 "Mellanox Technologies"
> Device: pci 0x1013 "MT27700 Family [ConnectX-4]"
> SubVendor: pci 0x15b3 "Mellanox Technologies"
> SubDevice: pci 0x0003
>
> Michal Kubecek
^ permalink raw reply
* Job Offer
From: PineCone Research LLC @ 2018-09-16 0:43 UTC (permalink / raw)
To: netdev
EMPLOYMENT TITLE: PAYROLL COORDINATOR
EMPLOYMENT TYPE: PART-TIME (Work From Home)
SALARY: $4500.00 Monthly
PineCone Research is pleased to extend this offer of employment for the position of a Payroll Coordinator.
POSITION SUMMARY:
As a Payroll Coordinator, you will process all aspects of payroll for an assigned client base and report directly to the HR Manager in order to ensure effective, efficient and accurate operations. This position requires efficiency and flexibility in performing detailed tasks.
ESSENTIAL DUTIES & RESPONSIBILITIES:
-Compile payroll data, in order to balance the payroll and maintain payroll records
-Research client inquiries concerning paychecks or payroll in general
-Maintain client files in a confidential and secure manner
-Other duties as assigned.
MINIMUM QUALIFICATIONS:
-Detail oriented, well organized; high degree of accuracy
-Proficient in Microsoft Office (Word, Excel, Outlook)
-Professional, driven, motivated self-starter
-Reliable and dependable.
SALARY:
Your initial compensation includes a monthly salary of $4500.00
APPLY now:
Complete the sign up form below:
-Full Name:
-Mailing Address:
-Phone Number (Cell):
-Work Experience/Resume:
We look forward to a long lasting and mutually beneficial relationship and are confident your abilities will play a key role in our company. Please let me know if you have any questions.
Sincerely,
PineCone Research LLC
250 E 5th St 9th Fl
Cincinnati, Oh 45202
Attn: Richard Scott (HR Manager)
P: (513) 666-7709
^ permalink raw reply
* pull-request: bpf 2018-09-16
From: Daniel Borkmann @ 2018-09-16 0:36 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix end boundary calculation in BTF for the type section, from Martin.
2) Fix and revert subtraction of pointers that was accidentally allowed
for unprivileged programs, from Alexei.
3) Fix bpf_msg_pull_data() helper by using __GFP_COMP in order to avoid
a warning in linearizing sg pages into a single one for large allocs,
from Tushar.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit cc4dfb7f70a344f24c1c71e298deea0771dadcb2:
rds: fix two RCU related problems (2018-09-12 00:09:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 4c3d795cb012a378855543a775408fba1ccff6f2:
bpf: use __GFP_COMP while allocating page (2018-09-12 23:47:28 +0200)
----------------------------------------------------------------
Alexei Starovoitov (1):
bpf/verifier: disallow pointer subtraction
Martin KaFai Lau (1):
bpf: btf: Fix end boundary calculation for type section
Tushar Dave (1):
bpf: use __GFP_COMP while allocating page
kernel/bpf/btf.c | 2 +-
kernel/bpf/verifier.c | 2 +-
net/core/filter.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* Fw: [Bug 201137] New: using traffic control with sfq cause kernel crash
From: Stephen Hemminger @ 2018-09-15 23:26 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sat, 15 Sep 2018 08:43:09 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 201137] New: using traffic control with sfq cause kernel crash
https://bugzilla.kernel.org/show_bug.cgi?id=201137
Bug ID: 201137
Summary: using traffic control with sfq cause kernel crash
Product: Networking
Version: 2.5
Kernel Version: 4.18.5
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: grafgrimm77@gmx.de
Regression: No
Created attachment 278555
--> https://bugzilla.kernel.org/attachment.cgi?id=278555&action=edit
kernel config
Copying from the machine to an other server (protocol does not matter), causes
a kernel crash when using tc-setting with SFQ.
The machine has a Qualcom Killer NIC: lspci |grep Killer
03:00.0 Ethernet controller: Qualcomm Atheros Killer E220x Gigabit Ethernet
Controller (rev 13)
I use traffic control with SFQ:
tc qdisc add dev enp3s0 root handle 1: sfq
tc qdisc show dev enp3s0
Now I try to copy a big file (124GB, an image of a partition) to another
Linux-Server (same kernel version) to a NFS-Share. It does not matter if it is
a nfs or samba or whatever-share. It also does not matter if I use cp or rsync
command.
The target-share is for example:
grep base /proc/mounts
jaguar.grafnetz:/base /mnt/base nfs4
rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.9,local_lock=none,addr=192.168.0.7
0 0
df shows this nfs-share called base when mounted:
jaguar.grafnetz:/base 11718572032 6012592128 5705979904 52% /mnt/base
Now I use a simpe cp-command:
cp big-fime.dd.image /mnt/base/test_01
The machine crashes after 7833735168 Bytes reached the Target-Server. About 7,9
GB (with G=1000^3).
I can reproduce this crash.
The good thing is: I figured out that no kernel crash happens when I do not
use:
tc qdisc add dev enp3s0 root handle 1: sfq
tc qdisc show dev enp3s0
(So I commented it out from my local start-script and rebootet the system.)
Result: No crash any more. Copying the big file (124GB) completed without a
kernel crash.
Additional Information...
NIC is configured with IPv4:
haswell ~ # ifconfig
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.9 netmask 255.255.255.0 broadcast 192.168.0.255
ether d4:3d:7e:bd:89:44 txqueuelen 1000 (Ethernet)
RX packets 7399483 bytes 511559908 (487.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 91781850 bytes 47176316774 (43.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19
ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Current message level: 0x000060e4 (24804)
link ifup rx_err tx_err hw wol
Link detected: yes
While copying over the Gigabit-Network, speed is near maximum:
ifstat
enp2s0
KB/s in KB/s out
0.06 0.18
8348.65 31.60
117536.2 435.11
118049.0 435.04
119100.9 434.84
118889.7 435.19
119004.1 444.53
119061.4 440.47
119102.8 444.04
119077.4 444.39
119084.1 432.32
119089.6 439.71
[...]
So, perhaps the sfq-Kernel-module has a bug. I use the vanilla kernel from
kernel.org and sfq is compiled as a module.
/usr/src/linux # grep SFQ .config
CONFIG_NET_SCH_SFQ=m
Perhaps important: the server with the target-share also uses sfq with the same
settings without a problem. It runs stable.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc
From: Jason A. Donenfeld @ 2018-09-15 23:21 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <201809160711.HzjdJedZ%fengguang.wu@intel.com>
Hi Mr. Ro Bot,
On Sun, Sep 16, 2018 at 1:14 AM kbuild test robot <lkp@intel.com> wrote:
> crypto/chacha20_zinc.o: In function `crypto_chacha20_crypt':
> >> crypto/chacha20_zinc.c:55: undefined reference to `chacha20'
Looks like my Kconfig change didn't get squashed in as intended. Fixed for v5.
Thanks,
Jason
^ permalink raw reply
* [PATCH net-next] selftests/tls: Add MSG_WAITALL in recv() syscall
From: Vakul Garg @ 2018-09-16 4:34 UTC (permalink / raw)
To: netdev
Cc: linux-kselftest, linux-kernel, shuah, davejwatson, davem, doronrk,
Vakul Garg
A number of tls selftests rely upon recv() to return an exact number of
data bytes. When tls record crypto is done using an async accelerator,
it is possible that recv() returns lesser than expected number bytes.
This leads to failure of many test cases. To fix it, MSG_WAITALL has
been used in flags passed to recv() syscall.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
tools/testing/selftests/net/tls.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/net/tls.c b/tools/testing/selftests/net/tls.c
index 07daff076ce0..96fc6fe70293 100644
--- a/tools/testing/selftests/net/tls.c
+++ b/tools/testing/selftests/net/tls.c
@@ -121,11 +121,11 @@ TEST_F(tls, send_then_sendfile)
buf = (char *)malloc(st.st_size);
EXPECT_EQ(send(self->fd, test_str, to_send, 0), to_send);
- EXPECT_EQ(recv(self->cfd, recv_buf, to_send, 0), to_send);
+ EXPECT_EQ(recv(self->cfd, recv_buf, to_send, MSG_WAITALL), to_send);
EXPECT_EQ(memcmp(test_str, recv_buf, to_send), 0);
EXPECT_GE(sendfile(self->fd, filefd, 0, st.st_size), 0);
- EXPECT_EQ(recv(self->cfd, buf, st.st_size, 0), st.st_size);
+ EXPECT_EQ(recv(self->cfd, buf, st.st_size, MSG_WAITALL), st.st_size);
}
TEST_F(tls, recv_max)
@@ -160,7 +160,7 @@ TEST_F(tls, msg_more)
EXPECT_EQ(send(self->fd, test_str, send_len, MSG_MORE), send_len);
EXPECT_EQ(recv(self->cfd, buf, send_len, MSG_DONTWAIT), -1);
EXPECT_EQ(send(self->fd, test_str, send_len, 0), send_len);
- EXPECT_EQ(recv(self->cfd, buf, send_len * 2, MSG_DONTWAIT),
+ EXPECT_EQ(recv(self->cfd, buf, send_len * 2, MSG_WAITALL),
send_len * 2);
EXPECT_EQ(memcmp(buf, test_str, send_len), 0);
}
@@ -180,7 +180,7 @@ TEST_F(tls, sendmsg_single)
msg.msg_iov = &vec;
msg.msg_iovlen = 1;
EXPECT_EQ(sendmsg(self->fd, &msg, 0), send_len);
- EXPECT_EQ(recv(self->cfd, buf, send_len, 0), send_len);
+ EXPECT_EQ(recv(self->cfd, buf, send_len, MSG_WAITALL), send_len);
EXPECT_EQ(memcmp(buf, test_str, send_len), 0);
}
@@ -306,7 +306,7 @@ TEST_F(tls, splice_from_pipe2)
EXPECT_GE(splice(p[0], NULL, self->fd, NULL, 8000, 0), 0);
EXPECT_GE(write(p2[1], mem_send + 8000, 8000), 0);
EXPECT_GE(splice(p2[0], NULL, self->fd, NULL, 8000, 0), 0);
- EXPECT_GE(recv(self->cfd, mem_recv, send_len, 0), 0);
+ EXPECT_EQ(recv(self->cfd, mem_recv, send_len, MSG_WAITALL), send_len);
EXPECT_EQ(memcmp(mem_send, mem_recv, send_len), 0);
}
@@ -436,7 +436,7 @@ TEST_F(tls, multiple_send_single_recv)
EXPECT_GE(send(self->fd, send_mem, send_len, 0), 0);
EXPECT_GE(send(self->fd, send_mem, send_len, 0), 0);
memset(recv_mem, 0, total_len);
- EXPECT_EQ(recv(self->cfd, recv_mem, total_len, 0), total_len);
+ EXPECT_EQ(recv(self->cfd, recv_mem, total_len, MSG_WAITALL), total_len);
EXPECT_EQ(memcmp(send_mem, recv_mem, send_len), 0);
EXPECT_EQ(memcmp(send_mem, recv_mem + send_len, send_len), 0);
@@ -537,7 +537,7 @@ TEST_F(tls, pollin)
EXPECT_EQ(poll(&fd, 1, 20), 1);
EXPECT_EQ(fd.revents & POLLIN, 1);
- EXPECT_EQ(recv(self->cfd, buf, send_len, 0), send_len);
+ EXPECT_EQ(recv(self->cfd, buf, send_len, MSG_WAITALL), send_len);
/* Test timing out */
EXPECT_EQ(poll(&fd, 1, 20), 0);
}
@@ -555,7 +555,7 @@ TEST_F(tls, poll_wait)
/* Set timeout to inf. secs */
EXPECT_EQ(poll(&fd, 1, -1), 1);
EXPECT_EQ(fd.revents & POLLIN, 1);
- EXPECT_EQ(recv(self->cfd, recv_mem, send_len, 0), send_len);
+ EXPECT_EQ(recv(self->cfd, recv_mem, send_len, MSG_WAITALL), send_len);
}
TEST_F(tls, blocking)
@@ -701,7 +701,7 @@ TEST_F(tls, control_msg)
EXPECT_EQ(recv(self->cfd, buf, send_len, 0), -1);
vec.iov_base = buf;
- EXPECT_EQ(recvmsg(self->cfd, &msg, 0), send_len);
+ EXPECT_EQ(recvmsg(self->cfd, &msg, MSG_WAITALL), send_len);
cmsg = CMSG_FIRSTHDR(&msg);
EXPECT_NE(cmsg, NULL);
EXPECT_EQ(cmsg->cmsg_level, SOL_TLS);
--
2.13.6
^ permalink raw reply related
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Andrew Lunn @ 2018-09-15 22:30 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <12e5b18f-400f-d4d0-aca3-4e4d8b4bb6a9@gmail.com>
On Sat, Sep 15, 2018 at 02:31:14PM -0700, Florian Fainelli wrote:
>
>
> On 09/14/18 14:38, Andrew Lunn wrote:
> > This is one step in allowing phylib to make use of link_mode bitmaps,
> > instead of u32 for supported and advertised features. Convert the phy
> > drivers to use bitmaps to indicates the features they support. This
> > requires some macro magic in order to construct constant bitmaps used
> > to initialise the driver structures.
> >
> > Some new PHY_*_FEATURES are added, to indicate FIBRE is supported, and
> > that all media ports are supported. This is done since bitmaps cannot
> > be ORed together at compile time.
> >
> > Within phylib, the features bitmap is currently turned back into a
> > u32. The MAC API to phylib needs to be cleaned up before the core of
> > phylib can be converted to using bitmaps instead of u32.
>
> Nice!
Hi Florian
This is the patch i don't like. I'm hoping somebody can think of a
better way to initialise a bitmap.
Andrew
^ permalink raw reply
* Re: Urgent Please!!
From: Reem Al-Hashimy @ 2018-09-13 13:29 UTC (permalink / raw)
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international cooparation. I got your contact from a certain email database from your country while i was looking for someone to handle a huge financial transaction for me in confidence. Can you receive and invest on behalf of my only son. Please reply to reemhashimy718@gmail.com, for more details if you are interested.
Regards,
Ms. Reem Al-Hashimy
^ permalink raw reply
* Re: [PATH RFC net-next 8/8] net: phy: Add build warning if assumptions get broken
From: Florian Fainelli @ 2018-09-15 21:31 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <1536961136-30453-9-git-send-email-andrew@lunn.ch>
On 09/14/18 14:38, Andrew Lunn wrote:
> The macro magic to build constant bitmaps of supported PHY features
> breaks when we have more than 63 ETHTOOL_LINK_MODE bits. Make the
> breakage loud, not a subtle bug, when we get to that condition.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Florian Fainelli @ 2018-09-15 21:31 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <1536961136-30453-8-git-send-email-andrew@lunn.ch>
On 09/14/18 14:38, Andrew Lunn wrote:
> This is one step in allowing phylib to make use of link_mode bitmaps,
> instead of u32 for supported and advertised features. Convert the phy
> drivers to use bitmaps to indicates the features they support. This
> requires some macro magic in order to construct constant bitmaps used
> to initialise the driver structures.
>
> Some new PHY_*_FEATURES are added, to indicate FIBRE is supported, and
> that all media ports are supported. This is done since bitmaps cannot
> be ORed together at compile time.
>
> Within phylib, the features bitmap is currently turned back into a
> u32. The MAC API to phylib needs to be cleaned up before the core of
> phylib can be converted to using bitmaps instead of u32.
Nice!
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v3 11/11] net: mscc: ocelot: make use of SerDes PHYs for handling their configuration
From: Florian Fainelli @ 2018-09-15 21:25 UTC (permalink / raw)
To: Quentin Schulz, alexandre.belloni, ralf, paul.burton, jhogan,
robh+dt, mark.rutland, davem, kishon, andrew
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni
In-Reply-To: <00989856964175eafbe1435a70862c2ac66cffc0.1536912834.git-series.quentin.schulz@bootlin.com>
On 09/14/18 01:16, Quentin Schulz wrote:
> Previously, the SerDes muxing was hardcoded to a given mode in the MAC
> controller driver. Now, the SerDes muxing is configured within the
> Device Tree and is enforced in the MAC controller driver so we can have
> a lot of different SerDes configurations.
>
> Make use of the SerDes PHYs in the MAC controller to set up the SerDes
> according to the SerDes<->switch port mapping and the communication mode
> with the Ethernet PHY.
This looks good, just a few comments below:
[snip]
> + err = of_get_phy_mode(portnp);
> + if (err < 0)
> + ocelot->ports[port]->phy_mode = PHY_INTERFACE_MODE_NA;
> + else
> + ocelot->ports[port]->phy_mode = err;
> +
> + switch (ocelot->ports[port]->phy_mode) {
> + case PHY_INTERFACE_MODE_NA:
> + continue;
Would not you want to issue a message indicating that the Device Tree
must be updated here? AFAICT with your patch series, this should no
longer be a condition that you will hit unless you kept the old DTB
around, right?
> + case PHY_INTERFACE_MODE_SGMII:
> + phy_mode = PHY_MODE_SGMII;
> + break;
> + case PHY_INTERFACE_MODE_QSGMII:
> + phy_mode = PHY_MODE_QSGMII;
> + break;
> + default:
> + dev_err(ocelot->dev,
> + "invalid phy mode for port%d, (Q)SGMII only\n",
> + port);
> + return -EINVAL;
> + }
> +
> + serdes = devm_of_phy_get(ocelot->dev, portnp, NULL);
> + if (IS_ERR(serdes)) {
> + err = PTR_ERR(serdes);
> + if (err == -EPROBE_DEFER) {
This can be simplified into:
if (err == -EPROBE_DEFER)
dev_dbg();
else
dev_err();
goto err_probe_ports;
> + dev_dbg(ocelot->dev, "deferring probe\n");
> + goto err_probe_ports;
> + }
> +
> + dev_err(ocelot->dev, "missing SerDes phys for port%d\n",
> + port);
> goto err_probe_ports;
> }
> +
> + ocelot->ports[port]->serdes = serdes;
> }
>
> register_netdevice_notifier(&ocelot_netdevice_nb);
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v3 10/11] phy: add driver for Microsemi Ocelot SerDes muxing
From: Florian Fainelli @ 2018-09-15 21:20 UTC (permalink / raw)
To: Quentin Schulz, alexandre.belloni, ralf, paul.burton, jhogan,
robh+dt, mark.rutland, davem, kishon, andrew
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni
In-Reply-To: <cde4ccafdbd948db7ccbb263dd5b1a803e63a83e.1536912834.git-series.quentin.schulz@bootlin.com>
On 09/14/18 01:16, Quentin Schulz wrote:
> The Microsemi Ocelot can mux SerDes lanes (aka macros) to different
> switch ports or even make it act as a PCIe interface.
>
> This adds support for the muxing of the SerDes.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> ---
[snip]
> +
> +struct serdes_macro {
> + u8 idx;
> + /* Not used when in QSGMII or PCIe mode */
> + int port;
u8 port to be consistent with the mux table?
[snip]
> +#define SERDES_MUX(_idx, _port, _mode, _mask, _mux) { \
> + .idx = _idx, \
> + .port = _port, \
> + .mode = _mode, \
> + .mask = _mask, \
> + .mux = _mux, \
> +}
> +
> +static const struct serdes_mux ocelot_serdes_muxes[] = {
> + SERDES_MUX(SERDES1G_0, 0, PHY_MODE_SGMII, 0, 0),
> + SERDES_MUX(SERDES1G_1, 1, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_5_MODE, 0),
> + SERDES_MUX(SERDES1G_1, 5, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_5_MODE, HSIO_HW_CFG_DEV1G_5_MODE),
Why not go one step further and define a SERDES_MUX_SGMII() macro which
automatically resolves the correct bit definitions to use?
The current macro does not make this particularly easy to read :/
> + SERDES_MUX(SERDES1G_2, 2, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_4_MODE, 0),
> + SERDES_MUX(SERDES1G_2, 4, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_4_MODE, HSIO_HW_CFG_DEV1G_4_MODE),
> + SERDES_MUX(SERDES1G_3, 3, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_6_MODE, 0),
> + SERDES_MUX(SERDES1G_3, 6, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_6_MODE, HSIO_HW_CFG_DEV1G_6_MODE),
> + SERDES_MUX(SERDES1G_4, 4, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_4_MODE | HSIO_HW_CFG_DEV1G_9_MODE, 0),
> + SERDES_MUX(SERDES1G_4, 9, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_4_MODE |
> + HSIO_HW_CFG_DEV1G_9_MODE, HSIO_HW_CFG_DEV1G_4_MODE |
> + HSIO_HW_CFG_DEV1G_9_MODE),
> + SERDES_MUX(SERDES1G_5, 5, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_5_MODE | HSIO_HW_CFG_DEV2G5_10_MODE, 0),
> + SERDES_MUX(SERDES1G_5, 10, PHY_MODE_SGMII, HSIO_HW_CFG_PCIE_ENA |
> + HSIO_HW_CFG_DEV1G_5_MODE | HSIO_HW_CFG_DEV2G5_10_MODE,
> + HSIO_HW_CFG_DEV1G_5_MODE | HSIO_HW_CFG_DEV2G5_10_MODE),
> + SERDES_MUX(SERDES6G_0, 4, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_0, 5, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_0, 6, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_0, 7, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA, 0),
> + SERDES_MUX(SERDES6G_0, 7, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_1, 8, PHY_MODE_SGMII, 0, 0),
> + SERDES_MUX(SERDES6G_2, 10, PHY_MODE_SGMII, HSIO_HW_CFG_PCIE_ENA |
> + HSIO_HW_CFG_DEV2G5_10_MODE, 0),
> + SERDES_MUX(SERDES6G_2, 10, PHY_MODE_PCIE, HSIO_HW_CFG_PCIE_ENA,
> + HSIO_HW_CFG_PCIE_ENA),
> +};
> +
> +static int serdes_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct serdes_macro *macro = phy_get_drvdata(phy);
> + int ret, i;
unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(ocelot_serdes_muxes); i++) {
> + if (macro->idx != ocelot_serdes_muxes[i].idx ||
> + mode != ocelot_serdes_muxes[i].mode)
> + continue;
> +
> + if (mode != PHY_MODE_QSGMII &&
> + macro->port != ocelot_serdes_muxes[i].port)
> + continue;
> +
> + ret = regmap_update_bits(macro->ctrl->regs, HSIO_HW_CFG,
> + ocelot_serdes_muxes[i].mask,
> + ocelot_serdes_muxes[i].mux);
> + if (ret)
> + return ret;
> +
> + if (macro->idx < SERDES1G_MAX)
> + return serdes_init_s1g(macro->ctrl->regs, macro->idx);
> +
> + /* SERDES6G and PCIe not supported yet */
> + return 0;
Would not returning -EOPNOTSUPP be more helpful rather than leaving the
PHY unconfigured (or did the bootloader somehow configure it before for us)?
> + }
> +
> + return -EINVAL;
> +}
> +
> +static const struct phy_ops serdes_ops = {
> + .set_mode = serdes_set_mode,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct phy *serdes_simple_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct serdes_ctrl *ctrl = dev_get_drvdata(dev);
> + int port, idx, i;
unsigned int port, idx, i;
[snip]
> +
> +static int serdes_probe(struct platform_device *pdev)
> +{
> + struct phy_provider *provider;
> + struct serdes_ctrl *ctrl;
> + int i, ret;
unsigned int i;
> +
> + ctrl = devm_kzalloc(&pdev->dev, sizeof(*ctrl), GFP_KERNEL);
> + if (!ctrl)
> + return -ENOMEM;
> +
> + ctrl->dev = &pdev->dev;
> + ctrl->regs = syscon_node_to_regmap(pdev->dev.parent->of_node);
> + if (!ctrl->regs)
> + return -ENODEV;
> +
> + for (i = 0; i <= SERDES_MAX; i++) {
Every other loop you have is using <, is this one off-by-one?
--
Florian
^ permalink raw reply
* [PATCH RFC net-next] Amiga PCMCIA 100 MBit card support
From: ALeX Kazik @ 2018-09-15 20:40 UTC (permalink / raw)
To: netdev; +Cc: Linux/m68k, Rolf Anders
This adds an option to change the (10 MBit only) "apne" driver to support
the 10/100 Mbit cards (e.g. Netgear FA411, CNet Singlepoint) instead.
A new configure option is added as a bool to the apne driver to change the
behaviour to support some new cards instead.
The option can be only enabled if no other 8390 driver is active because the
8390 library is modified when activated.
The patch is initially from http://www.g-mb.de/pcmcia_e.html and adapted by
me from the 2.6 version.
The contained reset fix is required to use a pcmcia card after a reset/reboot,
and is also only activated with new option. (Background, as far as I
understood it: The pcmcia reset line is not connected and after a reset/reboot
the pcmcia card is in an undefined state and needs a manual reset.)
This reset patch is probably useful to all Amiga pcmcia drivers (network and
other) but since I do not own any other card I can't verify that.
Signed-off-by: ALeX Kazik <alex@kazik.de>
Tested-by: ALeX Kazik <alex@kazik.de>
diff -urp linux-4.18.7/drivers/net/ethernet/8390/8390.h linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h
--- linux-4.18.7/drivers/net/ethernet/8390/8390.h 2018-09-09 10:32:43.000000000 +0200
+++ linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h 2018-09-15 14:51:00.000000000 +0200
@@ -222,4 +222,21 @@ struct ei_device {
#define ENTSR_CDH 0x40 /* The collision detect "heartbeat" signal was lost. */
#define ENTSR_OWC 0x80 /* There was an out-of-window collision. */
+/* Change the driver to support word access instead of byte access.
+ * Cards that work with byte access will not work with word access.
+ */
+#ifdef CONFIG_APNE100MBIT
+/* redefine inb to do word accesses */
+#undef inb
+#define inb(x) ((x) & 1 ? inw((x) - 1) & 0xff : inw(x) >> 8)
+#undef inb_p
+#define inb_p(x) inb(x)
+
+/* The following redefinition of outb isn't necessary, but may be faster on
+ * slow processors.
+ */
+#undef outb
+#define outb(x, y) raw_outb(x, (y) + GAYLE_IO + (((y) & 1) ? GAYLE_ODD : 0))
+#endif
+
#endif /* _8390_h */
Only in linux-4.18.7-patched/drivers/net/ethernet/8390/: 8390.h.orig
diff -urp linux-4.18.7/drivers/net/ethernet/8390/Kconfig linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig
--- linux-4.18.7/drivers/net/ethernet/8390/Kconfig 2018-09-09 10:32:43.000000000 +0200
+++ linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig 2018-09-15 14:34:18.000000000 +0200
@@ -142,6 +142,22 @@ config APNE
To compile this driver as a module, choose M here: the module
will be called apne.
+if APNE
+config APNE100MBIT
+ bool "PCMCIA NE2000 100MBit support"
+ default n
+ depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n
+ depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n
+ depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
+ depends on XSURF100=n && ZORRO8390=n
+ ---help---
+ This changes the driver to support ONLY 10/100Mbit cards (e.g. Netgear
+ FA411, CNet Singlepoint).
+ Cards that worked with the original version won't with this version.
+
+ Say N, unless you absolutely know what you are doing.
+endif
+
config PCMCIA_PCNET
tristate "NE2000 compatible PCMCIA support"
depends on PCMCIA
diff -urp linux-4.18.7/drivers/net/ethernet/8390/apne.c linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c
--- linux-4.18.7/drivers/net/ethernet/8390/apne.c 2018-09-09 10:32:43.000000000 +0200
+++ linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c 2018-09-15 14:48:27.000000000 +0200
@@ -590,6 +590,16 @@ static int init_pcmcia(void)
#endif
u_long offset;
+#ifdef CONFIG_APNE100MBIT
+ /* reset card (idea taken from CardReset by Artur Pogoda) */
+ {
+ u_char tmp = gayle.intreq;
+
+ gayle.intreq = 0xff; mdelay(1);
+ gayle.intreq = tmp; mdelay(300);
+ }
+#endif
+
pcmcia_reset();
pcmcia_program_voltage(PCMCIA_0V);
pcmcia_access_speed(PCMCIA_SPEED_250NS);
^ permalink raw reply
* Re: [PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc
From: Jason A. Donenfeld @ 2018-09-16 0:31 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <201809160719.qunccnIZ%fengguang.wu@intel.com>
Greetings Mr. Ro Bot,
Another one of your robot friends also caught this, and the offending
code has been removed for v5.
Thanks for botting,
Jason
^ permalink raw reply
* Re: [PATCH net-next v4 19/20] security/keys: rewrite big_key crypto to use Zinc
From: Jason A. Donenfeld @ 2018-09-16 0:29 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Eric Biggers, David Howells
In-Reply-To: <201809160738.Z71qdjGu%fengguang.wu@intel.com>
Hey again Ro,
> 32bbe22e Jason A. Donenfeld 2018-09-14 49 imply KERNEL_MODE_NEON if CPU_V7
This shouldn't have ever been there anyway. Fixed now for v5.
Thanks,
Jason
^ permalink raw reply
* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: Maciej S. Szmigiero @ 2018-09-15 23:54 UTC (permalink / raw)
To: David Arendt; +Cc: linux-kernel, nic_swsd, netdev
In-Reply-To: <4f54989b-9492-420e-374b-d8c9bddf0a7d@prnet.org>
[ I've added Realtek Linux NIC and netdev mailing lists to CC ]
Hi David,
On 15.09.2018 23:23, David Arendt wrote:
> Hi,
>
> just a follow up:
>
> In kernel 4.18.8 the behaviour is different.
>
> The network is not reachable a number of times, but restarting to be
> reachable by itself before it finally is no longer reachable at all.
>
> Here the logging output:
>
> Sep 15 17:44:43 server kernel: NETDEV WATCHDOG: enp3s0 (r8169): transmit
> queue 0 timed out
> Sep 15 17:44:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:10:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:12:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:13:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:14:48 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:20:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:34:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:43:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:46:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 19:00:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>
> From 17:44 ro 18:46 the network is recovering automatically. After the
> up from 19:00, the network is no longer reachable without any additional
> message.
>
> If looking at ifconfig, the counter for TX packets is incrementing, the
> counter for RX packets not.
>
> Here again the driver from 4.17.14 is working flawlessly.
Could you please try this patch on top of 4.18.8:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f74dd480cf4e31e12971c58a1d832044db945670
In my case the problem fixed by the above commit was only limited to
bad TX performance but my r8169 NIC models were different from what
you have.
If this does not help then try bisecting the issue
(maybe limited to drivers/net/ethernet/realtek/r8169.c to save time).
If the NIC dies after a heavy load it might be possible to generate
such load quickly by in-kernel pktgen.
If that's not possible then at please least compare NIC register
values displayed by "ethtool -d enp3s0" between working and
non-working kernels.
> Thanks in advance,
> David Arendt
Maciej
>
>
> On 9/4/18 8:19 AM, David Arendt wrote:
>> Hi,
>>
>> When using kernel 4.18.5 the Realtek 8111G network adapter stops
>> responding under high system load.
>>
>> Dmesg is showing no errors.
>>
>> Sometimes an ifconfig enp3s0 down followed by an ifconfig enp3s0 up is
>> enough for the network adapter to restart responding. Sometimes a reboot
>> is necessary.
>>
>> When copying r8169.c from 4.17.14 to the 4.18.5 kernel, networking works
>> perfectly stable on 4.18.5 so the problem seems r8169.c related.
>>
>> Here the output from lshw:
>>
>> *-pci:2
>> description: PCI bridge
>> product: 8 Series/C220 Series Chipset Family PCI Express
>> Root Port #3
>> vendor: Intel Corporation
>> physical id: 1c.2
>> bus info: pci@0000:00:1c.2
>> version: d5
>> width: 32 bits
>> clock: 33MHz
>> capabilities: pci pciexpress msi pm normal_decode
>> bus_master cap_list
>> configuration: driver=pcieport
>> resources: irq:18 ioport:d000(size=4096)
>> memory:f7300000-f73fffff ioport:f2100000(size=1048576)
>> *-network
>> description: Ethernet interface
>> product: RTL8111/8168/8411 PCI Express Gigabit Ethernet
>> Controller
>> vendor: Realtek Semiconductor Co., Ltd.
>> physical id: 0
>> bus info: pci@0000:03:00.0
>> logical name: enp3s0
>> version: 0c
>> serial: <hidden>
>> size: 1Gbit/s
>> capacity: 1Gbit/s
>> width: 64 bits
>> clock: 33MHz
>> capabilities: pm msi pciexpress msix vpd bus_master
>> cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt
>> 1000bt-fd autonegotiation
>> configuration: autonegotiation=on broadcast=yes
>> driver=r8169 driverversion=2.3LK-NAPI duplex=full
>> firmware=rtl8168g-2_0.0.1 02/06/13 latency=0 link=yes multicast=yes
>> port=MII speed=1Gbit/s
>> resources: irq:18 ioport:d000(size=256)
>> memory:f7300000-f7300fff memory:f2100000-f2103fff
>>
>> Thanks in advance for looking into this,
>>
>> David Arendt
>>
>>
>
^ permalink raw reply
* Re: [PATCH net-next v4 19/20] security/keys: rewrite big_key crypto to use Zinc
From: kbuild test robot @ 2018-09-15 23:52 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, linux-crypto, davem, gregkh,
Jason A. Donenfeld, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson, Eric Biggers, David Howells
In-Reply-To: <20180914162240.7925-20-Jason@zx2c4.com>
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180916-043623
config: arm64-defconfig
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
GCC_VERSION=7.2.0 make.cross ARCH=arm64 defconfig
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> drivers/acpi/Kconfig:9:error: recursive dependency detected!
drivers/acpi/Kconfig:9: symbol ACPI depends on ARCH_SUPPORTS_ACPI
drivers/acpi/Kconfig:6: symbol ARCH_SUPPORTS_ACPI is selected by EFI
arch/arm64/Kconfig:1253: symbol EFI depends on KERNEL_MODE_NEON
arch/arm64/Kconfig:262: symbol KERNEL_MODE_NEON is implied by ZINC_ARCH_ARM
lib/zinc/Kconfig:42: symbol ZINC_ARCH_ARM depends on ZINC
>> lib/zinc/Kconfig:1: symbol ZINC is selected by ZINC_CHACHA20
>> lib/zinc/Kconfig:4: symbol ZINC_CHACHA20 is selected by ZINC_CHACHA20POLY1305
>> lib/zinc/Kconfig:13: symbol ZINC_CHACHA20POLY1305 is selected by BIG_KEYS
>> security/keys/Kconfig:44: symbol BIG_KEYS depends on KEYS
>> security/keys/Kconfig:5: symbol KEYS is selected by FS_ENCRYPTION
>> fs/crypto/Kconfig:1: symbol FS_ENCRYPTION is selected by UBIFS_FS_ENCRYPTION
>> fs/ubifs/Kconfig:65: symbol UBIFS_FS_ENCRYPTION depends on MISC_FILESYSTEMS
>> fs/Kconfig:218: symbol MISC_FILESYSTEMS is selected by ACPI_APEI
>> drivers/acpi/apei/Kconfig:8: symbol ACPI_APEI depends on ACPI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
vim +4 lib/zinc/Kconfig
32bbe22e Jason A. Donenfeld 2018-09-14 @1 config ZINC
32bbe22e Jason A. Donenfeld 2018-09-14 2 tristate
32bbe22e Jason A. Donenfeld 2018-09-14 3
35f45248 Jason A. Donenfeld 2018-09-14 @4 config ZINC_CHACHA20
35f45248 Jason A. Donenfeld 2018-09-14 5 bool
35f45248 Jason A. Donenfeld 2018-09-14 6 select ZINC
35f45248 Jason A. Donenfeld 2018-09-14 7 select CRYPTO_ALGAPI
35f45248 Jason A. Donenfeld 2018-09-14 8
0a36c146 Jason A. Donenfeld 2018-09-14 9 config ZINC_POLY1305
0a36c146 Jason A. Donenfeld 2018-09-14 10 bool
0a36c146 Jason A. Donenfeld 2018-09-14 11 select ZINC
0a36c146 Jason A. Donenfeld 2018-09-14 12
1b5dbb86 Jason A. Donenfeld 2018-09-14 @13 config ZINC_CHACHA20POLY1305
1b5dbb86 Jason A. Donenfeld 2018-09-14 14 bool
1b5dbb86 Jason A. Donenfeld 2018-09-14 15 select ZINC
1b5dbb86 Jason A. Donenfeld 2018-09-14 16 select ZINC_CHACHA20
1b5dbb86 Jason A. Donenfeld 2018-09-14 17 select ZINC_POLY1305
1b5dbb86 Jason A. Donenfeld 2018-09-14 18 select CRYPTO_BLKCIPHER
1b5dbb86 Jason A. Donenfeld 2018-09-14 19
a740374c Jason A. Donenfeld 2018-09-14 20 config ZINC_BLAKE2S
a740374c Jason A. Donenfeld 2018-09-14 21 bool
a740374c Jason A. Donenfeld 2018-09-14 22 select ZINC
a740374c Jason A. Donenfeld 2018-09-14 23
cec5aa7c Jason A. Donenfeld 2018-09-14 24 config ZINC_CURVE25519
cec5aa7c Jason A. Donenfeld 2018-09-14 25 bool
cec5aa7c Jason A. Donenfeld 2018-09-14 26 select ZINC
cec5aa7c Jason A. Donenfeld 2018-09-14 27 select CONFIG_CRYPTO
cec5aa7c Jason A. Donenfeld 2018-09-14 28
32bbe22e Jason A. Donenfeld 2018-09-14 29 config ZINC_DEBUG
32bbe22e Jason A. Donenfeld 2018-09-14 30 bool "Zinc cryptography library debugging and self-tests"
32bbe22e Jason A. Donenfeld 2018-09-14 31 depends on ZINC
32bbe22e Jason A. Donenfeld 2018-09-14 32 help
32bbe22e Jason A. Donenfeld 2018-09-14 33 This builds a series of self-tests for the Zinc crypto library, which
32bbe22e Jason A. Donenfeld 2018-09-14 34 help diagnose any cryptographic algorithm implementation issues that
32bbe22e Jason A. Donenfeld 2018-09-14 35 might be at the root cause of potential bugs. It also adds various
32bbe22e Jason A. Donenfeld 2018-09-14 36 debugging traps.
32bbe22e Jason A. Donenfeld 2018-09-14 37
32bbe22e Jason A. Donenfeld 2018-09-14 38 Unless you're developing and testing cryptographic routines, or are
32bbe22e Jason A. Donenfeld 2018-09-14 39 especially paranoid about correctness on your hardware, you may say
32bbe22e Jason A. Donenfeld 2018-09-14 40 N here.
32bbe22e Jason A. Donenfeld 2018-09-14 41
32bbe22e Jason A. Donenfeld 2018-09-14 @42 config ZINC_ARCH_ARM
32bbe22e Jason A. Donenfeld 2018-09-14 43 def_bool y
32bbe22e Jason A. Donenfeld 2018-09-14 44 depends on ARM
32bbe22e Jason A. Donenfeld 2018-09-14 45 depends on ZINC
32bbe22e Jason A. Donenfeld 2018-09-14 46 imply VFP
32bbe22e Jason A. Donenfeld 2018-09-14 47 imply VFPv3 if CPU_V7
32bbe22e Jason A. Donenfeld 2018-09-14 48 imply NEON if CPU_V7
32bbe22e Jason A. Donenfeld 2018-09-14 49 imply KERNEL_MODE_NEON if CPU_V7
32bbe22e Jason A. Donenfeld 2018-09-14 50
:::::: The code at line 4 was first introduced by commit
:::::: 35f45248597b5a2c80f0f4a680344c22c86efe7d zinc: ChaCha20 generic C implementation
:::::: TO: Jason A. Donenfeld <Jason@zx2c4.com>
:::::: CC: 0day robot <lkp@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v4 20/20] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-15 23:48 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <201809160701.EQDrNg4f%fengguang.wu@intel.com>
Hi Mr. Ro Bot,
Looks like this is related to stack frames with KASAN. I've fixed this for v5.
Thanks,
Jason
^ 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