From: Michael Spiegle <mike@nauticaltech.com>
To: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
bugme-daemon@bugzilla.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [Bugme-new] [Bug 12201] New: long wait in call_usermodehelper() / queue_work() / wait_for_completion()
Date: Fri, 12 Dec 2008 11:51:57 -0800 [thread overview]
Message-ID: <4942C0DD.50602@nauticaltech.com> (raw)
In-Reply-To: <20081211230521.GA2392@ioremap.net>
> Btw, does this ugly hack fix the problem?
> According to your description it may be the case.
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 480184a..2b64eb5 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -434,6 +434,10 @@ static int netlink_create(struct net *net, struct socket *sock, int protocol)
> if (protocol < 0 || protocol >= MAX_LINKS)
> return -EPROTONOSUPPORT;
>
> +#ifndef CONFIG_AUDIT
> + if (protocol == NETLINK_AUDIT)
> + return -EPROTONOSUPPORT;
> +#endif
> netlink_lock_table();
> #ifdef CONFIG_MODULES
> if (!nl_table[protocol].registered) {
>
>
Yes, that would take care of it. My original workaround was to disable
CONFIG_KMOD. I only have a few modules compiled (for servers that
require those modules), but most of my servers don't need any modules.
This would allow me to manually load modules myself and never have to
worry about the kernel forking stuff in userspace. Unfortunately, it
appears that CONFIG_KMOD is being deprecated soon and I didn't want to
rely on it.
What is the core reason for removing CONFIG_KMOD? I personally would
rather have the choice as to whether my kernel tries to find its own
modules or not.
Michael Spiegle
mike@nauticaltech.com
next prev parent reply other threads:[~2008-12-12 19:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-12201-10286@http.bugzilla.kernel.org/>
2008-12-11 22:37 ` [Bugme-new] [Bug 12201] New: long wait in call_usermodehelper() / queue_work() / wait_for_completion() Andrew Morton
2008-12-11 22:48 ` Kay Sievers
2008-12-12 19:47 ` Michael Spiegle
2008-12-11 22:51 ` Evgeniy Polyakov
2008-12-11 23:05 ` Evgeniy Polyakov
2008-12-12 19:51 ` Michael Spiegle [this message]
2008-12-12 19:42 ` Michael Spiegle
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=4942C0DD.50602@nauticaltech.com \
--to=mike@nauticaltech.com \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zbr@ioremap.net \
/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;
as well as URLs for NNTP newsgroup(s).