* Compliment of the day to you Dear Friend.
From: Mrs. Amina Kadi @ 2018-09-13 13:22 UTC (permalink / raw)
Compliment of the day to you Dear Friend.
Dear Friend.
I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.
Mrs. Amina Kadi
^ permalink raw reply
* [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Arnaldo Carvalho de Melo @ 2018-09-13 18:32 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jakub Kicinski, Daniel Borkmann, Thomas Richter,
Hendrik Brueckner, Jiri Olsa, Namhyung Kim,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180911212451.hvnyfwyvcs4yojqy@ast-mbp>
Em Tue, Sep 11, 2018 at 02:24:53PM -0700, Alexei Starovoitov escreveu:
> On Tue, Sep 11, 2018 at 09:15:43AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Sep 11, 2018 at 12:22:18PM +0200, Jakub Kicinski escreveu:
> > > On Mon, 10 Sep 2018 14:29:03 -0300, Arnaldo Carvalho de Melo wrote:
> > > > After lunch I'll work on a patch to fix this,
> > > Any luck?
> > Well, we need to apply the patch below and make tools/lib/str_error_r.c
> > live in a library that libbpf and perf is linked to.
> do you want us to take the patch or you're applying it yourself?
Please do some testing with my perf/libbpf+str_error_r branch, it has
two patches to get this fixed, the one I sent and a prep one making
libbpf link against libapi.
[acme@jouet perf]$ git log --oneline -2
a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
[acme@jouet perf]$
I did a lot of tests to make sure tools/perf, tools/lib/bpf,
tools/bpf/bpftools and the bpf selftests all build as expected, with
OUTPUT= and in place.
The csets have further comments about tricky aspects of this.
- Arnaldo
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] man: Add devlink health man page
From: Andrew Lunn @ 2018-09-13 13:24 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Jakub Kicinski,
Simon Horman, Alexander Duyck, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <5c12253d-2100-09bb-9e3e-6259fc7a9323@mellanox.com>
On Thu, Sep 13, 2018 at 03:49:37PM +0300, Eran Ben Elisha wrote:
>
>
> On 9/13/2018 3:08 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.
> >
> >I hope the real sensors have more understandable names. If i remember
> >correctly, the same sort of comment was given for resource
> >management. It was pretty unclear what the resource names actually
> >mean. Is an average user going to have any idea how to actually use
> >these sensors and actions?
>
> well, hopefully. the whole point is to have it fully controlled by the user.
> However, names for the command should be short. I guess we shall have it
> documented (challenge is to fit to multi vendors).
>
> >
> >Can you give more examples of sensors. We should understand if there
> >are any overlaps with hwmon.
>
> I restate here that we shall have SW sensors as well, and not only HW
> sensors.
>
> 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
Hi Eran
I'm having trouble differentiating between these SW sensors and bugs
which need fixing. What causes a command interface error? Sending it a
command it does not understand? A wrongly formatted command? A command
the version of the firmware does not support? These all sound just
like plain old bugs which need fixing, not something which needs a
framework to detect them and try to recover from them by resetting
something.
I would of expected that all the issues are about physical
properties. Something similar to SMART for hard disks. The power
supplies are starting to droop, suggesting it might die soon. The
tacho on the fan suggests the FAN is not rotating as fast as it
should, so the motor is going to die soon. An SFP is giving i2c
errors, suggesting it is not seated correctly. The card as a whole is
overheating, despite the fan working, suggesting the ambient
temperature is just too high.
Andrew
^ permalink raw reply
* [PATCH net-next] net: phy: et011c: Remove incorrect PHY_POLL flags
From: Florian Fainelli @ 2018-09-13 18:36 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, David S. Miller, open list
PHY_POLL is defined as -1 which means that we would be setting all flags of the
PHY driver, this is also not a valid flag to tell PHYLIB about, just remove it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/et1011c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/et1011c.c b/drivers/net/phy/et1011c.c
index ab541c9c56fb..565e49e7f76f 100644
--- a/drivers/net/phy/et1011c.c
+++ b/drivers/net/phy/et1011c.c
@@ -92,7 +92,6 @@ static struct phy_driver et1011c_driver[] = { {
.name = "ET1011C",
.phy_id_mask = 0xfffffff0,
.features = PHY_GBIT_FEATURES,
- .flags = PHY_POLL,
.config_aneg = et1011c_config_aneg,
.read_status = et1011c_read_status,
} };
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] tg3: Fix fall-through annotations
From: Gustavo A. R. Silva @ 2018-09-13 18:39 UTC (permalink / raw)
To: Siva Reddy Kallam, Prashant Sreedharan, Michael Chan,
David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva
Replace "fallthru" with a proper "fall through" annotation.
This fix is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/broadcom/tg3.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index e6f28c7..ee7ef32 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -1598,7 +1598,7 @@ static int tg3_mdio_init(struct tg3 *tp)
phydev->dev_flags |= PHY_BRCM_EXT_IBND_RX_ENABLE;
if (tg3_flag(tp, RGMII_EXT_IBND_TX_EN))
phydev->dev_flags |= PHY_BRCM_EXT_IBND_TX_ENABLE;
- /* fallthru */
+ /* fall through */
case PHY_ID_RTL8211C:
phydev->interface = PHY_INTERFACE_MODE_RGMII;
break;
@@ -2127,7 +2127,7 @@ static int tg3_phy_init(struct tg3 *tp)
SUPPORTED_Asym_Pause);
break;
}
- /* fallthru */
+ /* fall through */
case PHY_INTERFACE_MODE_MII:
phydev->supported &= (PHY_BASIC_FEATURES |
SUPPORTED_Pause |
@@ -5215,7 +5215,7 @@ static int tg3_fiber_aneg_smachine(struct tg3 *tp,
if (ap->flags & (MR_AN_ENABLE | MR_RESTART_AN))
ap->state = ANEG_STATE_AN_ENABLE;
- /* fallthru */
+ /* fall through */
case ANEG_STATE_AN_ENABLE:
ap->flags &= ~(MR_AN_COMPLETE | MR_PAGE_RX);
if (ap->flags & MR_AN_ENABLE) {
@@ -5245,7 +5245,7 @@ static int tg3_fiber_aneg_smachine(struct tg3 *tp,
ret = ANEG_TIMER_ENAB;
ap->state = ANEG_STATE_RESTART;
- /* fallthru */
+ /* fall through */
case ANEG_STATE_RESTART:
delta = ap->cur_time - ap->link_time;
if (delta > ANEG_STATE_SETTLE_TIME)
@@ -5288,7 +5288,7 @@ static int tg3_fiber_aneg_smachine(struct tg3 *tp,
ap->state = ANEG_STATE_ACK_DETECT;
- /* fallthru */
+ /* fall through */
case ANEG_STATE_ACK_DETECT:
if (ap->ack_match != 0) {
if ((ap->rxconfig & ~ANEG_CFG_ACK) ==
@@ -14013,7 +14013,7 @@ static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
case SIOCGMIIPHY:
data->phy_id = tp->phy_addr;
- /* fallthru */
+ /* fall through */
case SIOCGMIIREG: {
u32 mii_regval;
--
2.7.4
^ permalink raw reply related
* general protection fault in xfrmi_rcv_cb
From: syzbot @ 2018-09-13 13:31 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 11957be20ff6 htb: use anonymous union for simplicity
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1773c6da400000
kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
dashboard link: https://syzkaller.appspot.com/bug?extid=af91688fec2b033aa620
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+af91688fec2b033aa620@syzkaller.appspotmail.com
RBP: 0000000020000000 R08: 00000000000000f0 R09: 0000000000000000
R10: 0000000000000064 R11: 0000000000000293 R12: 0000000000000004
R13: 00000000004d7270 R14: 00000000004ca37e R15: 0000000000000003
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 12674 Comm: syz-executor3 Not tainted 4.19.0-rc2+ #211
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:xs_net include/net/xfrm.h:253 [inline]
RIP: 0010:xfrmi_rcv_cb+0xd4/0x9d0 net/xfrm/xfrm_interface.c:256
Code: 7c e5 10 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 f0 07 00 00 48 b8 00
00 00 00 00 fc ff df 4f 8b 64 e5 10 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
85 da 07 00 00 49 8b 3c 24 49 8d b4 24 d0 00 00 00
RSP: 0018:ffff88019dd3e968 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff8801c56c5bc0 RCX: ffffc90003252000
RDX: 0000000000000000 RSI: ffffffff86b73915 RDI: ffff8801b93b6b88
RBP: ffff88019dd3e9a8 R08: ffff880191300640 R09: 1ffffffff12f43cd
R10: ffffed003b584732 R11: ffff8801dac23993 R12: 0000000000000000
R13: ffff8801b93b6b80 R14: ffff8801c56c5c28 R15: 0000000000000001
FS: 00007f969fbaa700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
kobject: 'loop0' (000000007546342c): kobject_uevent_env
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000019bf04000 CR4: 00000000001406f0
Call Trace:
xfrm6_rcv_cb+0x220/0x400 net/ipv6/xfrm6_protocol.c:59
kobject: 'tx-3' (000000000393e75f): kobject_uevent_env
xfrm_rcv_cb net/xfrm/xfrm_input.c:108 [inline]
xfrm_input+0x8aa/0x3190 net/xfrm/xfrm_input.c:495
kobject: 'loop0' (000000007546342c): fill_kobj_path: path
= '/devices/virtual/block/loop0'
kobject: 'tx-3' (000000000393e75f): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim3/net/wlan1/queues/tx-3'
kobject: 'loop1' (000000003d7d00b3): kobject_uevent_env
kobject: 'loop1' (000000003d7d00b3): fill_kobj_path: path
= '/devices/virtual/block/loop1'
xfrm6_rcv_spi net/ipv6/xfrm6_input.c:31 [inline]
xfrm6_rcv_tnl+0x168/0x1d0 net/ipv6/xfrm6_input.c:73
xfrm6_rcv+0x17/0x20 net/ipv6/xfrm6_input.c:80
kobject: 'loop4' (00000000627de047): kobject_uevent_env
xfrm6_esp_rcv+0x1a5/0x3a0 net/ipv6/xfrm6_protocol.c:74
kobject: 'loop4' (00000000627de047): fill_kobj_path: path
= '/devices/virtual/block/loop4'
ip6_input_finish+0x3fc/0x1aa0 net/ipv6/ip6_input.c:383
NF_HOOK include/linux/netfilter.h:287 [inline]
ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
ip6_mc_input+0x48a/0xd20 net/ipv6/ip6_input.c:503
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:287 [inline]
ipv6_rcv+0x11e/0x650 net/ipv6/ip6_input.c:271
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4894
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5004
netif_receive_skb_internal+0x12c/0x620 net/core/dev.c:5107
napi_frags_finish net/core/dev.c:5643 [inline]
napi_gro_frags+0x75a/0xc90 net/core/dev.c:5716
tun_get_user+0x31d5/0x42a0 drivers/net/tun.c:1965
tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:2010
call_write_iter include/linux/fs.h:1807 [inline]
do_iter_readv_writev+0x8b0/0xa80 fs/read_write.c:680
do_iter_write+0x185/0x5f0 fs/read_write.c:959
vfs_writev+0x1f1/0x360 fs/read_write.c:1004
do_writev+0x11a/0x310 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457161
Code: 75 14 b8 14 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 b6 fb ff c3 48
83 ec 08 e8 da 2c 00 00 48 89 04 24 b8 14 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 23 2d 00 00 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007f969fba9ba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 000000000000004a RCX: 0000000000457161
RDX: 0000000000000001 RSI: 00007f969fba9bf0 RDI: 00000000000000f0
RBP: 0000000020000000 R08: 00000000000000f0 R09: 0000000000000000
R10: 0000000000000064 R11: 0000000000000293 R12: 0000000000000004
R13: 00000000004d7270 R14: 00000000004ca37e R15: 0000000000000003
Modules linked in:
---[ end trace 37ac9ade311d7a37 ]---
RIP: 0010:xs_net include/net/xfrm.h:253 [inline]
RIP: 0010:xfrmi_rcv_cb+0xd4/0x9d0 net/xfrm/xfrm_interface.c:256
Code: 7c e5 10 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 f0 07 00 00 48 b8 00
00 00 00 00 fc ff df 4f 8b 64 e5 10 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
85 da 07 00 00 49 8b 3c 24 49 8d b4 24 d0 00 00 00
RSP: 0018:ffff88019dd3e968 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff8801c56c5bc0 RCX: ffffc90003252000
RDX: 0000000000000000 RSI: ffffffff86b73915 RDI: ffff8801b93b6b88
RBP: ffff88019dd3e9a8 R08: ffff880191300640 R09: 1ffffffff12f43cd
R10: ffffed003b584732 R11: ffff8801dac23993 R12: 0000000000000000
R13: ffff8801b93b6b80 R14: ffff8801c56c5c28 R15: 0000000000000001
FS: 00007f969fbaa700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000019bf04000 CR4: 00000000001406f0
---
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.
^ permalink raw reply
* Re: [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Alexei Starovoitov @ 2018-09-13 18:56 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jakub Kicinski, Daniel Borkmann, Thomas Richter,
Hendrik Brueckner, Jiri Olsa, Namhyung Kim,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180913183240.GF30969@kernel.org>
On Thu, Sep 13, 2018 at 03:32:40PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 11, 2018 at 02:24:53PM -0700, Alexei Starovoitov escreveu:
> > On Tue, Sep 11, 2018 at 09:15:43AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Sep 11, 2018 at 12:22:18PM +0200, Jakub Kicinski escreveu:
> > > > On Mon, 10 Sep 2018 14:29:03 -0300, Arnaldo Carvalho de Melo wrote:
> > > > > After lunch I'll work on a patch to fix this,
> > > > Any luck?
>
> > > Well, we need to apply the patch below and make tools/lib/str_error_r.c
> > > live in a library that libbpf and perf is linked to.
>
> > do you want us to take the patch or you're applying it yourself?
>
> Please do some testing with my perf/libbpf+str_error_r branch, it has
> two patches to get this fixed, the one I sent and a prep one making
> libbpf link against libapi.
>
> [acme@jouet perf]$ git log --oneline -2
> a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
> fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/libbpf%2bstr_error_r&id=fb4a79e04c2b37ee873a3b31a3250925cf466fff
we cannot do this.
lib/api is GPL we cannot use it in LGPL library.
^ permalink raw reply
* Re: [PATCH v3] neighbour: confirm neigh entries when ARP packet is received
From: David Miller @ 2018-09-13 19:02 UTC (permalink / raw)
To: sergei.shtylyov
Cc: vasilykh, roopa, adobriyan, edumazet, stephen, jwestfall,
w.bumiller, anarsoul, keescook, ihrachys, netdev, linux-kernel
In-Reply-To: <16ad730b-ef79-62b0-4b11-9473c0b033e1@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Thu, 13 Sep 2018 21:26:42 +0300
> Hello!
>
> On 09/13/2018 09:12 PM, Vasily Khoruzhick wrote:
>
>> Update 'confirmed' timestamp when ARP packet is received. It shouldn't
>> affect locktime logic and anyway entry can be confirmed by any higher-layer
>> protocol. Thus it makes sense to confirm it when ARP packet is received.
>>
>> Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is effective")
>
> Need at least 12 hex digits... Perhaps could be fixed when applying?
Yeah I took care of that.
>
>> Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
> [...]
Applied and queued up for -stable.
^ permalink raw reply
* [PATCH net-next] pktgen: Fix fall-through annotation
From: Gustavo A. R. Silva @ 2018-09-13 19:03 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Gustavo A. R. Silva
Replace "fallthru" with a proper "fall through" annotation.
This fix is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/core/pktgen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 7f69384..6ac9198 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3426,7 +3426,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
net_info_ratelimited("%s xmit error: %d\n",
pkt_dev->odevname, ret);
pkt_dev->errors++;
- /* fallthru */
+ /* fall through */
case NETDEV_TX_BUSY:
/* Retry it next time */
refcount_dec(&(pkt_dev->skb->users));
--
2.7.4
^ permalink raw reply related
* Re: KMSAN: uninit-value in pppoe_rcv
From: Eric Dumazet @ 2018-09-13 13:57 UTC (permalink / raw)
To: Alexander Potapenko, syzbot+f5f6080811c849739212
Cc: LKML, mostrows, Networking, syzkaller-bugs
In-Reply-To: <CAG_fn=Vk2HMPCLJV3aj1dt0KkDmksasBRRfKGnCTRHjvQ6OnQg@mail.gmail.com>
On 09/12/2018 03:38 AM, Alexander Potapenko wrote:
> On Wed, Sep 12, 2018 at 12:24 PM syzbot
> <syzbot+f5f6080811c849739212@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: d2d741e5d189 kmsan: add initialization for shmem pages
>> git tree: https://github.com/google/kmsan.git/master
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1465fc37800000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
>> dashboard link: https://syzkaller.appspot.com/bug?extid=f5f6080811c849739212
>> compiler: clang version 7.0.0 (trunk 329391)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d6e607800000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10a15b5b800000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com
>>
>> IPVS: ftp: loaded support on port[0] = 21
>> ==================================================================
>> BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline]
>> BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline]
>> BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0
>> drivers/net/ppp/pppoe.c:450
>> CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
>> __get_item drivers/net/ppp/pppoe.c:172 [inline]
>> get_item drivers/net/ppp/pppoe.c:236 [inline]
>> pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
>> __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562
>> __netif_receive_skb net/core/dev.c:4627 [inline]
>> netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
>> netif_receive_skb+0x230/0x240 net/core/dev.c:4725
>> tun_rx_batched drivers/net/tun.c:1555 [inline]
>> tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962
>> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
>> call_write_iter include/linux/fs.h:1782 [inline]
>> new_sync_write fs/read_write.c:469 [inline]
>> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
>> vfs_write+0x463/0x8d0 fs/read_write.c:544
>> SYSC_write+0x172/0x360 fs/read_write.c:589
>> SyS_write+0x55/0x80 fs/read_write.c:581
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> RIP: 0033:0x4447c9
>> RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001
>> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9
>> RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004
>> RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda
>> R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0
>> R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000
>>
>> Uninit was created at:
>> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
>> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
>> kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
>> slab_post_alloc_hook mm/slab.h:445 [inline]
>> slab_alloc_node mm/slub.c:2737 [inline]
>> __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
>> __kmalloc_reserve net/core/skbuff.c:138 [inline]
>> __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
>> alloc_skb include/linux/skbuff.h:984 [inline]
>> alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
>> sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
>> tun_alloc_skb drivers/net/tun.c:1532 [inline]
>> tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829
>> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
>> call_write_iter include/linux/fs.h:1782 [inline]
>> new_sync_write fs/read_write.c:469 [inline]
>> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
>> vfs_write+0x463/0x8d0 fs/read_write.c:544
>> SYSC_write+0x172/0x360 fs/read_write.c:589
>> SyS_write+0x55/0x80 fs/read_write.c:581
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> ==================================================================
> I did a little digging before sending the bug upstream.
> If I add memset(obj, 0xfe, size) to __kmalloc_reserve(), these 0xfe
> bytes are visible in __get_item() at the place where KMSAN reports an
> error.
>
> The problem is somehow related to tun_get_user() creating a fragmented
> sk_buff - when I change the call to tun_alloc_skb() so that it
> allocates a single buffer the bug goes away.
>
I guess the following patch would fix the issue
(I will submit it more formally)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index ce61231e96ea5fe27f512fbd0d80d4609997e508..333e967ed968ea3ff2dda25289f7f657263db2b9 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -423,6 +423,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
struct pppoe_hdr *ph;
struct pppox_sock *po;
struct pppoe_net *pn;
+ __be16 sid;
int len;
skb = skb_share_check(skb, GFP_ATOMIC);
@@ -434,6 +435,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
ph = pppoe_hdr(skb);
len = ntohs(ph->length);
+ sid = ph->sid;
skb_pull_rcsum(skb, sizeof(*ph));
if (skb->len < len)
@@ -447,7 +449,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
/* Note that get_item does a sock_hold(), so sk_pppox(po)
* is known to be safe.
*/
- po = get_item(pn, ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
+ po = get_item(pn, sid, eth_hdr(skb)->h_source, dev->ifindex);
if (!po)
goto drop;
^ permalink raw reply related
* Re: [PATCH v3] neighbour: confirm neigh entries when ARP packet is received
From: Vasiliy Khoruzhick @ 2018-09-13 19:10 UTC (permalink / raw)
To: David Miller
Cc: sergei.shtylyov, Roopa Prabhu, Alexey Dobriyan, Eric Dumazet,
Stephen Hemminger, Jim Westfall, Wolfgang Bumiller,
Vasily Khoruzhick, Kees Cook, Ihar Hrachyshka, netdev,
linux-kernel
In-Reply-To: <20180913.120241.924379440079172532.davem@davemloft.net>
On Thu, Sep 13, 2018 at 12:02 PM, David Miller <davem@davemloft.net> wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Date: Thu, 13 Sep 2018 21:26:42 +0300
>
>> Hello!
>>
>> On 09/13/2018 09:12 PM, Vasily Khoruzhick wrote:
>>
>>> Update 'confirmed' timestamp when ARP packet is received. It shouldn't
>>> affect locktime logic and anyway entry can be confirmed by any higher-layer
>>> protocol. Thus it makes sense to confirm it when ARP packet is received.
>>>
>>> Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is effective")
>>
>> Need at least 12 hex digits... Perhaps could be fixed when applying?
>
> Yeah I took care of that.
>
>>
>>> Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
>> [...]
>
> Applied and queued up for -stable.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] vxlan: Remove duplicated include from vxlan.h
From: David Miller @ 2018-09-13 19:10 UTC (permalink / raw)
To: yuehaibing; +Cc: linux-kernel, netdev
In-Reply-To: <20180913133223.14984-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 13 Sep 2018 21:32:23 +0800
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: et011c: Remove incorrect PHY_POLL flags
From: Andrew Lunn @ 2018-09-13 19:13 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, David S. Miller, open list
In-Reply-To: <20180913183630.32584-1-f.fainelli@gmail.com>
On Thu, Sep 13, 2018 at 11:36:30AM -0700, Florian Fainelli wrote:
> PHY_POLL is defined as -1 which means that we would be setting all flags of the
> PHY driver, this is also not a valid flag to tell PHYLIB about, just remove it.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] gso_segment: Reset skb->mac_len after modifying network header
From: Eric Dumazet @ 2018-09-13 14:11 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, netdev; +Cc: cake, Eric Dumazet
In-Reply-To: <153670437243.12756.693381878569982309.stgit@alrua-kau>
On 09/11/2018 03:19 PM, Toke Høiland-Jørgensen wrote:
> When splitting a GSO segment that consists of encapsulated packets, the
> skb->mac_len of the segments can end up being set wrong, causing packet
> drops in particular when using act_mirred and ifb interfaces in
> combination with a qdisc that splits GSO packets.
>
> This happens because at the time skb_segment() is called, network_header
> will point to the inner header, throwing off the calculation in
> skb_reset_mac_len(). The network_header is subsequently adjust by the
> outer IP gso_segment handlers, but they don't set the mac_len.
>
> Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6
> gso_segment handlers, after they modify the network_header.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Looks good but I would have appreciated a thanks or something
after the help I gave on this problem.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: KMSAN: uninit-value in pppoe_rcv
From: Alexander Potapenko @ 2018-09-13 14:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: syzbot+f5f6080811c849739212, LKML, mostrows, Networking,
syzkaller-bugs
In-Reply-To: <7424e094-afda-084a-ad80-299f219ced92@gmail.com>
On Thu, Sep 13, 2018 at 3:57 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 09/12/2018 03:38 AM, Alexander Potapenko wrote:
> > On Wed, Sep 12, 2018 at 12:24 PM syzbot
> > <syzbot+f5f6080811c849739212@syzkaller.appspotmail.com> wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: d2d741e5d189 kmsan: add initialization for shmem pages
> >> git tree: https://github.com/google/kmsan.git/master
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=1465fc37800000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=f5f6080811c849739212
> >> compiler: clang version 7.0.0 (trunk 329391)
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d6e607800000
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10a15b5b800000
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com
> >>
> >> IPVS: ftp: loaded support on port[0] = 21
> >> ==================================================================
> >> BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline]
> >> BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline]
> >> BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0
> >> drivers/net/ppp/pppoe.c:450
> >> CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:17 [inline]
> >> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
> >> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> >> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
> >> __get_item drivers/net/ppp/pppoe.c:172 [inline]
> >> get_item drivers/net/ppp/pppoe.c:236 [inline]
> >> pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
> >> __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562
> >> __netif_receive_skb net/core/dev.c:4627 [inline]
> >> netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
> >> netif_receive_skb+0x230/0x240 net/core/dev.c:4725
> >> tun_rx_batched drivers/net/tun.c:1555 [inline]
> >> tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962
> >> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
> >> call_write_iter include/linux/fs.h:1782 [inline]
> >> new_sync_write fs/read_write.c:469 [inline]
> >> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
> >> vfs_write+0x463/0x8d0 fs/read_write.c:544
> >> SYSC_write+0x172/0x360 fs/read_write.c:589
> >> SyS_write+0x55/0x80 fs/read_write.c:581
> >> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
> >> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> >> RIP: 0033:0x4447c9
> >> RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001
> >> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9
> >> RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004
> >> RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda
> >> R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0
> >> R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000
> >>
> >> Uninit was created at:
> >> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
> >> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
> >> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
> >> kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
> >> slab_post_alloc_hook mm/slab.h:445 [inline]
> >> slab_alloc_node mm/slub.c:2737 [inline]
> >> __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
> >> __kmalloc_reserve net/core/skbuff.c:138 [inline]
> >> __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
> >> alloc_skb include/linux/skbuff.h:984 [inline]
> >> alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
> >> sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
> >> tun_alloc_skb drivers/net/tun.c:1532 [inline]
> >> tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829
> >> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
> >> call_write_iter include/linux/fs.h:1782 [inline]
> >> new_sync_write fs/read_write.c:469 [inline]
> >> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
> >> vfs_write+0x463/0x8d0 fs/read_write.c:544
> >> SYSC_write+0x172/0x360 fs/read_write.c:589
> >> SyS_write+0x55/0x80 fs/read_write.c:581
> >> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
> >> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> >> ==================================================================
> > I did a little digging before sending the bug upstream.
> > If I add memset(obj, 0xfe, size) to __kmalloc_reserve(), these 0xfe
> > bytes are visible in __get_item() at the place where KMSAN reports an
> > error.
> >
> > The problem is somehow related to tun_get_user() creating a fragmented
> > sk_buff - when I change the call to tun_alloc_skb() so that it
> > allocates a single buffer the bug goes away.
> >
>
> I guess the following patch would fix the issue
>
> (I will submit it more formally)
No, as far as I can see it doesn't.
Saving sid before __skb_pull() is still a good idea, but in this
particular case |ph| doesn't change.
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> index ce61231e96ea5fe27f512fbd0d80d4609997e508..333e967ed968ea3ff2dda25289f7f657263db2b9 100644
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
> @@ -423,6 +423,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> struct pppoe_hdr *ph;
> struct pppox_sock *po;
> struct pppoe_net *pn;
> + __be16 sid;
> int len;
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> @@ -434,6 +435,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
>
> ph = pppoe_hdr(skb);
> len = ntohs(ph->length);
> + sid = ph->sid;
>
> skb_pull_rcsum(skb, sizeof(*ph));
> if (skb->len < len)
> @@ -447,7 +449,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> /* Note that get_item does a sock_hold(), so sk_pppox(po)
> * is known to be safe.
> */
> - po = get_item(pn, ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
> + po = get_item(pn, sid, eth_hdr(skb)->h_source, dev->ifindex);
> if (!po)
> goto drop;
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/7424e094-afda-084a-ad80-299f219ced92%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [Cake] [PATCH net] gso_segment: Reset skb->mac_len after modifying network header
From: Dave Taht @ 2018-09-13 14:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Toke Høiland-Jørgensen, Linux Kernel Network Developers,
Cake List, Eric Dumazet
In-Reply-To: <5dc16f03-7cd2-f797-1bda-592d5f5462b5@gmail.com>
On Thu, Sep 13, 2018 at 7:11 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 09/11/2018 03:19 PM, Toke Høiland-Jørgensen wrote:
> > When splitting a GSO segment that consists of encapsulated packets, the
> > skb->mac_len of the segments can end up being set wrong, causing packet
> > drops in particular when using act_mirred and ifb interfaces in
> > combination with a qdisc that splits GSO packets.
> >
> > This happens because at the time skb_segment() is called, network_header
> > will point to the inner header, throwing off the calculation in
> > skb_reset_mac_len(). The network_header is subsequently adjust by the
> > outer IP gso_segment handlers, but they don't set the mac_len.
> >
> > Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6
> > gso_segment handlers, after they modify the network_header.
> >
> > Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>
> Looks good but I would have appreciated a thanks or something
> after the help I gave on this problem.
>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks, eric! (post-hoc)
Acked-by: Dave Taht <dave.taht@gmail.com>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
^ permalink raw reply
* Re: [PATCH net] gso_segment: Reset skb->mac_len after modifying network header
From: Toke Høiland-Jørgensen @ 2018-09-13 14:22 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake, Eric Dumazet
In-Reply-To: <5dc16f03-7cd2-f797-1bda-592d5f5462b5@gmail.com>
On 13 September 2018 16:11:18 CEST, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>On 09/11/2018 03:19 PM, Toke Høiland-Jørgensen wrote:
>> When splitting a GSO segment that consists of encapsulated packets,
>the
>> skb->mac_len of the segments can end up being set wrong, causing
>packet
>> drops in particular when using act_mirred and ifb interfaces in
>> combination with a qdisc that splits GSO packets.
>>
>> This happens because at the time skb_segment() is called,
>network_header
>> will point to the inner header, throwing off the calculation in
>> skb_reset_mac_len(). The network_header is subsequently adjust by the
>> outer IP gso_segment handlers, but they don't set the mac_len.
>>
>> Fix this by adding skb_reset_mac_len() calls to both the IPv4 and
>IPv6
>> gso_segment handlers, after they modify the network_header.
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>
>Looks good but I would have appreciated a thanks or something
>after the help I gave on this problem.
Yes, of course. Should have mentioned that in the commit message.
My apologies, won't happen again. And thanks! :)
-Toke
^ permalink raw reply
* [PATCH net 0/2] udp: add missing check on edumx rx path
From: Paolo Abeni @ 2018-09-13 14:27 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Tom Herbert
The early demux RX path for the UDP protocol is currently missing
some checks. Both ipv4 and ipv6 implementations lack checksum conversion
and the ipv6 implementation additionally lack the zero checksum
validation.
The first patch takes care of UDPv4 and the second one of UDPv6
Paolo Abeni (2):
udp4: fix IP_CMSG_CHECKSUM for connected sockets
udp6: add missing checks on edumux packet processing
net/ipv4/udp.c | 49 +++++++++++++++++++------------------
net/ipv6/udp.c | 65 ++++++++++++++++++++++++++++----------------------
2 files changed, 63 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net 1/2] udp4: fix IP_CMSG_CHECKSUM for connected sockets
From: Paolo Abeni @ 2018-09-13 14:27 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Tom Herbert
In-Reply-To: <cover.1536848512.git.pabeni@redhat.com>
commit 2abb7cdc0dc8 ("udp: Add support for doing checksum
unnecessary conversion") left out the early demux path for
connected sockets. As a result IP_CMSG_CHECKSUM gives wrong
values for such socket when GRO is not enabled/available.
This change addresses the issue by moving the csum conversion to a
common helper and using such helper in both the default and the
early demux rx path.
Fixes: 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv4/udp.c | 49 ++++++++++++++++++++++++++-----------------------
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index f4e35b2ff8b8..7d69dd6fa7e8 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2124,6 +2124,28 @@ static inline int udp4_csum_init(struct sk_buff *skb, struct udphdr *uh,
inet_compute_pseudo);
}
+/* wrapper for udp_queue_rcv_skb tacking care of csum conversion and
+ * return code conversion for ip layer consumption
+ */
+static int udp_unicast_rcv_skb(struct sock *sk, struct sk_buff *skb,
+ struct udphdr *uh)
+{
+ int ret;
+
+ if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
+ skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
+ inet_compute_pseudo);
+
+ ret = udp_queue_rcv_skb(sk, skb);
+
+ /* a return value > 0 means to resubmit the input, but
+ * it wants the return to be -protocol, or 0
+ */
+ if (ret > 0)
+ return -ret;
+ return 0;
+}
+
/*
* All we need to do is get the socket, and then do a checksum.
*/
@@ -2170,14 +2192,9 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
if (unlikely(sk->sk_rx_dst != dst))
udp_sk_rx_dst_set(sk, dst);
- ret = udp_queue_rcv_skb(sk, skb);
+ ret = udp_unicast_rcv_skb(sk, skb, uh);
sock_put(sk);
- /* a return value > 0 means to resubmit the input, but
- * it wants the return to be -protocol, or 0
- */
- if (ret > 0)
- return -ret;
- return 0;
+ return ret;
}
if (rt->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST))
@@ -2185,22 +2202,8 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
saddr, daddr, udptable, proto);
sk = __udp4_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
- if (sk) {
- int ret;
-
- if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
- skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
- inet_compute_pseudo);
-
- ret = udp_queue_rcv_skb(sk, skb);
-
- /* a return value > 0 means to resubmit the input, but
- * it wants the return to be -protocol, or 0
- */
- if (ret > 0)
- return -ret;
- return 0;
- }
+ if (sk)
+ return udp_unicast_rcv_skb(sk, skb, uh);
if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
goto drop;
--
2.17.1
^ permalink raw reply related
* [PATCH net 2/2] udp6: add missing checks on edumux packet processing
From: Paolo Abeni @ 2018-09-13 14:27 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Tom Herbert
In-Reply-To: <cover.1536848512.git.pabeni@redhat.com>
Currently the UDPv6 early demux rx code path lacks some mandatory
checks, already implemented into the normal RX code path - namely
the checksum conversion and no_check6_rx check.
Similar to the previous commit, we move the common processing to
an UDPv6 specific helper and call it from both edemux code path
and normal code path. In respect to the UDPv4, we need to add an
explicit check for non zero csum according to no_check6_rx value.
Reported-by: Jianlin Shi <jishi@redhat.com>
Suggested-by: Xin Long <lucien.xin@gmail.com>
Fixes: c9f2c1ae123a ("udp6: fix socket leak on early demux")
Fixes: 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv6/udp.c | 65 ++++++++++++++++++++++++++++----------------------
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 83f4c77c79d8..28c4aa5078fc 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -752,6 +752,28 @@ static void udp6_sk_rx_dst_set(struct sock *sk, struct dst_entry *dst)
}
}
+/* wrapper for udp_queue_rcv_skb tacking care of csum conversion and
+ * return code conversion for ip layer consumption
+ */
+static int udp6_unicast_rcv_skb(struct sock *sk, struct sk_buff *skb,
+ struct udphdr *uh)
+{
+ int ret;
+
+ if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
+ skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
+ ip6_compute_pseudo);
+
+ ret = udpv6_queue_rcv_skb(sk, skb);
+
+ /* a return value > 0 means to resubmit the input, but
+ * it wants the return to be -protocol, or 0
+ */
+ if (ret > 0)
+ return -ret;
+ return 0;
+}
+
int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
int proto)
{
@@ -803,13 +825,14 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
if (unlikely(sk->sk_rx_dst != dst))
udp6_sk_rx_dst_set(sk, dst);
- ret = udpv6_queue_rcv_skb(sk, skb);
- sock_put(sk);
+ if (!uh->check && !udp_sk(sk)->no_check6_rx) {
+ sock_put(sk);
+ goto report_csum_error;
+ }
- /* a return value > 0 means to resubmit the input */
- if (ret > 0)
- return ret;
- return 0;
+ ret = udp6_unicast_rcv_skb(sk, skb, uh);
+ sock_put(sk);
+ return ret;
}
/*
@@ -822,30 +845,13 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
/* Unicast */
sk = __udp6_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
if (sk) {
- int ret;
-
- if (!uh->check && !udp_sk(sk)->no_check6_rx) {
- udp6_csum_zero_error(skb);
- goto csum_error;
- }
-
- if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
- skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
- ip6_compute_pseudo);
-
- ret = udpv6_queue_rcv_skb(sk, skb);
-
- /* a return value > 0 means to resubmit the input */
- if (ret > 0)
- return ret;
-
- return 0;
+ if (!uh->check && !udp_sk(sk)->no_check6_rx)
+ goto report_csum_error;
+ return udp6_unicast_rcv_skb(sk, skb, uh);
}
- if (!uh->check) {
- udp6_csum_zero_error(skb);
- goto csum_error;
- }
+ if (!uh->check)
+ goto report_csum_error;
if (!xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb))
goto discard;
@@ -866,6 +872,9 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
ulen, skb->len,
daddr, ntohs(uh->dest));
goto discard;
+
+report_csum_error:
+ udp6_csum_zero_error(skb);
csum_error:
__UDP6_INC_STATS(net, UDP_MIB_CSUMERRORS, proto == IPPROTO_UDPLITE);
discard:
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH iproute2-next] man: Add devlink health man page
From: Eran Ben Elisha @ 2018-09-13 14:30 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: <20180913132453.GE11702@lunn.ch>
On 9/13/2018 4:24 PM, Andrew Lunn wrote:
> On Thu, Sep 13, 2018 at 03:49:37PM +0300, Eran Ben Elisha wrote:
>>
>>
>> On 9/13/2018 3:08 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.
>>>
>>> I hope the real sensors have more understandable names. If i remember
>>> correctly, the same sort of comment was given for resource
>>> management. It was pretty unclear what the resource names actually
>>> mean. Is an average user going to have any idea how to actually use
>>> these sensors and actions?
>>
>> well, hopefully. the whole point is to have it fully controlled by the user.
>> However, names for the command should be short. I guess we shall have it
>> documented (challenge is to fit to multi vendors).
>>
>>>
>>> Can you give more examples of sensors. We should understand if there
>>> are any overlaps with hwmon.
>>
>> I restate here that we shall have SW sensors as well, and not only HW
>> sensors.
>>
>> 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
>
> Hi Eran
>
> I'm having trouble differentiating between these SW sensors and bugs
> which need fixing. What causes a command interface error? Sending it a
> command it does not understand? A wrongly formatted command? A command
> the version of the firmware does not support? These all sound just
> like plain old bugs which need fixing, not something which needs a
> framework to detect them and try to recover from them by resetting
> something.
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.
>
> I would of expected that all the issues are about physical
> properties. Something similar to SMART for hard disks. The power
> supplies are starting to droop, suggesting it might die soon. The
> tacho on the fan suggests the FAN is not rotating as fast as it
> should, so the motor is going to die soon. An SFP is giving i2c
> errors, suggesting it is not seated correctly. The card as a whole is
> overheating, despite the fan working, suggesting the ambient
> temperature is just too high.
AFAIU, the kind of sensors you suggest here requires manual fix /
physically approaching to the setup, replace HW, install new Fan, etc.
Monitor such events is easy, driver can just log events from HW to the
dmesg and end its handle there.
None of these is a real networking issue I would like to handle with
devlink-health.
Eran
>
> Andrew
>
^ permalink raw reply
* Re: [net-next, PATCH 2/2, v2] net: socionext: add XDP support
From: Jesper Dangaard Brouer @ 2018-09-13 14:32 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: netdev, jaswinder.singh, ard.biesheuvel, masami.hiramatsu, arnd,
mykyta.iziumtsev, bjorn.topel, magnus.karlsson, daniel, ast,
brouer
In-Reply-To: <20180912092915.GA31978@apalos>
On Wed, 12 Sep 2018 12:29:15 +0300
Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> On Wed, Sep 12, 2018 at 11:25:24AM +0200, Jesper Dangaard Brouer wrote:
> > On Wed, 12 Sep 2018 12:02:38 +0300
> > Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> >
> > > static const struct net_device_ops netsec_netdev_ops = {
> > > .ndo_init = netsec_netdev_init,
> > > .ndo_uninit = netsec_netdev_uninit,
> > > @@ -1430,6 +1627,7 @@ static const struct net_device_ops netsec_netdev_ops = {
> > > .ndo_set_mac_address = eth_mac_addr,
> > > .ndo_validate_addr = eth_validate_addr,
> > > .ndo_do_ioctl = netsec_netdev_ioctl,
> > > + .ndo_bpf = netsec_xdp,
> > > };
> > >
> >
> > You have not implemented ndo_xdp_xmit.
> >
> > Thus, you have "only" implemented the RX side of XDP_REDIRECT. Which
> > allows you to do, cpumap and AF_XDP redirects, but not allowing other
> > drivers to XDP send out this device.
>
> Correct, that was the planning, is ndo_xdp_xmit() needed for the patch or
> is the patch message just misleading and i should change that ?
Yes, I think you should ALSO implement ndo_xdp_xmit, maybe as a separate
patch, but in the same series. (Our experience is that if we don't
require this, people forget to complete this part of the XDP support).
Also you XDP_TX is not optimal, as it (looks like) you flush TX on
every send.
BTW, do you have any performance numbers?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Arnaldo Carvalho de Melo @ 2018-09-13 19:44 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Josh Poimboeuf, Arnaldo Carvalho de Melo, Jakub Kicinski,
Daniel Borkmann, Thomas Richter, Hendrik Brueckner, Jiri Olsa,
Namhyung Kim, Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180913185629.su22fnimluoezntg@ast-mbp>
Em Thu, Sep 13, 2018 at 11:56:31AM -0700, Alexei Starovoitov escreveu:
> On Thu, Sep 13, 2018 at 03:32:40PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Sep 11, 2018 at 02:24:53PM -0700, Alexei Starovoitov escreveu:
> > > On Tue, Sep 11, 2018 at 09:15:43AM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Tue, Sep 11, 2018 at 12:22:18PM +0200, Jakub Kicinski escreveu:
> > > > > On Mon, 10 Sep 2018 14:29:03 -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > After lunch I'll work on a patch to fix this,
> > > > > Any luck?
> >
> > > > Well, we need to apply the patch below and make tools/lib/str_error_r.c
> > > > live in a library that libbpf and perf is linked to.
> >
> > > do you want us to take the patch or you're applying it yourself?
> >
> > Please do some testing with my perf/libbpf+str_error_r branch, it has
> > two patches to get this fixed, the one I sent and a prep one making
> > libbpf link against libapi.
> >
> > [acme@jouet perf]$ git log --oneline -2
> > a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
> > fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
>
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/libbpf%2bstr_error_r&id=fb4a79e04c2b37ee873a3b31a3250925cf466fff
> we cannot do this.
> lib/api is GPL we cannot use it in LGPL library.
Humm, I wrote tools/lib/str_error_r.c, so I can possibly relicense it as
LGPL and then link just that one, as I did in one of my local patches.
The only line that is not from me in tha file is from Josh Poinboeuf,
which I CCed here.
- Arnaldo
^ permalink raw reply
* [PATCH net v2] gso_segment: Reset skb->mac_len after modifying network header
From: Toke Høiland-Jørgensen @ 2018-09-13 14:43 UTC (permalink / raw)
To: netdev
Cc: Toke Høiland-Jørgensen, cake, David Miller,
Eric Dumazet, Dave Taht
In-Reply-To: <153670437243.12756.693381878569982309.stgit@alrua-kau>
When splitting a GSO segment that consists of encapsulated packets, the
skb->mac_len of the segments can end up being set wrong, causing packet
drops in particular when using act_mirred and ifb interfaces in
combination with a qdisc that splits GSO packets.
This happens because at the time skb_segment() is called, network_header
will point to the inner header, throwing off the calculation in
skb_reset_mac_len(). The network_header is subsequently adjust by the
outer IP gso_segment handlers, but they don't set the mac_len.
Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6
gso_segment handlers, after they modify the network_header.
Many thanks to Eric Dumazet for his help in identifying the cause of
the bug.
Acked-by: Dave Taht <dave.taht@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
v2:
- Properly credit Eric for his help
- Add review and ack tags
net/ipv4/af_inet.c | 1 +
net/ipv6/ip6_offload.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 20fda8fb8ffd..1fbe2f815474 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1377,6 +1377,7 @@ struct sk_buff *inet_gso_segment(struct sk_buff *skb,
if (encap)
skb_reset_inner_headers(skb);
skb->network_header = (u8 *)iph - skb->head;
+ skb_reset_mac_len(skb);
} while ((skb = skb->next));
out:
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 37ff4805b20c..c7e495f12011 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -115,6 +115,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
payload_len = skb->len - nhoff - sizeof(*ipv6h);
ipv6h->payload_len = htons(payload_len);
skb->network_header = (u8 *)ipv6h - skb->head;
+ skb_reset_mac_len(skb);
if (udpfrag) {
int err = ip6_find_1stfragopt(skb, &prevhdr);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: ethtool tx napi configuration
From: Willem de Bruijn @ 2018-09-13 14:58 UTC (permalink / raw)
To: Jason Wang
Cc: f.fainelli, Network Development, David Miller, caleb.raitto,
Michael S. Tsirkin, Jon Olson (Google Drive), Willem de Bruijn
In-Reply-To: <4a3d69be-8651-e36d-bc14-5a3f1f23d155@redhat.com>
On Thu, Sep 13, 2018 at 5:02 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
>
> On 2018年09月13日 07:27, Willem de Bruijn wrote:
> > On Wed, Sep 12, 2018 at 3:11 PM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> >> On Wed, Sep 12, 2018 at 2:16 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>>
> >>>
> >>> On 9/12/2018 11:07 AM, Willem de Bruijn wrote:
> >>>> On Wed, Sep 12, 2018 at 1:42 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> On 9/9/2018 3:44 PM, Willem de Bruijn wrote:
> >>>>>> From: Willem de Bruijn <willemb@google.com>
> >>>>>>
> >>>>>> Implement ethtool .set_coalesce (-C) and .get_coalesce (-c) handlers.
> >>>>>> Interrupt moderation is currently not supported, so these accept and
> >>>>>> display the default settings of 0 usec and 1 frame.
> >>>>>>
> >>>>>> Toggle tx napi through a bit in tx-frames. So as to not interfere
> >>>>>> with possible future interrupt moderation, use bit 10, well outside
> >>>>>> the reasonable range of real interrupt moderation values.
> >>>>>>
> >>>>>> Changes are not atomic. The tx IRQ, napi BH and transmit path must
> >>>>>> be quiesced when switching modes. Only allow changing this setting
> >>>>>> when the device is down.
> >>>>> Humm, would not a private ethtool flag to switch TX NAPI on/off be more
> >>>>> appropriate rather than use the coalescing configuration API here?
> >>>> What do you mean by private ethtool flag? A new field in ethtool
> >>>> --features (-k)?
> >>> I meant using ethtool_drvinfo::n_priv_flags, ETH_SS_PRIV_FLAGS and then
> >>> ETHTOOL_GFPFLAGS and ETHTOOL_SPFLAGS to control the toggling of that
> >>> private flag. mlx5 has a number of privates flags for instance.
> >> Interesting, thanks! I was not at all aware of those ethtool flags.
> >> Am having a look. It definitely looks promising.
> > Okay, I made that change. That is indeed much cleaner, thanks.
> > Let me send the patch, initially as RFC.
> >
> > I've observed one issue where if we toggle the flag before bringing
> > up the device, it hits a kernel BUG at include/linux/netdevice.h:515
> >
> > BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
>
> This reminds me that we need to check netif_running() before trying to
> enable and disable tx napi in ethtool_set_coalesce().
The first iteration of my patch checked IFF_UP and effectively
only allowed the change when not running. What do you mean
by need to check?
And to respond to the other follow-up notes at once:
> Consider we may have interrupt moderation in the future, I tend to use
> set_coalesce. Otherwise we may need two steps to enable moderation:
>
> - tx-napi on
> - set_coalesce
FWIW, I don't care strongly whether we do this through coalesce or priv_flags.
>> + if (!napi_weight)
>> + virtqueue_enable_cb(vi->sq[i].vq);
>
> I don't get why we need to disable enable cb here.
To avoid entering no-napi mode with too few descriptors to
make progress and no way to get out of that state. This is a
pretty crude attempt at handling that, admittedly.
^ 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