You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
64 lines
2.5 KiB
64 lines
2.5 KiB
xfs_repair: fix progress reporting |
|
|
|
RHEL7 note: this is a simplified version of the upstream patch. |
|
|
|
The Fixes: commit tried to avoid a segfault in case the progress timer |
|
went off before the first message type had been set up, but this |
|
had the net effect of short-circuiting the pthread start routine, |
|
and so the timer didn't get set up at all and we lost all fine-grained |
|
progress reporting. |
|
|
|
The initial problem occurred when log zeroing took more time than the |
|
timer interval. |
|
|
|
[RHEL7: we do not explicitly track log zeroing, and instead lump it into |
|
Phase 2, so the next part of the description is not relevant to this |
|
patch.] |
|
|
|
So, make a new log zeroing progress item and initialize it when we first |
|
set up the timer thread, to be sure that if the timer goes off while we |
|
are still zeroing the log, it will be initialized and correct. |
|
|
|
(We can't offer fine-grained status on log zeroing, so it'll go from |
|
zero to $LOGBLOCKS with nothing in between, but it's unlikely that log |
|
zeroing will take so long that this really matters.) |
|
|
|
Reported-by: Leonardo Vaz <lvaz@redhat.com> |
|
Fixes: 7f2d6b811755 ("xfs_repair: avoid segfault if reporting progre...") |
|
Signed-off-by: Eric Sandeen <sandeen@redhat.com> |
|
--- |
|
|
|
It might be nice to add progress reporting for the log zeroing, but that |
|
requires renumbering all these macros, and we don't/can't actually get |
|
any fine-grained progress at all, so probably not worth it. |
|
|
|
Index: xfsprogs-4.5.0/repair/progress.c |
|
=================================================================== |
|
--- xfsprogs-4.5.0.orig/repair/progress.c |
|
+++ xfsprogs-4.5.0/repair/progress.c |
|
@@ -124,7 +124,13 @@ init_progress_rpt (void) |
|
*/ |
|
|
|
pthread_mutex_init(&global_msgs.mutex, NULL); |
|
- global_msgs.format = NULL; |
|
+ /* |
|
+ * Ensure the format string is not NULL in case the first timer |
|
+ * goes off before any stage calls set_progress_msg() to set it. |
|
+ * Choosing PROG_FMT_SCAN_AG lumps log zeroing in with the AG scan |
|
+ * but that is not expected to take inordinately long. |
|
+ */ |
|
+ global_msgs.format = &progress_rpt_reports[PROG_FMT_SCAN_AG]; |
|
global_msgs.count = glob_agcount; |
|
global_msgs.interval = report_interval; |
|
global_msgs.done = prog_rpt_done; |
|
@@ -170,10 +176,6 @@ progress_rpt_thread (void *p) |
|
msg_block_t *msgp = (msg_block_t *)p; |
|
__uint64_t percent; |
|
|
|
- /* It's possible to get here very early w/ no progress msg set */ |
|
- if (!msgp->format) |
|
- return NULL; |
|
- |
|
if ((msgbuf = (char *)malloc(DURATION_BUF_SIZE)) == NULL) |
|
do_error (_("progress_rpt: cannot malloc progress msg buffer\n")); |
|
|
|
|