Received: by 10.192.165.148 with SMTP id m20csp697919imm; Fri, 20 Apr 2018 13:59:48 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/wPl7oi/mwGFlJSWz9cE8e3Pg3Pd5a3i0IMJQ99Js+wBeolArxLz8TWwV8imEHCeyrmYWk X-Received: by 10.101.96.10 with SMTP id m10mr9609669pgu.281.1524257988451; Fri, 20 Apr 2018 13:59:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524257988; cv=none; d=google.com; s=arc-20160816; b=XiJK7mOY4hA6kt+ZdFLbOgPYowGJszSFBzO1rUQqmOOQRlWay9n3DL6kchNYUND9Q7 pd5BIr+v/VCM/g9625AlbcJFmeE5KvZbz7e3QvYLfdsiLyGyQCA5zOYV1uZ1k0zH4xXW ZK5WRtOC2m5d7+yMjM/9sYDzjjJJxZtfghWKoJz09qeMc849ysnqt2bLRtsrN1XrCE0g GvFzGWuY7knrSGUvMCu2r2NkC06jCbbiWRoL2pz8NzuIh3G1rGHxxCKO1WMklyqX1CVS RMrSAZYkTUeQYWZmuTpMf+KaYKCTuuV1ds/aCYCA4tjGEwyliQMrfagRwcknnraO2q7G prIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=+/evC8wffsrZnzEdBR26ad86vIswMoSMvLpSwiIeLPU=; b=JmaJabWd0mHvD1fKiaWQP1Pg0nKDXtFndWDy90g/tm8QpW0NfbBGa+192SRea67qo/ SUCJwc7c+nou50saGn78M4GFG5vthAihZUDYmk+9xj4WXSTLdWEZ4kg2gMojmue+j+SQ yLMJDMHxCYSynWuB3LJKMKH183aiGwP6D9zJUp2+JfAgCwMY2q+D1UGhvkzqj7Q8IVP6 20geInYzbsVxiIpOinANT6XO4sEm3PCE3ICYXJplawQWhYaV6QZ3m9csuewomGiSyDnI kmt5tHpS3n0oG5zUnfAeuTXj4yn204FiSRo8WzZIJWqBd//sLsXVNw2lkW9q5pxO34bO EnZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n19si5203484pgc.229.2018.04.20.13.59.11; Fri, 20 Apr 2018 13:59:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753041AbeDTU4P (ORCPT + 99 others); Fri, 20 Apr 2018 16:56:15 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:54694 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751882AbeDTU4N (ORCPT ); Fri, 20 Apr 2018 16:56:13 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E69508DC4E; Fri, 20 Apr 2018 20:56:12 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CE87FAFD79; Fri, 20 Apr 2018 20:56:07 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id w3KKu7ui028735; Fri, 20 Apr 2018 16:56:07 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w3KKu7pS028731; Fri, 20 Apr 2018 16:56:07 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Fri, 20 Apr 2018 16:56:07 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Michal Hocko cc: Matthew Wilcox , David Miller , Andrew Morton , linux-mm@kvack.org, eric.dumazet@gmail.com, edumazet@google.com, bhutchings@solarflare.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, virtualization@lists.linux-foundation.org, dm-devel@redhat.com, Vlastimil Babka Subject: Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM In-Reply-To: <20180420134901.GB17484@dhcp22.suse.cz> Message-ID: References: <3e65977e-53cd-bf09-bc4b-0ce40e9091fe@gmail.com> <20180418.134651.2225112489265654270.davem@davemloft.net> <20180420130852.GC16083@dhcp22.suse.cz> <20180420134136.GD10788@bombadil.infradead.org> <20180420134901.GB17484@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-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 20 Apr 2018 20:56:13 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 20 Apr 2018 20:56:13 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mpatocka@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Apr 2018, Michal Hocko wrote: > On Fri 20-04-18 06:41:36, Matthew Wilcox wrote: > > On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote: > > > > In order to detect these bugs reliably I submit this patch that changes > > > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on. > > > > > > No way. This is just wrong! First of all, you will explode most likely > > > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be > > > enabled quite often. > > > > I think it'll still suit Mikulas' debugging needs if we always use > > vmalloc for sizes above PAGE_SIZE? > > Even if that was the case then this doesn't sounds like CONFIG_DEBUG_VM > material. We do not want a completely different behavior when the config > > -- > Michal Hocko > SUSE Labs I'm not arguing that it must be turned on exactly by CONFIG_DEBUG_VM. It may be turned on some other option that is enabled in debug kernels (CONFIG_DEBUG_SG may be a better option, because you'll get meaningful stracktraces from DMA API then). > is enabled. If we really need some better fallback testing coverage > then the fault injection, as suggested by Vlastimil, sounds much more > reasonable to me People who test kernels will install the kernel-debug package, reboot to the debug kernel and run their testsuites. They won't turn on magic options in debugfs or use some hideous kernel commandline arguments. If the kvmalloc test isn't in the debug kernel, then the testing crew won't test it - that's it. Mikulas