Re: replace MAX_MAP_COUNT with /proc/sys/vm/max_map_count

From: Stephen Smalley
Date: Mon Mar 29 2004 - 08:52:16 EST

On Sat, 2004-03-27 at 01:17, Andrew Morton wrote:
> David Mosberger <davidm@xxxxxxxxxxxxxxxxx> wrote:
> >
> > Below is a warmed up version of a patch originally done by Werner
> > Almesberger (see 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@xxxxxxxxxxxxxx>
National Security Agency

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at