Re: [PATCH] target: pscsi: avoid Wempty-body warning

[Matthew Wilcox]

On Mon, Mar 22, 2021 at 12:44:34PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@xxxxxxxx>
> 
> Building with 'make W=1' shows a harmless warning for pscsi:
> 
> drivers/target/target_core_pscsi.c: In function 'pscsi_complete_cmd':
> drivers/target/target_core_pscsi.c:624:33: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
>   624 |                                 ; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */
>       |                                 ^
> 
> Rework the coding style as suggested by gcc to avoid the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> ---
>  drivers/target/target_core_pscsi.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
> index 3cbc074992bc..913b092955f6 100644
> --- a/drivers/target/target_core_pscsi.c
> +++ b/drivers/target/target_core_pscsi.c
> @@ -620,8 +620,9 @@ static void pscsi_complete_cmd(struct se_cmd *cmd, u8 scsi_status,
>  			unsigned char *buf;
>  
>  			buf = transport_kmap_data_sg(cmd);
> -			if (!buf)
> -				; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */
> +			if (!buf) {
> +				/* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */
> +			}

But why not just delete the code?

			buf = transport_kmap_data_sg(cmd);
			/* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */

I mean, this seems like a real warning here.  We're not actually
handling the failure to allocate 'buf'.  It's not marked as __must_check,
but watch the code flow:

                        buf = transport_kmap_data_sg(cmd);
                        if (!buf)
                                ; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */

                        if (cdb[0] == MODE_SENSE_10) {
                                if (!(buf[3] & 0x80))
                                        buf[3] |= 0x80;
                        } else {
                                if (!(buf[2] & 0x80))
                                        buf[2] |= 0x80;
                        }

we're about to do a NULL ptr dereference.  So this should be handled
somehow.