* Re: [PATCH net-next 01/12] netfilter: nfnetlink_hook: Dump nat type chains
From: patchwork-bot+netdevbpf @ 2026-07-03 20:10 UTC (permalink / raw)
To: Florian Westphal
Cc: netdev, pabeni, davem, edumazet, kuba, netfilter-devel, pablo
In-Reply-To: <20260702105003.13550-2-fw@strlen.de>
Hello:
This series was applied to netdev/net-next.git (main)
by Florian Westphal <fw@strlen.de>:
On Thu, 2 Jul 2026 12:49:52 +0200 you wrote:
> From: Phil Sutter <phil@nwl.cc>
>
> These chains are indirectly attached to the hook since they are
> not called for packets belonging to an established connection.
>
> Introduce NF_HOOK_OP_NAT to identify the container and dump attached
> entries instead of the container itself.
>
> [...]
Here is the summary with links:
- [net-next,01/12] netfilter: nfnetlink_hook: Dump nat type chains
https://git.kernel.org/netdev/net-next/c/b010e2a4a9ac
- [net-next,02/12] netfilter: x_tables: replace strlcat() with snprintf()
https://git.kernel.org/netdev/net-next/c/9cc4d9720d70
- [net-next,03/12] netfilter: replace u_int8_t and u_int16t with u8 and u16
https://git.kernel.org/netdev/net-next/c/32b00984e002
- [net-next,04/12] netfilter: avoid strcpy usage
https://git.kernel.org/netdev/net-next/c/1501ab0701fd
- [net-next,05/12] netfilter: remove redundant null check before kvfree()
https://git.kernel.org/netdev/net-next/c/5efbced92ec1
- [net-next,06/12] netfilter: xt_tcpmss: add checkentry for parameter validation
https://git.kernel.org/netdev/net-next/c/68fc6c6470d6
- [net-next,07/12] netfilter: xt_dscp: add checkentry for tos match
https://git.kernel.org/netdev/net-next/c/60aee97fc7f8
- [net-next,08/12] netfilter: nf_conntrack_helper: do not hash by tuple
https://git.kernel.org/netdev/net-next/c/26fb502773bc
- [net-next,09/12] netfilter: conntrack: get rid of tuple in helper definitions
https://git.kernel.org/netdev/net-next/c/5de6c8ad0bcc
- [net-next,10/12] netfilter: conntrack: remove obsolete module parameters
https://git.kernel.org/netdev/net-next/c/78217fb2ccf9
- [net-next,11/12] netfilter: ebtables: bound num_counters like nentries in do_replace()
https://git.kernel.org/netdev/net-next/c/43ae85af154b
- [net-next,12/12] netfilter: nft_ct: support expectation creation for natted flows
https://git.kernel.org/netdev/net-next/c/d4beefc90a66
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 1/1] net: sctp: fix AUTH HMAC list overflow into auth_chunks
From: Xin Long @ 2026-07-03 20:20 UTC (permalink / raw)
To: Ren Wei
Cc: linux-sctp, netdev, marcelo.leitner, davem, edumazet, pabeni,
horms, vladislav.yasevich, yuantan098, dstsmallbird, xizh2024
In-Reply-To: <e62943a59f5e1c7a68beddc1dbebe50a9a036c16.1782798905.git.xizh2024@lzu.edu.cn>
On Fri, Jul 3, 2026 at 3:19 AM Ren Wei <enjou1224z@gmail.com> wrote:
>
> From: Zihan Xi <xizh2024@lzu.edu.cn>
>
> sctp_auth_ep_set_hmacs() may advertise a 12-byte HMAC-ALGO parameter when
> four identifiers are configured, but the association only stores ten bytes
> in c.auth_hmacs. sctp_association_init() copies the advertised length and
> overwrites the adjacent auth_chunks field, so sctp_auth_asoc_verify_hmac_id()
> accepts forged HMAC identifiers and sctp_auth_get_hmac() indexes past
> sctp_hmac_list.
>
> Clamp the stored parameter length to the association buffer, copy only that
> many bytes when initializing an association, and reject out-of-range HMAC
> identifiers in sctp_auth_get_hmac().
>
> Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.")
> Cc: stable@vger.kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Xin Liu <dstsmallbird@foxmail.com>
> Assisted-by: Codex:gpt-5.4
> Signed-off-by: Zihan Xi <xizh2024@lzu.edu.cn>
> Reviewed-by: Ren Wei <enjou1224z@gmail.com>
> ---
> net/sctp/associola.c | 10 +++++++---
> net/sctp/auth.c | 10 ++++++++--
> net/sctp/sm_statefuns.c | 2 ++
> 3 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index 62d3cc1558..760457def6 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -260,9 +260,13 @@ static struct sctp_association *sctp_association_init(
> asoc->strreset_enable = ep->strreset_enable;
>
> /* Save the hmacs and chunks list into this association */
> - if (ep->auth_hmacs_list)
> - memcpy(asoc->c.auth_hmacs, ep->auth_hmacs_list,
> - ntohs(ep->auth_hmacs_list->param_hdr.length));
> + if (ep->auth_hmacs_list) {
> + size_t hmac_len = min_t(size_t,
> + ntohs(ep->auth_hmacs_list->param_hdr.length),
> + sizeof(asoc->c.auth_hmacs));
> +
> + memcpy(asoc->c.auth_hmacs, ep->auth_hmacs_list, hmac_len);
> + }
> if (ep->auth_chunk_list)
> memcpy(asoc->c.auth_chunks, ep->auth_chunk_list,
> ntohs(ep->auth_chunk_list->param_hdr.length));
> diff --git a/net/sctp/auth.c b/net/sctp/auth.c
> index be9782760f..4d14bd6185 100644
> --- a/net/sctp/auth.c
> +++ b/net/sctp/auth.c
> @@ -447,6 +447,8 @@ struct sctp_shared_key *sctp_auth_get_shkey(
>
> const struct sctp_hmac *sctp_auth_get_hmac(__u16 hmac_id)
> {
> + if (hmac_id >= SCTP_AUTH_NUM_HMACS)
> + return NULL;
> return &sctp_hmac_list[hmac_id];
> }
>
> @@ -510,6 +512,9 @@ int sctp_auth_asoc_verify_hmac_id(const struct sctp_association *asoc,
> hmacs = (struct sctp_hmac_algo_param *)asoc->c.auth_hmacs;
> n_elt = (ntohs(hmacs->param_hdr.length) -
> sizeof(struct sctp_paramhdr)) >> 1;
> + n_elt = min_t(__u16, n_elt,
> + (sizeof(asoc->c.auth_hmacs) -
> + sizeof(struct sctp_paramhdr)) / sizeof(__u16));
>
> return __sctp_auth_find_hmacid(hmacs->hmac_ids, n_elt, hmac_id);
> }
> @@ -708,8 +713,9 @@ int sctp_auth_ep_set_hmacs(struct sctp_endpoint *ep,
> ep->auth_hmacs_list->hmac_ids[i] =
> htons(hmacs->shmac_idents[i]);
> ep->auth_hmacs_list->param_hdr.length =
> - htons(sizeof(struct sctp_paramhdr) +
> - hmacs->shmac_num_idents * sizeof(__u16));
> + htons(min_t(__u16, sizeof(struct sctp_paramhdr) +
> + hmacs->shmac_num_idents * sizeof(__u16),
> + SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2));
> return 0;
> }
>
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index d23d935e12..21cda509a0 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -4431,6 +4431,8 @@ static enum sctp_ierror sctp_sf_authenticate(
> sig_len = ntohs(chunk->chunk_hdr->length) -
> sizeof(struct sctp_auth_chunk);
> hmac = sctp_auth_get_hmac(ntohs(auth_hdr->hmac_id));
> + if (!hmac)
> + return SCTP_IERROR_AUTH_BAD_HMAC;
> if (sig_len != hmac->hmac_len)
> return SCTP_IERROR_PROTO_VIOLATION;
>
> --
> 2.43.0
I think real issue is the member:
__u8 auth_hmacs[SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2]
in struct sctp_cookie.
It's supposed to include a 'struct struct sctp_paramhdr' + N * hmac_id.
However, sizeof(struct struct sctp_paramhdr) is 4 not 2, which causes
the overflow when copying it from ep to asoc.
The right fix should be:
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index affee44bd38e..cccc662561aa 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -312,7 +312,8 @@ struct sctp_cookie {
__u8 auth_random[sizeof(struct sctp_paramhdr) +
SCTP_AUTH_RANDOM_LENGTH];
- __u8 auth_hmacs[SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2];
+ __u8 auth_hmacs[sizeof(struct sctp_paramhdr) +
+ SCTP_AUTH_NUM_HMACS * sizeof(__u16)];
__u8 auth_chunks[sizeof(struct sctp_paramhdr) + SCTP_AUTH_MAX_CHUNKS];
/* This is a shim for my peer's INIT packet, followed by
Please give it a try in your test env, Thanks.
^ permalink raw reply related
* Re: [PATCH net-next v4 1/6] r8169: add speed in private struct
From: Andrew Lunn @ 2026-07-03 20:21 UTC (permalink / raw)
To: javen
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel
In-Reply-To: <20260703092459.1124-2-javen_xu@realsil.com.cn>
On Fri, Jul 03, 2026 at 05:24:54PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds speed in private struct in order to decouple
> from phydev in the following patch supporting for phylink.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next 1/2] dt-bindings: net: nfc: samsung,s3fwrn5: add S3NRN4V and clk-req-gpios
From: Jorijn van der Graaf @ 2026-07-03 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: David Heidelberg, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Conor Dooley,
oe-linux-nfc, netdev, devicetree, linux-kernel,
Jorijn van der Graaf
In-Reply-To: <20260703202601.78563-1-jorijnvdgraaf@catcrafts.net>
The S3NRN4V is an S3FWRN5-family NFC + eSE controller found e.g. on the
Fairphone 6 (SM7635). Add a compatible for it and document the optional
clk-req-gpios property: when wired, the controller drives this line to
request its reference clock (needed to generate the poll carrier), and the
driver gates the clock on it instead of leaving it always-on.
The line is modelled as a GPIO rather than an interrupt because the driver
reads its level to (re)synchronise the clock state, not just react to its
edges. It is only meaningful on the S3NRN4V, so it is restricted to that
compatible.
Assisted-by: Claude:claude-opus-4-8
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
---
.../bindings/net/nfc/samsung,s3fwrn5.yaml | 23 ++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
index 12baee457..3ebcd0933 100644
--- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
@@ -14,12 +14,20 @@ properties:
enum:
- samsung,s3fwrn5-i2c
- samsung,s3fwrn82
+ - samsung,s3nrn4v-i2c
en-gpios:
maxItems: 1
description:
Output GPIO pin used for enabling/disabling the chip
+ clk-req-gpios:
+ maxItems: 1
+ description:
+ Input GPIO pin connected to the controller's clock-request output. When
+ present, the reference clock is enabled in response to this signal
+ instead of being left always-on.
+
interrupts:
maxItems: 1
@@ -58,12 +66,25 @@ allOf:
properties:
compatible:
contains:
- const: samsung,s3fwrn5-i2c
+ enum:
+ - samsung,s3fwrn5-i2c
+ - samsung,s3nrn4v-i2c
then:
required:
- interrupts
- reg
+ # The clock-request handshake only exists on the S3NRN4V.
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: samsung,s3nrn4v-i2c
+ then:
+ properties:
+ clk-req-gpios: false
+
examples:
- |
#include <dt-bindings/gpio/gpio.h>
--
2.55.0
^ permalink raw reply related
* [PATCH net-next 2/2] nfc: s3fwrn5: support the S3NRN4V variant
From: Jorijn van der Graaf @ 2026-07-03 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: David Heidelberg, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Conor Dooley,
oe-linux-nfc, netdev, devicetree, linux-kernel,
Jorijn van der Graaf
In-Reply-To: <20260703202601.78563-1-jorijnvdgraaf@catcrafts.net>
The S3NRN4V (e.g. on the Fairphone 6, SM7635) is an S3FWRN5-family NFC
controller that needs different bring-up, selected with a new
samsung,s3nrn4v-i2c compatible:
- It ships with working firmware behind a bootloader protocol this
driver does not implement (GET_BOOTINFO times out), so the firmware
download step is skipped. Its RF registers are (re)loaded with the
proprietary DUAL_OPTION command (the HW and SW register blobs merged
into a single stream) instead of the START/SET/STOP_RFREG sequence.
- Its reference clock speed is configured with the single-byte FW_CFG
form, sent from the ->setup hook (after CORE_RESET, before CORE_INIT).
The selector value (0x11) is taken from the vendor configuration for
this part; its encoding is not documented.
- It gates its XI clock through a CLK_REQ line: the chip drives it high
when it needs the clock, notably to synthesise the 13.56 MHz poll
carrier. Left always-on, the free-running clock never lets the chip's
TX PLL lock on a fresh start and it cannot poll (it falls back to
listen only). Service the handshake when a clk-req GPIO is described,
gating the clock on it; without one the clock stays always-on.
The error policy differs between the two configuration steps on purpose:
a clock misconfiguration is fatal (a ->setup failure aborts CORE_INIT),
whereas an RF-register update failure is only warned about and bring-up
continues, since the chip falls back to the RF registers programmed in
its flash and NFC may still work.
Unlike the host-endian word read in the legacy rfreg path, the
DUAL_OPTION checksum is accumulated with get_unaligned_le32() and emitted
little-endian explicitly, so it is correct regardless of CPU endianness.
Existing S3FWRN5 / S3FWRN82 setups keep the firmware-download path and
the always-on clock, unchanged.
Assisted-by: Claude:claude-opus-4-8
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
---
drivers/nfc/s3fwrn5/core.c | 40 +++++++++++-
drivers/nfc/s3fwrn5/i2c.c | 114 +++++++++++++++++++++++++++++++---
drivers/nfc/s3fwrn5/nci.c | 111 ++++++++++++++++++++++++++++++++-
drivers/nfc/s3fwrn5/nci.h | 32 +++++++++-
drivers/nfc/s3fwrn5/s3fwrn5.h | 14 ++++-
drivers/nfc/s3fwrn5/uart.c | 2 +-
6 files changed, 299 insertions(+), 14 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/core.c b/drivers/nfc/s3fwrn5/core.c
index af0fa8bd9..59317eaad 100644
--- a/drivers/nfc/s3fwrn5/core.c
+++ b/drivers/nfc/s3fwrn5/core.c
@@ -122,11 +122,47 @@ static int s3fwrn5_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
return 0;
}
+static int s3fwrn5_nci_setup(struct nci_dev *ndev)
+{
+ struct s3fwrn5_info *info = nci_get_drvdata(ndev);
+
+ /*
+ * Runs after CORE_RESET, before CORE_INIT. The S3NRN4V needs its
+ * reference clock configured here (the downstream stack does it in the
+ * bootloader, before CORE_RESET, but this is the earliest hook the NCI
+ * core offers and the chip accepts it).
+ */
+ if (info->variant == S3FWRN5_VARIANT_S3NRN4V)
+ return s3fwrn5_nci_clk_cfg(info);
+
+ return 0;
+}
+
static int s3fwrn5_nci_post_setup(struct nci_dev *ndev)
{
struct s3fwrn5_info *info = nci_get_drvdata(ndev);
int ret;
+ if (info->variant == S3FWRN5_VARIANT_S3NRN4V) {
+ /*
+ * The S3NRN4V ships with working firmware behind a bootloader
+ * protocol this driver does not implement, so there is no
+ * download step; the NCI core has already done CORE_RESET +
+ * CORE_INIT. Just (re)load the RF registers via DUAL_OPTION.
+ */
+ ret = s3fwrn5_nci_rf_configure_dual(info, "sec_s3nrn4v_hwreg.bin",
+ "sec_s3nrn4v_swreg.bin");
+ /*
+ * Keep going even if the blobs could not be loaded: the chip
+ * still enumerates and falls back to the RF registers programmed
+ * in its flash, so NFC may work anyway.
+ */
+ if (ret < 0)
+ dev_warn(&ndev->nfc_dev->dev,
+ "rfreg configure failed (%d)\n", ret);
+ return 0;
+ }
+
if (s3fwrn5_firmware_init(info)) {
//skip bootloader mode
return 0;
@@ -152,13 +188,14 @@ static const struct nci_ops s3fwrn5_nci_ops = {
.open = s3fwrn5_nci_open,
.close = s3fwrn5_nci_close,
.send = s3fwrn5_nci_send,
+ .setup = s3fwrn5_nci_setup,
.post_setup = s3fwrn5_nci_post_setup,
.prop_ops = s3fwrn5_nci_prop_ops,
.n_prop_ops = ARRAY_SIZE(s3fwrn5_nci_prop_ops),
};
int s3fwrn5_probe(struct nci_dev **ndev, void *phy_id, struct device *pdev,
- const struct s3fwrn5_phy_ops *phy_ops)
+ const struct s3fwrn5_phy_ops *phy_ops, enum s3fwrn5_variant variant)
{
struct s3fwrn5_info *info;
int ret;
@@ -170,6 +207,7 @@ int s3fwrn5_probe(struct nci_dev **ndev, void *phy_id, struct device *pdev,
info->phy_id = phy_id;
info->pdev = pdev;
info->phy_ops = phy_ops;
+ info->variant = variant;
mutex_init(&info->mutex);
s3fwrn5_set_mode(info, S3FWRN5_MODE_COLD);
diff --git a/drivers/nfc/s3fwrn5/i2c.c b/drivers/nfc/s3fwrn5/i2c.c
index e9a34d27a..88a498879 100644
--- a/drivers/nfc/s3fwrn5/i2c.c
+++ b/drivers/nfc/s3fwrn5/i2c.c
@@ -23,9 +23,53 @@ struct s3fwrn5_i2c_phy {
struct i2c_client *i2c_dev;
struct clk *clk;
+ /*
+ * Optional hardware clock-request handshake. When a CLK_REQ GPIO is
+ * wired, the chip drives it high while it needs its XI clock -- notably
+ * to generate the poll/reader carrier -- and the clock is gated on it
+ * instead of being left always-on (which never lets the chip's TX PLL
+ * lock on a fresh clock start, leaving it unable to poll).
+ */
+ struct gpio_desc *gpio_clk_req;
+ bool clk_on;
+ struct mutex clk_lock; /* serialises clk_on against the CLK_REQ irq */
+
unsigned int irq_skip:1;
};
+static void s3fwrn5_i2c_clk_set(struct s3fwrn5_i2c_phy *phy, bool on)
+{
+ mutex_lock(&phy->clk_lock);
+ if (on && !phy->clk_on) {
+ int ret = clk_prepare_enable(phy->clk);
+
+ if (ret == 0)
+ phy->clk_on = true;
+ else
+ dev_warn_once(&phy->i2c_dev->dev,
+ "failed to enable clock (%d); NFC may not poll\n",
+ ret);
+ } else if (!on && phy->clk_on) {
+ clk_disable_unprepare(phy->clk);
+ phy->clk_on = false;
+ }
+ mutex_unlock(&phy->clk_lock);
+}
+
+static void s3fwrn5_i2c_clk_disable_action(void *data)
+{
+ s3fwrn5_i2c_clk_set(data, false);
+}
+
+static irqreturn_t s3fwrn5_i2c_clk_req_thread(int irq, void *phy_id)
+{
+ struct s3fwrn5_i2c_phy *phy = phy_id;
+
+ s3fwrn5_i2c_clk_set(phy, gpiod_get_value_cansleep(phy->gpio_clk_req) > 0);
+
+ return IRQ_HANDLED;
+}
+
static void s3fwrn5_i2c_set_mode(void *phy_id, enum s3fwrn5_mode mode)
{
struct s3fwrn5_i2c_phy *phy = phy_id;
@@ -146,6 +190,7 @@ static irqreturn_t s3fwrn5_i2c_irq_thread_fn(int irq, void *phy_id)
static int s3fwrn5_i2c_probe(struct i2c_client *client)
{
+ enum s3fwrn5_variant variant;
struct s3fwrn5_i2c_phy *phy;
int ret;
@@ -172,15 +217,63 @@ static int s3fwrn5_i2c_probe(struct i2c_client *client)
* S3FWRN5 depends on a clock input ("XI" pin) to function properly.
* Depending on the hardware configuration this could be an always-on
* oscillator or some external clock that must be explicitly enabled.
- * Make sure the clock is running before starting S3FWRN5.
+ *
+ * If a CLK_REQ GPIO is wired, the chip gates the clock itself (driving
+ * CLK_REQ high when it needs XI); service that handshake. Otherwise just
+ * make sure the clock is running before starting S3FWRN5.
*/
- phy->clk = devm_clk_get_optional_enabled(&client->dev, NULL);
- if (IS_ERR(phy->clk))
- return dev_err_probe(&client->dev, PTR_ERR(phy->clk),
- "failed to get clock\n");
+ mutex_init(&phy->clk_lock);
+ phy->gpio_clk_req = devm_gpiod_get_optional(&client->dev, "clk-req",
+ GPIOD_IN);
+ if (IS_ERR(phy->gpio_clk_req))
+ return PTR_ERR(phy->gpio_clk_req);
+
+ if (phy->gpio_clk_req) {
+ int clk_req_irq;
+
+ phy->clk = devm_clk_get_optional(&client->dev, NULL);
+ if (IS_ERR(phy->clk))
+ return dev_err_probe(&client->dev, PTR_ERR(phy->clk),
+ "failed to get clock\n");
+
+ /*
+ * Unlike the always-on branch below, this clock is enabled by
+ * hand from the CLK_REQ handler, so devm will not disable it on
+ * unbind. Gate it off explicitly if it is still on at teardown.
+ */
+ ret = devm_add_action_or_reset(&client->dev,
+ s3fwrn5_i2c_clk_disable_action,
+ phy);
+ if (ret)
+ return ret;
+
+ clk_req_irq = gpiod_to_irq(phy->gpio_clk_req);
+ if (clk_req_irq < 0)
+ return clk_req_irq;
+
+ ret = devm_request_threaded_irq(&client->dev, clk_req_irq, NULL,
+ s3fwrn5_i2c_clk_req_thread,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING |
+ IRQF_ONESHOT,
+ "s3fwrn5_clk_req", phy);
+ if (ret)
+ return ret;
+
+ /* Seed the clock state from the current CLK_REQ level. */
+ s3fwrn5_i2c_clk_set(phy,
+ gpiod_get_value_cansleep(phy->gpio_clk_req) > 0);
+ } else {
+ phy->clk = devm_clk_get_optional_enabled(&client->dev, NULL);
+ if (IS_ERR(phy->clk))
+ return dev_err_probe(&client->dev, PTR_ERR(phy->clk),
+ "failed to get clock\n");
+ }
+ /* No match data (e.g. i2c_device_id binding) means the default FWDL. */
+ variant = (uintptr_t)i2c_get_match_data(client);
ret = s3fwrn5_probe(&phy->common.ndev, phy, &phy->i2c_dev->dev,
- &i2c_phy_ops);
+ &i2c_phy_ops, variant);
if (ret < 0)
return ret;
@@ -210,8 +303,11 @@ static const struct i2c_device_id s3fwrn5_i2c_id_table[] = {
};
MODULE_DEVICE_TABLE(i2c, s3fwrn5_i2c_id_table);
-static const struct of_device_id of_s3fwrn5_i2c_match[] __maybe_unused = {
- { .compatible = "samsung,s3fwrn5-i2c", },
+static const struct of_device_id of_s3fwrn5_i2c_match[] = {
+ { .compatible = "samsung,s3fwrn5-i2c",
+ .data = (void *)S3FWRN5_VARIANT_FWDL, },
+ { .compatible = "samsung,s3nrn4v-i2c",
+ .data = (void *)S3FWRN5_VARIANT_S3NRN4V, },
{}
};
MODULE_DEVICE_TABLE(of, of_s3fwrn5_i2c_match);
@@ -219,7 +315,7 @@ MODULE_DEVICE_TABLE(of, of_s3fwrn5_i2c_match);
static struct i2c_driver s3fwrn5_i2c_driver = {
.driver = {
.name = S3FWRN5_I2C_DRIVER_NAME,
- .of_match_table = of_match_ptr(of_s3fwrn5_i2c_match),
+ .of_match_table = of_s3fwrn5_i2c_match,
},
.probe = s3fwrn5_i2c_probe,
.remove = s3fwrn5_i2c_remove,
diff --git a/drivers/nfc/s3fwrn5/nci.c b/drivers/nfc/s3fwrn5/nci.c
index 5a9de11bb..04f4c3626 100644
--- a/drivers/nfc/s3fwrn5/nci.c
+++ b/drivers/nfc/s3fwrn5/nci.c
@@ -8,6 +8,9 @@
#include <linux/completion.h>
#include <linux/firmware.h>
+#include <linux/minmax.h>
+#include <linux/slab.h>
+#include <linux/unaligned.h>
#include "s3fwrn5.h"
#include "nci.h"
@@ -20,7 +23,7 @@ static int s3fwrn5_nci_prop_rsp(struct nci_dev *ndev, struct sk_buff *skb)
return 0;
}
-const struct nci_driver_ops s3fwrn5_nci_prop_ops[4] = {
+const struct nci_driver_ops s3fwrn5_nci_prop_ops[5] = {
{
.opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
NCI_PROP_SET_RFREG),
@@ -41,6 +44,11 @@ const struct nci_driver_ops s3fwrn5_nci_prop_ops[4] = {
NCI_PROP_FW_CFG),
.rsp = s3fwrn5_nci_prop_rsp,
},
+ {
+ .opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
+ NCI_PROP_DUAL_OPTION),
+ .rsp = s3fwrn5_nci_prop_rsp,
+ },
};
#define S3FWRN5_RFREG_SECTION_SIZE 252
@@ -117,3 +125,104 @@ int s3fwrn5_nci_rf_configure(struct s3fwrn5_info *info, const char *fw_name)
release_firmware(fw);
return ret;
}
+
+/*
+ * Configure the reference clock. The S3NRN4V expects the single-byte FW_CFG
+ * form (just the clock-speed selector). The downstream stack sends this in the
+ * bootloader before CORE_RESET; the earliest the mainline NCI core lets us in
+ * is the ->setup hook (after CORE_RESET, before CORE_INIT), which works.
+ */
+int s3fwrn5_nci_clk_cfg(struct s3fwrn5_info *info)
+{
+ u8 clk_speed = NCI_PROP_FW_CFG_CLK_SPEED;
+
+ return nci_prop_cmd(info->ndev, NCI_PROP_FW_CFG, 1, &clk_speed);
+}
+
+/*
+ * S3NRN4V RF register update. The HW and SW register blobs are merged into a
+ * single stream (HW first) and pushed via the DUAL_OPTION command:
+ * START_UPDATE, one SET_OPTION per 252-byte section, then STOP_UPDATE carrying
+ * a 16-bit checksum (running sum of the merged stream as 32-bit words).
+ */
+int s3fwrn5_nci_rf_configure_dual(struct s3fwrn5_info *info,
+ const char *hw_name, const char *sw_name)
+{
+ const struct firmware *hw_fw = NULL, *sw_fw = NULL;
+ struct nci_prop_dual_set_option_cmd set_option;
+ struct device *dev = &info->ndev->nfc_dev->dev;
+ size_t merged_size, i, len;
+ u8 *merged = NULL;
+ u8 stop_cmd[3];
+ u32 checksum;
+ u8 sub_oid;
+ int ret;
+
+ ret = request_firmware(&hw_fw, hw_name, dev);
+ if (ret < 0)
+ return ret;
+ ret = request_firmware(&sw_fw, sw_name, dev);
+ if (ret < 0)
+ goto out_hw;
+
+ merged_size = hw_fw->size + sw_fw->size;
+ merged = kmalloc(merged_size, GFP_KERNEL);
+ if (!merged) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ memcpy(merged, hw_fw->data, hw_fw->size);
+ memcpy(merged + hw_fw->size, sw_fw->data, sw_fw->size);
+
+ /*
+ * Running sum of the merged stream as little-endian 32-bit words. The
+ * rfreg blobs are word-aligned, so the loop consumes the whole stream;
+ * should a future blob not be a multiple of 4 bytes its tail would be
+ * ignored here.
+ */
+ checksum = 0;
+ for (i = 0; i + 4 <= merged_size; i += 4)
+ checksum += get_unaligned_le32(merged + i);
+
+ dev_dbg(dev, "rfreg dual-option update: %s + %s\n", hw_name, sw_name);
+
+ /* START_UPDATE */
+ sub_oid = NCI_PROP_DUAL_SUB_START_UPDATE;
+ ret = nci_prop_cmd(info->ndev, NCI_PROP_DUAL_OPTION, 1, &sub_oid);
+ if (ret < 0) {
+ dev_err(dev, "Unable to start rfreg update\n");
+ goto out;
+ }
+
+ /* SET_OPTION per section */
+ set_option.sub_oid = NCI_PROP_DUAL_SUB_SET_OPTION;
+ set_option.index = 0;
+ for (i = 0; i < merged_size; i += NCI_PROP_DUAL_SECTION_SIZE) {
+ len = min_t(size_t, merged_size - i, NCI_PROP_DUAL_SECTION_SIZE);
+ memcpy(set_option.data, merged + i, len);
+ ret = nci_prop_cmd(info->ndev, NCI_PROP_DUAL_OPTION,
+ len + 2, (__u8 *)&set_option);
+ if (ret < 0) {
+ dev_err(dev, "rfreg update error (code=%d)\n", ret);
+ goto out;
+ }
+ set_option.index++;
+ }
+
+ /* STOP_UPDATE with checksum */
+ stop_cmd[0] = NCI_PROP_DUAL_SUB_STOP_UPDATE;
+ put_unaligned_le16(checksum, &stop_cmd[1]);
+ ret = nci_prop_cmd(info->ndev, NCI_PROP_DUAL_OPTION, 3, stop_cmd);
+ if (ret < 0) {
+ dev_err(dev, "Unable to stop rfreg update\n");
+ goto out;
+ }
+
+ dev_dbg(dev, "rfreg dual-option update: success\n");
+out:
+ kfree(merged);
+ release_firmware(sw_fw);
+out_hw:
+ release_firmware(hw_fw);
+ return ret;
+}
diff --git a/drivers/nfc/s3fwrn5/nci.h b/drivers/nfc/s3fwrn5/nci.h
index bc4bce2bb..23179ba09 100644
--- a/drivers/nfc/s3fwrn5/nci.h
+++ b/drivers/nfc/s3fwrn5/nci.h
@@ -40,6 +40,13 @@ struct nci_prop_stop_rfreg_rsp {
#define NCI_PROP_FW_CFG 0x28
+/*
+ * Single-byte FW_CFG payload (clock-speed selector) for the S3NRN4V reference
+ * clock. Taken from the vendor configuration for this part (the encoding is
+ * not documented).
+ */
+#define NCI_PROP_FW_CFG_CLK_SPEED 0x11
+
struct nci_prop_fw_cfg_cmd {
__u8 clk_type;
__u8 clk_speed;
@@ -50,7 +57,30 @@ struct nci_prop_fw_cfg_rsp {
__u8 status;
};
-extern const struct nci_driver_ops s3fwrn5_nci_prop_ops[4];
+/*
+ * The S3NRN4V updates its RF registers through a single "dual option" command
+ * (a sub-OID selects the operation) instead of the START/SET/STOP_RFREG
+ * opcodes above, and expects the HW and SW register blobs merged into one
+ * stream.
+ */
+#define NCI_PROP_DUAL_OPTION 0x2a
+
+#define NCI_PROP_DUAL_SUB_START_UPDATE 0x01
+#define NCI_PROP_DUAL_SUB_SET_OPTION 0x02
+#define NCI_PROP_DUAL_SUB_STOP_UPDATE 0x03
+
+#define NCI_PROP_DUAL_SECTION_SIZE 252
+
+struct nci_prop_dual_set_option_cmd {
+ __u8 sub_oid; /* NCI_PROP_DUAL_SUB_SET_OPTION */
+ __u8 index;
+ __u8 data[NCI_PROP_DUAL_SECTION_SIZE];
+};
+
+extern const struct nci_driver_ops s3fwrn5_nci_prop_ops[5];
int s3fwrn5_nci_rf_configure(struct s3fwrn5_info *info, const char *fw_name);
+int s3fwrn5_nci_rf_configure_dual(struct s3fwrn5_info *info,
+ const char *hw_name, const char *sw_name);
+int s3fwrn5_nci_clk_cfg(struct s3fwrn5_info *info);
#endif /* __LOCAL_S3FWRN5_NCI_H_ */
diff --git a/drivers/nfc/s3fwrn5/s3fwrn5.h b/drivers/nfc/s3fwrn5/s3fwrn5.h
index 2b4922360..2d8c12091 100644
--- a/drivers/nfc/s3fwrn5/s3fwrn5.h
+++ b/drivers/nfc/s3fwrn5/s3fwrn5.h
@@ -21,6 +21,17 @@ enum s3fwrn5_mode {
S3FWRN5_MODE_FW,
};
+enum s3fwrn5_variant {
+ /* S3FWRN5 / S3FWRN82: firmware is downloaded by this driver */
+ S3FWRN5_VARIANT_FWDL,
+ /*
+ * S3NRN4V: ships with working firmware behind a bootloader protocol
+ * this driver does not implement; skip the download, configure the
+ * clock (FW_CFG) and update the RF registers via the DUAL_OPTION cmd.
+ */
+ S3FWRN5_VARIANT_S3NRN4V,
+};
+
struct s3fwrn5_phy_ops {
void (*set_wake)(void *id, bool sleep);
void (*set_mode)(void *id, enum s3fwrn5_mode);
@@ -36,6 +47,7 @@ struct s3fwrn5_info {
const struct s3fwrn5_phy_ops *phy_ops;
struct s3fwrn5_fw_info fw_info;
+ enum s3fwrn5_variant variant;
struct mutex mutex;
};
@@ -78,7 +90,7 @@ static inline int s3fwrn5_write(struct s3fwrn5_info *info, struct sk_buff *skb)
}
int s3fwrn5_probe(struct nci_dev **ndev, void *phy_id, struct device *pdev,
- const struct s3fwrn5_phy_ops *phy_ops);
+ const struct s3fwrn5_phy_ops *phy_ops, enum s3fwrn5_variant variant);
void s3fwrn5_remove(struct nci_dev *ndev);
int s3fwrn5_recv_frame(struct nci_dev *ndev, struct sk_buff *skb,
diff --git a/drivers/nfc/s3fwrn5/uart.c b/drivers/nfc/s3fwrn5/uart.c
index 540a4ddb0..47172d739 100644
--- a/drivers/nfc/s3fwrn5/uart.c
+++ b/drivers/nfc/s3fwrn5/uart.c
@@ -137,7 +137,7 @@ static int s3fwrn82_uart_probe(struct serdev_device *serdev)
}
ret = s3fwrn5_probe(&phy->common.ndev, phy, &phy->ser_dev->dev,
- &uart_phy_ops);
+ &uart_phy_ops, S3FWRN5_VARIANT_FWDL);
if (ret < 0)
goto err_serdev;
--
2.55.0
^ permalink raw reply related
* [PATCH net-next 0/2] nfc: s3fwrn5: support the S3NRN4V variant
From: Jorijn van der Graaf @ 2026-07-03 20:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: David Heidelberg, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Conor Dooley,
oe-linux-nfc, netdev, devicetree, linux-kernel,
Jorijn van der Graaf
This adds support for the Samsung S3NRN4V, an S3FWRN5-family NFC
controller found e.g. on the Fairphone 6 (SM7635), to the s3fwrn5
driver.
The S3NRN4V differs from the already-supported parts in three ways: it
ships with working firmware behind a bootloader protocol the driver
does not implement (so firmware download is skipped), it loads its RF
registers through a different proprietary command (DUAL_OPTION), and it
gates its reference clock through a CLK_REQ line that the driver must
service for the chip to be able to generate the 13.56 MHz poll carrier.
Patch 1 adds the compatible and the clk-req-gpios property to the
binding; patch 2 implements the variant in the driver.
Tested on a Fairphone 6 running a mainline kernel: reader mode polls
and reads ISO 14443-4 tags reliably, both from a fresh boot and across
driver reloads. Existing S3FWRN5/S3FWRN82 setups are unaffected.
Jorijn van der Graaf (2):
dt-bindings: net: nfc: samsung,s3fwrn5: add S3NRN4V and clk-req-gpios
nfc: s3fwrn5: support the S3NRN4V variant
.../bindings/net/nfc/samsung,s3fwrn5.yaml | 23 +++-
drivers/nfc/s3fwrn5/core.c | 40 +++++-
drivers/nfc/s3fwrn5/i2c.c | 114 ++++++++++++++++--
drivers/nfc/s3fwrn5/nci.c | 111 ++++++++++++++++-
drivers/nfc/s3fwrn5/nci.h | 32 ++++-
drivers/nfc/s3fwrn5/s3fwrn5.h | 14 ++-
drivers/nfc/s3fwrn5/uart.c | 2 +-
7 files changed, 321 insertions(+), 15 deletions(-)
base-commit: 805185b7c7a1069e407b6f7b3bc98e44d415f484
--
2.55.0
^ permalink raw reply
* Re: [PATCH net-next v4 2/6] r8169: add support for phylink
From: Andrew Lunn @ 2026-07-03 20:37 UTC (permalink / raw)
To: javen
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel
In-Reply-To: <20260703092459.1124-3-javen_xu@realsil.com.cn>
> + if (jumbo) {
> + if (!tp->jumbo_pause_saved) {
> + struct ethtool_link_ksettings cmd = {};
> + bool adv_pause, adv_asym;
> +
> + phylink_ethtool_get_pauseparam(tp->phylink, &tp->saved_pause);
> + if (tp->saved_pause.autoneg) {
> + phylink_ethtool_ksettings_get(tp->phylink, &cmd);
> + adv_pause = ethtool_link_ksettings_test_link_mode(&cmd,
> + advertising,
> + Pause);
> + adv_asym = ethtool_link_ksettings_test_link_mode(&cmd,
> + advertising,
> + Asym_Pause);
> + if (adv_pause && !adv_asym) {
> + tp->saved_pause.rx_pause = 1;
> + tp->saved_pause.tx_pause = 1;
This does not look correct. Pause is negotiated. In order to determine
how to program the MAC you need to look at what the local side is
advertising, and what the link peer is advertising. I don't see
anything here about lp_.
I forget what the issues is. Is it something like, if you are using a
normal MTU, pause is supported? But with jumbo MTU it is not?
For this to work correctly, i would expect a change of MTU to trigger
a new autoneg, with the local advertisement changed. That might
require changes in phylink, since it does not expect this sort of
thing.
> @@ -5288,6 +5326,8 @@ static void rtl_remove_one(struct pci_dev *pdev)
> r8169_remove_leds(tp->leds);
>
> unregister_netdev(tp->dev);
> + if (tp->phylink)
> + phylink_destroy(tp->phylink);
I've not looked in detail, but is tp->phylink optional? I would expect
the probe to fail if it could not create it.
> +static int rtl_mac_enable_tx_lpi(struct phylink_config *config, u32 timer, bool tx_clk_stop)
> +{
> + struct rtl8169_private *tp = container_of(config, struct rtl8169_private, phylink_config);
> +
> + if (!rtl_supports_eee(tp))
> + return -EOPNOTSUPP;
Can that happen? You should only be telling phylink EEE is supported
if EEE is actually supported.
> +static int rtl_init_phylink(struct rtl8169_private *tp)
> +{
> + struct phylink *pl;
> + phy_interface_t phy_mode;
> +
> + tp->phylink_config.dev = &tp->dev->dev;
> + tp->phylink_config.type = PHYLINK_NETDEV;
> + tp->phylink_config.mac_managed_pm = true;
> + tp->phylink_config.lpi_capabilities = rtl8169_get_lpi_caps(tp);
> + tp->phylink_config.mac_capabilities |= MAC_ASYM_PAUSE | MAC_SYM_PAUSE;
> +
> + if (tp->sfp_mode) {
> + phy_mode = PHY_INTERFACE_MODE_INTERNAL;
> + tp->phylink_config.mac_capabilities |= MAC_10000FD;
Only 10G? Is it not possible to slow down to 1G for a 1G SFP?
Andrew
^ permalink raw reply
* Re: [PATCH net-next v4 3/3] net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio hook
From: Carlo Szelinsky @ 2026-07-03 21:06 UTC (permalink / raw)
To: Paolo Abeni
Cc: Oleksij Rempel, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, David S . Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, Corey Leavitt, Jonas Jelonek, netdev, linux-kernel,
Carlo Szelinsky
In-Reply-To: <20260703071025.100797-1-pabeni@redhat.com>
Hi Paolo,
Thanks, I traced this and I think the review is right.
A phy that has been device_del()'d but is still pinned (an attached
netdev holds a get_device() from phy_attach_direct()) is off the
mdio_bus_type klist, so the PSE_UNREGISTERED walk (bus_for_each_dev)
does not see it and phy_pse_detach_one() never clears its phydev->psec.
When it is finally released, after pse_release_pis() has already freed
pcdev->pi, __pse_control_release() reads pcdev->pi[] and pcdev->owner
-> use-after-free. So the commit message is wrong for the off-klist
case: bus_for_each_dev() only defers the release for phys it can still
reach.
A few questions so I fix it the right way:
1. The trigger I can see is unbinding the MDIO bus while a netdev still
has the phy attached (mdiobus_unregister -> phy_device_remove ->
device_del, and the phy stays alive on the netdev's reference), and
then the PSE controller unbinds. Is that the path you have in mind,
or is there an easier one I am missing?
2. On keeping pse_control_put() in phy_device_remove(): wouldn't that
bring back the reason it was moved out? phy_device_remove() and the
walk's phy_pse_detach_one() would both touch phydev->psec, and
serializing them means taking rtnl in phy_device_remove() - which
the sfp caller already holds, so it would deadlock. Did you mean a
plain put there, or something narrower?
3. Simon raised the same psec-vs-pcdev lifetime on the net regulator
patch [1] and suggested either draining the references on unregister
or having pse_control hold a refcount on pcdev. This series does the
drain, which (as you show) misses off-klist phys. Would having
pse_control pin pcdev; so pcdev->pi and pcdev->owner cannot be
freed while any pse_control is still out... be the direction you
prefer? That makes the deferred put safe no matter what the klist
walk sees.
I'll send a v5 once the direction is clear.
Thanks,
Carlo
[1] https://lore.kernel.org/netdev/20260624151251.1137250-1-horms@kernel.org/
^ permalink raw reply
* Re: [PATCH net] net/tls: Consume empty data records in tls_sw_read_sock()
From: Chuck Lever @ 2026-07-03 21:07 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: john.fastabend, Jakub Kicinski, davem, edumazet, Paolo Abeni,
Simon Horman, netdev
In-Reply-To: <akbdFcQP7oTp_n3s@krikkit>
On Thu, Jul 2, 2026, at 5:50 PM, Sabrina Dubroca wrote:
> 2026-07-02, 15:52:49 -0400, Chuck Lever wrote:
>> On Thu, Jul 2, 2026, at 2:05 PM, Sabrina Dubroca wrote:
>> > Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
>> >
>> > I think tls_sw_splice_read() suffers from a similar issue (returning 0
>> > even though more data may be available). Sashiko agrees, and also
>> > found a few more pre-existing issues.
>>
>> Do you want a v2 series with those issues addressed?
>
> I'd be ok with this patch going in on its own, and the other issues
> being addressed separately. If you have time to look into those,
> that'd be great.
While I'm waiting for this patch to matriculate from net
into net-next (as it is a pre-requisite for supporting
TLS Alerts for in-kernel TLS consumers), I've started
looking at the Sashiko findings. I might drop finding #3
because it doesn't seem to be easily reachable in the
current code base. The other two seem straightforward.
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: realtek: rtl8366rb: Switch to generic port_bridge* handlers
From: Linus Walleij @ 2026-07-03 21:17 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <CAJq09z77GUn+wksbHNjHpPsrLLgU_yqo7V=M+XY-h1AKQE+WAQ@mail.gmail.com>
On Fri, Jul 3, 2026 at 3:24 PM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> > +static int rtl8366rb_port_set_isolation(struct realtek_priv *priv, int port,
> > + u32 mask)
> > +{
> > + /* Bit 0 enables isolation so set this if we enable isolation
> > + * any of the ports an clear it if we disable on all of them.
> > + */
> > + if (mask)
> > + mask = RTL8366RB_PORT_ISO_PORTS(mask) | RTL8366RB_PORT_ISO_EN;
> > +
> > + return regmap_write(priv->map, RTL8366RB_PORT_ISO(port),
> > + mask);
> > +}
>
> As sashiko pointed out, set_insolation(...,0) actually disables it
> instead of completely isolating it.
> I would unconditionally isolate the ports as we will never need to disable it.
Yeah, I'm working on a follow-up patch to fix this!
Thanks,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: embedded PTP timestamp support
From: Luke Howard @ 2026-07-03 21:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Richard Cochran,
Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <6cc25a97-3702-42d0-a667-11494bf5cbe6@lunn.ch>
> On 4 Jul 2026, at 1:13 am, Andrew Lunn <andrew@lunn.ch> wrote:
>
>> + /* Arrival Time Stamp Mode (ArrTSMode); see the ArrTSMode encoding in
>> + * hwtstamp.h. Zero (the default) leaves arrival time stamps in the
>> + * switch registers; non-zero embeds them in the frame, either appended
>> + * as a trailer or overwritten at that byte offset past the start of the
>> + * PTP common header.
>
> So how do you indicate trailer?
ArrTSMode being 1 (matches switch register interpretation).
Will remove (c).
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: use direct ATU hash on 88E6141/6341
From: Luke Howard @ 2026-07-03 21:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Cedric Jehasse,
Kieran Tyrrell, Max Holtmann, Max Hunter, Christoph Mellauner,
Simon Gapp, netdev, linux-kernel
In-Reply-To: <9eea72a5-b30d-4543-ac97-179743d99950@lunn.ch>
> On 4 Jul 2026, at 1:40 am, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Fri, Jul 03, 2026 at 04:42:56PM +1000, Luke Howard wrote:
>> The default 88E6341/88E6141 ATU hash algorithm appears to result
>> in frequent collisions, evicting permanent registrations (including
>> the broadcast address) out of the ATU.
>
> Is there any documentation about how the 88E6341/88E6141 hashing
> algorithm is different to all the other chips? How is it special?
No documentation, just my experience, which is why I asked in the cover for others to test. I can include test results with the next revision.
>> have a performance impact (the data sheet notes this is for testing
>> only), but it also enables correctness, at least in local testing.
>
> How do you define correctness? Are you using a well defined test?
>
> Why is the devlink parameter not sufficient.
Devlink would indeed be better, but changing hash mode with a non-empty ATU causes it to be corrupt on read back. Perhaps the right solution is to flus the ATU when changing hash mode via devlink.
Luke
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: write the ATU FID register on 88E6141/88E6341
From: Luke Howard @ 2026-07-03 21:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Cedric Jehasse,
Kieran Tyrrell, Max Holtmann, Max Hunter, Christoph Mellauner,
Simon Gapp, netdev, linux-kernel
In-Reply-To: <eadfade3-c46d-42fd-8301-3b2acebd7bcb@lunn.ch>
> On 4 Jul 2026, at 1:31 am, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Fri, Jul 03, 2026 at 04:42:55PM +1000, Luke Howard wrote:
>> The existing code assumed the 88E6141/88E6341 did not have a dedicated
>> ATU FID register because of its database count (256), instead taking
>> the legacy path which resulted in the FID register never being set.
>>
>> This resulted in every FDB entry being loaded into FID 0, breaking
>> VLAN aware bridging.
>>
>> Fixes: a75961d0ebfd ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341")
>
> Please submit fixes to the net tree.
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Will do.
>> @@ -131,6 +131,7 @@ struct mv88e6xxx_info {
>> u16 prod_num;
>> const char *name;
>> unsigned int num_databases;
>> + bool atu_fid_reg;
>> unsigned int num_macs;
>> unsigned int num_ports;
>> unsigned int num_internal_phys;
>
> Please think about padding. The current structure layout is not great,
> invalid_port_mask should be somewhere else, but please don't make it
> worse. Also, this structure has some reasonable comments. You have the
> chance to comment that the number of FIBs does not imply if there is a
> dedicated register, there are examples with 255 and a dedicated
> register.
Noted.
>
>> diff --git a/drivers/net/dsa/mv88e6xxx/global1_atu.c b/drivers/net/dsa/mv88e6xxx/global1_atu.c
>> index c47f068f56b32..aa5adc78607ca 100644
>> --- a/drivers/net/dsa/mv88e6xxx/global1_atu.c
>> +++ b/drivers/net/dsa/mv88e6xxx/global1_atu.c
>> @@ -135,7 +135,7 @@ static int mv88e6xxx_g1_atu_op(struct mv88e6xxx_chip *chip, u16 fid, u16 op)
>> int err;
>>
>> /* FID bits are dispatched all around gradually as more are supported */
>> - if (mv88e6xxx_num_databases(chip) > 256) {
>> + if (mv88e6xxx_num_databases(chip) > 256 || chip->info->atu_fid_reg) {
>
> So currently, > 256 implies a dedicated register. But do we need both
>> 255 and chip->info->atu_fid_reg? I would probably set atu_fid_reg
> true for all devices which have a dedicated register.
Noted.
Luke
^ permalink raw reply
* Re: [PATCH bpf-next v5 1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper
From: David Ahern @ 2026-07-03 21:34 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Avinash Duduskar, ast, daniel,
andrii
Cc: eddyz87, memxor, martin.lau, song, yonghong.song, jolsa, emil,
john.fastabend, sdf, davem, edumazet, kuba, pabeni, horms, shuah,
hawk, yatsenko, leon.hwang, kpsingh, a.s.protopopov, ameryhung,
rongtao, eyal.birger, bpf, netdev, linux-kernel, linux-kselftest
In-Reply-To: <87ik6x1m9n.fsf@toke.dk>
On 7/2/26 8:47 AM, Toke Høiland-Jørgensen wrote:
> David Ahern <dsahern@kernel.org> writes:
>
>> On 7/1/26 5:02 AM, Toke Høiland-Jørgensen wrote:
>>> David Ahern <dsahern@kernel.org> writes:
>>>> Seems to me the fib_lookup for xdp needs to return the bottom device,
>>>> not the vlan device, for forwarding to work. That's why I added the
>>>> fields to the struct. That allows the program to push the vlan header if
>>>> required. My preference (dream?) was that Tx path had support to tell
>>>> the redirect the vlan and h/w added it on send.
>>>
>>> Sure, returning the bottom device index with the VLAN tag makes sense,
>>> and that's basically what this series does (but bails out on stacked
>>> VLANs). However, that's not what the helper does today, which is why the
>>> flag is there, to opt-in to the new behaviour. I don't think we can just
>>> change the ifindex without breaking existing applications (as noted
>>> up-thread).
>>
>> I do not see it as breaking existing programs which is why I chimed in
>> on the thread.
>>
>>>
>>>> But really, once stacked devices come into play, I just wanted to make
>>>> sure thought is given to different use cases. As you know the lookup
>>>> struct if hard bound to 64B and it is trying to cover a lot of use cases.
>>>
>>> Agreed, I don't think we can handle stacked devices in this helper. But
>>> we could split it out into a new one. Something like:
>>>
>>> struct lower_device_info {
>>> enum device_type type;
>>> struct {
>>> __be16 h_vlan_proto;
>>> __be16 h_vlan_TCI;
>>> } vlan;
>>> /* add other types here */
>>> };
>>>
>>> int xdp_get_lower_device(int ifindex, struct lower_device_info *info);
>>>
>>> called like:
>>>
>>> int xdp_program(struct xdp_md *ctx)
>>> {
>>> struct lower_device_info dev_info = {};
>>> int ifindex, ret;
>>>
>>> ifindex = find_destination(ctx); /* does fib lookup, or something else */
>>>
>>> while ((ret = xdp_get_lower_device_info(ifindex, &dev_info)) > 0) {
>>> if (dev_info.type == VLAN) {
>>> push_vlan_tag(ctx, &dev_info.vlan);
>>> ifindex = ret;
>>> } else {
>>> return XDP_PASS; /* we only handle VLAN devices */
>>> }
>>> }
>>>
>>> return bpf_redirect(ifindex, 0);
>>> }
>>>
>>>
>>> With a helper like this, we obviously don't strictly speaking need to
>>> change the fib lookup helper at all. However, for the single-tagged VLAN
>>> case, I think supporting it directly in the fib lookup could still have
>>> value, as an optimisation: it saves an extra call for resolving the
>>> ifindex, and the fields are already there. So I think my preference
>>> would be to merge this series as-is, and then follow up with a new kfunc
>>> to handle the stacked case. But we could also just drop this series and
>>> go straight to the new kfunc.
>>>
>>> WDYT?
>>
>> no preference. I only chimed in because of the added flag to the uapi
>> which I do not see as needed. If the consensus is that it is in fact
>> needed, all good then.
>
> Alright, cool - care to provide an ACK, then? :)
>
Acked-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: use direct ATU hash on 88E6141/6341
From: Andrew Lunn @ 2026-07-03 21:43 UTC (permalink / raw)
To: Luke Howard
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Cedric Jehasse,
Kieran Tyrrell, Max Holtmann, Max Hunter, Christoph Mellauner,
Simon Gapp, netdev, linux-kernel
In-Reply-To: <81F61D3E-D9EB-4646-A401-9C34BAF0903D@padl.com>
> No documentation, just my experience, which is why I asked in the
> cover for others to test. I can include test results with the next
> revision.
Not so much the test results, but the test case.
The reason i added the devlink option was because the network
contained only devices from one vendor. So the OUI in the MAC
addresses was the same, the usable number of bits in the MAC address
being cut in half, in the best case. As a result, there was a lot of
hash collisions. For this special case network, the test mode hash was
better.
If you are also seeing a lot of collisions, it makes me wounder what
your distribution of MAC addresses is.
> >> have a performance impact (the data sheet notes this is for testing
> >> only), but it also enables correctness, at least in local testing.
> >
> > How do you define correctness? Are you using a well defined test?
> >
> > Why is the devlink parameter not sufficient.
>
> Devlink would indeed be better, but changing hash mode with a
> non-empty ATU causes it to be corrupt on read back. Perhaps the
> right solution is to flus the ATU when changing hash mode via
> devlink.
Flushing the ATU would make sense. It could well be in the system i
was working on, once it was shown to help, the EEPROM contents was set
to configure the ATU hash at hardware boot time, and devlink was not
used in production. The vendor had a bad habit of using the EEPROM.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: use direct ATU hash on 88E6141/6341
From: Luke Howard @ 2026-07-03 21:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Cedric Jehasse,
Kieran Tyrrell, Max Holtmann, Max Hunter, Christoph Mellauner,
Simon Gapp, netdev, linux-kernel
In-Reply-To: <8c2fd5d8-6b64-41d1-9dd4-bb1db687b844@lunn.ch>
> On 4 Jul 2026, at 7:43 am, Andrew Lunn <andrew@lunn.ch> wrote:
>
>> No documentation, just my experience, which is why I asked in the
>> cover for others to test. I can include test results with the next
>> revision.
>
> Not so much the test results, but the test case.
>
> The reason i added the devlink option was because the network
> contained only devices from one vendor. So the OUI in the MAC
> addresses was the same, the usable number of bits in the MAC address
> being cut in half, in the best case. As a result, there was a lot of
> hash collisions. For this special case network, the test mode hash was
> better.
>
> If you are also seeing a lot of collisions, it makes me wounder what
> your distribution of MAC addresses is.
Well, a bunch of unicast addresses along with MAAP for AVB.
But what triggered it was multiple FIDs (VLAN-aware bridge), which wouldn’t have been visible without the first patch to configure the ATU FID register correctly.
Luke
^ permalink raw reply
* Re: [PATCH v2 2/2] bonding: reuse neigh_setup from slave neigh_parms
From: Kuniyuki Iwashima @ 2026-07-04 1:43 UTC (permalink / raw)
To: Paritosh Potukuchi
Cc: netdev, linux-kernel, kuba, edumazet, andrew+netdev, jv, davem,
pabeni, paritosh.potukuchi
In-Reply-To: <20260703094735.678916-1-paritosh.potukuchi@amd.com>
On Fri, Jul 3, 2026 at 2:47 AM Paritosh Potukuchi
<paritoshpotukuchi@gmail.com> wrote:
>
> Hi Kuniyuki,
>
> >This introduces O(n) list traversal while it can be done
> >with fixed costs (3 dereferences + 1 call).
>
> >Since neigh_table is global (arp_tbl or nd_tbl), the O(n)
> >list traversal could take longer and rather de-optimise.
>
> Yes, that is true. One reason why I chose to do that is
> because ndo_neigh_setup is a function primarily meant
> to setup the neigh_parms structure, when neigh_parms does
> not exist.
> On the other hand, lookup_neigh_parms is meant
> to search for a near-complete neigh_parms structure,
> that is already associated with a netdev.
> Even if we want to use ndo_neigh_setup, since it takes
> less time, I would suggest using it as a fallback to
> not finding an already existing parms, setup.
>
> Moreover, time complexity might not be an issue in this
> path since, this is rarely used aggresively.
The real user is qeth_l3_main.c only and it's not compiled
on 99% host.
We usually bail out at if (!slave_ops->ndo_neigh_setup),
which is called after your neigh_parms_lookup_dev(), and
there is no need to do O(n) traversal.
With 2K netns, it could incur unnecessary 4K traversal (lo
+ another dev) for each neigh creation, which is done under
RTNL or from interrupt context.
So, it will be a problem.
>
>
> One issue with ndo_neigh_setup in bond-like devices is
> that, to get the underlying netdevs neigh_setup function,
> it expects us to pass a dummy neigh_parms structure that
> has been zeroed out. This seems to be fragile as suggested
> in a TODO in bond_neigh_init().
> Generally its main goal is to fill the parms.neigh_setup
> field.
>
> Can we populate a few more fields in the zeroed-
> out parms structure, before passing to the driver in
> ndo_neigh_setup? That seems to be a much safer approach.
It does not help. Just populating fields does not change the
loop detection logic.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] af_unix: Clean up error handling in unix_listen()
From: Kuniyuki Iwashima @ 2026-07-04 1:46 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
John Ericson, Simon Horman, Christian Brauner, David Rheinsberg,
Cong Wang, Sergei Zimmerman, netdev, linux-kernel
In-Reply-To: <20260703081416.2583118-3-John.Ericson@Obsidian.Systems>
On Fri, Jul 3, 2026 at 1:15 AM John Ericson
<John.Ericson@obsidian.systems> wrote:
>
> From: John Ericson <mail@johnericson.me>
>
> To avoid the sort of bug that was just fixed going forward, switch to a
> style where `err = -E...;` instead happens right before the `goto`.
> (`err = other_function(...);` is not changed.) Then there is no
> spooky-action-at-a-distance between the `err` initialization and the
> `goto`, something which is easier to slip by code review.
Sorry, I meant posting this separately to net-next.git after the
patch 1 is merged to net.git and lands net-next.git.
Also could you remove markdown `` ?
>
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: John Ericson <mail@johnericson.me>
> ---
> net/unix/af_unix.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 10ed9421e43a..7878b27bbaf8 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -813,19 +813,22 @@ static int unix_listen(struct socket *sock, int backlog)
> struct unix_sock *u = unix_sk(sk);
> struct unix_peercred peercred = {};
>
> - err = -EOPNOTSUPP;
> - if (sock->type != SOCK_STREAM && sock->type != SOCK_SEQPACKET)
> + if (sock->type != SOCK_STREAM && sock->type != SOCK_SEQPACKET) {
> + err = -EOPNOTSUPP;
> goto out; /* Only stream/seqpacket sockets accept */
> - err = -EINVAL;
> - if (!READ_ONCE(u->addr))
> + }
> + if (!READ_ONCE(u->addr)) {
> + err = -EINVAL;
> goto out; /* No listens on an unbound socket */
> + }
> err = prepare_peercred(&peercred);
> if (err)
> goto out;
> unix_state_lock(sk);
> - err = -EINVAL;
> - if (sk->sk_state != TCP_CLOSE && sk->sk_state != TCP_LISTEN)
> + if (sk->sk_state != TCP_CLOSE && sk->sk_state != TCP_LISTEN) {
> + err = -EINVAL;
> goto out_unlock;
> + }
> if (backlog > sk->sk_max_ack_backlog)
> wake_up_interruptible_all(&u->peer_wait);
> sk->sk_max_ack_backlog = backlog;
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH net v2 2/3] selftests/net/af_unix: test listen() rejects wrong socket states
From: Kuniyuki Iwashima @ 2026-07-04 1:54 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
John Ericson, Simon Horman, Christian Brauner, David Rheinsberg,
Cong Wang, Sergei Zimmerman, netdev, linux-kernel
In-Reply-To: <20260703081416.2583118-2-John.Ericson@Obsidian.Systems>
On Fri, Jul 3, 2026 at 1:15 AM John Ericson
<John.Ericson@obsidian.systems> wrote:
>
> From: John Ericson <mail@johnericson.me>
>
> Add a regression test for the `unix_listen()` state check. The key case
> is `listen()` on a bound socket that has already been connected: it is
> no longer in `TCP_CLOSE` or `TCP_LISTEN`, so it must fail with `EINVAL`.
> A `prepare_peercred()` call slipped in ahead of that check once left
> `err` at 0 and made `listen()` silently succeed there instead; this
> guards against a repeat.
>
> The neighbouring outcomes are covered too so they cannot regress the
> same way: a bound socket in `TCP_CLOSE` listens fine, re-`listen()`ing a
> socket already in `TCP_LISTEN` is allowed, and an unbound socket fails
> with `EINVAL`.
>
> Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: John Ericson <mail@johnericson.me>
> ---
> .../testing/selftests/net/af_unix/.gitignore | 1 +
> tools/testing/selftests/net/af_unix/Makefile | 1 +
> .../selftests/net/af_unix/unix_listen.c | 126 ++++++++++++++++++
> 3 files changed, 128 insertions(+)
> create mode 100644 tools/testing/selftests/net/af_unix/unix_listen.c
>
> diff --git a/tools/testing/selftests/net/af_unix/.gitignore b/tools/testing/selftests/net/af_unix/.gitignore
> index 240b26740c9e..973176644103 100644
> --- a/tools/testing/selftests/net/af_unix/.gitignore
> +++ b/tools/testing/selftests/net/af_unix/.gitignore
> @@ -6,3 +6,4 @@ scm_rights
> so_peek_off
> unix_connect
> unix_connreset
> +unix_listen
> diff --git a/tools/testing/selftests/net/af_unix/Makefile b/tools/testing/selftests/net/af_unix/Makefile
> index 4c0375e28bbe..57d159803a3a 100644
> --- a/tools/testing/selftests/net/af_unix/Makefile
> +++ b/tools/testing/selftests/net/af_unix/Makefile
> @@ -14,6 +14,7 @@ TEST_GEN_PROGS := \
> so_peek_off \
> unix_connect \
> unix_connreset \
> + unix_listen \
> # end of TEST_GEN_PROGS
>
> include ../../lib.mk
> diff --git a/tools/testing/selftests/net/af_unix/unix_listen.c b/tools/testing/selftests/net/af_unix/unix_listen.c
> new file mode 100644
> index 000000000000..7b5264c97f52
> --- /dev/null
> +++ b/tools/testing/selftests/net/af_unix/unix_listen.c
> @@ -0,0 +1,126 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Tests for the state checks in AF_UNIX listen().
> + *
> + * The central case is a regression test: listen() on a bound socket that
> + * is already connected (i.e. not in TCP_CLOSE or TCP_LISTEN state) must
> + * fail with EINVAL. A prior change accidentally let it return success
> + * without doing anything, because a helper called in between reset the
> + * error code to 0. The neighbouring checks (unbound, already listening)
> + * are tested too so they cannot silently regress the same way.
> + */
> +#define _GNU_SOURCE
> +
> +#include <errno.h>
> +#include <stddef.h>
> +#include <string.h>
> +#include <unistd.h>
> +
> +#include <sys/socket.h>
> +#include <sys/un.h>
> +
> +#include "kselftest_harness.h"
> +
> +/* Fill @addr with an abstract-namespace address named @name. */
> +static socklen_t unix_abstract(struct sockaddr_un *addr, const char *name)
> +{
> + size_t len = strlen(name);
> +
> + memset(addr, 0, sizeof(*addr));
> + addr->sun_family = AF_UNIX;
> + /* Leading NUL selects the abstract namespace (no filesystem entry). */
> + memcpy(addr->sun_path + 1, name, len);
> +
> + return offsetof(struct sockaddr_un, sun_path) + 1 + len;
> +}
> +
> +FIXTURE(unix_listen)
> +{
> + int sk; /* socket under test */
> + int server; /* a listening peer, when a test needs one */
> + struct sockaddr_un addr, srv_addr;
> + socklen_t addrlen, srv_addrlen;
> +};
Could you add test cases for SOCK_SEQPACKET and pathname
sockets ? so it will be 4-patterns. see unix_connect.c
> +
> +FIXTURE_SETUP(unix_listen)
> +{
> + self->sk = -1;
> + self->server = -1;
> + self->addrlen = unix_abstract(&self->addr, "unix_listen.sk");
> + self->srv_addrlen = unix_abstract(&self->srv_addr, "unix_listen.srv");
> +}
> +
> +FIXTURE_TEARDOWN(unix_listen)
> +{
> + if (self->sk >= 0)
> + close(self->sk);
> + if (self->server >= 0)
> + close(self->server);
> + /* Abstract addresses are released automatically on close. */
> +}
> +
> +/* A bound socket in TCP_CLOSE is the normal, allowed case. */
> +TEST_F(unix_listen, bound_is_ok)
> +{
> + self->sk = socket(AF_UNIX, SOCK_STREAM, 0);
> + ASSERT_LE(0, self->sk);
> + ASSERT_EQ(0, bind(self->sk, (struct sockaddr *)&self->addr,
> + self->addrlen));
Personally I think this style is more readable:
err = func(...)
ASSERT_XX(val, err)
> +
> + EXPECT_EQ(0, listen(self->sk, 8));
> +}
> +
> +/* Listening again on an already-listening socket (TCP_LISTEN) is allowed. */
> +TEST_F(unix_listen, relisten_is_ok)
> +{
> + self->sk = socket(AF_UNIX, SOCK_STREAM, 0);
> + ASSERT_LE(0, self->sk);
> + ASSERT_EQ(0, bind(self->sk, (struct sockaddr *)&self->addr,
> + self->addrlen));
> + ASSERT_EQ(0, listen(self->sk, 8));
> +
> + EXPECT_EQ(0, listen(self->sk, 16));
> +}
> +
> +/* listen() on an unbound socket fails: there is nothing to listen on. */
> +TEST_F(unix_listen, unbound_is_einval)
> +{
> + int ret;
> +
> + self->sk = socket(AF_UNIX, SOCK_STREAM, 0);
> + ASSERT_LE(0, self->sk);
> +
> + ret = listen(self->sk, 8);
> + EXPECT_EQ(-1, ret);
> + EXPECT_EQ(EINVAL, errno);
> +}
> +
> +/*
> + * The regression: a bound socket that has already been connected is not in
> + * TCP_CLOSE or TCP_LISTEN, so listen() must reject it with EINVAL rather
> + * than quietly succeeding.
> + */
> +TEST_F(unix_listen, connected_is_einval)
> +{
> + int ret;
> +
> + self->server = socket(AF_UNIX, SOCK_STREAM, 0);
> + ASSERT_LE(0, self->server);
> + ASSERT_EQ(0, bind(self->server, (struct sockaddr *)&self->srv_addr,
> + self->srv_addrlen));
> + ASSERT_EQ(0, listen(self->server, 8));
> +
> + self->sk = socket(AF_UNIX, SOCK_STREAM, 0);
> + ASSERT_LE(0, self->sk);
> + /* Bind first so the unbound check does not mask the state check. */
> + ASSERT_EQ(0, bind(self->sk, (struct sockaddr *)&self->addr,
> + self->addrlen));
> + ASSERT_EQ(0, connect(self->sk, (struct sockaddr *)&self->srv_addr,
> + self->srv_addrlen));
> +
> + ret = listen(self->sk, 8);
> + EXPECT_EQ(-1, ret);
> + EXPECT_EQ(EINVAL, errno);
> +}
> +
> +TEST_HARNESS_MAIN
> --
> 2.54.0
>
^ permalink raw reply
* [PATCHv2 net] net: emac: mal: fix W1C write race in ICINTSTAT clearing
From: Rosen Penev @ 2026-07-04 3:21 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jeff Garzik, David Gibson, open list
The ICINTSTAT register is write-1-to-clear (W1C). The read-modify-write
pattern in both mal_txeob() and mal_rxeob() can lose interrupts: if a bit
that should not be cleared is already asserted when mfdcri() reads the
register, it is included in the read value, retained by the bitwise OR, and
then written back as 1 - inadvertently clearing a pending but unhandled
interrupt.
Fix by writing only the specific bit to clear (ICINTSTAT_ICTX for TXEOB,
ICINTSTAT_ICRX for RXEOB). W1C semantics guarantee that writing 0 to the
other bits has no effect.
Tested on Cisco Meraki MX60. No issues seen.
Fixes: 1d3bb996481e ("Device tree aware EMAC driver")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: mention that this was tested.
drivers/net/ethernet/ibm/emac/mal.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/mal.c b/drivers/net/ethernet/ibm/emac/mal.c
index 74526002d52b..e88e4a1ddcd4 100644
--- a/drivers/net/ethernet/ibm/emac/mal.c
+++ b/drivers/net/ethernet/ibm/emac/mal.c
@@ -282,8 +282,7 @@ static irqreturn_t mal_txeob(int irq, void *dev_instance)
#ifdef CONFIG_PPC_DCR_NATIVE
if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
- mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
- (mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | ICINTSTAT_ICTX));
+ mtdcri(SDR0, DCRN_SDR_ICINTSTAT, ICINTSTAT_ICTX);
#endif
return IRQ_HANDLED;
@@ -302,8 +301,7 @@ static irqreturn_t mal_rxeob(int irq, void *dev_instance)
#ifdef CONFIG_PPC_DCR_NATIVE
if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
- mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
- (mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | ICINTSTAT_ICRX));
+ mtdcri(SDR0, DCRN_SDR_ICINTSTAT, ICINTSTAT_ICRX);
#endif
return IRQ_HANDLED;
--
2.55.0
^ permalink raw reply related
* [PATCHv2 net] net: emac: mal: replace devm_request_irq with request_irq to fix probe error race
From: Rosen Penev @ 2026-07-04 3:32 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rosen Penev, open list
devm_request_irq() is a managed resource: the IRQ is not freed until
devres_release_all() runs after the probe function returns. In the
probe error path, free_netdev(mal->dummy_dev) and dcr_unmap() execute
while the IRQ is still live. If the shared IRQ fires during cleanup,
the handler accesses unmapped DCR registers (crash) or the already-
freed dummy_dev (use-after-free).
Switch to plain request_irq() with per-IRQ error labels that tear down
only the IRQs that were successfully registered, and add the matching
free_irq() calls in mal_remove().
Tested on Cisco Meraki MX60
Fixes: 14f59154ff0b ("net: ibm: emac: mal: use devm for request_irq")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: rebase and add tested comment
drivers/net/ethernet/ibm/emac/mal.c | 43 +++++++++++++++++++----------
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/mal.c b/drivers/net/ethernet/ibm/emac/mal.c
index e88e4a1ddcd4..b42ba53671fd 100644
--- a/drivers/net/ethernet/ibm/emac/mal.c
+++ b/drivers/net/ethernet/ibm/emac/mal.c
@@ -656,26 +656,26 @@ static int mal_probe(struct platform_device *ofdev)
hdlr_rxde = mal_rxde;
}
- err = devm_request_irq(&ofdev->dev, mal->serr_irq, hdlr_serr, irqflags,
- "MAL SERR", mal);
+ err = request_irq(mal->serr_irq, hdlr_serr, irqflags,
+ "MAL SERR", mal);
if (err)
goto fail2;
- err = devm_request_irq(&ofdev->dev, mal->txde_irq, hdlr_txde, irqflags,
- "MAL TX DE", mal);
+ err = request_irq(mal->txde_irq, hdlr_txde, irqflags,
+ "MAL TX DE", mal);
if (err)
- goto fail2;
- err = devm_request_irq(&ofdev->dev, mal->txeob_irq, mal_txeob, 0,
- "MAL TX EOB", mal);
+ goto fail_serr_irq;
+ err = request_irq(mal->txeob_irq, mal_txeob, 0,
+ "MAL TX EOB", mal);
if (err)
- goto fail2;
- err = devm_request_irq(&ofdev->dev, mal->rxde_irq, hdlr_rxde, irqflags,
- "MAL RX DE", mal);
+ goto fail_txde_irq;
+ err = request_irq(mal->rxde_irq, hdlr_rxde, irqflags,
+ "MAL RX DE", mal);
if (err)
- goto fail2;
- err = devm_request_irq(&ofdev->dev, mal->rxeob_irq, mal_rxeob, 0,
- "MAL RX EOB", mal);
+ goto fail_txeob_irq;
+ err = request_irq(mal->rxeob_irq, mal_rxeob, 0,
+ "MAL RX EOB", mal);
if (err)
- goto fail2;
+ goto fail_rxde_irq;
/* Enable all MAL SERR interrupt sources */
set_mal_dcrn(mal, MAL_IER, MAL_IER_EVENTS);
@@ -694,6 +694,14 @@ static int mal_probe(struct platform_device *ofdev)
return 0;
+ fail_rxde_irq:
+ free_irq(mal->rxde_irq, mal);
+ fail_txeob_irq:
+ free_irq(mal->txeob_irq, mal);
+ fail_txde_irq:
+ free_irq(mal->txde_irq, mal);
+ fail_serr_irq:
+ free_irq(mal->serr_irq, mal);
fail2:
dma_free_coherent(&ofdev->dev, bd_size, mal->bd_virt, mal->bd_dma);
fail_dummy:
@@ -720,6 +728,13 @@ static void mal_remove(struct platform_device *ofdev)
mal_reset(mal);
+ /* Free IRQs before freeing resources they access */
+ free_irq(mal->serr_irq, mal);
+ free_irq(mal->txde_irq, mal);
+ free_irq(mal->txeob_irq, mal);
+ free_irq(mal->rxde_irq, mal);
+ free_irq(mal->rxeob_irq, mal);
+
free_netdev(mal->dummy_dev);
dcr_unmap(mal->dcr_host, 0x100);
--
2.55.0
^ permalink raw reply related
* [PATCH net] sctp: validate STALE_COOKIE cause length before reading staleness
From: Weiming Shi @ 2026-07-04 3:35 UTC (permalink / raw)
To: linux-sctp
Cc: Marcelo Ricardo Leitner, Xin Long, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Xiang Mei, Weiming Shi,
stable
When an ERROR chunk with a STALE_COOKIE cause is received in the
COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure
of Staleness that follows the cause header:
err = (struct sctp_errhdr *)(chunk->skb->data);
stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));
err is the first cause in the chunk, not the STALE_COOKIE cause that
caused the dispatch, and nothing guarantees the staleness field is
present. sctp_walk_errors() only requires a cause to be as long as the
4-byte header, so for a STALE_COOKIE cause of length 4 the read runs
past the cause, and for a minimal ERROR chunk past skb->tail. The value
is echoed to the peer in the Cookie Preservative of the reply INIT,
leaking uninitialized memory.
sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so
check its length there and pass it to sctp_sf_do_5_2_6_stale(), which
reads that cause instead of the first one. A STALE_COOKIE cause too
short to hold the staleness field is discarded.
The read is reachable by any peer that can drive an association into
COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket
in a user and network namespace.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Cc: stable@vger.kernel.org
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/sctp/sm_statefuns.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index d23d935e128e..3893b44448b3 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -74,7 +74,8 @@ static enum sctp_disposition sctp_sf_do_5_2_6_stale(
const struct sctp_association *asoc,
const union sctp_subtype type,
void *arg,
- struct sctp_cmd_seq *commands);
+ struct sctp_cmd_seq *commands,
+ struct sctp_errhdr *err);
static enum sctp_disposition sctp_sf_shut_8_4_5(
struct net *net,
const struct sctp_endpoint *ep,
@@ -2529,9 +2530,15 @@ enum sctp_disposition sctp_sf_cookie_echoed_err(
* errors.
*/
sctp_walk_errors(err, chunk->chunk_hdr) {
- if (SCTP_ERROR_STALE_COOKIE == err->cause)
- return sctp_sf_do_5_2_6_stale(net, ep, asoc, type,
- arg, commands);
+ if (err->cause != SCTP_ERROR_STALE_COOKIE)
+ continue;
+ /* The staleness is only meaningful if the cause is long
+ * enough to hold it; a shorter one is malformed.
+ */
+ if (ntohs(err->length) < sizeof(*err) + sizeof(__be32))
+ break;
+ return sctp_sf_do_5_2_6_stale(net, ep, asoc, type,
+ arg, commands, err);
}
/* It is possible to have malformed error causes, and that
@@ -2573,13 +2580,13 @@ static enum sctp_disposition sctp_sf_do_5_2_6_stale(
const struct sctp_association *asoc,
const union sctp_subtype type,
void *arg,
- struct sctp_cmd_seq *commands)
+ struct sctp_cmd_seq *commands,
+ struct sctp_errhdr *err)
{
int attempts = asoc->init_err_counter + 1;
- struct sctp_chunk *chunk = arg, *reply;
struct sctp_cookie_preserve_param bht;
struct sctp_bind_addr *bp;
- struct sctp_errhdr *err;
+ struct sctp_chunk *reply;
u32 stale;
if (attempts > asoc->max_init_attempts) {
@@ -2590,8 +2597,6 @@ static enum sctp_disposition sctp_sf_do_5_2_6_stale(
return SCTP_DISPOSITION_DELETE_TCB;
}
- err = (struct sctp_errhdr *)(chunk->skb->data);
-
/* When calculating the time extension, an implementation
* SHOULD use the RTT information measured based on the
* previous COOKIE ECHO / ERROR exchange, and should add no
--
2.43.0
^ permalink raw reply related
* [PATCH net-next] devlink: Replace strlcat() with seq_buf
From: Ian Bridges @ 2026-07-04 3:49 UTC (permalink / raw)
To: Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: netdev, linux-kernel, linux-hardening
In preparation for removing the strlcat() API[1], replace its uses in
__devlink_compat_running_version().
The function accumulates a variable number of version strings into a
fixed buffer, which is what seq_buf is for. The seq_buf is anchored at
the end of any existing string in the buffer and each version string
is appended with a single seq_buf_printf(). The output is unchanged,
including under truncation.
Link: https://github.com/KSPP/linux/issues/370 [1]
Signed-off-by: Ian Bridges <icb@fastmail.org>
---
The patch was tested as follows, on top of net-next:
- x86_64 allmodconfig and allyesconfig builds of net/devlink/dev.o at
W=1 produce no warnings.
- A userspace comparison of the old and new construction ran with
randomized version lists and buffer contents across all buffer
fill levels. The outputs are byte-identical in every case,
including on overflow.
- The changed path was exercised in a QEMU guest through the ethtool
GDRVINFO ioctl against a netdevsim device, before and after the
change, with identical fw_version output.
net/devlink/dev.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/devlink/dev.c b/net/devlink/dev.c
index 57b2b8f03543..0d4301267171 100644
--- a/net/devlink/dev.c
+++ b/net/devlink/dev.c
@@ -5,6 +5,7 @@
*/
#include <linux/device.h>
+#include <linux/seq_buf.h>
#include <net/genetlink.h>
#include <net/sock.h>
#include "devl_internal.h"
@@ -1188,8 +1189,10 @@ static void __devlink_compat_running_version(struct devlink *devlink,
char *buf, size_t len)
{
struct devlink_info_req req = {};
+ size_t used = strnlen(buf, len);
const struct nlattr *nlattr;
struct sk_buff *msg;
+ struct seq_buf sb;
int rem, err;
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
@@ -1201,6 +1204,8 @@ static void __devlink_compat_running_version(struct devlink *devlink,
if (err)
goto free_msg;
+ seq_buf_init(&sb, buf + used, len - used);
+
nla_for_each_attr_type(nlattr, DEVLINK_ATTR_INFO_VERSION_RUNNING,
(void *)msg->data, msg->len, rem) {
const struct nlattr *kv;
@@ -1208,8 +1213,8 @@ static void __devlink_compat_running_version(struct devlink *devlink,
nla_for_each_nested_type(kv, DEVLINK_ATTR_INFO_VERSION_VALUE,
nlattr, rem_kv) {
- strlcat(buf, nla_data(kv), len);
- strlcat(buf, " ", len);
+ seq_buf_printf(&sb, "%s ",
+ (const char *)nla_data(kv));
}
}
free_msg:
--
2.47.3
^ permalink raw reply related
* [syzbot] Monthly wireless report (Jul 2026)
From: syzbot @ 2026-07-04 4:32 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev, syzkaller-bugs
Hello wireless maintainers/developers,
This is a 31-day syzbot report for the wireless subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/wireless
During the period, 3 new issues were detected and 0 were fixed.
In total, 30 issues are still open and 178 have already been fixed.
There are also 17 low-priority issues.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 6964 Yes WARNING in __cfg80211_ibss_joined (2)
https://syzkaller.appspot.com/bug?extid=7f064ba1704c2466e36d
<2> 1243 Yes INFO: task hung in reg_process_self_managed_hints
https://syzkaller.appspot.com/bug?extid=1f16507d9ec05f64210a
<3> 327 Yes INFO: task hung in ath9k_hif_usb_firmware_cb (3)
https://syzkaller.appspot.com/bug?extid=e9b1ff41aa6a7ebf9640
<4> 65 Yes WARNING in cfg80211_scan_done
https://syzkaller.appspot.com/bug?extid=189dcafc06865d38178d
<5> 42 Yes WARNING: ODEBUG bug in ieee80211_led_exit (2)
https://syzkaller.appspot.com/bug?extid=e84ecca6d1fa09a9b3d9
<6> 1032 Yes INFO: task hung in reg_check_chans_work (7)
https://syzkaller.appspot.com/bug?extid=a2de4763f84f61499210
<7> 204 Yes WARNING in ieee80211_free_ack_frame (2)
https://syzkaller.appspot.com/bug?extid=ac648b0525be1feba506
<8> 44 Yes possible deadlock in zd_chip_disable_rxtx
https://syzkaller.appspot.com/bug?extid=0ec3d1a6cf1fbe79c153
<9> 21 Yes WARNING in mac80211_hwsim_tx (2)
https://syzkaller.appspot.com/bug?extid=435fdb053cf98bfa5778
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* [syzbot] [wireless?] [usb?] WARNING in __carl9170_tx_process_status
From: syzbot @ 2026-07-04 5:46 UTC (permalink / raw)
To: chunkeey, linux-kernel, linux-usb, linux-wireless, netdev,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: dc59e4fea9d8 Linux 7.2-rc1
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=1792f9fe580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6ec4d592e55f7960
dashboard link: https://syzkaller.appspot.com/bug?extid=381102a7292a374fe8a7
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1125c289580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17049e89580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/8540695a33d7/disk-dc59e4fe.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e144bb9cdc33/vmlinux-dc59e4fe.xz
kernel image: https://storage.googleapis.com/syzbot-assets/6e3051bf9301/bzImage-dc59e4fe.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+381102a7292a374fe8a7@syzkaller.appspotmail.com
------------[ cut here ]------------
__lockdep_enabled && !this_cpu_read(hardirqs_enabled)
WARNING: kernel/softirq.c:430 at __local_bh_enable_ip+0xbd/0x120 kernel/softirq.c:430, CPU#0: swapper/0/0
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(lazy)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026
RIP: 0010:__local_bh_enable_ip+0xbd/0x120 kernel/softirq.c:430
Code: 00 e8 a7 d1 0b 00 e8 62 10 45 00 fb 65 8b 05 7a c3 86 0b 85 c0 74 50 5b 5d c3 cc cc cc cc 65 8b 05 04 03 87 0b 85 c0 75 a0 90 <0f> 0b 90 eb 9a e8 59 12 45 00 eb 9b 48 89 ef e8 0f 0b 19 00 eb a4
RSP: 0018:ffffc90000007aa8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000201 RCX: 1ffffffff15e7114
RDX: 0000000000000001 RSI: 0000000000000201 RDI: ffffffff8446537b
RBP: ffffffff8446537b R08: 0000000000000000 R09: ffffed1023c03a8b
R10: ffff88811e01d45b R11: 0000000000000000 R12: ffff88811c516705
R13: dffffc0000000000 R14: ffff88811e01b220 R15: ffff88811e01d440
FS: 0000000000000000(0000) GS:ffff888268640000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdd9de6dc4 CR3: 00000001197ae000 CR4: 00000000003506f0
Call Trace:
<IRQ>
spin_unlock_bh include/linux/spinlock.h:396 [inline]
carl9170_get_queued_skb drivers/net/wireless/ath/carl9170/tx.c:531 [inline]
__carl9170_tx_process_status+0x13b/0x620 drivers/net/wireless/ath/carl9170/tx.c:668
carl9170_tx_process_status+0xf6/0x230 drivers/net/wireless/ath/carl9170/tx.c:701
carl9170_handle_command_response+0x3c8/0xc50 drivers/net/wireless/ath/carl9170/rx.c:219
carl9170_usb_rx_irq_complete+0xfc/0x1b0 drivers/net/wireless/ath/carl9170/usb.c:307
__usb_hcd_giveback_urb+0x38d/0x610 drivers/usb/core/hcd.c:1657
usb_hcd_giveback_urb+0x3ca/0x4a0 drivers/usb/core/hcd.c:1741
dummy_timer+0xda1/0x36c0 drivers/usb/gadget/udc/dummy_hcd.c:2005
__run_hrtimer kernel/time/hrtimer.c:2032 [inline]
__hrtimer_run_queues+0x462/0x9c0 kernel/time/hrtimer.c:2096
hrtimer_run_softirq+0x17d/0x2c0 kernel/time/hrtimer.c:2113
handle_softirqs+0x1dd/0x990 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x160/0x210 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1062
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
RIP: 0010:pv_native_safe_halt+0xf/0x20 arch/x86/kernel/paravirt.c:64
Code: 90 ac 01 c3 cc cc cc cc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 03 8f 0b 00 fb f4 <e9> 3c f6 02 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90
RSP: 0018:ffffffff89407e20 EFLAGS: 00000242
RAX: 0000000000096967 RBX: ffffffff8942c8c0 RCX: ffffffff877af8e5
RDX: 0000000000000000 RSI: ffffffff890edf5a RDI: ffffffff87b15200
RBP: fffffbfff1285918 R08: 0000000000000001 R09: ffffed103eac670d
R10: ffff8881f563386b R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 1ffffffff1280fc8 R15: dffffc0000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:62 [inline]
default_idle+0x9/0x10 arch/x86/kernel/process.c:768
default_idle_call+0x6c/0xb0 kernel/sched/idle.c:122
cpuidle_idle_call kernel/sched/idle.c:199 [inline]
do_idle+0x3a7/0x5b0 kernel/sched/idle.c:355
cpu_startup_entry+0x4f/0x60 kernel/sched/idle.c:454
rest_init+0x251/0x260 init/main.c:717
start_kernel+0x489/0x490 init/main.c:1175
x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
x86_64_start_kernel+0x12b/0x130 arch/x86/kernel/head64.c:291
common_startup_64+0x13e/0x158
</TASK>
----------------
Code disassembly (best guess):
0: 90 nop
1: ac lods %ds:(%rsi),%al
2: 01 c3 add %eax,%ebx
4: cc int3
5: cc int3
6: cc int3
7: cc int3
8: 0f 1f 00 nopl (%rax)
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
10: 90 nop
11: 90 nop
12: 90 nop
13: 90 nop
14: 90 nop
15: 90 nop
16: 90 nop
17: 90 nop
18: 90 nop
19: 90 nop
1a: 90 nop
1b: f3 0f 1e fa endbr64
1f: 66 90 xchg %ax,%ax
21: 0f 00 2d 03 8f 0b 00 verw 0xb8f03(%rip) # 0xb8f2b
28: fb sti
29: f4 hlt
* 2a: e9 3c f6 02 00 jmp 0x2f66b <-- trapping instruction
2f: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
36: 00 00 00
39: 66 90 xchg %ax,%ax
3b: 90 nop
3c: 90 nop
3d: 90 nop
3e: 90 nop
3f: 90 nop
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ 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