From: Andrew Morton <akpm@linux-foundation.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Pavel Emelyanov <xemul@openvz.org>,
linux-kernel@vger.kernel.org, devel@openvz.org
Subject: Re: [PATCH 1/7][QUOTA] Move sysctl management code under ifdef CONFIG_SYSCTL
Date: Tue, 4 Dec 2007 03:48:36 -0800 [thread overview]
Message-ID: <20071204034836.47211436.akpm@linux-foundation.org> (raw)
In-Reply-To: <m1zlwqy9g5.fsf@ebiederm.dsl.xmission.com>
On Tue, 04 Dec 2007 04:40:26 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Tue, 04 Dec 2007 12:31:37 +0300 Pavel Emelyanov <xemul@openvz.org> wrote:
> >
> >> Andrew Morton wrote:
> >> > On Tue, 04 Dec 2007 11:58:30 +0300 Pavel Emelyanov <xemul@openvz.org> wrote:
> >> >
> >> >>>> +#ifdef CONFIG_SYSCTL
> >> >>>> register_sysctl_table(sys_table);
> >> >>>> +#endif
> >> >>>>
> >> >>>> dquot_cachep = kmem_cache_create("dquot",
> >> >>>> sizeof(struct dquot), sizeof(unsigned long) * 4,
> >> >>> We should avoid the ifdefs around the register_sysctl_table() call.
> >> >>>
> >> >>> At present the !CONFIG_SYSCTL implementation of register_sysctl_table() is
> >> >>> a non-inlined NULL-returning stub. All we have to do is to inline that
> > stub
> >> >>> then these ifdefs can go away.
> >> >> What if some code checks for the return value to be not-NULL? In case
> >> >> CONFIG_SYSCTL=n this code will always think, that the registration failed.
> >> >
> >> > The stub function should return success?
> >>
> >> Well, I think yes. If some functionality is turned off, then the
> >> caller should think that everything is going fine (or he should
> >> explicitly removes the call to it with some other ifdef).
> >>
> >> At least this is true for stubs that return the error code, not
> >> the pointer. E.g. copy_semundo() always returns success if SYSVIPC
> >> is off, or namespaces cloning routines act in a similar way.
> >>
> >> Thus I though, that routines, that return pointers should better
> >> report that everything is OK (somehow) to reduce the number of
> >> "helpers" in the outer code. No?
> >>
> >
> > Dunno. Returning NULL should be OK. If anyone is dereferenceing that
> > pointer with CONFIG_SYSCTL=n then they might need some attention?
>
> We do have some current code in the network stack that fails miserably
> when register_sysctl_table returns NULL, and there are explicit
> checks for that.
So that code would be failing today with CONFIG_SYSCTL=n? Unless the
failing code is itself under #ifdef CONFIG_SYSCTL, in which case we don't
need to change anything?
> Grr.
>
> I had forgotten about that.
>
> I expect the right answer is to simply have code ignore the fact
> that register_sysctl_xxxx returns NULL, and not error on it.
>
> The alternative is to get fancy and have everyone check the
> return code and make the return type an IS_ERR thing. That seems
> a lot more trouble then it is worth.
>
> We can probably define it as register_sysctl_xxxx always returns
> a token that must be passed to unregister_sysctl, and no errors
> will be reported except to dmesg. That at sounds simple sane
> and supportable from where we are now.
>
> Eric
>
>
next prev parent reply other threads:[~2007-12-04 11:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 12:58 [PATCH 0/7] Start using sysctl paths in the core kernel code Pavel Emelyanov
2007-11-30 13:02 ` [PATCH 1/7][QUOTA] Move sysctl management code under ifdef CONFIG_SYSCTL Pavel Emelyanov
2007-12-03 21:38 ` Andrew Morton
2007-12-03 23:32 ` Eric W. Biederman
2007-12-04 8:58 ` Pavel Emelyanov
2007-12-04 9:23 ` Andrew Morton
2007-12-04 9:31 ` Pavel Emelyanov
2007-12-04 9:45 ` Andrew Morton
2007-12-04 11:40 ` Eric W. Biederman
2007-12-04 11:48 ` Andrew Morton [this message]
2007-12-04 11:58 ` Pavel Emelyanov
2007-12-04 12:48 ` Eric W. Biederman
2007-11-30 13:04 ` [PATCH 2/7][QUOTA] Use sysctl paths to register tables Pavel Emelyanov
2007-11-30 13:09 ` [PATCH 3/7][SYSVIPC] Use the ctl " Pavel Emelyanov
2007-11-30 13:11 ` [PATCH 4/7][SCHED] " Pavel Emelyanov
2007-11-30 13:13 ` [PATCH 5/7][UTS] " Pavel Emelyanov
2007-11-30 13:16 ` [PATCH 6/7][MQUEUE] Move sysctl management code under ifdef CONFIG_SYSCTL Pavel Emelyanov
2007-11-30 13:18 ` [PATCH 7/7][MQUEUE] Use the ctl paths to register tables Pavel Emelyanov
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=20071204034836.47211436.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xemul@openvz.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.