All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Machata <petrm@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Petr Machata <petrm@nvidia.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, <netdev@vger.kernel.org>,
	Simon Horman <horms@kernel.org>, Ido Schimmel <idosch@nvidia.com>,
	Amit Cohen <amcohen@nvidia.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Andy Roulin <aroulin@nvidia.com>, <mlxsw@nvidia.com>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Shuah Khan <shuah@kernel.org>,
	Benjamin Poirier <bpoirier@nvidia.com>,
	Hangbin Liu <liuhangbin@gmail.com>,
	<linux-kselftest@vger.kernel.org>, Jiri Pirko <jiri@resnulli.us>
Subject: Re: [PATCH net-next v3 7/7] selftests: net: fdb_notify: Add a test for FDB notifications
Date: Wed, 13 Nov 2024 12:46:10 +0100	[thread overview]
Message-ID: <875xorjq37.fsf@nvidia.com> (raw)
In-Reply-To: <20241112142234.7abf2232@kernel.org>


Jakub Kicinski <kuba@kernel.org> writes:

> On Mon, 11 Nov 2024 18:09:01 +0100 Petr Machata wrote:
>> Check that only one notification is produced for various FDB edit
>> operations.
>> 
>> Regarding the ip_link_add() and ip_link_master() helpers. This pattern of
>> action plus corresponding defer is bound to come up often, and a dedicated
>> vocabulary to capture it will be handy. tunnel_create() and vlan_create()
>> from forwarding/lib.sh are somewhat opaque and perhaps too kitchen-sinky,
>> so I tried to go in the opposite direction with these ones, and wrapped
>> only the bare minimum to schedule a corresponding cleanup.
>
> Looks like it fails about half of the time :(
>
> https://netdev.bots.linux.dev/flakes.html?min-flip=0&tn-needle=fdb-notify&br-cnt=200

OK, I can't reproduce this. Trying in VM, on an actual HW, debug, no
debug, no luck. But I see basically two failures:

- A "0 seen, 1 expected", which... I don't know, maybe it could just be
  a misplaced sleep. I don't see how, but it's a deterministing
  scenario, there shouldn't be anything racy here, either it emits or it
  doesn't, so some buffering issue is the only thing I can think of.

- Deadlocks. E.g. this, which looks like it deadlocked and timed out
  ("bad unlock balance detected" followed by "blocked for more than 122
  seconds" et.al.):

    https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/846621/18-fdb-notify-sh/

  Like... how could this patchset even theoretically cause a deadlock?

  reply	other threads:[~2024-11-13 12:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-11 17:08 [PATCH net-next v3 0/7] net: ndo_fdb_add/del: Have drivers report whether they notified Petr Machata
2024-11-11 17:08 ` [PATCH net-next v3 1/7] ndo_fdb_add: Add a parameter to report whether notification was sent Petr Machata
2024-11-11 17:08   ` [Intel-wired-lan] " Petr Machata
2024-11-12 13:56   ` Nikolay Aleksandrov
2024-11-12 13:56     ` [Intel-wired-lan] " Nikolay Aleksandrov
2024-11-11 17:08 ` [PATCH net-next v3 2/7] ndo_fdb_del: " Petr Machata
2024-11-11 17:08   ` [Intel-wired-lan] " Petr Machata
2024-11-12 13:56   ` Nikolay Aleksandrov
2024-11-12 13:56     ` [Intel-wired-lan] " Nikolay Aleksandrov
2024-11-11 17:08 ` [PATCH net-next v3 3/7] selftests: net: lib: Move logging from forwarding/lib.sh here Petr Machata
2024-11-11 17:08 ` [PATCH net-next v3 4/7] selftests: net: lib: Move tests_run " Petr Machata
2024-11-11 17:08 ` [PATCH net-next v3 5/7] selftests: net: lib: Move checks " Petr Machata
2024-11-11 17:09 ` [PATCH net-next v3 6/7] selftests: net: lib: Add kill_process Petr Machata
2024-11-11 17:09 ` [PATCH net-next v3 7/7] selftests: net: fdb_notify: Add a test for FDB notifications Petr Machata
2024-11-12 22:22   ` Jakub Kicinski
2024-11-13 11:46     ` Petr Machata [this message]
2024-11-13 15:11       ` Petr Machata
2024-11-14  1:08         ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875xorjq37.fsf@nvidia.com \
    --to=petrm@nvidia.com \
    --cc=amcohen@nvidia.com \
    --cc=aroulin@nvidia.com \
    --cc=bpoirier@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.