[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLSuvFnV5er6A5abg6EMWM6XVZmVaOCRjwTMS+p4oEXAQ@mail.gmail.com>
Date: Fri, 2 Dec 2011 11:23:32 -0800
From: Kees Cook <keescook@...omium.org>
To: Cyrill Gorcunov <gorcunov@...il.com>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>, Andrew Vagin <avagin@...nvz.org>,
Serge Hallyn <serge.hallyn@...onical.com>,
Pavel Emelyanov <xemul@...allels.com>,
Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: [rfc 1/3] fs, proc: Add start_data, end_data, start_brk members
to /proc/$pid/stat
On Thu, Dec 1, 2011 at 11:28 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On Fri, Dec 02, 2011 at 03:24:06AM +0300, Alexey Dobriyan wrote:
>> > > + cputime_to_clock_t(cgtime),
>> > > + mm ? (permitted ? mm->start_data : 1) : 0,
>> > > + mm ? (permitted ? mm->end_data : 1) : 0,
>> > > + mm ? (permitted ? mm->start_brk : 1) : 0);
>> > > if (mm)
>> > > mmput(mm);
>> > > return 0;
>> >
>> > Thanks for using "permitted" here. :)
>>
>> And these are new fields, so "1" hack is unnecessary.
>
> I perhaps miss some history here, you mean just print 0
> instead of 1, right?
The history is that when "0" is seen for start_code, tools like "ps"
assumed the process was a kernel thread, so "1" was used as a hack to
not break userspace reporting. So yeah, since this is a new field,
it's fine to just do:
+ (mm && permitted) ? mm->start_data : 0,
+ (mm && permitted) ? mm->end_data : 0,
+ (mm && permitted) ? mm->start_brk : 0,
-Kees
--
Kees Cook
ChromeOS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists