On Fri, Nov 27, 2009 at 06:46:27PM +0100, Veaceslav Falico wrote:
> On Thu, Nov 26, 2009 at 11:37:03PM +0100, Oleg Nesterov wrote:
> >
> > Could you look at this
> >
> > ptrace-copy_process-should-disable-stepping.patch
> > http://marc.info/?l=linux-mm-commits&m=125789789322573
> >
> > patch? I
On Fri, Nov 27, 2009 at 04:15:21PM +0100, Oleg Nesterov wrote:
> On 11/27, Ananth N Mavinakayanahalli wrote:
> >
> > I am confused as to why we need two atomics count and live in signal_struct.
> >
> > report_death() uses ->live as the group_dead indicator,
>
> report_death? Perhaps you meant do_e
On Fri, Nov 27, 2009 at 04:05:31PM +0100, Oleg Nesterov wrote:
> On 11/27, Ananth N Mavinakayanahalli wrote:
> >
> > On Thu, Nov 26, 2009 at 03:50:51PM +0100, Oleg Nesterov wrote:
> >
> > > Ananth, could you please run the test-case from the changelog
> > > below ? I do not really expect this can h
* Christoph Hellwig wrote:
> > Yes. Which is a further argument to not do it like that but to do
> > one arch at a time. Trying to do too much at once is bad
> > engineering.
>
> I'm not sure why you're trying to pick fights here, [...]
I am advocating proper engineering practices - not sure
On Thu, Nov 26, 2009 at 11:37:03PM +0100, Oleg Nesterov wrote:
>
> Could you look at this
>
> ptrace-copy_process-should-disable-stepping.patch
> http://marc.info/?l=linux-mm-commits&m=125789789322573
>
> patch? It is not clear to me how we can modify the test-case to
> verify it fixes the orig
On 11/27, Ananth N Mavinakayanahalli wrote:
>
> I am confused as to why we need two atomics count and live in signal_struct.
>
> report_death() uses ->live as the group_dead indicator,
report_death? Perhaps you meant do_exit() ?
> while there are
> places (like the scheduler) which uses ->count a
On 11/27, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Nov 26, 2009 at 03:50:51PM +0100, Oleg Nesterov wrote:
>
> > Ananth, could you please run the test-case from the changelog
> > below ? I do not really expect this can help, but just in case.
>
> Right, it doesn't help :-(
>
> GDB shows that th
On Fri, 27 Nov 2009 15:34:05 +0100, Oleg Nesterov wrote:
> Jan, if you see something particular which needs more attention or should
> be fixed, please let me know. I'll try to investigate then.
I am still not finished with the verifications yesterday but so far no kernel
behavior change has been
On 11/27, Veaceslav Falico wrote:
>
> On Wed, Nov 25, 2009 at 01:17:15PM -0800, Roland McGrath wrote:
> >
> > That's certainly good to hear. If you are pretty confident about that,
> > then I am quite happy to consider nonregression on all of ptrace-tests the
> > sole gating test for kernel change
On 11/27, Christoph Hellwig wrote:
>
> On Thu, Nov 26, 2009 at 01:24:41PM +0100, Ingo Molnar wrote:
> >
> > FYI, it's been in -mm, that's where it's maintained.
>
> None of the recent mm snapshots has anything utrace related in there,
Well, not that I think this is important, but...
Two weeks ago
On Fri, 27 Nov 2009 15:11:09 +0100, Veaceslav Falico wrote:
> -FAIL: gdb.base/foll-fork.exp: unpatch child, unpatched parent breakpoints
> from child (timeout)
> +PASS: gdb.base/foll-fork.exp: unpatch child, unpatched parent breakpoints
> from child
> -PASS: gdb.base/foll-fork.exp: set follow par
On Wed, Nov 25, 2009 at 01:17:15PM -0800, Roland McGrath wrote:
>
> That's certainly good to hear. If you are pretty confident about that,
> then I am quite happy to consider nonregression on all of ptrace-tests the
> sole gating test for kernel changes. We just don't want to wind up having
> ot
On Thu, Nov 26, 2009 at 01:24:41PM +0100, Ingo Molnar wrote:
> FYI, the merge window has not opened yet, so it cannot close in a few
> days.
subsystems merged window, not Linus'.
>
> > [...] and thus not getting any of the broad -next test coverage is a
> > pretty bad idea. In the end it will
Oleg,
I am confused as to why we need two atomics count and live in signal_struct.
report_death() uses ->live as the group_dead indicator, while there are
places (like the scheduler) which uses ->count as the nr_threads
indicator.
I tried git blame to see if it remembers why, but the addition pr
14 matches
Mail list logo
