Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1085191pxu; Wed, 6 Jan 2021 11:50:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJzOMTIaX/UvmAE2/jJRT4tWkSjtXIAvBBXnxw9S1IrB6KtTj0b8b28h72o+SlDHzLgVaFj4 X-Received: by 2002:aa7:db14:: with SMTP id t20mr5050615eds.158.1609962644829; Wed, 06 Jan 2021 11:50:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609962644; cv=none; d=google.com; s=arc-20160816; b=MVEFz5CEbYru/7ddIpHSCZ53I/EiXKcqSHyV5gJGc5AjX5AIzItOdVpDghnBw8wcKL l4axx0Nn2syTRQs7KDP6daOCU2pYBZblyTimM+lHZJACdOU4q/kd1M0WnVnrepNEC/9b fpRKTrUyLva9U6U9qm6k6U5lF9belS1eamAK0LawUQ582PVFzxXtYrXFiWN9RbXLh8lq +IB+k04pbBkFDXbtNPL5s6fY1qDLdGkCBNkLduSrhdGsuYGjqHQLzVosWkt4tRm5SmwE tqmWHTwXdf6MngDgvLQYPg7c+wlNf/mcCNKk9h0t7Y2vZZ1aKLxLa6UdxccjS+87kcZ9 YyzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=RufHzsTjEVCbevLEkjammUx+O5WVGOsdkJ340THGUB4=; b=WK0Ej58r8n49jBkDxaHhqLyrQE+VnEm3ZB8I18hnC+vObU4ZebZvBzrsO3043vQBZE mgr50Imz3JygHKScnpYT0zbUcV+ZZhnRdLZmLodrqH432xYJqPsi4kp9XfGfn0UO2Nt9 rjKEu9pke0k8qBkVlfCbvnQ1aa06FU85I/iR7wRFvqk8gB+CCS/bu+YHmwoZoZzPt5a+ j6P1XStcZ6QhaZdiSnoc28Jjq7ClIPkNh6tQa0aIHV0ymRX/LwIFeeizAbBtlvwMAysA pxOfwqtRpCpR8InUmVnUQcJwiHF/C/3EN95QbmWmhI74UpLWyLbfNHro7rJ5LfInwUlx OgTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=lOdJhUQa; 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 yd29si1252109ejb.741.2021.01.06.11.50.21; Wed, 06 Jan 2021 11:50:44 -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; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=lOdJhUQa; 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 S1726880AbhAFTrC (ORCPT + 99 others); Wed, 6 Jan 2021 14:47:02 -0500 Received: from mail.kernel.org ([198.145.29.99]:45758 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726494AbhAFTrC (ORCPT ); Wed, 6 Jan 2021 14:47:02 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4B00123131; Wed, 6 Jan 2021 19:46:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1609962381; bh=mTkPqvalyZGT+HNCgL8RBG8IvEJHEcO8w9JgqACOlqk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lOdJhUQafw8lhnLzWFVEy8xjLN97baNoa8CetSHuHg+wkKl6LbziGFBbfNl4FMqrT vu5eHaNGbgR9wcM8KVJ9C+TCtUEwuJsYX5dc4fKzyXkG7bhaR92EnBWv8NUH6C8bDy BjS+g2qj8JhLYGOuRb7YWqbfl48p7+SuMShXOmcg= Date: Wed, 6 Jan 2021 11:46:20 -0800 From: Andrew Morton To: Hugh Dickins Cc: Alex Shi , Minchan Kim , Andrea Arcangeli , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/mmap: replace if (cond) BUG() with BUG_ON() Message-Id: <20210106114620.5c221690f3a9cad7afcc3077@linux-foundation.org> In-Reply-To: References: <1607743586-80303-1-git-send-email-alex.shi@linux.alibaba.com> <1607743586-80303-2-git-send-email-alex.shi@linux.alibaba.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Jan 2021 20:28:27 -0800 (PST) Hugh Dickins wrote: > Alex, please consider why the authors of these lines (whom you > did not Cc) chose to write them without BUG_ON(): it has always > been preferred practice to use BUG_ON() on predicates, but not on > functionally effective statements (sorry, I've forgotten the proper > term: I'd say statements with side-effects, but here they are not > just side-effects: they are their main purpose). > > We prefer not to hide those away inside BUG macros Should we change that? I find BUG_ON(something_which_shouldnt_fail()) to be quite natural and readable. As are things like the existing BUG_ON(mmap_read_trylock(mm)); BUG_ON(wb_domain_init(&global_wb_domain, GFP_KERNEL)); etc. No strong opinion here, but is current mostly-practice really useful?