On Mon, 2008-03-24 at 10:34 -0700, Frank Mayhar wrote:
quoted text
> On Sat, 2008-03-22 at 14:58 -0700, Roland McGrath wrote:
> > The analysis above is correct but your conclusion here is wrong.
> > The current value of an itimer is a user feature, not just a piece
> > of internal bookkeeping.
> 
> After looking at the code again, I now understand what you're talking
> about.  You overloaded it_*_expires to support both the POSIX interval
> timers and RLIMIT_CPU.  So the way I have things, setting one can stomp
> the other.
> 
> > Your code causes any timer_settime or timer_delete call on a process
> > CPU timer or any setrlimit call on RLIMIT_CPU to suddenly change the
> > itimer setting just as if the user had made some setitimer call that
> > was never made or intended.  That's wrong.
> 
> Right, because the original effect was to only set the it_*_expires on
> each individual task struct, leaving the one in the signal struct alone.
> 
> Might it be cleaner to handle the RLIMIT_CPU stuff separately, rather
> than rolling it into the itimer handling?

Okay, my proposed fix for this is to introduce a new field in
signal_struct, rlim_expires, a cputime_t.  Everywhere that the
RLIMIT_CPU code formerly set it_prof_expires it will now set
rlim_expires and in run_posix_cpu_timers() I'll check it against the
thread group prof_time.

I believe that that will solve the problem, if I understand this
correctly.  If I don't, I trust that you will set me straight. :-)
-- 
Frank Mayhar <fmayhar@google.com>
Google, Inc.

--
unsubscribe notice
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/