Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message

On Wed, 2014-01-15 at 12:17 -0800, David Miller wrote:

From: Jan Kaluza <redacted>
Date: Mon, 13 Jan 2014 09:01:46 +0100

quoted

Changes introduced in this patchset can also increase performance
of such server-like processes, because current way of opening and
parsing /proc/$PID/* files is much more expensive than receiving these
metadata using SCM.

The problem with this line of reasoning is that these changes will
hurt everyone else, because these new control messages are sent
unconditionally, whether the application is interested in them or not.

I really don't like this cost tradeoff, it's terrible, and therefore
I'm really not inclined to apply these patches, sorry.

Agreed.  Although you seem to be ignoring the part of the logic where is
solves a problem that can not be solved today.

The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.

Reliably being able to audit what process requested an action is
extremely useful.  And I like the audit patch, as it is a couple of ints
we are storing.

procinfo and cgroup can both be up to 4k of data.

Is there an alternative he should consider?  Some way to grab a
reference on task_struct and just attach that to the message?