From: Pekka Enberg <[email protected]>
Impact: fix build
This patch fixes up the following build breakage caused by commit
e251ea2fa52321009940fad02238ef1c369531ae ("rcu: don't include unnecessary
headers, allow kmemtrace w/ tracepoints"):
CC fs/befs/debug.o
fs/befs/debug.c: In function ‘befs_error’:
fs/befs/debug.c:31: error: implicit declaration of function ‘kmalloc’
fs/befs/debug.c:31: warning: initialization makes pointer from integer without a cast
fs/befs/debug.c:42: error: implicit declaration of function ‘kfree’
fs/befs/debug.c: In function ‘befs_warning’:
fs/befs/debug.c:49: warning: initialization makes pointer from integer without a cast
fs/befs/debug.c: In function ‘befs_debug’:
fs/befs/debug.c:73: warning: assignment makes pointer from integer without a cast
make[1]: *** [fs/befs/debug.o] Error 1
make: *** [fs/befs/] Error 2
Cc: Eduard - Gabriel Munteanu <[email protected]>
Signed-off-by: Pekka Enberg <[email protected]>
---
fs/befs/debug.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/befs/debug.c b/fs/befs/debug.c
index b8e304a..622e737 100644
--- a/fs/befs/debug.c
+++ b/fs/befs/debug.c
@@ -17,6 +17,7 @@
#include <linux/spinlock.h>
#include <linux/kernel.h>
#include <linux/fs.h>
+#include <linux/slab.h>
#endif /* __KERNEL__ */
--
1.5.4.3
there's another build problem as well, in squashfs, and in key.h:
include/linux/key.h:128: error: field 'sem' has incomplete type
fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
And i suspect there's more as well. Is there really no unintrusive
way to solve this - or do you think the RCU change reduces the
include file spaghetti?
Ingo
On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> there's another build problem as well, in squashfs, and in key.h:
>
> include/linux/key.h:128: error: field 'sem' has incomplete type
> fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
>
> And i suspect there's more as well. Is there really no unintrusive
> way to solve this - or do you think the RCU change reduces the
> include file spaghetti?
I don't think there is and yes, I do think the RCU change cleans up
things as well.
Pekka
* Pekka Enberg <[email protected]> wrote:
> On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> > there's another build problem as well, in squashfs, and in key.h:
> >
> > include/linux/key.h:128: error: field 'sem' has incomplete type
> > fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> > fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
> >
> > And i suspect there's more as well. Is there really no unintrusive
> > way to solve this - or do you think the RCU change reduces the
> > include file spaghetti?
>
> I don't think there is and yes, I do think the RCU change cleans
> up things as well.
Okay. Note, you'll have to test tip:tracing/kmemtrace explicitly as
i had to exclude it from tip:master due to test failures. Will put
it back in once fixes arrive :)
Ingo
On Tue, 2009-03-24 at 09:56 +0100, Ingo Molnar wrote:
> * Pekka Enberg <[email protected]> wrote:
>
> > On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> > > there's another build problem as well, in squashfs, and in key.h:
> > >
> > > include/linux/key.h:128: error: field 'sem' has incomplete type
> > > fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> > > fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
> > >
> > > And i suspect there's more as well. Is there really no unintrusive
> > > way to solve this - or do you think the RCU change reduces the
> > > include file spaghetti?
> >
> > I don't think there is and yes, I do think the RCU change cleans
> > up things as well.
>
> Okay. Note, you'll have to test tip:tracing/kmemtrace explicitly as
> i had to exclude it from tip:master due to test failures. Will put
> it back in once fixes arrive :)
That's what I am testing right now. It's just that I am working on an
old laptop where building the kernel takes a looong time.... :-)
* Pekka Enberg <[email protected]> wrote:
> On Tue, 2009-03-24 at 09:56 +0100, Ingo Molnar wrote:
> > * Pekka Enberg <[email protected]> wrote:
> >
> > > On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> > > > there's another build problem as well, in squashfs, and in key.h:
> > > >
> > > > include/linux/key.h:128: error: field 'sem' has incomplete type
> > > > fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> > > > fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
> > > >
> > > > And i suspect there's more as well. Is there really no unintrusive
> > > > way to solve this - or do you think the RCU change reduces the
> > > > include file spaghetti?
> > >
> > > I don't think there is and yes, I do think the RCU change cleans
> > > up things as well.
> >
> > Okay. Note, you'll have to test tip:tracing/kmemtrace explicitly as
> > i had to exclude it from tip:master due to test failures. Will put
> > it back in once fixes arrive :)
>
> That's what I am testing right now. It's just that I am working on
> an old laptop where building the kernel takes a looong time....
> :-)
ok - let me help then.
On (64-bit) allyesconfig there's 5 distinct build failures:
include/linux/key.h:128: error: field ‘sem’ has incomplete type
distcc[22541] ERROR: compile security/keys/sysctl.c on a/16 failed
lib/decompress_bunzip2.c:636: error: implicit declaration of function ‘kmalloc’
lib/decompress_bunzip2.c:726: error: implicit declaration of function ‘kfree’
In file included from include/keys/user-type.h:16,
from fs/cifs/cifs_spnego.c:25:
include/linux/key.h:128: error: field ‘sem’ has incomplete type
distcc[3226] ERROR: compile fs/cifs/cifs_spnego.c on ph/16 failed
lib/decompress_inflate.c:45: error: implicit declaration of function ‘kmalloc’
lib/decompress_inflate.c:154: error: implicit declaration of function ‘kfree’
lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
You should be able to reproduce them (on 32-bit too) one by one via:
make lib/decompress_unlzma.o
etc. - without having to redo the full allyesconfig. (i'll redo that
after the fixes, to flush out remaining/dependent bugs)
Ingo
On Tue, 2009-03-24 at 10:07 +0100, Ingo Molnar wrote:
> * Pekka Enberg <[email protected]> wrote:
>
> > On Tue, 2009-03-24 at 09:56 +0100, Ingo Molnar wrote:
> > > * Pekka Enberg <[email protected]> wrote:
> > >
> > > > On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> > > > > there's another build problem as well, in squashfs, and in key.h:
> > > > >
> > > > > include/linux/key.h:128: error: field 'sem' has incomplete type
> > > > > fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> > > > > fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
> > > > >
> > > > > And i suspect there's more as well. Is there really no unintrusive
> > > > > way to solve this - or do you think the RCU change reduces the
> > > > > include file spaghetti?
> > > >
> > > > I don't think there is and yes, I do think the RCU change cleans
> > > > up things as well.
> > >
> > > Okay. Note, you'll have to test tip:tracing/kmemtrace explicitly as
> > > i had to exclude it from tip:master due to test failures. Will put
> > > it back in once fixes arrive :)
> >
> > That's what I am testing right now. It's just that I am working on
> > an old laptop where building the kernel takes a looong time....
> > :-)
>
> ok - let me help then.
>
> On (64-bit) allyesconfig there's 5 distinct build failures:
>
> include/linux/key.h:128: error: field ‘sem’ has incomplete type
> distcc[22541] ERROR: compile security/keys/sysctl.c on a/16 failed
>
> lib/decompress_bunzip2.c:636: error: implicit declaration of function ‘kmalloc’
> lib/decompress_bunzip2.c:726: error: implicit declaration of function ‘kfree’
>
> In file included from include/keys/user-type.h:16,
> from fs/cifs/cifs_spnego.c:25:
> include/linux/key.h:128: error: field ‘sem’ has incomplete type
> distcc[3226] ERROR: compile fs/cifs/cifs_spnego.c on ph/16 failed
>
> lib/decompress_inflate.c:45: error: implicit declaration of function ‘kmalloc’
> lib/decompress_inflate.c:154: error: implicit declaration of function ‘kfree’
>
> lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
> lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
>
> You should be able to reproduce them (on 32-bit too) one by one via:
>
> make lib/decompress_unlzma.o
>
> etc. - without having to redo the full allyesconfig. (i'll redo that
> after the fixes, to flush out remaining/dependent bugs)
OK, I think all of them are now fixed. I haven't yet been able to
complete a build so help is still appreciated. ;-)
Pekka
* Pekka Enberg <[email protected]> wrote:
> On Tue, 2009-03-24 at 10:07 +0100, Ingo Molnar wrote:
> > * Pekka Enberg <[email protected]> wrote:
> >
> > > On Tue, 2009-03-24 at 09:56 +0100, Ingo Molnar wrote:
> > > > * Pekka Enberg <[email protected]> wrote:
> > > >
> > > > > On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> > > > > > there's another build problem as well, in squashfs, and in key.h:
> > > > > >
> > > > > > include/linux/key.h:128: error: field 'sem' has incomplete type
> > > > > > fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> > > > > > fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
> > > > > >
> > > > > > And i suspect there's more as well. Is there really no unintrusive
> > > > > > way to solve this - or do you think the RCU change reduces the
> > > > > > include file spaghetti?
> > > > >
> > > > > I don't think there is and yes, I do think the RCU change cleans
> > > > > up things as well.
> > > >
> > > > Okay. Note, you'll have to test tip:tracing/kmemtrace explicitly as
> > > > i had to exclude it from tip:master due to test failures. Will put
> > > > it back in once fixes arrive :)
> > >
> > > That's what I am testing right now. It's just that I am working on
> > > an old laptop where building the kernel takes a looong time....
> > > :-)
> >
> > ok - let me help then.
> >
> > On (64-bit) allyesconfig there's 5 distinct build failures:
> >
> > include/linux/key.h:128: error: field ‘sem’ has incomplete type
> > distcc[22541] ERROR: compile security/keys/sysctl.c on a/16 failed
> >
> > lib/decompress_bunzip2.c:636: error: implicit declaration of function ‘kmalloc’
> > lib/decompress_bunzip2.c:726: error: implicit declaration of function ‘kfree’
> >
> > In file included from include/keys/user-type.h:16,
> > from fs/cifs/cifs_spnego.c:25:
> > include/linux/key.h:128: error: field ‘sem’ has incomplete type
> > distcc[3226] ERROR: compile fs/cifs/cifs_spnego.c on ph/16 failed
> >
> > lib/decompress_inflate.c:45: error: implicit declaration of function ‘kmalloc’
> > lib/decompress_inflate.c:154: error: implicit declaration of function ‘kfree’
> >
> > lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
> > lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
> >
> > You should be able to reproduce them (on 32-bit too) one by one via:
> >
> > make lib/decompress_unlzma.o
> >
> > etc. - without having to redo the full allyesconfig. (i'll redo that
> > after the fixes, to flush out remaining/dependent bugs)
>
> OK, I think all of them are now fixed. I haven't yet been able to
> complete a build so help is still appreciated. ;-)
unless there's a mail delay, we still have:
lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
Ingo
On Tue, 2009-03-24 at 10:17 +0100, Ingo Molnar wrote:
> > OK, I think all of them are now fixed. I haven't yet been able to
> > complete a build so help is still appreciated. ;-)
>
> unless there's a mail delay, we still have:
>
> lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
> lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
Sorry, I missed that. I was testing the .config you sent in the initial
mail, not allyesconfig. I sent you a patch to fix that as well now.
Pekka
* Pekka Enberg <[email protected]> wrote:
> On Tue, 2009-03-24 at 10:17 +0100, Ingo Molnar wrote:
> > > OK, I think all of them are now fixed. I haven't yet been able to
> > > complete a build so help is still appreciated. ;-)
> >
> > unless there's a mail delay, we still have:
> >
> > lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
> > lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
>
> Sorry, I missed that. I was testing the .config you sent in the
> initial mail, not allyesconfig. I sent you a patch to fix that as
> well now.
no problem, i missed it too - computer reminded us that it's still
there ;-)
there's a new headers-export-check failure:
/home/mingo/tip/usr/include/linux/bsg.h:11: found __[us]{8,16,32,64} type without #include <linux/types.h>
/home/mingo/tip/usr/include/linux/fs.h:11: included file 'linux/gfp.h' is not exported
make[3]: *** [/home/mingo/tip/usr/include/linux/.check] Error 1
make[2]: *** [linux] Error 2
(CONFIG_HEADERS_CHECK)
Ingo
there's also link failures with certain configs:
mm/built-in.o: In function `sparse_index_alloc':
sparse.c:(.ref.text+0x142): undefined reference to `__tracepoint_kmalloc'
sparse.c:(.ref.text+0x156): undefined reference to `__tracepoint_kmalloc'
config attached.
Ingo
On Tue, 2009-03-24 at 10:31 +0100, Ingo Molnar wrote:
> * Pekka Enberg <[email protected]> wrote:
>
> > On Tue, 2009-03-24 at 10:17 +0100, Ingo Molnar wrote:
> > > > OK, I think all of them are now fixed. I haven't yet been able to
> > > > complete a build so help is still appreciated. ;-)
> > >
> > > unless there's a mail delay, we still have:
> > >
> > > lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
> > > lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
> >
> > Sorry, I missed that. I was testing the .config you sent in the
> > initial mail, not allyesconfig. I sent you a patch to fix that as
> > well now.
>
> no problem, i missed it too - computer reminded us that it's still
> there ;-)
>
> there's a new headers-export-check failure:
>
> /home/mingo/tip/usr/include/linux/bsg.h:11: found __[us]{8,16,32,64} type without #include <linux/types.h>
> /home/mingo/tip/usr/include/linux/fs.h:11: included file 'linux/gfp.h' is not exported
> make[3]: *** [/home/mingo/tip/usr/include/linux/.check] Error 1
> make[2]: *** [linux] Error 2
>
> (CONFIG_HEADERS_CHECK)
Hmm, I wonder what is the best way to fix this, though. I think we
better use macros there (like rest of linux/fs.h) does because of
dependency issues. What do you think?
Pekka
diff --git a/include/linux/fs.h b/include/linux/fs.h
index add95da..4dda05d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -8,7 +8,6 @@
#include <linux/limits.h>
#include <linux/ioctl.h>
-#include <linux/gfp.h>
/*
* It's silly to have NR_OPEN bigger than NR_FILE, but you can change
@@ -2233,15 +2232,8 @@ ssize_t simple_attr_write(struct file *file, const char __user *buf,
#ifdef CONFIG_SECURITY
-static inline char *alloc_secdata(void)
-{
- return (char *)get_zeroed_page(GFP_KERNEL);
-}
-
-static inline void free_secdata(void *secdata)
-{
- free_page((unsigned long)secdata);
-}
+#define alloc_secdata() (char *)get_zeroed_page(GFP_KERNEL)
+#define free_secdata() free_page((unsigned long) secdata)
#else
static inline char *alloc_secdata(void)
{
there's also this build failure:
In file included from include/linux/slub_def.h:14,
from include/linux/slab.h:154,
from include/linux/percpu.h:6,
from include/linux/rcutree.h:37,
from include/linux/rcupdate.h:61,
from include/linux/tracepoint.h:19,
from include/linux/module.h:20,
from include/linux/crypto.h:22,
from arch/x86/kernel/asm-offsets_64.c:8,
from arch/x86/kernel/asm-offsets.c:5:
include/trace/kmemtrace.h:18: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:25: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:32: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:40: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:48: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:51: error: expected ‘)’ before ‘(’ token
In file included from include/linux/slab.h:154,
from include/linux/percpu.h:6,
from include/linux/rcutree.h:37,
from include/linux/rcupdate.h:61,
from include/linux/tracepoint.h:19,
from include/linux/module.h:20,
from include/linux/crypto.h:22,
from arch/x86/kernel/asm-offsets_64.c:8,
from arch/x86/kernel/asm-offsets.c:5:
include/linux/slub_def.h: In function ‘kmalloc_large’:
include/linux/slub_def.h:236: error: implicit declaration of function ‘trace_kmalloc’
include/linux/slub_def.h: In function ‘kmalloc_node’:
include/linux/slub_def.h:296: error: implicit declaration of function ‘trace_kmalloc_node’
with the attached config.
Ingo
* Pekka Enberg <[email protected]> wrote:
> On Tue, 2009-03-24 at 10:31 +0100, Ingo Molnar wrote:
> > * Pekka Enberg <[email protected]> wrote:
> >
> > > On Tue, 2009-03-24 at 10:17 +0100, Ingo Molnar wrote:
> > > > > OK, I think all of them are now fixed. I haven't yet been able to
> > > > > complete a build so help is still appreciated. ;-)
> > > >
> > > > unless there's a mail delay, we still have:
> > > >
> > > > lib/decompress_unlzma.c:122: error: implicit declaration of function ‘kfree’
> > > > lib/decompress_unlzma.c:551: error: implicit declaration of function ‘kmalloc’
> > >
> > > Sorry, I missed that. I was testing the .config you sent in the
> > > initial mail, not allyesconfig. I sent you a patch to fix that as
> > > well now.
> >
> > no problem, i missed it too - computer reminded us that it's still
> > there ;-)
> >
> > there's a new headers-export-check failure:
> >
> > /home/mingo/tip/usr/include/linux/bsg.h:11: found __[us]{8,16,32,64} type without #include <linux/types.h>
> > /home/mingo/tip/usr/include/linux/fs.h:11: included file 'linux/gfp.h' is not exported
> > make[3]: *** [/home/mingo/tip/usr/include/linux/.check] Error 1
> > make[2]: *** [linux] Error 2
> >
> > (CONFIG_HEADERS_CHECK)
>
> Hmm, I wonder what is the best way to fix this, though. I think we
> better use macros there (like rest of linux/fs.h) does because of
> dependency issues. What do you think?
>
> Pekka
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index add95da..4dda05d 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -8,7 +8,6 @@
>
> #include <linux/limits.h>
> #include <linux/ioctl.h>
> -#include <linux/gfp.h>
>
> /*
> * It's silly to have NR_OPEN bigger than NR_FILE, but you can change
> @@ -2233,15 +2232,8 @@ ssize_t simple_attr_write(struct file *file, const char __user *buf,
>
>
> #ifdef CONFIG_SECURITY
> -static inline char *alloc_secdata(void)
> -{
> - return (char *)get_zeroed_page(GFP_KERNEL);
> -}
> -
> -static inline void free_secdata(void *secdata)
> -{
> - free_page((unsigned long)secdata);
> -}
> +#define alloc_secdata() (char *)get_zeroed_page(GFP_KERNEL)
> +#define free_secdata() free_page((unsigned long) secdata)
yep, that would be fine - but please add a comment about why they
are macros and what would have to be done to fix it.
(the real fix would be to separate fs.h into fs_types.h and
fs_apis.h - like we did it with spinlock.h. Similarly with slab.h.)
Ingo
allyes is fine now. There's an allnoconfig failure:
init/built-in.o: In function `start_kernel':
(.init.text+0x669): undefined reference to `kmemtrace_init'
Ingo
64-bit defconfig:
In file included from include/linux/slub_def.h:14,
from include/linux/slab.h:154,
from include/linux/percpu.h:6,
from include/linux/rcutree.h:37,
from include/linux/rcupdate.h:61,
from include/linux/tracepoint.h:19,
from include/linux/module.h:20,
from include/linux/crypto.h:22,
from arch/x86/kernel/asm-offsets_64.c:8,
from arch/x86/kernel/asm-offsets.c:5:
include/trace/kmemtrace.h:24: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:31: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:38: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:46: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:54: error: expected ‘)’ before ‘(’ token
include/trace/kmemtrace.h:57: error: expected ‘)’ before ‘(’ token
In file included from include/linux/slab.h:154,
from include/linux/percpu.h:6,
from include/linux/rcutree.h:37,
from include/linux/rcupdate.h:61,
from include/linux/tracepoint.h:19,
from include/linux/module.h:20,
from include/linux/crypto.h:22,
from arch/x86/kernel/asm-offsets_64.c:8,
from arch/x86/kernel/asm-offsets.c:5:
include/linux/slub_def.h: In function ‘kmalloc_large’:
include/linux/slub_def.h:236: error: implicit declaration of function ‘trace_kmalloc’
include/linux/slub_def.h: In function ‘kmalloc_node’:
include/linux/slub_def.h:296: error: implicit declaration of function ‘trace_kmalloc_node’
3.65user 0.62system 0:02.86elapsed 149%CPU (0avgtext+0avgdata 0maxresident)k
On Tue, Mar 24, 2009 at 10:53:46AM +0100, Ingo Molnar wrote:
> > -static inline char *alloc_secdata(void)
> > -{
> > - return (char *)get_zeroed_page(GFP_KERNEL);
> > -}
> > -
> > -static inline void free_secdata(void *secdata)
> > -{
> > - free_page((unsigned long)secdata);
> > -}
> > +#define alloc_secdata() (char *)get_zeroed_page(GFP_KERNEL)
> > +#define free_secdata() free_page((unsigned long) secdata)
>
> yep, that would be fine - but please add a comment about why they
> are macros and what would have to be done to fix it.
Nooo!
Stick it into security.h!
> (the real fix would be to separate fs.h into fs_types.h and
> fs_apis.h - like we did it with spinlock.h. Similarly with slab.h.)
On Tue, 2009-03-24 at 16:09 +0300, Alexey Dobriyan wrote:
> On Tue, Mar 24, 2009 at 10:53:46AM +0100, Ingo Molnar wrote:
> > > -static inline char *alloc_secdata(void)
> > > -{
> > > - return (char *)get_zeroed_page(GFP_KERNEL);
> > > -}
> > > -
> > > -static inline void free_secdata(void *secdata)
> > > -{
> > > - free_page((unsigned long)secdata);
> > > -}
> > > +#define alloc_secdata() (char *)get_zeroed_page(GFP_KERNEL)
> > > +#define free_secdata() free_page((unsigned long) secdata)
> >
> > yep, that would be fine - but please add a comment about why they
> > are macros and what would have to be done to fix it.
>
> Nooo!
>
> Stick it into security.h!
Something like this untested patch?
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 11fdc57..159f7b8 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2230,24 +2230,6 @@ ssize_t simple_attr_read(struct file *file, char __user *buf,
ssize_t simple_attr_write(struct file *file, const char __user *buf,
size_t len, loff_t *ppos);
-
-#ifdef CONFIG_SECURITY
-/*
- * These need to be macros because we cannot include <linux/gfp.h> in this
- * header file.
- */
-#define alloc_secdata() (char *)get_zeroed_page(GFP_KERNEL)
-#define free_secdata(secdata) free_page((unsigned long) secdata)
-#else
-static inline char *alloc_secdata(void)
-{
- return (char *)1;
-}
-
-static inline void free_secdata(void *secdata)
-{ }
-#endif /* CONFIG_SECURITY */
-
struct ctl_table;
int proc_nr_files(struct ctl_table *table, int write, struct file *filp,
void __user *buffer, size_t *lenp, loff_t *ppos);
diff --git a/include/linux/security.h b/include/linux/security.h
index 1f2ab63..e3e2f8a 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -32,6 +32,7 @@
#include <linux/sched.h>
#include <linux/key.h>
#include <linux/xfrm.h>
+#include <linux/gfp.h>
#include <net/flow.h>
/* Maximum number of letters for an LSM name string */
@@ -2966,5 +2967,28 @@ static inline void securityfs_remove(struct dentry *dentry)
#endif
+#ifdef CONFIG_SECURITY
+
+static inline char *alloc_secdata(void)
+{
+ return (char *)get_zeroed_page(GFP_KERNEL);
+}
+
+static inline void free_secdata(void *secdata)
+{
+ free_page((unsigned long)secdata);
+}
+
+#else
+
+static inline char *alloc_secdata(void)
+{
+ return (char *)1;
+}
+
+static inline void free_secdata(void *secdata)
+{ }
+#endif /* CONFIG_SECURITY */
+
#endif /* ! __LINUX_SECURITY_H */
On Tue, Mar 24, 2009 at 11:15:13AM +0200, Pekka Enberg wrote:
> On Tue, 2009-03-24 at 10:07 +0100, Ingo Molnar wrote:
> > * Pekka Enberg <[email protected]> wrote:
> >
> > > On Tue, 2009-03-24 at 09:56 +0100, Ingo Molnar wrote:
> > > > * Pekka Enberg <[email protected]> wrote:
> > > >
> > > > > On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> > > > > > there's another build problem as well, in squashfs, and in key.h:
> > > > > >
> > > > > > include/linux/key.h:128: error: field 'sem' has incomplete type
> > > > > > fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> > > > > > fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
> > > > > >
> > > > > > And i suspect there's more as well. Is there really no unintrusive
> > > > > > way to solve this - or do you think the RCU change reduces the
> > > > > > include file spaghetti?
> > > > >
> > > > > I don't think there is and yes, I do think the RCU change cleans
> > > > > up things as well.
> > > >
> > > > Okay. Note, you'll have to test tip:tracing/kmemtrace explicitly as
> > > > i had to exclude it from tip:master due to test failures. Will put
> > > > it back in once fixes arrive :)
> > >
> > > That's what I am testing right now. It's just that I am working on
> > > an old laptop where building the kernel takes a looong time....
> > > :-)
> >
> > ok - let me help then.
> >
> > On (64-bit) allyesconfig there's 5 distinct build failures:
> >
> > include/linux/key.h:128: error: field ???sem??? has incomplete type
> > distcc[22541] ERROR: compile security/keys/sysctl.c on a/16 failed
> >
> > lib/decompress_bunzip2.c:636: error: implicit declaration of function ???kmalloc???
> > lib/decompress_bunzip2.c:726: error: implicit declaration of function ???kfree???
> >
> > In file included from include/keys/user-type.h:16,
> > from fs/cifs/cifs_spnego.c:25:
> > include/linux/key.h:128: error: field ???sem??? has incomplete type
> > distcc[3226] ERROR: compile fs/cifs/cifs_spnego.c on ph/16 failed
> >
> > lib/decompress_inflate.c:45: error: implicit declaration of function ???kmalloc???
> > lib/decompress_inflate.c:154: error: implicit declaration of function ???kfree???
> >
> > lib/decompress_unlzma.c:122: error: implicit declaration of function ???kfree???
> > lib/decompress_unlzma.c:551: error: implicit declaration of function ???kmalloc???
> >
> > You should be able to reproduce them (on 32-bit too) one by one via:
> >
> > make lib/decompress_unlzma.o
> >
> > etc. - without having to redo the full allyesconfig. (i'll redo that
> > after the fixes, to flush out remaining/dependent bugs)
>
> OK, I think all of them are now fixed. I haven't yet been able to
> complete a build so help is still appreciated. ;-)
>
> Pekka
Gosh, what have I done?! oO
As far as I can see (or I hope so), it isn't really my fault the
original authors didn't use headers in a semantically-consistent way.
Pekka, thanks a lot for helping with this.
Eduard
* Eduard - Gabriel Munteanu <[email protected]> wrote:
> On Tue, Mar 24, 2009 at 11:15:13AM +0200, Pekka Enberg wrote:
> > On Tue, 2009-03-24 at 10:07 +0100, Ingo Molnar wrote:
> > > * Pekka Enberg <[email protected]> wrote:
> > >
> > > > On Tue, 2009-03-24 at 09:56 +0100, Ingo Molnar wrote:
> > > > > * Pekka Enberg <[email protected]> wrote:
> > > > >
> > > > > > On Tue, 2009-03-24 at 09:51 +0100, Ingo Molnar wrote:
> > > > > > > there's another build problem as well, in squashfs, and in key.h:
> > > > > > >
> > > > > > > include/linux/key.h:128: error: field 'sem' has incomplete type
> > > > > > > fs/squashfs/export.c:133: error: implicit declaration of function 'kmalloc'
> > > > > > > fs/squashfs/export.c:143: error: implicit declaration of function 'kfree'
> > > > > > >
> > > > > > > And i suspect there's more as well. Is there really no unintrusive
> > > > > > > way to solve this - or do you think the RCU change reduces the
> > > > > > > include file spaghetti?
> > > > > >
> > > > > > I don't think there is and yes, I do think the RCU change cleans
> > > > > > up things as well.
> > > > >
> > > > > Okay. Note, you'll have to test tip:tracing/kmemtrace explicitly as
> > > > > i had to exclude it from tip:master due to test failures. Will put
> > > > > it back in once fixes arrive :)
> > > >
> > > > That's what I am testing right now. It's just that I am working on
> > > > an old laptop where building the kernel takes a looong time....
> > > > :-)
> > >
> > > ok - let me help then.
> > >
> > > On (64-bit) allyesconfig there's 5 distinct build failures:
> > >
> > > include/linux/key.h:128: error: field ???sem??? has incomplete type
> > > distcc[22541] ERROR: compile security/keys/sysctl.c on a/16 failed
> > >
> > > lib/decompress_bunzip2.c:636: error: implicit declaration of function ???kmalloc???
> > > lib/decompress_bunzip2.c:726: error: implicit declaration of function ???kfree???
> > >
> > > In file included from include/keys/user-type.h:16,
> > > from fs/cifs/cifs_spnego.c:25:
> > > include/linux/key.h:128: error: field ???sem??? has incomplete type
> > > distcc[3226] ERROR: compile fs/cifs/cifs_spnego.c on ph/16 failed
> > >
> > > lib/decompress_inflate.c:45: error: implicit declaration of function ???kmalloc???
> > > lib/decompress_inflate.c:154: error: implicit declaration of function ???kfree???
> > >
> > > lib/decompress_unlzma.c:122: error: implicit declaration of function ???kfree???
> > > lib/decompress_unlzma.c:551: error: implicit declaration of function ???kmalloc???
> > >
> > > You should be able to reproduce them (on 32-bit too) one by one via:
> > >
> > > make lib/decompress_unlzma.o
> > >
> > > etc. - without having to redo the full allyesconfig. (i'll redo that
> > > after the fixes, to flush out remaining/dependent bugs)
> >
> > OK, I think all of them are now fixed. I haven't yet been able to
> > complete a build so help is still appreciated. ;-)
> >
> > Pekka
>
> Gosh, what have I done?! oO
>
> As far as I can see (or I hope so), it isn't really my fault the
> original authors didn't use headers in a semantically-consistent
> way.
yeah.
> Pekka, thanks a lot for helping with this.
indeed. Now we need to repeat this for most other large headers we
have in include/linux/*.h. Going by 'ls -lS include/linux/*.h' would
be a good start. It gives:
-rw-rw-r-- 1 mingo mingo 111235 2009-03-24 20:19 include/linux/security.h
Oh. We just grew security.h. Go figure :-/
Ingo