public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: Michael Noisternig <mnoist@cosy.sbg.ac.at>
Cc: linux-kernel@vger.kernel.org
Subject: Re: configfs: return value for drop_item()/make_item()?
Date: Tue, 23 Jan 2007 11:06:31 -0800	[thread overview]
Message-ID: <20070123190631.GH9422@ca-server1.us.oracle.com> (raw)
In-Reply-To: <45B61287.1060206@cosy.sbg.ac.at>

On Tue, Jan 23, 2007 at 02:49:59PM +0100, Michael Noisternig wrote:
> Sorry, I wasn't clear. I meant that it's not possible to let the user 
> create the parent directory via mkdir(2) within sysfs. I.e.
> # mkdir object  <-- create object/, configfs only
> # ls object
> type
> # echo b > object/type  <-- create b/, sysfs only
> # ls object
> type
> b/
> I cannot have both, sysfs and configfs functionality, within the same 
> module configuration file system tree.

	No, you can't have sysfs and configfs functionality in the same
exact portion of the tree.  But you can use both sysfs and configfs at
the same time in your driver.  The different parts will appear in the
different trees.  Up to you.

> 1. Is there any guarantee that strings passed to struct 
> configfs_item_operations->store_attribute are 0-terminated? If not, 
> there's not only potential for buffer overflows, but there already is - 
> in configfs_example.c, using simple_strtoul().

	There is no guarantee, but that's a bug.  The attribute handling
code came from sysfs.  I assume the initial assumption was that since
you can only copy a page, it's OK.  Clearly not the case.  sysfs fixed
this in October (commit 035ed7a49447bc8e15d4d9316fc6a359b2d94333).  I'll
be porting that over.  Thanks for noticing!

> 2. A minor one: I realize that the CONFIGFS_ITEM_NAME_LEN value of 20 is 
> taken over from sysfs, but in configfs a config_group now has 68 bytes 
> of size, and assuming that many times one would simply kmalloc a simple 
> struct config_group (without extending it) this would result in a waste 
> of 60 bytes per malloc. Do you want to keep that #define or reduce it to 
> 16? Just a thought...

	Hmm, interesting.  I'll look at that as well.

Joel

-- 

Life's Little Instruction Book #511

	"Call your mother."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

  reply	other threads:[~2007-01-23 19:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <45AF6D0C.8020600@cosy.sbg.ac.at>
2007-01-18 22:12 ` configfs: return value for drop_item()/make_item()? Joel Becker
2007-01-22 12:35   ` Michael Noisternig
2007-01-23  1:13     ` Joel Becker
2007-01-23 13:49       ` Michael Noisternig
2007-01-23 19:06         ` Joel Becker [this message]
2007-01-15 10:55 Michael Noisternig
2007-01-16  8:30 ` Joel Becker
2007-01-16 16:42   ` Michael Noisternig

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=20070123190631.GH9422@ca-server1.us.oracle.com \
    --to=joel.becker@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mnoist@cosy.sbg.ac.at \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox