>
> Why not copy the android developers who wrote this code on this thread?
>
> greg k-h
Adding Robert Love & Bjorn Bringert who added most part of the ashmem code.
> Umm... why does it need to hold that mutex past having checked that
> asma->file is non-NULL, anyway?
Not sure. As I mentioned e
Hi Dan,
Thanks for the feedback. I have incorporated both your review comments
and have re-tested the patch.
I'll submit the patch for approval.
Warm Regards,
Shankar
On Tue, Feb 19, 2013 at 7:08 PM, Dan Carpenter wrote:
> Good job fixing the bug. :)
>
> My one concern would be that in set_nam
Shankar Brahadeeswaran (1):
staging: android: ashmem: get_name,set_name not to hold
ashmem_mutex
drivers/staging/android/ashmem.c | 44 -
1 files changed, 33 insertions(+), 11 deletions(-)
--
1.7.6
--
To unsubscribe from this list: send the line
everse the lock order.
Testing:
Created a unit test case to reproduce the problem.
Used the same to test this fix on kernel version 3.4.0
Ported the same patch to 3.8
Signed-off-by: Shankar Brahadeeswaran
Reviewed-by: Dan Carpenter
---
drivers/staging/android/ashmem.c | 44 +++
Hi Dan,
Fixed the review comments and re-tested again.
Hope the patch is clean atleast this time.
Warm regards,
Shankar
Shankar Brahadeeswaran (1):
staging: android: ashmem: get_name,set_name not to hold
ashmem_mutex
drivers/staging/android/ashmem.c | 56
everse the lock order.
Testing:
Created a unit test case to reproduce the problem.
Used the same to test this fix on kernel version 3.4.0
Ported the same patch to 3.8
Signed-off-by: Shankar Brahadeeswaran
Reviewed-by: Dan Carpenter
---
drivers/staging/android/ashmem.c | 56 +++
Hi Dan,
Oh, now I got what you say. Thanks for your patience.
I have done the necessary modifications.
Re-submitting the patch here
Shankar Brahadeeswaran (1):
staging: android: ashmem: get_name,set_name not to hold
ashmem_mutex
drivers/staging/android/ashmem.c | 45
everse the lock order.
Testing:
Created a unit test case to reproduce the problem.
Used the same to test this fix on kernel version 3.4.0
Ported the same patch to 3.8
Signed-off-by: Shankar Brahadeeswaran
Reviewed-by: Dan Carpenter
---
drivers/staging/an
>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.
> You don't want to hold ashmem_mutex across the VFS calls. It is only
> needed to protect the ashmem-internal structures.
In the ashmem_read function, after the VFS call the asma structure
gets updated again. So one option is to drop the lock before invoking
the VFS call and then take it again on
> You don't want to hold ashmem_mutex across the VFS calls. It is only
> needed to protect the ashmem-internal structures.
In the ashmem_read function, after the VFS call the asma structure
gets updated again. So one option is to drop the lock before invoking
the VFS call and then take it again on
Hi Robert,
Thanks for the patch. In the first email in this thread I was
proposing the same solution and had asked whether doing this has any
side effects.
That is how this discussion started. I did some experiments and have
got the answers for that. Just for every ones benefit I've re-worded
the q
tex,
but looks like its necessary.
Warm Regards,
Shankar
On Tue, Apr 23, 2013 at 10:54 PM, Robert Love wrote:
> On Tue, Apr 23, 2013 at 12:20 PM, Shankar Brahadeeswaran
> wrote:
>
>> I'm unable to think of a straight forward way to fix this. If you have
>> any suggestions p
rocess uses it.
On Thu, Apr 25, 2013 at 7:24 PM, Shankar Brahadeeswaran
wrote:
> Hi Robert,
> Thanks for the feedback.
>
>> This doesn't look insurmountable. It isn't necessary AFAICT to hold
>> ashmem_mutex across shmem_file_setup.
>
> I thought it may not be
Hi,
I'm working on Android Linux Kernel (version 3.4) and seeing a
"deadlock" in the ashmem driver, while handling mmap request.
I seek your support to fix the same. 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 t
"list_del corruption. next->prev should be %p, "
"but was %p\n", entry, next->prev))
__list_del(prev, next);
}
Please provide your feedback on the suggestion.
If the suggestion is OK, am I allowed to send the patch for the same?
PS: Pleas
16 matches
Mail list logo
