------- Comment From fnovak.com 2016-08-12 09:20 EDT-------
reverse RH1366512 - lparstat segfault if 'SPU' line in /proc/interrupts is too long

------- Comment From allenjoh.com 2016-08-16 10:33 EDT-------
*** This bug has been marked as a duplicate of bug 144709 ***

Hello,

I don't think this bug is a duplicate of bug 144709 which is opened for the evolution-2.0.2-3. Could you please double check it?

Thanks.

------- Comment From allenjoh.com 2016-08-16 11:34 EDT-------
(In reply to comment #7)
> Hello,
>
> I don't think this bug is a duplicate of bug 144709 which is opened for the
> evolution-2.0.2-3. Could you please double check it?
>
> Thanks.

That's IBM bugzilla 144709. Didn't mean to mark the mirrored RH bug a a duplicate, sorry about that.

------- Comment From allenjoh.com 2016-08-16 11:36 EDT-------
*** This bug has been marked as a duplicate of bug 144709 ***

Hello Red Hat / Qi Guo,
... the patch currently being posted for this bugzilla is
https://groups.google.com/forum/#!topic/powerpc-utils-devel/mmqVVIzZ5Y4
("[PATCH] lparstat: Fix segfault when parsing /proc/interrupts")
... would it be possible that you give this patch a try
whether it will resolve this bugzilla ..?
Please advise ...
Thanks for your support.

Hello Hanns,

Thanks for bringing up the information. I copy the posted patch here from the google groups for discussion:

#####################
Signed-off-by: John Allen <jal....ibm.com>
---
diff --git a/src/lparstat.c b/src/lparstat.c
index ebe0d13..81ceb93 100644
--- a/src/lparstat.c
+++ b/src/lparstat.c
@@ -203,7 +203,8 @@ int parse_lparcfg()
 int parse_proc_ints()
 {
         FILE *f;
-        char line[512];
+        char *line = NULL;
+        size_t n = 0;
         char *value;
         struct sysentry *se;
         long long int phint = 0;
@@ -214,7 +215,7 @@ int parse_proc_ints()
                 return -1;
         }

-        while (fgets(line, 512, f) != NULL) {
+        while (getline(&line, &n, f) != -1) {
                 /* we just need the SPU line */
                 if (line[0] != 'S' || line[1] != 'P' || line[2] != 'U') <<<---- HERE
                         continue;
@@ -224,8 +225,11 @@ int parse_proc_ints()
                         v = atoi(value);
                         phint += v;
                 }
+
+                break;
         }

+        free(line);
         fclose(f);

         se = get_sysentry("phint"); 

#####################

Is it possible that the first character of 'SPU:' line is not 'S'? Given the code in the kernel, the 'prec' can be greater than 3:

int arch_show_interrupts(struct seq_file *p, int prec)
{
...
        seq_printf(p, "%*s: ", prec, "SPU");
        for_each_online_cpu(j)
                seq_printf(p, "%10u ", per_cpu(irq_stat, j).spurious_irqs);
        seq_printf(p, "  Spurious interrupts\n");
...
}

int show_interrupts(struct seq_file *p, void *v)
{
        static int prec;

        unsigned long flags, any_count = 0;
        int i = *(loff_t *) v, j;
        struct irqaction *action;
        struct irq_desc *desc;

        if (i > ACTUAL_NR_IRQS)
                return 0;

        if (i == ACTUAL_NR_IRQS)
                return arch_show_interrupts(p, prec);

        /* print header and calculate the width of the first column */
        if (i == 0) {
                for (prec = 3, j = 1000; prec < 10 && j <= nr_irqs; ++prec)
                        j *= 10;

                seq_printf(p, "%*s", prec + 8, "");
                for_each_online_cpu(j)
                        seq_printf(p, "CPU%-8d", j);
                seq_putc(p, '\n');
        }
...
}

Please kindly share your thoughts. Thanks.

Regards,
Flos

------- Comment From hannsj_uhl.com 2016-08-17 13:59 EDT-------
Comment from  John Allen 2016-08-17 13:18:51 EDT

(In reply to comment #11)
> Is it possible that the first character of 'SPU:' line is not 'S'? Given the
> code in the kernel, the 'prec' can be greater than 3:

Ah yes, good catch. If any interrupt numbers exceed 3 characters, whitespace will be added to the beginning of the line to keep the columns aligned. I will submit a follow up patch that ignores any whitespace at the beginning of the line.

*** Bug 1367695 has been marked as a duplicate of this bug. ***

------- Comment From hannsj_uhl.com 2016-08-24 05:04 EDT-------
fyi ... an updated patch is now upstream posted at
and upstream accepted as git commit
https://github.com/nfont/powerpc-utils/commit/3c3a53825248e1ef52ee203c968f643c26820cc5
("lparstat: Fix segfault when parsing /proc/interrupts")
.
... please give it a try as soon as possibe whether it will fix this bugzilla ...
... thanks in advance ...

Hi Hanns,

Seems the possible leading white space issue is not fixed in this patch. Any other bug is created for it? Thanks.

Regards,
Flos

------- Comment From allenjoh.com 2016-08-24 10:15 EDT-------
Patch for the whitespace issue will be submitted soon--planning on submitting that this afternoon. There currently isn't another bug open to track that issue. I was planning on tracking that fix in this bug, but if it would be preferred, another bug can be opened to track the whitespace issue.

------- Comment From hannsj_uhl.com 2016-08-27 12:09 EDT-------
(In reply to comment #19)
> Patch for the whitespace issue will be submitted soon--planning on
> submitting that this afternoon. ...
... which is now accepted upstream as git commit
https://github.com/nfont/powerpc-utils/commit/b071e81d8cd71af496d5c5b36371c30449051def
("lparstat: Ignore whitespace at beginning of /proc/interrupts SPU line")

Hello Rafael,
... please include the two patches from comment #10 and comment #13 in RHEL7.3 ...
Thanks in advance for your support.

IBM,

unfortunately our QA is out of capacity. However, if you'd be willing to test this, we can still include the patches in RHEL-7.3.

(In reply to Rafael Fonseca from comment #16)
> IBM,
> 
> unfortunately our QA is out of capacity. However, if you'd be willing to
> test this, we can still include the patches in RHEL-7.3.
.
fyi ... IBM will do fix verification ... setting OtherQA ...

fyi ... verified with RHEL7.3 Snapshot 4 ... closing ...

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2389.html