public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xfsprogs: check for size parsing errors in xfs_quota
@ 2012-01-23 17:31 Eric Sandeen
  2012-01-23 19:59 ` Christoph Hellwig
  2012-01-24 17:56 ` Christoph Hellwig
  0 siblings, 2 replies; 7+ messages in thread
From: Eric Sandeen @ 2012-01-23 17:31 UTC (permalink / raw)
  To: xfs-oss; +Cc: James Lawrie

Doing something like 

# xfs_quota -x -c 'limit -u bhard=1.2g ...

will cause cvtnum to fail and return a value of -1LL (because it
cannot parse the decimal), but the quota caller doesn't check
for this error value, casts it to U64, shifts right, and we end
up with an answer of 16 petabytes rather than erroring out.
Fix this.

Reported-by: James Lawrie <james@jdlawrie.co.uk>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

diff --git a/quota/edit.c b/quota/edit.c
index b704e63..067cd63 100644
--- a/quota/edit.c
+++ b/quota/edit.c
@@ -226,13 +226,17 @@ extractb(
 	uint		sectorsize,
 	__uint64_t	*value)
 {
-	__uint64_t	v;
+	long long	v;
 	char		*s = string;
 
 	if (strncmp(string, prefix, length) == 0) {
 		s = string + length + 1;
-		v = (__uint64_t)cvtnum(blocksize, sectorsize, s);
-		*value = v >> 9;	/* syscalls use basic blocks */
+		v = cvtnum(blocksize, sectorsize, s);
+		if (v == -1LL) {
+			fprintf(stderr, _("%s: Error: could not parse size %s.\n"), progname, s);
+			return 0;
+		}
+		*value = (__uint64_t)v >> 8;	/* syscalls use basic blocks */
 		if (v > 0 && *value == 0)
 			fprintf(stderr, _("%s: Warning: `%s' in quota blocks is 0 (unlimited).\n"), progname, s);
 		return 1;

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] xfsprogs: check for size parsing errors in xfs_quota
  2012-01-23 17:31 [PATCH] xfsprogs: check for size parsing errors in xfs_quota Eric Sandeen
@ 2012-01-23 19:59 ` Christoph Hellwig
  2012-01-24  5:07   ` Eric Sandeen
  2012-01-24 17:56 ` Christoph Hellwig
  1 sibling, 1 reply; 7+ messages in thread
From: Christoph Hellwig @ 2012-01-23 19:59 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: James Lawrie, xfs-oss

On Mon, Jan 23, 2012 at 11:31:53AM -0600, Eric Sandeen wrote:
> Doing something like 
> 
> # xfs_quota -x -c 'limit -u bhard=1.2g ...
> 
> will cause cvtnum to fail and return a value of -1LL (because it
> cannot parse the decimal), but the quota caller doesn't check
> for this error value, casts it to U64, shifts right, and we end
> up with an answer of 16 petabytes rather than erroring out.
> Fix this.

Can you add a test case for it, please?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] xfsprogs: check for size parsing errors in xfs_quota
  2012-01-23 19:59 ` Christoph Hellwig
@ 2012-01-24  5:07   ` Eric Sandeen
  0 siblings, 0 replies; 7+ messages in thread
From: Eric Sandeen @ 2012-01-24  5:07 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: James Lawrie, Eric Sandeen, xfs-oss

On 1/23/12 1:59 PM, Christoph Hellwig wrote:
> On Mon, Jan 23, 2012 at 11:31:53AM -0600, Eric Sandeen wrote:
>> Doing something like 
>>
>> # xfs_quota -x -c 'limit -u bhard=1.2g ...
>>
>> will cause cvtnum to fail and return a value of -1LL (because it
>> cannot parse the decimal), but the quota caller doesn't check
>> for this error value, casts it to U64, shifts right, and we end
>> up with an answer of 16 petabytes rather than erroring out.
>> Fix this.
> 
> Can you add a test case for it, please?

sure... I have quite a backlog of tests I need to get pushed to git :(

Is that an ack for the patch, though? :)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] xfsprogs: check for size parsing errors in xfs_quota
  2012-01-23 17:31 [PATCH] xfsprogs: check for size parsing errors in xfs_quota Eric Sandeen
  2012-01-23 19:59 ` Christoph Hellwig
@ 2012-01-24 17:56 ` Christoph Hellwig
  2012-01-24 17:58   ` Eric Sandeen
  2012-01-27 19:26   ` [PATCH V2] " Eric Sandeen
  1 sibling, 2 replies; 7+ messages in thread
From: Christoph Hellwig @ 2012-01-24 17:56 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: James Lawrie, xfs-oss

> -		v = (__uint64_t)cvtnum(blocksize, sectorsize, s);
> -		*value = v >> 9;	/* syscalls use basic blocks */
> +		v = cvtnum(blocksize, sectorsize, s);
> +		if (v == -1LL) {
> +			fprintf(stderr, _("%s: Error: could not parse size %s.\n"), progname, s);
> +			return 0;
> +		}
> +		*value = (__uint64_t)v >> 8;	/* syscalls use basic blocks */

Why do you replace the shift by nine with a shift by 8?

Also please don't introduce new overly long lines, just move the
translated string to a line of its own, indented by a single tab similar
to how we do it in most new xfs/xfsprogs code.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] xfsprogs: check for size parsing errors in xfs_quota
  2012-01-24 17:56 ` Christoph Hellwig
@ 2012-01-24 17:58   ` Eric Sandeen
  2012-01-27 19:26   ` [PATCH V2] " Eric Sandeen
  1 sibling, 0 replies; 7+ messages in thread
From: Eric Sandeen @ 2012-01-24 17:58 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: James Lawrie, xfs-oss

On 1/24/12 11:56 AM, Christoph Hellwig wrote:
>> -		v = (__uint64_t)cvtnum(blocksize, sectorsize, s);
>> -		*value = v >> 9;	/* syscalls use basic blocks */
>> +		v = cvtnum(blocksize, sectorsize, s);
>> +		if (v == -1LL) {
>> +			fprintf(stderr, _("%s: Error: could not parse size %s.\n"), progname, s);
>> +			return 0;
>> +		}
>> +		*value = (__uint64_t)v >> 8;	/* syscalls use basic blocks */
> 
> Why do you replace the shift by nine with a shift by 8?

yeargh, NFI - vi gone wild?

> Also please don't introduce new overly long lines, just move the
> translated string to a line of its own, indented by a single tab similar
> to how we do it in most new xfs/xfsprogs code.

Ok, sure, sorry.  TBH I noticed it but there was such a long line below
I didn't worry.  Will resend.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH V2] xfsprogs: check for size parsing errors in xfs_quota
  2012-01-24 17:56 ` Christoph Hellwig
  2012-01-24 17:58   ` Eric Sandeen
@ 2012-01-27 19:26   ` Eric Sandeen
  2012-02-03 17:41     ` Mark Tinguely
  1 sibling, 1 reply; 7+ messages in thread
From: Eric Sandeen @ 2012-01-27 19:26 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: James Lawrie, xfs-oss

Doing something like 

# xfs_quota -x -c 'limit -u bhard=1.2g ...

will cause cvtnum to fail and return a value of -1LL (because it
cannot parse the decimal), but the quota caller doesn't check
for this error value, casts it to U64, shifts right, and we end
up with an answer of 16 petabytes rather than erroring out.
Fix this.

Reported-by: James Lawrie <james@jdlawrie.co.uk>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

V2: Fix mysterious change in shift size, shorten long line

diff --git a/quota/edit.c b/quota/edit.c
index b704e63..cad3aee 100644
--- a/quota/edit.c
+++ b/quota/edit.c
@@ -226,13 +226,19 @@ extractb(
 	uint		sectorsize,
 	__uint64_t	*value)
 {
-	__uint64_t	v;
+	long long	v;
 	char		*s = string;
 
 	if (strncmp(string, prefix, length) == 0) {
 		s = string + length + 1;
-		v = (__uint64_t)cvtnum(blocksize, sectorsize, s);
-		*value = v >> 9;	/* syscalls use basic blocks */
+		v = cvtnum(blocksize, sectorsize, s);
+		if (v == -1LL) {
+			fprintf(stderr,
+				_("%s: Error: could not parse size %s.\n"),
+				progname, s);
+			return 0;
+		}
+		*value = (__uint64_t)v >> 9;	/* syscalls use basic blocks */
 		if (v > 0 && *value == 0)
 			fprintf(stderr, _("%s: Warning: `%s' in quota blocks is 0 (unlimited).\n"), progname, s);
 		return 1;

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH V2] xfsprogs: check for size parsing errors in xfs_quota
  2012-01-27 19:26   ` [PATCH V2] " Eric Sandeen
@ 2012-02-03 17:41     ` Mark Tinguely
  0 siblings, 0 replies; 7+ messages in thread
From: Mark Tinguely @ 2012-02-03 17:41 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: James Lawrie, xfs-oss

On 01/27/12 13:26, Eric Sandeen wrote:
> Doing something like
>
> # xfs_quota -x -c 'limit -u bhard=1.2g ...
>
> will cause cvtnum to fail and return a value of -1LL (because it
> cannot parse the decimal), but the quota caller doesn't check
> for this error value, casts it to U64, shifts right, and we end
> up with an answer of 16 petabytes rather than erroring out.
> Fix this.
>
> Reported-by: James Lawrie<james@jdlawrie.co.uk>
> Signed-off-by: Eric Sandeen<sandeen@redhat.com>
> ---

Looks and works great.

Reviewed-by: Mark Tinguely <tinguely@sgi.com>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-02-03 17:41 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-23 17:31 [PATCH] xfsprogs: check for size parsing errors in xfs_quota Eric Sandeen
2012-01-23 19:59 ` Christoph Hellwig
2012-01-24  5:07   ` Eric Sandeen
2012-01-24 17:56 ` Christoph Hellwig
2012-01-24 17:58   ` Eric Sandeen
2012-01-27 19:26   ` [PATCH V2] " Eric Sandeen
2012-02-03 17:41     ` Mark Tinguely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox