>ashmem originally did not support read or write operations, just mmap,
>which is all 99% of users want. The original concurrency model with
>per-mapping ashmem_mutex's works fine there.
The situation I'm reporting here does not involve read/write. This is
to do with ashmem_mmap and ashmem_shrink.
The following is the control flow that could lead to dead lock
ashmem_mmap
|
----> ashmem_mutex acquired
|
-----> shmem_file_setup
|
------> several calls that leads to __alloc_pages
| Now assuming that low memory condition is hit,
we could enter into reclaim path
..... ---------> shrink_slab (calls all the shrinker functions)
|
-----> ashmem_shrink --- Tries to acquire the same
ashmem_mutex that is taken
in this same path while in ashmem_mmap
leading to dead lock.
I'm unable to think of a straight forward way to fix this. If you have
any suggestions please provide the same.
If we are unable to solve this too with minor mods, as suggested by
Dan we have to re-look at the locking in this driver.
Warm Regards,
Shankar
On Mon, Apr 22, 2013 at 8:13 PM, Robert Love <rl...@google.com> wrote:
> On Mon, Apr 22, 2013 at 10:22 AM, Dan Carpenter
> <dan.carpen...@oracle.com> wrote:
>> Read Al's email again: https://lkml.org/lkml/2013/3/20/458
>>
>> I don't know much about VFS locking, but the ashmem locking seems
>> pretty bogus to me. Why can't multiple threads read() at the same
>> time?
>
> ashmem originally did not support read or write operations, just mmap,
> which is all 99% of users want. The original concurrency model with
> per-mapping ashmem_mutex's works fine there. It is only with the later
> addition of read and write that locking becomes a cluster. If there
> isn't an obvious way to refactor the locking, I'd suggest removing
> read and write.
>
> Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
