Message-ID: <441C943A.6090307@tremplin-utc.net>
Date: Sun, 19 Mar 2006 00:14:02 +0100
From: Eric Piel <Eric.Piel@tremplin-utc.net>
User-Agent: Thunderbird 1.5 (X11/20060225)
MIME-Version: 1.0
To: Jesper Juhl <jesper.juhl@gmail.com>
CC: Andrew Morton <akpm@osdl.org>, tglx@linutronix.de,
       linux-kernel@vger.kernel.org, mingo@elte.hu, trini@kernel.crashing.org
Subject: Re: [patch 1/2] Validate itimer timeval from userspace
References: <20060318142827.419018000@localhost.localdomain>	 <20060318142830.607556000@localhost.localdomain>	 <20060318120728.63cbad54.akpm@osdl.org>	 <1142712975.17279.131.camel@localhost.localdomain>	 <20060318123102.7d8c048a.akpm@osdl.org> <9a8748490603181245v47b9f0a5v1ef252f91c30a7d2@mail.gmail.com>
In-Reply-To: <9a8748490603181245v47b9f0a5v1ef252f91c30a7d2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2072
Lines: 47

18.03.2006 21:45, Jesper Juhl wrote/a ?crit:
> On 3/18/06, Andrew Morton <akpm@osdl.org> wrote:
>> Thomas Gleixner <tglx@linutronix.de> wrote:
>>> On Sat, 2006-03-18 at 12:07 -0800, Andrew Morton wrote:
>>>
>>>> From my reading, 2.4's sys_setitimer() will normalise the incoming timeval
>>>> rather than rejecting it.  And I think 2.6.13 did that too.
>>>>
>>>> It would be bad of us to change this behaviour, even if that's what the
>>>> spec says we should do - because we can break existing applications.
>>>>
>>>> So I think we're stuck with it - we should normalise and then accept such
>>>> timevals.  And we should have a big comment explaining how we differ from
>>>> the spec, and why.
>>> Hmm. How do you treat a negative value ?
>>>
>> In the same way as earlier kernels did!
>>
>> Unless, of course, those kernels did something utterly insane.  In that
>> case we'd need to have a little think.
>>
> 
> If the change only affects buggy apps (as Thomas says), then it seems
> completely obvious to me that the change should be made.
> 
> 1. We'll be in compliance with the spec
> 2. Buggy applications will actually be helped by this by getting a
> clear error instead of undefined behaviour silently hiding the fact
> that they are buggy.
> 3. Correct applications are unaffected.
4. Applications written for an OS which respects the spec (and using 
this particular rule) will finally work on Linux.

Well, I'd vote for just making Linux conform to the spec as soon as 
someone notices a non-compliance. However, as this rule doesn't play 
well with a stable ABI, a "trade-off" solution could consists in:
- Keeping the old behavior for now and generate a printk() each time 
this code path is entered;
- Add an entry to feature-removal-schedule.txt saying Linux will start 
conforming to the spec next year.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/