* Re: [PATCH net] net: validate untrusted gso packets without csum offload
From: Willem de Bruijn @ 2019-02-18 19:12 UTC (permalink / raw)
To: Network Development
Cc: David Miller, Eric Dumazet, Jason Wang, Maxim Mikityanskiy,
Willem de Bruijn, syzbot
In-Reply-To: <20190215171547.247018-1-willemdebruijn.kernel@gmail.com>
On Fri, Feb 15, 2019 at 12:15 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> From: Willem de Bruijn <willemb@google.com>
>
> Syzkaller again found a path to a kernel crash through bad gso input.
> By building an excessively large packet to cause an skb field to wrap.
>
> If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have been dropped in
> skb_partial_csum_set.
>
> GSO packets that do not set checksum offload are suspicious and rare.
> Most callers of virtio_net_hdr_to_skb already pass them to
> skb_probe_transport_header.
>
> Move that test forward, change it to detect parse failure and drop
> packets on failure as those cleary are not one of the legitimate
> VIRTIO_NET_HDR_GSO types.
>
> Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.")
> Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
This causes false positive drops on virtio-net and tun for these
packets with gso without csum_off. And on pf_packet with proto 0.
This happens because skb->protocol is set in these callers after
the call to virtio_net_hdr_to_skb. And the flow dissector relies on
this to start dissection, not the link layer header (if present).
Moving this logic forward is too much churn for net, especially since
eth_type_header pulls the header, requiring additional changes to
adjust csum_start.
virtio_net_hdr_set_proto() aims to fix this by deriving skb->protocol
from the gso_type. But unfortunately for UDP it unconditionally
selects ipv4, which will cause drops for UDP over ipv6.
For net I plan to just ignore the error for these callers that do not
set skb->protocol.
- if (!skb_transport_header_was_set(skb))
+ if (!skb_transport_header_was_set(skb) && skb->protocol)
Possibly with an extension of tpacket_set_protocol to also cover
packet_snd, so that that cannot evade it on purpose. Other callers can
wait till net-next.
>
> ---
>
> This captures a variety of bad gso packets, but to tighten further:
>
> - drop SKB_GSO_DODGY packets with ipip/sit/.. , which cannot be legal.
> by ipip_gso_segment wrappers around inet_gso_segment
> expands on 121d57af308d ("gso: validate gso_type in GSO handlers")
>
> - limit the number of ipv6 exthdrs allowed from dodgy sources.
> not sure where to draw the line. but not at 64K ;)
This already exists, in the form of skb_flow_dissect_allowed
> - validate the network and transport protocol returned in
> skb_probe_transport_header against the VIRTIO_NET_HDR_GSO type
>
> - probe all dodgy GSO packets, also those that set checksum offload.
> this will have a performance impact, discussed previously in
> http://patchwork.ozlabs.org/patch/861874/
> but it would have blocked this latest bug as well
>
> All but the last one seem pretty uncontroversial to me. If no one
> objects I plan to send those to net-next.
>
> ---
> include/linux/skbuff.h | 2 +-
> include/linux/virtio_net.h | 9 +++++++++
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 95d25b010a25..4c1c82a5678c 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -2434,7 +2434,7 @@ static inline void skb_probe_transport_header(struct sk_buff *skb,
>
> if (skb_flow_dissect_flow_keys_basic(skb, &keys, NULL, 0, 0, 0, 0))
> skb_set_transport_header(skb, keys.control.thoff);
> - else
> + else if (offset_hint >= 0)
> skb_set_transport_header(skb, offset_hint);
> }
>
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index cb462f9ab7dd..71f2394abbf7 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -57,6 +57,15 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>
> if (!skb_partial_csum_set(skb, start, off))
> return -EINVAL;
> + } else {
> + /* gso packets without NEEDS_CSUM do not set transport_offset.
> + * probe and drop if does not match one of the above types.
> + */
> + if (gso_type) {
> + skb_probe_transport_header(skb, -1);
> + if (!skb_transport_header_was_set(skb))
> + return -EINVAL;
> + }
> }
>
> if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> --
> 2.21.0.rc0.258.g878e2cd30e-goog
>
^ permalink raw reply
* Re: [PATCH net-next 00/12] Refactor flower classifier to remove dependency on rtnl lock
From: Cong Wang @ 2019-02-18 19:15 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <20190214074712.17846-1-vladbu@mellanox.com>
Hi,
> net/sched/cls_flower.c | 424 +++++++++++++++++++++++++++++++++++++------------
> 1 file changed, 321 insertions(+), 103 deletions(-)
>
Given you change cls_flower so much, please also add a test case for
verifying your changes, especially focusing on the atomicity of concurrent
modifications.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Kalle Valo @ 2019-02-18 19:20 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
x86, linux-wireless, Christoph Hellwig, David S. Miller, netdev,
linux-kernel, Lorenzo Bianconi, linux-mediatek, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <87tvh0syq2.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>>
>>> __sw_hweight8() is just internal implementation.
>>>
>>> Drivers should use the common API, hweight8().
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>>
>> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>>
>>> This patch should go to x86 tree along with 2/2.
>>>
>>> Otherwise, all{yes,mod}config of x86 would be broken.
>>>
>>> This patch is trivial enough.
>>> I want ACK from the net/wireless maintainer
>>> so that this can go in via x86 tree.
>>
>> Sounds good to me, feel free to push via the x86 tree.
>
> Actually, can you wait a bit? Felix just reminded me that we have a
> similar patch pending from Ben Hutchings:
>
> https://patchwork.kernel.org/patch/10808203/
>
> And it seems there are two instances of __sw_hweight8, at least in my
> wireless-drivers-next tree:
>
> drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> __sw_hweight8(dev->antenna_mask);
> drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> __sw_hweight8(dev->antenna_mask);
>
> So we need to think what to do.
I think the best would be that Felix applies Ben's patch to the wireless
tree and I'll push it to Linus during the next merge window (via
net-next). Simpler and less conflicts that way.
So Masahiro, could you hold your x86 patch for a while until the mt76
patch will be in Linus' tree? That should not take more than two weeks,
I think.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next 12/12] net: sched: flower: set unlocked flag for flower proto ops
From: Cong Wang @ 2019-02-18 19:27 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <20190214074712.17846-13-vladbu@mellanox.com>
On Wed, Feb 13, 2019 at 11:47 PM Vlad Buslov <vladbu@mellanox.com> wrote:
>
> Set TCF_PROTO_OPS_DOIT_UNLOCKED for flower classifier to indicate that its
> ops callbacks don't require caller to hold rtnl lock.
So, if this means RTNL is gone for all cls_flower changes, why
do I still see rtnl_lock() in cls_flower.c after all your patches in this set?
For instance:
366 static void fl_destroy_filter_work(struct work_struct *work)
367 {
368 struct cls_fl_filter *f = container_of(to_rcu_work(work),
369 struct cls_fl_filter, rwork);
370
371 rtnl_lock();
372 __fl_destroy_filter(f);
373 rtnl_unlock();
374 }
and...
382 if (!rtnl_held)
383 rtnl_lock();
...
1436 if (!rtnl_held)
1437 rtnl_lock();
Please explain in your changelog, otherwise it is very confusing.
Thanks.
^ permalink raw reply
* [PATCH net-next 0/2] net: phy: improve genphy_read_status
From: Heiner Kallweit @ 2019-02-18 19:28 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Series includes two smaller improvements to genphy_read_status.
Heiner Kallweit (2):
net: phy: remove orphaned register read in genphy_read_status
net: phy: don't use 10BaseT/half as default in genphy_read_status
drivers/net/phy/phy_device.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net-next 1/2] net: phy: remove orphaned register read in genphy_read_status
From: Heiner Kallweit @ 2019-02-18 19:28 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <1a948543-0dc6-d5df-d50a-49134a2a4118@gmail.com>
After recent changes to genphy_read_status() this orphaned register
read remained as leftover. So remove it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 7e71124bb..803197fdd 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1785,10 +1785,6 @@ int genphy_read_status(struct phy_device *phydev)
mii_lpa_mod_linkmode_lpa_t(phydev->lp_advertising, lpa);
- adv = phy_read(phydev, MII_ADVERTISE);
- if (adv < 0)
- return adv;
-
phydev->speed = SPEED_10;
phydev->duplex = DUPLEX_HALF;
phydev->pause = 0;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: don't use 10BaseT/half as default in genphy_read_status
From: Heiner Kallweit @ 2019-02-18 19:29 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <1a948543-0dc6-d5df-d50a-49134a2a4118@gmail.com>
If link partner and we can't agree on any mode, then it doesn't make
sense to pretend we would have agreed on 10/half. Therefore set a
proper default.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 803197fdd..4bb3b6c28 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1785,8 +1785,8 @@ int genphy_read_status(struct phy_device *phydev)
mii_lpa_mod_linkmode_lpa_t(phydev->lp_advertising, lpa);
- phydev->speed = SPEED_10;
- phydev->duplex = DUPLEX_HALF;
+ phydev->speed = SPEED_UNKNOWN;
+ phydev->duplex = DUPLEX_UNKNOWN;
phydev->pause = 0;
phydev->asym_pause = 0;
--
2.20.1
^ permalink raw reply related
* Re: TC stats / hw offload question
From: Edward Cree @ 2019-02-18 19:37 UTC (permalink / raw)
To: Jamal Hadi Salim, netdev
Cc: Jiri Pirko, Cong Wang, Or Gerlitz, Andy Gospodarek, PJ Waskiewicz,
Anjali Singhai Jain, Jakub Kicinski
In-Reply-To: <5930f8e7-3615-5470-ea09-f0e6f2a3a3d7@solarflare.com>
On 18/02/19 18:56, Edward Cree wrote:
> (or
> maybe require it to be set to some distinguished value, like 0, to
> mean 'allocate', so that as a future extension we can support
> shareable counters).
Turns out 0 isn't an option, because TC already internally swallows
that and allocates its own index (same as if 'index' wasn't specified
on cmdline at all), unless we can change TC to pass that 0 on to the
driver.
-Ed
^ permalink raw reply
* Re: [PATCH net-next v4 10/17] net: sched: refactor tp insert/delete for concurrent execution
From: Cong Wang @ 2019-02-18 19:53 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190211085548.7190-11-vladbu@mellanox.com>
On Mon, Feb 11, 2019 at 12:56 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> +#define tcf_proto_dereference(p, tp) \
> + rcu_dereference_protected(p, lockdep_tcf_proto_is_locked(tp))
> +
BTW, it is not used anywhere even on top of your cls_flower changes...
$ git grep tcf_proto_dereference
include/net/sch_generic.h:#define tcf_proto_dereference(p, tp)
\
Please don't introduce new things unitl you actually use it.
^ permalink raw reply
* Re: [PATCH net-next v4 10/17] net: sched: refactor tp insert/delete for concurrent execution
From: Cong Wang @ 2019-02-18 19:55 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <vbfimxhqr7z.fsf@mellanox.com>
On Mon, Feb 18, 2019 at 3:19 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Fri 15 Feb 2019 at 23:17, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Mon, Feb 11, 2019 at 12:56 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> >> +static bool tcf_proto_is_empty(struct tcf_proto *tp)
> >> +{
> >> + struct tcf_walker walker = { .fn = walker_noop, };
> >> +
> >> + if (tp->ops->walk) {
> >> + tp->ops->walk(tp, &walker);
> >> + return !walker.stop;
> >> + }
> >> + return true;
> >> +}
> >> +
> >> +static bool tcf_proto_check_delete(struct tcf_proto *tp)
> >> +{
> >> + spin_lock(&tp->lock);
> >> + if (tcf_proto_is_empty(tp))
> >> + tp->deleting = true;
> >> + spin_unlock(&tp->lock);
> >> + return tp->deleting;
> >
> > If you use this spinlock for walking each tp data structure,
> > why it is not needed for adding to/deleting filters from each
> > tp?
>
> This lock is intended to be used by unlocked classifiers and I use it in
> my following flower patch set extensively. Classifiers that do not set
> 'unlocked' flag continue to rely on rtnl lock for synchronization.
It is never late to add it when you seriously use it. The way you
split the patches is really annoying for reviewers...
^ permalink raw reply
* Re: [PATCH 00/11] Netfilter/IPVS updates for net-next
From: David Miller @ 2019-02-18 19:59 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190217232357.29858-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 18 Feb 2019 00:23:46 +0100
> The following patchset contains Netfilter/IPVS updates for you net-next
> tree:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH net 0/2] tcp: fix possible crash in tcp_v4_err()
From: David Miller @ 2019-02-18 19:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: edumazet, netdev, ncardwell, ycheng, soukjin.bae
In-Reply-To: <8e6280f3-ea5b-48bd-4dc0-da134d4125d2@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 17 Feb 2019 18:20:21 -0800
>
>
> On 02/17/2019 03:47 PM, David Miller wrote:
>> From: Eric Dumazet <edumazet@google.com>
>> Date: Fri, 15 Feb 2019 13:36:19 -0800
>>
>>> soukjin bae reported a crash in tcp_v4_err() that we
>>> root caused to a missing initialization.
>>>
>>> Second patch adds a sanity check in tcp_v4_err() to avoid
>>> future potential problems. Ignoring an ICMP message
>>> is probably better than crashing a machine.
>>
>> Series applied, thanks Eric.
>>
>> Want me to queue these up for -stable?
>>
>
> Yes please, I put no Fixes: tag because it seemed to be a day-0 bug.
Done.
^ permalink raw reply
* Re: [RFC PATCH net-next v3 02/21] ethtool: move to its own directory
From: Jakub Kicinski @ 2019-02-18 20:01 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, David Miller, Andrew Lunn, Jiri Pirko, linux-kernel
In-Reply-To: <2078f959ed3474c4228fd6016c892331f8e2c7b8.1550513384.git.mkubecek@suse.cz>
On Mon, 18 Feb 2019 19:21:34 +0100 (CET), Michal Kubecek wrote:
> The ethtool netlink interface is going to be split into multiple files so
> that it will be more convenient to put all of them in a separate directory
> net/ethtool. Start by moving current ethtool.c with ioctl interface into
> this directory and renaming it to ioct.c.
nit: s/ioct.c/ioctl.c/
^ permalink raw reply
* Re: [PATCH net v2] net: crypto set sk to NULL when af_alg_release.
From: David Miller @ 2019-02-18 20:02 UTC (permalink / raw)
To: maowenan; +Cc: netdev, xiyou.wangcong, linux-kernel
In-Reply-To: <20190218024444.137328-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Mon, 18 Feb 2019 10:44:44 +0800
> KASAN has found use-after-free in sockfs_setattr.
> The existed commit 6d8c50dcb029 ("socket: close race condition between sock_close()
> and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
> that crypto module forgets to set the sk to NULL after af_alg_release.
>
> KASAN report details as below:
> BUG: KASAN: use-after-free in sockfs_setattr+0x120/0x150
> Write of size 4 at addr ffff88837b956128 by task syz-executor0/4186
...
> Fixes: 6d8c50dcb029 ("socket: close race condition between sock_close() and sockfs_setattr()")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: general protection fault in tc_ctl_chain
From: Cong Wang @ 2019-02-18 20:02 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs, Vlad Buslov
In-Reply-To: <0000000000006694750581ca4139@google.com>
(Cc'ing Vlad, please fix it)
On Wed, Feb 13, 2019 at 9:56 AM syzbot
<syzbot+eff9cae063e4b633c6c1@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: bd3606c29fcc rocker: Remove port_attr_bridge_flags_get ass..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=121bbf87400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8572a6e4661225f4
> dashboard link: https://syzkaller.appspot.com/bug?extid=eff9cae063e4b633c6c1
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11cbd404c00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fc80d4c00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+eff9cae063e4b633c6c1@syzkaller.appspotmail.com
>
> audit: type=1800 audit(1550028783.638:30): pid=7517 uid=0 auid=4294967295
> ses=4294967295 subj==unconfined op=collect_data cause=failed(directio)
> comm="startpar" name="rmnologin" dev="sda1" ino=2423 res=0
> 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: 7669 Comm: syz-executor789 Not tainted 5.0.0-rc5+ #60
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
> Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
> 85 dc 27 00 00 49 81 3c 24 20 45 9a 89 0f 84 03 f8
> RSP: 0018:ffff88808b44f180 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000060
> RBP: ffff88808b44f350 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff88808b44f570 R11: 0000000000000001 R12: 0000000000000060
> R13: 0000000000000000 R14: 0000000000000000 R15: ffff8880915d4680
> FS: 0000000001ef6880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000080 CR3: 0000000093549000 CR4: 00000000001406f0
> Call Trace:
> lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> __mutex_lock+0xf7/0x1310 kernel/locking/mutex.c:1072
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> tc_ctl_chain+0x42f/0x11a0 net/sched/cls_api.c:2812
> rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
> netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
> rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
> netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
> netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
> netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4400d9
> 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 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffd09281608 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004400d9
> RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401960
> R13: 00000000004019f0 R14: 0000000000000000 R15: 0000000000000000
> Modules linked in:
> ---[ end trace 25ab48d993ef9249 ]---
> RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
> Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
> 85 dc 27 00 00 49 81 3c 24 20 45 9a 89 0f 84 03 f8
> RSP: 0018:ffff88808b44f180 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000060
> RBP: ffff88808b44f350 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff88808b44f570 R11: 0000000000000001 R12: 0000000000000060
> R13: 0000000000000000 R14: 0000000000000000 R15: ffff8880915d4680
> FS: 0000000001ef6880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000080 CR3: 0000000093549000 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.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.
From: David Miller @ 2019-02-18 20:03 UTC (permalink / raw)
To: david0813
Cc: linux-usb, netdev, linux-kernel, hayeswang, mario.limonciello,
bigeasy, edumazet, jslaby, f.fainelli, david.chen7, kai.heng.feng,
zhongjiang
In-Reply-To: <20190218034817.7515-1-david0813@gmail.com>
Where is patch #1?
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: fix spelling mistake: "quiting" -> "quitting"
From: David Miller @ 2019-02-18 20:08 UTC (permalink / raw)
To: colin.king; +Cc: tariqt, netdev, linux-rdma, kernel-janitors, linux-kernel
In-Reply-To: <20190217230331.18678-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sun, 17 Feb 2019 23:03:31 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in a en_err error message. Fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks Colin.
And I agree that this doesn't really deserve a Fixes: tag.
Fixes: tags should really be for changes that introduce truly
functional bugs.
And that could even be applied in this case _iff_ the string
was essential in some way for userland tools which parse the
output or similar. But that is not the case here.
Anyways, thanks.
^ permalink raw reply
* [PATCH] net: netcp: Fix ethss driver probe issue
From: Murali Karicheri @ 2019-02-18 20:10 UTC (permalink / raw)
To: w-kwok2, davem, netdev, linux-kernel
Recent commit below has introduced a bug in netcp driver that causes
the ethss driver probe failure and thus break the networking function
on K2 SoCs such as K2HK, K2L, K2E etc. This patch fixes the issue to
restore networking on the above SoCs.
Fixes: 21c328dcecfc ("net: ethernet: Convert to using %pOFn instead of device_node.name")
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
Failure log: https://pastebin.ubuntu.com/p/cGCFZC4WkC/
With fix: https://pastebin.ubuntu.com/p/G9qYzXXNbw/
drivers/net/ethernet/ti/netcp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 1f612268c998..d847f672a705 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -259,7 +259,7 @@ static int netcp_module_probe(struct netcp_device *netcp_device,
const char *name;
char node_name[32];
- if (of_property_read_string(node, "label", &name) < 0) {
+ if (of_property_read_string(child, "label", &name) < 0) {
snprintf(node_name, sizeof(node_name), "%pOFn", child);
name = node_name;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] net: hamradio: remove unused hweight*() defines
From: David Miller @ 2019-02-18 20:10 UTC (permalink / raw)
To: yamada.masahiro; +Cc: netdev, linux-hams, t.sailer, linux-kernel
In-Reply-To: <1550471725-5575-1-git-send-email-yamada.masahiro@socionext.com>
From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Mon, 18 Feb 2019 15:35:25 +0900
> This file does not use hweight*() at all, and the definition is
> surrounded by #if 0 ... #endif.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum: Change IP2ME CPU policer rate and burst size values
From: David Miller @ 2019-02-18 20:11 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, mlxsw, shalomt
In-Reply-To: <20190218071925.14727-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Mon, 18 Feb 2019 07:19:44 +0000
> From: Shalom Toledo <shalomt@mellanox.com>
>
> The IP2ME packet trap is triggered by packets hitting local routes.
> After evaluating current defaults used by the driver it was decided to
> reduce the amount of traffic generated by this trap to 1Kpps and
> increase the burst size. This is inline with similarly deployed systems.
>
> Signed-off-by: Shalom Toledo <shalomt@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] yellowfin: fix remove set but not used variable warning
From: David Miller @ 2019-02-18 20:13 UTC (permalink / raw)
To: yuehaibing; +Cc: yang.wei9, netdev, kernel-janitors
In-Reply-To: <20190218081546.189509-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 18 Feb 2019 08:15:46 +0000
> @@ -1050,8 +1050,11 @@ static int yellowfin_rx(struct net_device *dev)
> struct sk_buff *rx_skb = yp->rx_skbuff[entry];
> s16 frame_status;
> u16 desc_status;
> - int data_size, yf_size;
> + int data_size;
> u8 *buf_addr;
> +#ifdef YF_PROTOTYPE
> + int yf_size = sizeof(struct yellowfin_desc);
> +#endif
This is just silly.
Please move this variable declaration and initialization into the
YF_PROTOTYPE basic block in the code below it, like this:
#ifdef YF_PROTOTYPE /* Support for prototype hardware errata. */
} else if ((yp->flags & HasMACAddrBug) &&
int yf_size = sizeof(struct yellowfin_desc);
!ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
entry * yf_size),
dev->dev_addr) &&
!ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
entry * yf_size),
"\377\377\377\377\377\377")) {
if (bogus_rx++ == 0)
netdev_warn(dev, "Bad frame to %pM\n",
buf_addr);
#endif
Thanks.
^ permalink raw reply
* Re: [RFC PATCH net-next v3 04/21] ethtool: helper functions for netlink interface
From: Jakub Kicinski @ 2019-02-18 20:15 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, David Miller, Andrew Lunn, Jiri Pirko, linux-kernel
In-Reply-To: <266b4ea3596de134329f8bbd5d13e282d1d27442.1550513384.git.mkubecek@suse.cz>
On Mon, 18 Feb 2019 19:21:44 +0100 (CET), Michal Kubecek wrote:
> +/* create skb for a reply and fill device identification
> + * payload: payload length (without netlink and genetlink header)
> + * dev: device the reply is about (may be null)
> + * cmd: ETHNL_CMD_* command for reply
> + * info: info for the received packet we respond to
> + * ehdrp: place to store payload pointer returned by genlmsg_new()
> + * returns: skb or null on error
> + */
nit: why not correct kdoc?
> +struct sk_buff *ethnl_reply_init(size_t payload, struct net_device *dev, u8 cmd,
> + u16 dev_attrtype, struct genl_info *info,
> + void **ehdrp)
> +{
> + void *ehdr;
> + struct sk_buff *rskb;
nit: reverse xmas tree
^ permalink raw reply
* [PATCH net-next 0/4] net: phy: improve generic clause 45 aneg configuration
From: Heiner Kallweit @ 2019-02-18 20:18 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Improve generic clause 45 aneg configuration.
Heiner Kallweit (4):
net: phy: export genphy_config_eee_advert
net: phy: use genphy_config_eee_advert in genphy_c45_an_config_aneg
net: phy: add genphy_c45_check_and_restart_aneg
net: phy: marvell10g: use genphy_c45_check_and_restart_aneg in
mv3310_config_aneg
drivers/net/phy/marvell10g.c | 15 +--------------
drivers/net/phy/phy-c45.c | 34 +++++++++++++++++++++++++++++++++-
drivers/net/phy/phy_device.c | 3 ++-
include/linux/phy.h | 2 ++
4 files changed, 38 insertions(+), 16 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net-next 1/4] net: phy: export genphy_config_eee_advert
From: Heiner Kallweit @ 2019-02-18 20:26 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <35d86611-9a07-7239-3310-767d8d1050b5@gmail.com>
We want to use this function in phy-c45.c too, therefore export it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 3 ++-
include/linux/phy.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 4bb3b6c28..49fdd1ee7 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1575,7 +1575,7 @@ static int genphy_config_advert(struct phy_device *phydev)
* efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
* changed, and 1 if it has changed.
*/
-static int genphy_config_eee_advert(struct phy_device *phydev)
+int genphy_config_eee_advert(struct phy_device *phydev)
{
int err;
@@ -1588,6 +1588,7 @@ static int genphy_config_eee_advert(struct phy_device *phydev)
/* If the call failed, we assume that EEE is not supported */
return err < 0 ? 0 : err;
}
+EXPORT_SYMBOL(genphy_config_eee_advert);
/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3db507e68..761131de4 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1077,6 +1077,7 @@ void phy_attached_info(struct phy_device *phydev);
int genphy_config_init(struct phy_device *phydev);
int genphy_setup_forced(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
+int genphy_config_eee_advert(struct phy_device *phydev);
int genphy_config_aneg(struct phy_device *phydev);
int genphy_aneg_done(struct phy_device *phydev);
int genphy_update_link(struct phy_device *phydev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/4] net: phy: use genphy_config_eee_advert in genphy_c45_an_config_aneg
From: Heiner Kallweit @ 2019-02-18 20:27 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <35d86611-9a07-7239-3310-767d8d1050b5@gmail.com>
Like in genphy_config_aneg() for clause 22 PHY's, we should keep modes
from being advertised that are known to be broken with EEE.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 16636d49b..2f5721430 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -89,12 +89,14 @@ EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
*/
int genphy_c45_an_config_aneg(struct phy_device *phydev)
{
- int changed = 0, ret;
+ int changed, ret;
u32 adv;
linkmode_and(phydev->advertising, phydev->advertising,
phydev->supported);
+ changed = genphy_config_eee_advert(phydev);
+
adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
--
2.20.1
^ permalink raw reply related
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