2013/5/17 Robert Love :
> On Thu, May 16, 2013 at 1:19 PM, Andrew Morton
> wrote:
>> On Thu, 16 May 2013 13:08:17 -0400 Robert Love wrote:
>>> This problem seems a rare proper use of mutex_trylock.
>>
>> Not really. The need for a trylock is often an indication that a
>> subsystem has a locking
2013/5/17 Robert Love rl...@google.com:
On Thu, May 16, 2013 at 1:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Thu, 16 May 2013 13:08:17 -0400 Robert Love rl...@google.com wrote:
This problem seems a rare proper use of mutex_trylock.
Not really. The need for a trylock is often
On Thu, May 16, 2013 at 1:19 PM, Andrew Morton
wrote:
> On Thu, 16 May 2013 13:08:17 -0400 Robert Love wrote:
>> This problem seems a rare proper use of mutex_trylock.
>
> Not really. The need for a trylock is often an indication that a
> subsystem has a locking misdesign. That is indeed the
On Thu, 16 May 2013 13:08:17 -0400 Robert Love wrote:
> On Thu, May 16, 2013 at 12:45 PM, Andrew Morton
> wrote:
> > A better approach would be to add a new __GFP_NOSHRINKERS, but it's all
> > variations on a theme.
>
> I don't like this proposal, either. Many of the existing GFP flags
>
On Thu, May 16, 2013 at 12:45 PM, Andrew Morton
wrote:
> A better approach would be to add a new __GFP_NOSHRINKERS, but it's all
> variations on a theme.
I don't like this proposal, either. Many of the existing GFP flags
already exist to prevent recurse into that flag's respective shrinker.
On Thu, 16 May 2013 09:44:49 -0400 Robert Love wrote:
> On Thu, May 16, 2013 at 4:15 AM, Raul Xiong wrote:
> > The issue happens in such sequence:
> > ashmem_mmap acquired ashmem_mutex --> ashmem_mutex:shmem_file_setup
> > called kmem_cache_alloc --> shrink due to low memory --> ashmem_shrink
>
On Thu, May 16, 2013 at 4:15 AM, Raul Xiong wrote:
> The issue happens in such sequence:
> ashmem_mmap acquired ashmem_mutex --> ashmem_mutex:shmem_file_setup
> called kmem_cache_alloc --> shrink due to low memory --> ashmem_shrink
> tries to acquire the same ashmem_mutex -- it blocks here.
>
> I
2013/5/14 Raul Xiong
>
> 2013/5/14 Neil Zhang :
> > 2013/5/14 Greg Kroah-Hartman :
> >> On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
> >>> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
> >>> into the
> >>> shrinker code from within ashmem. Just bail out,
2013/5/14 Raul Xiong raulxi...@gmail.com
2013/5/14 Neil Zhang glacier1...@gmail.com:
2013/5/14 Greg Kroah-Hartman gre...@linuxfoundation.org:
On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
into the
On Thu, May 16, 2013 at 4:15 AM, Raul Xiong raulxi...@gmail.com wrote:
The issue happens in such sequence:
ashmem_mmap acquired ashmem_mutex -- ashmem_mutex:shmem_file_setup
called kmem_cache_alloc -- shrink due to low memory -- ashmem_shrink
tries to acquire the same ashmem_mutex -- it blocks
On Thu, 16 May 2013 09:44:49 -0400 Robert Love rl...@google.com wrote:
On Thu, May 16, 2013 at 4:15 AM, Raul Xiong raulxi...@gmail.com wrote:
The issue happens in such sequence:
ashmem_mmap acquired ashmem_mutex -- ashmem_mutex:shmem_file_setup
called kmem_cache_alloc -- shrink due to low
On Thu, May 16, 2013 at 12:45 PM, Andrew Morton
a...@linux-foundation.org wrote:
A better approach would be to add a new __GFP_NOSHRINKERS, but it's all
variations on a theme.
I don't like this proposal, either. Many of the existing GFP flags
already exist to prevent recurse into that flag's
On Thu, 16 May 2013 13:08:17 -0400 Robert Love rl...@google.com wrote:
On Thu, May 16, 2013 at 12:45 PM, Andrew Morton
a...@linux-foundation.org wrote:
A better approach would be to add a new __GFP_NOSHRINKERS, but it's all
variations on a theme.
I don't like this proposal, either. Many
On Thu, May 16, 2013 at 1:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Thu, 16 May 2013 13:08:17 -0400 Robert Love rl...@google.com wrote:
This problem seems a rare proper use of mutex_trylock.
Not really. The need for a trylock is often an indication that a
subsystem has a
2013/5/14 Neil Zhang :
> 2013/5/14 Greg Kroah-Hartman :
>> On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
>>> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
>>> into the
>>> shrinker code from within ashmem. Just bail out, avoiding a deadlock.
>>> This is
>>>
2013/5/14 Greg Kroah-Hartman :
> On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
>> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
>> into the
>> shrinker code from within ashmem. Just bail out, avoiding a deadlock.
>> This is
>> fine, as ashmem cache pruning is
On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
> shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
> fine, as ashmem cache pruning is advisory anyhow.
>
> Signed-off-by:
On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
fine, as ashmem cache pruning is advisory anyhow.
Signed-off-by: Robert
2013/5/14 Greg Kroah-Hartman gre...@linuxfoundation.org:
On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
into the
shrinker code from within ashmem. Just bail out, avoiding a deadlock.
This is
fine, as ashmem
2013/5/14 Neil Zhang glacier1...@gmail.com:
2013/5/14 Greg Kroah-Hartman gre...@linuxfoundation.org:
On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
into the
shrinker code from within ashmem. Just bail out,
On Wed, 1 May 2013 09:56:13 -0400 Robert Love wrote:
> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
> shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
> fine, as ashmem cache pruning is advisory anyhow.
>
Sorry, but I don't think
On Wed, 1 May 2013 09:56:13 -0400 Robert Love rl...@google.com wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
fine, as ashmem cache pruning is advisory anyhow.
Sorry, but I
On Thu, May 02, 2013 at 11:22:18AM -0700, David Rientjes wrote:
> On Wed, 1 May 2013, David Rientjes wrote:
>
> > > Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
> > > into the
> > > shrinker code from within ashmem. Just bail out, avoiding a deadlock.
> > > This is
> >
On Wed, 1 May 2013, David Rientjes wrote:
> > Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into
> > the
> > shrinker code from within ashmem. Just bail out, avoiding a deadlock. This
> > is
> > fine, as ashmem cache pruning is advisory anyhow.
> >
> > Signed-off-by:
On Wed, 1 May 2013, David Rientjes wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into
the
shrinker code from within ashmem. Just bail out, avoiding a deadlock. This
is
fine, as ashmem cache pruning is advisory anyhow.
Signed-off-by: Robert Love
On Thu, May 02, 2013 at 11:22:18AM -0700, David Rientjes wrote:
On Wed, 1 May 2013, David Rientjes wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
into the
shrinker code from within ashmem. Just bail out, avoiding a deadlock.
This is
fine, as ashmem
On Wed, 1 May 2013, Robert Love wrote:
> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
> shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
> fine, as ashmem cache pruning is advisory anyhow.
>
> Signed-off-by: Robert Love
Any reason
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
fine, as ashmem cache pruning is advisory anyhow.
Signed-off-by: Robert Love
---
drivers/staging/android/ashmem.c | 6 +-
1 file
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
fine, as ashmem cache pruning is advisory anyhow.
Signed-off-by: Robert Love rl...@google.com
---
drivers/staging/android/ashmem.c | 6
On Wed, 1 May 2013, Robert Love wrote:
Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
fine, as ashmem cache pruning is advisory anyhow.
Signed-off-by: Robert Love rl...@google.com
30 matches
Mail list logo
