lkml.org 
[lkml]   [2009]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH] prctl: return MCE process flags through pointer
On Wed, 23 Dec Andrew Morton wrote:
>On Wed, 23 Dec 2009 10:52:23 +0100 Andi Kleen <andi@firstfloor.org> wrote:
>
>> On Tue, Dec 22, 2009 at 05:34:24PM -0800, Andrew Morton wrote:
>> > On Wed, 23 Dec 2009 02:14:51 +0100 Andi Kleen <andi@firstfloor.org>
>wrote:
>> >
>> > > "Smith, GeoffX" <geoffx.smith@intel.com> writes:
>> > >
>> > > > This patch fixes the semantics of prctl() option PR_MCE_KILL_GET
>> > > > to pass the return value through *arg2.
>> > > >
>> > > > With this change, the option now follows the same conventions as
>the
>> > > > other "get" options added since 2.6.0, and also brings it into
>> > > > conformance with the advice in chapter 16 of
>Documentation/CodingStyle.
>> > > >
>> > > > This prctl() option was only added within the last month, so there
>are
>> > > > not any production applications to break. This patch applies
>cleanly
>> > > > to mainline and to 2.6.32.2 for backporting.
>> > >
>> > > It breaks the test suite, the man pages, qemu and one slide deck at
>least.
>> > >
>> >
>> > Should've got it right the first time.
>>
>> To be honest it's not fully clear to me what is "wrong" with returning
>> the return value with "return".
>
>Just a convention thing.
>
>> If there was a security bug or something maybe such a radical step
>> as changing a published API would be justified, but for this I'm
>sceptical.
>
>hm, OK, shrug.
>

Sorry, I wasn't aware of any published API, PR_MCE_KILL and KILL_GET just got accepted into mainline. (And why aren't they called PR_SET/GET_MCE_KILL???)

I just noticed that these new options didn't follow the conventions of most prctl() options. There is only one option newer than 2.3.48 that uses return-as-function-result, and that one is essentially a no-op.

>Regarding "prctl: return timerslack through pointer": are there any
>known users of PR_GET_TIMERSLACK yet?

The feature is only 3 months old, so no. We are finding it beneficial in my group at Intel, which is the only reason I am looking at prctl().

>Why are task_struct.timer_slack_ns and
>task_struct.default_timer_slack_ns unsigned long, btw? AFACIT we could
>make them unsigned ints.

Timer slack is not a Boolean or enum, and we want the greatest range possible. (Actually, I'd like to talk Arjan into using the same time structure as select(), but that's another discussion.) Internally hrtimer uses unsigned long. I know long and unsigned long are the same on some architectures, but let's not introduce an unnatural restriction -- recall that arg2 is unsigned long.



\
 
 \ /
  Last update: 2009-12-23 18:59    [W:0.132 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site