Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2483852imm; Mon, 28 May 2018 08:58:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo79gpjXb5TOTpjmVKAS0aTZP05+NrmP9IoP2DautGk3rMQd3w+sl1DK/Q97fx1o3w2J9j4 X-Received: by 2002:a63:2547:: with SMTP id l68-v6mr11447963pgl.40.1527523109329; Mon, 28 May 2018 08:58:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527523109; cv=none; d=google.com; s=arc-20160816; b=xXZA0Cai+UGutPcp5vNs2fd0e9imFCHLO5tigOw83Ncyxs1RB0nJOc+y1cE5sRGCrQ hxGg18J1aHgvzMt1NYFbTJaynkNnW50g4K6MZcmvFfWtWTtue3BB0lU+WH3OvaCr80cw yglH5yc+qaj0SiKa0Kr9lKLi+DLOyzBN8ZM/FnRjxgyJHG9PWyT1b+vdLZUxrQYXC7Yb ojTe/yvQL9rGqG+wL6p/H3D6aGjeBSR1ZuPUJpShf04Mzk16ihDVNlZc0jg+eqM2RbCR nx839MDkOumS4uvcnCBx7o1hG+dg0SyXazeePKnVLavuU+nlepBjub64fEMnIappWRkr eKEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=TinWZoOuAB9oYM1PVhVG02eb5Y92yx4p5Nb94Ddbfe8=; b=akBHfqWG1ulrvBxffLIfJTijEqinQWkAjoUOlLmDRz1oKq4FkZhxukuU5Is9U5ZRTZ J0xghQYuojxnu0A4aJFmsFXaPSGibgIllEEaNVlGuacGUQvs3CaqEXg4jNRisbszs9JN uP9zzqzQncpGGQGU2yfXWcU6tMdKMomOaR1rLo+0Jkqow6mDR/M2mygAJzoAAqnjx+n5 MaKaG7a4DZxXbijDwGPeQzJKQeMe9udz2MBmQ6sZusXV9SR73Z/a/hlOX0pNAw+L3Bw2 pHBFnW+FjW6rcAx6K69Kl6ZTxvRzPkHBDmtJqE8tZrTZSV+t426TXZsDHumXtIvSPyhA 2/3A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u6-v6si30619801pls.462.2018.05.28.08.58.14; Mon, 28 May 2018 08:58:29 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S939755AbeE1Pzy (ORCPT + 99 others); Mon, 28 May 2018 11:55:54 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:41624 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425305AbeE1Pyi (ORCPT ); Mon, 28 May 2018 11:54:38 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1fNKTT-0007ek-HC; Mon, 28 May 2018 23:54:19 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1fNKTO-0004rI-Al; Mon, 28 May 2018 23:54:14 +0800 Date: Mon, 28 May 2018 23:54:14 +0800 From: Herbert Xu To: Davidlohr Bueso Cc: akpm@linux-foundation.org, torvalds@linux-foundation.org, tgraf@suug.ch, manfred@colorfullife.com, guillaume.knispel@supersonicimagine.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH 1/6] lib/rhashtable: convert param sanitations to WARN_ON Message-ID: <20180528155414.mbwyldat7mn6ro2j@gondor.apana.org.au> References: <20180524211135.27760-1-dave@stgolabs.net> <20180524211135.27760-2-dave@stgolabs.net> <20180528094048.etqeu2ubc227qrxf@gondor.apana.org.au> <20180528131209.mt4ythkapvfvykc7@linux-n805> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180528131209.mt4ythkapvfvykc7@linux-n805> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 28, 2018 at 06:12:09AM -0700, Davidlohr Bueso wrote: > > Well, I don't really _want_ them; nor does the ipc code which already > does a WARN_ON() (but that goes away in future patches). What I want > is to get rid of the return path. So I don't really care if we convert > them to WARN or remove them altogether. Would you be happy with the > later? It has nothing to do with the error return path. Assuming you remove the allocation failure path, then this error path can never trigger for *your* use-case. IOW you can either just ignore the return value for ipc or just do the WARN_ON in your code. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt