Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753590Ab0L1MYH (ORCPT ); Tue, 28 Dec 2010 07:24:07 -0500 Received: from mail-bw0-f46.google.com ([209.85.214.46]:46623 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753230Ab0L1MYE (ORCPT ); Tue, 28 Dec 2010 07:24:04 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X00sseI5X4OC8vCJz5wF4ZhYVmNVoQ2XuW3JgsRH+lPbhLiFGB1VA2onYrRg0m8Rbk P/7o2KxgOXIp0/pKoWc6JuQH5yytHcm04X9WlGXswQl+J3VOUqC/sXW11wqW/jF2R5mG mNZiE9/MvPozCVy8K5XQvClPibiEX03B6lI8Q= MIME-Version: 1.0 In-Reply-To: References: <1292870624-25450-1-git-send-email-felipe.contreras@nokia.com> <1293452486-notmuch-felipe.contreras@nokia.com> Date: Tue, 28 Dec 2010 14:24:03 +0200 Message-ID: Subject: Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly From: Felipe Contreras To: Ohad Ben-Cohen Cc: Felipe Contreras , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, greg@kroah.com, omar.ramirez@ti.com, fernando.lugo@ti.com, nm@ti.com, ameya.palande@nokia.com, h-kanigeri2@ti.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: 1653 Lines: 39 On Tue, Dec 28, 2010 at 2:18 PM, Ohad Ben-Cohen wrote: > On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras > wrote: >> I haven't investigated why that happens, but kernel-space should not >> panic regardless of what user-space does. > > Agree of course. But that's not what we were discussing... Well, hopefully after applying your patch it would be easier to figure that out. >>> Anyhow, a thread that is calling proc_*_dma() will both increase the >>> reference count and decrease it back before going back to user space. >>> Otherwise your patch would be problematic as well - who will unlock >>> the mutex you take in proc_*_dma() ? >> >> I'm saying that user-space might crash *before* proc_*_dma() finishes, >> before the reference count has been decreased. >> >> In my patch there would be no issue because proc_un_map() would wait >> until proc_*_dma() has released the lock. > > But what will happen if, as you say, user-space would crash before > proc_*_dma() has released the lock ? how could proc_un_map() run ? user-space crashed, not kernel-space; the code would continue to run and eventually release the lock. > This is all good, and I have no problem with it. As I said, I don't > resist your patch as a temporary fix. But it doesn't mean I like it... Yeah, so the chances of getting this fixed on 2.6.37 are dimmed. -- Felipe Contreras -- 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/