[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJsYZ5n84Jcb+zXiJAh10tmoxeTX2ySKY8HTVLs=r6Fd_8+CXg@mail.gmail.com>
Date: Fri, 22 Mar 2013 22:17:02 +0530
From: Shankar Brahadeeswaran <shankoo77@...il.com>
To: Robert Love <rlove@...gle.com>
Cc: Bjorn Bringert <bringert@...gle.com>,
Dan Carpenter <dan.carpenter@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Konstantin Khlebnikov <khlebnikov@...nvz.org>,
devel@...verdev.osuosl.org, LKML <linux-kernel@...r.kernel.org>,
Hugh Dickins <hughd@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [BUG] staging: android: ashmem: Deadlock during ashmem_mmap and ashmem_read
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists