* Re: [net-next RFC PATCH v3 4/4] dt-bindings: Document bindings for Marvell Aquantia PHY
From: Conor Dooley @ 2023-11-03 13:08 UTC (permalink / raw)
To: Christian Marangi
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
Heiner Kallweit, Russell King, Robert Marko, Vladimir Oltean,
netdev, devicetree, linux-kernel
In-Reply-To: <20231102150032.10740-4-ansuelsmth@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]
Yo,
On Thu, Nov 02, 2023 at 04:00:32PM +0100, Christian Marangi wrote:
> Document bindings for Marvell Aquantia PHY.
>
> The Marvell Aquantia PHY require a firmware to work correctly and there
> at least 3 way to load this firmware.
>
> Describe all the different way and document the binding "firmware-name"
> to load the PHY firmware from userspace.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> Changes v3:
> - Make DT description more OS agnostic
> - Use custom select to fix dtbs checks
> Changes v2:
> - Add DT patch
>
> .../bindings/net/marvell,aquantia.yaml | 126 ++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/marvell,aquantia.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/marvell,aquantia.yaml b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
> new file mode 100644
> index 000000000000..d43cf28a4d61
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/marvell,aquantia.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell Aquantia Ethernet PHY
> +
> +maintainers:
> + - Christian Marangi <ansuelsmth@gmail.com>
> +
> +description: |
> + Marvell Aquantia Ethernet PHY require a firmware to be loaded to actually
> + work.
> +
> + This can be done and is implemented by OEM in 3 different way:
> + - Attached SPI directly to the PHY with the firmware. The PHY will
You a word here? Should that not be "SPI flash"?
> + self load the firmware in the presence of this configuration.
> + - Dedicated partition on system NAND with firmware in it. NVMEM
> + subsystem will be used and the declared NVMEM cell will load
> + the firmware to the PHY using the PHY mailbox interface.
> + - Manually provided firmware loaded from a file in the filesystem.
> +
> + If declared, NVMEM will always take priority over filesystem provided
> + firmware.
This section here reads entirely like "software policy". The first
bullet in your list is fine - as that is what the PHY will do itself.
The second and third bullets here seem like two different ways that
someone could integrate their system, and I am not objecting to either
of those ways of doing things.
The priority system that you mention however I don't think is suitable
for a description of the hardware - the PHY itself doesn't require that
an external-to-it flash device take priority over something in the
filesystem, right?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next V3] ptp: fix corrupted list in ptp_open
From: Edward Adam Davis @ 2023-11-03 13:15 UTC (permalink / raw)
To: jeremy
Cc: davem, habetsm.xilinx, linux-kernel, netdev, reibax,
richardcochran, syzbot+df3f3ef31f60781fa911
There is no lock protection when writing ptp->tsevqs in ptp_open(),
ptp_release(), which can cause data corruption, use mutex lock to avoid this
issue.
Moreover, ptp_release() should not be used to release the queue in ptp_read(),
and it should be deleted together.
Reported-and-tested-by: syzbot+df3f3ef31f60781fa911@syzkaller.appspotmail.com
Fixes: 8f5de6fb2453 ("ptp: support multiple timestamp event readers")
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
drivers/ptp/ptp_chardev.c | 12 ++++++++++--
drivers/ptp/ptp_clock.c | 3 +++
drivers/ptp/ptp_private.h | 1 +
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 282cd7d24077..6e9762a54b14 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -119,8 +119,13 @@ int ptp_open(struct posix_clock_context *pccontext, fmode_t fmode)
}
bitmap_set(queue->mask, 0, PTP_MAX_CHANNELS);
spin_lock_init(&queue->lock);
+ if (mutex_lock_interruptible(&ptp->tsevq_mux)) {
+ kfree(queue);
+ return -ERESTARTSYS;
+ }
list_add_tail(&queue->qlist, &ptp->tsevqs);
pccontext->private_clkdata = queue;
+ mutex_unlock(&ptp->tsevq_mux);
/* Debugfs contents */
sprintf(debugfsname, "0x%p", queue);
@@ -138,14 +143,19 @@ int ptp_open(struct posix_clock_context *pccontext, fmode_t fmode)
int ptp_release(struct posix_clock_context *pccontext)
{
struct timestamp_event_queue *queue = pccontext->private_clkdata;
+ struct ptp_clock *ptp =
+ container_of(pccontext->clk, struct ptp_clock, clock);
unsigned long flags;
if (queue) {
+ if (mutex_lock_interruptible(&ptp->tsevq_mux))
+ return -ERESTARTSYS;
debugfs_remove(queue->debugfs_instance);
pccontext->private_clkdata = NULL;
spin_lock_irqsave(&queue->lock, flags);
list_del(&queue->qlist);
spin_unlock_irqrestore(&queue->lock, flags);
+ mutex_unlock(&ptp->tsevq_mux);
bitmap_free(queue->mask);
kfree(queue);
}
@@ -585,7 +595,5 @@ ssize_t ptp_read(struct posix_clock_context *pccontext, uint rdflags,
free_event:
kfree(event);
exit:
- if (result < 0)
- ptp_release(pccontext);
return result;
}
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index 3d1b0a97301c..7930db6ec18d 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -176,6 +176,7 @@ static void ptp_clock_release(struct device *dev)
ptp_cleanup_pin_groups(ptp);
kfree(ptp->vclock_index);
+ mutex_destroy(&ptp->tsevq_mux);
mutex_destroy(&ptp->pincfg_mux);
mutex_destroy(&ptp->n_vclocks_mux);
/* Delete first entry */
@@ -247,6 +248,7 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
if (!queue)
goto no_memory_queue;
list_add_tail(&queue->qlist, &ptp->tsevqs);
+ mutex_init(&ptp->tsevq_mux);
queue->mask = bitmap_alloc(PTP_MAX_CHANNELS, GFP_KERNEL);
if (!queue->mask)
goto no_memory_bitmap;
@@ -356,6 +358,7 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
if (ptp->kworker)
kthread_destroy_worker(ptp->kworker);
kworker_err:
+ mutex_destroy(&ptp->tsevq_mux);
mutex_destroy(&ptp->pincfg_mux);
mutex_destroy(&ptp->n_vclocks_mux);
bitmap_free(queue->mask);
diff --git a/drivers/ptp/ptp_private.h b/drivers/ptp/ptp_private.h
index 52f87e394aa6..1525bd2059ba 100644
--- a/drivers/ptp/ptp_private.h
+++ b/drivers/ptp/ptp_private.h
@@ -44,6 +44,7 @@ struct ptp_clock {
struct pps_device *pps_source;
long dialed_frequency; /* remembers the frequency adjustment */
struct list_head tsevqs; /* timestamp fifo list */
+ struct mutex tsevq_mux; /* one process at a time reading the fifo */
struct mutex pincfg_mux; /* protect concurrent info->pin_config access */
wait_queue_head_t tsev_wq;
int defunct; /* tells readers to go away when clock is being removed */
--
2.25.1
^ permalink raw reply related
* Re: [net-next RFC PATCH v4 4/4] dt-bindings: Document bindings for Marvell Aquantia PHY
From: Conor Dooley @ 2023-11-03 13:15 UTC (permalink / raw)
To: Christian Marangi
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
Heiner Kallweit, Russell King, Robert Marko, Vladimir Oltean,
netdev, devicetree, linux-kernel
In-Reply-To: <20231103123532.687-4-ansuelsmth@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5245 bytes --]
Hey,
On Fri, Nov 03, 2023 at 01:35:32PM +0100, Christian Marangi wrote:
> Document bindings for Marvell Aquantia PHY.
>
> The Marvell Aquantia PHY require a firmware to work correctly and there
> at least 3 way to load this firmware.
>
> Describe all the different way and document the binding "firmware-name"
> to load the PHY firmware from userspace.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> Changes v3:
> - Make DT description more OS agnostic
> - Use custom select to fix dtbs checks
> Changes v2:
> - Add DT patch
Please, it's the merge window, there's even less reason than usual to
spit out versions less than 24h apart. This is the third version in 48
hours. As there are no changes to the binding in the v4 patch, please
take a look at
<https://lore.kernel.org/all/20231103-outboard-murkiness-e3256874c9a7@spud/>
I left a review there a few moments ago.
Thanks,
Conor.
> .../bindings/net/marvell,aquantia.yaml | 126 ++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/marvell,aquantia.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/marvell,aquantia.yaml b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
> new file mode 100644
> index 000000000000..d43cf28a4d61
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/marvell,aquantia.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell Aquantia Ethernet PHY
> +
> +maintainers:
> + - Christian Marangi <ansuelsmth@gmail.com>
> +
> +description: |
> + Marvell Aquantia Ethernet PHY require a firmware to be loaded to actually
> + work.
> +
> + This can be done and is implemented by OEM in 3 different way:
> + - Attached SPI directly to the PHY with the firmware. The PHY will
> + self load the firmware in the presence of this configuration.
> + - Dedicated partition on system NAND with firmware in it. NVMEM
> + subsystem will be used and the declared NVMEM cell will load
> + the firmware to the PHY using the PHY mailbox interface.
> + - Manually provided firmware loaded from a file in the filesystem.
> +
> + If declared, NVMEM will always take priority over filesystem provided
> + firmware.
> +
> +allOf:
> + - $ref: ethernet-phy.yaml#
> +
> +select:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ethernet-phy-id03a1.b445
> + - ethernet-phy-id03a1.b460
> + - ethernet-phy-id03a1.b4a2
> + - ethernet-phy-id03a1.b4d0
> + - ethernet-phy-id03a1.b4e0
> + - ethernet-phy-id03a1.b5c2
> + - ethernet-phy-id03a1.b4b0
> + - ethernet-phy-id03a1.b662
> + - ethernet-phy-id03a1.b712
> + - ethernet-phy-id31c3.1c12
> + required:
> + - compatible
> +
> +properties:
> + reg:
> + maxItems: 1
> +
> + firmware-name:
> + description: specify the name of PHY firmware to load
> +
> + nvmem-cells:
> + description: phandle to the firmware nvmem cell
> + maxItems: 1
> +
> + nvmem-cell-names:
> + const: firmware
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy@0 {
> + /* Only needed to make DT lint tools work. Do not copy/paste
> + * into real DTS files.
> + */
> + compatible = "ethernet-phy-id31c3.1c12",
> + "ethernet-phy-ieee802.3-c45";
> +
> + reg = <0>;
> + firmware-name = "AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x8_ID44776_VER1630.cld";
> + };
> +
> + ethernet-phy@1 {
> + /* Only needed to make DT lint tools work. Do not copy/paste
> + * into real DTS files.
> + */
> + compatible = "ethernet-phy-id31c3.1c12",
> + "ethernet-phy-ieee802.3-c45";
> +
> + reg = <0>;
> + nvmem-cells = <&aqr_fw>;
> + nvmem-cell-names = "firmware";
> + };
> + };
> +
> + flash {
> + compatible = "jedec,spi-nor";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + /* ... */
> +
> + partition@650000 {
> + compatible = "nvmem-cells";
> + label = "0:ethphyfw";
> + reg = <0x650000 0x80000>;
> + read-only;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + aqr_fw: aqr_fw@0 {
> + reg = <0x0 0x5f42a>;
> + };
> + };
> +
> + /* ... */
> +
> + };
> + };
> --
> 2.40.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] Prevent out-of-bounds read/write in bcmasp_netfilt_rd and bcmasp_netfilt_wr
From: Yuran Pereira @ 2023-11-03 13:42 UTC (permalink / raw)
To: Greg KH
Cc: davem, netdev, florian.fainelli, linux-kernel, justin.chen,
edumazet, bcm-kernel-feedback-list, kuba, pabeni,
linux-kernel-mentees
In-Reply-To: <2023110301-purist-reputable-fab7@gregkh>
Hello Greg,
On Fri, Nov 03, 2023 at 01:57:13PM +0100, Greg KH wrote:
> > reg_offset = bcmasp_netfilt_get_reg_offset(priv, nfilt, reg_type,
> > offset);
> > + if (reg_offset < 0)
> > + return 0;
>
> Shouldn't you return an error here?
Yes, I think that makes sense. I might just return `reg_offset`
since it is bound to be -EINVAL when bcmasp_netfilt_get_reg_offset
fails.
But that now makes me wonder whether the previous check in that
function which currently returns 0, shouldn't be returning `-EINVAL`
instead.
```
static u32 bcmasp_netfilt_rd(struct bcmasp_priv *priv,
...
{
if (!IS_ALIGNED(offset, 4) || offset > MAX_WAKE_FILTER_SIZE)
return 0; <----- Should this one be -EINVAL?
}
```
Thank you for the feedback.
Yuran
^ permalink raw reply
* Re: [PATCH net-next 4/6] ice: Add support for E830 DDP package segment
From: Maciej Fijalkowski @ 2023-11-03 13:46 UTC (permalink / raw)
To: Jacob Keller
Cc: netdev, David Miller, Jakub Kicinski, Dan Nowlin,
Jesse Brandeburg, Paul Greenwalt, Simon Horman, Tony Brelinski
In-Reply-To: <20231025214157.1222758-5-jacob.e.keller@intel.com>
On Wed, Oct 25, 2023 at 02:41:55PM -0700, Jacob Keller wrote:
> From: Dan Nowlin <dan.nowlin@intel.com>
>
> Add support for E830 DDP package segment. For the E830 package,
> signature buffers will not be included inline in the configuration
> buffers. Instead, the signature buffers will be located in a
> signature segment.
This breaks E810 usage, they go into safe mode. I'll be sending a revert
to this commit or if you have any other idea how to address that I'm all
ears.
>
> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
> Co-developed-by: Paul Greenwalt <paul.greenwalt@intel.com>
> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
> Reviewed-by: Simon Horman <horms@kernel.org>
> Tested-by: Tony Brelinski <tony.brelinski@intel.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ddp.c | 436 ++++++++++++++++++----
> drivers/net/ethernet/intel/ice/ice_ddp.h | 27 +-
> drivers/net/ethernet/intel/ice/ice_type.h | 3 +
> 3 files changed, 387 insertions(+), 79 deletions(-)
>
^ permalink raw reply
* [PATCH] Documentation: Document the Netlink spec
From: Breno Leitao @ 2023-11-03 13:56 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, netdev, kuba, pabeni, edumazet
This is a Sphinx extension that parses the Netlink YAML spec files
(Documentation/netlink/specs/), and generates a rst file to be
displayed into Documentation pages.
Create a new Documentation/networking/netlink_spec page, and a sub-page
for each Netlink spec that needs to be documented, such as ethtool,
devlink, netdev, etc.
Create a Sphinx directive extension that reads the YAML spec
(located under Documentation/netlink/specs), parses it and returns a RST
string that is inserted where the Sphinx directive was called.
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Documentation/conf.py | 2 +-
Documentation/networking/index.rst | 1 +
.../networking/netlink_spec/devlink.rst | 9 +
.../networking/netlink_spec/ethtool.rst | 9 +
Documentation/networking/netlink_spec/fou.rst | 9 +
.../networking/netlink_spec/handshake.rst | 9 +
.../networking/netlink_spec/index.rst | 21 ++
.../networking/netlink_spec/netdev.rst | 9 +
.../networking/netlink_spec/ovs_datapath.rst | 9 +
.../networking/netlink_spec/ovs_flow.rst | 9 +
.../networking/netlink_spec/ovs_vport.rst | 9 +
.../networking/netlink_spec/rt_addr.rst | 9 +
.../networking/netlink_spec/rt_link.rst | 9 +
.../networking/netlink_spec/rt_route.rst | 9 +
Documentation/sphinx/netlink_spec.py | 283 ++++++++++++++++++
Documentation/sphinx/requirements.txt | 1 +
16 files changed, 406 insertions(+), 1 deletion(-)
create mode 100644 Documentation/networking/netlink_spec/devlink.rst
create mode 100644 Documentation/networking/netlink_spec/ethtool.rst
create mode 100644 Documentation/networking/netlink_spec/fou.rst
create mode 100644 Documentation/networking/netlink_spec/handshake.rst
create mode 100644 Documentation/networking/netlink_spec/index.rst
create mode 100644 Documentation/networking/netlink_spec/netdev.rst
create mode 100644 Documentation/networking/netlink_spec/ovs_datapath.rst
create mode 100644 Documentation/networking/netlink_spec/ovs_flow.rst
create mode 100644 Documentation/networking/netlink_spec/ovs_vport.rst
create mode 100644 Documentation/networking/netlink_spec/rt_addr.rst
create mode 100644 Documentation/networking/netlink_spec/rt_link.rst
create mode 100644 Documentation/networking/netlink_spec/rt_route.rst
create mode 100755 Documentation/sphinx/netlink_spec.py
diff --git a/Documentation/conf.py b/Documentation/conf.py
index d4fdf6a3875a..10ce47d1a7df 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -55,7 +55,7 @@ needs_sphinx = '1.7'
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
'maintainers_include', 'sphinx.ext.autosectionlabel',
- 'kernel_abi', 'kernel_feat']
+ 'kernel_abi', 'kernel_feat', 'netlink_spec']
if major >= 3:
if (major > 3) or (minor > 0 or patch >= 2):
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 5b75c3f7a137..ee3a2085af71 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -55,6 +55,7 @@ Contents:
filter
generic-hdlc
generic_netlink
+ netlink_spec/index
gen_stats
gtp
ila
diff --git a/Documentation/networking/netlink_spec/devlink.rst b/Documentation/networking/netlink_spec/devlink.rst
new file mode 100644
index 000000000000..ca4b98e29690
--- /dev/null
+++ b/Documentation/networking/netlink_spec/devlink.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Family ``devlink`` netlink specification
+========================================
+
+.. contents::
+
+.. netlink-spec:: devlink.yaml
diff --git a/Documentation/networking/netlink_spec/ethtool.rst b/Documentation/networking/netlink_spec/ethtool.rst
new file mode 100644
index 000000000000..017d5dff427b
--- /dev/null
+++ b/Documentation/networking/netlink_spec/ethtool.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Family ``ethtool`` netlink specification
+========================================
+
+.. contents::
+
+.. netlink-spec:: ethtool.yaml
diff --git a/Documentation/networking/netlink_spec/fou.rst b/Documentation/networking/netlink_spec/fou.rst
new file mode 100644
index 000000000000..4db939091f67
--- /dev/null
+++ b/Documentation/networking/netlink_spec/fou.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================================
+Family ``fou`` netlink specification
+=======================================
+
+.. contents::
+
+.. netlink-spec:: fou.yaml
diff --git a/Documentation/networking/netlink_spec/handshake.rst b/Documentation/networking/netlink_spec/handshake.rst
new file mode 100644
index 000000000000..ed3d79843602
--- /dev/null
+++ b/Documentation/networking/netlink_spec/handshake.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================
+Family ``handshake`` netlink specification
+==========================================
+
+.. contents::
+
+.. netlink-spec:: handshake.yaml
diff --git a/Documentation/networking/netlink_spec/index.rst b/Documentation/networking/netlink_spec/index.rst
new file mode 100644
index 000000000000..b330bda0ea21
--- /dev/null
+++ b/Documentation/networking/netlink_spec/index.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+Netlink Specifications
+======================
+
+.. toctree::
+ :maxdepth: 2
+
+ devlink
+ ethtool
+ fou
+ handshake
+ netdev
+ ovs_datapath
+ ovs_flow
+ ovs_vport
+ rt_addr
+ rt_link
+ rt_route
+
diff --git a/Documentation/networking/netlink_spec/netdev.rst b/Documentation/networking/netlink_spec/netdev.rst
new file mode 100644
index 000000000000..4f43c31805dd
--- /dev/null
+++ b/Documentation/networking/netlink_spec/netdev.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================================
+Family ``netdev`` netlink specification
+=======================================
+
+.. contents::
+
+.. netlink-spec:: netdev.yaml
diff --git a/Documentation/networking/netlink_spec/ovs_datapath.rst b/Documentation/networking/netlink_spec/ovs_datapath.rst
new file mode 100644
index 000000000000..8045a5c93001
--- /dev/null
+++ b/Documentation/networking/netlink_spec/ovs_datapath.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================================
+Family ``ovs_datapath`` netlink specification
+=============================================
+
+.. contents::
+
+.. netlink-spec:: ovs_datapath.yaml
diff --git a/Documentation/networking/netlink_spec/ovs_flow.rst b/Documentation/networking/netlink_spec/ovs_flow.rst
new file mode 100644
index 000000000000..3a60d75b79b4
--- /dev/null
+++ b/Documentation/networking/netlink_spec/ovs_flow.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+Family ``ovs_flow`` netlink specification
+=========================================
+
+.. contents::
+
+.. netlink-spec:: ovs_flow.yaml
diff --git a/Documentation/networking/netlink_spec/ovs_vport.rst b/Documentation/networking/netlink_spec/ovs_vport.rst
new file mode 100644
index 000000000000..2be013c0b524
--- /dev/null
+++ b/Documentation/networking/netlink_spec/ovs_vport.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================
+Family ``ovs_vport`` netlink specification
+==========================================
+
+.. contents::
+
+.. netlink-spec:: ovs_vport.yaml
diff --git a/Documentation/networking/netlink_spec/rt_addr.rst b/Documentation/networking/netlink_spec/rt_addr.rst
new file mode 100644
index 000000000000..ca002646fa5c
--- /dev/null
+++ b/Documentation/networking/netlink_spec/rt_addr.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Family ``rt_addr`` netlink specification
+========================================
+
+.. contents::
+
+.. netlink-spec:: rt_addr.yaml
diff --git a/Documentation/networking/netlink_spec/rt_link.rst b/Documentation/networking/netlink_spec/rt_link.rst
new file mode 100644
index 000000000000..e07481a34880
--- /dev/null
+++ b/Documentation/networking/netlink_spec/rt_link.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Family ``rt_link`` netlink specification
+========================================
+
+.. contents::
+
+.. netlink-spec:: rt_link.yaml
diff --git a/Documentation/networking/netlink_spec/rt_route.rst b/Documentation/networking/netlink_spec/rt_route.rst
new file mode 100644
index 000000000000..7fe674dc098e
--- /dev/null
+++ b/Documentation/networking/netlink_spec/rt_route.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+Family ``rt_route`` netlink specification
+=========================================
+
+.. contents::
+
+.. netlink-spec:: rt_route.yaml
diff --git a/Documentation/sphinx/netlink_spec.py b/Documentation/sphinx/netlink_spec.py
new file mode 100755
index 000000000000..80756e72ed4f
--- /dev/null
+++ b/Documentation/sphinx/netlink_spec.py
@@ -0,0 +1,283 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+# -*- coding: utf-8; mode: python -*-
+
+"""
+ netlink-spec
+ ~~~~~~~~~~~~~~~~~~~
+
+ Implementation of the ``netlink-spec`` ReST-directive.
+
+ :copyright: Copyright (C) 2023 Breno Leitao <leitao@debian.org>
+ :license: GPL Version 2, June 1991 see linux/COPYING for details.
+
+ The ``netlink-spec`` reST-directive performs extensive parsing
+ specific to the Linux kernel's standard netlink specs, in an
+ effort to avoid needing to heavily mark up the original YAML file.
+
+ This code is split in three big parts:
+ 1) RST formatters: Use to convert a string to a RST output
+ 2) Parser helpers: Helper functions to parse the YAML data
+ 3) NetlinkSpec Directive: The actual directive class
+"""
+
+from typing import Any, Dict, List
+import os.path
+from docutils.parsers.rst import Directive
+from docutils import statemachine
+import yaml
+
+__version__ = "1.0"
+SPACE_PER_LEVEL = 4
+
+# RST Formatters
+def rst_definition(key: str, value: Any, level: int = 0) -> str:
+ """Format a single rst definition"""
+ return headroom(level) + key + "\n" + headroom(level + 1) + str(value)
+
+
+def rst_paragraph(paragraph: str, level: int = 0) -> str:
+ """Return a formatted paragraph"""
+ return headroom(level) + paragraph
+
+
+def headroom(level: int) -> str:
+ """Return space to format"""
+ return " " * (level * SPACE_PER_LEVEL)
+
+
+def rst_bullet(item: str, level: int = 0) -> str:
+ """Return a formatted a bullet"""
+ return headroom(level) + f" - {item}"
+
+def rst_subsubtitle(title: str) -> str:
+ """Add a sub-sub-title to the document"""
+ return f"{title}\n" + "~" * len(title)
+
+
+def rst_fields(key: str, value: str, level: int = 0) -> str:
+ """Return a RST formatted field"""
+ return headroom(level) + f":{key}: {value}"
+
+
+def rst_subtitle(title: str, level: int = 0) -> str:
+ """Add a subtitle to the document"""
+ return headroom(level) + f"\n{title}\n" + "-" * len(title)
+
+
+def rst_list_inline(list_: List[str], level: int = 0) -> str:
+ """Format a list using inlines"""
+ return headroom(level) + "[" + ", ".join(inline(i) for i in list_) + "]"
+
+
+def bold(text: str) -> str:
+ """Format bold text"""
+ return f"**{text}**"
+
+
+def inline(text: str) -> str:
+ """Format inline text"""
+ return f"``{text}``"
+
+
+def sanitize(text: str) -> str:
+ """Remove newlines and multiple spaces"""
+ # This is useful for some fields that are spread in multiple lines
+ return str(text).replace("\n", "").strip()
+
+
+# Parser helpers
+# ==============
+def parse_mcast_group(mcast_group: List[Dict[str, Any]]) -> str:
+ """Parse 'multicast' group list and return a formatted string"""
+ lines = []
+ for group in mcast_group:
+ lines.append(rst_paragraph(group["name"], 1))
+
+ return "\n".join(lines)
+
+
+def parse_do(do_dict: Dict[str, Any], level: int = 0) -> str:
+ """Parse 'do' section and return a formatted string"""
+ lines = []
+ for key in do_dict.keys():
+ lines.append(rst_bullet(bold(key), level + 1))
+ lines.append(parse_do_attributes(do_dict[key], level + 1) + "\n")
+
+ return "\n".join(lines)
+
+
+def parse_do_attributes(attrs: Dict[str, Any], level: int = 0) -> str:
+ """Parse 'attributes' section"""
+ if "attributes" not in attrs:
+ return ""
+ lines = [rst_fields("attributes", rst_list_inline(attrs["attributes"]), level + 1)]
+
+ return "\n".join(lines)
+
+
+def parse_operations(operations: List[Dict[str, Any]]) -> str:
+ """Parse operations block"""
+ preprocessed = ["name", "doc", "title", "do", "dump"]
+ lines = []
+
+ for operation in operations:
+ lines.append(rst_subsubtitle(operation["name"]))
+ lines.append(rst_paragraph(operation["doc"]) + "\n")
+ if "do" in operation:
+ lines.append(rst_paragraph(bold("do"), 1))
+ lines.append(parse_do(operation["do"], 1))
+ if "dump" in operation:
+ lines.append(rst_paragraph(bold("dump"), 1))
+ lines.append(parse_do(operation["dump"], 1))
+
+ for key in operation.keys():
+ if key in preprocessed:
+ # Skip the special fields
+ continue
+ lines.append(rst_fields(key, operation[key], 1))
+
+ # New line after fields
+ lines.append("\n")
+
+ return "\n".join(lines)
+
+
+def parse_entries(entries: List[Dict[str, Any]], level: int) -> str:
+ """Parse a list of entries"""
+ lines = []
+ for entry in entries:
+ if isinstance(entry, dict):
+ # entries could be a list or a dictionary
+ lines.append(
+ rst_fields(entry.get("name"), sanitize(entry.get("doc")), level)
+ )
+ elif isinstance(entry, list):
+ lines.append(rst_list_inline(entry, level))
+ else:
+ lines.append(rst_bullet(inline(sanitize(entry)), level))
+
+ lines.append("\n")
+ return "\n".join(lines)
+
+
+def parse_definitions(defs: Dict[str, Any]) -> str:
+ """Parse definitions section"""
+ preprocessed = ["name", "entries", "members"]
+ ignored = ["render-max"] # This is not printed
+ lines = []
+
+ for definition in defs:
+ lines.append(rst_subsubtitle(definition["name"]))
+ for k in definition.keys():
+ if k in preprocessed + ignored:
+ continue
+ lines.append(rst_fields(k, sanitize(definition[k]), 1))
+
+ # Field list needs to finish with a new line
+ lines.append("\n")
+ if "entries" in definition:
+ lines.append(rst_paragraph(bold("Entries"), 1))
+ lines.append(parse_entries(definition["entries"], 2))
+ if "members" in definition:
+ lines.append(rst_paragraph(bold("members"), 1))
+ lines.append(parse_entries(definition["members"], 2))
+
+ return "\n".join(lines)
+
+
+def parse_attributes_set(entries: List[Dict[str, Any]]) -> str:
+ """Parse attribute from attribute-set"""
+ preprocessed = ["name", "type"]
+ ignored = ["checks"]
+ lines = []
+
+ for entry in entries:
+ lines.append(rst_bullet(bold(entry["name"])))
+ for attr in entry["attributes"]:
+ type_ = attr.get("type")
+ attr_line = bold(attr["name"])
+ if type_:
+ # Add the attribute type in the same line
+ attr_line += f" ({inline(type_)})"
+
+ lines.append(rst_bullet(attr_line, 2))
+
+ for k in attr.keys():
+ if k in preprocessed + ignored:
+ continue
+ lines.append(rst_fields(k, sanitize(attr[k]), 3))
+ lines.append("\n")
+
+ return "\n".join(lines)
+
+
+def parse_yaml(obj: Dict[str, Any]) -> str:
+ """Format the whole yaml into a RST string"""
+ lines = []
+
+ # This is coming from the RST
+ lines.append(rst_subtitle("Summary"))
+ lines.append(rst_paragraph(obj["doc"], 1))
+
+ # Operations
+ lines.append(rst_subtitle("Operations"))
+ lines.append(parse_operations(obj["operations"]["list"]))
+
+ # Multicast groups
+ if "mcast-groups" in obj:
+ lines.append(rst_subtitle("Multicast groups"))
+ lines.append(parse_mcast_group(obj["mcast-groups"]["list"]))
+
+ # Definitions
+ lines.append(rst_subtitle("Definitions"))
+ lines.append(parse_definitions(obj["definitions"]))
+
+ # Attributes set
+ lines.append(rst_subtitle("Attribute sets"))
+ lines.append(parse_attributes_set(obj["attribute-sets"]))
+
+ return "\n".join(lines)
+
+
+def parse_yaml_file(filename: str, debug: bool = False) -> str:
+ """Transform the yaml specified by filename into a rst-formmated string"""
+ with open(filename, "r") as file:
+ yaml_data = yaml.safe_load(file)
+ content = parse_yaml(yaml_data)
+
+ if debug:
+ # Save the rst for inspection
+ print(content, file=open(f"/tmp/{filename.split('/')[-1]}.rst", "w"))
+
+ return content
+
+
+# Main Sphinx Extension class
+def setup(app):
+ """Sphinx-build register function for 'netlink-spec' directive"""
+ app.add_directive("netlink-spec", NetlinkSpec)
+ return dict(version=__version__, parallel_read_safe=True, parallel_write_safe=True)
+
+
+class NetlinkSpec(Directive):
+ """NetlinkSpec (``netlink-spec``) directive class"""
+ has_content = True
+ # Argument is the filename to process
+ required_arguments = 1
+
+ def run(self):
+ srctree = os.path.abspath(os.environ["srctree"])
+ yaml_file = os.path.join(
+ srctree, "Documentation/netlink/specs", self.arguments[0]
+ )
+ self.state.document.settings.record_dependencies.add(yaml_file)
+
+ try:
+ content = parse_yaml_file(yaml_file)
+ except FileNotFoundError as exception:
+ raise self.severe(str(exception))
+
+ self.state_machine.insert_input(statemachine.string2lines(content), yaml_file)
+
+ return []
diff --git a/Documentation/sphinx/requirements.txt b/Documentation/sphinx/requirements.txt
index 335b53df35e2..a8a1aff6445e 100644
--- a/Documentation/sphinx/requirements.txt
+++ b/Documentation/sphinx/requirements.txt
@@ -1,3 +1,4 @@
# jinja2>=3.1 is not compatible with Sphinx<4.0
jinja2<3.1
Sphinx==2.4.4
+pyyaml
--
2.34.1
^ permalink raw reply related
* Re: [PATCH bpf-next v2] net, xdp: allow metadata > 32
From: Alexander Lobakin @ 2023-11-03 14:03 UTC (permalink / raw)
To: Larysa Zaremba
Cc: bpf, netdev, Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, Eric Dumazet,
Magnus Karlsson, Willem de Bruijn, Yunsheng Lin,
Maciej Fijalkowski, John Fastabend
In-Reply-To: <20231031175742.21455-1-larysa.zaremba@intel.com>
From: Larysa Zaremba <larysa.zaremba@intel.com>
Date: Tue, 31 Oct 2023 18:57:37 +0100
It doesn't have "From: Alexa..." here, so that you'll be the author once
this is applied. Is this intended? ^.^
> 32 bytes may be not enough for some custom metadata. Relax the restriction,
> allow metadata larger than 32 bytes and make __skb_metadata_differs() work
> with bigger lengths.
>
> Now size of metadata is only limited by the fact it is stored as u8
> in skb_shared_info, so the upper limit is now is 255. Other important
> conditions, such as having enough space for xdp_frame building, are already
> checked in bpf_xdp_adjust_meta().
[...]
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH] Prevent out-of-bounds read/write in bcmasp_netfilt_rd and bcmasp_netfilt_wr
From: Yuran Pereira @ 2023-11-03 14:14 UTC (permalink / raw)
To: gregkh, yuran.pereira
Cc: bcm-kernel-feedback-list, davem, edumazet, florian.fainelli,
justin.chen, kuba, linux-kernel-mentees, linux-kernel, netdev,
pabeni
In-Reply-To: <DB3PR10MB68352DF6CB458CCF97C416ECE8A5A@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM>
I guess that explains why the first check returns 0.
```
static int bcmasp_netfilt_wr_m_wake(struct bcmasp_priv *priv,
...
{
...
if (first_byte && (!IS_ALIGNED(offset, 4) || size < 3)) {
match_val = bcmasp_netfilt_rd(priv, nfilt,
ASP_NETFILT_MATCH,
ALIGN_DOWN(offset, 4));
mask_val = bcmasp_netfilt_rd(priv, nfilt,
ASP_NETFILT_MASK,
ALIGN_DOWN(offset, 4));
}
shift = (3 - (offset % 4)) * 8;
match_val &= ~GENMASK(shift + 7, shift);
mask_val &= ~GENMASK(shift + 7, shift);
match_val |= (u32)(*((u8 *)match) << shift);
mask_val |= (u32)(*((u8 *)mask) << shift);
```
^ permalink raw reply
* Re: [PATCH] Prevent out-of-bounds read/write in bcmasp_netfilt_rd and bcmasp_netfilt_wr
From: Yuran Pereira @ 2023-11-03 14:19 UTC (permalink / raw)
To: gregkh, yuran.pereira
Cc: bcm-kernel-feedback-list, davem, edumazet, florian.fainelli,
justin.chen, kuba, linux-kernel-mentees, linux-kernel, netdev,
pabeni
In-Reply-To: <DB3PR10MB68352DF6CB458CCF97C416ECE8A5A@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM>
On a second thought, it might not be a good idea to return
an error without modifying the caller, since the caller of
this function currently uses this return value without checking
if it's an error.
I guess that explains why the first check returns 0.
```
static int bcmasp_netfilt_wr_m_wake(struct bcmasp_priv *priv,
...
{
...
if (first_byte && (!IS_ALIGNED(offset, 4) || size < 3)) {
match_val = bcmasp_netfilt_rd(priv, nfilt,
ASP_NETFILT_MATCH,
ALIGN_DOWN(offset, 4));
mask_val = bcmasp_netfilt_rd(priv, nfilt,
ASP_NETFILT_MASK,
ALIGN_DOWN(offset, 4));
}
shift = (3 - (offset % 4)) * 8;
match_val &= ~GENMASK(shift + 7, shift);
mask_val &= ~GENMASK(shift + 7, shift);
match_val |= (u32)(*((u8 *)match) << shift);
mask_val |= (u32)(*((u8 *)mask) << shift);
```
^ permalink raw reply
* Re: [PATCH] net: ipmr_base: Check iif when returning a (*, G) MFC
From: Nicolas Dichtel @ 2023-11-03 14:21 UTC (permalink / raw)
To: Yang Sun; +Cc: Ido Schimmel, davem, dsahern, edumazet, kuba, pabeni, netdev
In-Reply-To: <CAF+qgb6uUF-Z8EkZoqzfboaCZv4PP6yG_r=-2ojaG9T61Kg3jA@mail.gmail.com>
Le 03/11/2023 à 12:05, Yang Sun a écrit :
> On Thu, Nov 2, 2023 at 10:19 PM Nicolas Dichtel
> <nicolas.dichtel@6wind.com> wrote:
>>
>> Le 02/11/2023 à 12:48, Yang Sun a écrit :
>>>> Is this a regression (doesn't seem that way)? If not, the change should
>>>> be targeted at net-next which is closed right now:
>>>
>>>> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>>>
>>> I see.
>>>
>>>>> - if (c->mfc_un.res.ttls[vifi] < 255)
>>>>> + if (c->mfc_parent == vifi && c->mfc_un.res.ttls[vifi] < 255)
>>>
>>>> What happens if the route doesn't have an iif (-1)? It won't match
>>>> anymore?
>>>
>>> Looks like the mfc_parent can't be -1? There is the check:
>>> if (mfc->mf6cc_parent >= MAXMIFS)
>>> return -ENFILE;
>>> before setting the parent:
>>> c->_c.mfc_parent = mfc->mf6cc_parent;
>>>
>>> I wrote this patch thinking (*, G) MFCs could be per iif, similar to the
>>> (S, G) MFCs, like we can add the following MFCs to forward packets from
>>> any address with group destination ff05::aa from if1 to if2, and forward
>>> packets from any address with group destination ff05::aa from if2 to
>>> both if1 and if3.
>>>
>>> (::, ff05::aa) Iif: if1 Oifs: if1 if2 State: resolved
>>> (::, ff05::aa) Iif: if2 Oifs: if1 if2 if3 State: resolved
>>>
>>> But reading Nicolas's initial commit message again, it seems to me that
>>> (*, G) has to be used together with (*, *) and there should be only one
>>> (*, G) entry per group address and include all relevant interfaces in
>>> the oifs? Like the following:
>>>
>>> (::, ::) Iif: if1 Oifs: if1 if2 if3 State: resolved
>>> (::, ff05::aa) Iif: if1 Oifs: if1 if2 if3 State: resolved
>>>
>>> Is this how the (*, *|G) MFCs are intended to be used? which means packets
>>> to ff05::aa are forwarded from any one of the interfaces to all the other
>>> interfaces? If this is the intended way it works then my patch would break
>>> things and should be rejected.
>> Yes, this was the intend. Only one (*, G) entry was expected (per G).
>>
>>>
>>> Is there a way to achieve the use case I described above? Like having
>>> different oifs for different iif?
>> Instead of being too strict, maybe you could try to return the 'best' entry.
>>
>> #1 (::, ff05::aa) Iif: if1 Oifs: if1 if2 State: resolved
>> #2 (::, ff05::aa) Iif: if2 Oifs: if1 if2 if3 State: resolved
>>
>> If a packet comes from if2, returns #2, but if a packet comes from if3, returns
>> the first matching entry, ie #1 here.
>>
>
> Thanks for your reply Nicolas!
> Here if it returns the first matching then it depends on which entry
> is returned first
> by the hash table lookup, the forwarding behavior may be indeterminate
> in that case
> it seems.
As I said, only one (*,G) entry was expected thus the 'first' one is
indeterminate if there are several entries.
>
> If a packet has no matching (*, G) entry, then it will use the (*, *)
> entry to be forwarded
> to the upstream interface in (*, *). And with the (*, *) it means we
> won't get any nocache upcall
> for interfaces included in the static tree, right? So the (S, G) MFC
> and the static proxy MFCs
> are not meant to be used together?
Not together. With proxy multicast, the multicast tree is static, ie there is no
multicast daemon. Mcast packets received from one interface are sent to the
other interfaces that are part of the tree.
Regards,
Nicolas
>
> I wonder how a real use case with (*, G|*) would look like, what
> interface could be an
> upstream interface. Is there an example?
>
> Thanks,
> Yang
>
>>
>> Regards,
>> Nicolas
^ permalink raw reply
* Re: [PATCH bpf-next v2] net, xdp: allow metadata > 32
From: Larysa Zaremba @ 2023-11-03 14:34 UTC (permalink / raw)
To: Alexander Lobakin
Cc: bpf, netdev, Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, Eric Dumazet,
Magnus Karlsson, Willem de Bruijn, Yunsheng Lin,
Maciej Fijalkowski, John Fastabend
In-Reply-To: <b6da9739-a6e6-4528-a4cd-f87e8e025740@intel.com>
On Fri, Nov 03, 2023 at 03:03:14PM +0100, Alexander Lobakin wrote:
> From: Larysa Zaremba <larysa.zaremba@intel.com>
> Date: Tue, 31 Oct 2023 18:57:37 +0100
>
> It doesn't have "From: Alexa..." here, so that you'll be the author once
> this is applied. Is this intended? ^.^
>
No, I should probably resend.
> > 32 bytes may be not enough for some custom metadata. Relax the restriction,
> > allow metadata larger than 32 bytes and make __skb_metadata_differs() work
> > with bigger lengths.
> >
> > Now size of metadata is only limited by the fact it is stored as u8
> > in skb_shared_info, so the upper limit is now is 255. Other important
> > conditions, such as having enough space for xdp_frame building, are already
> > checked in bpf_xdp_adjust_meta().
>
> [...]
>
> Thanks,
> Olek
^ permalink raw reply
* [PATCH bpf-next] selftests/xsk: fix for SEND_RECEIVE_UNALIGNED test.
From: Tushar Vyavahare @ 2023-11-03 14:29 UTC (permalink / raw)
To: bpf
Cc: netdev, bjorn, magnus.karlsson, maciej.fijalkowski,
jonathan.lemon, davem, kuba, pabeni, ast, daniel,
tirthendu.sarkar, tushar.vyavahare
Fix test broken by shared umem test and framework enhancement commit.
Correct the current implementation of pkt_stream_replace_half() by
ensuring that nb_valid_entries are not set to half, as this is not true
for all the tests.
Create a new function called pkt_modify() that allows for packet
modification to meet specific requirements while ensuring the accurate
maintenance of the valid packet count to prevent inconsistencies in packet
tracking.
Fixes: 6d198a89c004 ("selftests/xsk: Add a test for shared umem feature")
Reported-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com>
---
tools/testing/selftests/bpf/xskxceiver.c | 71 ++++++++++++++++--------
1 file changed, 47 insertions(+), 24 deletions(-)
diff --git a/tools/testing/selftests/bpf/xskxceiver.c b/tools/testing/selftests/bpf/xskxceiver.c
index 591ca9637b23..f7d3a4a9013f 100644
--- a/tools/testing/selftests/bpf/xskxceiver.c
+++ b/tools/testing/selftests/bpf/xskxceiver.c
@@ -634,16 +634,35 @@ static u32 pkt_nb_frags(u32 frame_size, struct pkt_stream *pkt_stream, struct pk
return nb_frags;
}
-static void pkt_set(struct pkt_stream *pkt_stream, struct pkt *pkt, int offset, u32 len)
+static bool pkt_valid(bool unaligned_mode, int offset, u32 len)
+{
+ if (len > MAX_ETH_JUMBO_SIZE || (!unaligned_mode && offset < 0))
+ return false;
+
+ return true;
+}
+
+static void pkt_set(struct pkt_stream *pkt_stream, struct xsk_umem_info *umem, struct pkt *pkt,
+ int offset, u32 len)
{
pkt->offset = offset;
pkt->len = len;
- if (len > MAX_ETH_JUMBO_SIZE) {
- pkt->valid = false;
- } else {
- pkt->valid = true;
+
+ pkt->valid = pkt_valid(umem->unaligned_mode, offset, len);
+ if (pkt->valid)
pkt_stream->nb_valid_entries++;
- }
+}
+
+static void pkt_modify(struct pkt_stream *pkt_stream, struct xsk_umem_info *umem, struct pkt *pkt,
+ int offset, u32 len)
+{
+ bool mod_valid;
+
+ pkt->offset = offset;
+ pkt->len = len;
+ mod_valid = pkt_valid(umem->unaligned_mode, offset, len);
+ pkt_stream->nb_valid_entries += mod_valid - pkt->valid;
+ pkt->valid = mod_valid;
}
static u32 pkt_get_buffer_len(struct xsk_umem_info *umem, u32 len)
@@ -651,7 +670,8 @@ static u32 pkt_get_buffer_len(struct xsk_umem_info *umem, u32 len)
return ceil_u32(len, umem->frame_size) * umem->frame_size;
}
-static struct pkt_stream *__pkt_stream_generate(u32 nb_pkts, u32 pkt_len, u32 nb_start, u32 nb_off)
+static struct pkt_stream *__pkt_stream_generate(struct xsk_umem_info *umem, u32 nb_pkts,
+ u32 pkt_len, u32 nb_start, u32 nb_off)
{
struct pkt_stream *pkt_stream;
u32 i;
@@ -665,30 +685,31 @@ static struct pkt_stream *__pkt_stream_generate(u32 nb_pkts, u32 pkt_len, u32 nb
for (i = 0; i < nb_pkts; i++) {
struct pkt *pkt = &pkt_stream->pkts[i];
- pkt_set(pkt_stream, pkt, 0, pkt_len);
+ pkt_set(pkt_stream, umem, pkt, 0, pkt_len);
pkt->pkt_nb = nb_start + i * nb_off;
}
return pkt_stream;
}
-static struct pkt_stream *pkt_stream_generate(u32 nb_pkts, u32 pkt_len)
+static struct pkt_stream *pkt_stream_generate(struct xsk_umem_info *umem, u32 nb_pkts, u32 pkt_len)
{
- return __pkt_stream_generate(nb_pkts, pkt_len, 0, 1);
+ return __pkt_stream_generate(umem, nb_pkts, pkt_len, 0, 1);
}
-static struct pkt_stream *pkt_stream_clone(struct pkt_stream *pkt_stream)
+static struct pkt_stream *pkt_stream_clone(struct pkt_stream *pkt_stream,
+ struct xsk_umem_info *umem)
{
- return pkt_stream_generate(pkt_stream->nb_pkts, pkt_stream->pkts[0].len);
+ return pkt_stream_generate(umem, pkt_stream->nb_pkts, pkt_stream->pkts[0].len);
}
static void pkt_stream_replace(struct test_spec *test, u32 nb_pkts, u32 pkt_len)
{
struct pkt_stream *pkt_stream;
- pkt_stream = pkt_stream_generate(nb_pkts, pkt_len);
+ pkt_stream = pkt_stream_generate(test->ifobj_rx->umem, nb_pkts, pkt_len);
test->ifobj_tx->xsk->pkt_stream = pkt_stream;
- pkt_stream = pkt_stream_generate(nb_pkts, pkt_len);
+ pkt_stream = pkt_stream_generate(test->ifobj_tx->umem, nb_pkts, pkt_len);
test->ifobj_rx->xsk->pkt_stream = pkt_stream;
}
@@ -698,12 +719,11 @@ static void __pkt_stream_replace_half(struct ifobject *ifobj, u32 pkt_len,
struct pkt_stream *pkt_stream;
u32 i;
- pkt_stream = pkt_stream_clone(ifobj->xsk->pkt_stream);
+ pkt_stream = pkt_stream_clone(ifobj->xsk->pkt_stream, ifobj->umem);
for (i = 1; i < ifobj->xsk->pkt_stream->nb_pkts; i += 2)
- pkt_set(pkt_stream, &pkt_stream->pkts[i], offset, pkt_len);
+ pkt_modify(pkt_stream, ifobj->umem, &pkt_stream->pkts[i], offset, pkt_len);
ifobj->xsk->pkt_stream = pkt_stream;
- pkt_stream->nb_valid_entries /= 2;
}
static void pkt_stream_replace_half(struct test_spec *test, u32 pkt_len, int offset)
@@ -715,9 +735,10 @@ static void pkt_stream_replace_half(struct test_spec *test, u32 pkt_len, int off
static void pkt_stream_receive_half(struct test_spec *test)
{
struct pkt_stream *pkt_stream = test->ifobj_tx->xsk->pkt_stream;
+ struct xsk_umem_info *umem = test->ifobj_rx->umem;
u32 i;
- test->ifobj_rx->xsk->pkt_stream = pkt_stream_generate(pkt_stream->nb_pkts,
+ test->ifobj_rx->xsk->pkt_stream = pkt_stream_generate(umem, pkt_stream->nb_pkts,
pkt_stream->pkts[0].len);
pkt_stream = test->ifobj_rx->xsk->pkt_stream;
for (i = 1; i < pkt_stream->nb_pkts; i += 2)
@@ -733,12 +754,12 @@ static void pkt_stream_even_odd_sequence(struct test_spec *test)
for (i = 0; i < test->nb_sockets; i++) {
pkt_stream = test->ifobj_tx->xsk_arr[i].pkt_stream;
- pkt_stream = __pkt_stream_generate(pkt_stream->nb_pkts / 2,
+ pkt_stream = __pkt_stream_generate(test->ifobj_tx->umem, pkt_stream->nb_pkts / 2,
pkt_stream->pkts[0].len, i, 2);
test->ifobj_tx->xsk_arr[i].pkt_stream = pkt_stream;
pkt_stream = test->ifobj_rx->xsk_arr[i].pkt_stream;
- pkt_stream = __pkt_stream_generate(pkt_stream->nb_pkts / 2,
+ pkt_stream = __pkt_stream_generate(test->ifobj_rx->umem, pkt_stream->nb_pkts / 2,
pkt_stream->pkts[0].len, i, 2);
test->ifobj_rx->xsk_arr[i].pkt_stream = pkt_stream;
}
@@ -1961,7 +1982,8 @@ static int testapp_stats_tx_invalid_descs(struct test_spec *test)
static int testapp_stats_rx_full(struct test_spec *test)
{
pkt_stream_replace(test, DEFAULT_UMEM_BUFFERS + DEFAULT_UMEM_BUFFERS / 2, MIN_PKT_SIZE);
- test->ifobj_rx->xsk->pkt_stream = pkt_stream_generate(DEFAULT_UMEM_BUFFERS, MIN_PKT_SIZE);
+ test->ifobj_rx->xsk->pkt_stream = pkt_stream_generate(test->ifobj_rx->umem,
+ DEFAULT_UMEM_BUFFERS, MIN_PKT_SIZE);
test->ifobj_rx->xsk->rxqsize = DEFAULT_UMEM_BUFFERS;
test->ifobj_rx->release_rx = false;
@@ -1972,7 +1994,8 @@ static int testapp_stats_rx_full(struct test_spec *test)
static int testapp_stats_fill_empty(struct test_spec *test)
{
pkt_stream_replace(test, DEFAULT_UMEM_BUFFERS + DEFAULT_UMEM_BUFFERS / 2, MIN_PKT_SIZE);
- test->ifobj_rx->xsk->pkt_stream = pkt_stream_generate(DEFAULT_UMEM_BUFFERS, MIN_PKT_SIZE);
+ test->ifobj_rx->xsk->pkt_stream = pkt_stream_generate(test->ifobj_rx->umem,
+ DEFAULT_UMEM_BUFFERS, MIN_PKT_SIZE);
test->ifobj_rx->use_fill_ring = false;
test->ifobj_rx->validation_func = validate_fill_empty;
@@ -2526,8 +2549,8 @@ int main(int argc, char **argv)
init_iface(ifobj_tx, worker_testapp_validate_tx);
test_spec_init(&test, ifobj_tx, ifobj_rx, 0, &tests[0]);
- tx_pkt_stream_default = pkt_stream_generate(DEFAULT_PKT_CNT, MIN_PKT_SIZE);
- rx_pkt_stream_default = pkt_stream_generate(DEFAULT_PKT_CNT, MIN_PKT_SIZE);
+ tx_pkt_stream_default = pkt_stream_generate(ifobj_tx->umem, DEFAULT_PKT_CNT, MIN_PKT_SIZE);
+ rx_pkt_stream_default = pkt_stream_generate(ifobj_rx->umem, DEFAULT_PKT_CNT, MIN_PKT_SIZE);
if (!tx_pkt_stream_default || !rx_pkt_stream_default)
exit_with_error(ENOMEM);
test.tx_pkt_stream_default = tx_pkt_stream_default;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v2 8/9] microchip: lan865x: add driver support for Microchip's LAN865X MACPHY
From: Parthiban.Veerasooran @ 2023-11-03 14:59 UTC (permalink / raw)
To: ramon.nordin.rodriguez
Cc: davem, edumazet, kuba, pabeni, robh+dt, krzysztof.kozlowski+dt,
conor+dt, corbet, Steen.Hegelund, rdunlap, horms, casper.casan,
andrew, netdev, devicetree, linux-kernel, linux-doc,
Horatiu.Vultur, Woojung.Huh, Nicolas.Ferre, UNGLinuxDriver,
Thorsten.Kummermehr
In-Reply-To: <ZUOUGf-PMGo8z1s-@debian>
Hi Ramon,
On 02/11/23 5:50 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Mon, Oct 23, 2023 at 09:16:48PM +0530, Parthiban Veerasooran wrote:
>> The LAN8650/1 is designed to conform to the OPEN Alliance 10BASE‑T1x
>> MAC‑PHY Serial Interface specification, Version 1.1. The IEEE Clause 4
>> MAC integration provides the low pin count standard SPI interface to any
>> microcontroller therefore providing Ethernet functionality without
>> requiring MAC integration within the microcontroller. The LAN8650/1
>> operates as an SPI client supporting SCLK clock rates up to a maximum of
>> 25 MHz. This SPI interface supports the transfer of both data (Ethernet
>> frames) and control (register access).
>>
>> By default, the chunk data payload is 64 bytes in size. A smaller payload
>> data size of 32 bytes is also supported and may be configured in the
>> Chunk Payload Size (CPS) field of the Configuration 0 (OA_CONFIG0)
>> register. Changing the chunk payload size requires the LAN8650/1 be reset
>> and shall not be done during normal operation.
>>
>> The Ethernet Media Access Controller (MAC) module implements a 10 Mbps
>> half duplex Ethernet MAC, compatible with the IEEE 802.3 standard.
>> 10BASE-T1S physical layer transceiver integrated into the LAN8650/1. The
>> PHY and MAC are connected via an internal Media Independent Interface
>> (MII).
>>
>> Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
>
> Hi Parthiban
>
> I've been testing the v2 patches out a bit, at Ferroamp we're planning
> on using a dual LAN8650 setup in a product.
I understand that you are using two LAN8650, isn't it? if so are they
both running simultaneously? or you are doing the testing with one alone?
>
> First let me say that we'd be happy to assist with testing and
> development.
Thank you for your support on this.
>
> I got some observations that I think this patch is the resonable place
> to discuss it, since they seem to be MAC/PHY related.
>
> In order to get a reliable link I'm using the dts snippet below (for an
> imx8 cpu)
>
> &ecspi1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_ecspi1>;
> cs-gpios = <0> , <&gpio5 9 GPIO_ACTIVE_LOW>;
> status = "okay";
>
> spe1: ethernet@1{
> compatible = "microchip,lan865x";
> reg = <1>;
> interrupt-parent = <&gpio5>;
> interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
> spi-max-frequency = <50000000>;
> oa-tc6{
> #address-cells = <1>;
> #size-cells = <0>;
> oa-cps = <32>;
> oa-prote;
> oa-dprac;
> };
> };
> };
>
> With this setup I'm getting a maximum throughput of about 90kB/s.
> If I increase the chunk size / oa-cps to 64 I get a might higher
> throughput ~900kB/s, but after 0-2s I get dump below (or similar).
Did you or possible to try a test case with below configuration?
- Single LAN8650 enabled
- UDP
- oa_cps = 64
- spi-max-frequency = 15000000,
Did you run iperf3 test? or any other tool?
If iperf3 then can you share the configuration you used?
I don't know whether these may audiences are needed in the CC for this
thread. Let's see what's Andrew Lunn thinks about it?
Best Regards,
Parthiban V
>
> [ 363.444460] eth0: Transmit protocol error
> [ 363.448527] eth0: Transmit buffer underflow
> [ 363.452740] eth0: Receive buffer overflow
> [ 363.456780] eth0: Header error
> [ 363.459869] eth0: Footer frame drop
> [ 363.463379] eth0: SPI transfer failed
> [ 363.470590] eth0: Receive buffer overflow
> [ 363.474631] eth0: Header error
> [ 363.477776] eth0: SPI transfer failed
> [ 363.482596] eth0: Footer frame drop
> [ 369.884680] ------------[ cut here ]------------
> [ 369.889336] NETDEV WATCHDOG: eth0 (lan865x): transmit queue 0 timed out 6448 ms
> [ 369.896726] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x22c/0x234
> [ 369.905023] Modules linked in:
> [ 369.908091] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.4.16-gc5e8aa9586d6 #3
> [ 369.915241] Hardware name: <Ferroamp dev kit>
> [ 369.921169] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 369.928146] pc : dev_watchdog+0x22c/0x234
> [ 369.932168] lr : dev_watchdog+0x22c/0x234
> [ 369.936190] sp : ffff80000800be20
> [ 369.939510] x29: ffff80000800be20 x28: 0000000000000101 x27: ffff80000800bf00
> [ 369.946665] x26: ffff8000092469c0 x25: 0000000000001930 x24: ffff800009246000
> [ 369.953817] x23: 0000000000000000 x22: ffff000000e883dc x21: ffff000000e88000
> [ 369.960971] x20: ffff0000010dc000 x19: ffff000000e88488 x18: ffffffffffffffff
> [ 369.968124] x17: 383434362074756f x16: 2064656d69742030 x15: 0720072007200720
> [ 369.975276] x14: 0720072007200720 x13: ffff80000925fe88 x12: 0000000000000444
> [ 369.982431] x11: 000000000000016c x10: ffff8000092b7e88 x9 : ffff80000925fe88
> [ 369.989584] x8 : 00000000ffffefff x7 : ffff8000092b7e88 x6 : 80000000fffff000
> [ 369.996738] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> [ 370.003890] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000000dd400
> [ 370.011044] Call trace:
> [ 370.013496] dev_watchdog+0x22c/0x234
> [ 370.017173] call_timer_fn.constprop.0+0x24/0x80
> [ 370.021802] __run_timers.part.0+0x1f8/0x244
> [ 370.026080] run_timer_softirq+0x3c/0x74
> [ 370.030012] __do_softirq+0x10c/0x280
> [ 370.033683] ____do_softirq+0x10/0x1c
> [ 370.037357] call_on_irq_stack+0x24/0x4c
> [ 370.041292] do_softirq_own_stack+0x1c/0x28
> [ 370.045484] __irq_exit_rcu+0xe4/0x100
> [ 370.049244] irq_exit_rcu+0x10/0x1c
> [ 370.052744] el1_interrupt+0x38/0x68
> [ 370.056331] el1h_64_irq_handler+0x18/0x24
> [ 370.060439] el1h_64_irq+0x64/0x68
> [ 370.063851] cpuidle_enter_state+0x134/0x2e0
> [ 370.068133] cpuidle_enter+0x38/0x50
> [ 370.071719] do_idle+0x1f4/0x264
> [ 370.074960] cpu_startup_entry+0x24/0x2c
> [ 370.078895] secondary_start_kernel+0x130/0x150
> [ 370.083440] __secondary_switched+0xb8/0xbc
> [ 370.087634] ---[ end trace 0000000000000000 ]---
>
>
> Additionally when hotplugging cables, which might not be a realworld
> scenario I'm also seeing intermittent watchdog timeouts.
>
> In both scenarios the driver does not recover.
>
^ permalink raw reply
* [PATCH net] net/sched: act_ct: Always fill offloading tuple iifidx
From: Vlad Buslov @ 2023-11-03 15:14 UTC (permalink / raw)
To: davem, kuba, pabeni
Cc: netdev, jhs, xiyou.wangcong, jiri, pablo, Vlad Buslov,
Paul Blakey
Referenced commit doesn't always set iifidx when offloading the flow to
hardware. Fix the following cases:
- nf_conn_act_ct_ext_fill() is called before extension is created with
nf_conn_act_ct_ext_add() in tcf_ct_act(). This can cause rule offload with
unspecified iifidx when connection is offloaded after only single
original-direction packet has been processed by tc data path. Always fill
the new nf_conn_act_ct_ext instance after creating it in
nf_conn_act_ct_ext_add().
- Offloading of unidirectional UDP NEW connections is now supported, but ct
flow iifidx field is not updated when connection is promoted to
bidirectional which can result reply-direction iifidx to be zero when
refreshing the connection. Fill in the extension and update flow iifidx
before calling flow_offload_refresh().
Fixes: 9795ded7f924 ("net/sched: act_ct: Fill offloading tuple iifidx")
Reviewed-by: Paul Blakey <paulb@nvidia.com>
Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
---
include/net/netfilter/nf_conntrack_act_ct.h | 34 ++++++++++++---------
net/openvswitch/conntrack.c | 2 +-
net/sched/act_ct.c | 15 ++++++++-
3 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_act_ct.h b/include/net/netfilter/nf_conntrack_act_ct.h
index 078d3c52c03f..e5f2f0b73a9a 100644
--- a/include/net/netfilter/nf_conntrack_act_ct.h
+++ b/include/net/netfilter/nf_conntrack_act_ct.h
@@ -20,21 +20,6 @@ static inline struct nf_conn_act_ct_ext *nf_conn_act_ct_ext_find(const struct nf
#endif
}
-static inline struct nf_conn_act_ct_ext *nf_conn_act_ct_ext_add(struct nf_conn *ct)
-{
-#if IS_ENABLED(CONFIG_NET_ACT_CT)
- struct nf_conn_act_ct_ext *act_ct = nf_ct_ext_find(ct, NF_CT_EXT_ACT_CT);
-
- if (act_ct)
- return act_ct;
-
- act_ct = nf_ct_ext_add(ct, NF_CT_EXT_ACT_CT, GFP_ATOMIC);
- return act_ct;
-#else
- return NULL;
-#endif
-}
-
static inline void nf_conn_act_ct_ext_fill(struct sk_buff *skb, struct nf_conn *ct,
enum ip_conntrack_info ctinfo)
{
@@ -47,4 +32,23 @@ static inline void nf_conn_act_ct_ext_fill(struct sk_buff *skb, struct nf_conn *
#endif
}
+static inline struct
+nf_conn_act_ct_ext *nf_conn_act_ct_ext_add(struct sk_buff *skb,
+ struct nf_conn *ct,
+ enum ip_conntrack_info ctinfo)
+{
+#if IS_ENABLED(CONFIG_NET_ACT_CT)
+ struct nf_conn_act_ct_ext *act_ct = nf_ct_ext_find(ct, NF_CT_EXT_ACT_CT);
+
+ if (act_ct)
+ return act_ct;
+
+ act_ct = nf_ct_ext_add(ct, NF_CT_EXT_ACT_CT, GFP_ATOMIC);
+ nf_conn_act_ct_ext_fill(skb, ct, ctinfo);
+ return act_ct;
+#else
+ return NULL;
+#endif
+}
+
#endif /* _NF_CONNTRACK_ACT_CT_H */
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 0b9a785dea45..3019a4406ca4 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -985,7 +985,7 @@ static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,
if (err)
return err;
- nf_conn_act_ct_ext_add(ct);
+ nf_conn_act_ct_ext_add(skb, ct, ctinfo);
} else if (IS_ENABLED(CONFIG_NF_CONNTRACK_LABELS) &&
labels_nonzero(&info->labels.mask)) {
err = ovs_ct_set_labels(ct, key, &info->labels.value,
diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
index 9583645e86c2..0db0ecf1d110 100644
--- a/net/sched/act_ct.c
+++ b/net/sched/act_ct.c
@@ -376,6 +376,17 @@ static void tcf_ct_flow_tc_ifidx(struct flow_offload *entry,
entry->tuplehash[dir].tuple.tc.iifidx = act_ct_ext->ifindex[dir];
}
+static void tcf_ct_flow_ct_ext_ifidx_update(struct flow_offload *entry)
+{
+ struct nf_conn_act_ct_ext *act_ct_ext;
+
+ act_ct_ext = nf_conn_act_ct_ext_find(entry->ct);
+ if (act_ct_ext) {
+ tcf_ct_flow_tc_ifidx(entry, act_ct_ext, FLOW_OFFLOAD_DIR_ORIGINAL);
+ tcf_ct_flow_tc_ifidx(entry, act_ct_ext, FLOW_OFFLOAD_DIR_REPLY);
+ }
+}
+
static void tcf_ct_flow_table_add(struct tcf_ct_flow_table *ct_ft,
struct nf_conn *ct,
bool tcp, bool bidirectional)
@@ -671,6 +682,8 @@ static bool tcf_ct_flow_table_lookup(struct tcf_ct_params *p,
else
ctinfo = IP_CT_ESTABLISHED_REPLY;
+ nf_conn_act_ct_ext_fill(skb, ct, ctinfo);
+ tcf_ct_flow_ct_ext_ifidx_update(flow);
flow_offload_refresh(nf_ft, flow, force_refresh);
if (!test_bit(IPS_ASSURED_BIT, &ct->status)) {
/* Process this flow in SW to allow promoting to ASSURED */
@@ -1034,7 +1047,7 @@ TC_INDIRECT_SCOPE int tcf_ct_act(struct sk_buff *skb, const struct tc_action *a,
tcf_ct_act_set_labels(ct, p->labels, p->labels_mask);
if (!nf_ct_is_confirmed(ct))
- nf_conn_act_ct_ext_add(ct);
+ nf_conn_act_ct_ext_add(skb, ct, ctinfo);
/* This will take care of sending queued events
* even if the connection is already confirmed.
--
2.39.2
^ permalink raw reply related
* Re: [PATCH bpf-next] bpftool: fix prog object type in manpage
From: Yonghong Song @ 2023-11-03 15:34 UTC (permalink / raw)
To: Artem Savkov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, bpf, netdev
Cc: Jerry Snitselaar
In-Reply-To: <20231103081126.170034-1-asavkov@redhat.com>
On 11/3/23 1:11 AM, Artem Savkov wrote:
> bpftool's man page lists "program" as one of possible values for OBJECT,
> while in fact bpftool accepts "prog" instead.
>
> Reported-by: Jerry Snitselaar <jsnitsel@redhat.com>
> Signed-off-by: Artem Savkov <asavkov@redhat.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
^ permalink raw reply
* Re: [PATCH bpf-next] bpftool: fix prog object type in manpage
From: Quentin Monnet @ 2023-11-03 16:17 UTC (permalink / raw)
To: Yonghong Song, Artem Savkov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, bpf, netdev
Cc: Jerry Snitselaar
In-Reply-To: <a115f76f-f53c-42c0-918a-b88d34c3f54e@linux.dev>
On 3 November 2023 15:34:05 GMT, Yonghong Song <yonghong.song@linux.dev> wrote:
>
>On 11/3/23 1:11 AM, Artem Savkov wrote:
>> bpftool's man page lists "program" as one of possible values for OBJECT,
>> while in fact bpftool accepts "prog" instead.
>>
>> Reported-by: Jerry Snitselaar <jsnitsel@redhat.com>
>> Signed-off-by: Artem Savkov <asavkov@redhat.com>
>
>
>Acked-by: Yonghong Song <yonghong.song@linux.dev>
>
Acked-by: Quentin Monnet <quentin@isovalent.com>
Thanks!
^ permalink raw reply
* Re: [PATCH] selftests: bpf: xskxceiver: ksft_print_msg: fix format type error
From: Andrii Nakryiko @ 2023-11-03 16:26 UTC (permalink / raw)
To: Anders Roxell
Cc: bjorn, magnus.karlsson, maciej.fijalkowski, netdev, bpf,
linux-kernel
In-Reply-To: <20231103112237.1756288-1-anders.roxell@linaro.org>
On Fri, Nov 3, 2023 at 4:23 AM Anders Roxell <anders.roxell@linaro.org> wrote:
>
> Crossbuilding selftests/bpf for architecture arm64, format specifies
> type error show up like.
>
> xskxceiver.c:912:34: error: format specifies type 'int' but the argument
> has type '__u64' (aka 'unsigned long long') [-Werror,-Wformat]
> ksft_print_msg("[%s] expected meta_count [%d], got meta_count [%d]\n",
> ~~
> %llu
> __func__, pkt->pkt_nb, meta->count);
> ^~~~~~~~~~~
> xskxceiver.c:929:55: error: format specifies type 'unsigned long long' but
> the argument has type 'u64' (aka 'unsigned long') [-Werror,-Wformat]
> ksft_print_msg("Frag invalid addr: %llx len: %u\n", addr, len);
> ~~~~ ^~~~
>
With u64s it might be %llx or %lx, depending on architecture, so best
is to force cast to (long long) or (unsigned long long) and then use
%llx.
> Fixing the issues by using the proposed format specifiers by the
> compilor.
>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> ---
> tools/testing/selftests/bpf/xskxceiver.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/xskxceiver.c b/tools/testing/selftests/bpf/xskxceiver.c
> index 591ca9637b23..dc03692f34d8 100644
> --- a/tools/testing/selftests/bpf/xskxceiver.c
> +++ b/tools/testing/selftests/bpf/xskxceiver.c
> @@ -908,7 +908,7 @@ static bool is_metadata_correct(struct pkt *pkt, void *buffer, u64 addr)
> struct xdp_info *meta = data - sizeof(struct xdp_info);
>
> if (meta->count != pkt->pkt_nb) {
> - ksft_print_msg("[%s] expected meta_count [%d], got meta_count [%d]\n",
> + ksft_print_msg("[%s] expected meta_count [%d], got meta_count [%llu]\n",
> __func__, pkt->pkt_nb, meta->count);
> return false;
> }
> @@ -926,11 +926,11 @@ static bool is_frag_valid(struct xsk_umem_info *umem, u64 addr, u32 len, u32 exp
>
> if (addr >= umem->num_frames * umem->frame_size ||
> addr + len > umem->num_frames * umem->frame_size) {
> - ksft_print_msg("Frag invalid addr: %llx len: %u\n", addr, len);
> + ksft_print_msg("Frag invalid addr: %lx len: %u\n", addr, len);
> return false;
> }
> if (!umem->unaligned_mode && addr % umem->frame_size + len > umem->frame_size) {
> - ksft_print_msg("Frag crosses frame boundary addr: %llx len: %u\n", addr, len);
> + ksft_print_msg("Frag crosses frame boundary addr: %lx len: %u\n", addr, len);
> return false;
> }
>
> @@ -1029,7 +1029,7 @@ static int complete_pkts(struct xsk_socket_info *xsk, int batch_size)
> u64 addr = *xsk_ring_cons__comp_addr(&xsk->umem->cq, idx + rcvd - 1);
>
> ksft_print_msg("[%s] Too many packets completed\n", __func__);
> - ksft_print_msg("Last completion address: %llx\n", addr);
> + ksft_print_msg("Last completion address: %lx\n", addr);
> return TEST_FAILURE;
> }
>
> @@ -1513,7 +1513,7 @@ static int validate_tx_invalid_descs(struct ifobject *ifobject)
> }
>
> if (stats.tx_invalid_descs != ifobject->xsk->pkt_stream->nb_pkts / 2) {
> - ksft_print_msg("[%s] tx_invalid_descs incorrect. Got [%u] expected [%u]\n",
> + ksft_print_msg("[%s] tx_invalid_descs incorrect. Got [%llu] expected [%u]\n",
> __func__, stats.tx_invalid_descs,
> ifobject->xsk->pkt_stream->nb_pkts);
> return TEST_FAILURE;
> --
> 2.42.0
>
>
^ permalink raw reply
* [PATCH iwl-next] ice: periodically kick Tx timestamp interrupt
From: Karol Kolacinski @ 2023-11-03 16:29 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, anthony.l.nguyen, jesse.brandeburg, Jacob Keller,
Karol Kolacinski, Andrii Staikov
From: Jacob Keller <jacob.e.keller@intel.com>
The E822 hardware for Tx timestamping keeps track of how many
outstanding timestamps are still in the PHY memory block. It will not
generate a new interrupt to the MAC until all of the timestamps in the
region have been read.
If somehow all the available data is not read, but the driver has exited
its interrupt routine already, the PHY will not generate a new interrupt
even if new timestamp data is captured. Because no interrupt is
generated, the driver never processes the timestamp data. This state
results in a permanent failure for all future Tx timestamps.
It is not clear how the driver and hardware could enter this state.
However, if it does, there is currently no recovery mechanism.
Add a recovery mechanism via the periodic PTP work thread which invokes
ice_ptp_periodic_work(). Introduce a new check,
ice_ptp_maybe_trigger_tx_interrupt() which checks the PHY timestamp
ready bitmask. If any bits are set, trigger a software interrupt by
writing to PFINT_OICR.
Once triggered, the main timestamp processing thread will read through
the PHY data and clear the outstanding timestamp data. Once cleared, new
data should trigger interrupts as expected.
This should allow recovery from such a state rather than leaving the
device in a state where we cannot process Tx timestamps.
It is possible that this function checks for timestamp data
simultaneously with the interrupt, and it might trigger additional
unnecessary interrupts. This will cause a small amount of additional
processing.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Reviewed-by: Andrii Staikov <andrii.staikov@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ptp.c | 50 ++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
index 5fb9dbbdfc16..79c1fa61d1a8 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -2460,6 +2460,54 @@ enum ice_tx_tstamp_work ice_ptp_process_ts(struct ice_pf *pf)
}
}
+/**
+ * ice_ptp_maybe_trigger_tx_interrupt - Trigger Tx timstamp interrupt
+ * @pf: Board private structure
+ *
+ * The device PHY issues Tx timestamp interrupts to the driver for processing
+ * timestamp data from the PHY. It will not interrupt again until all
+ * current timestamp data is read. In rare circumstances, it is possible that
+ * the driver fails to read all outstanding data.
+ *
+ * To avoid getting permanently stuck, periodically check if the PHY has
+ * outstanding timestamp data. If so, trigger an interrupt from software to
+ * process this data.
+ */
+static void ice_ptp_maybe_trigger_tx_interrupt(struct ice_pf *pf)
+{
+ struct device *dev = ice_pf_to_dev(pf);
+ struct ice_hw *hw = &pf->hw;
+ bool trigger_oicr = false;
+ unsigned int i;
+
+ if (ice_is_e810(hw))
+ return;
+
+ if (!ice_pf_src_tmr_owned(pf))
+ return;
+
+ for (i = 0; i < ICE_MAX_QUAD; i++) {
+ u64 tstamp_ready;
+ int err;
+
+ err = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);
+ if (!err && tstamp_ready) {
+ trigger_oicr = true;
+ break;
+ }
+ }
+
+ if (trigger_oicr) {
+ /* Trigger a software interrupt, to ensure this data
+ * gets processed.
+ */
+ dev_dbg(dev, "PTP periodic task detected waiting timestamps. Triggering Tx timestamp interrupt now.\n");
+
+ wr32(hw, PFINT_OICR, PFINT_OICR_TSYN_TX_M);
+ ice_flush(hw);
+ }
+}
+
static void ice_ptp_periodic_work(struct kthread_work *work)
{
struct ice_ptp *ptp = container_of(work, struct ice_ptp, work.work);
@@ -2471,6 +2519,8 @@ static void ice_ptp_periodic_work(struct kthread_work *work)
err = ice_ptp_update_cached_phctime(pf);
+ ice_ptp_maybe_trigger_tx_interrupt(pf);
+
/* Run twice a second or reschedule if phc update failed */
kthread_queue_delayed_work(ptp->kworker, &ptp->work,
msecs_to_jiffies(err ? 10 : 500));
base-commit: 75eabdb41c25d36bd15661df81033a4e3086c4c9
--
2.40.1
^ permalink raw reply related
* RE: [EXT] Re: [net PATCH] octeontx2: Fix klockwork and coverity issues
From: Suman Ghosh @ 2023-11-03 16:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Sunil Kovvuri Goutham, Geethasowjanya Akula,
Subbaraya Sundeep Bhatta, Hariprasad Kelam, Linu Cherian,
Jerin Jacob Kollanukkaran, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
horms@kernel.org, Ratheesh Kannoth
In-Reply-To: <335216cc-3412-4898-8b88-10405ff7c316@lunn.ch>
>> Fix all klockwork and coverity issues reported on AF and PF/VF driver.
>>
>> Signed-off-by: Suman Ghosh <sumang@marvell.com>
>> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
>
>The subject line is:
>[net PATCH] octeontx2: Fix klockwork and coverity issues
>
>So you want these fixes backported to net? If so, you need to provide
>Fixes: tags.
>
>This patch is way too big. A fix patch generally fixes one thing, and it
>documents what it fixes. Or it could be one class of problems, like
>uninitialised variables etc. Its good to include the message from the
>static analyser in the commit message.
>
> Andrew
[Suman] Yes, backporting to net was the intention. Do we need to put all the fixes tags? Because the fixes are from different commits.
Are there any generic submission steps for klockwork fixes?
>
>---
>pw-bot: cr
^ permalink raw reply
* Re: [PATCH v8 2/2] can: esd: add support for esd GmbH PCIe/402 CAN interface family
From: Simon Horman @ 2023-11-03 16:48 UTC (permalink / raw)
To: Stefan Mätje
Cc: Marc Kleine-Budde, linux-can, netdev, linux-kernel,
Wolfgang Grandegger, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
In-Reply-To: <20231025141635.1459606-3-stefan.maetje@esd.eu>
On Wed, Oct 25, 2023 at 04:16:35PM +0200, Stefan Mätje wrote:
> This patch adds support for the PCI based PCIe/402 CAN interface family
> from esd GmbH that is available with various form factors
> (https://esd.eu/en/products/402-series-can-interfaces).
>
> All boards utilize a FPGA based CAN controller solution developed
> by esd (esdACC). For more information on the esdACC see
> https://esd.eu/en/products/esdacc.
>
> This driver detects all available CAN interface board variants of
> the family but atm. operates the CAN-FD capable devices in
> Classic-CAN mode only! A later patch will introduce the CAN-FD
> functionality in this driver.
>
> Co-developed-by: Thomas Körper <thomas.koerper@esd.eu>
> Signed-off-by: Thomas Körper <thomas.koerper@esd.eu>
> Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
...
> +static int pci402_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> +{
> + struct pci402_card *card = NULL;
> + int err;
> +
> + err = pci_enable_device(pdev);
> + if (err)
> + return err;
> +
> + card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
> + if (!card)
Hi Thomas and Stefan,
If this condition is met then the function will return err,
but err is set to 0. Perhaps it should be set to an error value here?
Flagged by Smatch.
> + goto failure_disable_pci;
> +
> + pci_set_drvdata(pdev, card);
> +
> + err = pci_request_regions(pdev, pci_name(pdev));
> + if (err)
> + goto failure_disable_pci;
> +
> + card->addr = pci_iomap(pdev, PCI402_BAR, PCI402_IO_LEN_TOTAL);
> + if (!card->addr) {
> + err = -ENOMEM;
> + goto failure_release_regions;
> + }
> +
> + err = pci402_init_card(pdev);
> + if (err)
> + goto failure_unmap;
> +
> + err = pci402_init_dma(pdev);
> + if (err)
> + goto failure_unmap;
> +
> + err = pci402_init_interrupt(pdev);
> + if (err)
> + goto failure_finish_dma;
> +
> + err = pci402_init_cores(pdev);
> + if (err)
> + goto failure_finish_interrupt;
> +
> + return 0;
> +
> +failure_finish_interrupt:
> + pci402_finish_interrupt(pdev);
> +
> +failure_finish_dma:
> + pci402_finish_dma(pdev);
> +
> +failure_unmap:
> + pci_iounmap(pdev, card->addr);
> +
> +failure_release_regions:
> + pci_release_regions(pdev);
> +
> +failure_disable_pci:
> + pci_disable_device(pdev);
> +
> + return err;
> +}
...
^ permalink raw reply
* Re: [PATCH v5 8/8] r8152: Block future register access if register access fails
From: Simon Horman @ 2023-11-03 16:52 UTC (permalink / raw)
To: Doug Anderson
Cc: Jakub Kicinski, Hayes Wang, David S . Miller, Edward Hill,
Laura Nao, Alan Stern, linux-usb, Grant Grundler, Bjørn Mork,
Eric Dumazet, Paolo Abeni, linux-kernel, netdev
In-Reply-To: <CAD=FV=XVJVkyA09Ca_YGa5xRS4jGra4cw-6ArgwCekMzn7uWcA@mail.gmail.com>
On Wed, Oct 25, 2023 at 01:24:55PM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Oct 25, 2023 at 9:28 AM Simon Horman <horms@kernel.org> wrote:
> >
> > On Fri, Oct 20, 2023 at 02:06:59PM -0700, Douglas Anderson wrote:
> >
> > ...
> >
> > > @@ -9603,25 +9713,14 @@ static bool rtl8152_supports_lenovo_macpassthru(struct usb_device *udev)
> > > return 0;
> > > }
> > >
> > > -static int rtl8152_probe(struct usb_interface *intf,
> > > - const struct usb_device_id *id)
> > > +static int rtl8152_probe_once(struct usb_interface *intf,
> > > + const struct usb_device_id *id, u8 version)
> > > {
> > > struct usb_device *udev = interface_to_usbdev(intf);
> > > struct r8152 *tp;
> > > struct net_device *netdev;
> > > - u8 version;
> > > int ret;
> > >
> > > - if (intf->cur_altsetting->desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC)
> > > - return -ENODEV;
> > > -
> > > - if (!rtl_check_vendor_ok(intf))
> > > - return -ENODEV;
> > > -
> > > - version = rtl8152_get_version(intf);
> > > - if (version == RTL_VER_UNKNOWN)
> > > - return -ENODEV;
> > > -
> > > usb_reset_device(udev);
> > > netdev = alloc_etherdev(sizeof(struct r8152));
> > > if (!netdev) {
> > > @@ -9784,10 +9883,20 @@ static int rtl8152_probe(struct usb_interface *intf,
> > > else
> > > device_set_wakeup_enable(&udev->dev, false);
> > >
> > > + /* If we saw a control transfer error while probing then we may
> > > + * want to try probe() again. Consider this an error.
> > > + */
> > > + if (test_bit(PROBE_SHOULD_RETRY, &tp->flags))
> > > + goto out2;
> >
> > Sorry for being a bit slow here, but if this is an error condition,
> > sould ret be set to an error value?
> >
> > As flagged by Smatch.
>
> Thanks for the note. I think we're OK, though. If you look at the
> "out:" label, which is right after "out1" it tests for the same bit.
> That will set "ret = -EAGAIN" for us.
Thanks, and sorry for being even slower than the previous time.
I see your point regarding "out:" and agree that the code is correct.
> I'll admit it probably violates the principle of least astonishment,
> but there's a method to my madness. Specifically:
>
> a) We need a test here to make sure we don't return "success" if the
> bit is set. The driver doesn't error check for success when it
> modifies HW registers so it might _thnk_ it was successful but still
> have this bit set. ...so we need this check right before we return
> "success".
>
> b) We also need to test for this bit if we're in the error handling
> code. Even though the driver doesn't check for success in lots of
> places, there still could be some places that notice an error. It may
> return any kind of error here, so we need to override it to -EAGAIN.
>
> ...so I just set "ret = -EAGAIN" in one place.
>
> Does that make sense? If you want to submit a patch adjusting the
> comment to make this more obvious, I'm happy to review it.
Thanks it does make sense.
And I don't think any further action is required.
^ permalink raw reply
* Re: [PATCH net] tcp: Fix -Wc23-extensions in tcp_options_write()
From: Nathan Chancellor @ 2023-11-03 16:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: edumazet, davem, dsahern, kuba, pabeni, ndesaulniers, trix,
0x7f454c46, fruggeri, noureddine, netdev, linux-kernel, llvm,
patches
In-Reply-To: <ZUStrQCqBjBBB6dc@infradead.org>
Hi Christoph,
On Fri, Nov 03, 2023 at 01:22:05AM -0700, Christoph Hellwig wrote:
> On Tue, Oct 31, 2023 at 01:23:35PM -0700, Nathan Chancellor wrote:
> > Clang warns (or errors with CONFIG_WERROR=y) when CONFIG_TCP_AO is set:
> >
> > net/ipv4/tcp_output.c:663:2: error: label at end of compound statement is a C23 extension [-Werror,-Wc23-extensions]
> > 663 | }
> > | ^
> > 1 error generated.
> >
> > On earlier releases (such as clang-11, the current minimum supported
> > version for building the kernel) that do not support C23, this was a
> > hard error unconditionally:
> >
> > net/ipv4/tcp_output.c:663:2: error: expected statement
> > }
> > ^
> > 1 error generated.
> >
> > Add a semicolon after the label to create an empty statement, which
> > resolves the warning or error for all compilers.
>
> Can you please just split the A0 handlig into a separate helper, which
> shuld make the whole thing a lot cleaner?
Is something like this (I think I got all the pointer manipulation
correct...) what you had in mind? I am happy to send that as a v2 if the
netdev folks would prefer it over this small change (along with some
guidance about the function name, if it should be something different).
Cheers,
Nathan
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index f558c054cf6e..6f2a5e3bb7b3 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -601,6 +601,43 @@ static void bpf_skops_write_hdr_opt(struct sock *sk, struct sk_buff *skb,
}
#endif
+static void process_tcp_ao_options(struct tcp_sock *tp,
+ const struct tcp_request_sock *tcprsk,
+ struct tcp_out_options *opts,
+ struct tcp_key *key, __be32 **ptr)
+{
+#ifdef CONFIG_TCP_AO
+ u8 maclen = tcp_ao_maclen(key->ao_key);
+
+ if (tcprsk) {
+ u8 aolen = maclen + sizeof(struct tcp_ao_hdr);
+
+ *(*ptr)++ = htonl((TCPOPT_AO << 24) | (aolen << 16) |
+ (tcprsk->ao_keyid << 8) |
+ (tcprsk->ao_rcv_next));
+ } else {
+ struct tcp_ao_key *rnext_key;
+ struct tcp_ao_info *ao_info;
+
+ ao_info = rcu_dereference_check(tp->ao_info,
+ lockdep_sock_is_held(&tp->inet_conn.icsk_inet.sk));
+ rnext_key = READ_ONCE(ao_info->rnext_key);
+ if (WARN_ON_ONCE(!rnext_key))
+ return;
+ *(*ptr)++ = htonl((TCPOPT_AO << 24) |
+ (tcp_ao_len(key->ao_key) << 16) |
+ (key->ao_key->sndid << 8) |
+ (rnext_key->rcvid));
+ }
+ opts->hash_location = (__u8 *)(*ptr);
+ *ptr += maclen / sizeof(**ptr);
+ if (unlikely(maclen % sizeof(**ptr))) {
+ memset(*ptr, TCPOPT_NOP, sizeof(**ptr));
+ (*ptr)++;
+ }
+#endif
+}
+
/* Write previously computed TCP options to the packet.
*
* Beware: Something in the Internet is very sensitive to the ordering of
@@ -629,37 +666,7 @@ static void tcp_options_write(struct tcphdr *th, struct tcp_sock *tp,
opts->hash_location = (__u8 *)ptr;
ptr += 4;
} else if (tcp_key_is_ao(key)) {
-#ifdef CONFIG_TCP_AO
- u8 maclen = tcp_ao_maclen(key->ao_key);
-
- if (tcprsk) {
- u8 aolen = maclen + sizeof(struct tcp_ao_hdr);
-
- *ptr++ = htonl((TCPOPT_AO << 24) | (aolen << 16) |
- (tcprsk->ao_keyid << 8) |
- (tcprsk->ao_rcv_next));
- } else {
- struct tcp_ao_key *rnext_key;
- struct tcp_ao_info *ao_info;
-
- ao_info = rcu_dereference_check(tp->ao_info,
- lockdep_sock_is_held(&tp->inet_conn.icsk_inet.sk));
- rnext_key = READ_ONCE(ao_info->rnext_key);
- if (WARN_ON_ONCE(!rnext_key))
- goto out_ao;
- *ptr++ = htonl((TCPOPT_AO << 24) |
- (tcp_ao_len(key->ao_key) << 16) |
- (key->ao_key->sndid << 8) |
- (rnext_key->rcvid));
- }
- opts->hash_location = (__u8 *)ptr;
- ptr += maclen / sizeof(*ptr);
- if (unlikely(maclen % sizeof(*ptr))) {
- memset(ptr, TCPOPT_NOP, sizeof(*ptr));
- ptr++;
- }
-out_ao:
-#endif
+ process_tcp_ao_options(tp, tcprsk, opts, key, &ptr);
}
if (unlikely(opts->mss)) {
*ptr++ = htonl((TCPOPT_MSS << 24) |
^ permalink raw reply related
* Re: [PATCH iwl-next v1] ice: change vfs.num_msix_per to vf->num_msix
From: Simon Horman @ 2023-11-03 16:56 UTC (permalink / raw)
To: Michal Swiatkowski
Cc: intel-wired-lan, netdev, yahui.cao, jacob.e.keller,
przemyslaw.kitszel, marcin.szycik
In-Reply-To: <20231024142010.175592-1-michal.swiatkowski@linux.intel.com>
On Tue, Oct 24, 2023 at 04:20:10PM +0200, Michal Swiatkowski wrote:
> vfs::num_msix_per should be only used as default value for
> vf->num_msix. For other use cases vf->num_msix should be used, as VF can
> have different MSI-X amount values.
>
> Fix incorrect register index calculation. vfs::num_msix_per and
> pf->sriov_base_vector shouldn't be used after implementation of changing
> MSI-X amount on VFs. Instead vf->first_vector_idx should be used, as it
> is storing value for first irq index.
>
> Fixes: fe1c5ca2fe76 ("ice: implement num_msix field per VF")
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net] tcp: Fix -Wc23-extensions in tcp_options_write()
From: Nick Desaulniers @ 2023-11-03 16:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Nathan Chancellor, edumazet, davem, dsahern, kuba, pabeni, trix,
0x7f454c46, fruggeri, noureddine, netdev, linux-kernel, llvm,
patches, Thorsten Leemhuis
In-Reply-To: <ZUStrQCqBjBBB6dc@infradead.org>
On Fri, Nov 3, 2023 at 1:22 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Oct 31, 2023 at 01:23:35PM -0700, Nathan Chancellor wrote:
> > Clang warns (or errors with CONFIG_WERROR=y) when CONFIG_TCP_AO is set:
> >
> > net/ipv4/tcp_output.c:663:2: error: label at end of compound statement is a C23 extension [-Werror,-Wc23-extensions]
> > 663 | }
> > | ^
> > 1 error generated.
> >
> > On earlier releases (such as clang-11, the current minimum supported
> > version for building the kernel) that do not support C23, this was a
> > hard error unconditionally:
> >
> > net/ipv4/tcp_output.c:663:2: error: expected statement
> > }
> > ^
> > 1 error generated.
> >
> > Add a semicolon after the label to create an empty statement, which
> > resolves the warning or error for all compilers.
>
> Can you please just split the A0 handlig into a separate helper, which
> shuld make the whole thing a lot cleaner?
Just a note; mainline is currently red over this for us since
1e03d32bea8e spent all of ~3 days in linux-next before getting merged
into mainline.
Whatever the fix is, it would be great to get it into mainline ASAP.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
From: Luiz Angelo Daros de Luca @ 2023-11-03 17:05 UTC (permalink / raw)
To: Linus Walleij
Cc: Vladimir Oltean, Andrew Lunn, Florian Fainelli, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <CACRpkdaoBo0S0RgLhacObd3pbjtWAfr6s3oizQAHqdB76gaG5A@mail.gmail.com>
> > [ 3.967086] realtek-smi switch: set MAC: 42:E4:F5:XX:XX:XX
>
> Unrelated: I have seen other DSA switches "inherit" the MAC of the
> conduit interface (BRCM). I wonder if we could do that too instead
> of this random MAC number. Usually the conduit interface has a
> properly configured MAC.
>
> > [ 3.976779] realtek-smi switch: missing child interrupt-controller node
> > [ 3.983455] realtek-smi switch: no interrupt support
> > [ 4.158891] realtek-smi switch: no LED for port 5
>
> Are the LEDs working? My device has no LEDs so I have never
> tested it, despite I coded it. (Also these days we can actually
> support each LED individually configured from device tree using
> the LED API, but that would be quite a bit of code, so only some
> fun for the aspiring developer...)
No at all. LEDs sometimes change state all together but they normally
are just kept on.
My device is not funny to play with. It has only 32MB of RAM and it
frequently OOM. Even flashing a new image requires some sokoban,
unloading all possible kernel modules. It is not usable anymore in the
real world but I might take a look at LEDs just for fun. The LEDs in
the old swconfig driver do work and I can compare the code.
> > Maybe the ag71xx driver is doing something differently.
>
> I'll look at it!
>
> Thanks a lot Luiz,
I'm glad to help.
Regards,
Luiz
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox