From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758641AbcGKNSY (ORCPT ); Mon, 11 Jul 2016 09:18:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35588 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758550AbcGKNSV (ORCPT ); Mon, 11 Jul 2016 09:18:21 -0400 Date: Mon, 11 Jul 2016 09:18:19 -0400 From: Mike Snitzer To: Matthias Dahl Cc: linux-mm@kvack.org, dm-devel@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [4.7.0rc6] Page Allocation Failures with dm-crypt Message-ID: <20160711131818.GA28102@redhat.com> References: <28dc911645dce0b5741c369dd7650099@mail.ud19.udmedia.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 11 Jul 2016 13:18:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 11 2016 at 4:31am -0400, Matthias Dahl wrote: > Hello, > > I made a few more tests and here my observations: > > - kernels 4.4.8 and 4.5.5 show the same behavior > > - the moment dd starts, memory usage spikes rapidly and within a just > a few seconds has filled up all 32 GiB of RAM > > - dd w/ direct i/o works just fine > > - mkfs.ext4 unfortunately shows the same behavior as dd w/o direct i/o > and such makes creation of an ext4 fs on dm-crypt a game of luck > > (much more exposed so with e2fsprogs 1.43.1) > > I am kind of puzzled that this bug has seemingly gone so long unnoticed > since it is rather severe and makes dm-crypt unusable to a certain > degree > for fs encryption (or at least the initial creation of the fs). Am I > missing something here or doing something terribly stupid? Not clear. Certainly haven't had any reports of memory leaks with dm-crypt. Something must explain the execessive nature of your leak but it isn't a known issue. Have you tried running with kmemleak enabled?