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
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 ca
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
> alread
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.
This
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, avo
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
>>> fi
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: Rober
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 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: Rob
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 n
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 change
15 matches
Mail list logo
