On Thu, Oct 31, 2013 at 8:46 AM, Richard Guy Briggs <rgb@redhat.com> wrote:

On Thu, Oct 31, 2013 at 08:33:34AM -0700, William Roberts wrote:
> On Thu, Oct 31, 2013 at 8:28 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>
> > On Thu, Oct 31, 2013 at 08:24:11AM -0700, William Roberts wrote:
> > > On Thu, Oct 31, 2013 at 7:36 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wednesday, October 30, 2013 01:18:13 PM William Roberts wrote:
> > > > > On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > > > I have compiled kernels in the past with custom COMM widths, but
> > > > > the memory footprint goes up, at least here were not keeping a
> > > > > bunch of possibly unused data around in the kernel plus we're not
> > > > > allocating anything on the common case of it being turned off.
> > > >
> > > > I don't like the idea of fields appearing and disappearing. The
> > > > complaint is "comm" is meaningless. Let's fix that.
> > >
> > > Its not that the field is disappearing, its just whether or not you
> > > want the value printed out. cmdline=(null) vs cmdline="something".
> > > That's a trivial change of not making it dynamic which is what my
> > > first patch did but Richard Briggs suggested making it a dynamic
> > > feature and I was pretty ok with that.
> >
> > Ok, so how about both fields are always present, but have some keyword
> > that is printed that indicates it is a duplicate of the other field?
> >
> > Something like cmdline=(comm)
>
> How are you going to detect that cmdlne has changed, its a region of
> memory in userspace? We would have to cmp the values, and if we cannot
> detect the transition, this gets more expensive. Also, I have yet to
> see a case where the above statement is true, so it would be a very
> infrequent event.

Is it likely that those two point to the same region of memory?  If so,
just compare the pointers.

no cmdline is mapped into the user process, cmdline is mapped into the kernel, so their

virtual addresses and pa's are different (hopefully or I don't understand mmu based memory management)

 

> However, their is a condition in my patch where an error will cause
> comm=(null) not to be printed, which could be
> viewed as a disappearing field.

Would it be useful if this condition were changed to print instead comm=(error)?

It could be, but ideally we should printk the error too.... someone can arbitrarily set their

proc cmdline entry or tsk comm to something "reserved"

 

> > > William C Roberts
> >
> > - RGB
>
> William C Roberts

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545

--
Respectfully,

William C Roberts