On 09/05, Mina Almasry wrote: > On Fri, Sep 5, 2025 at 8:22 AM Stanislav Fomichev <[email protected]> > wrote: > > > > On 09/04, Mina Almasry wrote: > > > On Thu, Sep 4, 2025 at 11:27 AM Stanislav Fomichev <[email protected]> > > > 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..
