All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Ivan Vecera <ivecera@redhat.com>
Cc: netdev@vger.kernel.org,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Milena Olech <milena.olech@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Michal Michalik <michal.michalik@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 2/2] dpll: report dumps interrupted by topology changes
Date: Tue, 10 Nov 2026 14:02:41 -0800	[thread overview]
Message-ID: <20261110140241.422a981a@kernel.org> (raw)
In-Reply-To: <20261105131145.1010406-3-ivecera@redhat.com>

On Thu,  5 Nov 2026 14:11:45 +0100 Ivan Vecera wrote:
> Pin and device dumps release dpll_lock between parts and resume from the
> id saved by the previous part. An object registered in between is missed
> if its id is below that one, as is the case for an object allocated
> before the dump started. User space gets an incomplete dump and has no
> way to tell.

This is not really a problem, just something AI loves to complain about.
IMO dumps must be correct only wrt unmodified objects. If we have
objects A B C, and A and C either get registered or removed during the
dump - whether they appear in the dump does not matter. Only B must
appear. If the IDs are from Xarray they are usually stable, the problems
with dump consistency mostly come when dumping a list or a hash table.

Please repost with a better commit msg if there's some list / hash table
here that I'm not spotting. I'll take patch 1 as is.

  parent reply	other threads:[~2026-11-10 22:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 13:11 [PATCH net 0/2] dpll: fix a false notification and report interrupted dumps Ivan Vecera
2026-11-05 13:11 ` [PATCH net 1/2] dpll: notify about a reference sync pair only if it was added Ivan Vecera
2026-11-05 22:14   ` Vadim Fedorenko
2026-11-10 15:25   ` Petr Oros
2026-11-05 13:11 ` [PATCH net 2/2] dpll: report dumps interrupted by topology changes Ivan Vecera
2026-11-10 15:25   ` Petr Oros
2026-11-10 22:02   ` Jakub Kicinski [this message]
2026-11-11 11:08     ` Ivan Vecera
2026-11-10 22:10 ` [PATCH net 0/2] dpll: fix a false notification and report interrupted dumps patchwork-bot+netdevbpf

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=20261110140241.422a981a@kernel.org \
    --to=kuba@kernel.org \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=davem@davemloft.net \
    --cc=ivecera@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.michalik@intel.com \
    --cc=milena.olech@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=vadim.fedorenko@linux.dev \
    /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.