All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Simon Horman <horms@verge.net.au>
Cc: linux-pm@lists.linux-foundation.org,
	Dan Carpenter <error27@gmail.com>,
	mark gross <markgross@thegnar.org>
Subject: Re: [PATCH] PM QoS: Allow parsing of ASCII values
Date: Fri, 18 Feb 2011 10:17:20 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1102181006110.1972-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <20110218063955.GA2558@verge.net.au>

On Fri, 18 Feb 2011, Simon Horman wrote:

> Hi Mark,
> 
> On Thu, Feb 17, 2011 at 09:05:16PM -0800, mark gross wrote:
> > On Fri, Feb 18, 2011 at 10:54:56AM +0900, Simon Horman wrote:
> > > In "PM QoS: Correct pr_debug() misuse and improve parameter checks"
> > > the parsing of the ASCII hex value was tightened. Unfortunately
> > > it was tightened to the point where no value is valid.
> > 
> > How is it of no value?  Can you not sent a 10 char string with a
> > zero-byte end of string maker?
> 
> My testing indicates that
> 
> echo -n "0x12345678" will yield count == 10 in copy_from_user()
> 
> that
> 
> echo "0x12345678" will yield count == 11 in copy_from_user()
> 
> and that in both case strlen() will yeild the same value as count.
> 
> > Is expecting the c-string marker in the interface a bad idea that needs
> > fixing?
> 
> I think that is the crux of the problem from my point of view.
> That is, using echo as above there is no '\0' by the time
> the string gets to the kernel.
> 
> I now see that the following works :-)
> 
> echo -ne '0x12345678\0' | dd of=/dev/network_latency
> 
> However I wonder if the call to strlen() is safe.
> In the case of the following is there any guarantee that
> ascii_value is '\0' terminated? Perhaps strnlen() is needed?
> 
> echo -n '0x123456789' | dd of=/dev/network_latency

Normally these interfaces are designed so that people can do either

	echo '...data...' >/dev/...

or

	echo -n '...data...' >/dev/...

and it will just work.  This means you should allow count to be equal 
to either 10 or 11, but if it is 11 then you should check that the last 
character really is '\n'.

Also, you might want to consider using strict_strtoul() for parsing or 
conversion.

Alan Stern

  reply	other threads:[~2011-02-18 15:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18  1:54 [PATCH] PM QoS: Allow parsing of ASCII values Simon Horman
2011-02-18  5:05 ` mark gross
2011-02-18  6:39   ` Simon Horman
2011-02-18 15:17     ` Alan Stern [this message]
2011-02-22  4:33 ` mark gross
2011-02-23  6:56   ` mark gross
2011-02-23 15:20     ` Alan Stern
2011-02-24 16:17       ` mark gross
2011-02-24 17:00         ` Alan Stern
2011-03-06 14:07           ` mark gross
2011-03-29 20:01             ` Rafael J. Wysocki
2011-03-30  3:59               ` mark gross
2011-03-30  7:11                 ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1102181006110.1972-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=error27@gmail.com \
    --cc=horms@verge.net.au \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=markgross@thegnar.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.