lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ