> userland could never rely on the kernel's policy at all since get_arg_page > could have failed for more reasons than overstepping the currently hardcoded > ARG_MAX check in there. I don't see how it could fail except for OOM cases where get_user_pages() failed rather than blocking. Is that what you mean? > so what AT_ARGMAX would buy us is to allow the kernel > policy to change over time, but it's never been about guarantees, whether > POSIX wants such a thing or not. I understand the motivation for an explicit mechanism for the kernel to tell userland its limit. Since the kernel policy today depends on something that can change between execs, AT_ARGMAX is inadequate for that purpose for today's policy, let alone any future different policy. > > The information that these give is about the conditions at startup. > > That's what they mean to userland, and userland only uses them to know > > the situation before it has made any calls. The definition of AT_EUID > > is "effective user ID at program startup", and that fact does not > > change. > > just for my own curiosity, where does this definition come from? You mean documentation? I'm not really sure if there is any for that. But it's the inherent definition of auxv that all its information can only be about the conditions at program startup. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
