Re: [PATCH 1/3] libxfs: handle 0 blocksize or sectorsize in cvtnum

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/22/17 8:01 PM, Dave Chinner wrote:
> On Tue, Aug 22, 2017 at 04:12:48PM -0500, Eric Sandeen wrote:
>> Blocksize and sectorsize are unique in that they must
>> be provided, unlike every other suffix which can be
>> calculated from constants.
>>
>> Nothing protects against unspecified block & sector size,
>> so catch it if it happens and return a parsing error.
>>
>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
>> ---
>>
>> diff --git a/libxcmd/input.c b/libxcmd/input.c
>> index 7a69dc1..7b86225 100644
>> --- a/libxcmd/input.c
>> +++ b/libxcmd/input.c
>> @@ -330,8 +330,12 @@ cvtnum(
>>  	c = tolower(*sp);
>>  	switch (c) {
>>  	case 'b':
>> +		if (!blocksize)
>> +			return -1LL;
>>  		return i * blocksize;
>>  	case 's':
>> +		if (!sectorsize)
>> +			return -1LL;
>>  		return i * sectorsize;
>>  	case 'k':
>>  		return KILOBYTES(i);
> 
> With this you could have mkfs call the generic function, too.

Yep, or at least closer; mkfs does a printf and usage()/exit()
and it indicates a user error (most likely)

in libxcmd/xfs_io it's more of a programming error, with no 
printf to the user at least today... so would need a little more
finessing.

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux