From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752519AbcGMQZK (ORCPT ); Wed, 13 Jul 2016 12:25:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41625 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751494AbcGMQZF (ORCPT ); Wed, 13 Jul 2016 12:25:05 -0400 Subject: Re: [dm-devel] Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage) To: Matthias Dahl , Michal Hocko References: <02580b0a303da26b669b4a9892624b13@mail.ud19.udmedia.de> <20160712095013.GA14591@dhcp22.suse.cz> <20160712114920.GF14586@dhcp22.suse.cz> <20160712140715.GL14586@dhcp22.suse.cz> <459d501038de4d25db6d140ac5ea5f8d@mail.ud19.udmedia.de> <20160713112126.GH28723@dhcp22.suse.cz> <20160713121828.GI28723@dhcp22.suse.cz> <74b9325c37948cf2b460bd759cff23dd@mail.ud19.udmedia.de> <20160713134717.GL28723@dhcp22.suse.cz> Cc: linux-raid@vger.kernel.org, linux-mm@kvack.org, dm-devel@redhat.com, linux-kernel@vger.kernel.org, Mike Snitzer From: Ondrej Kozina Message-ID: <2704a8dd-48c5-82b8-890e-72bf5e1ed1e1@redhat.com> Date: Wed, 13 Jul 2016 18:24:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 13 Jul 2016 16:24:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/13/2016 05:32 PM, Matthias Dahl wrote: > > No matter what, I have no clue how to further diagnose this issue. And > given that I already had unsolvable issues with dm-crypt a couple of > months ago with my old machine where the system simply hang itself or > went OOM when the swap was encrypted and just a few kilobytes needed to > be swapped out, I am not so sure anymore I can trust dm-crypt with a > full disk encryption to the point where I feel "safe"... as-in, nothing > bad will happen or the system won't suddenly hang itself due to it. Or > if a bug is introduced, that it will actually be possible to diagnose it > and help fix it or that it will even be eventually fixed. Which is > really > a pity, since I would really have liked to help solve this. With the > swap issue, I did git bisects, tests, narrowed it down to kernel > versions > when said bug was introduced... but in the end, the bug is still present > as far as I know. :( > One step after another. Mathias, your original report was not forgotten, it's just not so easy to find the real culprit and fix it without causing yet another regression. See the https://marc.info/?l=linux-mm&m=146825178722612&w=2 thread... Not to mention that on current 4.7-rc7 kernels it behaves yet slightly differently (yet far from ideally). Regards O.