netdev - Re: [PATCH net v2 4/4] selftests: drv-net: rss_ctx: test RSS contexts persist after ifdown/up

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: <20260211083132.15b15870@kernel.org>
Date: Wed, 11 Feb 2026 08:31:32 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Pavan Chebbi <pavan.chebbi@...adcom.com>
Cc: Bobby Eshleman <bobbyeshleman@...il.com>, Michael Chan
 <michael.chan@...adcom.com>, "David S . Miller" <davem@...emloft.net>,
 Linux Netdev List <netdev@...r.kernel.org>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Andrew Lunn
 <andrew+netdev@...n.ch>, Andrew Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net v2 4/4] selftests: drv-net: rss_ctx: test RSS
 contexts persist after ifdown/up

On Wed, 11 Feb 2026 13:29:06 +0530 Pavan Chebbi wrote:
> > > If you check the carrier manually in a second terminal while it's
> > > running -- do you see it go to 1? The helper keeps the file open  
> >
> > Thanks for the nudge. I think I get the real issue now. It's not the
> > cmd() but ifup.exec()
> > I am using :
> > ifup = defer(ip, f"link set dev {cfg.ifname} up")
> > and later
> > ifup.exec()
> >
> > I see that exec() takes unusually long time for carrier to go to 1.
> > Upto 20s and sometimes still fails.
> > Same with both direct exec or deferred. And this explains why I cannot
> > ping for long time after suite exists. Thats because I rely on defer()
> > to bring the interface up after bnxt exits with carrier 0 for the
> > second test.
> > If replace the exec with direct call to ip(f"link set dev {cfg.ifname}
> > up") I see it works reliably.
> 
> My experiments are pointing to 'self.cancel()' sometimes taking a lot
> of time as part of the exec().
> I don't know but I feel the new test code itself should be OK. I can
> send a v3 and you can run it once too?

Could you reply to this thread with what the version of the patch where
you see defer() takes a long time? We use defer all over the place..