> 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
On Thu, Mar 21, 2013 at 10:06 AM, Bjorn Bringert wrote:
> I did implement ashmem_read, but I had no idea what I was doing. Calling the
> VFS read function seemed like an obvious way to do it, but it might be
> wrong. If that needs fixing, then the similar VFS call in ashmem_llseek
> probably
On Thu, Mar 21, 2013 at 10:06 AM, Bjorn Bringert bring...@google.com wrote:
I did implement ashmem_read, but I had no idea what I was doing. Calling the
VFS read function seemed like an obvious way to do it, but it might be
wrong. If that needs fixing, then the similar VFS call in ashmem_llseek
>
> 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
On Wed, Mar 20, 2013 at 09:08:03PM +0530, Shankar Brahadeeswaran wrote:
> Hi Greg, Dan,
>
> Few days back I posted a patch to fix a dead lock issue in the ashmem
> driver that got merged in staging-next branch
> https://lkml.org/lkml/2013/2/20/429
>
> I'm seeing that there exists another path in
On Wed, Mar 20, 2013 at 09:08:03PM +0530, Shankar Brahadeeswaran wrote:
> Hi Greg, Dan,
>
> Few days back I posted a patch to fix a dead lock issue in the ashmem
> driver that got merged in staging-next branch
> https://lkml.org/lkml/2013/2/20/429
>
> I'm seeing that there exists another path in
On Wed, Mar 20, 2013 at 09:08:03PM +0530, Shankar Brahadeeswaran wrote:
Hi Greg, Dan,
Few days back I posted a patch to fix a dead lock issue in the ashmem
driver that got merged in staging-next branch
https://lkml.org/lkml/2013/2/20/429
I'm seeing that there exists another path in the
On Wed, Mar 20, 2013 at 09:08:03PM +0530, Shankar Brahadeeswaran wrote:
Hi Greg, Dan,
Few days back I posted a patch to fix a dead lock issue in the ashmem
driver that got merged in staging-next branch
https://lkml.org/lkml/2013/2/20/429
I'm seeing that there exists another path in the
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
12 matches
Mail list logo
