On Monday, May 06, 2013 12:33:07 PM Tejun Heo wrote:
> Hello,
>
> On Mon, May 06, 2013 at 12:30:19PM -0700, Colin Cross wrote:
> > > I don't care about %current change, especially given that it's a debug
> > > interface but that really should be a separate patch, so please split
> > > it out if yo
Hello,
On Mon, May 06, 2013 at 12:30:19PM -0700, Colin Cross wrote:
> > I don't care about %current change, especially given that it's a debug
> > interface but that really should be a separate patch, so please split
> > it out if you want it (and I think we want it).
>
> The current change was r
On Mon, May 6, 2013 at 12:01 PM, Tejun Heo wrote:
> On Fri, May 03, 2013 at 02:04:10PM -0700, Colin Cross wrote:
>> From: Mandeep Singh Baines
>>
>> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
>> deadlock if the lock is later acquired in the suspend or hibernate path
On Fri, May 03, 2013 at 02:04:10PM -0700, Colin Cross wrote:
> From: Mandeep Singh Baines
>
> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
> deadlock if the lock is later acquired in the suspend or hibernate path
> (e.g. by dpm). Holding a lock can also cause a dead
On Mon, May 06, 2013 at 07:33:28AM -0700, Linus Torvalds wrote:
> On Mon, May 6, 2013 at 1:55 AM, Peter Zijlstra wrote:
> >
> > Doesn't i386 have all the funny per-cpu stuff too? So the only reason it
> > still
> > does the fugly stack based thing is because nobody could be arsed to do the
> > wo
On Mon, May 6, 2013 at 1:55 AM, Peter Zijlstra wrote:
>
> Doesn't i386 have all the funny per-cpu stuff too? So the only reason it still
> does the fugly stack based thing is because nobody could be arsed to do the
> work of converting it.
Umm. That "fugly stack-based" thing is better than the pe
1;2403;0cOn Mon 2013-05-06 10:55:47, Peter Zijlstra wrote:
> On Sun, May 05, 2013 at 11:18:44AM +0200, Ingo Molnar wrote:
> > That's the old 32-bit x86 trick to compute 'current' from the kernel stack
> > pointer.
> >
> > It can be done better - for example on platforms with optimized percpu
> >
On Sun, May 05, 2013 at 11:18:44AM +0200, Ingo Molnar wrote:
> That's the old 32-bit x86 trick to compute 'current' from the kernel stack
> pointer.
>
> It can be done better - for example on platforms with optimized percpu
> variables (x86-64) it looks like this:
Doesn't i386 have all the funn
* Pavel Machek wrote:
> Hi!
>
> > >> >> --- a/kernel/exit.c
> > >> >> +++ b/kernel/exit.c
> > >> >> @@ -835,7 +835,7 @@ void do_exit(long code)
> > >> >> /*
> > >> >>* Make sure we are holding no locks:
> > >> >>*/
> > >> >> - debug_check_no_locks_held(tsk);
> > >> >>
On Sat 2013-05-04 17:23:01, Colin Cross wrote:
> On Sat, May 4, 2013 at 5:05 PM, Pavel Machek wrote:
> > Hi!
> >
> >> >> >> --- a/kernel/exit.c
> >> >> >> +++ b/kernel/exit.c
> >> >> >> @@ -835,7 +835,7 @@ void do_exit(long code)
> >> >> >> /*
> >> >> >>* Make sure we are holding no
On Sat, May 4, 2013 at 5:05 PM, Pavel Machek wrote:
> Hi!
>
>> >> >> --- a/kernel/exit.c
>> >> >> +++ b/kernel/exit.c
>> >> >> @@ -835,7 +835,7 @@ void do_exit(long code)
>> >> >> /*
>> >> >>* Make sure we are holding no locks:
>> >> >>*/
>> >> >> - debug_check_no_locks_h
Hi!
> >> >> --- a/kernel/exit.c
> >> >> +++ b/kernel/exit.c
> >> >> @@ -835,7 +835,7 @@ void do_exit(long code)
> >> >> /*
> >> >>* Make sure we are holding no locks:
> >> >>*/
> >> >> - debug_check_no_locks_held(tsk);
> >> >> + debug_check_no_locks_held();
> >> >
> >
On Sat, May 4, 2013 at 3:57 PM, Pavel Machek wrote:
> On Sat 2013-05-04 13:27:23, Colin Cross wrote:
>> On Sat, May 4, 2013 at 6:04 AM, Pavel Machek wrote:
>> > On Fri 2013-05-03 14:04:10, Colin Cross wrote:
>> >> From: Mandeep Singh Baines
>> >>
>> >> We shouldn't try_to_freeze if locks are hel
On Sat 2013-05-04 13:27:23, Colin Cross wrote:
> On Sat, May 4, 2013 at 6:04 AM, Pavel Machek wrote:
> > On Fri 2013-05-03 14:04:10, Colin Cross wrote:
> >> From: Mandeep Singh Baines
> >>
> >> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
> >> deadlock if the lock is
On Sat, May 4, 2013 at 6:04 AM, Pavel Machek wrote:
> On Fri 2013-05-03 14:04:10, Colin Cross wrote:
>> From: Mandeep Singh Baines
>>
>> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
>> deadlock if the lock is later acquired in the suspend or hibernate path
>> (e.g. b
On Fri 2013-05-03 14:04:10, Colin Cross wrote:
> From: Mandeep Singh Baines
>
> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
> deadlock if the lock is later acquired in the suspend or hibernate path
> (e.g. by dpm). Holding a lock can also cause a deadlock in the ca
From: Mandeep Singh Baines
We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
deadlock if the lock is later acquired in the suspend or hibernate path
(e.g. by dpm). Holding a lock can also cause a deadlock in the case of
cgroup_freezer if a lock is held inside a frozen cg
17 matches
Mail list logo
