Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
James Morris <[EMAIL PROTECTED]> wrote: > I suspect it may be useful ensure all global identifiers for the key > subsystem are prefixed with key_, as 'copy_keys' does seem a little > generic. Many of the fork helpers are called copy_xxx(). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
James Morris [EMAIL PROTECTED] wrote: I suspect it may be useful ensure all global identifiers for the key subsystem are prefixed with key_, as 'copy_keys' does seem a little generic. Many of the fork helpers are called copy_xxx(). David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Tue, 25 Dec 2007, Andrew Morton wrote: > On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris <[EMAIL PROTECTED]> > wrote: > > > > > +#ifdef CONFIG_SECURITY > > > > +extern unsigned long mmap_min_addr; > > > > +#endif > > > > + > > > > #include > > > > #include > > > > #include > > > > > > Fine by me. > > > > I'll queue it for -mm & 2.6.25. > > I don't think we need the ifdef. If someone incorrectly refers to this > then they'll get a link-time error rather than a compile-time error (bad). > But we lose an ifdef (good). Done, & rebased the git branch. - James -- James Morris <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris <[EMAIL PROTECTED]> wrote: > > > +#ifdef CONFIG_SECURITY > > > +extern unsigned long mmap_min_addr; > > > +#endif > > > + > > > #include > > > #include > > > #include > > > > Fine by me. > > I'll queue it for -mm & 2.6.25. I don't think we need the ifdef. If someone incorrectly refers to this then they'll get a link-time error rather than a compile-time error (bad). But we lose an ifdef (good). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris [EMAIL PROTECTED] wrote: +#ifdef CONFIG_SECURITY +extern unsigned long mmap_min_addr; +#endif + #include asm/page.h #include asm/pgtable.h #include asm/processor.h Fine by me. I'll queue it for -mm 2.6.25. I don't think we need the ifdef. If someone incorrectly refers to this then they'll get a link-time error rather than a compile-time error (bad). But we lose an ifdef (good). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Tue, 25 Dec 2007, Andrew Morton wrote: On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris [EMAIL PROTECTED] wrote: +#ifdef CONFIG_SECURITY +extern unsigned long mmap_min_addr; +#endif + #include asm/page.h #include asm/pgtable.h #include asm/processor.h Fine by me. I'll queue it for -mm 2.6.25. I don't think we need the ifdef. If someone incorrectly refers to this then they'll get a link-time error rather than a compile-time error (bad). But we lose an ifdef (good). Done, rebased the git branch. - James -- James Morris [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, 2007-12-20 at 11:07 +1100, James Morris wrote: > On Wed, 19 Dec 2007, David Chinner wrote: > > > Folks, > > > > I just updated a git tree and started getting errors on a > > "copy_keys" macro warning. > > > > The code I've been working on uses a ->copy_keys() method for > > copying the keys in a btree block from one place to another. I've > > been working on this code for a while > > (http://oss.sgi.com/archives/xfs/2007-11/msg00046.html) and keep the > > tree I'm working in reletively up to date (lags linus by a couple of > > weeks at most). The update I did this afternoon gave a conflict > > warning with the macro in include/linux/key.h. > > > > Given that I'm not directly including key.h anywhere in the XFS > > code, I'm getting the namespace polluted indirectly from some other > > include that is necessary. > > > > As it turns out, this commit from 13 days ago: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b > > > > included security.h in mm.h and that is how I'm seeing the namespace > > poisoning coming from key.h when !CONFIG_KEY. > > > > Including security.h in mm.h means much wider includes for pretty > > much the entire kernel, and it opens up namespace issues like this > > that never previously existed. > > > > The patch below (only tested for !CONFIG_KEYS && !CONFIG_SECURITY) > > moves security.h into the mmap.c and nommu.c files that need it so > > it doesn't end up with kernel wide scope. > > > > Comments? > > The idea with this placement was to keep memory management code with other > similar code, rather than pushing it into security.h, where it does not > functionally belong. > > Something to not also is that you can't "depend" on security.h not being > included all over the place, as LSM does touch a lot of the kernel. > Unecessarily including it is bad, of course. > > I'm not sure I understand your namespace pollution issue, either. > > In any case, I think the right solution is not to include security.h at > all in mm.h, as it is only being done to get a declaration for > mmap_min_addr. > > How about this, instead ? > > Signed-off-by: James Morris <[EMAIL PROTECTED]> Acked-by: Eric Paris <[EMAIL PROTECTED]> > --- > > mm.h |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 1b7b95c..02fbac7 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -12,7 +12,6 @@ > #include > #include > #include > -#include > > struct mempolicy; > struct anon_vma; > @@ -34,6 +33,10 @@ extern int sysctl_legacy_va_layout; > #define sysctl_legacy_va_layout 0 > #endif > > +#ifdef CONFIG_SECURITY > +extern unsigned long mmap_min_addr; > +#endif > + > #include > #include > #include > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, 2007-12-20 at 11:07 +1100, James Morris wrote: On Wed, 19 Dec 2007, David Chinner wrote: Folks, I just updated a git tree and started getting errors on a copy_keys macro warning. The code I've been working on uses a -copy_keys() method for copying the keys in a btree block from one place to another. I've been working on this code for a while (http://oss.sgi.com/archives/xfs/2007-11/msg00046.html) and keep the tree I'm working in reletively up to date (lags linus by a couple of weeks at most). The update I did this afternoon gave a conflict warning with the macro in include/linux/key.h. Given that I'm not directly including key.h anywhere in the XFS code, I'm getting the namespace polluted indirectly from some other include that is necessary. As it turns out, this commit from 13 days ago: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b included security.h in mm.h and that is how I'm seeing the namespace poisoning coming from key.h when !CONFIG_KEY. Including security.h in mm.h means much wider includes for pretty much the entire kernel, and it opens up namespace issues like this that never previously existed. The patch below (only tested for !CONFIG_KEYS !CONFIG_SECURITY) moves security.h into the mmap.c and nommu.c files that need it so it doesn't end up with kernel wide scope. Comments? The idea with this placement was to keep memory management code with other similar code, rather than pushing it into security.h, where it does not functionally belong. Something to not also is that you can't depend on security.h not being included all over the place, as LSM does touch a lot of the kernel. Unecessarily including it is bad, of course. I'm not sure I understand your namespace pollution issue, either. In any case, I think the right solution is not to include security.h at all in mm.h, as it is only being done to get a declaration for mmap_min_addr. How about this, instead ? Signed-off-by: James Morris [EMAIL PROTECTED] Acked-by: Eric Paris [EMAIL PROTECTED] --- mm.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 1b7b95c..02fbac7 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -12,7 +12,6 @@ #include linux/prio_tree.h #include linux/debug_locks.h #include linux/mm_types.h -#include linux/security.h struct mempolicy; struct anon_vma; @@ -34,6 +33,10 @@ extern int sysctl_legacy_va_layout; #define sysctl_legacy_va_layout 0 #endif +#ifdef CONFIG_SECURITY +extern unsigned long mmap_min_addr; +#endif + #include asm/page.h #include asm/pgtable.h #include asm/processor.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, 20 Dec 2007, David Chinner wrote: > > I'm not sure I understand your namespace pollution issue, either. > > doing this globally: > > #ifdef CONFIG_SOMETHING > extern intsome_common_name(int a, int b, int c); > #else > #define some_common_name(a,b,c) 0 > #endif I suspect it may be useful ensure all global identifiers for the key subsystem are prefixed with key_, as 'copy_keys' does seem a little generic. > > +#ifdef CONFIG_SECURITY > > +extern unsigned long mmap_min_addr; > > +#endif > > + > > #include > > #include > > #include > > Fine by me. I'll queue it for -mm & 2.6.25. - James -- James Morris <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, Dec 20, 2007 at 11:07:01AM +1100, James Morris wrote: > On Wed, 19 Dec 2007, David Chinner wrote: > > > Folks, > > > > I just updated a git tree and started getting errors on a > > "copy_keys" macro warning. > > > > The code I've been working on uses a ->copy_keys() method for > > copying the keys in a btree block from one place to another. I've > > been working on this code for a while > > (http://oss.sgi.com/archives/xfs/2007-11/msg00046.html) and keep the > > tree I'm working in reletively up to date (lags linus by a couple of > > weeks at most). The update I did this afternoon gave a conflict > > warning with the macro in include/linux/key.h. > > > > Given that I'm not directly including key.h anywhere in the XFS > > code, I'm getting the namespace polluted indirectly from some other > > include that is necessary. > > > > As it turns out, this commit from 13 days ago: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b > > > > included security.h in mm.h and that is how I'm seeing the namespace > > poisoning coming from key.h when !CONFIG_KEY. > > > > Including security.h in mm.h means much wider includes for pretty > > much the entire kernel, and it opens up namespace issues like this > > that never previously existed. > > > > The patch below (only tested for !CONFIG_KEYS && !CONFIG_SECURITY) > > moves security.h into the mmap.c and nommu.c files that need it so > > it doesn't end up with kernel wide scope. > > > > Comments? > > The idea with this placement was to keep memory management code with other > similar code, rather than pushing it into security.h, where it does not > functionally belong. > > Something to not also is that you can't "depend" on security.h not being > included all over the place, as LSM does touch a lot of the kernel. > Unecessarily including it is bad, of course. Which is what including it in mm.h does. It also pull sin a lot of other headers files as has already been noted. > I'm not sure I understand your namespace pollution issue, either. doing this globally: #ifdef CONFIG_SOMETHING extern int some_common_name(int a, int b, int c); #else #define some_common_name(a,b,c) 0 #endif means that no-one can use some_common_name *anywhere* in the kernel. In this case, i have a completely *private* use of some_common_name and now I can't use that because the wonderful define above that now has effectively global scope because it gets included from key.h via security.h via mm.h. > In any case, I think the right solution is not to include security.h at > all in mm.h, as it is only being done to get a declaration for > mmap_min_addr. > > How about this, instead ? > > Signed-off-by: James Morris <[EMAIL PROTECTED]> > --- > > mm.h |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 1b7b95c..02fbac7 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -12,7 +12,6 @@ > #include > #include > #include > -#include > > struct mempolicy; > struct anon_vma; > @@ -34,6 +33,10 @@ extern int sysctl_legacy_va_layout; > #define sysctl_legacy_va_layout 0 > #endif > > +#ifdef CONFIG_SECURITY > +extern unsigned long mmap_min_addr; > +#endif > + > #include > #include > #include Fine by me. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Wed, 19 Dec 2007, David Chinner wrote: > Folks, > > I just updated a git tree and started getting errors on a > "copy_keys" macro warning. > > The code I've been working on uses a ->copy_keys() method for > copying the keys in a btree block from one place to another. I've > been working on this code for a while > (http://oss.sgi.com/archives/xfs/2007-11/msg00046.html) and keep the > tree I'm working in reletively up to date (lags linus by a couple of > weeks at most). The update I did this afternoon gave a conflict > warning with the macro in include/linux/key.h. > > Given that I'm not directly including key.h anywhere in the XFS > code, I'm getting the namespace polluted indirectly from some other > include that is necessary. > > As it turns out, this commit from 13 days ago: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b > > included security.h in mm.h and that is how I'm seeing the namespace > poisoning coming from key.h when !CONFIG_KEY. > > Including security.h in mm.h means much wider includes for pretty > much the entire kernel, and it opens up namespace issues like this > that never previously existed. > > The patch below (only tested for !CONFIG_KEYS && !CONFIG_SECURITY) > moves security.h into the mmap.c and nommu.c files that need it so > it doesn't end up with kernel wide scope. > > Comments? The idea with this placement was to keep memory management code with other similar code, rather than pushing it into security.h, where it does not functionally belong. Something to not also is that you can't "depend" on security.h not being included all over the place, as LSM does touch a lot of the kernel. Unecessarily including it is bad, of course. I'm not sure I understand your namespace pollution issue, either. In any case, I think the right solution is not to include security.h at all in mm.h, as it is only being done to get a declaration for mmap_min_addr. How about this, instead ? Signed-off-by: James Morris <[EMAIL PROTECTED]> --- mm.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 1b7b95c..02fbac7 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -12,7 +12,6 @@ #include #include #include -#include struct mempolicy; struct anon_vma; @@ -34,6 +33,10 @@ extern int sysctl_legacy_va_layout; #define sysctl_legacy_va_layout 0 #endif +#ifdef CONFIG_SECURITY +extern unsigned long mmap_min_addr; +#endif + #include #include #include -- James Morris <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On 12/19/07, David Chinner <[EMAIL PROTECTED]> wrote: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b > > included security.h in mm.h and that is how I'm seeing the namespace > poisoning coming from key.h when !CONFIG_KEY. > > Including security.h in mm.h means much wider includes for pretty > much the entire kernel, and it opens up namespace issues like this > that never previously existed. ACK, removing sched.h from mm.h was quite painful and security.h added it back unconditionally. As result, standalone mm.h inclusion goes from ~9K to ~16K of code after preprocessing which is quite unpleasant. > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -12,7 +12,6 @@ > #include > #include > #include > -#include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On 12/19/07, David Chinner [EMAIL PROTECTED] wrote: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b included security.h in mm.h and that is how I'm seeing the namespace poisoning coming from key.h when !CONFIG_KEY. Including security.h in mm.h means much wider includes for pretty much the entire kernel, and it opens up namespace issues like this that never previously existed. ACK, removing sched.h from mm.h was quite painful and security.h added it back unconditionally. As result, standalone mm.h inclusion goes from ~9K to ~16K of code after preprocessing which is quite unpleasant. --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -12,7 +12,6 @@ #include linux/prio_tree.h #include linux/debug_locks.h #include linux/mm_types.h -#include linux/security.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Wed, 19 Dec 2007, David Chinner wrote: Folks, I just updated a git tree and started getting errors on a copy_keys macro warning. The code I've been working on uses a -copy_keys() method for copying the keys in a btree block from one place to another. I've been working on this code for a while (http://oss.sgi.com/archives/xfs/2007-11/msg00046.html) and keep the tree I'm working in reletively up to date (lags linus by a couple of weeks at most). The update I did this afternoon gave a conflict warning with the macro in include/linux/key.h. Given that I'm not directly including key.h anywhere in the XFS code, I'm getting the namespace polluted indirectly from some other include that is necessary. As it turns out, this commit from 13 days ago: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b included security.h in mm.h and that is how I'm seeing the namespace poisoning coming from key.h when !CONFIG_KEY. Including security.h in mm.h means much wider includes for pretty much the entire kernel, and it opens up namespace issues like this that never previously existed. The patch below (only tested for !CONFIG_KEYS !CONFIG_SECURITY) moves security.h into the mmap.c and nommu.c files that need it so it doesn't end up with kernel wide scope. Comments? The idea with this placement was to keep memory management code with other similar code, rather than pushing it into security.h, where it does not functionally belong. Something to not also is that you can't depend on security.h not being included all over the place, as LSM does touch a lot of the kernel. Unecessarily including it is bad, of course. I'm not sure I understand your namespace pollution issue, either. In any case, I think the right solution is not to include security.h at all in mm.h, as it is only being done to get a declaration for mmap_min_addr. How about this, instead ? Signed-off-by: James Morris [EMAIL PROTECTED] --- mm.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 1b7b95c..02fbac7 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -12,7 +12,6 @@ #include linux/prio_tree.h #include linux/debug_locks.h #include linux/mm_types.h -#include linux/security.h struct mempolicy; struct anon_vma; @@ -34,6 +33,10 @@ extern int sysctl_legacy_va_layout; #define sysctl_legacy_va_layout 0 #endif +#ifdef CONFIG_SECURITY +extern unsigned long mmap_min_addr; +#endif + #include asm/page.h #include asm/pgtable.h #include asm/processor.h -- James Morris [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, Dec 20, 2007 at 11:07:01AM +1100, James Morris wrote: On Wed, 19 Dec 2007, David Chinner wrote: Folks, I just updated a git tree and started getting errors on a copy_keys macro warning. The code I've been working on uses a -copy_keys() method for copying the keys in a btree block from one place to another. I've been working on this code for a while (http://oss.sgi.com/archives/xfs/2007-11/msg00046.html) and keep the tree I'm working in reletively up to date (lags linus by a couple of weeks at most). The update I did this afternoon gave a conflict warning with the macro in include/linux/key.h. Given that I'm not directly including key.h anywhere in the XFS code, I'm getting the namespace polluted indirectly from some other include that is necessary. As it turns out, this commit from 13 days ago: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b included security.h in mm.h and that is how I'm seeing the namespace poisoning coming from key.h when !CONFIG_KEY. Including security.h in mm.h means much wider includes for pretty much the entire kernel, and it opens up namespace issues like this that never previously existed. The patch below (only tested for !CONFIG_KEYS !CONFIG_SECURITY) moves security.h into the mmap.c and nommu.c files that need it so it doesn't end up with kernel wide scope. Comments? The idea with this placement was to keep memory management code with other similar code, rather than pushing it into security.h, where it does not functionally belong. Something to not also is that you can't depend on security.h not being included all over the place, as LSM does touch a lot of the kernel. Unecessarily including it is bad, of course. Which is what including it in mm.h does. It also pull sin a lot of other headers files as has already been noted. I'm not sure I understand your namespace pollution issue, either. doing this globally: #ifdef CONFIG_SOMETHING extern int some_common_name(int a, int b, int c); #else #define some_common_name(a,b,c) 0 #endif means that no-one can use some_common_name *anywhere* in the kernel. In this case, i have a completely *private* use of some_common_name and now I can't use that because the wonderful define above that now has effectively global scope because it gets included from key.h via security.h via mm.h. In any case, I think the right solution is not to include security.h at all in mm.h, as it is only being done to get a declaration for mmap_min_addr. How about this, instead ? Signed-off-by: James Morris [EMAIL PROTECTED] --- mm.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 1b7b95c..02fbac7 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -12,7 +12,6 @@ #include linux/prio_tree.h #include linux/debug_locks.h #include linux/mm_types.h -#include linux/security.h struct mempolicy; struct anon_vma; @@ -34,6 +33,10 @@ extern int sysctl_legacy_va_layout; #define sysctl_legacy_va_layout 0 #endif +#ifdef CONFIG_SECURITY +extern unsigned long mmap_min_addr; +#endif + #include asm/page.h #include asm/pgtable.h #include asm/processor.h Fine by me. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
On Thu, 20 Dec 2007, David Chinner wrote: I'm not sure I understand your namespace pollution issue, either. doing this globally: #ifdef CONFIG_SOMETHING extern intsome_common_name(int a, int b, int c); #else #define some_common_name(a,b,c) 0 #endif I suspect it may be useful ensure all global identifiers for the key subsystem are prefixed with key_, as 'copy_keys' does seem a little generic. +#ifdef CONFIG_SECURITY +extern unsigned long mmap_min_addr; +#endif + #include asm/page.h #include asm/pgtable.h #include asm/processor.h Fine by me. I'll queue it for -mm 2.6.25. - James -- James Morris [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
