Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1718734 > unrolled thread

[PATCH v2] scsi: lpfc: avoid false positive gcc-8 warning

Back to article view | Back to linux.kernel

Contents

  [PATCH v2] scsi: lpfc: avoid false positive gcc-8 warning James Smart <jsmart2021@gmail.com> - 2017-08-24 02:40 +0200
    Re: [PATCH v2] scsi: lpfc: avoid false positive gcc-8 warning Arnd Bergmann <arnd@arndb.de> - 2017-08-24 13:10 +0200
      Re: [PATCH v2] scsi: lpfc: avoid false positive gcc-8 warning James Smart <jsmart2021@gmail.com> - 2017-08-24 18:30 +0200

#1718734 — [PATCH v2] scsi: lpfc: avoid false positive gcc-8 warning

Arnd Bergmann, testing gcc-8, encountered the following:

> This is an interesting regression with gcc-8, showing a harmless
> warning for correct code:
>
>In file included from include/linux/kernel.h:13:0,
>    ...
>    from drivers/scsi/lpfc/lpfc_debugfs.c:23:
>    include/linux/printk.h:301:2: error: 'eq' may be used
>    uninitialized in this function [-Werror=maybe-uninitialized]
>       printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>       ^~~~~~
>    In file included from drivers/scsi/lpfc/lpfc_debugfs.c:58:0:
>    drivers/scsi/lpfc/lpfc_debugfs.h:451:31: note: 'eq' was
>    declared here

The code is fine: a for loop which if there's at least 1 itteration,
will assign eq a value. Followed by an if test that checks for no
itterations and assigns eq a default value. But the checker doesn't
see the relationship between the two so assumes eq may not a have a
value.

I believe, simply initializing with a NULL will solve the issue.

Signed-off-by: James Smart <james.smart@broadcom.com>
---
 drivers/scsi/lpfc/lpfc_debugfs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_debugfs.h b/drivers/scsi/lpfc/lpfc_debugfs.h
index 7b7d314af0e0..32e86d7813a0 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.h
+++ b/drivers/scsi/lpfc/lpfc_debugfs.h
@@ -448,7 +448,7 @@ lpfc_debug_dump_wq(struct lpfc_hba *phba, int qtype, int wqidx)
 static inline void
 lpfc_debug_dump_cq(struct lpfc_hba *phba, int qtype, int wqidx)
 {
-	struct lpfc_queue *wq, *cq, *eq;
+	struct lpfc_queue *wq, *cq, *eq = NULL;
 	char *qtypestr;
 	int eqidx;
 
-- 
2.13.1

[toc] | [next] | [standalone]

#1719160

On Thu, Aug 24, 2017 at 2:34 AM, James Smart <jsmart2021@gmail.com> wrote:
> Arnd Bergmann, testing gcc-8, encountered the following:
>
>> This is an interesting regression with gcc-8, showing a harmless
>> warning for correct code:
>>
>>In file included from include/linux/kernel.h:13:0,
>>    ...
>>    from drivers/scsi/lpfc/lpfc_debugfs.c:23:
>>    include/linux/printk.h:301:2: error: 'eq' may be used
>>    uninitialized in this function [-Werror=maybe-uninitialized]
>>       printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>>       ^~~~~~
>>    In file included from drivers/scsi/lpfc/lpfc_debugfs.c:58:0:
>>    drivers/scsi/lpfc/lpfc_debugfs.h:451:31: note: 'eq' was
>>    declared here
>
> The code is fine: a for loop which if there's at least 1 itteration,
> will assign eq a value. Followed by an if test that checks for no
> itterations and assigns eq a default value. But the checker doesn't
> see the relationship between the two so assumes eq may not a have a
> value.
>
> I believe, simply initializing with a NULL will solve the issue.
>
> Signed-off-by: James Smart <james.smart@broadcom.com>

That's probably good enough here, as the warning is rather obscure
(only one instance in the entire kernel in 1000 randconfig builds),
with an unreleased compiler.

Anyway, I have successfully reduced a test case and reported
a gcc bug for it, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81958

The compiler test case is

__attribute__ ((__cold__)) int printk();
struct lpfc_queue {
        int queue_id;
        struct lpfc_queue *hba_eq;
} *cq_phba;
void lpfc_debug_dump_all_queues(unsigned maxidx)
{
        struct lpfc_queue *eq;
        unsigned eqidx;
        printk();
        for (eqidx = 0; eqidx < maxidx; eqidx++) {
                eq = &cq_phba->hba_eq[eqidx];
                if (eq->queue_id)
                        break;
        }
        if (eqidx == maxidx)
                eq = &cq_phba->hba_eq[0];
        printk(eq);
}

and I see no reason why the compiler should get this wrong.

I have also come up with a different workaround of my own
(sorry for the broken formatting here) and tested it successfully
over night. I have definitely spent more time on it than it was
worth now. Let me know if you prefer that version over yours,
then I'll submit that as a proper patch with your Ack.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

--- a/drivers/scsi/lpfc/lpfc_debugfs.h
+++ b/drivers/scsi/lpfc/lpfc_debugfs.h
@@ -450,7 +450,7 @@ lpfc_debug_dump_cq(struct lpfc_hba *phba, int
qtype, int wqidx)
 {
        struct lpfc_queue *wq, *cq, *eq;
        char *qtypestr;
-       unsigned int eqidx;
+       int eqidx;

        /* fcp/nvme wq and cq are 1:1, thus same indexes */

@@ -478,16 +478,16 @@ lpfc_debug_dump_cq(struct lpfc_hba *phba, int
qtype, int wqidx)
                return;

        for (eqidx = 0; eqidx < phba->io_channel_irqs; eqidx++) {
-               eq = phba->sli4_hba.hba_eq[eqidx];
-               if (cq->assoc_qid == eq->queue_id)
+               if (cq->assoc_qid == phba->sli4_hba.hba_eq[eqidx]->queue_id)
                        break;
        }
        if (eqidx == phba->io_channel_irqs) {
                pr_err("Couldn't find EQ for CQ. Using EQ[0]\n");
                eqidx = 0;
-               eq = phba->sli4_hba.hba_eq[0];
        }

+       eq = phba->sli4_hba.hba_eq[eqidx];
+
        if (qtype == DUMP_FCP || qtype == DUMP_NVME)
                pr_err("%s CQ: WQ[Idx:%d|Qid%d]->CQ[Idx%d|Qid%d]"
                        "->EQ[Idx:%d|Qid:%d]:\n",


     Arnd

[toc] | [prev] | [next] | [standalone]

#1719397

On 8/24/2017 4:01 AM, Arnd Bergmann wrote:
> 
> I have also come up with a different workaround of my own
> (sorry for the broken formatting here) and tested it successfully
> over night. I have definitely spent more time on it than it was
> worth now. Let me know if you prefer that version over yours,
> then I'll submit that as a proper patch with your Ack.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> --- a/drivers/scsi/lpfc/lpfc_debugfs.h

I'm ok with either solution. I prefer less change but this is a trivial 
thing.

Signed-off-by: James Smart <james.smart@broadcom.com>

-- james

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web