From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966168AbbD1Uga (ORCPT ); Tue, 28 Apr 2015 16:36:30 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:33087 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966059AbbD1Ug2 (ORCPT ); Tue, 28 Apr 2015 16:36:28 -0400 Date: Tue, 28 Apr 2015 22:36:25 +0200 From: Michal Hocko To: Linus Torvalds Cc: linux-mm , Cyril Hrubis , Andrew Morton , Hugh Dickins , Michel Lespinasse , Rik van Riel , Michael Kerrisk , LKML , Linux API Subject: Re: Should mmap MAP_LOCKED fail if mm_poppulate fails? Message-ID: <20150428203625.GA9664@dhcp22.suse.cz> References: <20150114095019.GC4706@dhcp22.suse.cz> <1430223111-14817-1-git-send-email-mhocko@suse.cz> <20150428164302.GI2659@dhcp22.suse.cz> <20150428183535.GB30918@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 28-04-15 11:38:35, Linus Torvalds wrote: > On Tue, Apr 28, 2015 at 11:35 AM, Michal Hocko wrote: > > > > I am still not sure I see the problem here. > > Basically, I absolutely hate the notion of us doing something > unsynchronized, when I can see us undoing a mmap that another thread > is doing. It's wrong. > > You also didn't react to all the *other* things that were wrong in > that patch-set. The games you play with !fatal_signal_pending() etc > are just crazy. I planed to get to those later, because I felt the locks vs. racing mmaps argument was the most important objection. > End result: I absolutely detest the whole thing. I told you what I > consider an acceptable solution instead, that is much simpler and > doesn't have any of the problems of your patchset. I will surely think about those. As I've written in the cover email already, I am fine with patching the man page and be clear about a long term behavior. The primary motivation for this RFC was to start the discussion. -- Michal Hocko SUSE Labs