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
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
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 a good id
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 please provide the sa
,
Shankar
On Tue, Apr 23, 2013 at 10:54 PM, Robert Love rl...@google.com wrote:
On Tue, Apr 23, 2013 at 12:20 PM, Shankar Brahadeeswaran
shanko...@gmail.com wrote:
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
uses it.
On Thu, Apr 25, 2013 at 7:24 PM, Shankar Brahadeeswaran
shanko...@gmail.com 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 a good idea to do so and hence
>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 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
> 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
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
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
>
> 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
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 even I
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
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/android/ashmem.c | 56 +++
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
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,
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
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 dan.carpen...@oracle.com wrote:
Good job fixing the bug. :)
My one concern
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
.
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 shanko...@gmail.com
Reviewed-by: Dan Carpenter dan.carpen...@oracle.com
---
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
.
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 shanko...@gmail.com
Reviewed-by: Dan Carpenter dan.carpen...@oracle.com
---
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
.
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 shanko...@gmail.com
Reviewed-by: Dan Carpenter dan.carpen...@oracle.com
---
drivers/staging/android/ashmem.c | 45
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
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 the
orruption. 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: Please mark a copy of the reply to
.
If the suggestion is OK, am I allowed to send the patch for the same?
PS: Please mark a copy of the reply to my email id since I'm not
subscribed to linux-kernel@vger.kernel.org
Warm Regards,
Shankar Brahadeeswaran
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
32 matches
Mail list logo
