[1/3] libxfs: handle 0 blocksize or sectorsize in cvtnum
diff mbox

Message ID 2e0acf4a-a863-8304-65d3-5027368c69e2@sandeen.net
State New
Headers show

Commit Message

Eric Sandeen Aug. 22, 2017, 9:12 p.m. UTC
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@redhat.com>
---

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

Comments

Dave Chinner Aug. 23, 2017, 1:01 a.m. UTC | #1
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@redhat.com>
> ---
> 
> 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.

Cheers,

Dave.
Eric Sandeen Aug. 23, 2017, 2:13 a.m. UTC | #2
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@redhat.com>
>> ---
>>
>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Darrick J. Wong Aug. 23, 2017, 8:14 p.m. UTC | #3
On Tue, Aug 22, 2017 at 09:13:03PM -0500, Eric Sandeen wrote:
> 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@redhat.com>
> >> ---
> >>
> >> 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.

This series looks mostly fine to me, but I'm wondering if io_cvtnum
should be promoted so that mkfs/spaceman/quota/etc can take advantage of
it too?

--D

> 
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Sandeen Aug. 23, 2017, 8:18 p.m. UTC | #4
On 8/23/17 3:14 PM, Darrick J. Wong wrote:
> On Tue, Aug 22, 2017 at 09:13:03PM -0500, Eric Sandeen wrote:
>> 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@redhat.com>
>>>> ---
>>>>
>>>> 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.
> 
> This series looks mostly fine to me, but I'm wondering if io_cvtnum
> should be promoted so that mkfs/spaceman/quota/etc can take advantage of
> it too?

I thought about that, but it relies on the global var "file" that io uses,
which seems a bit unique to io, no?

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Darrick J. Wong Aug. 23, 2017, 8:24 p.m. UTC | #5
On Wed, Aug 23, 2017 at 03:18:45PM -0500, Eric Sandeen wrote:
> 
> 
> On 8/23/17 3:14 PM, Darrick J. Wong wrote:
> > On Tue, Aug 22, 2017 at 09:13:03PM -0500, Eric Sandeen wrote:
> >> 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@redhat.com>
> >>>> ---
> >>>>
> >>>> 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.
> > 
> > This series looks mostly fine to me, but I'm wondering if io_cvtnum
> > should be promoted so that mkfs/spaceman/quota/etc can take advantage of
> > it too?
> 
> I thought about that, but it relies on the global var "file" that io uses,
> which seems a bit unique to io, no?

Spaceman has it too.

I guess quota does its own weird thing...

--D

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

Patch
diff mbox

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);