* [PATCH net-next 2/2] selftests: forwarding: Test mirror-to-gretap w/ UL 802.1q
From: Petr Machata @ 2018-07-02 17:58 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah
In-Reply-To: <cover.1530553971.git.petrm@mellanox.com>
Test for "tc action mirred egress mirror" that mirrors to gretap when
the underlay route points at a VLAN-aware bridge (802.1q).
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
.../net/forwarding/mirror_gre_bridge_1q.sh | 126 +++++++++++++++++++++
1 file changed, 126 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
diff --git a/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
new file mode 100755
index 000000000000..a3402cd8d5b6
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
@@ -0,0 +1,126 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test for "tc action mirred egress mirror" when the underlay route points at a
+# bridge device with vlan filtering (802.1q).
+#
+# This test uses standard topology for testing mirror-to-gretap. See
+# mirror_gre_topo_lib.sh for more details. The full topology is as follows:
+#
+# +---------------------+ +---------------------+
+# | H1 | | H2 |
+# | + $h1 | | $h2 + |
+# | | 192.0.2.1/28 | | 192.0.2.2/28 | |
+# +-----|---------------+ +---------------|-----+
+# | |
+# +-----|---------------------------------------------------------------|-----+
+# | SW o---> mirror | |
+# | +---|---------------------------------------------------------------|---+ |
+# | | + $swp1 + br1 (802.1q bridge) $swp2 + | |
+# | | 192.0.2.129/28 | |
+# | | + $swp3 2001:db8:2::1/64 | |
+# | | | vid555 vid555[pvid,untagged] | |
+# | +---|-------------------------------------------------------------------+ |
+# | | ^ ^ |
+# | | + gt6 (ip6gretap) | + gt4 (gretap) | |
+# | | : loc=2001:db8:2::1 | : loc=192.0.2.129 | |
+# | | : rem=2001:db8:2::2 -+ : rem=192.0.2.130 -+ |
+# | | : ttl=100 : ttl=100 |
+# | | : tos=inherit : tos=inherit |
+# +-----|---------------------:------------------------:----------------------+
+# | : :
+# +-----|---------------------:------------------------:----------------------+
+# | H3 + $h3 + h3-gt6(ip6gretap) + h3-gt4 (gretap) |
+# | | loc=2001:db8:2::2 loc=192.0.2.130 |
+# | + $h3.555 rem=2001:db8:2::1 rem=192.0.2.129 |
+# | 192.0.2.130/28 ttl=100 ttl=100 |
+# | 2001:db8:2::2/64 tos=inherit tos=inherit |
+# +---------------------------------------------------------------------------+
+
+ALL_TESTS="
+ test_gretap
+ test_ip6gretap
+"
+
+NUM_NETIFS=6
+source lib.sh
+source mirror_lib.sh
+source mirror_gre_lib.sh
+source mirror_gre_topo_lib.sh
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+
+ swp2=${NETIFS[p3]}
+ h2=${NETIFS[p4]}
+
+ swp3=${NETIFS[p5]}
+ h3=${NETIFS[p6]}
+
+ vrf_prepare
+ mirror_gre_topo_create
+
+ ip link set dev $swp3 master br1
+ bridge vlan add dev br1 vid 555 pvid untagged self
+ ip address add dev br1 192.0.2.129/28
+ ip address add dev br1 2001:db8:2::1/64
+
+ ip -4 route add 192.0.2.130/32 dev br1
+ ip -6 route add 2001:db8:2::2/128 dev br1
+
+ vlan_create $h3 555 v$h3 192.0.2.130/28 2001:db8:2::2/64
+ bridge vlan add dev $swp3 vid 555
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ ip link set dev $swp3 nomaster
+ vlan_destroy $h3 555
+
+ mirror_gre_topo_destroy
+ vrf_cleanup
+}
+
+test_gretap()
+{
+ full_test_span_gre_dir gt4 ingress 8 0 "mirror to gretap"
+ full_test_span_gre_dir gt4 egress 0 8 "mirror to gretap"
+}
+
+test_ip6gretap()
+{
+ full_test_span_gre_dir gt6 ingress 8 0 "mirror to ip6gretap"
+ full_test_span_gre_dir gt6 egress 0 8 "mirror to ip6gretap"
+}
+
+tests()
+{
+ slow_path_trap_install $swp1 ingress
+ slow_path_trap_install $swp1 egress
+
+ tests_run
+
+ slow_path_trap_uninstall $swp1 egress
+ slow_path_trap_uninstall $swp1 ingress
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tcflags="skip_hw"
+tests
+
+if ! tc_offload_check; then
+ echo "WARN: Could not test offloaded functionality"
+else
+ tcflags="skip_sw"
+ tests
+fi
+
+exit $EXIT_STATUS
--
2.4.11
^ permalink raw reply related
* [PATCH net-next 1/2] selftests: forwarding: Test mirror-to-gretap w/ UL 802.1d
From: Petr Machata @ 2018-07-02 17:58 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah
In-Reply-To: <cover.1530553971.git.petrm@mellanox.com>
Test for "tc action mirred egress mirror" that mirrors to gretap when
the underlay route points at a VLAN-unaware bridge (802.1d).
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
.../net/forwarding/mirror_gre_bridge_1d.sh | 132 +++++++++++++++++++++
1 file changed, 132 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
diff --git a/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
new file mode 100755
index 000000000000..c5095da7f6bf
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
@@ -0,0 +1,132 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test for "tc action mirred egress mirror" when the underlay route points at a
+# bridge device without vlan filtering (802.1d).
+#
+# This test uses standard topology for testing mirror-to-gretap. See
+# mirror_gre_topo_lib.sh for more details. The full topology is as follows:
+#
+# +---------------------+ +---------------------+
+# | H1 | | H2 |
+# | + $h1 | | $h2 + |
+# | | 192.0.2.1/28 | | 192.0.2.2/28 | |
+# +-----|---------------+ +---------------|-----+
+# | |
+# +-----|-------------------------------------------------------------|-----+
+# | SW o---> mirror | |
+# | +---|-------------------------------------------------------------|---+ |
+# | | + $swp1 + br1 (802.1q bridge) $swp2 + | |
+# | +---------------------------------------------------------------------+ |
+# | |
+# | +---------------------------------------------------------------------+ |
+# | | + br2 (802.1d bridge) | |
+# | | 192.0.2.129/28 | |
+# | | + $swp3 2001:db8:2::1/64 | |
+# | +---|-----------------------------------------------------------------+ |
+# | | ^ ^ |
+# | | + gt6 (ip6gretap) | + gt4 (gretap) | |
+# | | : loc=2001:db8:2::1 | : loc=192.0.2.129 | |
+# | | : rem=2001:db8:2::2 -+ : rem=192.0.2.130 -+ |
+# | | : ttl=100 : ttl=100 |
+# | | : tos=inherit : tos=inherit |
+# +-----|---------------------:----------------------:----------------------+
+# | : :
+# +-----|---------------------:----------------------:----------------------+
+# | H3 + $h3 + h3-gt6(ip6gretap) + h3-gt4 (gretap) |
+# | 192.0.2.130/28 loc=2001:db8:2::2 loc=192.0.2.130 |
+# | 2001:db8:2::2/64 rem=2001:db8:2::1 rem=192.0.2.129 |
+# | ttl=100 ttl=100 |
+# | tos=inherit tos=inherit |
+# +-------------------------------------------------------------------------+
+
+ALL_TESTS="
+ test_gretap
+ test_ip6gretap
+"
+
+NUM_NETIFS=6
+source lib.sh
+source mirror_lib.sh
+source mirror_gre_lib.sh
+source mirror_gre_topo_lib.sh
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+
+ swp2=${NETIFS[p3]}
+ h2=${NETIFS[p4]}
+
+ swp3=${NETIFS[p5]}
+ h3=${NETIFS[p6]}
+
+ vrf_prepare
+ mirror_gre_topo_create
+
+ ip link add name br2 type bridge vlan_filtering 0
+ ip link set dev br2 up
+
+ ip link set dev $swp3 master br2
+ ip route add 192.0.2.130/32 dev br2
+ ip -6 route add 2001:db8:2::2/128 dev br2
+
+ ip address add dev br2 192.0.2.129/28
+ ip address add dev br2 2001:db8:2::1/64
+
+ ip address add dev $h3 192.0.2.130/28
+ ip address add dev $h3 2001:db8:2::2/64
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ ip address del dev $h3 2001:db8:2::2/64
+ ip address del dev $h3 192.0.2.130/28
+ ip link del dev br2
+
+ mirror_gre_topo_destroy
+ vrf_cleanup
+}
+
+test_gretap()
+{
+ full_test_span_gre_dir gt4 ingress 8 0 "mirror to gretap"
+ full_test_span_gre_dir gt4 egress 0 8 "mirror to gretap"
+}
+
+test_ip6gretap()
+{
+ full_test_span_gre_dir gt6 ingress 8 0 "mirror to ip6gretap"
+ full_test_span_gre_dir gt6 egress 0 8 "mirror to ip6gretap"
+}
+
+test_all()
+{
+ slow_path_trap_install $swp1 ingress
+ slow_path_trap_install $swp1 egress
+
+ tests_run
+
+ slow_path_trap_uninstall $swp1 egress
+ slow_path_trap_uninstall $swp1 ingress
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tcflags="skip_hw"
+test_all
+
+if ! tc_offload_check; then
+ echo "WARN: Could not test offloaded functionality"
+else
+ tcflags="skip_sw"
+ test_all
+fi
+
+exit $EXIT_STATUS
--
2.4.11
^ permalink raw reply related
* [PATCH net-next 0/2] More mirror-to-gretap tests with bridge in UL
From: Petr Machata @ 2018-07-02 17:58 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah
This patchset adds two more tests where the mirror-to-gretap has a
bridge in underlay packet path, without a VLAN above or below that
bridge.
In patch #1, a non-VLAN-filtering bridge is tested.
In patch #2, a VLAN-filtering bridge is tested.
Petr Machata (2):
selftests: forwarding: Test mirror-to-gretap w/ UL 802.1d
selftests: forwarding: Test mirror-to-gretap w/ UL 802.1q
.../net/forwarding/mirror_gre_bridge_1d.sh | 132 +++++++++++++++++++++
.../net/forwarding/mirror_gre_bridge_1q.sh | 126 ++++++++++++++++++++
2 files changed, 258 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
--
2.4.11
^ permalink raw reply
* Re: [RFC net-next 08/15] net: lora: sx1276: Add debugfs
From: Andreas Färber @ 2018-07-02 17:57 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180702162649.GC2737@nanopsycho.orion>
Am 02.07.2018 um 18:26 schrieb Jiri Pirko:
> Sun, Jul 01, 2018 at 01:07:57PM CEST, afaerber@suse.de wrote:
>> Allow some interactive inspection at runtime via debugfs.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
[...]
>> @@ -566,6 +691,10 @@ static int sx1276_probe(struct spi_device *spi)
>> return ret;
>> }
>>
>> + priv->debugfs = debugfs_create_dir(dev_name(&spi->dev), NULL);
>> + debugfs_create_file("state", S_IRUGO, priv->debugfs, netdev, &sx1276_state_fops);
>> + debugfs_create_file("frequency", S_IRUGO, priv->debugfs, netdev, &sx1276_freq_fops);
>
> Hmm. These look like useful information not only for debugging. I think
> it would be worth to expose these via some standard uapi. Like generic
> netlink, similar to nl80211
Which API to use for reading/writing such config data was question 4) in
my cover letter. :)
"frequency" was added first and helped me debug a calculation overflow.
Netlink might indeed be an option here, haven't worked on it before,
I'll look into nl80211. Thanks.
"state" was just a partial dump of SPI registers, to monitor status
changes after the initial probe or other callbacks with printks, while
debugging GPIO interrupts iirc. So I'd think merging that to mainline
would be unnecessary, but it could remain useful during development.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] ieee802154: add rx LQI from userspace
From: Alexander Aring @ 2018-07-02 17:53 UTC (permalink / raw)
To: Clément Péron
Cc: Romuald Cari, linux-wpan, Alexander Aring, Stefan Schmidt,
David S . Miller, netdev, linux-kernel, Clément Peron
In-Reply-To: <CAJiuCcdCE42FvWc0svNpQDD0rczYi7Xz-RW5PbbjAuvZe9dgwg@mail.gmail.com>
Hi,
On Mon, Jul 02, 2018 at 03:28:04PM +0200, Clément Péron wrote:
> Could you review it please ?
>
sorry... I was thinking a lot what I can contribute to this patch, I
want to make it short.
I see your use case and your use case has of course a valid point.
What I can say about the code? This socket layer was contributed a lot
in a time where the subsystem was unmaintained. Stefan has some
experience with this socket layer by doing some examples [0].
In my opinion I am confused that a lot of netlink handling is needed to
do "something" with this socket layer. I already thought that we need
some af802154ng for next generation.
Known bug is also RAW sockets on af802154 are totally messed up... but
we don't need them, this can be done by AF_PACKET (just need to think
about similar handling there).
---
Now to your patch, you use skb->cb there. The tc ingress part can
_maybe_? use this control block information. I think this issue is out
of scope because we have also other parts in the code how we pass data
between driver and packet layer with skb->cb -> we simply do it wrong.
I have no problems to have this patch inside but for future we should
tackle a af802154ng with a better UAPI handling.
If we fix skb->cb we just need to think about how to pass such data up
to socket layer.
- Alex
[0] https://github.com/linux-wpan/wpan-tools/tree/master/examples
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Andreas Färber @ 2018-07-02 17:34 UTC (permalink / raw)
To: Mark Brown
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan, Jiri Pirko,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Ben Whitten,
Steve deRosier, linux-spi, LoRa_Community_Support
In-Reply-To: <20180702161258.GA18744@sirena.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 5074 bytes --]
Hi Mark,
This driver is still evolving, there's newer code on my lora-next branch
already: https://github.com/afaerber/linux/commits/lora-next
The reason you're in CC on this RFC is two-fold:
1) You applied Ben's patch to associate "semtech,sx1301" with spidev,
whereas I am now preparing a new driver for the same compatible.
2) This SPI device is in turn exposing the two SPI masters that you
already found below, and I didn't see a sane way to split that code out
into drivers/spi/, so it's in drivers/net/lora/ here - has there been
any precedence either way?
More inline ...
Am 02.07.2018 um 18:12 schrieb Mark Brown:
> On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
>
>> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
>> +{
>> + int ret;
>> +
>> + dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
>> +
>> + if (enable)
>> + return;
>> +
>> + ret = sx1301_radio_set_cs(spi->controller, enable);
>> + if (ret)
>> + dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
>> +}
>
> So we never disable chip select?
Not here, I instead did that in transfer_one below.
Unfortunately there seems to be no documentation, only reference code:
https://github.com/Lora-net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L121
https://github.com/Lora-net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L165
It sets CS to 0 before writing to address and data registers, then
immediately sets CS to 1 and back to 0 before reading or ending the
write transaction. I've tried to force the same behavior in this driver.
My guess was that CS is high-active during the short 1-0 cycle, because
if it's low-active during the register writes then why the heck is it
set to 0 again in the end instead of keeping at 1... confusing.
Maybe the Semtech folks CC'ed can comment how these registers work?
>> + if (tx_buf) {
>> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
>
> This looks confused. We're in an if (tx_buf) block but there's a use of
> the ternery operator that appears to be checking if we have a tx_buf?
Yeah, as mentioned this RFC is not ready for merging - checkpatch.pl
will complain about lines too long, and TODOs are sprinkled all over or
not even mentioned. It's a Proof of Concept that a net_device could work
for a wide range of spi and serdev based drivers, and on top this device
has more than one channel, which may influence network-level design
discussions.
That said, I'll happily drop the second check. Thanks for spotting!
>> + if (ret) {
>> + dev_err(&spi->dev, "SPI radio address write failed\n");
>> + return ret;
>> + }
>> +
>> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
>> + if (ret) {
>> + dev_err(&spi->dev, "SPI radio data write failed\n");
>> + return ret;
>> + }
>
> This looks awfully like you're coming in at the wrong abstraction layer
> and the hardware actually implements a register abstraction rather than
> a SPI one so you should be using regmap as the abstraction.
I don't understand. Ben has suggested using regmap for the SPI _device_
that we're talking to, which may be a good idea. But this SX1301 device
in turn has two SPI _masters_ talking to an SX125x slave each. I don't
see how using regmap instead of my wrappers avoids this spi_controller?
The whole point of this spi_controller is to abstract and separate the
SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
instead of mixing it into the SX1301 driver - to me that looks cleaner
and more extensible. It also has the side-effect that we could configure
the two radios via DT (frequencies, clk output, etc.).
You will find a datasheet with some diagrams mentioning "SPI" at:
https://www.semtech.com/products/wireless-rf/lora-gateways/SX1301
>> + if (rx_buf) {
>> + ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
>> + if (ret) {
>> + dev_err(&spi->dev, "SPI radio data read failed\n");
>> + return ret;
>> + }
>> + }
>
> For a read we never set an address?
To read, you first write the address via tx_buf, then either in the same
transfer in the third byte or in a subsequent one-byte transfer as first
byte you get the data.
If you have better ideas how to structure this, do let me know.
>> +static void sx1301_radio_setup(struct spi_controller *ctrl)
>> +{
>> + ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
>
> This controller has no chip select but we provided a set_cs operation?
Oops, I played around with those two options and was hoping SPI_NO_CS
would avoid the undesired set_cs invocations, but it didn't work as
expected and so I added the "if (enabled)" check above.
Thanks for your review,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] Fix references for some missing documentation files
From: Jonathan Corbet @ 2018-07-02 17:27 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mark Rutland, James Morris, kvm, Linux Doc Mailing List,
virtualization, linux-leds, linux-scsi, Ingo Molnar,
intel-wired-lan, Jeff Kirsher, linux-input, devicetree,
Steven Rostedt, Mauro Carvalho Chehab, linux-gpio,
Jacek Anaszewski, Andy Whitcroft, netdev, linux-kernel,
Changbin Du, Masami Hiramatsu, linux-kernel, Joe Perches,
Andrew Morton, linuxppc-dev, "
In-Reply-To: <cover.1530005114.git.mchehab+samsung@kernel.org>
On Tue, 26 Jun 2018 06:49:02 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Having nothing to do while waiting for my plane to arrive while
> returning back from Japan, I ended by writing a small series of
> patches meant to reduce the number of bad Documentation/*
> links that are detected by:
> ./scripts/documentation-file-ref-check
I've applied everything except the two networking patches, since I expect
those to go through Dave's tree.
Thanks,
jon
^ permalink raw reply
* [PATCH net] tls: fix skb_to_sgvec returning unhandled error.
From: Doron Roberts-Kedes @ 2018-07-02 17:25 UTC (permalink / raw)
To: David S . Miller; +Cc: Dave Watson, netdev, Doron Roberts-Kedes
The current code does not inspect the return value of skb_to_sgvec. This
can cause a nullptr kernel panic when the malformed sgvec is passed into
the crypto request.
Checking the return value of skb_to_sgvec and skipping decryption if it
is negative fixes this problem.
Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Acked-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com>
---
net/tls/tls_sw.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 173d8b89072d..b6e118499083 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -701,6 +701,10 @@ static int decrypt_skb(struct sock *sk, struct sk_buff *skb,
nsg = skb_to_sgvec(skb, &sgin[1],
rxm->offset + tls_ctx->rx.prepend_size,
rxm->full_len - tls_ctx->rx.prepend_size);
+ if (nsg < 0) {
+ ret = nsg;
+ goto out;
+ }
tls_make_aad(ctx->rx_aad_ciphertext,
rxm->full_len - tls_ctx->rx.overhead_size,
@@ -712,6 +716,7 @@ static int decrypt_skb(struct sock *sk, struct sk_buff *skb,
rxm->full_len - tls_ctx->rx.overhead_size,
skb, sk->sk_allocation);
+out:
if (sgin != &sgin_arr[0])
kfree(sgin);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Jakub Kicinski @ 2018-07-02 17:19 UTC (permalink / raw)
To: Okash Khawaja
Cc: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180701103146.GA1388@w1t1fb>
On Sun, 1 Jul 2018 11:31:47 +0100, Okash Khawaja wrote:
> On Wed, Jun 27, 2018 at 02:56:49PM +0200, Daniel Borkmann wrote:
> > On 06/27/2018 01:47 PM, Okash Khawaja wrote:
> > > On Wed, Jun 27, 2018 at 12:34:35PM +0200, Daniel Borkmann wrote:
> > >> On 06/27/2018 12:35 AM, Jakub Kicinski wrote:
> > >>> On Tue, 26 Jun 2018 15:27:09 -0700, Martin KaFai Lau wrote:
> > >>>> On Tue, Jun 26, 2018 at 01:31:33PM -0700, Jakub Kicinski wrote:
> > >> [...]
> > >>>>> Implementing both outputs in one series will help you structure your
> > >>>>> code to best suit both of the formats up front.
> > >>>> hex and "formatted" are the only things missing? As always, things
> > >>>> can be refactored when new use case comes up. Lets wait for
> > >>>> Okash input.
> > >>>>
> > >>>> Regardless, plaintext is our current use case. Having the current
> > >>>> patchset in does not stop us or others from contributing other use
> > >>>> cases (json, "bpftool map find"...etc), and IMO it is actually
> > >>>> the opposite. Others may help us get there faster than us alone.
> > >>>> We should not stop making forward progress and take this patch
> > >>>> as hostage because "abc" and "xyz" are not done together.
> > >>>
> > >>> Parity between JSON and plain text output is non negotiable.
> > >>
> > >> Longish discussion and some confusion in this thread. :-) First of all
> > >> thanks a lot for working on it, very useful!
> > > Thanks :)
> > >
> > >> My $0.02 on it is that so far
> > >> great care has been taken in bpftool to indeed have feature parity between
> > >> JSON and plain text, so it would be highly desirable to keep continuing
> > >> this practice if the consensus is that it indeed is feasible and makes
> > >> sense wrt BTF data. There has been mentioned that given BTF data can be
> > >> dynamic depending on what the user loads via bpf(2) so a potential JSON
> > >> output may look different/break each time anyway. This however could all be
> > >> embedded under a container object that has a fixed key like 'formatted'
> > >> where tools like jq(1) can query into it. I think this would be fine since
> > >> the rest of the (non-dynamic) output is still retained as-is and then
> > >> wouldn't confuse or collide with existing users, and anyone programmatically
> > >> parsing deeper into the BTF data under such JSON container object needs
> > >> to have awareness of what specific data it wants to query from it; so
> > >> there's no conflict wrt breaking anything here. Imho, both outputs would
> > >> be very valuable.
> > > Okay I can add "formatted" object under json output.
> > >
> > > One thing to note here is that the fixed output will change if the map
> > > itself changes. So someone writing a program that consumes that fixed
> > > output will have to account for his program breaking in future, thus
> >
> > Yes, that aspect is fine though, any program/script parsing this would need
> > to be aware of the underlying map type to make sense of it (e.g. per-cpu vs
> > non per-cpu maps to name one). But that info it could query/verify already
> > beforehand via bpftool as well (via normal map info dump for a given id).
> >
> > > breaking backward compatibility anyway as far as the developer is
> > > concerned :)
> > >
> > > I will go ahead with work on "formatted" object.
> >
> > Cool, thanks,
> > Daniel
>
>
> hi,
>
> couple of questions:
>
> 1. just to be sure, formatted section will be on the same level as "key"
> and "value"? so something like following:
>
>
> $ bpftool map dump -p id 8
> [{
> "key": ["0x00","0x00","0x00","0x00"
> ],
> "value": [...
> ],
> "formatted": {
> "key": 0,
> "value": {
> "int_field": 3,
> "pointerfield": 2152930552,
> ...
> }
> }
> }]
Looks good, yes!
> 2. i noticed that the ouput in v1 has all the keys and values on the
> same level. in v2, i'll change them so that each key-value pair is a
> separate object. let me know what you think.
For non-JSON output? No preference, whatever looks better :) Empty
line between key/value pairs to visually separate them could also
work. But up to you.
> finally, i noticed there is a map lookup command which also prints map
> entries. do want that to also be btf-printed in this patchset?
It would be nice to share the printing code for the two, yes.
^ permalink raw reply
* Re: [PATCH v3 1/4] Simplify usbnet_cdc_update_filter
From: Bjørn Mork @ 2018-07-02 17:13 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Miguel Rodríguez Pérez, gregkh, linux-usb, netdev
In-Reply-To: <1530519944.18402.10.camel@suse.com>
Oliver Neukum <oneukum@suse.com> writes:
> On So, 2018-07-01 at 11:05 +0200, Miguel Rodríguez Pérez wrote:
>> Remove some unneded varibles to make the code easier to read
>> and, replace the generic usb_control_msg function for the
>> more specific usbnet_write_cmd.
>>
>> Signed-off-by: Miguel Rodríguez Pérez <miguel@det.uvigo.gal>
>
> No,
>
> sorry, but this is not good. The reason is a bit subtle.
> Drivers need to reset the filters when handling post_reset()
> [ and reset_resume() ] usbnet_write_cmd() falls back to
> kmemdup() with GFP_KERNEL. Usbnet is a framework with class
> drivers and some of the devices we drive have a storage
> interface. Thence we are on the block error handling path here.
Right. I knew there had to be some reason this was left out when the
rest of these were converted. But I don't think the reason is
valid... usbnet_write_cmd() will never call kmemdup when data is NULL.
There is of course also little advantage in using usbnet_write_cmd when
we don't need to allocate a buffer. But I'd still prefer to see it for
consistency, power management and debug logging.
Or if it is left as-is: Maybe add a comment so that I don't ask the same
stupid questions in 3 weeks time? :-) My memory is los^Husy...
> The simplest solution is to leave out this patch in the sequence.
As Miguel noted: That won't work. The switch from dev->data->control to
dev->intf is necessary to make this function reusable by other
minidrivers.
Bjørn
^ permalink raw reply
* Re: [RFC net-next 05/15] HACK: net: lora: Deal with .poll_mask in 4.18-rc2
From: Andreas Färber @ 2018-07-02 16:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180702162238.GB2737@nanopsycho.orion>
Am 02.07.2018 um 18:22 schrieb Jiri Pirko:
> Sun, Jul 01, 2018 at 01:07:54PM CEST, afaerber@suse.de wrote:
>> linux-next and 4.18-rc2 both identify as LINUX_VERSION(4,18,0), but
>> commit a11e1d432b51f63ba698d044441284a661f01144 (Revert changes to
>> convert to ->poll_mask() and aio IOCB_CMD_POLL) reverted .poll_mask
>> to .poll again.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>> net/lora/dgram.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/net/lora/dgram.c b/net/lora/dgram.c
>> index 4d931fd3778a..ef56fd90e762 100644
>> --- a/net/lora/dgram.c
>> +++ b/net/lora/dgram.c
>> @@ -217,7 +217,11 @@ const struct proto_ops dgram_proto_ops = {
>> .socketpair = sock_no_socketpair,
>> .accept = sock_no_accept,
>> .getname = dgram_getname,
>> +#if 0 /* LINUX_VERSION_CODE >= LINUX_VERSION(4, 18, 0) */
>> + .poll_mask = datagram_poll_mask,
>> +#else
>
> I guess that you sent this patch by mistake...
No mistake, it's clearly marked as "HACK", and the cover letter states
this is not for merging but for the design discussion. You wanted to see
patches for discussing the topic, so I sent you my current draft.
On my development machine with -rc2 I still use .poll_mask. I will be
able to drop the patch once we have -rc3 built, unless .poll_mask gets
reintroduced later in the cycle. If you know of some macro to check
whether we're -rc2 or -rc3 of 4.18 I'm all ears, otherwise grep'ing in
the Makefile and defining some custom macro would be an alternative.
Some other places in this series have similar, not-commented-out
compatibility code to allow me to test individual modules quickly
without having to build and boot a full kernel for every change. Like
some sk function got/lost a parameter at some point. Originally I kept
compatibility with openSUSE Leap 42.3's 4.4 kernel, now 15.0's 4.12.
https://github.com/afaerber/lora-modules has a Makefile and load.sh
script for that purpose, plus a small C example to send a packet.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* [PATCH] lib: rhashtable: Correct self-assignment in rhashtable.c
From: Rishabh Bhatnagar @ 2018-07-02 16:35 UTC (permalink / raw)
To: netdev, neilb, tgraf, herbert; +Cc: linux-arm-msm, Rishabh Bhatnagar
In file lib/rhashtable.c line 777, skip variable is assigned to
itself. The following error was observed:
lib/rhashtable.c:777:41: warning: explicitly assigning value of
variable of type 'int' to itself [-Wself-assign] error, forbidden
warning: rhashtable.c:777
This error was found when compiling with Clang 6.0. Change it to iter->skip.
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: NeilBrown <neilb@suse.com>
---
lib/rhashtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 9427b57..3109b2e 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -774,7 +774,7 @@ int rhashtable_walk_start_check(struct rhashtable_iter *iter)
skip++;
if (list == iter->list) {
iter->p = p;
- skip = skip;
+ iter->skip = skip;
goto found;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* RE: [External] Re: incomplete firmware-version shown in ethtool -i
From: Gang Gang10 Liu @ 2018-07-02 16:35 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180702150641.GA6339@tuxdriver.com>
Hi John,
Thanks for your answer!
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Monday, July 2, 2018 11:07 PM
To: Gang Gang10 Liu <liugang10@lenovo.com>
Cc: netdev@vger.kernel.org
Subject: [External] Re: incomplete firmware-version shown in ethtool -i
On Wed, Jun 27, 2018 at 07:54:39AM +0000, Gang Gang10 Liu wrote:
> Dear,
>
> I study that the ethtool only can show 31 characters firmware version,
> is it NIC driver not followed ethtool spec or Can we have any other way to get the full firmware version?
>
I think the bnxt team is doing what they can to make as much information available as possible. In this case, they seem to be trying to make versioning info about the firmware package available along with the info about the firmware version itself, and together just barely overflowing the available space in the ethtool structure.
I'll leave it to you and/or Broadcom to determine whether or not that is a bug that needs to be changed.
In the meanwhile, from your quoted message it seems that lspci can give you the correct package version information for the device.
Good luck!
John
>
> Thanks!
>
>
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/im
> ages/gradient.gif]
>
> Gang Liu 刘刚
> Global Advisory Testing Engineer
>
> DCG Test Strategy and Automation
> Lenovo SZ
>
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/im
> ages/Email%20Gifs/T.gif]+86 13620981830
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/im
> ages/Email%20Gifs/E.gif]liugang10@lenovo.com<mailto:rrivera2@lenovo.co
> m>
>
>
>
> Lenovo.com <http://www.lenovo.com/>
> Twitter<http://twitter.com/lenovo> |
> Facebook<http://www.facebook.com/lenovo> |
> Instagram<https://instagram.com/lenovo> |
> Blogs<http://blog.lenovo.com/> | Forums<http://forums.lenovo.com/>
>
>
> [The-Lenovo-Way]
>
>
>
>
>
>
> From: Gang Gang10 Liu
> Sent: Wednesday, June 27, 2018 3:13 PM
> To: Ken Cheng4 <kcheng4@lenovo.com>; Yuhong YH6 Wu <wuyh6@lenovo.com>;
> Qinwei QW1 Yu <yuqw1@lenovo.com>; Vincent HY1 Long
> <longhy1@lenovo.com>; -Product GTE <-Product_GTE@lenovo.com>
> Cc: Frank Y Wu <frankwu@lenovo.com>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi all,
>
>
> From ethtool source code, the root cause for this issue is:
>
> the internal buffer for firmware-version in ethtool is 32 (include the string tail zero), so it only can show 31 characters version.
> But the actual firmware-version got from NIC driver is large than 32.
>
> struct ethtool_drvinfo {
> __u32 cmd;
> char driver[32];
> char version[32];
> char fw_version[ETHTOOL_FWVERS_LEN];
> …
>
> #define ETHTOOL_FWVERS_LEN 32
>
>
>
>
> From: Ken Cheng4
> Sent: Wednesday, June 27, 2018 2:44 PM
> To: Yuhong YH6 Wu <wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>>; Qinwei
> QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent HY1 Long
> <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>; Gang Gang10
> Liu <liugang10@lenovo.com<mailto:liugang10@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Yuhong,
>
> A merge request for common had been raised to fix the failure from this ethtool bug while testing firmware level of Broadcom cards.
> https://l3-prd01-rtp.labs.lenovo.com:4443/te/common/merge_requests/151
> 3
>
>
> ===Background===
> Ethtool can not return correctly when the last number is zero like "212.0.107/1.9.1 pkg 212.0.112." <--missing 0 in the end.
>
> Code change is to:
>
> (1) get incomplete version like: 212.0.112
> (2) get complete version from lspci like "[V0] Vendor specific: 212.0.112.0"
> (3) compare the first three numbers with the firmware level from
> ethtool, ex:212.0.112
> (4) if the first three numbers match, fill incomplete firmware version from ethtool with correct one from lspci like: "212.0.107/1.9.1 pkg 212.0.112.0"
>
> I will let Liu Gang to review first and then submit another merge request for more_common.
>
>
>
> Ken Cheng
> Global TE Engineer
> LME
> Taiwan
>
>
> kcheng4@lenovo.com<mailto:e-mail>
> Ph: +886 2 8170-7580
> Fax: +886 2 2651-8246
>
>
> Shipping Address:
> Lenovo Technology B.V. Taiwan Branch
> 4F, No. 66 SanChong Road, NanGang,
> Taipei, Taiwan, 11502
> 荷蘭商聯想股份有限公司台灣分公司
> 台北市南港區三重路66號4樓
>
> [描述: Lenovo-For-Those-Who-Do]
>
>
>
> From: Ken Cheng4
> Sent: Tuesday, June 26, 2018 12:35 PM
> To: Yuhong YH6 Wu; Qinwei QW1 Yu; Vincent HY1 Long; -Product GTE
> Cc: Frank Y Wu
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Yuhong,
>
> We may need more time to investigate whether his statement is valid for the other component cards:
>
> === quoted from Qinwei === I believe it has
> same problem for other vendor adapters when the last number of FW version is 0.
>
> But for now I think a quick patch might be better for EOQ support. I was thinking to add an additional zero in the end of fw string when the last digit returned from ethtool is period ‘.’ in order to avoid that tuple error.
>
> For example, to add an additional 0 after “212.0.112.” before it is
> sent to tuple actual_parts = version_tuple(actual)
>
>
> Ken Cheng
> Global TE Engineer
> LME
> Taiwan
>
>
> kcheng4@lenovo.com<mailto:e-mail>
> Ph: +886 2 8170-7580
> Fax: +886 2 2651-8246
>
>
> Shipping Address:
> Lenovo Technology B.V. Taiwan Branch
> 4F, No. 66 SanChong Road, NanGang,
> Taipei, Taiwan, 11502
> 荷蘭商聯想股份有限公司台灣分公司
> 台北市南港區三重路66號4樓
>
> [描述: Lenovo-For-Those-Who-Do]
>
>
>
> From: Yuhong YH6 Wu
> Sent: Tuesday, June 26, 2018 10:41 AM
> To: Qinwei QW1 Yu; Vincent HY1 Long; -Product GTE; Ken Cheng4
> Cc: Frank Y Wu
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Ken,
>
> Pre talk with Dev Qinwei brcm fw show have some problem by ethtool whether able to use lspci common replace ethtool to read fw level as below.
>
> [6/26/2018 10:07 AM] Yuhong YH6 Wu:
>
> [root@localhost ~]# ethtool -i eth2
> driver: bnxt_en
> version: 1.7.25
> firmware-version: 212.0.107/1.9.1 pkg 212.0.112. – missing 0
> expansion-rom-version:
> bus-info: 0000:06:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: no
> supports-priv-flags: no
> 重启之后那个0就没了
> [6/26/2018 10:09 AM] Yuhong YH6 Wu:
>
> [root@localhost ~]# lspci -vv -s 06:00.0 |grep V0 -- lspci can read out complete string character.
> [V0] Vendor specific: 212.0.112.0
> 这里看到有
>
>
>
> From: Yuhong YH6 Wu
> Sent: Tuesday, June 26, 2018 9:20 AM
> To: Qinwei QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent
> HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>; Ken Cheng4
> <kcheng4@lenovo.com<mailto:kcheng4@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Qinwei,
> But actual fw level is ‘212.0.112.’ and chg log is ‘Firmware Version: 212.0.112.0’ are you sure this is correct ?
>
> Hi Ken,
>
> If ‘212.0.112.’ fw is correct we need change the common code fix below issue from Broadcom.py.
>
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO | Broadcom FW Flash |
> 180625-11:26:32 INFO
> ----------------------------------------------------------------------
> ------------------------------
> 180625-11:26:32 INFO Fetching Broadcom information for location Rear
> Slot 2
> 180625-11:26:36 INFO Configuring <eth0>...
> 180625-11:26:36 INFO Configuring <eth1>...
> 180625-11:26:38 INFO Configuring <eth2>...
> 180625-11:26:40 INFO Configuring <eth3>...
> 180625-11:26:42 INFO Configuring <eth4>...
> 180625-11:26:44 INFO Configuring <eth5>...
> 180625-11:26:46 INFO Configuring <eth6>...
> 180625-11:26:46 INFO Configuring <eth7>...
> 180625-11:26:48 INFO Configuring <eth8>...
> 180625-11:26:50 INFO Configuring <eth9>...
> 180625-11:26:52 INFO Configuring <eth10>...
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO Verified Broadcom [Slot 2] firmware level
> actual(=5719-v1.47) == expected(=5719-v1.47)
> 180625-11:26:56 INFO Fetching Broadcom information for location Rear
> Slot 1
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO pattern:\.|-v|-,version:212.0.112.
> 180625-11:26:57 ERR* Unhandled Exception has been thrown
> 180625-11:26:57 EXC** Traceback (most recent call last):
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/platform/modules/Run.py", line 384, in runmain
> 180625-11:26:57 EXC** result = func(*bares, **keywords)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/tests/broadcom_code_test.py", line 37, in main
> 180625-11:26:57 EXC** broadcom.verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 180, in verify_firmware_level
> 180625-11:26:57 EXC** result, expected, actual = self._verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 193, in _verify_firmware_level
> 180625-11:26:57 EXC** actual_parts = version_tuple(actual)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in version_tuple
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in <genexpr>
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** ValueError: invalid literal for int() with base 16: ''
> 180625-11:26:57 FAIL FAIL
> 180625-11:26:57 TESTE FAIL broadcom_code_test.py flash
>
>
> From: Qinwei QW1 Yu
> Sent: Monday, June 25, 2018 6:50 PM
> To: Yuhong YH6 Wu <wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>>; Vincent
> HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Yuhong
>
> The version in adapter VPD is correct.
> I suppose it is caused by ethtool.
> Different ethtool version has different display. See attachment.
> I believe it has same problem for other vendor adapters when the last number of FW version is 0.
>
> Best Regards!
>
> -Qinwei
> NIC Engineer
>
> From: Yuhong YH6 Wu
> Sent: Monday, June 25, 2018 1:29 PM
> To: Qinwei QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent
> HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64
> issue
>
> Hi Qinwei,
> Per talk in lync bnxt_en fw show at ‘212.0.112.’ but actually need is ‘212.0.112.0’ from 18b bin file ‘brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64.bin’
> Pls help to confirm this.
>
> [root@localhost ~]# ethtool -i eth5
> driver: bnxt_en
> version: 1.7.25
> firmware-version: 212.0.107/1.9.1 pkg 212.0.112.
> expansion-rom-version:
> bus-info: 0000:30:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: no
> supports-priv-flags: no
>
> failed in test process as below info:
>
>
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO | Broadcom FW Flash |
> 180625-11:26:32 INFO
> ----------------------------------------------------------------------
> ------------------------------
> 180625-11:26:32 INFO Fetching Broadcom information for location Rear
> Slot 2
> 180625-11:26:36 INFO Configuring <eth0>...
> 180625-11:26:36 INFO Configuring <eth1>...
> 180625-11:26:38 INFO Configuring <eth2>...
> 180625-11:26:40 INFO Configuring <eth3>...
> 180625-11:26:42 INFO Configuring <eth4>...
> 180625-11:26:44 INFO Configuring <eth5>...
> 180625-11:26:46 INFO Configuring <eth6>...
> 180625-11:26:46 INFO Configuring <eth7>...
> 180625-11:26:48 INFO Configuring <eth8>...
> 180625-11:26:50 INFO Configuring <eth9>...
> 180625-11:26:52 INFO Configuring <eth10>...
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO Verified Broadcom [Slot 2] firmware level
> actual(=5719-v1.47) == expected(=5719-v1.47)
> 180625-11:26:56 INFO Fetching Broadcom information for location Rear
> Slot 1
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO pattern:\.|-v|-,version:212.0.112.
> 180625-11:26:57 ERR* Unhandled Exception has been thrown
> 180625-11:26:57 EXC** Traceback (most recent call last):
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/platform/modules/Run.py", line 384, in runmain
> 180625-11:26:57 EXC** result = func(*bares, **keywords)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/tests/broadcom_code_test.py", line 37, in main
> 180625-11:26:57 EXC** broadcom.verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 180, in verify_firmware_level
> 180625-11:26:57 EXC** result, expected, actual = self._verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 193, in _verify_firmware_level
> 180625-11:26:57 EXC** actual_parts = version_tuple(actual)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in version_tuple
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in <genexpr>
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** ValueError: invalid literal for int() with base 16: ''
> 180625-11:26:57 FAIL FAIL
> 180625-11:26:57 TESTE FAIL broadcom_code_test.py flash
>
> Globa Test Engineer
> Email: wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>
>
--
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: [RFC net-next 08/15] net: lora: sx1276: Add debugfs
From: Jiri Pirko @ 2018-07-02 16:26 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180701110804.32415-9-afaerber@suse.de>
Sun, Jul 01, 2018 at 01:07:57PM CEST, afaerber@suse.de wrote:
>Allow some interactive inspection at runtime via debugfs.
>
>Signed-off-by: Andreas Färber <afaerber@suse.de>
>---
> drivers/net/lora/sx1276.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 132 insertions(+)
>
>diff --git a/drivers/net/lora/sx1276.c b/drivers/net/lora/sx1276.c
>index d6732111247a..1072019cfcc1 100644
>--- a/drivers/net/lora/sx1276.c
>+++ b/drivers/net/lora/sx1276.c
>@@ -5,6 +5,7 @@
> * Copyright (c) 2016-2018 Andreas Färber
> */
>
>+#include <linux/debugfs.h>
> #include <linux/delay.h>
> #include <linux/lora.h>
> #include <linux/module.h>
>@@ -61,6 +62,8 @@ struct sx1276_priv {
>
> struct workqueue_struct *wq;
> struct work_struct tx_work;
>+
>+ struct dentry *debugfs;
> };
>
> static int sx1276_read_single(struct spi_device *spi, u8 reg, u8 *val)
>@@ -416,6 +419,128 @@ static const struct net_device_ops sx1276_netdev_ops = {
> .ndo_start_xmit = sx1276_loradev_start_xmit,
> };
>
>+static ssize_t sx1276_freq_read(struct file *file, char __user *user_buf,
>+ size_t count, loff_t *ppos)
>+{
>+ struct net_device *netdev = file->private_data;
>+ struct sx1276_priv *priv = netdev_priv(netdev);
>+ struct spi_device *spi = priv->spi;
>+ ssize_t size;
>+ char *buf;
>+ int ret;
>+ u8 msb, mid, lsb;
>+ u32 freq_xosc;
>+ unsigned long long frf;
>+
>+ ret = of_property_read_u32(spi->dev.of_node, "clock-frequency", &freq_xosc);
>+ if (ret)
>+ return 0;
>+
>+ mutex_lock(&priv->spi_lock);
>+
>+ ret = sx1276_read_single(spi, REG_FRF_MSB, &msb);
>+ if (!ret)
>+ ret = sx1276_read_single(spi, REG_FRF_MID, &mid);
>+ if (!ret)
>+ ret = sx1276_read_single(spi, REG_FRF_LSB, &lsb);
>+
>+ mutex_unlock(&priv->spi_lock);
>+
>+ if (ret)
>+ return 0;
>+
>+ frf = freq_xosc;
>+ frf *= ((ulong)msb << 16) | ((ulong)mid << 8) | lsb;
>+ frf /= (1 << 19);
>+
>+ buf = kasprintf(GFP_KERNEL, "%llu\n", frf);
>+ if (!buf)
>+ return 0;
>+
>+ size = simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));
>+ kfree(buf);
>+
>+ return size;
>+}
>+
>+static const struct file_operations sx1276_freq_fops = {
>+ .owner = THIS_MODULE,
>+ .open = simple_open,
>+ .read = sx1276_freq_read,
>+};
>+
>+static ssize_t sx1276_state_read(struct file *file, char __user *user_buf,
>+ size_t count, loff_t *ppos)
>+{
>+ struct net_device *netdev = file->private_data;
>+ struct sx1276_priv *priv = netdev_priv(netdev);
>+ struct spi_device *spi = priv->spi;
>+ ssize_t size;
>+ char *buf;
>+ int len = 0;
>+ int ret;
>+ u8 val;
>+ bool lora_mode = true;
>+ const int max_len = 4096;
>+
>+ buf = kzalloc(max_len, GFP_KERNEL);
>+ if (!buf)
>+ return 0;
>+
>+ mutex_lock(&priv->spi_lock);
>+
>+ ret = sx1276_read_single(spi, REG_OPMODE, &val);
>+ if (!ret) {
>+ len += snprintf(buf + len, max_len - len, "RegOpMode = 0x%02x\n", val);
>+ lora_mode = (val & REG_OPMODE_LONG_RANGE_MODE) != 0;
>+ }
>+
>+ ret = sx1276_read_single(spi, REG_FRF_MSB, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegFrMsb = 0x%02x\n", val);
>+ ret = sx1276_read_single(spi, REG_FRF_MID, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegFrMid = 0x%02x\n", val);
>+ ret = sx1276_read_single(spi, REG_FRF_LSB, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegFrLsb = 0x%02x\n", val);
>+
>+ ret = sx1276_read_single(spi, REG_PA_CONFIG, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegPaConfig = 0x%02x\n", val);
>+
>+ if (lora_mode) {
>+ ret = sx1276_read_single(spi, LORA_REG_IRQ_FLAGS_MASK, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegIrqFlagsMask = 0x%02x\n", val);
>+
>+ ret = sx1276_read_single(spi, LORA_REG_IRQ_FLAGS, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegIrqFlags = 0x%02x\n", val);
>+
>+ ret = sx1276_read_single(spi, LORA_REG_SYNC_WORD, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegSyncWord = 0x%02x\n", val);
>+ }
>+
>+ ret = sx1276_read_single(spi, REG_PA_DAC, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegPaDac = 0x%02x\n", val);
>+
>+ mutex_unlock(&priv->spi_lock);
>+
>+ size = simple_read_from_buffer(user_buf, count, ppos, buf, len);
>+ kfree(buf);
>+
>+ return size;
>+}
>+
>+static const struct file_operations sx1276_state_fops = {
>+ .owner = THIS_MODULE,
>+ .open = simple_open,
>+ .read = sx1276_state_read,
>+};
>+
> static int sx1276_probe(struct spi_device *spi)
> {
> struct net_device *netdev;
>@@ -566,6 +691,10 @@ static int sx1276_probe(struct spi_device *spi)
> return ret;
> }
>
>+ priv->debugfs = debugfs_create_dir(dev_name(&spi->dev), NULL);
>+ debugfs_create_file("state", S_IRUGO, priv->debugfs, netdev, &sx1276_state_fops);
>+ debugfs_create_file("frequency", S_IRUGO, priv->debugfs, netdev, &sx1276_freq_fops);
Hmm. These look like useful information not only for debugging. I think
it would be worth to expose these via some standard uapi. Like generic
netlink, similar to nl80211
>+
> dev_info(&spi->dev, "SX1276 module probed (SX%d)", model);
>
> return 0;
>@@ -574,6 +703,9 @@ static int sx1276_probe(struct spi_device *spi)
> static int sx1276_remove(struct spi_device *spi)
> {
> struct net_device *netdev = spi_get_drvdata(spi);
>+ struct sx1276_priv *priv = netdev_priv(netdev);
>+
>+ debugfs_remove_recursive(priv->debugfs);
>
> unregister_loradev(netdev);
> free_loradev(netdev);
>--
>2.16.4
>
^ permalink raw reply
* Re: [RFC net-next 05/15] HACK: net: lora: Deal with .poll_mask in 4.18-rc2
From: Jiri Pirko @ 2018-07-02 16:22 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180701110804.32415-6-afaerber@suse.de>
Sun, Jul 01, 2018 at 01:07:54PM CEST, afaerber@suse.de wrote:
>linux-next and 4.18-rc2 both identify as LINUX_VERSION(4,18,0), but
>commit a11e1d432b51f63ba698d044441284a661f01144 (Revert changes to
>convert to ->poll_mask() and aio IOCB_CMD_POLL) reverted .poll_mask
>to .poll again.
>
>Signed-off-by: Andreas Färber <afaerber@suse.de>
>---
> net/lora/dgram.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
>diff --git a/net/lora/dgram.c b/net/lora/dgram.c
>index 4d931fd3778a..ef56fd90e762 100644
>--- a/net/lora/dgram.c
>+++ b/net/lora/dgram.c
>@@ -217,7 +217,11 @@ const struct proto_ops dgram_proto_ops = {
> .socketpair = sock_no_socketpair,
> .accept = sock_no_accept,
> .getname = dgram_getname,
>+#if 0 /* LINUX_VERSION_CODE >= LINUX_VERSION(4, 18, 0) */
>+ .poll_mask = datagram_poll_mask,
>+#else
I guess that you sent this patch by mistake...
> .poll = datagram_poll,
>+#endif
> .ioctl = dgram_ioctl,
> .listen = sock_no_listen,
> .shutdown = sock_no_shutdown,
>--
>2.16.4
>
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Mark Brown @ 2018-07-02 16:12 UTC (permalink / raw)
To: Andreas Färber
Cc: Steve deRosier, Matthias Brugger, Jiri Pirko, Ben Whitten, netdev,
Marcel Holtmann, Dollar Chen, linux-kernel, Michael Röder,
Janus Piwek, linux-spi, Jian-Hong Pan, Ken Yu, David S . Miller,
linux-arm-kernel
In-Reply-To: <20180701110804.32415-16-afaerber@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1719 bytes --]
On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
> +{
> + int ret;
> +
> + dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> +
> + if (enable)
> + return;
> +
> + ret = sx1301_radio_set_cs(spi->controller, enable);
> + if (ret)
> + dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
> +}
So we never disable chip select?
> + if (tx_buf) {
> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
This looks confused. We're in an if (tx_buf) block but there's a use of
the ternery operator that appears to be checking if we have a tx_buf?
> + if (ret) {
> + dev_err(&spi->dev, "SPI radio address write failed\n");
> + return ret;
> + }
> +
> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> + if (ret) {
> + dev_err(&spi->dev, "SPI radio data write failed\n");
> + return ret;
> + }
This looks awfully like you're coming in at the wrong abstraction layer
and the hardware actually implements a register abstraction rather than
a SPI one so you should be using regmap as the abstraction.
> + if (rx_buf) {
> + ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
> + if (ret) {
> + dev_err(&spi->dev, "SPI radio data read failed\n");
> + return ret;
> + }
> + }
For a read we never set an address?
> +static void sx1301_radio_setup(struct spi_controller *ctrl)
> +{
> + ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
This controller has no chip select but we provided a set_cs operation?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 net-next 0/9] Handle multiple received packets at each stage
From: David Ahern @ 2018-07-02 15:40 UTC (permalink / raw)
To: Edward Cree, davem; +Cc: netdev
In-Reply-To: <5bf84d99-8f77-54ee-7543-ada13a730361@solarflare.com>
On 7/2/18 9:11 AM, Edward Cree wrote:
> This patch series adds the capability for the network stack to receive a
> list of packets and process them as a unit, rather than handling each
> packet singly in sequence. This is done by factoring out the existing
> datapath code at each layer and wrapping it in list handling code.
>
...
> drivers/net/ethernet/sfc/efx.c | 12 +++
> drivers/net/ethernet/sfc/net_driver.h | 3 +
> drivers/net/ethernet/sfc/rx.c | 7 +-
> include/linux/list.h | 30 ++++++
> include/linux/netdevice.h | 4 +
> include/linux/netfilter.h | 22 +++++
> include/net/ip.h | 2 +
> include/trace/events/net.h | 7 ++
> net/core/dev.c | 174 ++++++++++++++++++++++++++++++++--
> net/ipv4/af_inet.c | 1 +
> net/ipv4/ip_input.c | 114 ++++++++++++++++++++--
> 11 files changed, 360 insertions(+), 16 deletions(-)
>
Nice work. Have you looked at IPv6 support yet?
^ permalink raw reply
* Re: [PATCH] net: stmmac_tc: use 64-bit arithmetic instead of 32-bit
From: Jose Abreu @ 2018-07-02 15:19 UTC (permalink / raw)
To: Gustavo A. R. Silva, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller
Cc: netdev, linux-kernel
In-Reply-To: <20180702120932.GA13079@embeddedor.com>
On 02-07-2018 13:09, Gustavo A. R. Silva wrote:
> Add suffix UL to constant 1024 in order to give the compiler complete
> information about the proper arithmetic to use. Notice that this
> constant is used in a context that expects an expression of type
> u64 (64 bits, unsigned) and following expressions are currently
> being evaluated using 32-bit arithmetic:
>
> qopt->idleslope * 1024 * ptr
> qopt->hicredit * 1024 * 8
> qopt->locredit * 1024 * 8
>
> Addresses-Coverity-ID: 1470246 ("Unintentional integer overflow")
> Addresses-Coverity-ID: 1470248 ("Unintentional integer overflow")
> Addresses-Coverity-ID: 1470249 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
Acked-by: Jose Abreu <joabreu@synopsys.com>
Thanks!
Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: Compiler warnings in kernel 4.14.51
From: David Ahern @ 2018-07-02 15:18 UTC (permalink / raw)
To: Enrico Mioso, netdev
Cc: David S. Miller, Daniel Borkmann, Kirill Tkhai, Jakub Kicinski,
Alexei Starovoitov, Rasmus Villemoes, John Fastabend,
Jesper Dangaard Brouer
In-Reply-To: <20180701203507.GA15211@mStation.localdomain>
On 7/1/18 2:35 PM, Enrico Mioso wrote:
> Hello!
>
> While compiling kernel 4.14.51 I got the following warnings:
> CC net/core/dev.o
> net/core/dev.c: In function 'validate_xmit_skb_list':
> net/core/dev.c:3121:15: warning: 'tail' may be used uninitialized in this function [-Wmaybe-uninitialized]
> ...
>
> CC net/ipv4/fib_trie.o
> net/ipv4/fib_trie.c: In function 'fib_trie_unmerge':
> net/ipv4/fib_trie.c:1749:8: warning: 'local_tp' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> The kernel has been compiled for the MIPS architecture, little-endian 32-bit.
Not seen with x86-64, Debian stretch. In both cases the compiler should
be able to see they are set before use.
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: notify when a delayed ack is sent
From: Neal Cardwell @ 2018-07-02 15:17 UTC (permalink / raw)
To: Lawrence Brakmo
Cc: Netdev, Kernel Team, bmatheny, ast, Yuchung Cheng, Steve Ibanez,
Eric Dumazet
In-Reply-To: <20180630014815.2881895-2-brakmo@fb.com>
On Fri, Jun 29, 2018 at 9:48 PM Lawrence Brakmo <brakmo@fb.com> wrote:
>
> DCTCP depends on the CA_EVENT_NON_DELAYED_ACK and CA_EVENT_DELAYED_ACK
> notifications to keep track if it needs to send an ACK for packets that
> were received with a particular ECN state but whose ACK was delayed.
>
> Under some circumstances, for example when a delayed ACK is sent with a
> data packet, DCTCP state was not being updated due to a lack of
> notification that the previously delayed ACK was sent. As a result, it
> would sometimes send a duplicate ACK when a new data packet arrived.
>
> This patch insures that DCTCP's state is correctly updated so it will
> not send the duplicate ACK.
>
> Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
> ---
> net/ipv4/tcp_output.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index f8f6129160dd..41f6ad7a21e4 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -172,6 +172,8 @@ static inline void tcp_event_ack_sent(struct sock *sk, unsigned int pkts)
> __sock_put(sk);
> }
> tcp_dec_quickack_mode(sk, pkts);
> + if (inet_csk_ack_scheduled(sk))
> + tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK);
> inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
> }
Thanks for this fix! Seems like this would work, but if I am reading
this correctly then it seems like this would cause a duplicate call to
tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK) when we are sending a pure
ACK (delayed or non-delayed):
(1) once from tcp_send_ack() before we send the ACK:
tcp_send_ack(struct sock *sk)
-> tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK);
(2) then again from tcp_event_ack_sent() after we have sent the ACK:
tcp_event_ack_sent()
-> if (inet_csk_ack_scheduled(sk))
tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK);
What if we remove the original CA_EVENT_NON_DELAYED_ACK call and just
replace it with your new one? (not compiled, not tested):
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 3889dcd4868d4..bddb49617d9be 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -184,6 +184,8 @@ static inline void tcp_event_ack_sent(struct sock
*sk, unsigned int pkts)
__sock_put(sk);
}
tcp_dec_quickack_mode(sk, pkts);
+ if (inet_csk_ack_scheduled(sk))
+ tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK);
inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
}
@@ -3836,8 +3838,6 @@ void tcp_send_ack(struct sock *sk)
if (sk->sk_state == TCP_CLOSE)
return;
- tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK);
-
/* We are not putting this on the write queue, so
* tcp_transmit_skb() will set the ownership to this
* sock.
Aside from lower CPU overhead, one nice benefit of that is that we
then only call tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK) in one
place, which might be a little easier to reason about.
Does that work?
neal
^ permalink raw reply related
* Re: incomplete firmware-version shown in ethtool -i
From: John W. Linville @ 2018-07-02 15:06 UTC (permalink / raw)
To: Gang Gang10 Liu; +Cc: netdev@vger.kernel.org
In-Reply-To: <CB4BD528EE74B3468883651D71AA4268767B8308@CNMAILEX03.lenovo.com>
On Wed, Jun 27, 2018 at 07:54:39AM +0000, Gang Gang10 Liu wrote:
> Dear,
>
> I study that the ethtool only can show 31 characters firmware version, is it NIC driver not followed ethtool spec or
> Can we have any other way to get the full firmware version?
>
I think the bnxt team is doing what they can to make as much
information available as possible. In this case, they seem to be
trying to make versioning info about the firmware package available
along with the info about the firmware version itself, and together
just barely overflowing the available space in the ethtool structure.
I'll leave it to you and/or Broadcom to determine whether or not that
is a bug that needs to be changed.
In the meanwhile, from your quoted message it seems that lspci can
give you the correct package version information for the device.
Good luck!
John
>
> Thanks!
>
>
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif]
>
> Gang Liu 刘刚
> Global Advisory Testing Engineer
>
> DCG Test Strategy and Automation
> Lenovo SZ
>
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/Email%20Gifs/T.gif]+86 13620981830
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/Email%20Gifs/E.gif]liugang10@lenovo.com<mailto:rrivera2@lenovo.com>
>
>
>
> Lenovo.com <http://www.lenovo.com/>
> Twitter<http://twitter.com/lenovo> | Facebook<http://www.facebook.com/lenovo> | Instagram<https://instagram.com/lenovo> | Blogs<http://blog.lenovo.com/> | Forums<http://forums.lenovo.com/>
>
>
> [The-Lenovo-Way]
>
>
>
>
>
>
> From: Gang Gang10 Liu
> Sent: Wednesday, June 27, 2018 3:13 PM
> To: Ken Cheng4 <kcheng4@lenovo.com>; Yuhong YH6 Wu <wuyh6@lenovo.com>; Qinwei QW1 Yu <yuqw1@lenovo.com>; Vincent HY1 Long <longhy1@lenovo.com>; -Product GTE <-Product_GTE@lenovo.com>
> Cc: Frank Y Wu <frankwu@lenovo.com>
> Subject: RE: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi all,
>
>
> From ethtool source code, the root cause for this issue is:
>
> the internal buffer for firmware-version in ethtool is 32 (include the string tail zero), so it only can show 31 characters version.
> But the actual firmware-version got from NIC driver is large than 32.
>
> struct ethtool_drvinfo {
> __u32 cmd;
> char driver[32];
> char version[32];
> char fw_version[ETHTOOL_FWVERS_LEN];
> …
>
> #define ETHTOOL_FWVERS_LEN 32
>
>
>
>
> From: Ken Cheng4
> Sent: Wednesday, June 27, 2018 2:44 PM
> To: Yuhong YH6 Wu <wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>>; Qinwei QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>; Gang Gang10 Liu <liugang10@lenovo.com<mailto:liugang10@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Yuhong,
>
> A merge request for common had been raised to fix the failure from this ethtool bug while testing firmware level of Broadcom cards.
> https://l3-prd01-rtp.labs.lenovo.com:4443/te/common/merge_requests/1513
>
>
> ===Background===
> Ethtool can not return correctly when the last number is zero like "212.0.107/1.9.1 pkg 212.0.112." <--missing 0 in the end.
>
> Code change is to:
>
> (1) get incomplete version like: 212.0.112
> (2) get complete version from lspci like "[V0] Vendor specific: 212.0.112.0"
> (3) compare the first three numbers with the firmware level from ethtool, ex:212.0.112
> (4) if the first three numbers match, fill incomplete firmware version from ethtool with correct one from lspci like: "212.0.107/1.9.1 pkg 212.0.112.0"
>
> I will let Liu Gang to review first and then submit another merge request for more_common.
>
>
>
> Ken Cheng
> Global TE Engineer
> LME
> Taiwan
>
>
> kcheng4@lenovo.com<mailto:e-mail>
> Ph: +886 2 8170-7580
> Fax: +886 2 2651-8246
>
>
> Shipping Address:
> Lenovo Technology B.V. Taiwan Branch
> 4F, No. 66 SanChong Road, NanGang,
> Taipei, Taiwan, 11502
> 荷蘭商聯想股份有限公司台灣分公司
> 台北市南港區三重路66號4樓
>
> [描述: Lenovo-For-Those-Who-Do]
>
>
>
> From: Ken Cheng4
> Sent: Tuesday, June 26, 2018 12:35 PM
> To: Yuhong YH6 Wu; Qinwei QW1 Yu; Vincent HY1 Long; -Product GTE
> Cc: Frank Y Wu
> Subject: RE: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Yuhong,
>
> We may need more time to investigate whether his statement is valid for the other component cards:
>
> === quoted from Qinwei ===
> I believe it has same problem for other vendor adapters when the last number of FW version is 0.
>
> But for now I think a quick patch might be better for EOQ support. I was thinking to add an additional zero in the end of fw string when the last digit returned from ethtool is period ‘.’ in order to avoid that tuple error.
>
> For example, to add an additional 0 after “212.0.112.” before it is sent to tuple actual_parts = version_tuple(actual)
>
>
> Ken Cheng
> Global TE Engineer
> LME
> Taiwan
>
>
> kcheng4@lenovo.com<mailto:e-mail>
> Ph: +886 2 8170-7580
> Fax: +886 2 2651-8246
>
>
> Shipping Address:
> Lenovo Technology B.V. Taiwan Branch
> 4F, No. 66 SanChong Road, NanGang,
> Taipei, Taiwan, 11502
> 荷蘭商聯想股份有限公司台灣分公司
> 台北市南港區三重路66號4樓
>
> [描述: Lenovo-For-Those-Who-Do]
>
>
>
> From: Yuhong YH6 Wu
> Sent: Tuesday, June 26, 2018 10:41 AM
> To: Qinwei QW1 Yu; Vincent HY1 Long; -Product GTE; Ken Cheng4
> Cc: Frank Y Wu
> Subject: RE: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Ken,
>
> Pre talk with Dev Qinwei brcm fw show have some problem by ethtool whether able to use lspci common replace ethtool to read fw level as below.
>
> [6/26/2018 10:07 AM] Yuhong YH6 Wu:
>
> [root@localhost ~]# ethtool -i eth2
> driver: bnxt_en
> version: 1.7.25
> firmware-version: 212.0.107/1.9.1 pkg 212.0.112. – missing 0
> expansion-rom-version:
> bus-info: 0000:06:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: no
> supports-priv-flags: no
> 重启之后那个0就没了
> [6/26/2018 10:09 AM] Yuhong YH6 Wu:
>
> [root@localhost ~]# lspci -vv -s 06:00.0 |grep V0 -- lspci can read out complete string character.
> [V0] Vendor specific: 212.0.112.0
> 这里看到有
>
>
>
> From: Yuhong YH6 Wu
> Sent: Tuesday, June 26, 2018 9:20 AM
> To: Qinwei QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>; Ken Cheng4 <kcheng4@lenovo.com<mailto:kcheng4@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Qinwei,
> But actual fw level is ‘212.0.112.’ and chg log is ‘Firmware Version: 212.0.112.0’ are you sure this is correct ?
>
> Hi Ken,
>
> If ‘212.0.112.’ fw is correct we need change the common code fix below issue from Broadcom.py.
>
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO | Broadcom FW Flash |
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO Fetching Broadcom information for location Rear Slot 2
> 180625-11:26:36 INFO Configuring <eth0>...
> 180625-11:26:36 INFO Configuring <eth1>...
> 180625-11:26:38 INFO Configuring <eth2>...
> 180625-11:26:40 INFO Configuring <eth3>...
> 180625-11:26:42 INFO Configuring <eth4>...
> 180625-11:26:44 INFO Configuring <eth5>...
> 180625-11:26:46 INFO Configuring <eth6>...
> 180625-11:26:46 INFO Configuring <eth7>...
> 180625-11:26:48 INFO Configuring <eth8>...
> 180625-11:26:50 INFO Configuring <eth9>...
> 180625-11:26:52 INFO Configuring <eth10>...
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO Verified Broadcom [Slot 2] firmware level actual(=5719-v1.47) == expected(=5719-v1.47)
> 180625-11:26:56 INFO Fetching Broadcom information for location Rear Slot 1
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO pattern:\.|-v|-,version:212.0.112.
> 180625-11:26:57 ERR* Unhandled Exception has been thrown
> 180625-11:26:57 EXC** Traceback (most recent call last):
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/platform/modules/Run.py", line 384, in runmain
> 180625-11:26:57 EXC** result = func(*bares, **keywords)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/tests/broadcom_code_test.py", line 37, in main
> 180625-11:26:57 EXC** broadcom.verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 180, in verify_firmware_level
> 180625-11:26:57 EXC** result, expected, actual = self._verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 193, in _verify_firmware_level
> 180625-11:26:57 EXC** actual_parts = version_tuple(actual)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in version_tuple
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in <genexpr>
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** ValueError: invalid literal for int() with base 16: ''
> 180625-11:26:57 FAIL FAIL
> 180625-11:26:57 TESTE FAIL broadcom_code_test.py flash
>
>
> From: Qinwei QW1 Yu
> Sent: Monday, June 25, 2018 6:50 PM
> To: Yuhong YH6 Wu <wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>>; Vincent HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Yuhong
>
> The version in adapter VPD is correct.
> I suppose it is caused by ethtool.
> Different ethtool version has different display. See attachment.
> I believe it has same problem for other vendor adapters when the last number of FW version is 0.
>
> Best Regards!
>
> -Qinwei
> NIC Engineer
>
> From: Yuhong YH6 Wu
> Sent: Monday, June 25, 2018 1:29 PM
> To: Qinwei QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Qinwei,
> Per talk in lync bnxt_en fw show at ‘212.0.112.’ but actually need is ‘212.0.112.0’ from 18b bin file ‘brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64.bin’
> Pls help to confirm this.
>
> [root@localhost ~]# ethtool -i eth5
> driver: bnxt_en
> version: 1.7.25
> firmware-version: 212.0.107/1.9.1 pkg 212.0.112.
> expansion-rom-version:
> bus-info: 0000:30:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: no
> supports-priv-flags: no
>
> failed in test process as below info:
>
>
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO | Broadcom FW Flash |
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO Fetching Broadcom information for location Rear Slot 2
> 180625-11:26:36 INFO Configuring <eth0>...
> 180625-11:26:36 INFO Configuring <eth1>...
> 180625-11:26:38 INFO Configuring <eth2>...
> 180625-11:26:40 INFO Configuring <eth3>...
> 180625-11:26:42 INFO Configuring <eth4>...
> 180625-11:26:44 INFO Configuring <eth5>...
> 180625-11:26:46 INFO Configuring <eth6>...
> 180625-11:26:46 INFO Configuring <eth7>...
> 180625-11:26:48 INFO Configuring <eth8>...
> 180625-11:26:50 INFO Configuring <eth9>...
> 180625-11:26:52 INFO Configuring <eth10>...
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO Verified Broadcom [Slot 2] firmware level actual(=5719-v1.47) == expected(=5719-v1.47)
> 180625-11:26:56 INFO Fetching Broadcom information for location Rear Slot 1
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO pattern:\.|-v|-,version:212.0.112.
> 180625-11:26:57 ERR* Unhandled Exception has been thrown
> 180625-11:26:57 EXC** Traceback (most recent call last):
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/platform/modules/Run.py", line 384, in runmain
> 180625-11:26:57 EXC** result = func(*bares, **keywords)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/tests/broadcom_code_test.py", line 37, in main
> 180625-11:26:57 EXC** broadcom.verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 180, in verify_firmware_level
> 180625-11:26:57 EXC** result, expected, actual = self._verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 193, in _verify_firmware_level
> 180625-11:26:57 EXC** actual_parts = version_tuple(actual)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in version_tuple
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in <genexpr>
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** ValueError: invalid literal for int() with base 16: ''
> 180625-11:26:57 FAIL FAIL
> 180625-11:26:57 TESTE FAIL broadcom_code_test.py flash
>
> Globa Test Engineer
> Email: wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>
>
--
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
* [PATCH v4 net-next 9/9] net: don't bother calling list RX functions on empty lists
From: Edward Cree @ 2018-07-02 15:14 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <5bf84d99-8f77-54ee-7543-ada13a730361@solarflare.com>
Generally the check should be very cheap, as the sk_buff_head is in cache.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
net/core/dev.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4c5ebfab9bc8..d6084b0cd9ce 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4773,7 +4773,8 @@ static void __netif_receive_skb_list(struct list_head *head)
/* Handle the previous sublist */
list_cut_before(&sublist, head, &skb->list);
- __netif_receive_skb_list_core(&sublist, pfmemalloc);
+ if (!list_empty(&sublist))
+ __netif_receive_skb_list_core(&sublist, pfmemalloc);
pfmemalloc = !pfmemalloc;
/* See comments in __netif_receive_skb */
if (pfmemalloc)
@@ -4783,7 +4784,8 @@ static void __netif_receive_skb_list(struct list_head *head)
}
}
/* Handle the remaining sublist */
- __netif_receive_skb_list_core(head, pfmemalloc);
+ if (!list_empty(head))
+ __netif_receive_skb_list_core(head, pfmemalloc);
/* Restore pflags */
if (pfmemalloc)
memalloc_noreclaim_restore(noreclaim_flag);
@@ -4944,6 +4946,8 @@ void netif_receive_skb_list(struct list_head *head)
{
struct sk_buff *skb;
+ if (list_empty(head))
+ return;
list_for_each_entry(skb, head, list)
trace_netif_receive_skb_list_entry(skb);
netif_receive_skb_list_internal(head);
^ permalink raw reply related
* [PATCH v4 net-next 8/9] net: ipv4: listify ip_rcv_finish
From: Edward Cree @ 2018-07-02 15:14 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <5bf84d99-8f77-54ee-7543-ada13a730361@solarflare.com>
ip_rcv_finish_core(), if it does not drop, sets skb->dst by either early
demux or route lookup. The last step, calling dst_input(skb), is left to
the caller; in the listified case, we split to form sublists with a common
dst, but then ip_sublist_rcv_finish() just calls dst_input(skb) in a loop.
The next step in listification would thus be to add a list_input() method
to struct dst_entry.
Early demux is an indirect call based on iph->protocol; this is another
opportunity for listification which is not taken here (it would require
slicing up ip_rcv_finish_core() to allow splitting on protocol changes).
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
net/ipv4/ip_input.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 914240830bdf..24b9b0210aeb 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -307,7 +307,8 @@ static inline bool ip_rcv_options(struct sk_buff *skb)
return true;
}
-static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
+static int ip_rcv_finish_core(struct net *net, struct sock *sk,
+ struct sk_buff *skb)
{
const struct iphdr *iph = ip_hdr(skb);
int (*edemux)(struct sk_buff *skb);
@@ -393,7 +394,7 @@ static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
goto drop;
}
- return dst_input(skb);
+ return NET_RX_SUCCESS;
drop:
kfree_skb(skb);
@@ -405,6 +406,15 @@ static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
goto drop;
}
+static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
+{
+ int ret = ip_rcv_finish_core(net, sk, skb);
+
+ if (ret != NET_RX_DROP)
+ ret = dst_input(skb);
+ return ret;
+}
+
/*
* Main IP Receive routine.
*/
@@ -515,15 +525,47 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
ip_rcv_finish);
}
-static void ip_sublist_rcv(struct list_head *head, struct net_device *dev,
- struct net *net)
+static void ip_sublist_rcv_finish(struct list_head *head)
{
struct sk_buff *skb, *next;
+ list_for_each_entry_safe(skb, next, head, list)
+ dst_input(skb);
+}
+
+static void ip_list_rcv_finish(struct net *net, struct sock *sk,
+ struct list_head *head)
+{
+ struct dst_entry *curr_dst = NULL;
+ struct sk_buff *skb, *next;
+ struct list_head sublist;
+
+ list_for_each_entry_safe(skb, next, head, list) {
+ struct dst_entry *dst;
+
+ if (ip_rcv_finish_core(net, sk, skb) == NET_RX_DROP)
+ continue;
+
+ dst = skb_dst(skb);
+ if (curr_dst != dst) {
+ /* dispatch old sublist */
+ list_cut_before(&sublist, head, &skb->list);
+ if (!list_empty(&sublist))
+ ip_sublist_rcv_finish(&sublist);
+ /* start new sublist */
+ curr_dst = dst;
+ }
+ }
+ /* dispatch final sublist */
+ ip_sublist_rcv_finish(head);
+}
+
+static void ip_sublist_rcv(struct list_head *head, struct net_device *dev,
+ struct net *net)
+{
NF_HOOK_LIST(NFPROTO_IPV4, NF_INET_PRE_ROUTING, net, NULL,
head, dev, NULL, ip_rcv_finish);
- list_for_each_entry_safe(skb, next, head, list)
- ip_rcv_finish(net, NULL, skb);
+ ip_list_rcv_finish(net, NULL, head);
}
/* Receive a list of IP packets */
^ permalink raw reply related
* [PATCH v4 net-next 7/9] net: ipv4: listified version of ip_rcv
From: Edward Cree @ 2018-07-02 15:14 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <5bf84d99-8f77-54ee-7543-ada13a730361@solarflare.com>
Also involved adding a way to run a netfilter hook over a list of packets.
Rather than attempting to make netfilter know about lists (which would be
a major project in itself) we just let it call the regular okfn (in this
case ip_rcv_finish()) for any packets it steals, and have it give us back
a list of packets it's synchronously accepted (which normally NF_HOOK
would automatically call okfn() on, but we want to be able to potentially
pass the list to a listified version of okfn().)
The netfilter hooks themselves are indirect calls that still happen per-
packet (see nf_hook_entry_hookfn()), but again, changing that can be left
for future work.
There is potential for out-of-order receives if the netfilter hook ends up
synchronously stealing packets, as they will be processed before any
accepts earlier in the list. However, it was already possible for an
asynchronous accept to cause out-of-order receives, so presumably this is
considered OK.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
include/linux/netdevice.h | 3 +++
include/linux/netfilter.h | 22 +++++++++++++++
include/net/ip.h | 2 ++
net/core/dev.c | 8 +++---
net/ipv4/af_inet.c | 1 +
net/ipv4/ip_input.c | 68 ++++++++++++++++++++++++++++++++++++++++++-----
6 files changed, 94 insertions(+), 10 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e104b2e4a735..fe81a2bfcd08 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2291,6 +2291,9 @@ struct packet_type {
struct net_device *,
struct packet_type *,
struct net_device *);
+ void (*list_func) (struct list_head *,
+ struct packet_type *,
+ struct net_device *);
bool (*id_match)(struct packet_type *ptype,
struct sock *sk);
void *af_packet_priv;
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index dd2052f0efb7..5a5e0a2ab2a3 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -288,6 +288,20 @@ NF_HOOK(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk, struct
return ret;
}
+static inline void
+NF_HOOK_LIST(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk,
+ struct list_head *head, struct net_device *in, struct net_device *out,
+ int (*okfn)(struct net *, struct sock *, struct sk_buff *))
+{
+ struct sk_buff *skb, *next;
+
+ list_for_each_entry_safe(skb, next, head, list) {
+ int ret = nf_hook(pf, hook, net, sk, skb, in, out, okfn);
+ if (ret != 1)
+ list_del(&skb->list);
+ }
+}
+
/* Call setsockopt() */
int nf_setsockopt(struct sock *sk, u_int8_t pf, int optval, char __user *opt,
unsigned int len);
@@ -369,6 +383,14 @@ NF_HOOK(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk,
return okfn(net, sk, skb);
}
+static inline void
+NF_HOOK_LIST(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk,
+ struct list_head *head, struct net_device *in, struct net_device *out,
+ int (*okfn)(struct net *, struct sock *, struct sk_buff *))
+{
+ /* nothing to do */
+}
+
static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
struct sock *sk, struct sk_buff *skb,
struct net_device *indev, struct net_device *outdev,
diff --git a/include/net/ip.h b/include/net/ip.h
index 0d2281b4b27a..1de72f9cb23c 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -138,6 +138,8 @@ int ip_build_and_send_pkt(struct sk_buff *skb, const struct sock *sk,
struct ip_options_rcu *opt);
int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
struct net_device *orig_dev);
+void ip_list_rcv(struct list_head *head, struct packet_type *pt,
+ struct net_device *orig_dev);
int ip_local_deliver(struct sk_buff *skb);
int ip_mr_input(struct sk_buff *skb);
int ip_output(struct net *net, struct sock *sk, struct sk_buff *skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index edd67b1f1e12..4c5ebfab9bc8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4692,9 +4692,11 @@ static inline void __netif_receive_skb_list_ptype(struct list_head *head,
return;
if (list_empty(head))
return;
-
- list_for_each_entry_safe(skb, next, head, list)
- pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ if (pt_prev->list_func != NULL)
+ pt_prev->list_func(head, pt_prev, orig_dev);
+ else
+ list_for_each_entry_safe(skb, next, head, list)
+ pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
}
static void __netif_receive_skb_list_core(struct list_head *head, bool pfmemalloc)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 06b218a2870f..3ff7659c9afd 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1882,6 +1882,7 @@ fs_initcall(ipv4_offload_init);
static struct packet_type ip_packet_type __read_mostly = {
.type = cpu_to_be16(ETH_P_IP),
.func = ip_rcv,
+ .list_func = ip_list_rcv,
};
static int __init inet_init(void)
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 7582713dd18f..914240830bdf 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -408,10 +408,9 @@ static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
/*
* Main IP Receive routine.
*/
-int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt, struct net_device *orig_dev)
+static struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)
{
const struct iphdr *iph;
- struct net *net;
u32 len;
/* When the interface is in promisc. mode, drop all the crap
@@ -421,7 +420,6 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
goto drop;
- net = dev_net(dev);
__IP_UPD_PO_STATS(net, IPSTATS_MIB_IN, skb->len);
skb = skb_share_check(skb, GFP_ATOMIC);
@@ -489,9 +487,7 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
/* Must drop socket now because of tproxy. */
skb_orphan(skb);
- return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
- net, NULL, skb, dev, NULL,
- ip_rcv_finish);
+ return skb;
csum_error:
__IP_INC_STATS(net, IPSTATS_MIB_CSUMERRORS);
@@ -500,5 +496,63 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
drop:
kfree_skb(skb);
out:
- return NET_RX_DROP;
+ return NULL;
+}
+
+/*
+ * IP receive entry point
+ */
+int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
+ struct net_device *orig_dev)
+{
+ struct net *net = dev_net(dev);
+
+ skb = ip_rcv_core(skb, net);
+ if (skb == NULL)
+ return NET_RX_DROP;
+ return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
+ net, NULL, skb, dev, NULL,
+ ip_rcv_finish);
+}
+
+static void ip_sublist_rcv(struct list_head *head, struct net_device *dev,
+ struct net *net)
+{
+ struct sk_buff *skb, *next;
+
+ NF_HOOK_LIST(NFPROTO_IPV4, NF_INET_PRE_ROUTING, net, NULL,
+ head, dev, NULL, ip_rcv_finish);
+ list_for_each_entry_safe(skb, next, head, list)
+ ip_rcv_finish(net, NULL, skb);
+}
+
+/* Receive a list of IP packets */
+void ip_list_rcv(struct list_head *head, struct packet_type *pt,
+ struct net_device *orig_dev)
+{
+ struct net_device *curr_dev = NULL;
+ struct net *curr_net = NULL;
+ struct sk_buff *skb, *next;
+ struct list_head sublist;
+
+ list_for_each_entry_safe(skb, next, head, list) {
+ struct net_device *dev = skb->dev;
+ struct net *net = dev_net(dev);
+
+ skb = ip_rcv_core(skb, net);
+ if (skb == NULL)
+ continue;
+
+ if (curr_dev != dev || curr_net != net) {
+ /* dispatch old sublist */
+ list_cut_before(&sublist, head, &skb->list);
+ if (!list_empty(&sublist))
+ ip_sublist_rcv(&sublist, dev, net);
+ /* start new sublist */
+ curr_dev = dev;
+ curr_net = net;
+ }
+ }
+ /* dispatch final sublist */
+ ip_sublist_rcv(head, curr_dev, curr_net);
}
^ permalink raw reply related
* [PATCH v4 net-next 6/9] net: core: propagate SKB lists through packet_type lookup
From: Edward Cree @ 2018-07-02 15:13 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <5bf84d99-8f77-54ee-7543-ada13a730361@solarflare.com>
__netif_receive_skb_core() does a depressingly large amount of per-packet
work that can't easily be listified, because the another_round looping
makes it nontrivial to slice up into smaller functions.
Fortunately, most of that work disappears in the fast path:
* Hardware devices generally don't have an rx_handler
* Unless you're tcpdumping or something, there is usually only one ptype
* VLAN processing comes before the protocol ptype lookup, so doesn't force
a pt_prev deliver
so normally, __netif_receive_skb_core() will run straight through and pass
back the one ptype found in ptype_base[hash of skb->protocol].
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
net/core/dev.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 64 insertions(+), 8 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d2454678bc82..edd67b1f1e12 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4494,7 +4494,8 @@ static inline int nf_ingress(struct sk_buff *skb, struct packet_type **pt_prev,
return 0;
}
-static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
+static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc,
+ struct packet_type **ppt_prev)
{
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
@@ -4624,8 +4625,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
if (pt_prev) {
if (unlikely(skb_orphan_frags_rx(skb, GFP_ATOMIC)))
goto drop;
- else
- ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ *ppt_prev = pt_prev;
} else {
drop:
if (!deliver_exact)
@@ -4643,6 +4643,18 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
return ret;
}
+static int __netif_receive_skb_one_core(struct sk_buff *skb, bool pfmemalloc)
+{
+ struct net_device *orig_dev = skb->dev;
+ struct packet_type *pt_prev = NULL;
+ int ret;
+
+ ret = __netif_receive_skb_core(skb, pfmemalloc, &pt_prev);
+ if (pt_prev)
+ ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ return ret;
+}
+
/**
* netif_receive_skb_core - special purpose version of netif_receive_skb
* @skb: buffer to process
@@ -4663,19 +4675,63 @@ int netif_receive_skb_core(struct sk_buff *skb)
int ret;
rcu_read_lock();
- ret = __netif_receive_skb_core(skb, false);
+ ret = __netif_receive_skb_one_core(skb, false);
rcu_read_unlock();
return ret;
}
EXPORT_SYMBOL(netif_receive_skb_core);
-static void __netif_receive_skb_list_core(struct list_head *head, bool pfmemalloc)
+static inline void __netif_receive_skb_list_ptype(struct list_head *head,
+ struct packet_type *pt_prev,
+ struct net_device *orig_dev)
{
struct sk_buff *skb, *next;
+ if (!pt_prev)
+ return;
+ if (list_empty(head))
+ return;
+
list_for_each_entry_safe(skb, next, head, list)
- __netif_receive_skb_core(skb, pfmemalloc);
+ pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+}
+
+static void __netif_receive_skb_list_core(struct list_head *head, bool pfmemalloc)
+{
+ /* Fast-path assumptions:
+ * - There is no RX handler.
+ * - Only one packet_type matches.
+ * If either of these fails, we will end up doing some per-packet
+ * processing in-line, then handling the 'last ptype' for the whole
+ * sublist. This can't cause out-of-order delivery to any single ptype,
+ * because the 'last ptype' must be constant across the sublist, and all
+ * other ptypes are handled per-packet.
+ */
+ /* Current (common) ptype of sublist */
+ struct packet_type *pt_curr = NULL;
+ /* Current (common) orig_dev of sublist */
+ struct net_device *od_curr = NULL;
+ struct list_head sublist;
+ struct sk_buff *skb, *next;
+
+ list_for_each_entry_safe(skb, next, head, list) {
+ struct net_device *orig_dev = skb->dev;
+ struct packet_type *pt_prev = NULL;
+
+ __netif_receive_skb_core(skb, pfmemalloc, &pt_prev);
+ if (pt_curr != pt_prev || od_curr != orig_dev) {
+ /* dispatch old sublist */
+ list_cut_before(&sublist, head, &skb->list);
+ __netif_receive_skb_list_ptype(&sublist, pt_curr, od_curr);
+ /* start new sublist */
+ pt_curr = pt_prev;
+ od_curr = orig_dev;
+ }
+ }
+
+ /* dispatch final sublist */
+ __netif_receive_skb_list_ptype(head, pt_curr, od_curr);
}
static int __netif_receive_skb(struct sk_buff *skb)
@@ -4695,10 +4751,10 @@ static int __netif_receive_skb(struct sk_buff *skb)
* context down to all allocation sites.
*/
noreclaim_flag = memalloc_noreclaim_save();
- ret = __netif_receive_skb_core(skb, true);
+ ret = __netif_receive_skb_one_core(skb, true);
memalloc_noreclaim_restore(noreclaim_flag);
} else
- ret = __netif_receive_skb_core(skb, false);
+ ret = __netif_receive_skb_one_core(skb, false);
return ret;
}
^ 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