Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On 11/08/2016 04:24 PM, Joel Fernandes wrote: > On Wed, Oct 19, 2016 at 4:15 AM, Chris Wilson > wrote: >> On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >>> This is how everyone seems to already use them, but let's make that >>> explicit. >> >> Ah,

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On 11/08/2016 04:24 PM, Joel Fernandes wrote: > On Wed, Oct 19, 2016 at 4:15 AM, Chris Wilson > wrote: >> On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >>> This is how everyone seems to already use them, but let's make that >>> explicit. >> >> Ah, found an exception,

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 4:15 AM, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >> This is how everyone seems to already use them, but let's make that >> explicit. > > Ah, found an exception, vmapped stacks: > > [ 696.928541]

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 4:15 AM, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >> This is how everyone seems to already use them, but let's make that >> explicit. > > Ah, found an exception, vmapped stacks: > > [ 696.928541] BUG: sleeping function

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

Hi Christoph, On Wed, Oct 19, 2016 at 9:31 AM, Christoph Hellwig wrote: > On Wed, Oct 19, 2016 at 08:34:40AM -0700, Andy Lutomirski wrote: >> >> It would be quite awkward for a task stack to get freed from a >> sleepable context, because the obvious sleepable context is the task >>

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

Hi Christoph, On Wed, Oct 19, 2016 at 9:31 AM, Christoph Hellwig wrote: > On Wed, Oct 19, 2016 at 08:34:40AM -0700, Andy Lutomirski wrote: >> >> It would be quite awkward for a task stack to get freed from a >> sleepable context, because the obvious sleepable context is the task >> itself, and

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 06:31:12PM +0200, Christoph Hellwig wrote: > On Wed, Oct 19, 2016 at 08:34:40AM -0700, Andy Lutomirski wrote: > > > > It would be quite awkward for a task stack to get freed from a > > sleepable context, because the obvious sleepable context is the task > > itself, and it

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 06:31:12PM +0200, Christoph Hellwig wrote: > On Wed, Oct 19, 2016 at 08:34:40AM -0700, Andy Lutomirski wrote: > > > > It would be quite awkward for a task stack to get freed from a > > sleepable context, because the obvious sleepable context is the task > > itself, and it

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 08:34:40AM -0700, Andy Lutomirski wrote: > > It would be quite awkward for a task stack to get freed from a > sleepable context, because the obvious sleepable context is the task > itself, and it still needs its stack. This was true even in the old > regime when task

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 08:34:40AM -0700, Andy Lutomirski wrote: > > It would be quite awkward for a task stack to get freed from a > sleepable context, because the obvious sleepable context is the task > itself, and it still needs its stack. This was true even in the old > regime when task

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 6:05 AM, Christoph Hellwig wrote: > On Wed, Oct 19, 2016 at 12:15:41PM +0100, Chris Wilson wrote: >> On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >> > This is how everyone seems to already use them, but let's make that >> > explicit. >>

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 6:05 AM, Christoph Hellwig wrote: > On Wed, Oct 19, 2016 at 12:15:41PM +0100, Chris Wilson wrote: >> On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: >> > This is how everyone seems to already use them, but let's make that >> > explicit. >> >> Ah, found

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > This is how everyone seems to already use them, but let's make that > explicit. Ah, found an exception, vmapped stacks: [ 696.928541] BUG: sleeping function called from invalid context at mm/vmalloc.c:615 [ 696.928576]

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > This is how everyone seems to already use them, but let's make that > explicit. Ah, found an exception, vmapped stacks: [ 696.928541] BUG: sleeping function called from invalid context at mm/vmalloc.c:615 [ 696.928576]

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 12:15:41PM +0100, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > > This is how everyone seems to already use them, but let's make that > > explicit. > > Ah, found an exception, vmapped stacks: Oh, fun. So if we can't require

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Wed, Oct 19, 2016 at 12:15:41PM +0100, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > > This is how everyone seems to already use them, but let's make that > > explicit. > > Ah, found an exception, vmapped stacks: Oh, fun. So if we can't require

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Tue, Oct 18, 2016 at 11:33:59AM +0100, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > > This is how everyone seems to already use them, but let's make that > > explicit. > > mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to > the

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Tue, Oct 18, 2016 at 11:33:59AM +0100, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > > This is how everyone seems to already use them, but let's make that > > explicit. > > mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to > the

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > This is how everyone seems to already use them, but let's make that > explicit. mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to the rule. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote: > This is how everyone seems to already use them, but let's make that > explicit. mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to the rule. -Chris -- Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

This is how everyone seems to already use them, but let's make that explicit. Signed-off-by: Christoph Hellwig --- mm/vmalloc.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index d045a10..9830514 100644 --- a/mm/vmalloc.c +++

[PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping

This is how everyone seems to already use them, but let's make that explicit. Signed-off-by: Christoph Hellwig --- mm/vmalloc.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index d045a10..9830514 100644 --- a/mm/vmalloc.c +++