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: <CALs4sv1GtqdhGLkcJC1RFbr_bi3n_Hk2A2qahhAg38hrcmRznQ@mail.gmail.com>
Date: Wed, 11 Feb 2026 22:08:39 +0530
From: Pavan Chebbi <pavan.chebbi@...adcom.com>
To: Jakub Kicinski <kuba@...nel.org>
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, Feb 11, 2026 at 10:01 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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..

Oh it is still in my sandbox. It's after I incorporate the comments I
received on the v2.
You should see it in v3. Let me ask Michael to send it.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5469 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ