* Re: [PATCH net] vhost: validate log when IOTLB is enabled
From: David Miller @ 2018-03-29 20:23 UTC (permalink / raw)
To: mst; +Cc: jasowang, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20180329154803-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 29 Mar 2018 15:48:22 +0300
> On Thu, Mar 29, 2018 at 04:00:04PM +0800, Jason Wang wrote:
>> Vq log_base is the userspace address of bitmap which has nothing to do
>> with IOTLB. So it needs to be validated unconditionally otherwise we
>> may try use 0 as log_base which may lead to pin pages that will lead
>> unexpected result (e.g trigger BUG_ON() in set_bit_to_user()).
>>
>> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
>> Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> stable material I guess.
Applied and queued up for -stable.
^ permalink raw reply
* Re: INFO: task hung in stop_sync_thread (2)
From: Julian Anastasov @ 2018-03-29 20:10 UTC (permalink / raw)
To: syzbot
Cc: coreteam, davem, fw, horms, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
In-Reply-To: <000000000000878b6a05688805c5@google.com>
Hello,
On Thu, 29 Mar 2018, syzbot wrote:
> syzbot hit the following crash on net-next commit
> 5d22d47b9ed96eddb35821dc2cc4f629f45827f7 (Tue Mar 27 17:33:21 2018 +0000)
> Merge branch 'sfc-filter-locking'
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=5fe074c01b2032ce9618
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=6119456711376896
> Kernel config: https://syzkaller.appspot.com/x/.config?id=4372867303600475372
> compiler: gcc (GCC) 7.1.1 20170620
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5fe074c01b2032ce9618@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.
>
> IPVS: sync thread started: state = BACKUP, mcast_ifn = syz_tun, syncid = 4, id
> IPVS: = 0
> IPVS: stopping backup sync thread 25415 ...
> INFO: task syz-executor7:25421 blocked for more than 120 seconds.
I think, I know what happens: start_sync_thread holds
rtnl_lock while calling kthread_stop on error. The backup kthread is
signalled and it tries to rtnl_lock in sock_release => lockup.
I think, my fix will solve both reports, only that there is no
reproducer for this one to test the fix with test command.
> Not tainted 4.16.0-rc6+ #284
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> syz-executor7 D23688 25421 4408 0x00000004
> Call Trace:
> context_switch kernel/sched/core.c:2862 [inline]
> __schedule+0x8fb/0x1ec0 kernel/sched/core.c:3440
> schedule+0xf5/0x430 kernel/sched/core.c:3499
> schedule_timeout+0x1a3/0x230 kernel/time/timer.c:1777
> do_wait_for_common kernel/sched/completion.c:86 [inline]
> __wait_for_common kernel/sched/completion.c:107 [inline]
> wait_for_common kernel/sched/completion.c:118 [inline]
> wait_for_completion+0x415/0x770 kernel/sched/completion.c:139
> kthread_stop+0x14a/0x7a0 kernel/kthread.c:530
> stop_sync_thread+0x3d9/0x740 net/netfilter/ipvs/ip_vs_sync.c:1996
> do_ip_vs_set_ctl+0x2b1/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2394
> nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
> nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
> ip_setsockopt+0x97/0xa0 net/ipv4/ip_sockglue.c:1253
> sctp_setsockopt+0x2ca/0x63e0 net/sctp/socket.c:4154
> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:3039
> SYSC_setsockopt net/socket.c:1850 [inline]
> SyS_setsockopt+0x189/0x360 net/socket.c:1829
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x454889
> RSP: 002b:00007fc927626c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 00007fc9276276d4 RCX: 0000000000454889
> RDX: 000000000000048c RSI: 0000000000000000 RDI: 0000000000000017
> RBP: 000000000072bf58 R08: 0000000000000018 R09: 0000000000000000
> R10: 0000000020000000 R11: 0000000000000246 R12: 00000000ffffffff
> R13: 000000000000051c R14: 00000000006f9b40 R15: 0000000000000001
>
> Showing all locks held in the system:
> 2 locks held by khungtaskd/868:
> #0: (rcu_read_lock){....}, at: [<00000000a1a8f002>]
> check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
> #0: (rcu_read_lock){....}, at: [<00000000a1a8f002>] watchdog+0x1c5/0xd60
> kernel/hung_task.c:249
> #1: (tasklist_lock){.+.+}, at: [<0000000037c2f8f9>]
> debug_show_all_locks+0xd3/0x3d0 kernel/locking/lockdep.c:4470
> 1 lock held by rsyslogd/4247:
> #0: (&f->f_pos_lock){+.+.}, at: [<000000000d8d6983>] __fdget_pos+0x12b/0x190
> fs/file.c:765
> 2 locks held by getty/4338:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
> n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4339:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
> n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4340:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
> n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4341:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
> n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4342:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
> n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4343:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
> n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4344:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
> n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
> 3 locks held by kworker/0:5/6494:
> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000a062b18e>]
> work_static include/linux/workqueue.h:198 [inline]
> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000a062b18e>]
> set_work_data kernel/workqueue.c:619 [inline]
> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000a062b18e>]
> set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000a062b18e>]
> process_one_work+0xb12/0x1bb0 kernel/workqueue.c:2084
> #1: ((addr_chk_work).work){+.+.}, at: [<00000000278427d5>]
> process_one_work+0xb89/0x1bb0 kernel/workqueue.c:2088
> #2: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by syz-executor7/25421:
> #0: (ipvs->sync_mutex){+.+.}, at: [<00000000d414a689>]
> do_ip_vs_set_ctl+0x277/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2393
> 2 locks held by syz-executor7/25427:
> #0: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> #1: (ipvs->sync_mutex){+.+.}, at: [<00000000e6d48489>]
> do_ip_vs_set_ctl+0x10f8/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2388
Above is start_sync_thread() waiting kthread to stop...
> 1 lock held by syz-executor7/25435:
> #0: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by ipvs-b:2:0/25415:
> #0: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
backup kthread needs rtnl_lock to stop...
>
> =============================================
>
> NMI backtrace for cpu 1
> CPU: 1 PID: 868 Comm: khungtaskd Not tainted 4.16.0-rc6+ #284
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
> 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x24d lib/dump_stack.c:53
> nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x123/0x180 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
> check_hung_task kernel/hung_task.c:132 [inline]
> check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
> watchdog+0x90c/0xd60 kernel/hung_task.c:249
> kthread+0x33c/0x400 kernel/kthread.c:238
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
> Sending NMI from CPU 1 to CPUs 0:
> NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0x6/0x10
> arch/x86/include/asm/irqflags.h:54
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug report.
> Note: all commands must start from beginning of the line in the email body.
Regards
^ permalink raw reply
* Re: [net-next PATCH v2 08/10] net: netcp: ethss: use of_get_phy_mode() to support different RGMII modes
From: Murali Karicheri @ 2018-03-29 20:03 UTC (permalink / raw)
To: Andrew Lunn
Cc: mark.rutland, devicetree, malat, netdev, linux-kernel, w-kwok2,
robh+dt, ssantosh, davem, linux-arm-kernel
In-Reply-To: <20180327173509.GQ5862@lunn.ch>
On 03/27/2018 01:35 PM, Andrew Lunn wrote:
>> + } else if (slave->link_interface == RGMII_LINK_MAC_PHY) {
>> + has_phy = true;
>> + phy_mode = of_get_phy_mode(slave->node);
>> + /* if phy-mode is not present, default to
>> + * PHY_INTERFACE_MODE_RGMII
>> + */
>> + if (phy_mode < 0)
>> + phy_mode = PHY_INTERFACE_MODE_RGMII;
>
> Can only do RGMII? Maybe add a call here to
> phy_interface_mode_is_rgmii() and return -EINVAL if DT contains
> something which is not RGMII?
>
Ok. Make sense.
> Andrew
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH net-next 6/6] netdevsim: Add simple FIB resource controller via devlink
From: David Ahern @ 2018-03-29 20:01 UTC (permalink / raw)
To: David Miller, jakub.kicinski
Cc: netdev, roopa, shm, jiri, idosch, andy.roulin
In-Reply-To: <20180329.141119.1343151558612891683.davem@davemloft.net>
On 3/29/18 12:11 PM, David Miller wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Tue, 27 Mar 2018 18:34:50 -0700
>
>> On Tue, 27 Mar 2018 18:22:00 -0700, David Ahern wrote:
>>> +void nsim_devlink_setup(struct netdevsim *ns)
>>> +{
> ...
>> nit: DaveM expressed preference to not have silent failures in a
>> discussion about DebugFS, not sure it applies here, but why not
>> handle errors?
>
> Yes it is a concern.
>
> David please address this as a follow-up.
Will do.
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: Allow FIB notifiers to fail add and replace
From: David Ahern @ 2018-03-29 20:00 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180329082934.GG22733@splinter>
On 3/29/18 2:29 AM, Ido Schimmel wrote:
> Nice work, David. Ran various tests and didn't see any regressions.
>
> I know you already know this, but for the record, we plan to add
> accounting to KVD hash resources which will eventually allow us to
> return errors when resources are exceeded.
Thanks for running the tests, and looking forward to the mlxsw updates
for resource management.
^ permalink raw reply
* [PATCH net-next] tc-testing: Add newline when writing test case files
From: Lucas Bates @ 2018-03-29 19:58 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Lucas Bates
When using the -i feature to generate random ID numbers for test
cases in tdc, the function that writes the JSON to file doesn't
add a newline character to the end of the file, so we have to
add our own.
Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
---
tools/testing/selftests/tc-testing/tdc.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/tc-testing/tdc.py b/tools/testing/selftests/tc-testing/tdc.py
index 44de4a2..87a04a8 100755
--- a/tools/testing/selftests/tc-testing/tdc.py
+++ b/tools/testing/selftests/tc-testing/tdc.py
@@ -490,6 +490,7 @@ def generate_case_ids(alltests):
testlist.append(t)
outfile = open(f, "w")
json.dump(testlist, outfile, indent=4)
+ outfile.write("\n")
outfile.close()
def filter_tests_by_id(args, testlist):
^ permalink raw reply related
* Re: [PATCH net-next] net: systemport: Add support for BQL
From: David Miller @ 2018-03-29 19:56 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, opendmb
In-Reply-To: <d7a6f1a5-162c-72c8-e20e-d128eadf5d3e@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 29 Mar 2018 12:30:08 -0700
> On 03/29/2018 12:27 PM, Florian Fainelli wrote:
>> We had all the accounting done already, but we did not plumb BQL. In
>> order to avoid fetching twice the netdev_queue pointer in the TX
>> reclamation path, move the queue waking into __bcm_sysport_tx_reclaim()
>> so we can update BQL and wake the TX queue there in one go.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> David, please disregard this patch, I found a bunch of issues, and it
> won't apply with the coalescing patch series.
Sure, no problem.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] Add ATU/VTU statistics
From: David Miller @ 2018-03-29 19:55 UTC (permalink / raw)
To: andrew; +Cc: netdev, f.fainelli
In-Reply-To: <1522273829-23542-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 28 Mar 2018 23:50:27 +0200
> Previous patches have added basic support for Address Translation Unit
> and VLAN translation Unit violation interrupts. Add statistics
> counters for when these occur, which can be accessed using
> ethtool. Downgrade one of the particularly spammy warnings from VTU
> violations to debug only, now that we have a counter for it.
Series applied, thanks Andrew.
^ permalink raw reply
* Re: [PATCH net-next 0/9] devlink: Add support for region access
From: Andrew Lunn @ 2018-03-29 19:51 UTC (permalink / raw)
To: Alex Vesker; +Cc: David S. Miller, netdev, Tariq Toukan, Jiri Pirko
In-Reply-To: <962b56c1-d471-97ec-e8e9-18252e809dfe@mellanox.com>
> >>Show all of the exposed regions with region sizes:
> >>$ devlink region show
> >>pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2]
> >So you have 2Mbytes of snapshot data. Is this held in the device, or
> >kernel memory?
> This is allocated in devlink, the maximum number of snapshots is set by the
> driver.
And it seems to want contiguous pages. How well does that work after
the system has been running for a while and memory is fragmented?
> >>Dump a snapshot:
> >>$ devlink region dump pci/0000:00:05.0/fw-health snapshot 1
> >>0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
> >>0000000000000010 0000 0000 ffff ff04 0029 8c00 0028 8cc8
> >>0000000000000020 0016 0bb8 0016 1720 0000 0000 c00f 3ffc
> >>0000000000000030 bada cce5 bada cce5 bada cce5 bada cce5
> >>
> >>Read a specific part of a snapshot:
> >>$ devlink region read pci/0000:00:05.0/fw-health snapshot 1 address 0
> >> length 16
> >>0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
> >Why a separate command? It seems to be just a subset of dump.
>
> This is useful when debugging values on specific addresses, this also
> brings the API one step closer for a read and write API.
The functionality is useful, yes. But why two commands? Why not one
command, dump, which takes optional parameters?
Also, i doubt write support will be accepted. That sounds like the
start of an API to allow a user space driver.
Andrew
^ permalink raw reply
* [PATCH net] vrf: Fix use after free and double free in vrf_finish_output
From: David Ahern @ 2018-03-29 19:49 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Miguel Fadon Perlines
Miguel reported an skb use after free / double free in vrf_finish_output
when neigh_output returns an error. The vrf driver should return after
the call to neigh_output as it takes over the skb on error path as well.
Patch is a simplified version of Miguel's patch which was written for 4.9,
and updated to top of tree.
Fixes: 8f58336d3f78a ("net: Add ethernet header for pass through VRF device")
Signed-off-by: Miguel Fadon Perlines <mfadon@teldat.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
drivers/net/vrf.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 139c61c8244a..ac40924fe437 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -578,12 +578,13 @@ static int vrf_finish_output(struct net *net, struct sock *sk, struct sk_buff *s
if (!IS_ERR(neigh)) {
sock_confirm_neigh(skb, neigh);
ret = neigh_output(neigh, skb);
+ rcu_read_unlock_bh();
+ return ret;
}
rcu_read_unlock_bh();
err:
- if (unlikely(ret < 0))
- vrf_tx_error(skb->dev, skb);
+ vrf_tx_error(skb->dev, skb);
return ret;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] json_print: fix print_uint with helper type extensions
From: Kevin Darbyshire-Bryant @ 2018-03-29 19:33 UTC (permalink / raw)
To: David Ahern; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <4f02a767-abc6-4e04-22c1-fee79e1ac323@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
> On 26 Mar 2018, at 16:03, David Ahern <dsahern@gmail.com> wrote:
>
> On 3/18/18 2:40 AM, Kevin Darbyshire-Bryant wrote:
>>
>>
>>> On 16 Mar 2018, at 20:34, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>>>
>>>> print_uint64(PRINT_ANY, "refcnt", "refcnt %" PRIu64 " ", t->tcm_info)
>>>>
>>>> Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
>>>
>>> I am fine with this. But since there is no code using it yet, it should
>>> go net-next branch.
>>>
>>> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
>>
>> Existing code is tripping up over the hidden uint - > uint64_t promotion in print_uint in iproute2 v4.15, that’s how I fell over the issue. Should I split the patch? One fixing the uint->uint64_t and the other offering the explicit type length options.
>>
>> Obviously I now realise that the email header should have iproute2 in it. Learning, slowly :-)
>>
>
> Kevin: I guess you need to split the patch. Extract the bug fix piece
> and send for iproute2; enhancements go to iproute2-next.
Done that - hopefully done it right or at least better.
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH iproute2-next] json_print: fix print_uint with helper type extensions
From: Kevin Darbyshire-Bryant @ 2018-03-29 19:32 UTC (permalink / raw)
To: netdev; +Cc: Kevin Darbyshire-Bryant
Introduce print helper functions for int, uint, explicit int32, uint32,
int64 & uint64.
print_int used 'int' type internally, whereas print_uint used 'uint64_t'
These helper functions eventually call vfprintf(fp, fmt, args) which is
a variable argument list function and is dependent upon 'fmt' containing
correct information about the length of the passed arguments.
Unfortunately print_int v print_uint offered no clue to the programmer
that internally passed ints to print_uint were being promoted to 64bits,
thus the format passed in 'fmt' string vs the actual passed integer
could be different lengths. This is even more interesting on big endian
architectures where 'vfprintf' would be looking in the middle of an
int64 type.
print_u/int now stick with native int size. print_u/int32 & print
u/int64 functions offer explicit integer sizes.
To portably use these formats you should use the relevant PRIdN or PRIuN
formats as defined in inttypes.h
e.g.
print_uint64(PRINT_ANY, "refcnt", "refcnt %" PRIu64 " ", t->tcm_info)
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
---
include/json_print.h | 6 +++++-
lib/json_print.c | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/json_print.h b/include/json_print.h
index 2ca7830a..fb62b142 100644
--- a/include/json_print.h
+++ b/include/json_print.h
@@ -56,10 +56,14 @@ void close_json_array(enum output_type type, const char *delim);
print_color_##type_name(t, COLOR_NONE, key, fmt, value); \
}
_PRINT_FUNC(int, int);
+_PRINT_FUNC(uint, unsigned int);
_PRINT_FUNC(bool, bool);
_PRINT_FUNC(null, const char*);
_PRINT_FUNC(string, const char*);
-_PRINT_FUNC(uint, uint64_t);
+_PRINT_FUNC(int32, int32_t);
+_PRINT_FUNC(uint32, uint32_t);
+_PRINT_FUNC(int64, int64_t);
+_PRINT_FUNC(uint64, uint64_t);
_PRINT_FUNC(hu, unsigned short);
_PRINT_FUNC(hex, unsigned int);
_PRINT_FUNC(0xhex, unsigned int);
diff --git a/lib/json_print.c b/lib/json_print.c
index bda72933..1194a6ec 100644
--- a/lib/json_print.c
+++ b/lib/json_print.c
@@ -116,8 +116,12 @@ void close_json_array(enum output_type type, const char *str)
} \
}
_PRINT_FUNC(int, int);
+_PRINT_FUNC(uint, unsigned int);
_PRINT_FUNC(hu, unsigned short);
-_PRINT_FUNC(uint, uint64_t);
+_PRINT_FUNC(int32, int32_t);
+_PRINT_FUNC(uint32, uint32_t);
+_PRINT_FUNC(int64, int64_t);
+_PRINT_FUNC(uint64, uint64_t);
_PRINT_FUNC(lluint, unsigned long long int);
_PRINT_FUNC(float, double);
#undef _PRINT_FUNC
--
2.14.3 (Apple Git-98)
^ permalink raw reply related
* Re: [PATCH net-next] net: systemport: Add support for BQL
From: Florian Fainelli @ 2018-03-29 19:30 UTC (permalink / raw)
To: netdev, davem; +Cc: opendmb
In-Reply-To: <20180329192711.19215-1-f.fainelli@gmail.com>
On 03/29/2018 12:27 PM, Florian Fainelli wrote:
> We had all the accounting done already, but we did not plumb BQL. In
> order to avoid fetching twice the netdev_queue pointer in the TX
> reclamation path, move the queue waking into __bcm_sysport_tx_reclaim()
> so we can update BQL and wake the TX queue there in one go.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
David, please disregard this patch, I found a bunch of issues, and it
won't apply with the coalescing patch series.
--
Florian
^ permalink raw reply
* [PATCH net-next] net: systemport: Add support for BQL
From: Florian Fainelli @ 2018-03-29 19:27 UTC (permalink / raw)
To: netdev; +Cc: davem, opendmb, Florian Fainelli
We had all the accounting done already, but we did not plumb BQL. In
order to avoid fetching twice the netdev_queue pointer in the TX
reclamation path, move the queue waking into __bcm_sysport_tx_reclaim()
so we can update BQL and wake the TX queue there in one go.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 4e26f606a7f2..22ec8d5452bf 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -903,6 +903,7 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
struct net_device *ndev = priv->netdev;
unsigned int txbds_processed = 0;
struct bcm_sysport_cb *cb;
+ struct netdev_queue *txq;
unsigned int txbds_ready;
unsigned int c_index;
u32 hw_ind;
@@ -945,10 +946,16 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
ring->c_index = c_index;
+ txq = netdev_get_tx_queue(ndev, ring->index);
+ netdev_tx_completed_queue(txq, pkts_compl, bytes_compl);
+
netif_dbg(priv, tx_done, ndev,
"ring=%d c_index=%d pkts_compl=%d, bytes_compl=%d\n",
ring->index, ring->c_index, pkts_compl, bytes_compl);
+ if (pkts_compl)
+ netif_tx_wake_queue(txq);
+
return pkts_compl;
}
@@ -956,17 +963,11 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
static unsigned int bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
struct bcm_sysport_tx_ring *ring)
{
- struct netdev_queue *txq;
unsigned int released;
unsigned long flags;
- txq = netdev_get_tx_queue(priv->netdev, ring->index);
-
spin_lock_irqsave(&ring->lock, flags);
released = __bcm_sysport_tx_reclaim(priv, ring);
- if (released)
- netif_tx_wake_queue(txq);
-
spin_unlock_irqrestore(&ring->lock, flags);
return released;
@@ -1359,6 +1360,8 @@ static netdev_tx_t bcm_sysport_xmit(struct sk_buff *skb,
desc->addr_status_len = len_status;
wmb();
+ netdev_tx_sent_queue(txq, skb->len);
+
/* Write this descriptor address to the RING write port */
tdma_port_write_desc_addr(priv, desc, ring->index);
@@ -1584,6 +1587,7 @@ static void bcm_sysport_fini_tx_ring(struct bcm_sysport_priv *priv,
napi_disable(&ring->napi);
cancel_work_sync(&ring->dim.dim.work);
netif_napi_del(&ring->napi);
+ netdev_tx_reset_queue(netdev_get_tx_queue(priv->netdev, ring->index));
bcm_sysport_tx_clean(priv, ring);
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v14 net-next 09/12] crypto: chtls - Inline TLS record Tx
From: Atul Gupta @ 2018-03-29 19:24 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: davem, herbert, davejwatson, sbrivio, linux-crypto, netdev,
werner, leedom, swise, indranil, ganeshgr
In-Reply-To: <20180329162611.GA9517@bistromath.localdomain>
On 3/29/2018 9:56 PM, Sabrina Dubroca wrote:
> 2018-03-29, 21:27:51 +0530, Atul Gupta wrote:
>> TLS handler for record transmit.
>> Create Inline TLS work request and post to FW.
>> Create Inline TLS record CPLs for hardware
>>
>> Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
>> Signed-off-by: Michael Werner <werner@chelsio.com>
>> ---
> ...
>> +int chtls_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
>> +{
>> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
>> + struct chtls_dev *cdev = csk->cdev;
>> + struct tcp_sock *tp = tcp_sk(sk);
>> + struct sk_buff *skb;
>> + int mss, flags, err;
>> + int recordsz = 0;
>> + int copied = 0;
>> + int hdrlen = 0;
>> + long timeo;
>> +
>> + lock_sock(sk);
>> + flags = msg->msg_flags;
>> + timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
>> +
>> + if (!sk_in_state(sk, TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) {
>> + err = sk_stream_wait_connect(sk, &timeo);
>> + if (err)
>> + goto out_err;
>> + }
>> +
>> + if (sk->sk_prot->sendmsg != chtls_sendmsg) {
> Can that actually happen? If so, how? AFAICT, this function is only
> called when sk->sk_prot has been set to be chtls_cpl_prot.
this is relevant for the tunneling of the active-open path and can be removed for now
>
>> + release_sock(sk);
>> + if (sk->sk_prot->sendmsg)
>> + return sk->sk_prot->sendmsg(sk, msg, size);
>> + else
>> + return sk->sk_socket->ops->sendmsg(sk->sk_socket,
>> + msg, size);
>> + }
^ permalink raw reply
* [PATCH iproute2] json_print: fix print_uint hidden type promotion
From: Kevin Darbyshire-Bryant @ 2018-03-29 19:22 UTC (permalink / raw)
To: netdev; +Cc: Kevin Darbyshire-Bryant
print_int used 'int' type internally, whereas print_uint used 'uint64_t'
These helper functions eventually call vfprintf(fp, fmt, args) which is
a variable argument list function and is dependent upon 'fmt' containing
correct information about the length of the passed arguments.
Unfortunately print_int v print_uint offered no clue to the programmer
that internally passed ints to print_uint were being promoted to 64bits,
thus the format passed in 'fmt' string vs the actual passed integer
could be different lengths. This is even more interesting on big endian
architectures where 'vfprintf' would be looking in the middle of an
int64 type.
print_u/int now stick with native int size.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
---
include/json_print.h | 2 +-
lib/json_print.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/json_print.h b/include/json_print.h
index 2ca7830a..45bc653d 100644
--- a/include/json_print.h
+++ b/include/json_print.h
@@ -56,10 +56,10 @@ void close_json_array(enum output_type type, const char *delim);
print_color_##type_name(t, COLOR_NONE, key, fmt, value); \
}
_PRINT_FUNC(int, int);
+_PRINT_FUNC(uint, unsigned int);
_PRINT_FUNC(bool, bool);
_PRINT_FUNC(null, const char*);
_PRINT_FUNC(string, const char*);
-_PRINT_FUNC(uint, uint64_t);
_PRINT_FUNC(hu, unsigned short);
_PRINT_FUNC(hex, unsigned int);
_PRINT_FUNC(0xhex, unsigned int);
diff --git a/lib/json_print.c b/lib/json_print.c
index 6518ba98..8d54d1d4 100644
--- a/lib/json_print.c
+++ b/lib/json_print.c
@@ -117,8 +117,8 @@ void close_json_array(enum output_type type, const char *str)
} \
}
_PRINT_FUNC(int, int);
+_PRINT_FUNC(uint, unsigned int);
_PRINT_FUNC(hu, unsigned short);
-_PRINT_FUNC(uint, uint64_t);
_PRINT_FUNC(lluint, unsigned long long int);
_PRINT_FUNC(float, double);
#undef _PRINT_FUNC
--
2.14.3 (Apple Git-98)
^ permalink raw reply related
* Re: [PATCH v14 net-next 08/12] crypto : chtls - CPL handler definition
From: Atul Gupta @ 2018-03-29 19:08 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: davem, herbert, davejwatson, sbrivio, linux-crypto, netdev,
werner, leedom, swise, indranil, ganeshgr
In-Reply-To: <20180329162623.GA9805@bistromath.localdomain>
On 3/29/2018 9:56 PM, Sabrina Dubroca wrote:
> 2018-03-29, 21:27:50 +0530, Atul Gupta wrote:
> ...
>> +static void chtls_pass_accept_request(struct sock *sk,
>> + struct sk_buff *skb)
>> +{
> ...
>> + if (chtls_get_module(newsk))
>> + goto reject;
>> + inet_csk_reqsk_queue_added(sk);
>> + reply_skb->sk = newsk;
>> + chtls_install_cpl_ops(newsk);
> Function defined in patch 11, declared in patch 6, and used in patch
> 8. Are you actually listening to the comments we've been sending?
Patch series is broken to make it bisectable, it ensures that existing modules net, cxgb4, chcr compiles fine, since chtls is new module the sequence of patches builds clean by virtue of having Makefile change in the last patch. We have followed a similar approach in the past for new submission of chcr, cxgbit drivers.
>
^ permalink raw reply
* Re: [PATCH net-next 0/9] devlink: Add support for region access
From: Alex Vesker @ 2018-03-29 18:59 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David S. Miller, netdev, Tariq Toukan, Jiri Pirko
In-Reply-To: <20180329171359.GA12150@lunn.ch>
On 3/29/2018 8:13 PM, Andrew Lunn wrote:
> On Thu, Mar 29, 2018 at 07:07:43PM +0300, Alex Vesker wrote:
>> This is a proposal which will allow access to driver defined address
>> regions using devlink. Each device can create its supported address
>> regions and register them. A device which exposes a region will allow
>> access to it using devlink.
>>
>> The suggested implementation will allow exposing regions to the user,
>> reading and dumping snapshots taken from different regions.
>> A snapshot represents a memory image of a region taken by the driver.
>>
>> If a device collects a snapshot of an address region it can be later
>> exposed using devlink region read or dump commands.
>> This functionality allows for future analyses on the snapshots to be
>> done.
> Hi Alex
>
> So the device is in change of making a snapshot? A user cannot
> initiate it?
Hi,
Correct, currently the user cannot initiate saving a snapshot but
as I said in the cover letter, planned support is for dumping "live"
regions.
> Seems like if i'm trying to debug something, i want to take a snapshot
> in the good state, issue the command which breaks things, and then
> take another snapshot. Looking at the diff then gives me an idea what
> happened.
>
>> Show all of the exposed regions with region sizes:
>> $ devlink region show
>> pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2]
> So you have 2Mbytes of snapshot data. Is this held in the device, or
> kernel memory?
This is allocated in devlink, the maximum number of snapshots is set by
the driver.
>> Dump a snapshot:
>> $ devlink region dump pci/0000:00:05.0/fw-health snapshot 1
>> 0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
>> 0000000000000010 0000 0000 ffff ff04 0029 8c00 0028 8cc8
>> 0000000000000020 0016 0bb8 0016 1720 0000 0000 c00f 3ffc
>> 0000000000000030 bada cce5 bada cce5 bada cce5 bada cce5
>>
>> Read a specific part of a snapshot:
>> $ devlink region read pci/0000:00:05.0/fw-health snapshot 1 address 0
>> length 16
>> 0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
> Why a separate command? It seems to be just a subset of dump.
This is useful when debugging values on specific addresses, this also
brings the API one step closer for a read and write API.
>
> Andrew
^ permalink raw reply
* Re: [net-next 1/4] tipc: replace name table service range array with rb tree
From: David Miller @ 2018-03-29 18:46 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1522249103-32714-2-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 28 Mar 2018 16:58:20 +0200
> -/*
> - * tipc_nametbl_publish - add name publication to network name tables
> +/* tipc_nametbl_publish - add service binding to name table
> */
> struct publication *tipc_nametbl_publish(struct net *net, u32 type, u32 lower,
> - u32 upper, u32 scope, u32 port_ref,
> + u32 upper, u32 scope, u32 port,
> u32 key)
> {
> - struct publication *publ;
> - struct sk_buff *buf = NULL;
> - struct tipc_net *tn = net_generic(net, tipc_net_id);
> + struct name_table *nt = tipc_name_table(net);
> + struct tipc_net *tn = tipc_net(net);
> + struct sk_buff *skb = NULL;
> + struct publication *p;
>
> spin_lock_bh(&tn->nametbl_lock);
> - if (tn->nametbl->local_publ_count >= TIPC_MAX_PUBLICATIONS) {
> - pr_warn("Publication failed, local publication limit reached (%u)\n",
> - TIPC_MAX_PUBLICATIONS);
> - spin_unlock_bh(&tn->nametbl_lock);
> - return NULL;
> +
> + if (nt->local_publ_count >= TIPC_MAX_PUBL) {
> + pr_warn("Bind failed, max limit %u reached\n", TIPC_MAX_PUBL);
> + goto exit;
If we goto exit:...
> +exit:
> spin_unlock_bh(&tn->nametbl_lock);
>
> - if (buf)
> - tipc_node_broadcast(net, buf);
> - return publ;
> + if (skb)
> + tipc_node_broadcast(net, skb);
> + return p;
> }
'p' is uninitialized, yet we return it.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: don't fall back to grxfhindir when context was specified
From: John W. Linville @ 2018-03-29 18:40 UTC (permalink / raw)
To: Edward Cree; +Cc: netdev
In-Reply-To: <cb6227a4-0ba8-d45d-b205-85611b4cebba@solarflare.com>
On Mon, Mar 19, 2018 at 04:52:06PM +0000, Edward Cree wrote:
> In do_grfxh(), if rss_context is non-zero, we must not fall back to
> do_grxfhindir() if ETHTOOL_GRSSH fails, for that reads the default RSS
> context and not the one specified.
>
> Fixes: f5d55b967e0c ("ethtool: add support for extra RSS contexts and RSS steering filters")
> Signed-off-by: Edward Cree <ecree@solarflare.com>
LGTM -- queued for next release...
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Fw: [Bug 199233] New: vxlan: hw csum failure
From: Stephen Hemminger @ 2018-03-29 18:39 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 28 Mar 2018 17:08:14 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199233] New: vxlan: hw csum failure
https://bugzilla.kernel.org/show_bug.cgi?id=199233
Bug ID: 199233
Summary: vxlan: hw csum failure
Product: Networking
Version: 2.5
Kernel Version: 4.9.82
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: asilva@wirelessmundi.com
Regression: No
when vxlan is encapsulated with ipsec (libreswan) i see lots of messages with
"hw csum failure".
my setup:
boxA [vxlan100] === ipsec/internet === [vxlan100]boxB
Both box have the same setup running debian stretch:
kernel 4.9.82
libreswan 3.23
iproute 4.9.0
NOTE: not sure if it duplicates issues #111331 and #198025, they seam very
similar... if so please forgive me.
Some errors in dmesg:
[76811.241149] vxlan100: hw csum failure
[76811.242677] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-6-amd64 #1
Debian 4.9.82-1+deb9u3
[76811.242685] Hardware name: AAEON UP-CHT01/UP-CHT01, BIOS UPC1BM0S 06/04/2016
[76811.242696] 0000000000000000 ffffffffa652e074 0000000000000000
ffff9b3b765b2500
[76811.242721] ffffffffa6706c4a ffff9b3b765b2500 ffffc8437fc10a08
0000000000000000
[76811.242738] 0000000000000074 ffffffffa677df2f ffff9b3b76860488
ffff9b3b765b2500
[76811.242756] Call Trace:
[76811.242766] <IRQ>
[76811.242792] [<ffffffffa652e074>] ? dump_stack+0x5c/0x78
[76811.242809] [<ffffffffa6706c4a>] ? __skb_gro_checksum_complete+0x9a/0xa0
[76811.242826] [<ffffffffa677df2f>] ? udp4_gro_receive+0xef/0x2d0
[76811.242839] [<ffffffffa6786418>] ? inet_gro_receive+0x1f8/0x2a0
[76811.242851] [<ffffffffa670a353>] ? dev_gro_receive+0x233/0x3c0
[76811.242864] [<ffffffffa670a513>] ? napi_gro_receive+0x33/0xe0
[76811.242889] [<ffffffffc0a18390>] ? gro_cell_poll+0x50/0x90 [vxlan]
[76811.242900] [<ffffffffa6709fe6>] ? net_rx_action+0x246/0x380
[76811.242915] [<ffffffffa6814dda>] ? __do_softirq+0x10a/0x29e
[76811.242930] [<ffffffffa627d7fe>] ? irq_exit+0xae/0xb0
[76811.242940] [<ffffffffa6813f0f>] ? do_IRQ+0x4f/0xd0
[76811.242952] [<ffffffffa6811c96>] ? common_interrupt+0x96/0x96
[76811.242956] <EOI>
[76811.242975] [<ffffffffa66d44a2>] ? cpuidle_enter_state+0xa2/0x2d0
[76811.242990] [<ffffffffa62ba404>] ? cpu_startup_entry+0x154/0x240
[76811.243006] [<ffffffffa6f3df62>] ? start_kernel+0x44b/0x46b
[76811.243017] [<ffffffffa6f3d120>] ? early_idt_handler_array+0x120/0x120
[76811.243027] [<ffffffffa6f3d408>] ? x86_64_start_kernel+0x14c/0x170
[76812.329058] br2: hw csum failure
[76812.330679] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-6-amd64 #1
Debian 4.9.82-1+deb9u3
[76812.330701] Hardware name: AAEON UP-CHT01/UP-CHT01, BIOS UPC1BM0S 06/04/2016
[76812.330729] 0000000000000000 ffffffffa652e074 ffff9b3b778c2400
ffff9b3b76561000
[76812.330751] ffffffffa66fb712 000000003ca7c358 ffff9b3b778c2400
ffffffffa6781805
[76812.330769] ffffffffa6a99c60 ffff9b3b778c2400 ffffffffa6edbb00
ffff9b3b78f44000
[76812.330787] Call Trace:
[76812.330796] <IRQ>
[76812.330819] [<ffffffffa652e074>] ? dump_stack+0x5c/0x78
[76812.330836] [<ffffffffa66fb712>] ? __skb_checksum_complete+0xb2/0xc0
[76812.330848] [<ffffffffa6781805>] ? icmp_rcv+0xa5/0x3a0
[76812.330879] [<ffffffffa674a853>] ? ip_local_deliver_finish+0x93/0x1c0
[76812.330913] [<ffffffffa674ab1b>] ? ip_local_deliver+0x6b/0xf0
[76812.330952] [<ffffffffa674a7c0>] ? ip_rcv_finish+0x400/0x400
[76812.330984] [<ffffffffa674ae20>] ? ip_rcv+0x280/0x3a0
[76812.330997] [<ffffffffa67fbbd1>] ? packet_rcv+0x41/0x430
[76812.331010] [<ffffffffa67091fd>] ? __netif_receive_skb_core+0x51d/0xa40
[76812.331024] [<ffffffffa62a2064>] ? try_to_wake_up+0x54/0x3c0
[76812.331037] [<ffffffffa670979f>] ? netif_receive_skb_internal+0x2f/0xa0
[76812.331091] [<ffffffffc03a5e9a>] ? xhci_queue_bulk_tx+0x26a/0x940
[xhci_hcd]
[76812.331148] [<ffffffffc0a3b6c2>] ? br_pass_frame_up+0xc2/0x160 [bridge]
[76812.331206] [<ffffffffc0a3b980>] ? br_handle_frame_finish+0x220/0x510
[bridge]
[76812.331235] [<ffffffffa62afa82>] ? enqueue_task_fair+0x82/0x940
[76812.331270] [<ffffffffc0a3bcb0>] ? br_handle_local_finish+0x40/0x40
[bridge]
[76812.331303] [<ffffffffc0a3be1b>] ? br_handle_frame+0x16b/0x2f0 [bridge]
[76812.331390] [<ffffffffc03325ad>] ? usb_hcd_submit_urb+0xad/0xaf0 [usbcore]
[76812.331420] [<ffffffffa66f2d3e>] ? __kmalloc_reserve.isra.35+0x2e/0x80
[76812.331433] [<ffffffffa6708fe8>] ? __netif_receive_skb_core+0x308/0xa40
[76812.331562] [<ffffffffc056ca22>] ? ieee80211_rx_napi+0x2f2/0x9c0 [mac80211]
[76812.331599] [<ffffffffa622e210>] ? recalibrate_cpu_khz+0x10/0x10
[76812.331620] [<ffffffffa670979f>] ? netif_receive_skb_internal+0x2f/0xa0
[76812.331631] [<ffffffffa670a598>] ? napi_gro_receive+0xb8/0xe0
[76812.331652] [<ffffffffc0a18390>] ? gro_cell_poll+0x50/0x90 [vxlan]
[76812.331663] [<ffffffffa6709fe6>] ? net_rx_action+0x246/0x380
[76812.331701] [<ffffffffa6814dda>] ? __do_softirq+0x10a/0x29e
[76812.331726] [<ffffffffa627d7fe>] ? irq_exit+0xae/0xb0
[76812.331736] [<ffffffffa6813f0f>] ? do_IRQ+0x4f/0xd0
[76812.331746] [<ffffffffa6811c96>] ? common_interrupt+0x96/0x96
[76812.331751] <EOI>
[76812.331770] [<ffffffffa66d44a2>] ? cpuidle_enter_state+0xa2/0x2d0
[76812.331812] [<ffffffffa62ba404>] ? cpu_startup_entry+0x154/0x240
[76812.331842] [<ffffffffa6f3df62>] ? start_kernel+0x44b/0x46b
[76812.331854] [<ffffffffa6f3d120>] ? early_idt_handler_array+0x120/0x120
[76812.331864] [<ffffffffa6f3d408>] ? x86_64_start_kernel+0x14c/0x170
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] [net-next] sctp: fix unused lable warning
From: David Miller @ 2018-03-29 18:38 UTC (permalink / raw)
To: arnd; +Cc: vyasevich, nhorman, viro, linux-sctp, netdev, linux-kernel
In-Reply-To: <20180328141512.3083992-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 28 Mar 2018 16:14:56 +0200
> The proc file cleanup left a label possibly unused:
>
> net/sctp/protocol.c: In function 'sctp_defaults_init':
> net/sctp/protocol.c:1304:1: error: label 'err_init_proc' defined but not used [-Werror=unused-label]
>
> This adds an #ifdef around it to match the respective 'goto'.
>
> Fixes: d47d08c8ca05 ("sctp: use proc_remove_subtree()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: cavium: use module_pci_driver to simplify the code
From: David Miller @ 2018-03-29 18:36 UTC (permalink / raw)
To: weiyongjun1
Cc: rad, aleksey.makarov, pombredanne, jglauber, netdev,
kernel-janitors
In-Reply-To: <1522241515-77766-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 28 Mar 2018 12:51:55 +0000
> Use the module_pci_driver() macro to make the code simpler
> by eliminating module_init and module_exit calls.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: return NULL instead of plain integer
From: David Miller @ 2018-03-29 18:36 UTC (permalink / raw)
To: weiyongjun1; +Cc: opendmb, f.fainelli, netdev, kernel-janitors
In-Reply-To: <1522241479-77691-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 28 Mar 2018 12:51:19 +0000
> Fixes the following sparse warning:
>
> drivers/net/ethernet/broadcom/genet/bcmgenet.c:1351:16: warning:
> Using plain integer as NULL pointer
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: hns3: remove unnecessary pci_set_drvdata() and devm_kfree()
From: David Miller @ 2018-03-29 18:35 UTC (permalink / raw)
To: weiyongjun1; +Cc: yisen.zhuang, salil.mehta, netdev, kernel-janitors
In-Reply-To: <1522241461-77556-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 28 Mar 2018 12:51:01 +0000
> The devm_kfree function allocates memory that is released when a
devm_kfree doesn't allocate memory, it frees it.
Your commit log message is confusing at best. I know what you're
trying to say, but a lot of the logic is reversed or hard to
understand.
Thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox