Re: [PATCH 4/4] scripts/qemugdb: coroutine: Add option for obtaining detailed trace in coredump

[Kevin Wolf <kwolf@redhat.com>]

Am 28.11.2025 um 13:24 hat Andrey Drobyshev geschrieben:
> On 11/27/25 6:39 PM, Kevin Wolf wrote:
> > Am 27.11.2025 um 15:31 hat Andrey Drobyshev geschrieben:
> >> As for reflink copy, this might've been a great solution.  However, it
> >> would largely depend on the FS used.  E.g. in my system coredumpctl
> >> places uncompressed coredump at /var/tmp, which is mounted as ext4.  And
> >> in this case:
> >>
> >> # cp --reflink /var/tmp/coredump-MQCZQc /root
> >> cp: failed to clone '/root/coredump-MQCZQc' from
> >> '/var/tmp/coredump-MQCZQc': Invalid cross-device link
> >>
> >> # cp --reflink /var/tmp/coredump-MQCZQc /var/tmp/coredump.ref
> >> cp: failed to clone '/var/tmp/coredump.ref' from
> >> '/var/tmp/coredump-MQCZQc': Operation not supported
> >>
> >> Apparently, ext4 doesn't support reflink copy. xfs and btrfs do.  But I
> >> guess our implementation better be FS-agnostic.
> > 
> > Yes, we might still need a slow copy fallback for those filesystems,
> > i.e. essentially a 'cp --reflink=auto'. For myself, coredumps will
> > generally live on XFS, so I would benefit from creating that copy in the
> > same filesystem where the coredump lives, and for you it shouldn't hurt
> > at least.
> > 
> > Another thought... it's a bit crazy, but... we're QEMU, we have our own
> > tools for this. We could create a qcow2 overlay for the coredump and
> > export it using FUSE! :-D (Probably not very practical because you need
> > the right paths for the binaries, but I had to mention it.)
> > 
> > Kevin
> 
> We can surely add reflink copying as a fast path option which we try
> first.  That's cheap to implement.  The real issue is designing a
> sensible fallback approach.

I mean, as far as I am concerned, you can keep what you already have as
the fallback approach. Reflink copy if possible, and otherwise a slow
full copy.

Or if the coredump can be written to, you could do the in-place editing,
though I would save the original content in a file that could survive a
crash. And after finishing the operation, the original content
definitely should be written back.

> As for creating an overlay... That's an interesting option but it would
> require everybody who wants to use this stuff configure their QEMU build
> with --enable-fuse.  We, for instance, don't have it enabled in our
> builds, as I'm sure many others.
> 
> Of course we can think of an NBD export for such an overlay instead of
> FUSE.  But it'll then require root user to write to /dev/nbd0.  Also not
> very acceptable.
> 
> Quick overlayfs mount with lowerdir=/var/tmp could also solve this.  But
> again, root is required.  Not good.
> 
> So the most robust option, I guess, is the one suggested by Daniel:
> copying some kind of minimal viable coredump part/range instead of the
> whole file, which is just enough for producing valid backtrace.  The
> only thing left is figuring out which part to copy.  That might require
> some tricky ELF structure parsing.

All of these solutions are interesting, but honestly feel a bit too
complex for a simple debugging script.

Kevin