* [RFC PATCH net-next 0/3] net: batched receive in GRO path
From: Edward Cree @ 2019-07-09 19:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
This series listifies part of GRO processing, in a manner which allows those
packets which are not GROed (i.e. for which dev_gro_receive returns
GRO_NORMAL) to be passed on to the listified regular receive path.
dev_gro_receive() itself is not listified, nor the per-protocol GRO
callback, since GRO's need to hold packets on lists under napi->gro_hash
makes keeping the packets on other lists awkward, and since the GRO control
block state of held skbs can refer only to one 'new' skb at a time.
Instead, when napi_frags_finish() handles a GRO_NORMAL result, stash the skb
onto a list in the napi struct, which is received at the end of the napi
poll or when its length exceeds the (new) sysctl net.core.gro_normal_batch.
Unlike my previous design ([1]), this does not require changes in drivers,
and also does not prevent the re-use of napi->skb after GRO_MERGED_FREE or
GRO_DROP.
Performance figures with this series, collected on a back-to-back pair of
Solarflare sfn8522-r2 NICs with 120-second NetPerf tests. In the stats,
sample size n for old and new code is 6 runs each; p is from a Welch t-test.
Tests were run both with GRO enabled and disabled, the latter simulating
uncoalesceable packets (e.g. due to IP or TCP options). The receive side
(which was the device under test) had the NetPerf process pinned to one CPU,
and the device interrupts pinned to a second CPU. CPU utilisation figures
(used in cases of line-rate performance) are summed across all CPUs.
Where not specified (as batch=), net.core.gro_normal_batch was set to 8.
The net-next baseline used for these tests was commit 7d30a7f6424e.
TCP 4 streams, GRO on: all results line rate (9.415Gbps)
net-next: 210.3% cpu
after #1: 181.5% cpu (-13.7%, p=0.031 vs net-next)
after #3: 191.7% cpu (- 8.9%, p=0.102 vs net-next)
TCP 4 streams, GRO off:
after #1: 7.785 Gbps
after #3: 8.387 Gbps (+ 7.7%, p=0.215 vs #1, but note *)
TCP 1 stream, GRO on: all results line rate & ~200% cpu.
TCP 1 stream, GRO off:
after #1: 6.444 Gbps
after #3: 7.363 Gbps (+14.3%, p=0.003 vs #1)
batch=16: 7.199 Gbps
batch= 4: 7.354 Gbps
batch= 0: 5.899 Gbps
TCP 100 RR, GRO off:
net-next: 995.083 us
after #1: 969.167 us (- 2.6%, p=0.204 vs net-next)
after #3: 976.433 us (- 1.9%, p=0.254 vs net-next)
(*) These tests produced a mixture of line-rate and below-line-rate results,
meaning that statistically speaking the results were 'censored' by the
upper bound, and were thus not normally distributed, making a Welch t-test
mathematically invalid. I therefore also calculated estimators according
to [2], which gave the following:
after #1: 8.155 Gbps
after #3: 8.716 Gbps (+ 6.9%, p=0.291 vs #1)
(though my procedure for determining ν wasn't mathematically well-founded
either, so take that p-value with a grain of salt).
Conclusion:
* Patch #1 is a fairly unambiguous improvement.
* Patch #3 has no statistically significant effect when GRO is active.
* Any effect of patch #3 on latency is within statistical noise.
* When GRO is inactive, patch #3 improves bandwidth, though for multiple
streams the effect is smaller (possibly owing to the line-rate limit).
* The optimal batch size for this setup appears to be around 8.
* Setting the batch size to zero gives worse performance than before the
patch; perhaps a static key is needed?
* Drivers which, unlike sfc, pass UDP traffic to GRO would expect to see a
benefit from gaining access to batching.
Notes for future thought: in principle if we passed the napi pointer to
napi_gro_complete(), it could add its superframe skb to napi->rx_list,
rather than immediately netif_receive_skb_internal()ing it. Without that
I'm not sure if there's a possibility of OoO between normal and GROed SKBs
on the same flow.
[1]: http://patchwork.ozlabs.org/cover/997844/
[2]: Cohen 1959, doi: 10.1080/00401706.1959.10489859
Edward Cree (3):
sfc: don't score irq moderation points for GRO
sfc: falcon: don't score irq moderation points for GRO
net: use listified RX for handling GRO_NORMAL skbs
drivers/net/ethernet/sfc/falcon/rx.c | 5 +----
drivers/net/ethernet/sfc/rx.c | 5 +----
include/linux/netdevice.h | 3 +++
net/core/dev.c | 32 ++++++++++++++++++++++++++--
net/core/sysctl_net_core.c | 8 +++++++
5 files changed, 43 insertions(+), 10 deletions(-)
^ permalink raw reply
* RE: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: Parav Pandit @ 2019-07-09 19:21 UTC (permalink / raw)
To: David Miller, jakub.kicinski@netronome.com
Cc: jiri@resnulli.us, netdev@vger.kernel.org, Jiri Pirko,
Saeed Mahameed
In-Reply-To: <20190709.120336.1987683013901804676.davem@davemloft.net>
Hi Dave,
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Wednesday, July 10, 2019 12:34 AM
> To: jakub.kicinski@netronome.com
> Cc: jiri@resnulli.us; Parav Pandit <parav@mellanox.com>;
> netdev@vger.kernel.org; Jiri Pirko <jiri@mellanox.com>; Saeed Mahameed
> <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and
> attributes
>
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Tue, 9 Jul 2019 11:20:58 -0700
>
> > On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
> >> >But I'll leave it to Jiri and Dave to decide if its worth a respin
> >> >:) Functionally I think this is okay.
> >>
> >> I'm happy with the set as it is right now.
> >
> > To be clear, I am happy enough as well. Hence the review tag.
>
> Series applied, thanks everyone.
>
> >> Anyway, if you want your concerns to be addresses, you should write
> >> them to the appropriate code. This list is hard to follow.
> >
> > Sorry, I was trying to be concise.
>
> Jiri et al., if Jakub put forth the time and effort to make the list and give you
> feedback you can put forth the effort to go through the list and address his
> feedback with follow-up patches. You cannot dictate how people give
> feedback to your changes, thank you.
I will be happy to write follow up patches.
mostly in kernel 5.4, I will be adding mdev (mediated device) port flavour as discussed in past.
I will possibly write up follow up patch or two before posting them or have it in that series, as it will extend this devlink code further.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] net: stmmac: Some improvements and a fix
From: David Miller @ 2019-07-09 19:20 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, maxime.ripard, wens, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1562659012.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 9 Jul 2019 10:02:57 +0200
> Some performace improvements (01/03 and 03/03) and a fix (02/03),
> all for -next.
Series applied, thanks Jose.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Add page_pool_destroy() during RX ring cleanup.
From: David Miller @ 2019-07-09 19:18 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, ilias.apalodimas, gospo
In-Reply-To: <1562658607-30048-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 9 Jul 2019 03:50:07 -0400
> Add page_pool_destroy() in bnxt_free_rx_rings() during normal RX ring
> cleanup, as Ilias has informed us that the following commit has been
> merged:
>
> 1da4bbeffe41 ("net: core: page_pool: add user refcnt and reintroduce page_pool_destroy")
>
> The special error handling code to call page_pool_free() can now be
> removed. bnxt_free_rx_rings() will always be called during normal
> shutdown or any error paths.
>
> Fixes: 322b87ca55f2 ("bnxt_en: add page_pool support")
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Andy Gospodarek <gospo@broadcom.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v6 0/4] net/sched: Introduce tc connection tracking
From: David Miller @ 2019-07-09 19:14 UTC (permalink / raw)
To: paulb
Cc: jiri, roid, yossiku, ozsh, marcelo.leitner, netdev, aconole,
wangzhike, ronye, nst-kernel, john.hurley, simon.horman, jpettit
In-Reply-To: <1562657451-20819-1-git-send-email-paulb@mellanox.com>
From: Paul Blakey <paulb@mellanox.com>
Date: Tue, 9 Jul 2019 10:30:47 +0300
> This patch series add connection tracking capabilities in tc sw datapath.
> It does so via a new tc action, called act_ct, and new tc flower classifier matching
> on conntrack state, mark and label.
...
Ok, I applied this, but two things:
1) You owe Cong Wang an explanation, a real detailed one, about the L2
vs L3 design of this feature. I did not see you address his feedback,
but if you did I apologize.
2) Because the MPLS changes went in first, TCA_ID_CT ended up in a
different spot in the enumeration and therefore the value is
different.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface
From: Shannon Nelson @ 2019-07-09 19:13 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev
In-Reply-To: <20190709065620.GJ2282@nanopsycho.orion>
On 7/8/19 11:56 PM, Jiri Pirko wrote:
> Tue, Jul 09, 2019 at 12:58:00AM CEST, snelson@pensando.io wrote:
>> On 7/8/19 1:03 PM, Jiri Pirko wrote:
>>> Mon, Jul 08, 2019 at 09:58:09PM CEST, snelson@pensando.io wrote:
>>>> On 7/8/19 12:34 PM, Jiri Pirko wrote:
>>>>> Mon, Jul 08, 2019 at 09:25:32PM CEST, snelson@pensando.io wrote:
>>>>>> +
>>>>>> +static const struct devlink_ops ionic_dl_ops = {
>>>>>> + .info_get = ionic_dl_info_get,
>>>>>> +};
>>>>>> +
>>>>>> +int ionic_devlink_register(struct ionic *ionic)
>>>>>> +{
>>>>>> + struct devlink *dl;
>>>>>> + struct ionic **ip;
>>>>>> + int err;
>>>>>> +
>>>>>> + dl = devlink_alloc(&ionic_dl_ops, sizeof(struct ionic *));
>>>>> Oups. Something is wrong with your flow. The devlink alloc is allocating
>>>>> the structure that holds private data (per-device data) for you. This is
>>>>> misuse :/
>>>>>
>>>>> You are missing one parent device struct apparently.
>>>>>
>>>>> Oh, I think I see something like it. The unused "struct ionic_devlink".
>>>> If I'm not mistaken, the alloc is only allocating enough for a pointer, not
>>>> the whole per device struct, and a few lines down from here the pointer to
>>>> the new devlink struct is assigned to ionic->dl. This was based on what I
>>>> found in the qed driver's qed_devlink_register(), and it all seems to work.
>>> I'm not saying your code won't work. What I say is that you should have
>>> a struct for device that would be allocated by devlink_alloc()
>> Is there a particular reason why? I appreciate that devlink_alloc() can give
>> you this device specific space, just as alloc_etherdev_mq() can, but is there
> Yes. Devlink manipulates with the whole device. However,
> alloc_etherdev_mq() allocates only net_device. These are 2 different
> things. devlink port relates 1:1 to net_device. However, devlink
> instance can have multiple ports. What I say is do it correctly.
So what you are saying is that anyone who wants to add even the smallest
devlink feature to their driver needs to rework their basic device
memory setup to do it the devlink way. I can see where some folks may
have a problem with this.
>
>
>> a specific reason why this should be used instead of setting up simply a
>> pointer to a space that has already been allocated? There are several
>> drivers that are using it the way I've setup here, which happened to be the
>> first examples I followed - are they doing something different that makes
>> this valid for them?
> Nope. I'll look at that and fix.
>
>
>>> The ionic struct should be associated with devlink_port. That you are
>>> missing too.
>> We don't support any of devlink_port features at this point, just the simple
>> device information.
> No problem, you can still register devlink_port. You don't have to do
> much in order to do so.
Is there any write-up to help guide developers new to devlink in using
the interface correctly? I haven't found much yet, but perhaps I've
missed something. The manpages are somewhat useful in showing what the
user might do, but they really don't help much in guiding the developer
through these details.
sln
^ permalink raw reply
* Reminder: 29 open syzbot bugs in bluetooth subsystem
From: Eric Biggers @ 2019-07-09 19:07 UTC (permalink / raw)
To: linux-bluetooth, netdev, Marcel Holtmann, Johan Hedberg,
David S. Miller, Loic Poulain, Benjamin Herrenschmidt,
Ben Young Tae Kim
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 29 of them as possibly being bugs in the bluetooth subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 29 bugs, 5 were seen in mainline in the last week.
Of these 29 bugs, 4 were bisected to commits from the following people:
Loic Poulain <loic.poulain@intel.com>
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Ben Young Tae Kim <ytkim@qca.qualcomm.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the bluetooth subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: WARNING: refcount bug in kobject_get
Last occurred: 5 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=06c8522152c9325bf0f1a3dc5b33d1b95a47431f
Original thread: https://lkml.kernel.org/lkml/00000000000037743205757f33ac@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b74b8b6e712f33454561@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000037743205757f33ac@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_get
Last occurred: 0 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b52dec65c1aaaec9b3893458b13a3304303de321
Original thread: https://lkml.kernel.org/lkml/000000000000f921ae05757f567c@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 251 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3dcb532381f98c86aeb1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f921ae05757f567c@google.com
--------------------------------------------------------------------------------
Title: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
Last occurred: 0 days ago
Reported: 125 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a
Original thread: https://lkml.kernel.org/lkml/000000000000b7fd51058370d0d9@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 1 reply, 88 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+91fd909b6e62ebe06131@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b7fd51058370d0d9@google.com
--------------------------------------------------------------------------------
Title: WARNING in tty_set_termios
Last occurred: 7 days ago
Reported: 177 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=2410d22f1d8e5984217329dd0884b01d99e3e48d
Original thread: https://lkml.kernel.org/lkml/000000000000bcd434057f4eb905@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 162f812f23bab583f5d514ca0e4df67797ac9cdf
Author: Loic Poulain <loic.poulain@intel.com>
Date: Mon Sep 19 14:29:27 2016 +0000
Bluetooth: hci_uart: Add Marvell support
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a950165cbb86bdd023a4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000bcd434057f4eb905@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in hci_cmd_timeout
Last occurred: 6 days ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=cb23ebfc8f304f510fb717cb783fe8b496c7ffb1
Original thread: https://lkml.kernel.org/lkml/00000000000035c756058848954a@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+19a9f729f05272857487@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000035c756058848954a@google.com
--------------------------------------------------------------------------------
Title: WARNING: refcount bug in kobject_add_internal
Last occurred: 8 days ago
Reported: 8 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=1d709c7eaa63a2bf50387e15d8c0173acc9c9972
Original thread: https://lkml.kernel.org/lkml/0000000000009b1944058ca3e4a8@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 726e41097920a73e4c7c33385dcc0debb1281e18
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Jul 10 00:29:10 2018 +0000
drivers: core: Remove glue dirs from sysfs earlier
The original thread for this bug has received 2 replies; the last was 7 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+32259bb9bc1a487ad206@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 7 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000009b1944058ca3e4a8@google.com
--------------------------------------------------------------------------------
Title: memory leak in get_device_parent
Last occurred: 7 days ago
Reported: 42 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=63d2295ec374cc088d03cc83ad9c7a372a3d02e9
Original thread: https://lkml.kernel.org/lkml/0000000000009b950f0589e804b3@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+02e97e2ad931a981e568@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009b950f0589e804b3@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in rfcomm_dlc_exists
Last occurred: 7 days ago
Reported: 350 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=93ca265e594ab40b3d0e819cf24ba39e75d71fd6
Original thread: https://lkml.kernel.org/lkml/00000000000026c18a0571b9b0de@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+728bead095cef3335bb6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000026c18a0571b9b0de@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in kfree_skb (3)
Last occurred: 16 days ago
Reported: 63 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=db842327c655eab57b1755f661f1ab677d94e0bb
Original thread: https://lkml.kernel.org/lkml/0000000000002f9ef4058848f26d@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+dcb1305dd05699c40640@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002f9ef4058848f26d@google.com
--------------------------------------------------------------------------------
Title: general protection fault in kernfs_add_one
Last occurred: 10 days ago
Reported: 296 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=c10f2ca5722a78c613e9ccd45af7877f5debf0ad
Original thread: https://lkml.kernel.org/lkml/000000000000bf6bd30575fec528@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+db1637662f412ac0d556@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000bf6bd30575fec528@google.com
--------------------------------------------------------------------------------
Title: general protection fault in skb_put
Last occurred: 12 days ago
Reported: 155 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=9abc0fdcdea0effb7b27984dbc1f336155cdad3f
Original thread: https://lkml.kernel.org/lkml/000000000000b9e68e0581142f19@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 4 replies; the last was 118 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+65788f9af9d54844389e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b9e68e0581142f19@google.com
--------------------------------------------------------------------------------
Title: memory leak in h4_recv_buf
Last occurred: 9 days ago
Reported: 15 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=32811c498b542bcef1950494eed33021cc91fd5f
Original thread: https://lkml.kernel.org/lkml/0000000000006b1779058c0cbdda@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006b1779058c0cbdda@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in hci_event_packet
Last occurred: 11 days ago
Reported: 183 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d708485af9edc3af35f3b4d554e827c6c8bf6b0f
Original thread: https://lkml.kernel.org/lkml/000000000000696949057ee26e44@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+cec7a50c412a2c03f8f5@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000696949057ee26e44@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_create_dir_ns
Last occurred: 10 days ago
Reported: 10 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=5124d1a0fef7e16146c1f5ea164ad3ddbdb3bb10
Original thread: https://lkml.kernel.org/lkml/0000000000003ec128058c7624ec@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug has received 2 replies; the last was 21 hours
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+38f5d5cf7ae88c46b11a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 21 hours ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000003ec128058c7624ec@google.com
--------------------------------------------------------------------------------
Title: general protection fault in qca_setup
Last occurred: 148 days ago
Reported: 148 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=62aaa13b8b6bba7f5bca8c0defef34b9a1623135
Original thread: https://lkml.kernel.org/lkml/0000000000002996510581a1487e@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 0ff252c1976da5d80db1377eb39b551931e61826
Author: Ben Young Tae Kim <ytkim@qca.qualcomm.com>
Date: Mon Aug 10 21:24:17 2015 +0000
Bluetooth: hciuart: Add support QCA chipset for UART
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8c0dbf8843bb75efaa05@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002996510581a1487e@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel NULL pointer dereference in hci_uart_set_flow_control
Last occurred: 110 days ago
Reported: 110 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
Original thread: https://lkml.kernel.org/lkml/00000000000017690505849d6b3c@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 162f812f23bab583f5d514ca0e4df67797ac9cdf
Author: Loic Poulain <loic.poulain@intel.com>
Date: Mon Sep 19 14:29:27 2016 +0000
Bluetooth: hci_uart: Add Marvell support
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000017690505849d6b3c@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in hci_event_packet
Last occurred: 73 days ago
Reported: 86 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=fac3d7b25f0e5f3899e4b0dcec32bb3177c95718
Original thread: https://lkml.kernel.org/lkml/0000000000005bb0ae05867271c1@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4918ee47ac82d51de00d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005bb0ae05867271c1@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Write in hci_sock_release
Last occurred: 186 days ago
Reported: 259 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=47befb59c610a69f024db20b927dea80c88fc045
Original thread: https://lkml.kernel.org/lkml/0000000000003692760578e651dd@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 3 replies; the last was 106 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b364ed862aa07c74bc62@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003692760578e651dd@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in bacpy
Last occurred: 68 days ago
Reported: 183 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=3acd1155d48a5acc5d76711568b04926945a6885
Original thread: https://lkml.kernel.org/lkml/0000000000008a1bce057ede3d13@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 6 replies; the last was 111 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+660883c56e2fa65d4497@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008a1bce057ede3d13@google.com
--------------------------------------------------------------------------------
Title: general protection fault in idr_remove
Last occurred: 12 days ago
Reported: 146 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=669469483cd7be33607ad681073484750f6f4c60
Original thread: https://lkml.kernel.org/lkml/00000000000023a7e70581b71894@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3d07f0ffd652af4f49e6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000023a7e70581b71894@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in rfcomm_dlc_free
Last occurred: 61 days ago
Reported: 343 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=97b7072a02091741ffc58f97884ab91565fd97ce
Original thread: https://lkml.kernel.org/lkml/00000000000086f39e057245c3ac@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1f6d4ad860c650c2f215@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000086f39e057245c3ac@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in hci_uart_send_frame
Last occurred: 82 days ago
Reported: 130 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=8aa05f314c1391e788221378935286690d49f482
Original thread: https://lkml.kernel.org/lkml/0000000000001913600582f91f5b@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a8587ba69fc78395d947@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001913600582f91f5b@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in rfcomm_dlc_open (2)
Last occurred: 49 days ago
Reported: 77 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=19321b91aa70d43289d580eb8cbf21e6aecef64f
Original thread: https://lkml.kernel.org/lkml/000000000000876c89058734fc71@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0b0fd24d40f358830891@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000876c89058734fc71@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_activate
Last occurred: 84 days ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=059379fb4ac22ac01d4f2d658aaa6043ff021f42
Original thread: https://lkml.kernel.org/lkml/000000000000fd5e300588491545@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1202f8882e4f4881d814@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fd5e300588491545@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in hci_uart_flush
Last occurred: 148 days ago
Reported: 148 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=9b359a901fde7f3eacc17249cbd613d35612e9aa
Original thread: https://lkml.kernel.org/lkml/0000000000006941590581a15637@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e8cd9d8b4dfedf394390@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006941590581a15637@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in hci_uart_tty_close
Last occurred: 142 days ago
Reported: 141 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=94b6786a5d26079c82301b2ec235ca4717884f4e
Original thread: https://lkml.kernel.org/lkml/0000000000005455bf058225e9c0@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+9fd324c8c2176a6022d3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005455bf058225e9c0@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rfcomm_dlc_exists
Last occurred: 67 days ago
Reported: 63 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=1c4e5c426ab13696077aa6d0c67596e074605ffd
Original thread: https://lkml.kernel.org/lkml/0000000000009c83b005884900cf@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+362be51217ce29d215bc@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009c83b005884900cf@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rfcomm_dlc_open
Last occurred: 68 days ago
Reported: 63 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=05e856115d50ca3d56e1fbea58b612a78877be65
Unfortunately, this bug does not have a reproducer.
For some reason the syzbot dashboard doesn't contain a link to the original
thread for this bug, so my script couldn't provide a link to it in this
reminder. Try searching for the bug title.
--------------------------------------------------------------------------------
Title: WARNING in lockdep_register_key
Last occurred: 113 days ago
Reported: 129 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=5f34c586def64408fb57ee0fd898da67efda36c3
Original thread: https://lkml.kernel.org/lkml/000000000000baab660583172b5c@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+072814ec793ff1946da1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000baab660583172b5c@google.com
^ permalink raw reply
* Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface
From: Shannon Nelson @ 2019-07-09 19:06 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190708182654.72446be5@cakuba.netronome.com>
On 7/8/19 6:26 PM, Jakub Kicinski wrote:
> On Mon, 8 Jul 2019 12:25:32 -0700, Shannon Nelson wrote:
>> Add a devlink interface for access to information that isn't
>> normally available through ethtool or the iplink interface.
>>
>> Example:
>> $ ./devlink -j -p dev info pci/0000:b6:00.0
>> {
>> "info": {
>> "pci/0000:b6:00.0": {
>> "driver": "ionic",
>> "serial_number": "FLM18420073",
>> "versions": {
>> "fixed": {
>> "fw_version": "0.11.0-50",
> Hm. Fixed is for hardware components. Seeing FW version reported as
> fixed seems counter intuitive. You probably want "running"?
Sure.
>
>> "fw_status": "0x1",
> I don't think this is the right interface to report status-like
> information. Perhaps devlink health reporters?
>
>> "fw_heartbeat": "0x716ce",
> Ditto, perhaps best to report it in health stuff?
I haven't dug too far into the health stuff, but on the surface it looks
like a lot of infrastructure for a couple of simple values. I'm tempted
to put them back into debugfs for the moment rather than add that much
more interface goo.
>
>> "asic_type": "0x0",
>> "asic_rev": "0x0"
> These seem like legit "fixed" versions 👍
>
>> }
>> }
>> }
>> }
>> }
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
> Isn't this a new patch? Perhaps you'd be best off upstreaming the
> first batch of support and add features later? It'd be easier on
> reviewers so we don't have to keep re-checking the first 16 patches..
Yes, and I commented about this in v2 notes: in the tension between
trying to address comments, keep the line count down, keep the basic
feature set, and keep the patches self-consistent and simple, I added
this one patch for the devlink goodies that were requested. At least the
total line count went down.
sln
^ permalink raw reply
* Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: David Miller @ 2019-07-09 19:03 UTC (permalink / raw)
To: jakub.kicinski; +Cc: jiri, parav, netdev, jiri, saeedm
In-Reply-To: <20190709112058.7ffe61d3@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 9 Jul 2019 11:20:58 -0700
> On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
>> >But I'll leave it to Jiri and Dave to decide if its worth a respin :)
>> >Functionally I think this is okay.
>>
>> I'm happy with the set as it is right now.
>
> To be clear, I am happy enough as well. Hence the review tag.
Series applied, thanks everyone.
>> Anyway, if you want your concerns to be addresses, you should write
>> them to the appropriate code. This list is hard to follow.
>
> Sorry, I was trying to be concise.
Jiri et al., if Jakub put forth the time and effort to make the list
and give you feedback you can put forth the effort to go through the
list and address his feedback with follow-up patches. You cannot
dictate how people give feedback to your changes, thank you.
^ permalink raw reply
* [PATCH] [net-next] net: dsa: vsc73xx: fix NET_DSA and OF dependencies
From: Arnd Bergmann @ 2019-07-09 18:55 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller
Cc: Arnd Bergmann, Pawel Dembicki, Linus Walleij, netdev,
linux-kernel
The restructuring of the driver got the dependencies wrong: without
CONFIG_NET_DSA we get this build failure:
WARNING: unmet direct dependencies detected for NET_DSA_VITESSE_VSC73XX
Depends on [n]: NETDEVICES [=y] && HAVE_NET_DSA [=y] && OF [=y] && NET_DSA [=n]
Selected by [m]:
- NET_DSA_VITESSE_VSC73XX_PLATFORM [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && HAS_IOMEM [=y]
ERROR: "dsa_unregister_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
ERROR: "dsa_switch_alloc" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
ERROR: "dsa_register_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
Add the appropriate dependencies.
Fixes: 95711cd5f0b4 ("net: dsa: vsc73xx: Split vsc73xx driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/dsa/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index cf9dbd15dd2d..f6232ce8481f 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -111,6 +111,8 @@ config NET_DSA_VITESSE_VSC73XX
config NET_DSA_VITESSE_VSC73XX_SPI
tristate "Vitesse VSC7385/7388/7395/7398 SPI mode support"
+ depends on OF
+ depends on NET_DSA
depends on SPI
select NET_DSA_VITESSE_VSC73XX
---help---
@@ -119,6 +121,8 @@ config NET_DSA_VITESSE_VSC73XX_SPI
config NET_DSA_VITESSE_VSC73XX_PLATFORM
tristate "Vitesse VSC7385/7388/7395/7398 Platform mode support"
+ depends on OF
+ depends on NET_DSA
depends on HAS_IOMEM
select NET_DSA_VITESSE_VSC73XX
---help---
--
2.20.0
^ permalink raw reply related
* Re: WARNING in mark_chain_precision
From: Andrii Nakryiko @ 2019-07-09 18:55 UTC (permalink / raw)
To: syzbot
Cc: aaron.f.brown, Alexei Starovoitov, bpf, Daniel Borkmann,
David S. Miller, hawk, intel-wired-lan, Jakub Kicinski,
jeffrey.t.kirsher, john fastabend, Martin Lau, open list,
Networking, sasha.neftin, Song Liu, syzkaller-bugs, xdp-newbies,
Yonghong Song
In-Reply-To: <000000000000a94981058d37f1a4@google.com>
Original reproducer is almost identical to the one that is fixed by
https://patchwork.ozlabs.org/patch/1129479/.
bpf_prog_free_deferred bug that's undeterministically exposed after
this fix seems to be the cause of a bunch of other bug reports and is
not related to verifier precision tracking.
#syz dup: WARNING in __mark_chain_precision
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Add page_pool_destroy() during RX ring cleanup.
From: Ilias Apalodimas @ 2019-07-09 18:55 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Michael Chan, davem, netdev
In-Reply-To: <20190709163154.GO87269@C02RW35GFVH8.dhcp.broadcom.net>
On Tue, Jul 09, 2019 at 12:31:54PM -0400, Andy Gospodarek wrote:
> On Tue, Jul 09, 2019 at 06:20:57PM +0300, Ilias Apalodimas wrote:
> > Hi,
> >
> > > > Add page_pool_destroy() in bnxt_free_rx_rings() during normal RX ring
> > > > cleanup, as Ilias has informed us that the following commit has been
> > > > merged:
> > > >
> > > > 1da4bbeffe41 ("net: core: page_pool: add user refcnt and reintroduce page_pool_destroy")
> > > >
> > > > The special error handling code to call page_pool_free() can now be
> > > > removed. bnxt_free_rx_rings() will always be called during normal
> > > > shutdown or any error paths.
> > > >
> > > > Fixes: 322b87ca55f2 ("bnxt_en: add page_pool support")
> > > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > Cc: Andy Gospodarek <gospo@broadcom.com>
> > > > Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> > > > ---
> > > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 ++------
> > > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > > index e9d3bd8..2b5b0ab 100644
> > > > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > > @@ -2500,6 +2500,7 @@ static void bnxt_free_rx_rings(struct bnxt *bp)
> > > > if (xdp_rxq_info_is_reg(&rxr->xdp_rxq))
> > > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > > >
> > > > + page_pool_destroy(rxr->page_pool);
> > > > rxr->page_pool = NULL;
> > > >
> > > > kfree(rxr->rx_tpa);
> > > > @@ -2560,19 +2561,14 @@ static int bnxt_alloc_rx_rings(struct bnxt *bp)
> > > > return rc;
> > > >
> > > > rc = xdp_rxq_info_reg(&rxr->xdp_rxq, bp->dev, i);
> > > > - if (rc < 0) {
> > > > - page_pool_free(rxr->page_pool);
> > > > - rxr->page_pool = NULL;
> > > > + if (rc < 0)
> > > > return rc;
> > > > - }
> > > >
> > > > rc = xdp_rxq_info_reg_mem_model(&rxr->xdp_rxq,
> > > > MEM_TYPE_PAGE_POOL,
> > > > rxr->page_pool);
> > > > if (rc) {
> > > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > > > - page_pool_free(rxr->page_pool);
> > > > - rxr->page_pool = NULL;
> > >
> > > Rather than deleting these lines it would also be acceptable to do:
> > >
> > > if (rc) {
> > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > > - page_pool_free(rxr->page_pool);
> > > + page_pool_destroy(rxr->page_pool);
> > > rxr->page_pool = NULL;
> > > return rc;
> > > }
> > >
> > > but anytime there is a failure to bnxt_alloc_rx_rings the driver will
> > > immediately follow it up with a call to bnxt_free_rx_rings, so
> > > page_pool_destroy will be called.
> > >
> > > Thanks for pushing this out so quickly!
> > >
> >
> > I also can't find page_pool_release_page() or page_pool_put_page() called when
> > destroying the pool. Can you try to insmod -> do some traffic -> rmmod ?
> > If there's stale buffers that haven't been unmapped properly you'll get a
> > WARN_ON for them.
>
> I did that test a few times with a few different bpf progs but I do not
> see any WARN messages. Of course this does not mean that the code we
> have is 100% correct.
>
I'll try to have a closer look as well
> Presumably you are talking about one of these messages, right?
>
> 215 /* The distance should not be able to become negative */
> 216 WARN(inflight < 0, "Negative(%d) inflight packet-pages", inflight);
>
> or
>
> 356 /* Drivers should fix this, but only problematic when DMA is used */
> 357 WARN(1, "Still in-flight pages:%d hold:%u released:%u",
> 358 distance, hold_cnt, release_cnt);
>
Yea particularly the second one. There's a counter we increase everytime you
alloc a fresh page which needs to be decresed before freeing the whole pool.
page_pool_release_page will do that for example
>
> > This part was added later on in the API when Jesper fixed in-flight packet
> > handling
Thanks
/Ilias
^ permalink raw reply
* Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: Jakub Kicinski @ 2019-07-09 18:20 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Parav Pandit, netdev, jiri, saeedm
In-Reply-To: <20190709061711.GH2282@nanopsycho.orion>
On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
> >But I'll leave it to Jiri and Dave to decide if its worth a respin :)
> >Functionally I think this is okay.
>
> I'm happy with the set as it is right now.
To be clear, I am happy enough as well. Hence the review tag.
> Anyway, if you want your concerns to be addresses, you should write
> them to the appropriate code. This list is hard to follow.
Sorry, I was trying to be concise.
> >Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [net-next:master 342/422] drivers/net/dsa/qca8k.c:1050:21: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_gpio_request_one'?
From: Christian Lamparter @ 2019-07-09 18:17 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, Netdev
In-Reply-To: <201907081633.62bX7tN5%lkp@intel.com>
(let's hope that the gmail web interface doesn't mangle this too much)
On Mon, Jul 8, 2019 at 10:16 AM kbuild test robot <lkp@intel.com> wrote:
>
> tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next.git master
> head: 61a582be1a668a0c1407a46f779965bfeff88784
> commit: a653f2f538f9d3e2d1f1445f74a47bfdace85c2e [342/422] net: dsa: qca8k: introduce reset via gpio feature
> config: x86_64-randconfig-s2-07081539 (attached as .config)
> compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
> reproduce:
> git checkout a653f2f538f9d3e2d1f1445f74a47bfdace85c2e
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> drivers/net/dsa/qca8k.c: In function 'qca8k_sw_probe':
> >> drivers/net/dsa/qca8k.c:1050:21: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_gpio_request_one'? [-Werror=implicit-function-declaration]
> priv->reset_gpio = devm_gpiod_get_optional(priv->dev, "reset",
> ^~~~~~~~~~~~~~~~~~~~~~~
> devm_gpio_request_one
> >> drivers/net/dsa/qca8k.c:1051:10: error: 'GPIOD_ASIS' undeclared (first use in this function); did you mean 'GPIOF_IN'?
> GPIOD_ASIS);
> ^~~~~~~~~~
> GPIOF_IN
> drivers/net/dsa/qca8k.c:1051:10: note: each undeclared identifier is reported only once for each function it appears in
> >> drivers/net/dsa/qca8k.c:1056:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration]
> gpiod_set_value_cansleep(priv->reset_gpio, 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~
> gpio_set_value_cansleep
> cc1: some warnings being treated as errors
>
> vim +1050 drivers/net/dsa/qca8k.c
Ok, I think that just the
#include <linux/gpio/consumer.h>
is needed. I can make a patch for this no issue. I'll download
net-next over the next days
(currently I'm just on a 3G/EDGE connection, so the 1.53 GiB will have
to wait until the
weekend.)
Regards,
Christian
^ permalink raw reply
* [PATCH bpf-next v8 2/2] selftests/bpf: Add selftests for bpf_perf_event_output
From: Allan Zhang @ 2019-07-09 18:00 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel; +Cc: ast, allanzhang
In-Reply-To: <20190709180005.33406-1-allanzhang@google.com>
From: allanzhang <allanzhang@google.com>
Software event output is only enabled by a few prog types.
This test is to ensure that all supported types are enabled for
bpf_perf_event_output successfully.
Signed-off-by: Allan Zhang <allanzhang@google.com>
---
tools/testing/selftests/bpf/test_verifier.c | 12 ++-
.../selftests/bpf/verifier/event_output.c | 94 +++++++++++++++++++
2 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/verifier/event_output.c
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index c5514daf8865..5e98d7c37eb7 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -50,7 +50,7 @@
#define MAX_INSNS BPF_MAXINSNS
#define MAX_TEST_INSNS 1000000
#define MAX_FIXUPS 8
-#define MAX_NR_MAPS 18
+#define MAX_NR_MAPS 19
#define MAX_TEST_RUNS 8
#define POINTER_VALUE 0xcafe4all
#define TEST_DATA_LEN 64
@@ -84,6 +84,7 @@ struct bpf_test {
int fixup_map_array_wo[MAX_FIXUPS];
int fixup_map_array_small[MAX_FIXUPS];
int fixup_sk_storage_map[MAX_FIXUPS];
+ int fixup_map_event_output[MAX_FIXUPS];
const char *errstr;
const char *errstr_unpriv;
uint32_t retval, retval_unpriv, insn_processed;
@@ -627,6 +628,7 @@ static void do_test_fixup(struct bpf_test *test, enum bpf_prog_type prog_type,
int *fixup_map_array_wo = test->fixup_map_array_wo;
int *fixup_map_array_small = test->fixup_map_array_small;
int *fixup_sk_storage_map = test->fixup_sk_storage_map;
+ int *fixup_map_event_output = test->fixup_map_event_output;
if (test->fill_helper) {
test->fill_insns = calloc(MAX_TEST_INSNS, sizeof(struct bpf_insn));
@@ -788,6 +790,14 @@ static void do_test_fixup(struct bpf_test *test, enum bpf_prog_type prog_type,
fixup_sk_storage_map++;
} while (*fixup_sk_storage_map);
}
+ if (*fixup_map_event_output) {
+ map_fds[18] = __create_map(BPF_MAP_TYPE_PERF_EVENT_ARRAY,
+ sizeof(int), sizeof(int), 1, 0);
+ do {
+ prog[*fixup_map_event_output].imm = map_fds[18];
+ fixup_map_event_output++;
+ } while (*fixup_map_event_output);
+ }
}
static int set_admin(bool admin)
diff --git a/tools/testing/selftests/bpf/verifier/event_output.c b/tools/testing/selftests/bpf/verifier/event_output.c
new file mode 100644
index 000000000000..130553e19eca
--- /dev/null
+++ b/tools/testing/selftests/bpf/verifier/event_output.c
@@ -0,0 +1,94 @@
+/* instructions used to output a skb based software event, produced
+ * from code snippet:
+ * struct TMP {
+ * uint64_t tmp;
+ * } tt;
+ * tt.tmp = 5;
+ * bpf_perf_event_output(skb, &connection_tracking_event_map, 0,
+ * &tt, sizeof(tt));
+ * return 1;
+ *
+ * the bpf assembly from llvm is:
+ * 0: b7 02 00 00 05 00 00 00 r2 = 5
+ * 1: 7b 2a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r2
+ * 2: bf a4 00 00 00 00 00 00 r4 = r10
+ * 3: 07 04 00 00 f8 ff ff ff r4 += -8
+ * 4: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0ll
+ * 6: b7 03 00 00 00 00 00 00 r3 = 0
+ * 7: b7 05 00 00 08 00 00 00 r5 = 8
+ * 8: 85 00 00 00 19 00 00 00 call 25
+ * 9: b7 00 00 00 01 00 00 00 r0 = 1
+ * 10: 95 00 00 00 00 00 00 00 exit
+ *
+ * The reason I put the code here instead of fill_helpers is that map fixup
+ * is against the insns, instead of filled prog.
+ */
+
+#define __PERF_EVENT_INSNS__ \
+ BPF_MOV64_IMM(BPF_REG_2, 5), \
+ BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_2, -8), \
+ BPF_MOV64_REG(BPF_REG_4, BPF_REG_10), \
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, -8), \
+ BPF_LD_MAP_FD(BPF_REG_2, 0), \
+ BPF_MOV64_IMM(BPF_REG_3, 0), \
+ BPF_MOV64_IMM(BPF_REG_5, 8), \
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, \
+ BPF_FUNC_perf_event_output), \
+ BPF_MOV64_IMM(BPF_REG_0, 1), \
+ BPF_EXIT_INSN(),
+{
+ "perfevent for sockops",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SOCK_OPS,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for tc",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for lwt out",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_LWT_OUT,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for xdp",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_XDP,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for socket filter",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for sk_skb",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SK_SKB,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for cgroup skb",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH bpf-next v8 1/2] bpf: Allow bpf_skb_event_output for a few prog types
From: Allan Zhang @ 2019-07-09 18:00 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel; +Cc: ast, allanzhang
In-Reply-To: <20190709180005.33406-1-allanzhang@google.com>
From: allanzhang <allanzhang@google.com>
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
Added socket_filter, cg_skb, sk_skb prog types to generate sw event.
Test bpf code is generated from code snippet:
struct TMP {
uint64_t tmp;
} tt;
tt.tmp = 5;
bpf_perf_event_output(skb, &connection_tracking_event_map, 0,
&tt, sizeof(tt));
return 1;
the bpf assembly from llvm is:
0: b7 02 00 00 05 00 00 00 r2 = 5
1: 7b 2a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r2
2: bf a4 00 00 00 00 00 00 r4 = r10
3: 07 04 00 00 f8 ff ff ff r4 += -8
4: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0ll
6: b7 03 00 00 00 00 00 00 r3 = 0
7: b7 05 00 00 08 00 00 00 r5 = 8
8: 85 00 00 00 19 00 00 00 call 25
9: b7 00 00 00 01 00 00 00 r0 = 1
10: 95 00 00 00 00 00 00 00 exit
Signed-off-by: Allan Zhang <allanzhang@google.com>
---
net/core/filter.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 2014d76e0d2a..b75fcf412628 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -5958,6 +5958,8 @@ sk_filter_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_get_socket_cookie_proto;
case BPF_FUNC_get_socket_uid:
return &bpf_get_socket_uid_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
default:
return bpf_base_func_proto(func_id);
}
@@ -5978,6 +5980,8 @@ cg_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_sk_storage_get_proto;
case BPF_FUNC_sk_storage_delete:
return &bpf_sk_storage_delete_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
#ifdef CONFIG_SOCK_CGROUP_DATA
case BPF_FUNC_skb_cgroup_id:
return &bpf_skb_cgroup_id_proto;
@@ -6226,6 +6230,8 @@ sk_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_sk_redirect_map_proto;
case BPF_FUNC_sk_redirect_hash:
return &bpf_sk_redirect_hash_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
#ifdef CONFIG_INET
case BPF_FUNC_sk_lookup_tcp:
return &bpf_sk_lookup_tcp_proto;
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH bpf-next v8 0/2] bpf: Allow bpf_skb_event_output for more prog types
From: Allan Zhang @ 2019-07-09 18:00 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel; +Cc: ast, Allan Zhang
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
More prog types are enabled to access bpf_skb_event_output in this
patch.
v8 changes:
No actual change, just cc to netdev@vger.kernel.org and
bpf@vger.kernel.org.
v7 patches are acked by Song Liu.
v7 changes:
Reformat from hints by scripts/checkpatch.pl, including Song's comment
on signed-off-by name to captical case in cover letter.
3 of hints are ignored:
1. new file mode.
2. SPDX-License-Identifier for event_output.c since all files under
this dir have no such line.
3. "Macros ... enclosed in parentheses" for macro in event_output.c
due to code's nature.
Change patch 02 subject "bpf:..." to "selftests/bpf:..."
v6 changes:
Fix Signed-off-by, fix fixup map creation.
v5 changes:
Fix typos, reformat comments in event_output.c, move revision history to
cover letter.
v4 changes:
Reformating log message.
v3 changes:
Reformating log message.
v2 changes:
Reformating log message.
Allan Zhang (2):
bpf: Allow bpf_skb_event_output for a few prog types
selftests/bpf: Add selftests for bpf_perf_event_output
net/core/filter.c | 6 ++
tools/testing/selftests/bpf/test_verifier.c | 12 ++-
.../selftests/bpf/verifier/event_output.c | 94 +++++++++++++++++++
3 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/verifier/event_output.c
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: fix bpf_target_sparc check
From: Andrii Nakryiko @ 2019-07-09 17:56 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, Networking
In-Reply-To: <20190709152126.37853-1-iii@linux.ibm.com>
On Tue, Jul 9, 2019 at 8:22 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> bpf_helpers.h fails to compile on sparc: the code should be checking
> for defined(bpf_target_sparc), but checks simply for bpf_target_sparc.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
> tools/testing/selftests/bpf/bpf_helpers.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 5f6f9e7aba2a..a8fea087aa90 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -443,7 +443,7 @@ static int (*bpf_skb_adjust_room)(void *ctx, __s32 len_diff, __u32 mode,
> #ifdef bpf_target_powerpc
While at it, can you please also fix this one?
> #define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ (ip) = (ctx)->link; })
> #define BPF_KRETPROBE_READ_RET_IP BPF_KPROBE_READ_RET_IP
> -#elif bpf_target_sparc
> +#elif defined(bpf_target_sparc)
> #define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ (ip) = PT_REGS_RET(ctx); })
> #define BPF_KRETPROBE_READ_RET_IP BPF_KPROBE_READ_RET_IP
> #else
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCHv2] tools bpftool: Fix json dump crash on powerpc
From: Jiri Olsa @ 2019-07-09 17:53 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Quentin Monnet, Jakub Kicinski, Jiri Olsa, Alexei Starovoitov,
Michael Petlan, netdev, bpf, Martin KaFai Lau
In-Reply-To: <5168f635-a23c-eac3-479d-747e55adfc4c@iogearbox.net>
On Sat, Jul 06, 2019 at 12:00:44AM +0200, Daniel Borkmann wrote:
> On 07/05/2019 07:26 PM, Quentin Monnet wrote:
> > 2019-07-05 10:24 UTC-0700 ~ Jakub Kicinski <jakub.kicinski@netronome.com>
> >> On Fri, 5 Jul 2019 14:10:31 +0200, Jiri Olsa wrote:
> >>> Michael reported crash with by bpf program in json mode on powerpc:
> >>>
> >>> # bpftool prog -p dump jited id 14
> >>> [{
> >>> "name": "0xd00000000a9aa760",
> >>> "insns": [{
> >>> "pc": "0x0",
> >>> "operation": "nop",
> >>> "operands": [null
> >>> ]
> >>> },{
> >>> "pc": "0x4",
> >>> "operation": "nop",
> >>> "operands": [null
> >>> ]
> >>> },{
> >>> "pc": "0x8",
> >>> "operation": "mflr",
> >>> Segmentation fault (core dumped)
> >>>
> >>> The code is assuming char pointers in format, which is not always
> >>> true at least for powerpc. Fixing this by dumping the whole string
> >>> into buffer based on its format.
> >>>
> >>> Please note that libopcodes code does not check return values from
> >>> fprintf callback, but as per Jakub suggestion returning -1 on allocation
> >>> failure so we do the best effort to propagate the error.
> >>>
> >>> Reported-by: Michael Petlan <mpetlan@redhat.com>
> >>> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> >>
> >> Thanks, let me repost all the tags (Quentin, please shout if you're
> >> not ok with this :)):
> >
> > I confirm it's all good for me, thanks :)
> >
> >> Fixes: 107f041212c1 ("tools: bpftool: add JSON output for `bpftool prog dump jited *` command")
> >> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
> >> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> Given merge window coming up, I've applied this to bpf-next, thanks everyone!
>
> P.s.: Jiri, please repost full/proper patch next time instead of inline reply.
will do, thanks
jirka
^ permalink raw reply
* Re: [PATCH v3 bpf-next 0/4] selftests/bpf: fix compiling loop{1,2,3}.c on s390
From: Andrii Nakryiko @ 2019-07-09 17:50 UTC (permalink / raw)
To: Ilya Leoshkevich
Cc: bpf, Networking, Stanislav Fomichev, Y Song, David S. Miller,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190709151809.37539-1-iii@linux.ibm.com>
On Tue, Jul 9, 2019 at 8:18 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> Use PT_REGS_RC(ctx) instead of ctx->rax, which is not present on s390.
>
> This patch series consists of three preparatory commits, which make it
> possible to use PT_REGS_RC in BPF selftests, followed by the actual fix.
>
> Since the last time, I've tested it with x86_64-linux-gnu-,
> aarch64-linux-gnu-, arm-linux-gnueabihf-, mips64el-linux-gnuabi64-,
> powerpc64le-linux-gnu-, s390x-linux-gnu- and sparc64-linux-gnu-
> compilers, and found that I also need to add arm64 support.
>
> Like s390, arm64 exports user_pt_regs instead of struct pt_regs to
> userspace.
>
> I've also made fixes for a few unrelated build problems, which I will
> post separately.
>
> v1->v2: Split into multiple patches.
> v2->v3: Added arm64 support.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>
>
Acked-by: Andrii Nakryiko <andriin@fb.com>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/4] selftests/bpf: make PT_REGS_* work in userspace
From: Andrii Nakryiko @ 2019-07-09 17:48 UTC (permalink / raw)
To: Ilya Leoshkevich
Cc: bpf, Networking, Stanislav Fomichev, Y Song, David S. Miller,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190709151809.37539-4-iii@linux.ibm.com>
On Tue, Jul 9, 2019 at 8:19 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> Right now, on certain architectures, these macros are usable only with
> kernel headers. This patch makes it possible to use them with userspace
> headers and, as a consequence, not only in BPF samples, but also in BPF
> selftests.
>
> On s390, provide the forward declaration of struct pt_regs and cast it
> to user_pt_regs in PT_REGS_* macros. This is necessary, because instead
> of the full struct pt_regs, s390 exposes only its first member
> user_pt_regs to userspace, and bpf_helpers.h is used with both userspace
> (in selftests) and kernel (in samples) headers. It was added in commit
> 466698e654e8 ("s390/bpf: correct broken uapi for
> BPF_PROG_TYPE_PERF_EVENT program type").
>
> Ditto on arm64.
>
> On x86, provide userspace versions of PT_REGS_* macros. Unlike s390 and
> arm64, x86 provides struct pt_regs to both userspace and kernel, however,
> with different member names.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
Just curious, what did you use as a reference for which register
corresponds to which PARM, RET, etc for different archs? I've tried to
look it up the other day, and it wasn't as straightforward to find as
I hoped for, so maybe I'm missing something obvious.
> tools/testing/selftests/bpf/bpf_helpers.h | 61 +++++++++++++++--------
> 1 file changed, 41 insertions(+), 20 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 73071a94769a..212ec564e5c3 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -358,6 +358,7 @@ static int (*bpf_skb_adjust_room)(void *ctx, __s32 len_diff, __u32 mode,
>
> #if defined(bpf_target_x86)
>
> +#ifdef __KERNEL__
> #define PT_REGS_PARM1(x) ((x)->di)
> #define PT_REGS_PARM2(x) ((x)->si)
> #define PT_REGS_PARM3(x) ((x)->dx)
> @@ -368,19 +369,35 @@ static int (*bpf_skb_adjust_room)(void *ctx, __s32 len_diff, __u32 mode,
> #define PT_REGS_RC(x) ((x)->ax)
> #define PT_REGS_SP(x) ((x)->sp)
> #define PT_REGS_IP(x) ((x)->ip)
> +#else
> +#define PT_REGS_PARM1(x) ((x)->rdi)
> +#define PT_REGS_PARM2(x) ((x)->rsi)
> +#define PT_REGS_PARM3(x) ((x)->rdx)
> +#define PT_REGS_PARM4(x) ((x)->rcx)
> +#define PT_REGS_PARM5(x) ((x)->r8)
> +#define PT_REGS_RET(x) ((x)->rsp)
> +#define PT_REGS_FP(x) ((x)->rbp)
> +#define PT_REGS_RC(x) ((x)->rax)
> +#define PT_REGS_SP(x) ((x)->rsp)
> +#define PT_REGS_IP(x) ((x)->rip)
Will this also work for 32-bit x86?
> +#endif
<snip>
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpf, libbpf: add a new API bpf_object__reuse_maps()
From: Andrii Nakryiko @ 2019-07-09 17:40 UTC (permalink / raw)
To: Anton Protopopov
Cc: Daniel Borkmann, Alexei Starovoitov, Martin KaFai Lau, Song Liu,
Yonghong Song, Networking, bpf, open list, Andrii Nakryiko
In-Reply-To: <CAGn_itw=BqWXn7ibg6M7j4r2T5CMo0paBhBoQQv7b+x7D2g2ww@mail.gmail.com>
On Mon, Jul 8, 2019 at 1:37 PM Anton Protopopov
<a.s.protopopov@gmail.com> wrote:
>
> пн, 8 июл. 2019 г. в 13:54, Andrii Nakryiko <andrii.nakryiko@gmail.com>:
> >
> > On Fri, Jul 5, 2019 at 2:53 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > >
> > > On 07/05/2019 10:44 PM, Anton Protopopov wrote:
> > > > Add a new API bpf_object__reuse_maps() which can be used to replace all maps in
> > > > an object by maps pinned to a directory provided in the path argument. Namely,
> > > > each map M in the object will be replaced by a map pinned to path/M.name.
> > > >
> > > > Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
> > > > ---
> > > > tools/lib/bpf/libbpf.c | 34 ++++++++++++++++++++++++++++++++++
> > > > tools/lib/bpf/libbpf.h | 2 ++
> > > > tools/lib/bpf/libbpf.map | 1 +
> > > > 3 files changed, 37 insertions(+)
> > > >
> > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > > index 4907997289e9..84c9e8f7bfd3 100644
> > > > --- a/tools/lib/bpf/libbpf.c
> > > > +++ b/tools/lib/bpf/libbpf.c
> > > > @@ -3144,6 +3144,40 @@ int bpf_object__unpin_maps(struct bpf_object *obj, const char *path)
> > > > return 0;
> > > > }
> > > >
> > > > +int bpf_object__reuse_maps(struct bpf_object *obj, const char *path)
> >
> > As is, bpf_object__reuse_maps() can be easily implemented by user
> > applications, as it's only using public libbpf APIs, so I'm not 100%
> > sure we need to add method like that to libbpf.
>
> The bpf_object__reuse_maps() can definitely be implemented by user
> applications, however, to use it a user also needs to re-implement the
> bpf_prog_load_xattr funciton, so it seemed to me that adding this
> functionality to the library is a better way.
I'm still not convinced. Looking at bpf_prog_load_xattr, I think some
of what it's doing should be part of bpf_object__object_xattr anyway
(all the expected type setting for programs).
Besides that, there isn't much more than just bpf_object__open and
bpf_object__load, to be honest. By doing open and load explicitly,
user gets an opportunity to do whatever adjustment they need: reuse
maps, adjust map sizes, etc. So I think we should improve
bpf_object__open to "guess" program attach types and add map
definition flags to allow reuse declaratively.
>
> >
> > > > +{
> > > > + struct bpf_map *map;
> > > > +
> > > > + if (!obj)
> > > > + return -ENOENT;
> > > > +
> > > > + if (!path)
> > > > + return -EINVAL;
> > > > +
> > > > + bpf_object__for_each_map(map, obj) {
> > > > + int len, err;
> > > > + int pinned_map_fd;
> > > > + char buf[PATH_MAX];
> > >
> > > We'd need to skip the case of bpf_map__is_internal(map) since they are always
> > > recreated for the given object.
> > >
> > > > + len = snprintf(buf, PATH_MAX, "%s/%s", path, bpf_map__name(map));
> > > > + if (len < 0) {
> > > > + return -EINVAL;
> > > > + } else if (len >= PATH_MAX) {
> > > > + return -ENAMETOOLONG;
> > > > + }
> > > > +
> > > > + pinned_map_fd = bpf_obj_get(buf);
> > > > + if (pinned_map_fd < 0)
> > > > + return pinned_map_fd;
> > >
> > > Should we rather have a new map definition attribute that tells to reuse
> > > the map if it's pinned in bpf fs, and if not, we create it and later on
> > > pin it? This is what iproute2 is doing and which we're making use of heavily.
> >
> > I'd like something like that as well. This would play nicely with
> > recently added BTF-defined maps as well.
> >
> > I think it should be not just pin/don't pin flag, but rather pinning
> > strategy, to accommodate various typical strategies of handling maps
> > that are already pinned. So something like this:
> >
> > 1. BPF_PIN_NOTHING - default, don't pin;
> > 2. BPF_PIN_EXCLUSIVE - pin, but if map is already pinned - fail;
> > 3. BPF_PIN_SET - pin; if existing map exists, reset its state to be
> > exact state of object's map;
> > 4. BPF_PIN_MERGE - pin, if map exists, fill in NULL entries only (this
> > is how Cilium is pinning PROG_ARRAY maps, if I understand correctly);
> > 5. BPF_PIN_MERGE_OVERWRITE - pin, if map exists, overwrite non-NULL values.
> >
> > This list is only for illustrative purposes, ideally people that have
> > a lot of experience using pinning for real-world use cases would chime
> > in on what strategies are useful and make sense.
>
> My case was simply to reuse existing maps when reloading a program.
> Does it make sense for you to add only the simplest cases of listed above?
Of course, it's enum, so we can start with few clearly useful ones and
then expand more if we ever have a need. But I think we still need a
bit wider discussion and let people who use pinning to chime in.
>
> Also, libbpf doesn't use standard naming conventions for pinning maps.
We talked about this in another thread related to BTF-defined maps. I
think the way to go with this is to actually define a default pinning
root path, but allow to override it on bpf_object__open, if user needs
a different one.
> Does it make sense to provide a list of already open maps to the
> bpf_prog_load_xattr function as an attribute? In this case a user
> can execute his own policy on pinning, but still will have an option
> to reuse, reset, and merge maps.
As explained above, I don't think there isn't much added value in
bpf_prog_load, so I'd advise to just switch to explicit
bpf_object__open + bpf_object__load and get maximum control and
flexibility.
>
> >
> > > In bpf_object__reuse_maps() bailing out if bpf_obj_get() fails is perhaps
> > > too limiting for a generic API as new version of an object file may contain
> > > new maps which are not yet present in bpf fs at that point.
> > >
> > > > + err = bpf_map__reuse_fd(map, pinned_map_fd);
> > > > + if (err)
> > > > + return err;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > int bpf_object__pin_programs(struct bpf_object *obj, const char *path)
> > > > {
> > > > struct bpf_program *prog;
> > > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > > index d639f47e3110..7fe465a1be76 100644
> > > > --- a/tools/lib/bpf/libbpf.h
> > > > +++ b/tools/lib/bpf/libbpf.h
> > > > @@ -82,6 +82,8 @@ int bpf_object__variable_offset(const struct bpf_object *obj, const char *name,
> > > > LIBBPF_API int bpf_object__pin_maps(struct bpf_object *obj, const char *path);
> > > > LIBBPF_API int bpf_object__unpin_maps(struct bpf_object *obj,
> > > > const char *path);
> > > > +LIBBPF_API int bpf_object__reuse_maps(struct bpf_object *obj,
> > > > + const char *path);
> > > > LIBBPF_API int bpf_object__pin_programs(struct bpf_object *obj,
> > > > const char *path);
> > > > LIBBPF_API int bpf_object__unpin_programs(struct bpf_object *obj,
> > > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > > > index 2c6d835620d2..66a30be6696c 100644
> > > > --- a/tools/lib/bpf/libbpf.map
> > > > +++ b/tools/lib/bpf/libbpf.map
> > > > @@ -172,5 +172,6 @@ LIBBPF_0.0.4 {
> > > > btf_dump__new;
> > > > btf__parse_elf;
> > > > bpf_object__load_xattr;
> > > > + bpf_object__reuse_maps;
> > > > libbpf_num_possible_cpus;
> > > > } LIBBPF_0.0.3;
> > > >
> > >
^ permalink raw reply
* Re: [PATCH iproute2 1/2] Revert "ip6tunnel: fix 'ip -6 {show|change} dev <name>' cmds"
From: Stephen Hemminger @ 2019-07-09 17:39 UTC (permalink / raw)
To: David Ahern; +Cc: Andrea Claudi, netdev, dsahern
In-Reply-To: <2460e246-5032-7804-fbc7-e689cebb4abe@gmail.com>
On Tue, 9 Jul 2019 11:14:00 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 7/9/19 7:16 AM, Andrea Claudi wrote:
> > This reverts commit ba126dcad20e6d0e472586541d78bdd1ac4f1123.
> > It breaks tunnel creation when using 'dev' parameter:
> >
> > $ ip link add type dummy
> > $ ip -6 tunnel add ip6tnl1 mode ip6ip6 remote 2001:db8:ffff:100::2 local 2001:db8:ffff:100::1 hoplimit 1 tclass 0x0 dev dummy0
> > add tunnel "ip6tnl0" failed: File exists
> >
> > dev parameter must be used to specify the device to which
> > the tunnel is binded, and not the tunnel itself.
> >
>
> Stephen: since this reverts a commit in 5.2 it should be in 5.2 as well.
5.2 has been released. Probably not worth doing 5.2.1 for corner case like this.
^ permalink raw reply
* Re: [PATCH iproute2 1/2] Revert "ip6tunnel: fix 'ip -6 {show|change} dev <name>' cmds"
From: Mahesh Bandewar (महेश बंडेवार) @ 2019-07-09 17:31 UTC (permalink / raw)
To: Andrea Claudi; +Cc: linux-netdev, stephen, dsahern
In-Reply-To: <5caaac096e5bbbf88ad3aedcc50ff2451f94105c.1562667648.git.aclaudi@redhat.com>
On Tue, Jul 9, 2019 at 6:16 AM Andrea Claudi <aclaudi@redhat.com> wrote:
>
> This reverts commit ba126dcad20e6d0e472586541d78bdd1ac4f1123.
> It breaks tunnel creation when using 'dev' parameter:
>
> $ ip link add type dummy
> $ ip -6 tunnel add ip6tnl1 mode ip6ip6 remote 2001:db8:ffff:100::2 local 2001:db8:ffff:100::1 hoplimit 1 tclass 0x0 dev dummy0
> add tunnel "ip6tnl0" failed: File exists
>
> dev parameter must be used to specify the device to which
> the tunnel is binded, and not the tunnel itself.
>
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Reviewed-by: Matteo Croce <mcroce@redhat.com>
> Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
> ---
> ip/ip6tunnel.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/ip/ip6tunnel.c b/ip/ip6tunnel.c
> index 56fd3466ed062..999408ed801b1 100644
> --- a/ip/ip6tunnel.c
> +++ b/ip/ip6tunnel.c
> @@ -298,8 +298,6 @@ static int parse_args(int argc, char **argv, int cmd, struct ip6_tnl_parm2 *p)
> p->link = ll_name_to_index(medium);
> if (!p->link)
> return nodev(medium);
> - else
> - strlcpy(p->name, medium, sizeof(p->name));
NACK
I see that ba126dcad20e6d0e472586541d78bdd1ac4f1123 has broke
something but that doesn't mean revert of the original fix is correct
way of fixing it. The original fix is fixing the show and change
command. Shouldn't you try fixing the add command so that all (show,
change, and add) work correctly?
> }
> return 0;
> }
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH net-next iproute2 v1] devlink: Show devlink port number
From: Parav Pandit @ 2019-07-09 17:26 UTC (permalink / raw)
To: netdev; +Cc: stephen, jiri, dsahern, Parav Pandit
In-Reply-To: <20190709163352.20371-1-parav@mellanox.com>
Show devlink port number whenever kernel reports that attribute.
An example output for a physical port.
$ devlink port show
pci/0000:06:00.1/65535: type eth netdev eth1_p1 flavour physical port 1
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
---
Changelog:
v0->v1:
- Declare and assign port_number as two different lines.
---
devlink/devlink.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 559f624e..c5491877 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -2806,6 +2806,12 @@ static void pr_out_port(struct dl *dl, struct nlattr **tb)
pr_out_str(dl, "flavour", port_flavour_name(port_flavour));
}
+ if (tb[DEVLINK_ATTR_PORT_NUMBER]) {
+ uint32_t port_number;
+
+ port_number = mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_NUMBER]);
+ pr_out_uint(dl, "port", port_number);
+ }
if (tb[DEVLINK_ATTR_PORT_SPLIT_GROUP])
pr_out_uint(dl, "split_group",
mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_SPLIT_GROUP]));
--
2.19.2
^ 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