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
Good job fixing the bug. :)
My one concern would be that in set_name() there is a race caused
by dropping the lock. It would be better to do that
copy_from_user() first, before taking the lock. I don't expect this
to actually be a problem in real life.
+ /*
+* Local variable to
Good job fixing the bug. :)
My one concern would be that in set_name() there is a race caused
by dropping the lock. It would be better to do that
copy_from_user() first, before taking the lock. I don't expect this
to actually be a problem in real life.
+ /*
+* Local variable 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
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
6 matches
Mail list logo