[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-mm-sig
Subject:    [Linaro-mm-sig] ashmem - mmap deadlock with mmap_sem & ashmem_mutex
From:       nishanth.p () gmail ! com (Nishanth Peethambaran)
Date:       2013-02-07 18:41:31
Message-ID: CAMcxFTQEH+1BZcg4QovWCoEDTUKrwzE4FnmvEf2iAkH1QY1iuA () mail ! gmail ! com
[Download RAW message or body]

Is it not better to drop ashmem_lock before taking the mmap_sem?
An example implementation is in v4l2 implementation. The soc-camera
driver lock is dropped before acquiring mmap_sem semaphore and then
soc-camera driver lock is re-acquired.
See vb2_qbuf() in videobuf2-core.c

- Nishanth Peethambaran
  +91-9448074166



On Thu, Feb 7, 2013 at 9:41 PM, Shankar Brahadeeswaran
<shankoo77 at gmail.com> wrote:
> Hi,
>
> I'm working on Android Linux Kernel Vesion 3.0.15 and seeing a
> "deadlock" in the ashmem driver, while handling mmap request. I seek
> your support in finding the correct fix.
> The locks that involved in the dead lock are
> 1) mm->mmap_sem
> 2) ashmem_mutex
>
> The following is the sequence of events that leads to the deadlock.
> There are two threads A and B that belong to the same process
> (system_server) and hence share the mm struct.
> A1) In the A's context an mmap system call is made with an fd of ashmem
> A2) The system call sys_mmap_pgoff acquires the mmap_sem of the "mm"
> and sleeps before calling the .mmap of ashmem i.e before calling
> ashmem_mmap
>
> Now the thread B runs and proceeds to do the following
> B1) In the B's context ashmem ioctl with option ASHMEM_SET_NAME is called.
> B2) Now the code proceeds to acquire the ashmem_mutex and performs a
> "copy_from_user"
> B3) copy_from_user raises a valid exception to copy the data from user
> space and proceeds to handle it gracefully, do_DataAbort -->
> do_page_fault
> B4) In do_page_fault it finds that the mm->mmap_sem is not available
> (Note A & B share the mm) since A has it and sleeps
>
> Now the thread A runs again
> A3) It proceeds to call ashmem_mmap and tries to acquired
> ashmem_mutex, which is not available (is with B) and sleeps.
>
> Now A has acquired mmap_sem and waits for B to release ashmem_mutex
> B has acquired ashmem_mutex and waits for the mmap_sem to be
> available, which is held by A
>
> This creates a dead lock in the system.
> I'm not sure how to use these locks in such a way as to prevent this
> scenario. Any suggestions would be of great help.
>
> Workaround:
> One possible work around is to replace the mutex_lock call made in the
> ashmem_mmap with mutex_trylock and if it fails, wait for few
> milliseconds and try back for few iterations and finally give up after
> few iterations. This will bring the system out deadlock if this
> scneario happens. I myself feel that this suggestion is not clean. But
> I'm unable to think of anything.
> Is there any suggestion to avoid this scenario.
>
> Warm Regards,
> Shankar
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig


[prev in list] [next in list] [prev in thread] [next in thread]