Messages in this thread | | | Date | Fri, 22 Mar 2013 22:17:02 +0530 | Subject | Re: [BUG] staging: android: ashmem: Deadlock during ashmem_mmap and ashmem_read | From | Shankar Brahadeeswaran <> |
| |
> 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 once it returns. But if a given thread invokes ashmem_read and sleeps, is there a scenario where some other task can come and access asma->file->f_pos ? If yes, the we'll be returning the older f_pos value. I'm not sure whether this is expected behavior. Since we are not done with the read yet, we can report the old f_pos, I think. So is the below pseudo code OK?
static ssize_t ashmem_read(struct file *file, char __user *buf, size_t len, loff_t *pos) { struct ashmem_area *asma = file->private_data; int ret = 0;
mutex_lock(&ashmem_mutex); .... mutex_unlock(&ashmem_mutex); ret = asma->file->f_op->read(asma->file, buf, len, pos); if (ret < 0) { return ret; }
mutex_lock(&ashmem_mutex); asma->file->f_pos = *pos; out: mutex_unlock(&ashmem_mutex); return ret; }
If this is OK, then similar changes can be done for ashmem_lseek as well.
| |