netdev - Re: [PATCH net-next] selftests: ncdevmem: don't retry EFAULT

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: <aLtK0OIocbEIsNhI@mini-arch>
Date: Fri, 5 Sep 2025 13:40:48 -0700
From: Stanislav Fomichev <stfomichev@...il.com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Stanislav Fomichev <sdf@...ichev.me>, 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 09/05, Mina Almasry wrote:
> On Fri, Sep 5, 2025 at 8:22 AM Stanislav Fomichev <stfomichev@...il.com> wrote:
> >
> > On 09/04, Mina Almasry wrote:
> > > 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.
> >
> > Yea, I don't understand what happens :-( I'm thinking of doing the
> > following as well:
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index 40b774b4f587..0c18a8c7965f 100644
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@ -2820,7 +2820,7 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len,
> >                                                          used);
> >                                 if (err <= 0) {
> >                                         if (!copied)
> > -                                               copied = -EFAULT;
> > +                                               copied = err;
> >
> >                                         break;
> >                                 }
> >
> > Should give us more info for the devmem case... LMK if you don't like
> > it. If I don't hear from you in a couple of days, I'll send it out..
> 
> Hmm, the other code paths overwrite the error to EFAULT; I don't know
> if that's significant in some way. But seems fine to me, I don't see
> why not do this, other than maybe potentional confusion with recvmsg
> returning an error not documented here:
> 
> https://linux.die.net/man/2/recvmsg
> 
> But that seems a minor point.

SG! Exporting new errnos seems to be ok because we are dealing with a
new devmem mode? I think the bug we have on the fbnic is that we don't
properly set skb->unreadable, so it's completely unrelated to this,
but still feels like it might help with future debugging..