> 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.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
