Bug 1250035 - xfs_logprint -c coredumps
xfs_logprint -c coredumps
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xfsprogs (Show other bugs)
7.1
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Eric Sandeen
Filesystem QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 07:57 EDT by Pavel Moravec
Modified: 2017-11-22 01:22 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
abrt report with the coredump (38.64 KB, application/x-xz)
2015-08-04 07:58 EDT, Pavel Moravec
no flags Details
compressed copy of the log (936.06 KB, application/x-bzip)
2015-08-04 13:43 EDT, Eric Sandeen
no flags Details

  None (edit)
Description Pavel Moravec 2015-08-04 07:57:39 EDT
Description of problem:
Having quite fresh installation of RHEL7.1, "xfs_logprint -c /dev/mapper/rhel-root" coredumps. Running it without "-c" does not coredump.

Running the same command on other RHEL7 machines, no coredump seen.

Attaching abrt report and to provide access to the reproducer machine.


Version-Release number of selected component (if applicable):
xfsprogs-3.2.1-6.el7.x86_64


How reproducible:
??? (100% on the machine I have)


Steps to Reproduce:
1. ???
2. xfs_logprint -c /dev/mapper/rhel-root


Actual results:
xfs_logprint coredumps


Expected results:
No coredump


Additional info:
Comment 1 Pavel Moravec 2015-08-04 07:58:00 EDT
Created attachment 1059053 [details]
abrt report with the coredump
Comment 3 Eric Sandeen 2015-08-04 13:34:09 EDT
Asking logprint to parse the log on a still-mounted filesystem is fairly unusual, though we still shouldn't coredump.  I'm curious, what prompted you to point xfs_logprint at the mounted root filesystem?

-Eric
Comment 4 Eric Sandeen 2015-08-04 13:37:33 EDT
Note, the first thing logprint says is:

# xfs_logprint -c /dev/mapper/rhel-root
xfs_logprint: /dev/mapper/rhel-root contains a mounted and writable filesystem
...

I'm a little surprised we even proceed after that.
Comment 5 Eric Sandeen 2015-08-04 13:43:35 EDT
Created attachment 1059193 [details]
compressed copy of the log

xfs_logprint -c -f logfile seems to fail in the same way, for this copy of the log.
Comment 6 Pavel Moravec 2015-08-05 07:08:52 EDT
(In reply to Eric Sandeen from comment #3)
> Asking logprint to parse the log on a still-mounted filesystem is fairly
> unusual, though we still shouldn't coredump.  I'm curious, what prompted you
> to point xfs_logprint at the mounted root filesystem?
> 
> -Eric

sosreport :) See /usr/lib/python2.7/site-packages/sos/plugins/xfs.py, when enabling logprint option.

The easiest way of reproducing it via sosreport:

sosreport -o xfs -e xfs -a --batch -v
..
[plugin:xfs] collecting output of 'xfs_logprint -c /dev/mapper/rhel-root'
[plugin:xfs] collecting output of 'xfs_logprint -c /dev/vda1'
..

(-a means enabling all plugin options).


I don't know how often / meaningful / useful this option is, though.
Comment 7 Eric Sandeen 2015-08-05 11:54:31 EDT
Yeah, that's not a useful thing for sosreport to do.... Any idea why it was added?
Comment 8 Eric Sandeen 2015-08-05 15:33:09 EDT
So, while I'll look at logprint, I think this highlights a more important issue - we need to make the xfs plugin collect useful information.  Logprint is almost never going to be relevant, especially when the fs is mounted.  It's also going to produce potentially very large files.  I'd drop it from sos.

xfs-specific information which *would* be useful is things like:

* xfsprogs version (xfs_repair -V) (I suppose we have this already from rpm data?)
* xfs_info output for all filesystems
* xfs mount options (probably gathered already?)
* xfs_stats output /proc/fs/xfs/stat & /proc/fs/xfs/xqmstat

-Eric
Comment 9 Pavel Moravec 2015-08-10 03:26:25 EDT
(In reply to Eric Sandeen from comment #8)
> So, while I'll look at logprint, I think this highlights a more important
> issue - we need to make the xfs plugin collect useful information.  Logprint
> is almost never going to be relevant, especially when the fs is mounted. 
> It's also going to produce potentially very large files.  I'd drop it from
> sos.
> 
> xfs-specific information which *would* be useful is things like:
> 
> * xfsprogs version (xfs_repair -V) (I suppose we have this already from rpm
> data?)
> * xfs_info output for all filesystems
> * xfs mount options (probably gathered already?)
> * xfs_stats output /proc/fs/xfs/stat & /proc/fs/xfs/xqmstat
> 
> -Eric

Makes sense, I raised https://github.com/sosreport/sos/issues/621 and will propose a patch for sosreport, once the discussion there will settle down the desired final state. Thanks for input.
Comment 11 Eric Sandeen 2016-06-27 17:59:45 EDT
In logprint we do this, around line 754 of log_print.c:

            *ptr += be32_to_cpu(op_head->oh_len);
            if (op_head->oh_flags & XLOG_CONTINUE_TRANS)
                return 1;
            op_head = (xlog_op_header_t *)*ptr;

and in this case, oh_len seems invalid; with debugging:

op_head->oh_flags 0x0 oh_len 0x34000000

so we move the op_head pointer to invalid memory.  I'm not sure offhand what sanity testing we can put on that value in this case...

Note You need to log in before you can comment on or make changes to this bug.