Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932204Ab3DVOn6 (ORCPT ); Mon, 22 Apr 2013 10:43:58 -0400 Received: from mail-qc0-f177.google.com ([209.85.216.177]:40119 "EHLO mail-qc0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754827Ab3DVOnv (ORCPT ); Mon, 22 Apr 2013 10:43:51 -0400 MIME-Version: 1.0 In-Reply-To: <20130422142218.GA26760@mwanda> References: <20130422142218.GA26760@mwanda> Date: Mon, 22 Apr 2013 10:43:50 -0400 Message-ID: Subject: Re: [BUG] staging: android: ashmem: Deadlock during ashmem_shrink From: Robert Love To: Dan Carpenter Cc: Shankar Brahadeeswaran , LKML , Bjorn Bringert , Al Viro , devel@driverdev.osuosl.org, Hugh Dickins , Greg Kroah-Hartman , anjanavk12@gmail.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 913 Lines: 21 On Mon, Apr 22, 2013 at 10:22 AM, Dan Carpenter wrote: > Read Al's email again: https://lkml.org/lkml/2013/3/20/458 > > I don't know much about VFS locking, but the ashmem locking seems > pretty bogus to me. Why can't multiple threads read() at the same > time? ashmem originally did not support read or write operations, just mmap, which is all 99% of users want. The original concurrency model with per-mapping ashmem_mutex's works fine there. It is only with the later addition of read and write that locking becomes a cluster. If there isn't an obvious way to refactor the locking, I'd suggest removing read and write. Robert -- 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/