Ping? Can someone take it before it's lost?
On Wed, Oct 31, 2012 at 2:29 PM, Sasha Levin wrote:
> On Fri, Oct 26, 2012 at 4:48 AM, Peter Zijlstra wrote:
>> On Thu, 2012-10-25 at 16:09 -0700, Linus Torvalds wrote:
>>> On Thu, Oct 25, 2012 at 7:39 AM, Peter Zijlstra
>>> wrote:
>>> >
>>> > So I
Ping? Can someone take it before it's lost?
On Wed, Oct 31, 2012 at 2:29 PM, Sasha Levin levinsasha...@gmail.com wrote:
On Fri, Oct 26, 2012 at 4:48 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2012-10-25 at 16:09 -0700, Linus Torvalds wrote:
On Thu, Oct 25, 2012 at 7:39 AM, Peter
On Fri, Oct 26, 2012 at 4:48 AM, Peter Zijlstra wrote:
> On Thu, 2012-10-25 at 16:09 -0700, Linus Torvalds wrote:
>> On Thu, Oct 25, 2012 at 7:39 AM, Peter Zijlstra wrote:
>> >
>> > So I think the below should work, we hold the spinlock over both rb-tree
>> > modification as sp free, this makes
On Fri, Oct 26, 2012 at 4:48 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2012-10-25 at 16:09 -0700, Linus Torvalds wrote:
On Thu, Oct 25, 2012 at 7:39 AM, Peter Zijlstra pet...@infradead.org wrote:
So I think the below should work, we hold the spinlock over both rb-tree
On Thu, 2012-10-25 at 16:09 -0700, Linus Torvalds wrote:
> On Thu, Oct 25, 2012 at 7:39 AM, Peter Zijlstra wrote:
> >
> > So I think the below should work, we hold the spinlock over both rb-tree
> > modification as sp free, this makes mpol_shared_policy_lookup() which
> > returns the policy with
On Thu, 2012-10-25 at 16:09 -0700, Linus Torvalds wrote:
On Thu, Oct 25, 2012 at 7:39 AM, Peter Zijlstra pet...@infradead.org wrote:
So I think the below should work, we hold the spinlock over both rb-tree
modification as sp free, this makes mpol_shared_policy_lookup() which
returns the
On Thu, Oct 25, 2012 at 7:39 AM, Peter Zijlstra wrote:
>
> So I think the below should work, we hold the spinlock over both rb-tree
> modification as sp free, this makes mpol_shared_policy_lookup() which
> returns the policy with an incremented refcount work with just the
> spinlock.
>
>
On Thu, 25 Oct 2012, Peter Zijlstra wrote:
> So I think the below should work, we hold the spinlock over both rb-tree
> modification as sp free, this makes mpol_shared_policy_lookup() which
> returns the policy with an incremented refcount work with just the
> spinlock.
>
> Comments?
>
It's
On 10/25/2012 10:39 AM, Peter Zijlstra wrote:
> On Thu, 2012-10-25 at 14:19 +0200, Peter Zijlstra wrote:
>> On Wed, 2012-10-24 at 17:08 -0700, David Rientjes wrote:
>>> Ok, this looks the same but it's actually a different issue:
>>> mpol_misplaced(), which now only exists in linux-next and not
On Thu, 2012-10-25 at 14:19 +0200, Peter Zijlstra wrote:
> On Wed, 2012-10-24 at 17:08 -0700, David Rientjes wrote:
> > Ok, this looks the same but it's actually a different issue:
> > mpol_misplaced(), which now only exists in linux-next and not in 3.7-rc2,
> > calls get_vma_policy() which may
On Wed, 2012-10-24 at 17:08 -0700, David Rientjes wrote:
> Ok, this looks the same but it's actually a different issue:
> mpol_misplaced(), which now only exists in linux-next and not in 3.7-rc2,
> calls get_vma_policy() which may take the shared policy mutex. This
> happens while holding
On Wed, 2012-10-24 at 17:08 -0700, David Rientjes wrote:
Ok, this looks the same but it's actually a different issue:
mpol_misplaced(), which now only exists in linux-next and not in 3.7-rc2,
calls get_vma_policy() which may take the shared policy mutex. This
happens while holding
On Thu, 2012-10-25 at 14:19 +0200, Peter Zijlstra wrote:
On Wed, 2012-10-24 at 17:08 -0700, David Rientjes wrote:
Ok, this looks the same but it's actually a different issue:
mpol_misplaced(), which now only exists in linux-next and not in 3.7-rc2,
calls get_vma_policy() which may take
On 10/25/2012 10:39 AM, Peter Zijlstra wrote:
On Thu, 2012-10-25 at 14:19 +0200, Peter Zijlstra wrote:
On Wed, 2012-10-24 at 17:08 -0700, David Rientjes wrote:
Ok, this looks the same but it's actually a different issue:
mpol_misplaced(), which now only exists in linux-next and not in
On Thu, 25 Oct 2012, Peter Zijlstra wrote:
So I think the below should work, we hold the spinlock over both rb-tree
modification as sp free, this makes mpol_shared_policy_lookup() which
returns the policy with an incremented refcount work with just the
spinlock.
Comments?
It's rather
On Thu, Oct 25, 2012 at 7:39 AM, Peter Zijlstra pet...@infradead.org wrote:
So I think the below should work, we hold the spinlock over both rb-tree
modification as sp free, this makes mpol_shared_policy_lookup() which
returns the policy with an incremented refcount work with just the
On Wed, 24 Oct 2012, KOSAKI Motohiro wrote:
> Hrm. I haven't noticed there is mpol_misplaced() in linux-next. Peter,
> I guess you commited it, right? If so, may I review your mempolicy
> changes? Now mempolicy has a lot of horrible buggy code and I hope to
> maintain carefully. Which tree should
On Wed, Oct 24, 2012 at 8:08 PM, David Rientjes wrote:
> On Wed, 24 Oct 2012, Sasha Levin wrote:
>
>> > This should be fixed by 9e7814404b77 ("hold task->mempolicy while
>> > numa_maps scans.") in 3.7-rc2, can you reproduce any issues reading
>> > /proc/pid/numa_maps on that kernel?
>>
>> I was
On Wed, 24 Oct 2012, Sasha Levin wrote:
> > This should be fixed by 9e7814404b77 ("hold task->mempolicy while
> > numa_maps scans.") in 3.7-rc2, can you reproduce any issues reading
> > /proc/pid/numa_maps on that kernel?
>
> I was actually referring to the warnings Dave Jones saw when fuzzing
>
On Wed, Oct 24, 2012 at 7:34 PM, David Rientjes wrote:
> On Wed, 24 Oct 2012, Sasha Levin wrote:
>
>> I'm not sure about the status of the patch, but it doesn't apply on
>> top of -next, and I still
>> see the warnings when fuzzing on -next.
>>
>
> This should be fixed by 9e7814404b77 ("hold
On Wed, 24 Oct 2012, Sasha Levin wrote:
> I'm not sure about the status of the patch, but it doesn't apply on
> top of -next, and I still
> see the warnings when fuzzing on -next.
>
This should be fixed by 9e7814404b77 ("hold task->mempolicy while
numa_maps scans.") in 3.7-rc2, can you
On Wed, Oct 17, 2012 at 1:24 AM, David Rientjes wrote:
> On Wed, 17 Oct 2012, Dave Jones wrote:
>
>> BUG: sleeping function called from invalid context at kernel/mutex.c:269
>> in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name: trinity-child2
>> 3 locks on stack by trinity-child2/8558:
>> #0:
On Wed, Oct 17, 2012 at 1:24 AM, David Rientjes rient...@google.com wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name: trinity-child2
3 locks on stack by
On Wed, 24 Oct 2012, Sasha Levin wrote:
I'm not sure about the status of the patch, but it doesn't apply on
top of -next, and I still
see the warnings when fuzzing on -next.
This should be fixed by 9e7814404b77 (hold task-mempolicy while
numa_maps scans.) in 3.7-rc2, can you reproduce any
On Wed, Oct 24, 2012 at 7:34 PM, David Rientjes rient...@google.com wrote:
On Wed, 24 Oct 2012, Sasha Levin wrote:
I'm not sure about the status of the patch, but it doesn't apply on
top of -next, and I still
see the warnings when fuzzing on -next.
This should be fixed by 9e7814404b77
On Wed, 24 Oct 2012, Sasha Levin wrote:
This should be fixed by 9e7814404b77 (hold task-mempolicy while
numa_maps scans.) in 3.7-rc2, can you reproduce any issues reading
/proc/pid/numa_maps on that kernel?
I was actually referring to the warnings Dave Jones saw when fuzzing
with
On Wed, Oct 24, 2012 at 8:08 PM, David Rientjes rient...@google.com wrote:
On Wed, 24 Oct 2012, Sasha Levin wrote:
This should be fixed by 9e7814404b77 (hold task-mempolicy while
numa_maps scans.) in 3.7-rc2, can you reproduce any issues reading
/proc/pid/numa_maps on that kernel?
I was
On Wed, 24 Oct 2012, KOSAKI Motohiro wrote:
Hrm. I haven't noticed there is mpol_misplaced() in linux-next. Peter,
I guess you commited it, right? If so, may I review your mempolicy
changes? Now mempolicy has a lot of horrible buggy code and I hope to
maintain carefully. Which tree should i
On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
> > Um, this was just changed to a mutex last week in commit b22d127a39dd
> > ("mempolicy: fix a race in shared_policy_replace()") so that sp_alloc()
> > can be done with GFP_KERNEL, so I didn't consider reverting that behavior.
> > Are you nacking that
On Wed, Oct 17, 2012 at 3:50 PM, David Rientjes wrote:
> On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
>
>> > I think this refcounting is better than using task_lock().
>>
>> I don't think so. get_vma_policy() is used from fast path. In other
>> words, number of
>> atomic ops is sensible for
On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
> > I think this refcounting is better than using task_lock().
>
> I don't think so. get_vma_policy() is used from fast path. In other
> words, number of
> atomic ops is sensible for allocation performance.
There are enhancements that we can make with
On Wed, Oct 17, 2012 at 12:38:55PM -0700, David Rientjes wrote:
> > > Sounds good. Is it possible to verify that policy_cache isn't getting
> > > larger than normal in /proc/slabinfo, i.e. when all processes with a
> > > task mempolicy or shared vma policy have exited, are there still a
On Wed, 17 Oct 2012, Dave Jones wrote:
> > Sounds good. Is it possible to verify that policy_cache isn't getting
> > larger than normal in /proc/slabinfo, i.e. when all processes with a
> > task mempolicy or shared vma policy have exited, are there still a
> > significant number of active
On Wed, Oct 17, 2012 at 12:21:10PM -0700, David Rientjes wrote:
> On Wed, 17 Oct 2012, Dave Jones wrote:
>
> > On Tue, Oct 16, 2012 at 10:24:32PM -0700, David Rientjes wrote:
> > > On Wed, 17 Oct 2012, Dave Jones wrote:
> > >
> > > > BUG: sleeping function called from invalid context at
On Wed, 17 Oct 2012, Dave Jones wrote:
> On Tue, Oct 16, 2012 at 10:24:32PM -0700, David Rientjes wrote:
> > On Wed, 17 Oct 2012, Dave Jones wrote:
> >
> > > BUG: sleeping function called from invalid context at kernel/mutex.c:269
> >
> > Hmm, looks like we need to change the refcount
On Tue, Oct 16, 2012 at 10:24:32PM -0700, David Rientjes wrote:
> On Wed, 17 Oct 2012, Dave Jones wrote:
>
> > BUG: sleeping function called from invalid context at kernel/mutex.c:269
>
> Hmm, looks like we need to change the refcount semantics entirely. We'll
> need to make
On Wed, Oct 17, 2012 at 1:42 AM, Kamezawa Hiroyuki
wrote:
> (2012/10/17 14:24), David Rientjes wrote:
>>
>> On Wed, 17 Oct 2012, Dave Jones wrote:
>>
>>> BUG: sleeping function called from invalid context at kernel/mutex.c:269
>>> in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name:
On Wed, Oct 17, 2012 at 1:42 AM, Kamezawa Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
(2012/10/17 14:24), David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 1, irqs_disabled(): 0, pid: 8558,
On Tue, Oct 16, 2012 at 10:24:32PM -0700, David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
Hmm, looks like we need to change the refcount semantics entirely. We'll
need to make get_vma_policy()
On Wed, 17 Oct 2012, Dave Jones wrote:
On Tue, Oct 16, 2012 at 10:24:32PM -0700, David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
Hmm, looks like we need to change the refcount semantics
On Wed, Oct 17, 2012 at 12:21:10PM -0700, David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
On Tue, Oct 16, 2012 at 10:24:32PM -0700, David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at
On Wed, 17 Oct 2012, Dave Jones wrote:
Sounds good. Is it possible to verify that policy_cache isn't getting
larger than normal in /proc/slabinfo, i.e. when all processes with a
task mempolicy or shared vma policy have exited, are there still a
significant number of active
On Wed, Oct 17, 2012 at 12:38:55PM -0700, David Rientjes wrote:
Sounds good. Is it possible to verify that policy_cache isn't getting
larger than normal in /proc/slabinfo, i.e. when all processes with a
task mempolicy or shared vma policy have exited, are there still a
On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
I think this refcounting is better than using task_lock().
I don't think so. get_vma_policy() is used from fast path. In other
words, number of
atomic ops is sensible for allocation performance.
There are enhancements that we can make with
On Wed, Oct 17, 2012 at 3:50 PM, David Rientjes rient...@google.com wrote:
On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
I think this refcounting is better than using task_lock().
I don't think so. get_vma_policy() is used from fast path. In other
words, number of
atomic ops is sensible for
On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
Um, this was just changed to a mutex last week in commit b22d127a39dd
(mempolicy: fix a race in shared_policy_replace()) so that sp_alloc()
can be done with GFP_KERNEL, so I didn't consider reverting that behavior.
Are you nacking that patch,
(2012/10/17 14:24), David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name: trinity-child2
3 locks on stack by trinity-child2/8558:
#0: held:
On Wed, 17 Oct 2012, Dave Jones wrote:
> BUG: sleeping function called from invalid context at kernel/mutex.c:269
> in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name: trinity-child2
> 3 locks on stack by trinity-child2/8558:
> #0: held: (>lock){+.+.+.}, instance: 88010c9a00b0, at:
>
On Tue, Oct 16, 2012 at 05:31:23PM -0700, David Rientjes wrote:
> -pol = get_vma_policy(proc_priv->task, vma, vma->vm_start);
> +task_lock(task);
> +pol = get_vma_policy(task, vma, vma->vm_start);
> mpol_to_str(buffer, sizeof(buffer), pol, 0);
> mpol_cond_put(pol);
> +
On Tue, Oct 16, 2012 at 9:49 PM, David Rientjes wrote:
> On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
>
>> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> > index 0b78fb9..d04a8a5 100644
>> > --- a/mm/mempolicy.c
>> > +++ b/mm/mempolicy.c
>> > @@ -1536,9 +1536,8 @@ asmlinkage long
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> > index 0b78fb9..d04a8a5 100644
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -1536,9 +1536,8 @@ asmlinkage long compat_sys_mbind(compat_ulong_t
> > start, compat_ulong_t len,
> > *
> >
On Tue, Oct 16, 2012 at 8:31 PM, David Rientjes wrote:
> When reading /proc/pid/numa_maps, it's possible to return the contents of
> the stack where the mempolicy string should be printed if the policy gets
> freed from beneath us.
>
> This happens because mpol_to_str() may return an error the
>
When reading /proc/pid/numa_maps, it's possible to return the contents of
the stack where the mempolicy string should be printed if the policy gets
freed from beneath us.
This happens because mpol_to_str() may return an error the
stack-allocated buffer is then printed without ever being
When reading /proc/pid/numa_maps, it's possible to return the contents of
the stack where the mempolicy string should be printed if the policy gets
freed from beneath us.
This happens because mpol_to_str() may return an error the
stack-allocated buffer is then printed without ever being
On Tue, Oct 16, 2012 at 8:31 PM, David Rientjes rient...@google.com wrote:
When reading /proc/pid/numa_maps, it's possible to return the contents of
the stack where the mempolicy string should be printed if the policy gets
freed from beneath us.
This happens because mpol_to_str() may return
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 0b78fb9..d04a8a5 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1536,9 +1536,8 @@ asmlinkage long compat_sys_mbind(compat_ulong_t
start, compat_ulong_t len,
*
* Returns
On Tue, Oct 16, 2012 at 9:49 PM, David Rientjes rient...@google.com wrote:
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 0b78fb9..d04a8a5 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1536,9 +1536,8 @@ asmlinkage long
On Tue, Oct 16, 2012 at 05:31:23PM -0700, David Rientjes wrote:
-pol = get_vma_policy(proc_priv-task, vma, vma-vm_start);
+task_lock(task);
+pol = get_vma_policy(task, vma, vma-vm_start);
mpol_to_str(buffer, sizeof(buffer), pol, 0);
mpol_cond_put(pol);
+
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name: trinity-child2
3 locks on stack by trinity-child2/8558:
#0: held: (p-lock){+.+.+.}, instance: 88010c9a00b0, at:
(2012/10/17 14:24), David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name: trinity-child2
3 locks on stack by trinity-child2/8558:
#0: held:
60 matches
Mail list logo
