Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2386013pxb; Thu, 11 Feb 2021 10:59:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJzK5BPV+GzfO6NT/rkfVUelFE/yO8txY8ONCMb6p/2X6Q2nZ1chUEm/8mAF12QV/ZJQ40v0 X-Received: by 2002:a17:906:c448:: with SMTP id ck8mr9894953ejb.55.1613069980421; Thu, 11 Feb 2021 10:59:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613069980; cv=none; d=google.com; s=arc-20160816; b=k4cvkV4M3CJgJzGiasuorXJY4h0u8rxCFSYIOxi/X4r3OsrkWgl1arMcO3Z/QjlQNG a5tjT9OkdPRIBqmlXRCqngr4MOQ4jqMDCE0O55gQwvbpJS+k3zEFzH0yoVK3WRrcI0CP ln0L56Kiyqp1OxZWTauKJymOPaiWLeUixk9eTY7dlE7998UM1na+OEXEGDcinm/g2iMa h89qjFz6r3iqYYqzAPaqBs9aGScbrPiu1HUqh07/Anz/1AHNYA8F1yGRqac4S9fMm+Gi edV2Q8OeMJY76WvYmiZuRZtMDwhIzH62LZOcdJKHk+qQ0KcbPRBj/U2o5JtkyUvC1Ezo 9w1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date; bh=OdONO7v5YSY4Kf6YYE0zy9yvJE9CuQXud1fbRINhagQ=; b=RfmZ17rPxaW5tHPjT9jL/0J8WnauyWBtFSsaNfbqJe2GsQoxgMcHnBmPYo6Rp3MDL7 DcPRaBjB9ucrSlFKd6BkkHeYq+3g0JhJDWMZNzQMEjEK4ipvOXiOXjseWQ6h48rUiKgc 5ZeFlIJL1NuBGBfIxhTLCY6X0X2oN7gLn39ZjnoCi8oCHIznZ1QTED7V5ZOc8p3ulT5V rEs00uFStSxi/d8vUabuNPHkMTU0f7Njc5ZgtiAjaEwmqKLb7Pfin7qAvDhUqfnmqBt5 LFqQqwiTngcyLLzlTZBeR8dXAWYkB5rYCGfeGbHdcjTVGLH/xE1afV1G/P8PgrGPJPrT DZPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hq38si3899026ejc.21.2021.02.11.10.59.14; Thu, 11 Feb 2021 10:59:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231637AbhBKS5y (ORCPT + 99 others); Thu, 11 Feb 2021 13:57:54 -0500 Received: from mx2.suse.de ([195.135.220.15]:57594 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230493AbhBKSzP (ORCPT ); Thu, 11 Feb 2021 13:55:15 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 14A0EAD57; Thu, 11 Feb 2021 18:54:29 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 10DDFDA6E9; Thu, 11 Feb 2021 19:52:35 +0100 (CET) Date: Thu, 11 Feb 2021 19:52:34 +0100 From: David Sterba To: Ira Weiny Cc: Matthew Wilcox , Christoph Hellwig , Andrew Morton , clm@fb.com, josef@toxicpanda.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH V2 4/8] mm/highmem: Add VM_BUG_ON() to mem*_page() calls Message-ID: <20210211185234.GG1993@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Ira Weiny , Matthew Wilcox , Christoph Hellwig , Andrew Morton , clm@fb.com, josef@toxicpanda.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20210210062221.3023586-1-ira.weiny@intel.com> <20210210062221.3023586-5-ira.weiny@intel.com> <20210210125502.GD2111784@infradead.org> <20210210162901.GB3014244@iweiny-DESK2.sc.intel.com> <20210210185606.GF308988@casper.infradead.org> <20210210212228.GF3014244@iweiny-DESK2.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210210212228.GF3014244@iweiny-DESK2.sc.intel.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 10, 2021 at 01:22:28PM -0800, Ira Weiny wrote: > On Wed, Feb 10, 2021 at 06:56:06PM +0000, Matthew Wilcox wrote: > > On Wed, Feb 10, 2021 at 08:29:01AM -0800, Ira Weiny wrote: > > > And I thought it was a good idea. Any file system development should have > > > tests with DEBUG_VM which should cover Matthew's concern while not having the > > > overhead in production. Seemed like a decent compromise? > > > > Why do you think these paths are only used during file system development? > > I can't guarantee it but right now most of the conversions I have worked on are > in FS's. > > > They're definitely used by networking, by device drivers of all kinds > > and they're probably even used by the graphics system. > > > > While developers *should* turn on DEBUG_VM during development, a > > shockingly high percentage don't even turn on lockdep. > > Honestly, I don't feel strongly enough to argue it. I checked my devel config and I don't have DEBUG_VM enabled, while I have a bunch of other debugging options related to locking or other fine-grained sanity checks. The help text is not very specific what exactly is being checked other that it hurts performance, so I read it as that it's for MM developers that change the MM code, while in filesystem we use the APIs. However, for the this patchset I'll turn it on all testing instances of course. > Andrew? David? David this is going through your tree so would you feel more > comfortable with 1 or the other? I think it's a question for MM people, for now I assume it's supposed to be VM_BUG_ON.