[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <354B2877CF17F44BB3FA44EB4DB0E5470C91CE18A8@orsmsx510.amr.corp.intel.com>
Date: Wed, 23 Dec 2009 09:56:04 -0800
From: "Smith, GeoffX" <geoffx.smith@...el.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Michael Stone <michael@...top.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: RE: [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@...stfloor.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@...stfloor.org>
>wrote:
>> >
>> > > "Smith, GeoffX" <geoffx.smith@...el.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.
--
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