* Re: [PATCH] ptp: drop redundant kasprintf() to create worker name
From: David Miller @ 2018-10-29 2:20 UTC (permalink / raw)
To: linux; +Cc: richardcochran, keescook, netdev, linux-kernel
In-Reply-To: <20181026212300.5827-1-linux@rasmusvillemoes.dk>
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Fri, 26 Oct 2018 23:22:59 +0200
> Building with -Wformat-nonliteral, gcc complains
>
> drivers/ptp/ptp_clock.c: In function ‘ptp_clock_register’:
> drivers/ptp/ptp_clock.c:239:26: warning: format not a string literal and no format arguments [-Wformat-nonliteral]
> worker_name : info->name);
>
> kthread_create_worker takes fmt+varargs to set the name of the
> worker, and that happens with a vsnprintf() to a stack buffer (that is
> then copied into task_comm). So there's no reason not to just pass
> "ptp%d", ptp->index to kthread_create_worker() and avoid the
> intermediate worker_name variable.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: David Miller @ 2018-10-29 2:18 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, bridge, yinxu, liuhangbin
In-Reply-To: <20181027090747.22104-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Sat, 27 Oct 2018 12:07:47 +0300
> Recently a check was added which prevents marking of routers with zero
> source address, but for IPv6 that cannot happen as the relevant RFCs
> actually forbid such packets:
> RFC 2710 (MLDv1):
> "To be valid, the Query message MUST
> come from a link-local IPv6 Source Address, be at least 24 octets
> long, and have a correct MLD checksum."
>
> Same goes for RFC 3810.
>
> And also it can be seen as a requirement in ipv6_mc_check_mld_query()
> which is used by the bridge to validate the message before processing
> it. Thus any queries with :: source address won't be processed anyway.
> So just remove the check for zero IPv6 source address from the query
> processing function.
>
> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied.
^ permalink raw reply
* Re: bnx2: rx_fw_discards: BCM5716 sporadically drops packets when update to driver version 2.2.6
From: maowenan @ 2018-10-29 2:15 UTC (permalink / raw)
To: rasesh.mody, netdev, f.fainelli, andrew, linux-kernel
In-Reply-To: <1a94796f-1760-f332-46f0-6ab0b5a0aab7@huawei.com>
Could anyone give some clues to address count of rx_fw_discards increasing issue?
On 2018/10/26 11:15, maowenan wrote:
> Hi，
>
> After I update version of bnx2 driver from 2.2.1 to 2.2.6, I find BCM5716 sporadically drops packets, which
> shows in rx_fw_discards.
> C36-141-5:~ # ethtool -S NIC0
>
> NIC statistics:
> rx_ucast_packets: 11902
>
> rx_mcast_packets: 217
>
> rx_bcast_packets: 4954320
>
> rx_filtered_packets: 328793
>
> rx_fw_discards: 2742
>
> C36-141-5:~ #
>
> 5s later:
>
> C36-141-5:~ # ethtool -S NIC0
>
> NIC statistics:
> rx_ucast_packets: 11910
>
> rx_mcast_packets: 217
>
> rx_bcast_packets: 4958117
>
> rx_filtered_packets: 328897
>
> rx_fw_discards: 2750
>
> C36-141-5:~ #
>
> so rx_fw_discards: 2742-----> rx_fw_discards: 2750, lost 8 packets.
>
> the information of bnx2
> C36-141-5:~ # modinfo bnx2
> kernel/drivers/net/ethernet/broadcom/bnx2.ko
>
> firmware: bnx2/bnx2-rv2p-09ax-6.0.17.fw
>
> firmware: bnx2/bnx2-rv2p-09-6.0.17.fw
>
> firmware: bnx2/bnx2-mips-09-6.2.1b.fw
>
> firmware: bnx2/bnx2-rv2p-06-6.0.15.fw
>
> firmware: bnx2/bnx2-mips-06-6.2.3.fw
> version: 2.2.6
>
>
> 1) Firstly, I check the patches from 2.2.1 to 2.2.6, below patch is interesting.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0021850d0417a4dc38ed871d929b651b87e2ead9
> Do not enable filter SORT MODE in chip init routine. This patch addresses an
> issue where BCM5716 sporadically drops packets when changing multicast list.
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
> index 8957eb5f4478..8c9a8b7787d2 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.c
> +++ b/drivers/net/ethernet/broadcom/bnx2.c
> @@ -4984,8 +4984,6 @@ bnx2_init_chip(struct bnx2 *bp)
>
> bp->idle_chk_status_idx = 0xffff;
>
> - bp->rx_mode = BNX2_EMAC_RX_MODE_SORT_MODE;
> -
> /* Set up how to generate a link change interrupt. */
> BNX2_WR(bp, BNX2_EMAC_ATTENTION_ENA, BNX2_EMAC_ATTENTION_ENA_LINK);
>
>
> 2) Secondly, I revert this patch, after verify it, I find rx_fw_discards does not increasing.
> so I think this patch can fix current issue. But I'm not sure the issue of this patch to fix
> will be reproduced?
> I'm not convinced that what factor will trigger rx_fw_discards increasing?
> And how to fix this?
>
> Thanks a lot.
>
>
>
>
>
>
>
>
>
>
>
>
>
> .
>
^ permalink raw reply
* [GIT PULL] 9p updates for 4.20
From: Dominique Martinet @ 2018-10-29 1:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: v9fs-developer, linux-kernel, netdev
Hi Linus,
Here is a 9p update for 4.20.
Highlights this time around are the end of Matthew's work to remove the
custom 9p request cache and use a slab directly for requests, with some
extra patches on my end to not degrade performance, but it's a very good
cleanup.
Tomas and I fixed a few more syzkaller bugs (refcount is the big one),
and I had a go at the coverity bugs and at some of the bugzilla reports
we had open for a while.
I'm a bit disappointed that I couldn't get much reviews for a few of my
own patches, but the big ones got some and it's all been soaking in
linux-next for quite a while so I think it should be OK.
Lastly, as said last time, I'm going to be confusing again as I changed
my PGP key - it's signed by the old one - but should keep this one for
the forseeable future now.
Thanks!
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git://github.com/martinetd/linux tags/9p-for-4.20
for you to fetch changes up to fb488fc1f2b4c5128540b032892ddec91edaf8d9:
9p/trans_fd: put worker reqs on destroy (2018-10-10 09:14:34 +0900)
----------------------------------------------------------------
Dan Carpenter (1):
9p: potential NULL dereference
Dinu-Razvan Chis-Serban (1):
9p locks: add mount option for lock retry interval
Dominique Martinet (12):
9p/xen: fix check for xenbus_read error in front_probe
v9fs_dir_readdir: fix double-free on p9stat_read error
9p: clear dangling pointers in p9stat_free
9p: embed fcall in req to round down buffer allocs
9p: add a per-client fcall kmem_cache
9p/rdma: do not disconnect on down_interruptible EAGAIN
9p: acl: fix uninitialized iattr access
9p/rdma: remove useless check in cm_event_handler
9p: p9dirent_read: check network-provided name length
9p locks: fix glock.client_id leak in do_lock
9p/trans_fd: abort p9_read_work if req status changed
9p/trans_fd: put worker reqs on destroy
Gertjan Halkes (1):
9p: do not trust pdu content for stat item size
Gustavo A. R. Silva (1):
9p: fix spelling mistake in fall-through annotation
Matthew Wilcox (2):
9p: Use a slab for allocating requests
9p: Remove p9_idpool
Tomas Bortoli (3):
9p: rename p9_free_req() function
9p: Add refcount to p9_req_t
9p: Rename req to rreq in trans_fd
fs/9p/acl.c | 2 +-
fs/9p/v9fs.c | 21 +++++
fs/9p/v9fs.h | 1 +
fs/9p/vfs_dir.c | 19 +---
fs/9p/vfs_file.c | 24 +++++-
include/net/9p/9p.h | 12 +--
include/net/9p/client.h | 71 ++++++---------
net/9p/Makefile | 1 -
net/9p/client.c | 551 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------
net/9p/mod.c | 9 +-
net/9p/protocol.c | 20 ++++-
net/9p/trans_fd.c | 64 +++++++++-----
net/9p/trans_rdma.c | 37 ++++----
net/9p/trans_virtio.c | 44 +++++++---
net/9p/trans_xen.c | 17 ++--
net/9p/util.c | 140 ------------------------------
16 files changed, 482 insertions(+), 551 deletions(-)
delete mode 100644 net/9p/util.c
^ permalink raw reply
* Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: Nikolay Aleksandrov @ 2018-10-28 16:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, roopa, bridge, yinxu, liuhangbin, davem
In-Reply-To: <20181028082023.222fac71@xeon-e3>
On 28/10/2018 17:20, Stephen Hemminger wrote:
> On Sat, 27 Oct 2018 12:07:47 +0300
> Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
>
>> Recently a check was added which prevents marking of routers with zero
>> source address, but for IPv6 that cannot happen as the relevant RFCs
>> actually forbid such packets:
>> RFC 2710 (MLDv1):
>> "To be valid, the Query message MUST
>> come from a link-local IPv6 Source Address, be at least 24 octets
>> long, and have a correct MLD checksum."
>>
>> Same goes for RFC 3810.
>>
>> And also it can be seen as a requirement in ipv6_mc_check_mld_query()
>> which is used by the bridge to validate the message before processing
>> it. Thus any queries with :: source address won't be processed anyway.
>> So just remove the check for zero IPv6 source address from the query
>> processing function.
>>
>> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>
> What about a broken/malicious sender? Could an all zero source be used
> to poison the multicast table?
>
No, this has nothing to do with the table. This is about marking routers
and we shouldn't consider queries with src 0.0.0.0 (the original fix)
but for IPv6 such query is invalid and in fact doesn't reach that code at all.
As I've written in the commit message, ipv6_mc_check_mld_query() already checks
for that and marks it as invalid thus it isn't processed and we can drop that
check from the bridge mcast code, if you test with such src you can see in
the bridge mcast statistics that the MLD errors are going up showing that these
packets are treated as errors.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH] ptp: drop redundant kasprintf() to create worker name
From: Kees Cook @ 2018-10-28 16:05 UTC (permalink / raw)
To: Rasmus Villemoes; +Cc: Richard Cochran, Network Development, LKML
In-Reply-To: <20181026212300.5827-1-linux@rasmusvillemoes.dk>
On Fri, Oct 26, 2018 at 10:22 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> Building with -Wformat-nonliteral, gcc complains
>
> drivers/ptp/ptp_clock.c: In function ‘ptp_clock_register’:
> drivers/ptp/ptp_clock.c:239:26: warning: format not a string literal and no format arguments [-Wformat-nonliteral]
> worker_name : info->name);
>
> kthread_create_worker takes fmt+varargs to set the name of the
> worker, and that happens with a vsnprintf() to a stack buffer (that is
> then copied into task_comm). So there's no reason not to just pass
> "ptp%d", ptp->index to kthread_create_worker() and avoid the
> intermediate worker_name variable.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/ptp/ptp_clock.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
> index 7eacc1c4b3b1..5419a89d300e 100644
> --- a/drivers/ptp/ptp_clock.c
> +++ b/drivers/ptp/ptp_clock.c
> @@ -232,12 +232,8 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
> init_waitqueue_head(&ptp->tsev_wq);
>
> if (ptp->info->do_aux_work) {
> - char *worker_name = kasprintf(GFP_KERNEL, "ptp%d", ptp->index);
> -
> kthread_init_delayed_work(&ptp->aux_work, ptp_aux_kworker);
> - ptp->kworker = kthread_create_worker(0, worker_name ?
> - worker_name : info->name);
> - kfree(worker_name);
> + ptp->kworker = kthread_create_worker(0, "ptp%d", ptp->index);
> if (IS_ERR(ptp->kworker)) {
> err = PTR_ERR(ptp->kworker);
> pr_err("failed to create ptp aux_worker %d\n", err);
> --
> 2.19.1.6.gbde171bbf5
>
--
Kees Cook
^ permalink raw reply
* Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: Stephen Hemminger @ 2018-10-28 15:20 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, bridge, yinxu, liuhangbin, davem
In-Reply-To: <20181027090747.22104-1-nikolay@cumulusnetworks.com>
On Sat, 27 Oct 2018 12:07:47 +0300
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> Recently a check was added which prevents marking of routers with zero
> source address, but for IPv6 that cannot happen as the relevant RFCs
> actually forbid such packets:
> RFC 2710 (MLDv1):
> "To be valid, the Query message MUST
> come from a link-local IPv6 Source Address, be at least 24 octets
> long, and have a correct MLD checksum."
>
> Same goes for RFC 3810.
>
> And also it can be seen as a requirement in ipv6_mc_check_mld_query()
> which is used by the bridge to validate the message before processing
> it. Thus any queries with :: source address won't be processed anyway.
> So just remove the check for zero IPv6 source address from the query
> processing function.
>
> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
What about a broken/malicious sender? Could an all zero source be used
to poison the multicast table?
^ permalink raw reply
* Re: CAKE and r8169 cause panic on upload in v4.19
From: Oleksandr Natalenko @ 2018-10-28 12:22 UTC (permalink / raw)
To: David Miller
Cc: dave.taht, hkallweit1, toke, jhs, xiyou.wangcong, jiri, netdev,
linux-kernel
In-Reply-To: <20181027.214426.537959459795607171.davem@davemloft.net>
Hi.
On 28.10.2018 05:44, David Miller wrote:
> Does this fix it?
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 022ad73d6253..77d43ae2a7bb 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5457,7 +5457,7 @@ static void gro_flush_oldest(struct list_head
> *head)
> /* Do not adjust napi->gro_hash[].count, caller is adding a new
> * SKB to the chain.
> */
> - list_del(&oldest->list);
> + skb_list_del_init(oldest);
> napi_gro_complete(oldest);
> }
Yes, but I had to apply both a8305bff6852 and 992cba7e276d too to get it
compiled. With these 3 patches the panic is not triggered any more while
having GRO enabled.
Thanks!
--
Oleksandr Natalenko (post-factum)
^ permalink raw reply
* [PATCH v2] bonding: fix length of actor system
From: Tobias Jungel @ 2018-10-28 11:54 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Veaceslav Falico, Andy Gospodarek, Eric Dumazet, netdev
In-Reply-To: <386.1540680344@nyx>
The attribute IFLA_BOND_AD_ACTOR_SYSTEM is sent to user space having the
length of sizeof(bond->params.ad_actor_system) which is 8 byte. This
patch aligns the length to ETH_ALEN to have the same MAC address exposed
as using sysfs.
Fixes: f87fda00b6ed2 ("bonding: prevent out of bound accesses")
Signed-off-by: Tobias Jungel <tobias.jungel@gmail.com>
---
Changes in v2:
- correct Fixes line
drivers/net/bonding/bond_netlink.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
index 9697977b80f0..6b9ad8673218 100644
--- a/drivers/net/bonding/bond_netlink.c
+++ b/drivers/net/bonding/bond_netlink.c
@@ -638,8 +638,7 @@ static int bond_fill_info(struct sk_buff *skb,
goto nla_put_failure;
if (nla_put(skb, IFLA_BOND_AD_ACTOR_SYSTEM,
- sizeof(bond->params.ad_actor_system),
- &bond->params.ad_actor_system))
+ ETH_ALEN, &bond->params.ad_actor_system))
goto nla_put_failure;
}
if (!bond_3ad_get_active_agg_info(bond, &info)) {
^ permalink raw reply related
* Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect tc block binds
From: Or Gerlitz @ 2018-10-28 11:10 UTC (permalink / raw)
To: John Hurley
Cc: Linux Netdev List, oss-drivers, Jiri Pirko, Oz Shlomo,
Jakub Kicinski, Simon Horman, Aviv Heller
In-Reply-To: <1540470417-14803-2-git-send-email-john.hurley@netronome.com>
On Thu, Oct 25, 2018 at 3:28 PM John Hurley <john.hurley@netronome.com> wrote:
> Currently drivers can register to receive TC block bind/unbind callbacks
> by implementing the setup_tc ndo in any of their given netdevs. However,
> drivers may also be interested in binds to higher level devices (e.g.
> tunnel drivers) to potentially offload filters applied to them.
> Introduce indirect block devs which allows drivers to register callbacks
> for block binds on other devices. The calling driver is expected to
> reference an 'owner' struct that it will pass to all block registrations.
> This is used to track the callbacks from a given driver and free them if
> the driver is removed while the upper level device is still active.
Hi John,
Maybe it would be better to follow the trusted environment model of the kernel
and not protect the core from driver bugs? If the driver does things right they
will unregister before bailing out and if not, they will have to fix..
> Freeing a callback will also trigger an unbind event (if necessary) to
> direct the driver to remove any offloaded rules and unreg any block filter
> callbacks.
> Allow registering an indirect block dev callback for a device that is
> already bound to a block. In this case (if it is an ingress block),
> register and also trigger the callback meaning that any already installed
> rules can be replayed to the calling driver.
not just can be replayed.. they will be replayed, but through an
existing (tc re-offload?)
facility, correct?
Or.
^ permalink raw reply
* Re: iproute2: fix build on glibc < 2.21 / uClibc
From: Petr Vorel @ 2018-10-28 10:16 UTC (permalink / raw)
To: netdev
Subject: [iproute] utils.h: provide fallback CLOCK_TAI definition
In-Reply-To: <20181027153102.32302-1-peter@korsgaard.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: netdev@vger.kernel.org, Peter Korsgaard <peter@korsgaard.com>
From: Petr Vorel <petr.vorel@gmail.com>
List-Id: <netdev.vger.kernel.org>
> q_{etf,taprio}.c uses CLOCK_TAI, which isn't exposed by glibc < 2.21 or
> uClibc, breaking the build. Provide a fallback definition like it is done
> for IPPROTO_MPLS and others.
>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
> ---
> include/utils.h | 4 ++++
> 1 file changed, 4 insertions(+)
Kind regards,
Petr
^ permalink raw reply
* Re: WARNING in __debug_object_init (3)
From: Eric Dumazet @ 2018-10-28 17:44 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, Eric Dumazet
Cc: Alexei Starovoitov, Daniel Borkmann, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <CACT4Y+bxF2gZpdp5JuWSWwyqX=ZumOmei-pOpnGFjALDeaqmQQ@mail.gmail.com>
On 10/28/2018 08:13 AM, Dmitry Vyukov wrote:
> On Sun, Oct 28, 2018 at 3:18 AM, syzbot
> <syzbot+6e682caa546b7c96c859@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 8c60c36d0b8c Add linux-next specific files for 20181019
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=100feec5400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=8b6d7c4c81535e89
>> dashboard link: https://syzkaller.appspot.com/bug?extid=6e682caa546b7c96c859
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13579abd400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13654f6b400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+6e682caa546b7c96c859@syzkaller.appspotmail.com
>
> +Eric knows what's wrong here. Something about "bpf: add tests for
> direct packet access from CGROUP_SKB" commit. Was is amended to fix a
> bug?
>
I know little.
It seems that this linux-next tree contains a (buggy) pre-version of
this commit :
commit 2cb494a36c98279c5c6ce8e99cf9776f15449ade
Author: Song Liu <songliubraving@fb.com>
Date: Fri Oct 19 09:57:58 2018 -0700
bpf: add tests for direct packet access from CGROUP_SKB
Tests are added to make sure CGROUP_SKB cannot access:
tc_classid, data_meta, flow_keys
and can read and write:
mark, prority, and cb[0-4]
and can read other fields.
To make selftest with skb->sk work, a dummy sk is added in
bpf_prog_test_run_skb().
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Maybe bpf maintainers chose to pre-submit a buggy patch and rebased their tree.
The buggy patch in linux-next was :
commit 75079847e9d05d4cc1b7e09b29e22cbc8318a6b7
Author: Song Liu <songliubraving@fb.com>
Date: Thu Oct 18 09:06:49 2018 -0700
bpf: add tests for direct packet access from CGROUP_SKB
Tests are added to make sure CGROUP_SKB cannot access:
tc_classid, data_meta, flow_keys
and can read and write:
mark, prority, and cb[0-4]
and can read other fields.
To make selftest with skb->sk work, a dummy sk is added in
bpf_prog_test_run_skb().
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>
>> ODEBUG: object 0000000015e9012c is on stack 00000000115bcb67, but NOT
>> annotated.
>> WARNING: CPU: 0 PID: 5594 at lib/debugobjects.c:369 debug_object_is_on_stack
>> lib/debugobjects.c:363 [inline]
>> WARNING: CPU: 0 PID: 5594 at lib/debugobjects.c:369
>> __debug_object_init.cold.14+0x51/0xdf lib/debugobjects.c:395
>> Kernel panic - not syncing: panic_on_warn set ...
>> CPU: 0 PID: 5594 Comm: syz-executor740 Not tainted 4.19.0-rc8-next-20181019+
>> #98
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0x244/0x39d lib/dump_stack.c:113
>> panic+0x2ad/0x55c kernel/panic.c:188
>> __warn.cold.8+0x20/0x45 kernel/panic.c:540
>> report_bug+0x254/0x2d0 lib/bug.c:186
>> fixup_bug arch/x86/kernel/traps.c:178 [inline]
>> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
>> do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
>> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
>> RIP: 0010:debug_object_is_on_stack lib/debugobjects.c:363 [inline]
>> RIP: 0010:__debug_object_init.cold.14+0x51/0xdf lib/debugobjects.c:395
>> Code: ea 03 80 3c 02 00 75 7c 49 8b 54 24 18 48 89 de 48 c7 c7 c0 f1 40 88
>> 4c 89 85 d0 fd ff ff e8 09 8c d1 fd 4c 8b 85 d0 fd ff ff <0f> 0b e9 09 d6 ff
>> ff 41 83 c4 01 b8 ff ff 37 00 44 89 25 b7 4e 66
>> RSP: 0018:ffff8801bb387308 EFLAGS: 00010086
>> RAX: 0000000000000050 RBX: ffff8801bb387af8 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: ffffffff816585a5 RDI: 0000000000000005
>> RBP: ffff8801bb387560 R08: ffff8801cb208a20 R09: ffffed003b5c5008
>> R10: ffffed003b5c5008 R11: ffff8801dae28047 R12: ffff8801d82ea300
>> R13: 0000000000069700 R14: ffff8801d82ea300 R15: ffff8801cb208a10
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_timer_init kernel/time/timer.c:704 [inline]
>> debug_init kernel/time/timer.c:757 [inline]
>> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
>> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
>> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
>> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
>> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
>> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
>> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x440259
>> 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:00007ffc212cf818 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
>> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
>> RDX: 0000000000000028 RSI: 0000000020000080 RDI: 000000000000000a
>> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
>> R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401ae0
>> R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
>>
>> ======================================================
>> WARNING: possible circular locking dependency detected
>> 4.19.0-rc8-next-20181019+ #98 Not tainted
>> ------------------------------------------------------
>> syz-executor740/5594 is trying to acquire lock:
>> 00000000688fcc6b ((console_sem).lock){-.-.}, at: down_trylock+0x13/0x70
>> kernel/locking/semaphore.c:136
>>
>> but task is already holding lock:
>> 00000000505ead1b (&obj_hash[i].lock){-.-.}, at:
>> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #3 (&obj_hash[i].lock){-.-.}:
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_hrtimer_init kernel/time/hrtimer.c:410 [inline]
>> debug_init kernel/time/hrtimer.c:458 [inline]
>> hrtimer_init+0x97/0x490 kernel/time/hrtimer.c:1308
>> init_dl_task_timer+0x1b/0x50 kernel/sched/deadline.c:1057
>> __sched_fork+0x2ae/0x590 kernel/sched/core.c:2166
>> init_idle+0x75/0x740 kernel/sched/core.c:5382
>> sched_init+0xb33/0xc02 kernel/sched/core.c:6065
>> start_kernel+0x4be/0xa2b init/main.c:608
>> x86_64_start_reservations+0x2e/0x30 arch/x86/kernel/head64.c:472
>> x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:451
>> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
>>
>> -> #2 (&rq->lock){-.-.}:
>> __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
>> _raw_spin_lock+0x2d/0x40 kernel/locking/spinlock.c:144
>> rq_lock kernel/sched/sched.h:1127 [inline]
>> task_fork_fair+0xb0/0x6d0 kernel/sched/fair.c:9768
>> sched_fork+0x443/0xba0 kernel/sched/core.c:2359
>> copy_process+0x2585/0x8770 kernel/fork.c:1887
>> _do_fork+0x1cb/0x11c0 kernel/fork.c:2216
>> kernel_thread+0x34/0x40 kernel/fork.c:2275
>> rest_init+0x28/0x372 init/main.c:409
>> arch_call_rest_init+0xe/0x1b
>> start_kernel+0x9f0/0xa2b init/main.c:745
>> x86_64_start_reservations+0x2e/0x30 arch/x86/kernel/head64.c:472
>> x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:451
>> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
>>
>> -> #1 (&p->pi_lock){-.-.}:
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> try_to_wake_up+0xd2/0x12e0 kernel/sched/core.c:1965
>> wake_up_process+0x10/0x20 kernel/sched/core.c:2129
>> __up.isra.1+0x1c0/0x2a0 kernel/locking/semaphore.c:262
>> up+0x13c/0x1c0 kernel/locking/semaphore.c:187
>> __up_console_sem+0xbe/0x1b0 kernel/printk/printk.c:236
>> console_unlock+0x80c/0x1190 kernel/printk/printk.c:2432
>> vprintk_emit+0x391/0x990 kernel/printk/printk.c:1922
>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
>> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
>> printk+0xa7/0xcf kernel/printk/printk.c:1997
>> check_stack_usage kernel/exit.c:755 [inline]
>> do_exit.cold.18+0x57/0x16f kernel/exit.c:916
>> do_group_exit+0x177/0x440 kernel/exit.c:970
>> __do_sys_exit_group kernel/exit.c:981 [inline]
>> __se_sys_exit_group kernel/exit.c:979 [inline]
>> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:979
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> -> #0 ((console_sem).lock){-.-.}:
>> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
>> __down_trylock_console_sem+0xae/0x1f0 kernel/printk/printk.c:219
>> console_trylock+0x15/0xa0 kernel/printk/printk.c:2247
>> console_trylock_spinning kernel/printk/printk.c:1653 [inline]
>> vprintk_emit+0x372/0x990 kernel/printk/printk.c:1921
>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
>> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
>> printk+0xa7/0xcf kernel/printk/printk.c:1997
>> debug_object_is_on_stack lib/debugobjects.c:363 [inline]
>> __debug_object_init.cold.14+0x4a/0xdf lib/debugobjects.c:395
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_timer_init kernel/time/timer.c:704 [inline]
>> debug_init kernel/time/timer.c:757 [inline]
>> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
>> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
>> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
>> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
>> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
>> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
>> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> other info that might help us debug this:
>>
>> Chain exists of:
>> (console_sem).lock --> &rq->lock --> &obj_hash[i].lock
>>
>> Possible unsafe locking scenario:
>>
>> CPU0 CPU1
>> ---- ----
>> lock(&obj_hash[i].lock);
>> lock(&rq->lock);
>> lock(&obj_hash[i].lock);
>> lock((console_sem).lock);
>>
>> *** DEADLOCK ***
>>
>> 1 lock held by syz-executor740/5594:
>> #0: 00000000505ead1b (&obj_hash[i].lock){-.-.}, at:
>> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>>
>> stack backtrace:
>> CPU: 0 PID: 5594 Comm: syz-executor740 Not tainted 4.19.0-rc8-next-20181019+
>> #98
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0x244/0x39d lib/dump_stack.c:113
>> print_circular_bug.isra.35.cold.54+0x1bd/0x27d
>> kernel/locking/lockdep.c:1221
>> check_prev_add kernel/locking/lockdep.c:1863 [inline]
>> check_prevs_add kernel/locking/lockdep.c:1976 [inline]
>> validate_chain kernel/locking/lockdep.c:2347 [inline]
>> __lock_acquire+0x3399/0x4c20 kernel/locking/lockdep.c:3341
>> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
>> __down_trylock_console_sem+0xae/0x1f0 kernel/printk/printk.c:219
>> console_trylock+0x15/0xa0 kernel/printk/printk.c:2247
>> console_trylock_spinning kernel/printk/printk.c:1653 [inline]
>> vprintk_emit+0x372/0x990 kernel/printk/printk.c:1921
>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
>> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
>> printk+0xa7/0xcf kernel/printk/printk.c:1997
>> debug_object_is_on_stack lib/debugobjects.c:363 [inline]
>> __debug_object_init.cold.14+0x4a/0xdf lib/debugobjects.c:395
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_timer_init kernel/time/timer.c:704 [inline]
>> debug_init kernel/time/timer.c:757 [inline]
>> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
>> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
>> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
>> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
>> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
>> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
>> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x440259
>> 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:00007ffc212cf818 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
>> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
>> RDX: 0000000000000028 RSI: 0000000020000080 RDI: 000000000000000a
>> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
>> R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401ae0
>> R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> 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
>>
>> --
>> 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/0000000000008db3210579416691%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2] sctp: socket.c validate sprstat_policy
From: Tomas Bortoli @ 2018-10-28 8:42 UTC (permalink / raw)
To: Xin Long
Cc: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, davem,
linux-sctp, network dev, LKML
In-Reply-To: <CADvbK_dHDq69jtLHh4p9xeonhcLAjSytTZMZ0vN3QzcukP2ajg@mail.gmail.com>
On 10/28/18 5:17 AM, Xin Long wrote:
> On Sun, Oct 28, 2018 at 5:54 AM Tomas Bortoli <tomasbortoli@gmail.com> wrote:
>>
>> It is possible to perform out-of-bound reads on
>> sctp_getsockopt_pr_streamstatus() and on
>> sctp_getsockopt_pr_assocstatus() by passing from userspace a
>> sprstat_policy that overflows the abandoned_sent/abandoned_unsent
>> fixed length arrays. The over-read data are directly copied/leaked
>> to userspace.
>>
>> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
>> Reported-by: syzbot+5da0d0a72a9e7d791748@syzkaller.appspotmail.com
>> ---
>> net/sctp/socket.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index fc0386e8ff23..14dce5d95817 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -7083,7 +7083,9 @@ static int sctp_getsockopt_pr_assocstatus(struct sock *sk, int len,
>> }
>>
>> policy = params.sprstat_policy;
>> - if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)))
>> + if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)) ||
>> + __SCTP_PR_INDEX(policy) > SCTP_PR_INDEX(MAX) ||
>> + __SCTP_PR_INDEX(policy) < 0)
>> goto out;
>>
>> asoc = sctp_id2assoc(sk, params.sprstat_assoc_id);
>> @@ -7142,7 +7144,9 @@ static int sctp_getsockopt_pr_streamstatus(struct sock *sk, int len,
>> }
>>
>> policy = params.sprstat_policy;
>> - if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)))
>> + if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)) ||
>> + __SCTP_PR_INDEX(policy) > SCTP_PR_INDEX(MAX) ||
>> + __SCTP_PR_INDEX(policy) < 0)
>> goto out;
> This is not the correct fix.
> See https://lkml.org/lkml/2018/10/27/136
>
Ack, good to know ty!
^ permalink raw reply
* [PATCH net 2/2] macsec: let the administrator set UP state even if lowerdev is down
From: Sabrina Dubroca @ 2018-10-28 8:33 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Radu Rendec, Patrick Talbert
In-Reply-To: <cover.1540714256.git.sd@queasysnail.net>
Currently, the kernel doesn't let the administrator set a macsec device
up unless its lower device is currently up. This is inconsistent, as a
macsec device that is up won't automatically go down when its lower
device goes down.
Now that linkstate propagation works, there's really no reason for this
limitation, so let's remove it.
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Reported-by: Radu Rendec <radu.rendec@gmail.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
drivers/net/macsec.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 6195b8edafc0..64a982563d59 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -2812,9 +2812,6 @@ static int macsec_dev_open(struct net_device *dev)
struct net_device *real_dev = macsec->real_dev;
int err;
- if (!(real_dev->flags & IFF_UP))
- return -ENETDOWN;
-
err = dev_uc_add(real_dev, dev->dev_addr);
if (err < 0)
return err;
--
2.19.1
^ permalink raw reply related
* [PATCH net 1/2] macsec: update operstate when lower device changes
From: Sabrina Dubroca @ 2018-10-28 8:33 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Radu Rendec, Patrick Talbert
In-Reply-To: <cover.1540714256.git.sd@queasysnail.net>
Like all other virtual devices (macvlan, vlan), the operstate of a
macsec device should match the state of its lower device. This is done
by calling netif_stacked_transfer_operstate from its netdevice notifier.
We also need to call netif_stacked_transfer_operstate when a new macsec
device is created, so that its operstate is set properly. This is only
relevant when we try to bring the device up directly when we create it.
Radu Rendec proposed a similar patch, inspired from the 802.1q driver,
that included changing the administrative state of the macsec device,
instead of just the operstate. This version is similar to what the
macvlan driver does, and updates only the operstate.
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Reported-by: Radu Rendec <radu.rendec@gmail.com>
Reported-by: Patrick Talbert <ptalbert@redhat.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
drivers/net/macsec.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 4bb90b6867a2..6195b8edafc0 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -3306,6 +3306,9 @@ static int macsec_newlink(struct net *net, struct net_device *dev,
if (err < 0)
goto del_dev;
+ netif_stacked_transfer_operstate(real_dev, dev);
+ linkwatch_fire_event(dev);
+
macsec_generation++;
return 0;
@@ -3490,6 +3493,20 @@ static int macsec_notify(struct notifier_block *this, unsigned long event,
return NOTIFY_DONE;
switch (event) {
+ case NETDEV_DOWN:
+ case NETDEV_UP:
+ case NETDEV_CHANGE: {
+ struct macsec_dev *m, *n;
+ struct macsec_rxh_data *rxd;
+
+ rxd = macsec_data_rtnl(real_dev);
+ list_for_each_entry_safe(m, n, &rxd->secys, secys) {
+ struct net_device *dev = m->secy.netdev;
+
+ netif_stacked_transfer_operstate(real_dev, dev);
+ }
+ break;
+ }
case NETDEV_UNREGISTER: {
struct macsec_dev *m, *n;
struct macsec_rxh_data *rxd;
--
2.19.1
^ permalink raw reply related
* [PATCH net 0/2] macsec: linkstate fixes
From: Sabrina Dubroca @ 2018-10-28 8:33 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Radu Rendec, Patrick Talbert
This series fixes issues with handling administrative and operstate of
macsec devices.
Radu Rendec proposed another version of the first patch [0] but I'd
rather not follow the behavior of vlan devices, going with macvlan
does instead. Patrick Talbert also reported the same issue to me.
The second patch is a follow-up. The restriction on setting the device
up is a bit unreasonable, and operstate provides the information we
need in this case.
[0] https://patchwork.ozlabs.org/patch/971374/
Sabrina Dubroca (2):
macsec: update operstate when lower device changes
macsec: let the administrator set UP state even if lowerdev is down
drivers/net/macsec.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
--
2.19.1
^ permalink raw reply
* Re: [Patch V3 net 05/11] net: hns3: remove unnecessary queue reset in the hns3_uninit_all_ring()
From: Sergei Shtylyov @ 2018-10-28 8:09 UTC (permalink / raw)
To: Huazhong Tan, davem
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-6-git-send-email-tanhuazhong@huawei.com>
Hello!
On 28.10.2018 6:34, Huazhong Tan wrote:
> It is not necessary to reset the queue in the hns3_uninit_all_ring(),
> since the queue is stopped in the down operation, and will be reset
> in the up operaton. And the judgment of the HCLGE_STATE_RST_HANDLING
Operation.
> flag in the hclge_reset_tqp() is not correct, because we need to reset
> tqp during pf reset, otherwise it may cause queue not be reset to
Not being reset?
> working state problem.
>
> Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: WARNING in __debug_object_init (3)
From: Dmitry Vyukov @ 2018-10-28 15:13 UTC (permalink / raw)
To: syzbot, Eric Dumazet
Cc: Alexei Starovoitov, Daniel Borkmann, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <0000000000008db3210579416691@google.com>
On Sun, Oct 28, 2018 at 3:18 AM, syzbot
<syzbot+6e682caa546b7c96c859@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 8c60c36d0b8c Add linux-next specific files for 20181019
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=100feec5400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8b6d7c4c81535e89
> dashboard link: https://syzkaller.appspot.com/bug?extid=6e682caa546b7c96c859
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13579abd400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13654f6b400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6e682caa546b7c96c859@syzkaller.appspotmail.com
+Eric knows what's wrong here. Something about "bpf: add tests for
direct packet access from CGROUP_SKB" commit. Was is amended to fix a
bug?
> ODEBUG: object 0000000015e9012c is on stack 00000000115bcb67, but NOT
> annotated.
> WARNING: CPU: 0 PID: 5594 at lib/debugobjects.c:369 debug_object_is_on_stack
> lib/debugobjects.c:363 [inline]
> WARNING: CPU: 0 PID: 5594 at lib/debugobjects.c:369
> __debug_object_init.cold.14+0x51/0xdf lib/debugobjects.c:395
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 5594 Comm: syz-executor740 Not tainted 4.19.0-rc8-next-20181019+
> #98
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x244/0x39d lib/dump_stack.c:113
> panic+0x2ad/0x55c kernel/panic.c:188
> __warn.cold.8+0x20/0x45 kernel/panic.c:540
> report_bug+0x254/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
> do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
> RIP: 0010:debug_object_is_on_stack lib/debugobjects.c:363 [inline]
> RIP: 0010:__debug_object_init.cold.14+0x51/0xdf lib/debugobjects.c:395
> Code: ea 03 80 3c 02 00 75 7c 49 8b 54 24 18 48 89 de 48 c7 c7 c0 f1 40 88
> 4c 89 85 d0 fd ff ff e8 09 8c d1 fd 4c 8b 85 d0 fd ff ff <0f> 0b e9 09 d6 ff
> ff 41 83 c4 01 b8 ff ff 37 00 44 89 25 b7 4e 66
> RSP: 0018:ffff8801bb387308 EFLAGS: 00010086
> RAX: 0000000000000050 RBX: ffff8801bb387af8 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffff816585a5 RDI: 0000000000000005
> RBP: ffff8801bb387560 R08: ffff8801cb208a20 R09: ffffed003b5c5008
> R10: ffffed003b5c5008 R11: ffff8801dae28047 R12: ffff8801d82ea300
> R13: 0000000000069700 R14: ffff8801d82ea300 R15: ffff8801cb208a10
> debug_object_init+0x16/0x20 lib/debugobjects.c:432
> debug_timer_init kernel/time/timer.c:704 [inline]
> debug_init kernel/time/timer.c:757 [inline]
> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x440259
> 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:00007ffc212cf818 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
> RDX: 0000000000000028 RSI: 0000000020000080 RDI: 000000000000000a
> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401ae0
> R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.19.0-rc8-next-20181019+ #98 Not tainted
> ------------------------------------------------------
> syz-executor740/5594 is trying to acquire lock:
> 00000000688fcc6b ((console_sem).lock){-.-.}, at: down_trylock+0x13/0x70
> kernel/locking/semaphore.c:136
>
> but task is already holding lock:
> 00000000505ead1b (&obj_hash[i].lock){-.-.}, at:
> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&obj_hash[i].lock){-.-.}:
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
> debug_object_init+0x16/0x20 lib/debugobjects.c:432
> debug_hrtimer_init kernel/time/hrtimer.c:410 [inline]
> debug_init kernel/time/hrtimer.c:458 [inline]
> hrtimer_init+0x97/0x490 kernel/time/hrtimer.c:1308
> init_dl_task_timer+0x1b/0x50 kernel/sched/deadline.c:1057
> __sched_fork+0x2ae/0x590 kernel/sched/core.c:2166
> init_idle+0x75/0x740 kernel/sched/core.c:5382
> sched_init+0xb33/0xc02 kernel/sched/core.c:6065
> start_kernel+0x4be/0xa2b init/main.c:608
> x86_64_start_reservations+0x2e/0x30 arch/x86/kernel/head64.c:472
> x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:451
> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
>
> -> #2 (&rq->lock){-.-.}:
> __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
> _raw_spin_lock+0x2d/0x40 kernel/locking/spinlock.c:144
> rq_lock kernel/sched/sched.h:1127 [inline]
> task_fork_fair+0xb0/0x6d0 kernel/sched/fair.c:9768
> sched_fork+0x443/0xba0 kernel/sched/core.c:2359
> copy_process+0x2585/0x8770 kernel/fork.c:1887
> _do_fork+0x1cb/0x11c0 kernel/fork.c:2216
> kernel_thread+0x34/0x40 kernel/fork.c:2275
> rest_init+0x28/0x372 init/main.c:409
> arch_call_rest_init+0xe/0x1b
> start_kernel+0x9f0/0xa2b init/main.c:745
> x86_64_start_reservations+0x2e/0x30 arch/x86/kernel/head64.c:472
> x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:451
> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
>
> -> #1 (&p->pi_lock){-.-.}:
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
> try_to_wake_up+0xd2/0x12e0 kernel/sched/core.c:1965
> wake_up_process+0x10/0x20 kernel/sched/core.c:2129
> __up.isra.1+0x1c0/0x2a0 kernel/locking/semaphore.c:262
> up+0x13c/0x1c0 kernel/locking/semaphore.c:187
> __up_console_sem+0xbe/0x1b0 kernel/printk/printk.c:236
> console_unlock+0x80c/0x1190 kernel/printk/printk.c:2432
> vprintk_emit+0x391/0x990 kernel/printk/printk.c:1922
> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
> printk+0xa7/0xcf kernel/printk/printk.c:1997
> check_stack_usage kernel/exit.c:755 [inline]
> do_exit.cold.18+0x57/0x16f kernel/exit.c:916
> do_group_exit+0x177/0x440 kernel/exit.c:970
> __do_sys_exit_group kernel/exit.c:981 [inline]
> __se_sys_exit_group kernel/exit.c:979 [inline]
> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:979
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 ((console_sem).lock){-.-.}:
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
> down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
> __down_trylock_console_sem+0xae/0x1f0 kernel/printk/printk.c:219
> console_trylock+0x15/0xa0 kernel/printk/printk.c:2247
> console_trylock_spinning kernel/printk/printk.c:1653 [inline]
> vprintk_emit+0x372/0x990 kernel/printk/printk.c:1921
> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
> printk+0xa7/0xcf kernel/printk/printk.c:1997
> debug_object_is_on_stack lib/debugobjects.c:363 [inline]
> __debug_object_init.cold.14+0x4a/0xdf lib/debugobjects.c:395
> debug_object_init+0x16/0x20 lib/debugobjects.c:432
> debug_timer_init kernel/time/timer.c:704 [inline]
> debug_init kernel/time/timer.c:757 [inline]
> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
> Chain exists of:
> (console_sem).lock --> &rq->lock --> &obj_hash[i].lock
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&obj_hash[i].lock);
> lock(&rq->lock);
> lock(&obj_hash[i].lock);
> lock((console_sem).lock);
>
> *** DEADLOCK ***
>
> 1 lock held by syz-executor740/5594:
> #0: 00000000505ead1b (&obj_hash[i].lock){-.-.}, at:
> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>
> stack backtrace:
> CPU: 0 PID: 5594 Comm: syz-executor740 Not tainted 4.19.0-rc8-next-20181019+
> #98
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x244/0x39d lib/dump_stack.c:113
> print_circular_bug.isra.35.cold.54+0x1bd/0x27d
> kernel/locking/lockdep.c:1221
> check_prev_add kernel/locking/lockdep.c:1863 [inline]
> check_prevs_add kernel/locking/lockdep.c:1976 [inline]
> validate_chain kernel/locking/lockdep.c:2347 [inline]
> __lock_acquire+0x3399/0x4c20 kernel/locking/lockdep.c:3341
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
> down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
> __down_trylock_console_sem+0xae/0x1f0 kernel/printk/printk.c:219
> console_trylock+0x15/0xa0 kernel/printk/printk.c:2247
> console_trylock_spinning kernel/printk/printk.c:1653 [inline]
> vprintk_emit+0x372/0x990 kernel/printk/printk.c:1921
> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
> printk+0xa7/0xcf kernel/printk/printk.c:1997
> debug_object_is_on_stack lib/debugobjects.c:363 [inline]
> __debug_object_init.cold.14+0x4a/0xdf lib/debugobjects.c:395
> debug_object_init+0x16/0x20 lib/debugobjects.c:432
> debug_timer_init kernel/time/timer.c:704 [inline]
> debug_init kernel/time/timer.c:757 [inline]
> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x440259
> 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:00007ffc212cf818 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
> RDX: 0000000000000028 RSI: 0000000020000080 RDI: 000000000000000a
> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401ae0
> R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> 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
>
> --
> 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/0000000000008db3210579416691%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [Patch V3 net 05/11] net: hns3: remove unnecessary queue reset in the hns3_uninit_all_ring()
From: Huazhong Tan @ 2018-10-28 3:34 UTC (permalink / raw)
To: davem, sergei.shtylyov
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-1-git-send-email-tanhuazhong@huawei.com>
It is not necessary to reset the queue in the hns3_uninit_all_ring(),
since the queue is stopped in the down operation, and will be reset
in the up operaton. And the judgment of the HCLGE_STATE_RST_HANDLING
flag in the hclge_reset_tqp() is not correct, because we need to reset
tqp during pf reset, otherwise it may cause queue not be reset to
working state problem.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
V3: Fixes comments from Sergei Shtylyov
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 6f0fd62..a80ecfb 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3240,9 +3240,6 @@ int hns3_uninit_all_ring(struct hns3_nic_priv *priv)
int i;
for (i = 0; i < h->kinfo.num_tqps; i++) {
- if (h->ae_algo->ops->reset_queue)
- h->ae_algo->ops->reset_queue(h, i);
-
hns3_fini_ring(priv->ring_data[i].ring);
hns3_fini_ring(priv->ring_data[i + h->kinfo.num_tqps].ring);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 2a63147..4dd0506 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -6116,9 +6116,6 @@ void hclge_reset_tqp(struct hnae3_handle *handle, u16 queue_id)
u16 queue_gid;
int ret;
- if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
- return;
-
queue_gid = hclge_covert_handle_qid_global(handle, queue_id);
ret = hclge_tqp_enable(hdev, queue_id, 0, false);
--
2.7.4
^ permalink raw reply related
* [Patch V3 net 07/11] net: hns3: bugfix for hclge_mdio_write and hclge_mdio_read
From: Huazhong Tan @ 2018-10-28 3:34 UTC (permalink / raw)
To: davem, sergei.shtylyov
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-1-git-send-email-tanhuazhong@huawei.com>
When there is a PHY, the driver needs to complete some operations through
MDIO during reset reinitialization, so HCLGE_STATE_CMD_DISABLE is more
suitable than HCLGE_STATE_RST_HANDLING to prevent the MDIO operation from
being sent during the hardware reset.
Fixes: b50ae26c57cb ("net: hns3: never send command queue message to IMP when reset)
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
index 24b1f2a..0301863 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
@@ -52,7 +52,7 @@ static int hclge_mdio_write(struct mii_bus *bus, int phyid, int regnum,
struct hclge_desc desc;
int ret;
- if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ if (test_bit(HCLGE_STATE_CMD_DISABLE, &hdev->state))
return 0;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_MDIO_CONFIG, false);
@@ -90,7 +90,7 @@ static int hclge_mdio_read(struct mii_bus *bus, int phyid, int regnum)
struct hclge_desc desc;
int ret;
- if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ if (test_bit(HCLGE_STATE_CMD_DISABLE, &hdev->state))
return 0;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_MDIO_CONFIG, true);
--
2.7.4
^ permalink raw reply related
* [Patch V3 net 06/11] net: hns3: bugfix for is_valid_csq_clean_head()
From: Huazhong Tan @ 2018-10-28 3:34 UTC (permalink / raw)
To: davem, sergei.shtylyov
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-1-git-send-email-tanhuazhong@huawei.com>
The HEAD pointer of the hardware command queue maybe equal to the command
queue's next_to_use in the driver, so that does not belong to the invalid
HEAD pointer, since the hardware may not process the command in time,
causing the HEAD pointer to be too late to update. The variables' name
in this function is unreadable, so give them a more readable one.
Fixes: 3ff504908f95 ("net: hns3: fix a dead loop in hclge_cmd_csq_clean")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 68026a5..690f62e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -24,15 +24,15 @@ static int hclge_ring_space(struct hclge_cmq_ring *ring)
return ring->desc_num - used - 1;
}
-static int is_valid_csq_clean_head(struct hclge_cmq_ring *ring, int h)
+static int is_valid_csq_clean_head(struct hclge_cmq_ring *ring, int head)
{
- int u = ring->next_to_use;
- int c = ring->next_to_clean;
+ int ntu = ring->next_to_use;
+ int ntc = ring->next_to_clean;
- if (unlikely(h >= ring->desc_num))
- return 0;
+ if (ntu > ntc)
+ return head >= ntc && head <= ntu;
- return u > c ? (h > c && h <= u) : (h > c || h <= u);
+ return head >= ntc || head <= ntu;
}
static int hclge_alloc_cmd_desc(struct hclge_cmq_ring *ring)
--
2.7.4
^ permalink raw reply related
* [Patch V3 net 10/11] net: hns3: bugfix for rtnl_lock's range in the hclge_reset()
From: Huazhong Tan @ 2018-10-28 3:34 UTC (permalink / raw)
To: davem, sergei.shtylyov
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-1-git-send-email-tanhuazhong@huawei.com>
Since hclge_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclge_reset_wait(). So this patch releases the lock for the duration
of hclge_reset_wait().
Fixes: 6d4fab39533f ("net: hns3: Reset net device with rtnl_lock")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index f3212c9..ffdd960 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2470,14 +2470,17 @@ static void hclge_reset(struct hclge_dev *hdev)
handle = &hdev->vport[0].nic;
rtnl_lock();
hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ rtnl_unlock();
if (!hclge_reset_wait(hdev)) {
+ rtnl_lock();
hclge_notify_client(hdev, HNAE3_UNINIT_CLIENT);
hclge_reset_ae_dev(hdev->ae_dev);
hclge_notify_client(hdev, HNAE3_INIT_CLIENT);
hclge_clear_reset_cause(hdev);
} else {
+ rtnl_lock();
/* schedule again to check pending resets later */
set_bit(hdev->reset_type, &hdev->reset_pending);
hclge_reset_task_schedule(hdev);
--
2.7.4
^ permalink raw reply related
* [Patch V3 net 00/11] Bugfix for the HNS3 driver
From: Huazhong Tan @ 2018-10-28 3:34 UTC (permalink / raw)
To: davem, sergei.shtylyov
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
This patch series include bugfix for the HNS3 ethernet
controller driver.
Change log:
V2->V3:
Fixes comments from Sergei Shtylyov
V1->V2:
Fixes the compilation break reported by kbuild test robot
http://patchwork.ozlabs.org/patch/989818/
Huazhong Tan (11):
net: hns3: add error handler for hns3_nic_init_vector_data()
net: hns3: add error handler for
hns3_get_ring_config/hns3_queue_to_ring
net: hns3: bugfix for reporting unknown vector0 interrupt repeatly
problem
net: hns3: bugfix for the initialization of command queue's spin lock
net: hns3: remove unnecessary queue reset in the
hns3_uninit_all_ring()
net: hns3: bugfix for is_valid_csq_clean_head()
net: hns3: bugfix for hclge_mdio_write and hclge_mdio_read
net: hns3: fix incorrect return value/type of some functions
net: hns3: bugfix for handling mailbox while the command queue
reinitialized
net: hns3: bugfix for rtnl_lock's range in the hclge_reset()
net: hns3: bugfix for rtnl_lock's range in the hclgevf_reset()
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 6 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 105 +++++++++++++++------
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 26 +++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 42 ++++-----
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 2 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 6 ++
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 4 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 19 ++--
9 files changed, 136 insertions(+), 76 deletions(-)
--
2.7.4
^ permalink raw reply
* [Patch V3 net 09/11] net: hns3: bugfix for handling mailbox while the command queue reinitialized
From: Huazhong Tan @ 2018-10-28 3:34 UTC (permalink / raw)
To: davem, sergei.shtylyov
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-1-git-send-email-tanhuazhong@huawei.com>
In a multi-core machine, the mailbox service and reset service
will be executed at the same time. The reset service will re-initialize
the command queue, before that, the mailbox handler can only get some
invalid messages.
The HCLGE_STATE_CMD_DISABLE flag means that the command queue is not
available and needs to be reinitialized. Therefore, when the mailbox
handler recognizes this flag, it should not process the command.
Fixes: dde1a86e93ca ("net: hns3: Add mailbox support to PF driver")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
V3: Fixes comments from Sergei Shtylyov
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index 04462a3..f890022 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -400,6 +400,12 @@ void hclge_mbx_handler(struct hclge_dev *hdev)
/* handle all the mailbox requests in the queue */
while (!hclge_cmd_crq_empty(&hdev->hw)) {
+ if (test_bit(HCLGE_STATE_CMD_DISABLE, &hdev->state)) {
+ dev_warn(&hdev->pdev->dev,
+ "command queue needs re-initializing\n");
+ return;
+ }
+
desc = &crq->desc[crq->next_to_use];
req = (struct hclge_mbx_vf_to_pf_cmd *)desc->data;
--
2.7.4
^ permalink raw reply related
* [Patch V3 net 11/11] net: hns3: bugfix for rtnl_lock's range in the hclgevf_reset()
From: Huazhong Tan @ 2018-10-28 3:34 UTC (permalink / raw)
To: davem, sergei.shtylyov
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-1-git-send-email-tanhuazhong@huawei.com>
Since hclgevf_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclgevf_reset_wait(). So this patch releases the lock for the duration
of hclgevf_reset_wait().
Fixes: 6988eb2a9b77 ("net: hns3: Add support to reset the enet/ring mgmt layer")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index b224f6a..085edb9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1170,6 +1170,8 @@ static int hclgevf_reset(struct hclgevf_dev *hdev)
/* bring down the nic to stop any ongoing TX/RX */
hclgevf_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ rtnl_unlock();
+
/* check if VF could successfully fetch the hardware reset completion
* status from the hardware
*/
@@ -1181,12 +1183,15 @@ static int hclgevf_reset(struct hclgevf_dev *hdev)
ret);
dev_warn(&hdev->pdev->dev, "VF reset failed, disabling VF!\n");
+ rtnl_lock();
hclgevf_notify_client(hdev, HNAE3_UNINIT_CLIENT);
rtnl_unlock();
return ret;
}
+ rtnl_lock();
+
/* now, re-initialize the nic client and ae device*/
ret = hclgevf_reset_stack(hdev);
if (ret)
--
2.7.4
^ 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