* Re: [PATCH ethtool] ethtool: dump nested registers
From: John W. Linville @ 2019-08-09 16:23 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev, f.fainelli, andrew, davem, linville, cphealy
In-Reply-To: <20190802193455.17126-1-vivien.didelot@gmail.com>
On Fri, Aug 02, 2019 at 03:34:54PM -0400, Vivien Didelot wrote:
> Usually kernel drivers set the regs->len value to the same length as
> info->regdump_len, which was used for the allocation. In case where
> regs->len is smaller than the allocated info->regdump_len length,
> we may assume that the dump contains a nested set of registers.
>
> This becomes handy for kernel drivers to expose registers of an
> underlying network conduit unfortunately not exposed to userspace,
> as found in network switching equipment for example.
>
> This patch adds support for recursing into the dump operation if there
> is enough room for a nested ethtool_drvinfo structure containing a
> valid driver name, followed by a ethtool_regs structure like this:
>
> 0 regs->len info->regdump_len
> v v v
> +--------------+-----------------+--------------+-- - --+
> | ethtool_regs | ethtool_drvinfo | ethtool_regs | |
> +--------------+-----------------+--------------+-- - --+
>
> Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
I wasn't sure what to do with this one, given the disucssion that
followed. But since Dave merged "net: dsa: dump CPU port regs through
master" for net-next, I went ahead and queued this one for the next
release. If that was the wrong thing to do, speak-up now!
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
* Re: [PATCH v2 09/13] net: lpc-enet: fix printk format strings
From: Joe Perches @ 2019-08-09 16:30 UTC (permalink / raw)
To: Arnd Bergmann, soc
Cc: Vladimir Zapolskiy, Sylvain Lemieux, linux-arm-kernel,
linux-kernel, kbuild test robot, David S. Miller, netdev
In-Reply-To: <20190809144043.476786-10-arnd@arndb.de>
On Fri, 2019-08-09 at 16:40 +0200, Arnd Bergmann wrote:
> compile-testing this driver on other architectures showed
> multiple warnings:
>
> drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
> drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
>
> drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
>
> Use format strings that work on all architectures.
[]
> diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
[]
> @@ -1333,13 +1333,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
> pldat->dma_buff_base_p = dma_handle;
>
> netdev_dbg(ndev, "IO address space :%pR\n", res);
> - netdev_dbg(ndev, "IO address size :%d\n", resource_size(res));
> + netdev_dbg(ndev, "IO address size :%zd\n",
> + (size_t)resource_size(res));
Ideally all these would use %zu not %zd
^ permalink raw reply
* AW: tcan4x5x on a Raspberry Pi
From: FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu) @ 2019-08-09 16:46 UTC (permalink / raw)
To: Dan Murphy, linux-can@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <d1badcdb-7635-705d-35d5-448297e8fafa@ti.com>
> Konstantin
>> On 7/29/19 6:19 AM, FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu) wrote:
>> Hi all,
>>
>> I am currently working on a project where I am trying to use the tcan4550 chip with a Raspberry PI 3B.
>> I am struggling to create a working device tree overlay file for the Raspberry Pi.
>> Has anyone here tried this already? I would appreciate any help.
> Are you using the driver from net-next?
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/net/can/m_can
Yes, I am using the driver from net-next.
> DT documentation here
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
I saw this documentation but it didn’t help much (As I said, I don’t have much experience with device trees) . My dts file currently looks like this:
/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709";
fragment@0 {
target = <&spi0>;
__overlay__ {
status = "okay";
spidev@0{
status = "disabled";
};
};
};
fragment@2 {
compatible = "bosch, m_can";
target = <&spi0>;
__overlay__ {
tcan4x5x: tcan4x5x@0 {
compatible = "ti,tcan4x5x";
reg = <0>;
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <10000000>;
bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
data-ready-gpios = <&gpio 23 0>;
device-wake-gpios = <&gpio 24 1>;
};
};
};
};
Checking dmesg I always see these errors:
[ 5.409051] tcan4x5x spi0.0: no clock found
[ 5.409064] tcan4x5x spi0.0: no CAN clock source defined
[ 5.409125] tcan4x5x spi0.0: data-ready gpio not defined
[ 5.409135] tcan4x5x spi0.0: Probe failed, err=-22
I already fixed the clock issue once by doing something like this:
clocks = <&can0_osc>,
<&can0_osc>;
clock-names = "hclk", "cclk";
But that didn’t fix the " data-ready gpio not defined" error.
> I did the development on a BeagleBone Black.
> Dan
> Thanks,
> Konstantin
>
^ permalink raw reply
* [PATCH][net-next] rxrpc: fix uninitialized return value in variable err
From: Colin King @ 2019-08-09 17:02 UTC (permalink / raw)
To: David Howells, David S . Miller, linux-afs, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
An earlier commit removed the setting of err to -ENOMEM so currently
the skb_shinfo(skb)->nr_frags > 16 check returns with an uninitialized
bogus return code. Fix this by setting err to -ENOMEM to restore
the original behaviour.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: b214b2d8f277 ("rxrpc: Don't use skb_cow_data() in rxkad")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/rxrpc/rxkad.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 8b4cddd8b673..c810a7c43b0f 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -248,8 +248,10 @@ static int rxkad_secure_packet_encrypt(const struct rxrpc_call *call,
crypto_skcipher_encrypt(req);
/* we want to encrypt the skbuff in-place */
- if (skb_shinfo(skb)->nr_frags > 16)
+ if (skb_shinfo(skb)->nr_frags > 16) {
+ err = -ENOMEM;
goto out;
+ }
len = data_size + call->conn->size_align - 1;
len &= ~(call->conn->size_align - 1);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 08/17] nfp: no need to check return value of debugfs_create functions
From: Jakub Kicinski @ 2019-08-09 17:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, David S. Miller, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Edwin Peer, Yangtao Li,
Simon Horman, oss-drivers
In-Reply-To: <20190809123108.27065-9-gregkh@linuxfoundation.org>
On Fri, 9 Aug 2019 14:30:59 +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Jesper Dangaard Brouer <hawk@kernel.org>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: Edwin Peer <edwin.peer@netronome.com>
> Cc: Yangtao Li <tiny.windzz@gmail.com>
> Cc: Simon Horman <simon.horman@netronome.com>
> Cc: oss-drivers@netronome.com
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Still
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
:) Thanks!
^ permalink raw reply
* RE: [PATCH v3 net-next 0/3] net: batched receive in GRO path
From: Ioana Ciocoi Radulescu @ 2019-08-09 17:14 UTC (permalink / raw)
To: Edward Cree, David Miller
Cc: netdev, Eric Dumazet, linux-net-drivers@solarflare.com
In-Reply-To: <c6e2474e-2c8a-5881-86bf-59c66bdfc34f@solarflare.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Edward Cree
> Sent: Tuesday, August 6, 2019 4:52 PM
> To: David Miller <davem@davemloft.net>
> Cc: netdev <netdev@vger.kernel.org>; Eric Dumazet
> <eric.dumazet@gmail.com>; linux-net-drivers@solarflare.com
> Subject: [PATCH v3 net-next 0/3] net: batched receive in GRO path
>
> 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.
Hi Edward,
I'm probably missing a lot of context here, but is there a reason
this change targets only the napi_gro_frags() path and not the
napi_gro_receive() one?
I'm trying to understand what drivers that don't call napi_gro_frags()
should do in order to benefit from this batching feature.
Thanks,
Ioana
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: dump nested registers
From: Michal Kubecek @ 2019-08-09 17:21 UTC (permalink / raw)
To: netdev
Cc: John W. Linville, Vivien Didelot, f.fainelli, andrew, davem,
linville, cphealy
In-Reply-To: <20190809162336.GB8016@tuxdriver.com>
On Fri, Aug 09, 2019 at 12:23:36PM -0400, John W. Linville wrote:
> On Fri, Aug 02, 2019 at 03:34:54PM -0400, Vivien Didelot wrote:
> > Usually kernel drivers set the regs->len value to the same length as
> > info->regdump_len, which was used for the allocation. In case where
> > regs->len is smaller than the allocated info->regdump_len length,
> > we may assume that the dump contains a nested set of registers.
> >
> > This becomes handy for kernel drivers to expose registers of an
> > underlying network conduit unfortunately not exposed to userspace,
> > as found in network switching equipment for example.
> >
> > This patch adds support for recursing into the dump operation if there
> > is enough room for a nested ethtool_drvinfo structure containing a
> > valid driver name, followed by a ethtool_regs structure like this:
> >
> > 0 regs->len info->regdump_len
> > v v v
> > +--------------+-----------------+--------------+-- - --+
> > | ethtool_regs | ethtool_drvinfo | ethtool_regs | |
> > +--------------+-----------------+--------------+-- - --+
> >
> > Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
>
> I wasn't sure what to do with this one, given the disucssion that
> followed. But since Dave merged "net: dsa: dump CPU port regs through
> master" for net-next, I went ahead and queued this one for the next
> release. If that was the wrong thing to do, speak-up now!
I'm certainly not happy about it as I'm afraid it's going to give me
a headache one day. But as long as the driver packs CPU port registers
into the device's register dump, it doesn't make sense not to allow
ethtool to parse them. And I'm not sure my objections are strong enough
to request a revert of the kernel part as I'm not sure the idea of
transforming the register dump into a structured format (an actual list
of registers rather than an opaque data block) is feasible at all.
So let's keep the patch in.
Michal
^ permalink raw reply
* KASAN: use-after-free Read in rxrpc_send_keepalive
From: syzbot @ 2019-08-09 17:22 UTC (permalink / raw)
To: davem, dhowells, linux-afs, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: b678c568 Merge tag 'nfs-for-5.3-2' of git://git.linux-nfs...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10ea5e36600000
kernel config: https://syzkaller.appspot.com/x/.config?x=a4c9e9f08e9e8960
dashboard link: https://syzkaller.appspot.com/bug?extid=d850c266e3df14da1d31
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d850c266e3df14da1d31@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in rxrpc_send_keepalive+0x8a2/0x940
net/rxrpc/output.c:635
Read of size 8 at addr ffff888064219698 by task kworker/0:3/11077
CPU: 0 PID: 11077 Comm: kworker/0:3 Not tainted 5.3.0-rc3+ #96
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: krxrpcd rxrpc_peer_keepalive_worker
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x17 mm/kasan/common.c:612
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
rxrpc_send_keepalive+0x8a2/0x940 net/rxrpc/output.c:635
rxrpc_peer_keepalive_dispatch net/rxrpc/peer_event.c:369 [inline]
rxrpc_peer_keepalive_worker+0x7be/0xd02 net/rxrpc/peer_event.c:430
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Allocated by task 20465:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
rxrpc_alloc_local net/rxrpc/local_object.c:79 [inline]
rxrpc_lookup_local+0x64c/0x1b70 net/rxrpc/local_object.c:279
rxrpc_sendmsg+0x379/0x5f0 net/rxrpc/af_rxrpc.c:566
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x3e2/0x920 net/socket.c:2311
__sys_sendmmsg+0x1bf/0x4d0 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg net/socket.c:2439 [inline]
__x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2439
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 0:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
rxrpc_local_rcu+0x62/0x80 net/rxrpc/local_object.c:471
__rcu_reclaim kernel/rcu/rcu.h:222 [inline]
rcu_do_batch kernel/rcu/tree.c:2114 [inline]
rcu_core+0x67f/0x1580 kernel/rcu/tree.c:2314
rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2323
__do_softirq+0x262/0x98c kernel/softirq.c:292
The buggy address belongs to the object at ffff888064219680
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 24 bytes inside of
1024-byte region [ffff888064219680, ffff888064219a80)
The buggy address belongs to the page:
page:ffffea0001908600 refcount:1 mapcount:0 mapping:ffff8880aa400c40
index:0xffff888064218480 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea00025f5a08 ffffea00028fca08 ffff8880aa400c40
raw: ffff888064218480 ffff888064218000 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888064219580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888064219600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff888064219680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888064219700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888064219780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* [PATCH] brcmfmac: remove redundant assignment to pointer hash
From: Colin King @ 2019-08-09 17:22 UTC (permalink / raw)
To: Arend van Spriel, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S . Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The pointer hash is being initialized with a value that is never read
and is being re-assigned a little later on. The assignment is
redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index 8428be8b8d43..e3dd8623be4e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -1468,7 +1468,6 @@ static int brcmf_msgbuf_stats_read(struct seq_file *seq, void *data)
seq_printf(seq, "\nh2d_flowrings: depth %u\n",
BRCMF_H2D_TXFLOWRING_MAX_ITEM);
seq_puts(seq, "Active flowrings:\n");
- hash = msgbuf->flow->hash;
for (i = 0; i < msgbuf->flow->nrofrings; i++) {
if (!msgbuf->flow->rings[i])
continue;
--
2.20.1
^ permalink raw reply related
* Re: KASAN: use-after-free Read in tomoyo_socket_sendmsg_permission
From: Cong Wang @ 2019-08-09 17:29 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Tetsuo Handa, syzbot, syzkaller-bugs, Ralf Baechle, linux-hams,
LKML, netdev
In-Reply-To: <CACT4Y+Y7d29kA1fpS13QvSopknuChPANRc9evxeWiJd-zkyNug@mail.gmail.com>
On Fri, Aug 9, 2019 at 1:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Fri, Aug 9, 2019 at 12:08 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >
> > On 2019/08/09 1:45, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: 107e47cc vrf: make sure skb->data contains ip header to ma..
> > > git tree: net
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=139506d8600000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=4dba67bf8b8c9ad7
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=b91501546ab4037f685f
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > This is not TOMOYO's bug. LSM modules expect that "struct sock" does not go away.
> >
> > Also, another use-after-free (presumably on the same "struct sock") was concurrently
> > inflight at nr_insert_socket() in net/netrom/af_netrom.c . Thus, suspecting netrom's bug.
>
> There is a number of UAFs/refcount bugs in nr sockets lately. Most
> likely it's the same issue them. Most of them were bisected to:
>
> commit c8c8218ec5af5d2598381883acbefbf604e56b5e
> Date: Thu Jun 27 21:30:58 2019 +0000
> netrom: fix a memory leak in nr_rx_frame()
The UAF introduced by this commit has been fixed. There is
another UAF in netrom which exists long before the above commit,
it is not fixed. The last time I looked at it, it seems related to the
state machine used by netrom sockets, so it is not easy.
Thanks,
^ permalink raw reply
* Re: [PATCH v3 net-next 0/3] net: batched receive in GRO path
From: Edward Cree @ 2019-08-09 17:32 UTC (permalink / raw)
To: Ioana Ciocoi Radulescu
Cc: David Miller, netdev, Eric Dumazet,
linux-net-drivers@solarflare.com
In-Reply-To: <AM0PR04MB4994C1A8F32FB6C9A7EE057E94D60@AM0PR04MB4994.eurprd04.prod.outlook.com>
On 09/08/2019 18:14, Ioana Ciocoi Radulescu wrote:
> Hi Edward,
>
> I'm probably missing a lot of context here, but is there a reason
> this change targets only the napi_gro_frags() path and not the
> napi_gro_receive() one?
> I'm trying to understand what drivers that don't call napi_gro_frags()
> should do in order to benefit from this batching feature.
The sfc driver (which is what I have lots of hardware for, so I can
test it) uses napi_gro_frags().
It should be possible to do a similar patch to napi_gro_receive(),
if someone wants to put in the effort of writing and testing it.
However, there are many more callers, so more effort required to
make sure none of them care whether the return value is GRO_DROP
or GRO_NORMAL (since the listified version cannot give that
indication).
Also, the guidance from Eric is that drivers seeking high performance
should use napi_gro_frags(), as this allows GRO to recycle the SKB.
All of this together means I don't plan to submit such a patch; I
would however be happy to review a patch if someone else writes one.
HTH,
-Ed
^ permalink raw reply
* Re: [PATCH v3] tools: bpftool: fix reading from /proc/config.gz
From: Quentin Monnet @ 2019-08-09 17:44 UTC (permalink / raw)
To: Peter Wu, Alexei Starovoitov, Daniel Borkmann
Cc: netdev, Stanislav Fomichev, Jakub Kicinski
In-Reply-To: <20190809003911.7852-1-peter@lekensteyn.nl>
2019-08-09 01:39 UTC+0100 ~ Peter Wu <peter@lekensteyn.nl>
> /proc/config has never existed as far as I can see, but /proc/config.gz
> is present on Arch Linux. Add support for decompressing config.gz using
> zlib which is a mandatory dependency of libelf. Replace existing stdio
> functions with gzFile operations since the latter transparently handles
> uncompressed and gzip-compressed files.
>
> Cc: Quentin Monnet <quentin.monnet@netronome.com>
> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
> ---
> v3: replace popen(gunzip) by linking directly to zlib. Reword commit
> message, remove "Fixes" line. (this patch)
> v2: fix style (reorder vars as reverse xmas tree, rename function,
> braces), fallback to /proc/config.gz if uname() fails.
> https://lkml.kernel.org/r/20190806010702.3303-1-peter@lekensteyn.nl
> v1: https://lkml.kernel.org/r/20190805001541.8096-1-peter@lekensteyn.nl
>
> Hi,
>
> Thanks to Jakub for observing that zlib is already used by libelf, this
> simplifies the patch tremendously as the same API can be used for both
> compressed and uncompressed files. No special case exists anymore for
> fclose/pclose.
>
> According to configure.ac in elfutils, zlib is mandatory, so I just
> assume it to be available. For simplicity I also silently assume lines
> to be less than 4096 characters. If that is not the case, then lines
> will appear truncated, but that should not be an issue for the
> CONFIG_xyz lines that we are scanning for.
>
> Jakub requested the handle leak fix to be posted separately against the
> bpf tree, but since the whole code is rewritten I am not sure if it is
> worth it. It is an unusual edge case: /boot/config-$(uname -r) could be
> opened, but starts with unexpected data.
>
> Kind regards,
> Peter
This version seems good to me, thanks!
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
^ permalink raw reply
* Re: [PATCH net-next] tcp: batch calls to sk_flush_backlog()
From: David Miller @ 2019-08-09 18:07 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, soheil
In-Reply-To: <20190809120447.93591-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 9 Aug 2019 05:04:47 -0700
> Starting from commit d41a69f1d390 ("tcp: make tcp_sendmsg() aware of socket backlog")
> loopback flows got hurt, because for each skb sent, the socket receives an
> immediate ACK and sk_flush_backlog() causes extra work.
>
> Intent was to not let the backlog grow too much, but we went a bit too far.
>
> We can check the backlog every 16 skbs (about 1MB chunks)
> to increase TCP over loopback performance by about 15 %
>
> Note that the call to sk_flush_backlog() handles a single ACK,
> thanks to coalescing done on backlog, but cleans the 16 skbs
> found in rtx rb-tree.
>
> Reported-by: Soheil Hassas Yeganeh <soheil@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: KASAN: null-ptr-deref Write in rxrpc_unuse_local
From: syzbot @ 2019-08-09 18:09 UTC (permalink / raw)
To: davem, dhowells, linux-afs, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000008cf14e058fad0c41@google.com>
syzbot has bisected this bug to:
commit 5c2833938bf50d502586e16b9dad1e3cf88fda6f
Author: David Howells <dhowells@redhat.com>
Date: Wed Jul 31 15:26:05 2019 +0000
rxrpc: Fix local endpoint refcounting
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1519a11c600000
start commit: 87b983f5 Add linux-next specific files for 20190809
git tree: linux-next
final crash: https://syzkaller.appspot.com/x/report.txt?x=1719a11c600000
console output: https://syzkaller.appspot.com/x/log.txt?x=1319a11c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=28eea330e11df0eb
dashboard link: https://syzkaller.appspot.com/bug?extid=20dee719a2e090427b5f
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ceae36600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10ebc40e600000
Reported-by: syzbot+20dee719a2e090427b5f@syzkaller.appspotmail.com
Fixes: 5c2833938bf5 ("rxrpc: Fix local endpoint refcounting")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH net-next 00/10] drop_monitor: Capture dropped packets and metadata
From: Toke Høiland-Jørgensen @ 2019-08-09 18:15 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, nhorman, jiri, dsahern, roopa, nikolay,
jakub.kicinski, andy, f.fainelli, andrew, vivien.didelot, mlxsw,
Ido Schimmel
In-Reply-To: <20190809125418.GB2931@splinter>
Ido Schimmel <idosch@idosch.org> writes:
> On Fri, Aug 09, 2019 at 10:41:47AM +0200, Toke Høiland-Jørgensen wrote:
>> This is great. Are you planning to add the XDP integration as well? :)
>
> Thanks, Toke. From one of your previous replies I got the impression
> that another hook needs to be added in order to catch 'XDP_DROP' as it
> is not covered by the 'xdp_exception' tracepoint which only covers
> 'XDP_ABORTED'. If you can take care of that, I can look into the
> integration with drop monitor.
>
> I kept the XDP case in mind while working on the hardware originated
> drops and I think that extending drop monitor for this use case should
> be relatively straightforward. I will Cc you on the patchset that adds
> monitoring of hardware drops and comment with how I think XDP
> integration should look like.
SGTM, thanks!
-Toke
^ permalink raw reply
* Re: [PATCH v2 09/13] net: lpc-enet: fix printk format strings
From: Arnd Bergmann @ 2019-08-09 18:20 UTC (permalink / raw)
To: Joe Perches
Cc: soc, Vladimir Zapolskiy, Sylvain Lemieux, Linux ARM,
Linux Kernel Mailing List, kbuild test robot, David S. Miller,
Networking
In-Reply-To: <dc0de0cd9a1e24477b20d563199e800b98d933f6.camel@perches.com>
On Fri, Aug 9, 2019 at 6:30 PM Joe Perches <joe@perches.com> wrote:
> > @@ -1333,13 +1333,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
> > pldat->dma_buff_base_p = dma_handle;
> >
> > netdev_dbg(ndev, "IO address space :%pR\n", res);
> > - netdev_dbg(ndev, "IO address size :%d\n", resource_size(res));
> > + netdev_dbg(ndev, "IO address size :%zd\n",
> > + (size_t)resource_size(res));
>
> Ideally all these would use %zu not %zd
Ok, changed now.
Arnd
^ permalink raw reply
* Re: [PATCH v2 00/17] Networking driver debugfs cleanups
From: David Miller @ 2019-08-09 18:20 UTC (permalink / raw)
To: gregkh; +Cc: netdev
In-Reply-To: <20190809123108.27065-1-gregkh@linuxfoundation.org>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 9 Aug 2019 14:30:51 +0200
> v2: fix up build warnings, it's as if I never even built these. Ugh, so
> sorry for wasting people's time with the v1 series. I need to stop
> relying on 0-day as it isn't working well anymore :(
One more try Greg:
drivers/net/wimax/i2400m/debugfs.c: In function ‘i2400m_debugfs_add’:
drivers/net/wimax/i2400m/debugfs.c:192:17: warning: unused variable ‘dev’ [-Wunused-variable]
struct device *dev = i2400m_dev(i2400m);
^~~
^ permalink raw reply
* Re: [PATCH v3 04/14] net: phy: adin: add {write,read}_mmd hooks
From: Heiner Kallweit @ 2019-08-09 18:21 UTC (permalink / raw)
To: Alexandru Ardelean, netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, andrew
In-Reply-To: <20190809133552.21597-5-alexandru.ardelean@analog.com>
On 09.08.2019 15:35, Alexandru Ardelean wrote:
> Both ADIN1200 & ADIN1300 support Clause 45 access for some registers.
> The Extended Management Interface (EMI) registers are accessible via both
> Clause 45 (at register MDIO_MMD_VEND1) and using Clause 22.
>
> However, the Clause 22 access for MMD regs differs from the standard one
> defined by 802.3. The ADIN PHYs use registers ExtRegPtr (0x0010) and
> ExtRegData (0x0011) to access Clause 45 & EMI registers.
>
> The indirect access is done via the following mechanism (for both R/W):
> 1. Write the address of the register in the ExtRegPtr
> 2. Read/write the value of the register (written at ExtRegPtr)
>
> This mechanism is needed to manage configuration of chip settings and to
> access EEE registers (via Clause 22).
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> drivers/net/phy/adin.c | 46 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> index 91ff26d08fd5..8973ad819b93 100644
> --- a/drivers/net/phy/adin.c
> +++ b/drivers/net/phy/adin.c
> @@ -14,6 +14,9 @@
> #define PHY_ID_ADIN1200 0x0283bc20
> #define PHY_ID_ADIN1300 0x0283bc30
>
> +#define ADIN1300_MII_EXT_REG_PTR 0x0010
> +#define ADIN1300_MII_EXT_REG_DATA 0x0011
> +
> #define ADIN1300_INT_MASK_REG 0x0018
> #define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
> #define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
> @@ -53,6 +56,45 @@ static int adin_phy_config_intr(struct phy_device *phydev)
> ADIN1300_INT_MASK_EN);
> }
>
> +static int adin_read_mmd(struct phy_device *phydev, int devad, u16 regnum)
> +{
> + struct mii_bus *bus = phydev->mdio.bus;
> + int phy_addr = phydev->mdio.addr;
> + int err;
> +
> + if (phydev->is_c45) {
Similar to what we discussed regarding feature detection:
Flag is_c45 shouldn't be set with these PHY's, therefore this is dead code.
> + u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
> +
> + return __mdiobus_read(bus, phy_addr, addr);
> + }
> +
> + err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR, regnum);
> + if (err)
> + return err;
> +
> + return __mdiobus_read(bus, phy_addr, ADIN1300_MII_EXT_REG_DATA);
> +}
> +
> +static int adin_write_mmd(struct phy_device *phydev, int devad, u16 regnum,
> + u16 val)
> +{
> + struct mii_bus *bus = phydev->mdio.bus;
> + int phy_addr = phydev->mdio.addr;
> + int err;
> +
> + if (phydev->is_c45) {
> + u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
> +
> + return __mdiobus_write(bus, phy_addr, addr, val);
> + }
> +
> + err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR, regnum);
> + if (err)
> + return err;
> +
> + return __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_DATA, val);
> +}
> +
> static struct phy_driver adin_driver[] = {
> {
> PHY_ID_MATCH_MODEL(PHY_ID_ADIN1200),
> @@ -64,6 +106,8 @@ static struct phy_driver adin_driver[] = {
> .config_intr = adin_phy_config_intr,
> .resume = genphy_resume,
> .suspend = genphy_suspend,
> + .read_mmd = adin_read_mmd,
> + .write_mmd = adin_write_mmd,
> },
> {
> PHY_ID_MATCH_MODEL(PHY_ID_ADIN1300),
> @@ -75,6 +119,8 @@ static struct phy_driver adin_driver[] = {
> .config_intr = adin_phy_config_intr,
> .resume = genphy_resume,
> .suspend = genphy_suspend,
> + .read_mmd = adin_read_mmd,
> + .write_mmd = adin_write_mmd,
> },
> };
>
>
^ permalink raw reply
* Re: [PATCH v3 03/14] net: phy: adin: add support for interrupts
From: Heiner Kallweit @ 2019-08-09 18:19 UTC (permalink / raw)
To: Alexandru Ardelean, netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, andrew
In-Reply-To: <20190809133552.21597-4-alexandru.ardelean@analog.com>
On 09.08.2019 15:35, Alexandru Ardelean wrote:
> This change adds support for enabling PHY interrupts that can be used by
> the PHY framework to get signal for link/speed/auto-negotiation changes.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> drivers/net/phy/adin.c | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> index fc0148ba4b94..91ff26d08fd5 100644
> --- a/drivers/net/phy/adin.c
> +++ b/drivers/net/phy/adin.c
> @@ -14,11 +14,45 @@
> #define PHY_ID_ADIN1200 0x0283bc20
> #define PHY_ID_ADIN1300 0x0283bc30
>
> +#define ADIN1300_INT_MASK_REG 0x0018
> +#define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
> +#define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
> +#define ADIN1300_INT_ANEG_PAGE_RX_EN BIT(6)
> +#define ADIN1300_INT_IDLE_ERR_CNT_EN BIT(5)
> +#define ADIN1300_INT_MAC_FIFO_OU_EN BIT(4)
> +#define ADIN1300_INT_RX_STAT_CHNG_EN BIT(3)
> +#define ADIN1300_INT_LINK_STAT_CHNG_EN BIT(2)
> +#define ADIN1300_INT_SPEED_CHNG_EN BIT(1)
> +#define ADIN1300_INT_HW_IRQ_EN BIT(0)
> +#define ADIN1300_INT_MASK_EN \
> + (ADIN1300_INT_ANEG_STAT_CHNG_EN | ADIN1300_INT_ANEG_PAGE_RX_EN | \
> + ADIN1300_INT_LINK_STAT_CHNG_EN | ADIN1300_INT_SPEED_CHNG_EN | \
> + ADIN1300_INT_HW_IRQ_EN)
phylib only needs the link status change interrupt. It shouldn't hurt
if enable more interrupt sources, but it's not needed.
> +#define ADIN1300_INT_STATUS_REG 0x0019
> +
> static int adin_config_init(struct phy_device *phydev)
> {
> return genphy_config_init(phydev);
> }
>
> +static int adin_phy_ack_intr(struct phy_device *phydev)
> +{
> + /* Clear pending interrupts */
> + int rc = phy_read(phydev, ADIN1300_INT_STATUS_REG);
> +
> + return rc < 0 ? rc : 0;
> +}
> +
> +static int adin_phy_config_intr(struct phy_device *phydev)
> +{
> + if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
> + return phy_set_bits(phydev, ADIN1300_INT_MASK_REG,
> + ADIN1300_INT_MASK_EN);
> +
> + return phy_clear_bits(phydev, ADIN1300_INT_MASK_REG,
> + ADIN1300_INT_MASK_EN);
> +}
> +
> static struct phy_driver adin_driver[] = {
> {
> PHY_ID_MATCH_MODEL(PHY_ID_ADIN1200),
> @@ -26,6 +60,8 @@ static struct phy_driver adin_driver[] = {
> .config_init = adin_config_init,
> .config_aneg = genphy_config_aneg,
> .read_status = genphy_read_status,
> + .ack_interrupt = adin_phy_ack_intr,
> + .config_intr = adin_phy_config_intr,
> .resume = genphy_resume,
> .suspend = genphy_suspend,
> },
> @@ -35,6 +71,8 @@ static struct phy_driver adin_driver[] = {
> .config_init = adin_config_init,
> .config_aneg = genphy_config_aneg,
> .read_status = genphy_read_status,
> + .ack_interrupt = adin_phy_ack_intr,
> + .config_intr = adin_phy_config_intr,
> .resume = genphy_resume,
> .suspend = genphy_suspend,
> },
>
^ permalink raw reply
* Re: [patch net-next] devlink: remove pointless data_len arg from region snapshot create
From: David Miller @ 2019-08-09 18:22 UTC (permalink / raw)
To: jiri; +Cc: netdev, tariqt, valex, mlxsw
In-Reply-To: <20190809132715.24282-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 9 Aug 2019 15:27:15 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> The size of the snapshot has to be the same as the size of the region,
> therefore no need to pass it again during snapshot creation. Remove the
> arg and use region->size instead.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/2] rxrpc: Fixes
From: David Miller @ 2019-08-09 18:27 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <156536674651.17478.15139844428920800280.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Fri, 09 Aug 2019 17:05:46 +0100
> Here's a couple of fixes for rxrpc:
>
> (1) Fix refcounting of the local endpoint.
>
> (2) Don't calculate or report packet skew information. This has been
> obsolete since AFS 3.1 and so is a waste of resources.
>
> The patches are tagged here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-fixes-20190809
Pulled, thanks David.
^ permalink raw reply
* [net-next 00/15][pull request] 100GbE Intel Wired LAN Driver Updates 2019-08-09
From: Jeff Kirsher @ 2019-08-09 18:31 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to ice driver only.
Henry adds support to query/add queues or channels on a VSI via ethtool
operations.
Brett fixes the detection of a hung transmit ring by checking the
software based tail (next_to_use) to determine if there is pending work.
Updates the driver to assume that using more than one receive queue per
receive ring container is a rare case, so use unlikely() in the case
were we actually need to divide our budget for multiple queues. Fixed
an issue where the write back on ITR bit was not being set when
interrupts are disabled, which was causing only write backs when polling
only when a cache line is filled. Cleans up unnecessary wait times
during VF bring up and reset paths. Increased the mailbox size for
receive queues that are used to communicate with VFs to accommodate the
large number of VFs that the driver can support.
Akeem restructures the initialization flows for VFs, including how VFs
are configured and resources allocated to improve flows so that when we
clean up resources, we do not try to free resources that were never
allocated. Organizes code to ensure that VF specific code is located in
the SR-IOV specific file.
Paul fixes an issue when setting the pause parameter which was
incorrectly blocking users from changing receive or transmit pause
settings. Ensure register access for MSIX vector index is only done in
the PF space and not absolute device space.
Usha fixes a potential kernel hang in the DCB rebuild path when in CEE
mode, where the ETS recommended DCB configuration is not being set or
set correctly.
Mitch updates the driver to process all receive descriptors, regardless
of the size of the associated data.
Tony fixes and issue during the reset/rebuild path of a PF VSI where we
were assuming that the PF VSI was always to be enabled, which can
attempt to bring up a PF VSI on a downed interface which can lead to
various crashes.
Pawel fixes up variable definitions to match the type of data being
stored.
The following are changes since commit fcc32a21655e26d30c746b4828b33a5fd4ccfb11:
liquidio: Use pcie_flr() instead of reimplementing it
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 100GbE
Akeem G Abodunrin (2):
ice: Restructure VFs initialization flows
ice: Move VF resources definition to SR-IOV specific file
Brett Creeley (6):
ice: Use the software based tail when checking for hung Tx ring
ice: Assume that more than one Rx queue is rare in ice_napi_poll
ice: Set WB_ON_ITR when we don't re-enable interrupts
ice: Reduce wait times during VF bringup/reset
ice: Increase size of Mailbox receive queue for many VFs
ice: improve print for VF's when adding/deleting MAC filters
Henry Tieman (1):
ice: Implement ethtool ops for channels
Mitch Williams (1):
ice: allow empty Rx descriptors
Paul Greenwalt (2):
ice: fix set pause param autoneg check
ice: update GLINT_DYN_CTL and GLINT_VECT2FUNC register access
Pawel Kaminski (1):
ice: Change type for queue counts
Tony Nguyen (1):
ice: Do not always bring up PF VSI in ice_ena_vsi()
Usha Ketineni (1):
ice: Fix kernel hang with DCB reset in CEE mode
drivers/net/ethernet/intel/ice/ice.h | 18 +-
drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 158 +++++++++++-------
drivers/net/ethernet/intel/ice/ice_dcb_lib.h | 2 +
drivers/net/ethernet/intel/ice/ice_ethtool.c | 113 ++++++++++++-
.../net/ethernet/intel/ice/ice_hw_autogen.h | 3 +
drivers/net/ethernet/intel/ice/ice_lib.c | 52 ++++--
drivers/net/ethernet/intel/ice/ice_lib.h | 2 +-
drivers/net/ethernet/intel/ice/ice_main.c | 103 +++++++++++-
drivers/net/ethernet/intel/ice/ice_txrx.c | 84 +++++++++-
drivers/net/ethernet/intel/ice/ice_txrx.h | 13 ++
.../net/ethernet/intel/ice/ice_virtchnl_pf.c | 148 +++++++++-------
.../net/ethernet/intel/ice/ice_virtchnl_pf.h | 20 ++-
12 files changed, 555 insertions(+), 161 deletions(-)
--
2.21.0
^ permalink raw reply
* [net-next 03/15] ice: Assume that more than one Rx queue is rare in ice_napi_poll
From: Jeff Kirsher @ 2019-08-09 18:31 UTC (permalink / raw)
To: davem; +Cc: Brett Creeley, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190809183139.30871-1-jeffrey.t.kirsher@intel.com>
From: Brett Creeley <brett.creeley@intel.com>
Currently we divide budget by the number of Rx queues per Rx ring
container in ice_napi_poll even if there is only 1. This is an
unnecessary divide for the normal case of 1 Rx ring per Rx ring
container. Fix this by using an unlikely() call in the case where we
actually need to divide.
Also, we will always set budget_per_ring even if there are no Rx rings
in the Rx ring container so we don't need to initialize it to 0.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_txrx.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index 9234fd203929..837d6ae2f33b 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -1414,8 +1414,8 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
container_of(napi, struct ice_q_vector, napi);
struct ice_vsi *vsi = q_vector->vsi;
bool clean_complete = true;
- int budget_per_ring = 0;
struct ice_ring *ring;
+ int budget_per_ring;
int work_done = 0;
/* Since the actual Tx work is minimal, we can give the Tx a larger
@@ -1429,11 +1429,16 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
if (budget <= 0)
return budget;
- /* We attempt to distribute budget to each Rx queue fairly, but don't
- * allow the budget to go below 1 because that would exit polling early.
- */
- if (q_vector->num_ring_rx)
+ /* normally we have 1 Rx ring per q_vector */
+ if (unlikely(q_vector->num_ring_rx > 1))
+ /* We attempt to distribute budget to each Rx queue fairly, but
+ * don't allow the budget to go below 1 because that would exit
+ * polling early.
+ */
budget_per_ring = max(budget / q_vector->num_ring_rx, 1);
+ else
+ /* Max of 1 Rx ring in this q_vector so give it the budget */
+ budget_per_ring = budget;
ice_for_each_ring(ring, q_vector->rx) {
int cleaned;
--
2.21.0
^ permalink raw reply related
* [net-next 01/15] ice: Implement ethtool ops for channels
From: Jeff Kirsher @ 2019-08-09 18:31 UTC (permalink / raw)
To: davem
Cc: Henry Tieman, netdev, nhorman, sassmann, Tony Nguyen,
Andrew Bowers, Jeff Kirsher
In-Reply-To: <20190809183139.30871-1-jeffrey.t.kirsher@intel.com>
From: Henry Tieman <henry.w.tieman@intel.com>
Add code to query and set the number of queues on the primary
VSI for a PF. This is accessed from the 'ethtool -l' and 'ethtool -L'
commands, respectively.
Signed-off-by: Henry Tieman <henry.w.tieman@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice.h | 4 +
drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 9 +-
drivers/net/ethernet/intel/ice/ice_dcb_lib.h | 2 +
drivers/net/ethernet/intel/ice/ice_ethtool.c | 85 ++++++++++++++++++
drivers/net/ethernet/intel/ice/ice_lib.c | 52 ++++++++---
drivers/net/ethernet/intel/ice/ice_lib.h | 2 +-
drivers/net/ethernet/intel/ice/ice_main.c | 91 +++++++++++++++++++-
7 files changed, 230 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index 794d97460fc7..07950ac4869f 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -298,6 +298,8 @@ struct ice_vsi {
u16 num_txq; /* Used Tx queues */
u16 alloc_rxq; /* Allocated Rx queues */
u16 num_rxq; /* Used Rx queues */
+ u16 req_txq; /* User requested Tx queues */
+ u16 req_rxq; /* User requested Rx queues */
u16 num_rx_desc;
u16 num_tx_desc;
struct ice_tc_cfg tc_cfg;
@@ -455,6 +457,7 @@ ice_find_vsi_by_type(struct ice_pf *pf, enum ice_vsi_type type)
int ice_vsi_setup_tx_rings(struct ice_vsi *vsi);
int ice_vsi_setup_rx_rings(struct ice_vsi *vsi);
void ice_set_ethtool_ops(struct net_device *netdev);
+int ice_vsi_recfg_qs(struct ice_vsi *vsi, int new_rx, int new_tx);
int ice_up(struct ice_vsi *vsi);
int ice_down(struct ice_vsi *vsi);
int ice_vsi_cfg(struct ice_vsi *vsi);
@@ -462,6 +465,7 @@ struct ice_vsi *ice_lb_vsi_setup(struct ice_pf *pf, struct ice_port_info *pi);
int ice_set_rss(struct ice_vsi *vsi, u8 *seed, u8 *lut, u16 lut_size);
int ice_get_rss(struct ice_vsi *vsi, u8 *seed, u8 *lut, u16 lut_size);
void ice_fill_rss_lut(u8 *lut, u16 rss_table_size, u16 rss_size);
+int ice_schedule_reset(struct ice_pf *pf, enum ice_reset_req reset);
void ice_print_link_msg(struct ice_vsi *vsi, bool isup);
#ifdef CONFIG_DCB
int ice_pf_ena_all_vsi(struct ice_pf *pf, bool locked);
diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
index fe88b127ca42..f80628a13f2a 100644
--- a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
@@ -85,11 +85,16 @@ void ice_vsi_cfg_dcb_rings(struct ice_vsi *vsi)
break;
qoffset = vsi->tc_cfg.tc_info[n].qoffset;
+
qcount = vsi->tc_cfg.tc_info[n].qcount_tx;
for (i = qoffset; i < (qoffset + qcount); i++) {
tx_ring = vsi->tx_rings[i];
- rx_ring = vsi->rx_rings[i];
tx_ring->dcb_tc = n;
+ }
+
+ qcount = vsi->tc_cfg.tc_info[n].qcount_rx;
+ for (i = qoffset; i < (qoffset + qcount); i++) {
+ rx_ring = vsi->rx_rings[i];
rx_ring->dcb_tc = n;
}
}
@@ -103,7 +108,7 @@ void ice_vsi_cfg_dcb_rings(struct ice_vsi *vsi)
* calling this function. Reconfiguring DCB based on
* local_dcbx_cfg.
*/
-static void ice_pf_dcb_recfg(struct ice_pf *pf)
+void ice_pf_dcb_recfg(struct ice_pf *pf)
{
struct ice_dcbx_cfg *dcbcfg = &pf->hw.port_info->local_dcbx_cfg;
u8 tc_map = 0;
diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_lib.h b/drivers/net/ethernet/intel/ice/ice_dcb_lib.h
index 819081053ff5..be2ab6f20b21 100644
--- a/drivers/net/ethernet/intel/ice/ice_dcb_lib.h
+++ b/drivers/net/ethernet/intel/ice/ice_dcb_lib.h
@@ -13,6 +13,7 @@
void ice_dcb_rebuild(struct ice_pf *pf);
u8 ice_dcb_get_ena_tc(struct ice_dcbx_cfg *dcbcfg);
u8 ice_dcb_get_num_tc(struct ice_dcbx_cfg *dcbcfg);
+void ice_pf_dcb_recfg(struct ice_pf *pf);
void ice_vsi_cfg_dcb_rings(struct ice_vsi *vsi);
int ice_init_pf_dcb(struct ice_pf *pf, bool locked);
void ice_update_dcb_stats(struct ice_pf *pf);
@@ -55,6 +56,7 @@ ice_tx_prepare_vlan_flags_dcb(struct ice_ring __always_unused *tx_ring,
}
#define ice_update_dcb_stats(pf) do {} while (0)
+#define ice_pf_dcb_recfg(pf) do {} while (0)
#define ice_vsi_cfg_dcb_rings(vsi) do {} while (0)
#define ice_dcb_process_lldp_set_mib_change(pf, event) do {} while (0)
#define ice_set_cgd_num(tlan_ctx, ring) do {} while (0)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index d3ba535bd65a..1fe048cfb737 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -3083,6 +3083,89 @@ ice_set_rxfh(struct net_device *netdev, const u32 *indir, const u8 *key,
return 0;
}
+/**
+ * ice_get_max_txq - return the maximum number of Tx queues for in a PF
+ * @pf: PF structure
+ */
+static int ice_get_max_txq(struct ice_pf *pf)
+{
+ return min_t(int, num_online_cpus(),
+ pf->hw.func_caps.common_cap.num_txq);
+}
+
+/**
+ * ice_get_max_rxq - return the maximum number of Rx queues for in a PF
+ * @pf: PF structure
+ */
+static int ice_get_max_rxq(struct ice_pf *pf)
+{
+ return min_t(int, num_online_cpus(),
+ pf->hw.func_caps.common_cap.num_rxq);
+}
+
+/**
+ * ice_get_channels - get the current and max supported channels
+ * @dev: network interface device structure
+ * @ch: ethtool channel data structure
+ */
+static void
+ice_get_channels(struct net_device *dev, struct ethtool_channels *ch)
+{
+ struct ice_netdev_priv *np = netdev_priv(dev);
+ struct ice_vsi *vsi = np->vsi;
+ struct ice_pf *pf = vsi->back;
+
+ /* check to see if VSI is active */
+ if (test_bit(__ICE_DOWN, vsi->state))
+ return;
+
+ /* report maximum channels */
+ ch->max_rx = ice_get_max_rxq(pf);
+ ch->max_tx = ice_get_max_txq(pf);
+
+ /* report current channels */
+ ch->rx_count = vsi->num_rxq;
+ ch->tx_count = vsi->num_txq;
+}
+
+/**
+ * ice_set_channels - set the number channels
+ * @dev: network interface device structure
+ * @ch: ethtool channel data structure
+ */
+static int ice_set_channels(struct net_device *dev, struct ethtool_channels *ch)
+{
+ struct ice_netdev_priv *np = netdev_priv(dev);
+ struct ice_vsi *vsi = np->vsi;
+ struct ice_pf *pf = vsi->back;
+ int new_rx = 0, new_tx = 0;
+
+ /* do not support changing other_count */
+ if (ch->other_count)
+ return -EINVAL;
+
+ /* verify request for a valid number of channels */
+ if (ch->rx_count > ice_get_max_rxq(pf) ||
+ ch->tx_count > ice_get_max_txq(pf))
+ return -EINVAL;
+
+ /* Use new Rx value only if changed */
+ if (ch->rx_count != vsi->num_rxq)
+ new_rx = ch->rx_count;
+
+ /* Use new Tx value only if changed */
+ if (ch->tx_count != vsi->num_txq)
+ new_tx = ch->tx_count;
+
+ /* verify that we have a valid request */
+ if (!new_rx && !new_tx)
+ return -EINVAL;
+
+ ice_vsi_recfg_qs(vsi, new_rx, new_tx);
+
+ return 0;
+}
+
enum ice_container_type {
ICE_RX_CONTAINER,
ICE_TX_CONTAINER,
@@ -3429,6 +3512,8 @@ static const struct ethtool_ops ice_ethtool_ops = {
.get_rxfh_indir_size = ice_get_rxfh_indir_size,
.get_rxfh = ice_get_rxfh,
.set_rxfh = ice_set_rxfh,
+ .get_channels = ice_get_channels,
+ .set_channels = ice_set_channels,
.get_ts_info = ethtool_op_get_ts_info,
.get_per_queue_coalesce = ice_get_per_q_coalesce,
.set_per_queue_coalesce = ice_set_per_q_coalesce,
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 6e34c40e7840..a62496a74a69 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -313,6 +313,14 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id)
case ICE_VSI_PF:
vsi->alloc_txq = pf->num_lan_tx;
vsi->alloc_rxq = pf->num_lan_rx;
+ if (vsi->req_txq) {
+ vsi->alloc_txq = vsi->req_txq;
+ vsi->num_txq = vsi->req_txq;
+ }
+ if (vsi->req_rxq) {
+ vsi->alloc_rxq = vsi->req_rxq;
+ vsi->num_rxq = vsi->req_rxq;
+ }
vsi->num_q_vectors = max_t(int, pf->num_lan_rx, pf->num_lan_tx);
break;
case ICE_VSI_VF:
@@ -855,7 +863,9 @@ static void ice_vsi_setup_q_map(struct ice_vsi *vsi, struct ice_vsi_ctx *ctxt)
else
max_rss = ICE_MAX_SMALL_RSS_QS;
qcount_rx = min_t(int, rx_numq_tc, max_rss);
- qcount_rx = min_t(int, qcount_rx, vsi->rss_size);
+ if (!vsi->req_rxq)
+ qcount_rx = min_t(int, qcount_rx,
+ vsi->rss_size);
}
}
@@ -959,11 +969,12 @@ static void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
/**
* ice_vsi_init - Create and initialize a VSI
* @vsi: the VSI being configured
+ * @init_vsi: is this call creating a VSI
*
* This initializes a VSI context depending on the VSI type to be added and
* passes it down to the add_vsi aq command to create a new VSI.
*/
-static int ice_vsi_init(struct ice_vsi *vsi)
+static int ice_vsi_init(struct ice_vsi *vsi, bool init_vsi)
{
struct ice_pf *pf = vsi->back;
struct ice_hw *hw = &pf->hw;
@@ -1010,11 +1021,20 @@ static int ice_vsi_init(struct ice_vsi *vsi)
ICE_AQ_VSI_SEC_FLAG_ENA_MAC_ANTI_SPOOF;
}
- ret = ice_add_vsi(hw, vsi->idx, ctxt, NULL);
- if (ret) {
- dev_err(&pf->pdev->dev,
- "Add VSI failed, err %d\n", ret);
- return -EIO;
+ if (init_vsi) {
+ ret = ice_add_vsi(hw, vsi->idx, ctxt, NULL);
+ if (ret) {
+ dev_err(&pf->pdev->dev,
+ "Add VSI failed, err %d\n", ret);
+ return -EIO;
+ }
+ } else {
+ ret = ice_update_vsi(hw, vsi->idx, ctxt, NULL);
+ if (ret) {
+ dev_err(&pf->pdev->dev,
+ "Update VSI failed, err %d\n", ret);
+ return -EIO;
+ }
}
/* keep context for update VSI operations */
@@ -2435,7 +2455,7 @@ ice_vsi_setup(struct ice_pf *pf, struct ice_port_info *pi,
ice_vsi_set_tc_cfg(vsi);
/* create the VSI */
- ret = ice_vsi_init(vsi);
+ ret = ice_vsi_init(vsi, true);
if (ret)
goto unroll_get_qs;
@@ -2911,10 +2931,11 @@ int ice_vsi_release(struct ice_vsi *vsi)
/**
* ice_vsi_rebuild - Rebuild VSI after reset
* @vsi: VSI to be rebuild
+ * @init_vsi: is this an initialization or a reconfigure of the VSI
*
* Returns 0 on success and negative value on failure
*/
-int ice_vsi_rebuild(struct ice_vsi *vsi)
+int ice_vsi_rebuild(struct ice_vsi *vsi, bool init_vsi)
{
u16 max_txqs[ICE_MAX_TRAFFIC_CLASS] = { 0 };
struct ice_vf *vf = NULL;
@@ -2947,14 +2968,18 @@ int ice_vsi_rebuild(struct ice_vsi *vsi)
ice_vsi_clear_rings(vsi);
ice_vsi_free_arrays(vsi);
ice_dev_onetime_setup(&pf->hw);
+ if (vsi->req_txq || vsi->req_rxq)
+ ice_vsi_put_qs(vsi);
if (vsi->type == ICE_VSI_VF)
ice_vsi_set_num_qs(vsi, vf->vf_id);
else
ice_vsi_set_num_qs(vsi, ICE_INVAL_VFID);
+ if (vsi->req_txq || vsi->req_rxq)
+ ice_vsi_get_qs(vsi);
ice_vsi_set_tc_cfg(vsi);
/* Initialize VSI struct elements and create VSI in FW */
- ret = ice_vsi_init(vsi);
+ ret = ice_vsi_init(vsi, init_vsi);
if (ret < 0)
goto err_vsi;
@@ -3018,7 +3043,12 @@ int ice_vsi_rebuild(struct ice_vsi *vsi)
dev_err(&pf->pdev->dev,
"VSI %d failed lan queue config, error %d\n",
vsi->vsi_num, status);
- goto err_vectors;
+ if (init_vsi) {
+ ret = -EIO;
+ goto err_vectors;
+ } else {
+ return ice_schedule_reset(pf, ICE_RESET_PFR);
+ }
}
return 0;
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.h b/drivers/net/ethernet/intel/ice/ice_lib.h
index 6e43ef03bfc3..7409a69f631d 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.h
+++ b/drivers/net/ethernet/intel/ice/ice_lib.h
@@ -70,7 +70,7 @@ int ice_free_res(struct ice_res_tracker *res, u16 index, u16 id);
int
ice_get_res(struct ice_pf *pf, struct ice_res_tracker *res, u16 needed, u16 id);
-int ice_vsi_rebuild(struct ice_vsi *vsi);
+int ice_vsi_rebuild(struct ice_vsi *vsi, bool init_vsi);
bool ice_is_reset_in_progress(unsigned long *state);
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index c26e6a102dac..f9f81307dac8 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1513,6 +1513,42 @@ static void ice_set_ctrlq_len(struct ice_hw *hw)
hw->mailboxq.sq_buf_size = ICE_MBXQ_MAX_BUF_LEN;
}
+/**
+ * ice_schedule_reset - schedule a reset
+ * @pf: board private structure
+ * @reset: reset being requested
+ */
+int ice_schedule_reset(struct ice_pf *pf, enum ice_reset_req reset)
+{
+ /* bail out if earlier reset has failed */
+ if (test_bit(__ICE_RESET_FAILED, pf->state)) {
+ dev_dbg(&pf->pdev->dev, "earlier reset has failed\n");
+ return -EIO;
+ }
+ /* bail if reset/recovery already in progress */
+ if (ice_is_reset_in_progress(pf->state)) {
+ dev_dbg(&pf->pdev->dev, "Reset already in progress\n");
+ return -EBUSY;
+ }
+
+ switch (reset) {
+ case ICE_RESET_PFR:
+ set_bit(__ICE_PFR_REQ, pf->state);
+ break;
+ case ICE_RESET_CORER:
+ set_bit(__ICE_CORER_REQ, pf->state);
+ break;
+ case ICE_RESET_GLOBR:
+ set_bit(__ICE_GLOBR_REQ, pf->state);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ice_service_task_schedule(pf);
+ return 0;
+}
+
/**
* ice_irq_affinity_notify - Callback for affinity changes
* @notify: context as to what irq was changed
@@ -3745,7 +3781,7 @@ static int ice_vsi_rebuild_all(struct ice_pf *pf)
if (!pf->vsi[i])
continue;
- err = ice_vsi_rebuild(pf->vsi[i]);
+ err = ice_vsi_rebuild(pf->vsi[i], true);
if (err) {
dev_err(&pf->pdev->dev,
"VSI at index %d rebuild failed\n",
@@ -3907,6 +3943,59 @@ static void ice_rebuild(struct ice_pf *pf)
dev_err(dev, "Rebuild failed, unload and reload driver\n");
}
+/**
+ * ice_vsi_recfg_qs - Change the number of queues on a VSI
+ * @vsi: VSI being changed
+ * @new_rx: new number of Rx queues
+ * @new_tx: new number of Tx queues
+ *
+ * Only change the number of queues if new_tx, or new_rx is non-0.
+ *
+ * Returns 0 on success.
+ */
+int ice_vsi_recfg_qs(struct ice_vsi *vsi, int new_rx, int new_tx)
+{
+ struct ice_pf *pf = vsi->back;
+ int err = 0, timeout = 50;
+
+ if (!new_rx && !new_tx)
+ return -EINVAL;
+
+ while (test_and_set_bit(__ICE_CFG_BUSY, pf->state)) {
+ timeout--;
+ if (!timeout)
+ return -EBUSY;
+ usleep_range(1000, 2000);
+ }
+
+ /* set for the next time the netdev is started */
+ if (!netif_running(vsi->netdev)) {
+ if (new_tx)
+ vsi->req_txq = new_tx;
+ if (new_rx)
+ vsi->req_rxq = new_rx;
+
+ dev_dbg(&pf->pdev->dev, "Link is down, queue count change happens when link is brought up\n");
+ goto done;
+ }
+
+ ice_vsi_close(vsi);
+
+ if (new_tx)
+ vsi->req_txq = new_tx;
+
+ if (new_rx)
+ vsi->req_rxq = new_rx;
+
+ ice_vsi_rebuild(vsi, false);
+ ice_pf_dcb_recfg(pf);
+
+ ice_vsi_open(vsi);
+done:
+ clear_bit(__ICE_CFG_BUSY, pf->state);
+ return err;
+}
+
/**
* ice_change_mtu - NDO callback to change the MTU
* @netdev: network interface device structure
--
2.21.0
^ permalink raw reply related
* [net-next 02/15] ice: Use the software based tail when checking for hung Tx ring
From: Jeff Kirsher @ 2019-08-09 18:31 UTC (permalink / raw)
To: davem; +Cc: Brett Creeley, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190809183139.30871-1-jeffrey.t.kirsher@intel.com>
From: Brett Creeley <brett.creeley@intel.com>
Currently in ice_get_tx_pending we try to read a Tx ring's tail. This is
then compared with the software based head (next_to_clean) to determine
if we have pending work. This will never work because reading of the Tx
ring's tail is no longer supported. Fix this by using the software based
tail (next_to_use) to determine if there is pending work.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index f9f81307dac8..f6926cbb48a4 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -41,12 +41,12 @@ static void ice_update_pf_stats(struct ice_pf *pf);
* ice_get_tx_pending - returns number of Tx descriptors not processed
* @ring: the ring of descriptors
*/
-static u32 ice_get_tx_pending(struct ice_ring *ring)
+static u16 ice_get_tx_pending(struct ice_ring *ring)
{
- u32 head, tail;
+ u16 head, tail;
head = ring->next_to_clean;
- tail = readl(ring->tail);
+ tail = ring->next_to_use;
if (head != tail)
return (head < tail) ?
--
2.21.0
^ 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