Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932192Ab3CVOml (ORCPT ); Fri, 22 Mar 2013 10:42:41 -0400 Received: from mail-ia0-f178.google.com ([209.85.210.178]:51452 "EHLO mail-ia0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933447Ab3CVOmh (ORCPT ); Fri, 22 Mar 2013 10:42:37 -0400 MIME-Version: 1.0 In-Reply-To: References: <20130320165339.GA28307@kroah.com> Date: Fri, 22 Mar 2013 20:12:36 +0530 Message-ID: Subject: Re: [BUG] staging: android: ashmem: Deadlock during ashmem_mmap and ashmem_read From: Shankar Brahadeeswaran To: Bjorn Bringert Cc: Robert Love , Dan Carpenter , Andrew Morton , Konstantin Khlebnikov , devel@driverdev.osuosl.org, LKML , Hugh Dickins , Greg Kroah-Hartman Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1523 Lines: 40 > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/