Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750963AbWCRUil (ORCPT ); Sat, 18 Mar 2006 15:38:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750968AbWCRUil (ORCPT ); Sat, 18 Mar 2006 15:38:41 -0500 Received: from 213-239-205-134.clients.your-server.de ([213.239.205.134]:63966 "EHLO mail.tglx.de") by vger.kernel.org with ESMTP id S1750963AbWCRUik (ORCPT ); Sat, 18 Mar 2006 15:38:40 -0500 Subject: Re: [patch 1/2] Validate itimer timeval from userspace From: Thomas Gleixner Reply-To: tglx@linutronix.de To: Andrew Morton Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, trini@kernel.crashing.org In-Reply-To: <20060318123102.7d8c048a.akpm@osdl.org> 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> Content-Type: text/plain Date: Sat, 18 Mar 2006 21:38:51 +0100 Message-Id: <1142714332.17279.148.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1621 Lines: 52 On Sat, 2006-03-18 at 12:31 -0800, Andrew Morton wrote: > Thomas Gleixner 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. It was caught by: timeval_to_jiffies(const struct timeval *value) { unsigned long sec = value->tv_sec; long usec = value->tv_usec; if (sec >= MAX_SEC_IN_JIFFIES) sec = MAX_SEC_IN_JIFFIES; .... } The conversion of long to unsigned long converted a negative value to the maximum timeout. It's not utterly insane, but it does not make much sense either. Of course I can convert it that way, if we want to keep this "help sloppy programmers aid" alive. tglx - 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/