Re: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 17:31:28 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Chris Wright wrote: > > Yes, and I think we can still improve performance although I can't > > see anyway to help out the modular case, so I guess it will have to > > incur the hit that's always been there. > > Broaden the paravirt patching machinery? > so far I've something much simpler in mind, I have a first prototype and it shows code that is pretty much optimal on modern cpus. I hope to have something postable in a week or so - 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: LSM conversion to static interface [revert patch]
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote: > Chris Wright wrote: > > Yes, and I think we can still improve performance although I can't see > > anyway to help out the modular case, so I guess it will have to incur > > the hit that's always been there. > > Broaden the paravirt patching machinery? Yup, that's essentially what we've been talking about. thanks, -chris - 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: LSM conversion to static interface [revert patch]
Chris Wright wrote: > Yes, and I think we can still improve performance although I can't see > anyway to help out the modular case, so I guess it will have to incur > the hit that's always been there. Broaden the paravirt patching machinery? J - 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: LSM conversion to static interface [revert patch]
On Oct 23 2007 02:13, Chris Wright wrote: >* Jan Engelhardt ([EMAIL PROTECTED]) wrote: >> On Oct 22 2007 22:16, Chris Wright wrote: >> >Yes, and I think we can still improve performance although I can't see >> >anyway to help out the modular case, so I guess it will have to incur >> >the hit that's always been there. I think your Kconfig option is a >> >decent compromise. >> >> (Un)registering security modules is a one-time hit. You do not load >> and unload modules on a per-minute basis outside debugging. > >I'm referring to the hit for indirect calls Indeed, I just seen that. Not too nice :( - 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: LSM conversion to static interface [revert patch]
* Jan Engelhardt ([EMAIL PROTECTED]) wrote: > On Oct 22 2007 22:16, Chris Wright wrote: > >Yes, and I think we can still improve performance although I can't see > >anyway to help out the modular case, so I guess it will have to incur > >the hit that's always been there. I think your Kconfig option is a > >decent compromise. > > (Un)registering security modules is a one-time hit. You do not load > and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls - 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: LSM conversion to static interface [revert patch]
On Oct 22 2007 22:16, Chris Wright wrote: >> >> If it turns out that the above module becomes unmaintained and no >> longer usable, and no other useful cases show up, we can always >> garbage collect this code in the future; it's now low-overhead >> anyway for those who care, due to the KConfig option. > >Yes, and I think we can still improve performance although I can't see >anyway to help out the modular case, so I guess it will have to incur >the hit that's always been there. I think your Kconfig option is a >decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. - 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: LSM conversion to static interface [revert patch]
On Oct 22 2007 22:16, Chris Wright wrote: If it turns out that the above module becomes unmaintained and no longer usable, and no other useful cases show up, we can always garbage collect this code in the future; it's now low-overhead anyway for those who care, due to the KConfig option. Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. - 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: LSM conversion to static interface [revert patch]
* Jan Engelhardt ([EMAIL PROTECTED]) wrote: On Oct 22 2007 22:16, Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls - 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: LSM conversion to static interface [revert patch]
On Oct 23 2007 02:13, Chris Wright wrote: * Jan Engelhardt ([EMAIL PROTECTED]) wrote: On Oct 22 2007 22:16, Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls Indeed, I just seen that. Not too nice :( - 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: LSM conversion to static interface [revert patch]
Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. Broaden the paravirt patching machinery? J - 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: LSM conversion to static interface [revert patch]
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote: Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. Broaden the paravirt patching machinery? Yup, that's essentially what we've been talking about. thanks, -chris - 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 17:31:28 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. Broaden the paravirt patching machinery? so far I've something much simpler in mind, I have a first prototype and it shows code that is pretty much optimal on modern cpus. I hope to have something postable in a week or so - 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: LSM conversion to static interface [revert patch]
* Arjan van de Ven ([EMAIL PROTECTED]) wrote: > On Sun, 21 Oct 2007 08:57:06 +1000 (EST) > James Morris <[EMAIL PROTECTED]> wrote: > > > On Sat, 20 Oct 2007, Jan Engelhardt wrote: > > > > > >I'd like to note that I asked people who were actually affected, > > > >and had examples of their real-world use to step forward and > > > >explain their use, and that I explicitly mentioned that this is > > > >something we can easily re-visit. > > > > > > > > > > I do have a pseudo LSM called "multiadm" at > > > http://freshmeat.net/p/multiadm/ , quoting: > > > > > > > Based on Linus' criteria, this appears to be a case for reverting the > > static LSM patch. > > I don't want to argue for or against the actual revert; however if > Linus/James/Chris > decide to do a revert, I've made a patch to do that below Thanks Arjan. I did not actually oppose making it non-modular, and thought there was sufficient time for people to complain meaningfully on that change. I also think there's not a lot of value in the modular interface, but it's very difficult to have rational discussions in this area. > (doing a full git revert is tricky since it gets mixed up with various other > cleanup > patches; even inside the original patch. I've done the relevant pieces by > hand via a > selective patch -R and compile-tested it). In addition I've made the > modularity a > Kconfig option, since it's clearly something that is contested and thus is > justified > as a user compile time choice; people who don't want this (out of paranoia or > otherwise) > can now decide to disable, while others who want to experiment or use out of > tree > LSM modules, can select the KConfig option. > > If it turns out that the above module becomes unmaintained and no longer > usable, and no > other useful cases show up, we can always garbage collect this code in the > future; it's > now low-overhead anyway for those who care, due to the KConfig option. Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. thanks, -chris - 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 14:56:52 +1000 (EST) James Morris <[EMAIL PROTECTED]> wrote: > On Mon, 22 Oct 2007, Arjan van de Ven wrote: > > > @@ -4895,6 +4908,7 @@ static struct security_operations selinu > > .sem_semop =selinux_sem_semop, > > > > .register_security = > > selinux_register_security, > > + .unregister_security = > > selinux_unregister_security, > > .d_instantiate =selinux_d_instantiate, > > You also need to consider whether to allow capabilities to be built > as an unloadable module. If not, then we don't need this hook added > back into SELinux. Otherwise, if it is desired, you also need to > reinstate capability_exit and general modular bits for > security/capability.c. > this just allows 3d party replacements of capability like functions; there is no need/point to have the existing capability back as modular to be honest. - 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: LSM conversion to static interface [revert patch]
On Mon, 22 Oct 2007, Arjan van de Ven wrote: > @@ -4895,6 +4908,7 @@ static struct security_operations selinu > .sem_semop =selinux_sem_semop, > > .register_security =selinux_register_security, > + .unregister_security = selinux_unregister_security, > > .d_instantiate =selinux_d_instantiate, You also need to consider whether to allow capabilities to be built as an unloadable module. If not, then we don't need this hook added back into SELinux. Otherwise, if it is desired, you also need to reinstate capability_exit and general modular bits for security/capability.c. - 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: LSM conversion to static interface [revert patch]
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris <[EMAIL PROTECTED]> wrote:
> On Sat, 20 Oct 2007, Jan Engelhardt wrote:
>
> > >I'd like to note that I asked people who were actually affected,
> > >and had examples of their real-world use to step forward and
> > >explain their use, and that I explicitly mentioned that this is
> > >something we can easily re-visit.
> > >
> >
> > I do have a pseudo LSM called "multiadm" at
> > http://freshmeat.net/p/multiadm/ , quoting:
> >
>
> Based on Linus' criteria, this appears to be a case for reverting the
> static LSM patch.
I don't want to argue for or against the actual revert; however if
Linus/James/Chris
decide to do a revert, I've made a patch to do that below
(doing a full git revert is tricky since it gets mixed up with various other
cleanup
patches; even inside the original patch. I've done the relevant pieces by hand
via a
selective patch -R and compile-tested it). In addition I've made the modularity
a
Kconfig option, since it's clearly something that is contested and thus is
justified
as a user compile time choice; people who don't want this (out of paranoia or
otherwise)
can now decide to disable, while others who want to experiment or use out of
tree
LSM modules, can select the KConfig option.
If it turns out that the above module becomes unmaintained and no longer
usable, and no
other useful cases show up, we can always garbage collect this code in the
future; it's
now low-overhead anyway for those who care, due to the KConfig option.
---
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: revert the modular LSM patch
Since there is a real out of tree, non-racey modular LSM module,
add back the capability to have modular LSM modules as a config option.
(note that this patch fails checkpatch.pl in a few places, however
since this is just a reverse-patch of the original code, I don't
want to fix this in order to keep exact revert behavior)
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
diff -purN linux-2.6.23-git17/include/linux.org/security.h
linux-2.6.23-git17/include/linux/security.h
--- linux-2.6.23-git17/include/linux.org/security.h 2007-10-21
10:35:49.0 +0200
+++ linux-2.6.23-git17/include/linux/security.h 2007-10-21 10:36:00.0
+0200
@@ -1178,6 +1178,10 @@ struct request_sock;
* allow module stacking.
* @name contains the name of the security module being stacked.
* @ops contains a pointer to the struct security_operations of the module
to stack.
+ * @unregister_security:
+ * remove a stacked module.
+ * @name contains the name of the security module being unstacked.
+ * @ops contains a pointer to the struct security_operations of the module
to unstack.
*
* @secid_to_secctx:
* Convert secid to security context.
@@ -1365,6 +1369,8 @@ struct security_operations {
/* allow module stacking */
int (*register_security) (const char *name,
struct security_operations *ops);
+ int (*unregister_security) (const char *name,
+ struct security_operations *ops);
void (*d_instantiate) (struct dentry *dentry, struct inode *inode);
@@ -1445,7 +1451,9 @@ struct security_operations {
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
+extern int unregister_security (struct security_operations *ops);
extern int mod_reg_security(const char *name, struct security_operations
*ops);
+extern int mod_unreg_security (const char *name, struct security_operations
*ops);
extern struct dentry *securityfs_create_file(const char *name, mode_t mode,
struct dentry *parent, void *data,
const struct file_operations
*fops);
diff -purN linux-2.6.23-git17/security.org/dummy.c
linux-2.6.23-git17/security/dummy.c
--- linux-2.6.23-git17/security.org/dummy.c 2007-10-21 02:04:21.0
+0200
+++ linux-2.6.23-git17/security/dummy.c 2007-10-21 10:36:00.0 +0200
@@ -908,6 +908,11 @@ static int dummy_register_security (cons
return -EINVAL;
}
+static int dummy_unregister_security (const char *name, struct
security_operations *ops)
+{
+ return -EINVAL;
+}
+
static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode)
{
return;
@@ -1082,6 +1087,7 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, netlink_send);
set_to_dummy_if_null(ops, netlink_recv);
set_to_dummy_if_null(ops, register_security);
+ set_to_dummy_if_null(ops, unregister_security);
set_to_dummy_if_null(ops, d_instantiate);
set_to_dummy_if_null(ops, getprocattr);
set_to_dummy_if_null(ops, setprocattr);
diff -purN linux-2.6.23-git17/security.org/Kconfig
linux-2.6.23-git17/security/Kconfig
---
Re: LSM conversion to static interface [revert patch]
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris [EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
I'd like to note that I asked people who were actually affected,
and had examples of their real-world use to step forward and
explain their use, and that I explicitly mentioned that this is
something we can easily re-visit.
I do have a pseudo LSM called multiadm at
http://freshmeat.net/p/multiadm/ , quoting:
Based on Linus' criteria, this appears to be a case for reverting the
static LSM patch.
I don't want to argue for or against the actual revert; however if
Linus/James/Chris
decide to do a revert, I've made a patch to do that below
(doing a full git revert is tricky since it gets mixed up with various other
cleanup
patches; even inside the original patch. I've done the relevant pieces by hand
via a
selective patch -R and compile-tested it). In addition I've made the modularity
a
Kconfig option, since it's clearly something that is contested and thus is
justified
as a user compile time choice; people who don't want this (out of paranoia or
otherwise)
can now decide to disable, while others who want to experiment or use out of
tree
LSM modules, can select the KConfig option.
If it turns out that the above module becomes unmaintained and no longer
usable, and no
other useful cases show up, we can always garbage collect this code in the
future; it's
now low-overhead anyway for those who care, due to the KConfig option.
---
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: revert the modular LSM patch
Since there is a real out of tree, non-racey modular LSM module,
add back the capability to have modular LSM modules as a config option.
(note that this patch fails checkpatch.pl in a few places, however
since this is just a reverse-patch of the original code, I don't
want to fix this in order to keep exact revert behavior)
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
diff -purN linux-2.6.23-git17/include/linux.org/security.h
linux-2.6.23-git17/include/linux/security.h
--- linux-2.6.23-git17/include/linux.org/security.h 2007-10-21
10:35:49.0 +0200
+++ linux-2.6.23-git17/include/linux/security.h 2007-10-21 10:36:00.0
+0200
@@ -1178,6 +1178,10 @@ struct request_sock;
* allow module stacking.
* @name contains the name of the security module being stacked.
* @ops contains a pointer to the struct security_operations of the module
to stack.
+ * @unregister_security:
+ * remove a stacked module.
+ * @name contains the name of the security module being unstacked.
+ * @ops contains a pointer to the struct security_operations of the module
to unstack.
*
* @secid_to_secctx:
* Convert secid to security context.
@@ -1365,6 +1369,8 @@ struct security_operations {
/* allow module stacking */
int (*register_security) (const char *name,
struct security_operations *ops);
+ int (*unregister_security) (const char *name,
+ struct security_operations *ops);
void (*d_instantiate) (struct dentry *dentry, struct inode *inode);
@@ -1445,7 +1451,9 @@ struct security_operations {
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
+extern int unregister_security (struct security_operations *ops);
extern int mod_reg_security(const char *name, struct security_operations
*ops);
+extern int mod_unreg_security (const char *name, struct security_operations
*ops);
extern struct dentry *securityfs_create_file(const char *name, mode_t mode,
struct dentry *parent, void *data,
const struct file_operations
*fops);
diff -purN linux-2.6.23-git17/security.org/dummy.c
linux-2.6.23-git17/security/dummy.c
--- linux-2.6.23-git17/security.org/dummy.c 2007-10-21 02:04:21.0
+0200
+++ linux-2.6.23-git17/security/dummy.c 2007-10-21 10:36:00.0 +0200
@@ -908,6 +908,11 @@ static int dummy_register_security (cons
return -EINVAL;
}
+static int dummy_unregister_security (const char *name, struct
security_operations *ops)
+{
+ return -EINVAL;
+}
+
static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode)
{
return;
@@ -1082,6 +1087,7 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, netlink_send);
set_to_dummy_if_null(ops, netlink_recv);
set_to_dummy_if_null(ops, register_security);
+ set_to_dummy_if_null(ops, unregister_security);
set_to_dummy_if_null(ops, d_instantiate);
set_to_dummy_if_null(ops, getprocattr);
set_to_dummy_if_null(ops, setprocattr);
diff -purN linux-2.6.23-git17/security.org/Kconfig
linux-2.6.23-git17/security/Kconfig
--- linux-2.6.23-git17/security.org/Kconfig 2007-10-21 02:04:21.0
Re: LSM conversion to static interface [revert patch]
On Mon, 22 Oct 2007, Arjan van de Ven wrote: @@ -4895,6 +4908,7 @@ static struct security_operations selinu .sem_semop =selinux_sem_semop, .register_security =selinux_register_security, + .unregister_security = selinux_unregister_security, .d_instantiate =selinux_d_instantiate, You also need to consider whether to allow capabilities to be built as an unloadable module. If not, then we don't need this hook added back into SELinux. Otherwise, if it is desired, you also need to reinstate capability_exit and general modular bits for security/capability.c. - 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 14:56:52 +1000 (EST) James Morris [EMAIL PROTECTED] wrote: On Mon, 22 Oct 2007, Arjan van de Ven wrote: @@ -4895,6 +4908,7 @@ static struct security_operations selinu .sem_semop =selinux_sem_semop, .register_security = selinux_register_security, + .unregister_security = selinux_unregister_security, .d_instantiate =selinux_d_instantiate, You also need to consider whether to allow capabilities to be built as an unloadable module. If not, then we don't need this hook added back into SELinux. Otherwise, if it is desired, you also need to reinstate capability_exit and general modular bits for security/capability.c. this just allows 3d party replacements of capability like functions; there is no need/point to have the existing capability back as modular to be honest. - 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: LSM conversion to static interface [revert patch]
* Arjan van de Ven ([EMAIL PROTECTED]) wrote: On Sun, 21 Oct 2007 08:57:06 +1000 (EST) James Morris [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Jan Engelhardt wrote: I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. I don't want to argue for or against the actual revert; however if Linus/James/Chris decide to do a revert, I've made a patch to do that below Thanks Arjan. I did not actually oppose making it non-modular, and thought there was sufficient time for people to complain meaningfully on that change. I also think there's not a lot of value in the modular interface, but it's very difficult to have rational discussions in this area. (doing a full git revert is tricky since it gets mixed up with various other cleanup patches; even inside the original patch. I've done the relevant pieces by hand via a selective patch -R and compile-tested it). In addition I've made the modularity a Kconfig option, since it's clearly something that is contested and thus is justified as a user compile time choice; people who don't want this (out of paranoia or otherwise) can now decide to disable, while others who want to experiment or use out of tree LSM modules, can select the KConfig option. If it turns out that the above module becomes unmaintained and no longer usable, and no other useful cases show up, we can always garbage collect this code in the future; it's now low-overhead anyway for those who care, due to the KConfig option. Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. thanks, -chris - 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/
