On Tue, Dec 10, 2024 at 07:40:04AM -0500, Kent Overstreet wrote:

On Tue, Dec 10, 2024 at 11:27:19AM +0000, Mark Rutland wrote:

quoted

On Mon, Dec 09, 2024 at 11:37:12AM +0000, Mark Rutland wrote:

quoted

On Thu, Dec 05, 2024 at 01:04:59PM -0500, Kent Overstreet wrote:

quoted

Looking some more, I see that bch2_btree_transactions_read() is trying
to unwind other tasks, and I believe what's happening here is that the
unwindee isn't actually blocked for the duration of the unwind, leading
to the unwinder encountering junk and consequently producing the
warning.

As a test case, it's possible to trigger similar with a few parallel
instances of:

	while true; do cat /proc/*/stack > /dev/null

The only thing we can do on the arm64 side is remove the WARN_ON_ONCE(),
which'll get rid of the splat. It seems we've never been unlucky enough
to hit a stale fgraph entry, or that would've blown up also.

Regardless of the way arm64 behaves here, the unwind performed by
bch2_btree_transactions_read() is going to contain garbage unless the
task is pinned in a blocked state. AFAICT the way
btree_trans::locking_wait::task is used is here is racy, and there's no
guarantee that the unwindee is actually blocked.

Occasionally returning garbage is completely fine, as long as the
interface is otherwise safe. This is debug info; it's important that it
be available and we can't impose additional synchronization for it.

Sure thing; just note that there's no guarantee that this is only
"occasionally" garbage -- this could be wrong 1% of the time or 99% of
the time depending on the specific scenario, HW it's running on, etc. As
long as you're happy to hold the pieces when that happens, that's fine.

I've pushed out fixes to the arm64/stacktrace/fixes branch on my
kernel.org git repo:

  https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/stacktrace/fixes
  git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/stacktrace/fixes

... and I'll get that out as a series on the list tomorrow.

Mark.