lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHS8izOSq+mYmP58eNqC5WFTvXxh+s8gRSrTv6YQdq6jn41pMw@mail.gmail.com>
Date: Thu, 4 Sep 2025 12:50:42 -0700
From: Mina Almasry <almasrymina@...gle.com>
To: Stanislav Fomichev <sdf@...ichev.me>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, andrew+netdev@...n.ch, shuah@...nel.org, 
	joe@...a.to, linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] selftests: ncdevmem: don't retry EFAULT

On Thu, Sep 4, 2025 at 11:27 AM Stanislav Fomichev <sdf@...ichev.me> wrote:
>
> devmem test fails on NIPA. Most likely we get skb(s) with readable
> frags (why?)

I would expect if we get readable frags that the frags land in the
host buffer we provide ncdevmem and we actually hit this error:

```
  1                 if (!is_devmem) {
  0                         pr_err("flow steering error");
  1                         goto err_close_client;
  2                 }
```

which as it says, should be root caused in a flow steering error. I
don't know what would cause an EFAULT off the top of my head.

> but the failure manifests as an OOM. The OOM happens
> because ncdevmem spams the following message:
>
>   recvmsg ret=-1
>   recvmsg: Bad address
>
> As of today, ncdevmem can't deal with various reasons of EFAULT:
> - falling back to regular recvmsg for non-devmem skbs
> - increasing ctrl_data size (can't happen with ncdevmem's large buffer)
>
> Exit (cleanly) with error when recvmsg returns EFAULT. This should at
> least cause the test to cleanup its state.
>
> Signed-off-by: Stanislav Fomichev <sdf@...ichev.me>

Either way, change looks good to me.

Reviewed-by: Mina Almasry <almasrymina@...gle.com>

-- 
Thanks,
Mina

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ