lkml.org 
[lkml]   [2011]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: A Plumber’ s Wish List for Linux
    On Fri, 07.10.11 03:57, Andi Kleen (andi@firstfloor.org) wrote:

    >
    > > Well, I am aware of PR_SET_NAME, but that modifies comm, not argv[]. And
    > > while "top" indeed shows the former, "ps" shows the latter. We are looking
    > > for a way to nice way to modify argv[] without having to reuse space
    > > from environ[] like most current Linux implementations of
    > > setproctitle() do.
    >
    > It's not clear to me how the kernel could change argv[] any better than you
    > could in user space.

    Well, it can resize the argv[] buffer, which we can't right now in
    userspace. See those PR_SET_PROCTITLE_AREA.

    > > Well, it's interesting in the syslog case, and it's OK if people can
    > > change it. What matters is that this information is available simply for
    > > the informational value. Right now, if one combines SCM_CREDENTIALS and
    > > /proc/$PID/comm you often end up with no information about the senders
    > > name at all, since at the time you try to read comm the PID might
    > > actually not exist anymore at all. We are simply trying to close this
    > > particular race between receiving SCM_CREDENTIALS and reading
    > > /proc/$PID/comm here, we are not looking for a way to make process names
    > > trusted.
    >
    > The issue with all of these proposals is that the sender currently doesn't
    > know if the receiver needs it. Thus it always has to put it in and you
    > slow down the fast paths.
    >
    > e.g. consider
    >
    > sender sends packet
    > receiver enables funky option
    > receiver reads
    >
    > If it was done lazily you would lose.

    Would you? I think it's OK if messages queued before the sockopt is
    enabled do not carry the SCM_COMM/SCM_CGROUPS data, even if they are
    dequeued after the sockopt. At least I wouldn't expect them to
    necessarily have the data, and this is probably just a matter of
    documentation, i.e. say in the man page explicitly that the control data
    will only be attached to newly queued messages. Given that
    SCM_COMM/SCM_CGROUPS is a completely new API anyway this should not
    create any compatibility problems.

    Lennart

    --
    Lennart Poettering - Red Hat, Inc.


    \
     
     \ /
      Last update: 2011-10-07 18:01    [W:5.221 / U:1.488 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site