]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs_repair: avoid segfault if reporting progress early in repair
authorEric Sandeen <sandeen@redhat.com>
Thu, 17 Oct 2013 17:50:16 +0000 (17:50 +0000)
committerRich Johnston <rjohnston@sgi.com>
Thu, 17 Oct 2013 20:38:05 +0000 (15:38 -0500)
commit7f2d6b811755b6b91f18aa5bd9d5980848a81267
treecd67a308c24addecd038195d950b61367817f239
parent5b962abcbb952e5409e2b2a1ecbc71b5d370cdea
xfs_repair: avoid segfault if reporting progress early in repair

For a very large filesystem, zeroing the log may take some time.

If we ask for progress reports frequently enough that one fires
before we finish with log zeroing, we try to use a progress format
which has not yet been set up, and segfault:

# mkfs.xfs -d size=60t,file,name=fsfile
# xfs_repair -m 9000 -o ag_stride=32 -t 1 fsfile
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 1 seconds
Phase 2 - using internal log
        - zero log...
Segmentation fault

(gdb) bt
#0  0x0000000000426962 in progress_rpt_thread (p=0x67ad20) at progress.c:234
#1  0x0000003b98a07851 in start_thread (arg=0x7f19d8e47700) at pthread_create.c:301
#2  0x0000003b982e767d in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) p msgp
$1 = (msg_block_t *) 0x67ad20
(gdb) p msgp->format
$2 = (progress_rpt_t *) 0x0
(gdb)

I suppose we could rig up progress reports for log zeroing, but
that won't usually take terribly long; for now, be defensive
and init the message->format to NULL, and just return early
from the progress thread if we've not yet set up any message.

(Sure, global_msgs is global, and ->format is already NULL,
but to me it's worth being explicit since we will test it).

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
repair/progress.c