Messages in this thread | | | Subject | Re: replace MAX_MAP_COUNT with /proc/sys/vm/max_map_count | From | Stephen Smalley <> | Date | Mon, 29 Mar 2004 08:42:45 -0500 |
| |
On Sat, 2004-03-27 at 01:17, Andrew Morton wrote: > David Mosberger <davidm@napali.hpl.hp.com> wrote: > > > > Below is a warmed up version of a patch originally done by Werner > > Almesberger (see http://tinyurl.com/25zra) to replace the > > MAX_MAP_COUNT limit with a sysctl variable. > > Fair enough. > > > int sysctl_overcommit_memory = 0; /* default is heuristic overcommit */ > > int sysctl_overcommit_ratio = 50; /* default is 50% */ > > +int sysctl_max_map_count = DEFAULT_MAX_MAP_COUNT; > > atomic_t vm_committed_space = ATOMIC_INIT(0); > > > > EXPORT_SYMBOL(sysctl_overcommit_memory); > > EXPORT_SYMBOL(sysctl_overcommit_ratio); > > +EXPORT_SYMBOL(sysctl_max_map_count); > > EXPORT_SYMBOL(vm_committed_space); > > The SELinux guys may want to hook into this. I assume that's why these > symbols are exported to modules at present?
The symbols are exported to support the vm_enough_memory hook functions in the security modules. We had originally (in 2.5) only proposed replacing the CAP_SYS_ADMIN check in the old vm_enough_memory function with a security hook so that SELinux could handle it differently than other CAP_SYS_ADMIN checks (in particular, to avoid spuriously auditing CAP_SYS_ADMIN denials generated by the check), but Alan Cox had suggested moving the entire vm_enough_memory logic into the security modules to support future implementation of policies such as role-based commit constraints. Unless you envision introducing a different max_map_count for privileged processes, I'm not sure it is worthwhile to introduce a hook for the map_count check or to export this symbol to modules. I've cc'd the LSM maintainer as well to see if he has a different view.
-- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |