[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091201065605.GA5361@elte.hu>
Date: Tue, 1 Dec 2009 07:56:05 +0100
From: Ingo Molnar <mingo@...e.hu>
To: David Howells <dhowells@...hat.com>
Cc: torvalds@...l.org, akpm@...ux-foundation.org, steved@...hat.com,
jens.axboe@...cle.com, linux-cachefs@...hat.com,
nfsv4@...ux-nfs.org, linux-fsdevel@...r.kernel.org,
cluster-devel@...hat.com, linux-kernel@...r.kernel.org,
linux-cifs-client@...ts.samba.org
Subject: [PATCH] slow-work: Fix build bug in the !CONFIG_MODULES case
* David Howells <dhowells@...hat.com> wrote:
> Hi Linus,
>
> Could you pull the attached patches before 2.6.32 please? I've added three
> one-liner patches to fix some silly bugs.
>
> For the most part these patches are bug fixes for the slow-work, FS-Cache and
> CacheFiles facilities, with a few patches to produce better debugging
> information, and a couple of patches to slow work from Jens that all the rest
> are built on top of.
these slow-work changes have introduced a new !CONFIG_MODULES build bug
on x86 (and all other architectures i suspect):
kernel/slow-work.c: In function ‘slow_work_execute’:
kernel/slow-work.c:313: error: ‘slow_work_thread_processing’ undeclared (first use in this function)
kernel/slow-work.c:313: error: (Each undeclared identifier is reported only once
kernel/slow-work.c:313: error: for each function it appears in.)
kernel/slow-work.c: In function ‘slow_work_wait_for_items’:
kernel/slow-work.c:950: error: ‘slow_work_unreg_sync_lock’ undeclared (first use in this function)
kernel/slow-work.c:951: error: ‘slow_work_unreg_wq’ undeclared (first use in this function)
kernel/slow-work.c:961: error: ‘slow_work_unreg_work_item’ undeclared (first use in this function)
kernel/slow-work.c:974: error: ‘slow_work_unreg_module’ undeclared (first use in this function)
kernel/slow-work.c:977: error: ‘slow_work_thread_processing’ undeclared (first use in this function)
Commit 3bde31a ("SLOW_WORK: Allow a requeueable work item to sleep till
the thread is needed") broke the !CONFIG_MODULES build by relying on
variables that are only available (and only make sense) with module
support enabled. Fix it.
Note, to fix it in a minimal way for .32 i've simply extended the
existing #ifdef's. In v2.6.33 a cleaner change would be to move the
whole wait-for-modules block into a separate slow-work-wait-modules.c
file or so - that will allow the removal of 6 #ifdefs.
Thanks,
Ingo
--------------------------->
>From ac73995e9be78ba5dcf3db843d7e04295decabcd Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...e.hu>
Date: Tue, 1 Dec 2009 07:47:52 +0100
Subject: [PATCH] slow-work: Fix build bug in the !CONFIG_MODULES case
Commit 3bde31a ("SLOW_WORK: Allow a requeueable work item to sleep till
the thread is needed") broke the !CONFIG_MODULES build by relying on
variables that are only available (and only make sense) with module
support enabled. Fix it.
Cc: David Howells <dhowells@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/slow-work.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kernel/slow-work.c b/kernel/slow-work.c
index da94f3c..5bae807 100644
--- a/kernel/slow-work.c
+++ b/kernel/slow-work.c
@@ -310,7 +310,9 @@ auto_requeue:
else
list_add_tail(&work->link, &slow_work_queue);
spin_unlock_irq(&slow_work_queue_lock);
+#ifdef CONFIG_MODULES
slow_work_thread_processing[id] = NULL;
+#endif
return true;
}
@@ -943,6 +945,7 @@ EXPORT_SYMBOL(slow_work_register_user);
*/
static void slow_work_wait_for_items(struct module *module)
{
+#ifdef CONFIG_MODULES
DECLARE_WAITQUEUE(myself, current);
struct slow_work *work;
int loop;
@@ -989,6 +992,7 @@ static void slow_work_wait_for_items(struct module *module)
remove_wait_queue(&slow_work_unreg_wq, &myself);
mutex_unlock(&slow_work_unreg_sync_lock);
+#endif
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists