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] [thread-next>] [day] [month] [year] [list]
Message-ID: <50F0CF13.9000106@oracle.com>
Date:	Sat, 12 Jan 2013 10:48:51 +0800
From:	Jeff Liu <jeff.liu@...cle.com>
To:	Dave Chinner <david@...morbit.com>
CC:	Abhijit Pawar <abhi.c.pawar@...il.com>, Ben Myers <bpm@....com>,
	Alex Elder <elder@...nel.org>, linux-kernel@...r.kernel.org,
	xfs@....sgi.com
Subject: Re: [PATCH 1/1] fs/xfs remove obsolete simple_strto<foo>

On 01/12/2013 06:52 AM, Dave Chinner wrote:
> On Fri, Jan 11, 2013 at 02:36:46PM +0800, Jeff Liu wrote:
>> On 01/09/2013 10:04 PM, Abhijit Pawar wrote:
>>> This patch replaces usages of obsolete simple_strtoul with kstrtoint in xfs_args and suffix_strtoul.
>>>
>>> Signed-off-by: Abhijit Pawar <abhi.c.pawar@...il.com>
>>> ---
>>> +			if (kstrtoint(value, 10, &dswidth))
>>> +				return EINVAL;
>>>  		} else if (!strcmp(this_char, MNTOPT_32BITINODE)) {
>>>  			mp->m_flags |= XFS_MOUNT_SMALL_INUMS;
>>>  		} else if (!strcmp(this_char, MNTOPT_64BITINODE)) {
>>>
>> checkpatch.pl show warning if we return EINVAL as below:
>> WARNING: return of an errno should typically be -ve (return -EINVAL)
>>
>> Can we just ignore such code style issue?
> 
> Returning a positive error is not a code style issue. It's a
> correctness issue. the core of the XFS code returns positive error
> numbers as that's the way it was done on Irix (where the XFs code
> comes from). The rest of the Linux code tends to use negative values
> for error returns, and we've never converted the XFS code base to
> negative errors.
> 
> You should always feel free to ignore checkpatch warnings that make
> no sense. I haven't used checkpatch now for several years - I
> stopped using it when it got too noisy warning about uselesss,
> trivial things in the XFS code base....
Thanks for the clarification, that would save me time to handle
checkpatch warnings against XFS in the future. :)

Cheers,
-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ