From: Joel Becker <Joel.Becker@oracle.com>
To: Louis Rilling <louis.rilling@kerlabs.com>
Cc: linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [RFC][PATCH] configfs: Report errors in config_*_init_type_name()
Date: Wed, 18 Jun 2008 13:22:26 -0700 [thread overview]
Message-ID: <20080618202226.GG16780@ca-server1.us.oracle.com> (raw)
In-Reply-To: <1213813851-7359-1-git-send-email-louis.rilling@kerlabs.com>
On Wed, Jun 18, 2008 at 08:30:51PM +0200, Louis Rilling wrote:
> [ applies on top of http://lkml.org/lkml/2008/6/12/427 ]
>
> config_item_set_name() may fail but its error code is not checked in
> config_*_init_type_name().
>
> This patch adds the missing error checking and make config_*_init_type_name()
> report errors. In-tree users are updated to report errors as well.
While this patch is correct on the face, I'd like to try a
different approach. I wasn't thinking about it right.
See, config_*_init_type_name() are generally a create-time thing.
Almost everyone uses it without error checking because they know it is
safe; they are usually using a static name. config_item_set_name()
can only error if strlen(name)>CONFIGFS_ITEM_NAME_LEN. That's why
config_*_init_type_name() are void.
In other words, we shouldn't be adding useless error-check
boilerplate for already-safe things.
But there are a couple of users of config_*_set_type_name() that
aren't safe. The lockspace in fs/dlm/config.c is one (lockspace names
can be 64 characters). The config_*_init_type_name() helpers are quite
convenient.
I see two choices:
1) Make your changes to return errors from config_*_init_type_name(),
but don't check the errors on known-safe usage (small static
strings).
2) Provide two API, one that is void and one that is not, so that
known-safe usage can use the void call (and BUG_ON() if the strlen()
is off), while other usage checks the errors.
Joel
--
Life's Little Instruction Book #3
"Watch a sunrise at least once a year."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
WARNING: multiple messages have this Message-ID (diff)
From: Joel Becker <Joel.Becker@oracle.com>
To: Louis Rilling <louis.rilling@kerlabs.com>
Cc: linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com
Subject: Re: [RFC][PATCH] configfs: Report errors in config_*_init_type_name()
Date: Wed, 18 Jun 2008 13:22:26 -0700 [thread overview]
Message-ID: <20080618202226.GG16780@ca-server1.us.oracle.com> (raw)
In-Reply-To: <1213813851-7359-1-git-send-email-louis.rilling@kerlabs.com>
On Wed, Jun 18, 2008 at 08:30:51PM +0200, Louis Rilling wrote:
> [ applies on top of http://lkml.org/lkml/2008/6/12/427 ]
>
> config_item_set_name() may fail but its error code is not checked in
> config_*_init_type_name().
>
> This patch adds the missing error checking and make config_*_init_type_name()
> report errors. In-tree users are updated to report errors as well.
While this patch is correct on the face, I'd like to try a
different approach. I wasn't thinking about it right.
See, config_*_init_type_name() are generally a create-time thing.
Almost everyone uses it without error checking because they know it is
safe; they are usually using a static name. config_item_set_name()
can only error if strlen(name)>CONFIGFS_ITEM_NAME_LEN. That's why
config_*_init_type_name() are void.
In other words, we shouldn't be adding useless error-check
boilerplate for already-safe things.
But there are a couple of users of config_*_set_type_name() that
aren't safe. The lockspace in fs/dlm/config.c is one (lockspace names
can be 64 characters). The config_*_init_type_name() helpers are quite
convenient.
I see two choices:
1) Make your changes to return errors from config_*_init_type_name(),
but don't check the errors on known-safe usage (small static
strings).
2) Provide two API, one that is void and one that is not, so that
known-safe usage can use the void call (and BUG_ON() if the strlen()
is off), while other usage checks the errors.
Joel
--
Life's Little Instruction Book #3
"Watch a sunrise at least once a year."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2008-06-18 20:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-18 18:30 [Ocfs2-devel] [RFC][PATCH] configfs: Report errors in config_*_init_type_name() Louis Rilling
2008-06-18 18:30 ` Louis Rilling
2008-06-18 20:22 ` Joel Becker [this message]
2008-06-18 20:22 ` Joel Becker
2008-06-19 9:10 ` [Ocfs2-devel] " Louis Rilling
2008-06-19 9:10 ` Louis Rilling
2008-06-19 22:08 ` [Ocfs2-devel] " Joel Becker
2008-06-19 22:08 ` Joel Becker
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=20080618202226.GG16780@ca-server1.us.oracle.com \
--to=joel.becker@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.rilling@kerlabs.com \
--cc=ocfs2-devel@oss.oracle.com \
/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.