• James Smart's avatar
    nvmet-fc: slight cleanup for kbuild test warnings · e4fcc72c
    James Smart authored
    The kbuild tst robot flagged the following 3 issues:
    
    Case 1)
    >> drivers/nvme/target/fc.c:1201:37: warning: Either the condition
    >> '!assoc' is redundant or there is possible null pointer dereference:
    >> assoc. [nullPointerRedundantCheck]
    >>  struct nvmet_fc_tgtport *tgtport = assoc->tgtport;
                                           ^
    >> drivers/nvme/target/fc.c:1853:7: note: Assuming that condition '!assoc'
    >> is not redundant
    >>   if (!assoc)
             ^
    >> drivers/nvme/target/fc.c:1850:37: note: Assignment
    >> 'assoc=nvmet_fc_find_target_assoc(tgtport,be64_to_cpu(
    >>              rqst->associd.association_id))', assigned value is 0
    >>   assoc = nvmet_fc_find_target_assoc(tgtport,
                                           ^
    >> drivers/nvme/target/fc.c:1896:31: note: Calling function
    >> 'nvmet_fc_delete_target_assoc', 1st argument 'assoc' value is 0
    >>  nvmet_fc_delete_target_assoc(assoc);
                                     ^
    
    The tool isn't smart enough to see that line 1854 sets a ret value which
    thereafter causes the routine to exit. This occurs before any of the assoc
    references, so it is not an issue. There are 2 more reportings of this
    same failure.
    
    To quiet the tool - rework the if test that does the exit to also
    reference assoc.  No change in logic otherwise.
    
    Case 2)
    drivers/nvme/target/fc.c:1202:29: warning: The scope of the variable
    'queue' can be reduced. [variableScope]
        struct nvmet_fc_tgt_queue *queue;
                                   ^
    
    The tool is requesting the variable be declared within the code block
    that utilizes it. Ignoring this report as existing code style is fine.
    
    Case 3)
    drivers/nvme/target/fc.c:1137:16: warning: Variable 'needrandom' is
    assigned a value that is never used. [unreadVariable]
           needrandom = true;
                      ^
    
    Another parsing issue with the tool. Given that parens were not used
    with the list_for_each_entry() check, it inadvertantly thinks the
    break exited the outer while loop not the inner for loop.
    
    This is not an error. But, added parens to the inner list_for_each_entry()
    to quiet the tool and as it is better coding style.
    
    -- james
    Signed-off-by: default avatarJames Smart <jsmart2021@gmail.com>
    Reported-by: default avatarkbuild test robot <lkp@intel.com>
    CC: kbuild test robot <lkp@intel.com>
    CC: Christoph Hellwig <hch@lst.de>
    Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    e4fcc72c
fc.c 78.7 KB