linux-kernel - Re: [PATCH 3/3] message: fusion: Fix line over 80 characters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1800e18130f7f768128feea2755f2c6ea0af7241.camel@perches.com>
Date:   Sun, 03 Jun 2018 13:03:03 -0700
From:   Joe Perches <joe@...ches.com>
To:     Varsha Rao <rvarsha016@...il.com>
Cc:     Sathya Prakash <sathya.prakash@...adcom.com>,
        Chaitra P B <chaitra.basappa@...adcom.com>,
        Suganath Prabu Subramani 
        <suganath-prabu.subramani@...adcom.com>,
        MPT-FusionLinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org, Nicholas Mc Guire <der.herr@...r.at>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: Re: [PATCH 3/3] message: fusion: Fix line over 80 characters

On Sun, 2018-06-03 at 18:52 +0530, Varsha Rao wrote:
> Line over 80 characters is split to fix the following checkpatch issue:
> 
> WARNING: line over 80 characters
[]
> diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
[]
> @@ -5690,7 +5690,8 @@ mpt_inactive_raid_volumes(MPT_ADAPTER *ioc, u8 channel, u8 id)
>  		    buffer->PhysDisk[i].PhysDiskNum, &phys_disk) != 0)
>  			continue;
>  
> -		if (!(component_info = kmalloc(sizeof(*component_info), GFP_KERNEL)))
> +		if (!(component_info = kmalloc(sizeof(*component_info),
> +		      GFP_KERNEL)))
>  			continue;

It's much more common to split this into multiple statements like

		component_info = kmalloc(sizeof(*component_info), GFP_KERNEL);
		if (!component_info)
			continue;

but the continue in a loop with a known alloc failure
seems silly as the next alloc is also extremely likely
to fail as well.

btw: Are you actually using this code?

If not, perhaps it's better to send cleanup only patches
for files in drivers/staging as practice instead.