From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935177AbdEVOxB (ORCPT ); Mon, 22 May 2017 10:53:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43662 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934881AbdEVOw4 (ORCPT ); Mon, 22 May 2017 10:52:56 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E909D804F0 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mpatocka@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E909D804F0 Date: Mon, 22 May 2017 10:52:44 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Michal Hocko cc: Junaid Shahid , David Rientjes , Alasdair Kergon , Mike Snitzer , Andrew Morton , linux-mm@kvack.org, andreslc@google.com, gthelen@google.com, vbabka@suse.cz, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() In-Reply-To: <20170522120937.GI8509@dhcp22.suse.cz> Message-ID: References: <20170518185040.108293-1-junaids@google.com> <20170518190406.GB2330@dhcp22.suse.cz> <1508444.i5EqlA1upv@js-desktop.svl.corp.google.com> <20170519074647.GC13041@dhcp22.suse.cz> <20170522093725.GF8509@dhcp22.suse.cz> <20170522120937.GI8509@dhcp22.suse.cz> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 22 May 2017 14:52:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 22 May 2017, Michal Hocko wrote: > On Mon 22-05-17 08:00:11, Mikulas Patocka wrote: > > > > On Mon, 22 May 2017, Michal Hocko wrote: > > > > > > Sometimes, I/O to a device mapper device is blocked until the userspace > > > > daemon dmeventd does some action (for example, when dm-mirror leg fails, > > > > dmeventd needs to mark the leg as failed in the lvm metadata and then > > > > reload the device). > > > > > > > > The dmeventd daemon mlocks itself in memory so that it doesn't generate > > > > any I/O. But it must be able to call ioctls. __GFP_HIGH is there so that > > > > the ioctls issued by dmeventd have higher chance of succeeding if some I/O > > > > is blocked, waiting for dmeventd action. It reduces the possibility of > > > > low-memory-deadlock, though it doesn't eliminate it entirely. > > > > > > So what happens if the memory reserves are depleted. Do we deadlock? > > > > Yes, it will deadlock. > > That would be more than unfortunate and begs for a different solution. > The thing is that __GFP_HIGH is not propagated to all allocations in the > vmalloc proper. E.g. page table allocations are hardcoded GFP_KERNEL. For a typical device mapper use, the ioctl area is smaller than 4k, so the vmalloc won't happen. > > > Why is OOM killer insufficient to allow the further progress? > > > > I don't know if the OOM killer will or won't be triggered in this > > situation, it depends on the people who wrote the OOM killer. > > I am not sure I understand. OOM killer is invoked for _all_ allocations > <= PAGE_ALLOC_COSTLY_ORDER that do not have __GFP_NORETRY as long as the > OOM killer is not disabled (oom_killer_disable) and that only happens > from the PM suspend path which makes sure that no userspace is active at > the time. AFAIU this is a userspace triggered path and so the later > shouldn't apply to it and GFP_KERNEL should be therefore sufficient. > Relying to a portion of memory reserves to prevent from deadlock seems > fundamentaly broken to me. > > -- > Michal Hocko > SUSE Labs The lvm2 was designed this way - it is broken, but there is not much that can be done about it - fixing this would mean major rewrite. The only thing we can do about it is to lower the deadlock probability with __GFP_HIGH (or PF_MEMALLOC that was used some times ago). Mikulas