Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4742104imu; Sat, 19 Jan 2019 17:35:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN4NJ16anQ/VH0Ot4eniXlyO6cPblL2lOoVodDSnZV1PaEJ5ge6UJv/AceJS9/QIHLJ0jfCj X-Received: by 2002:a65:590b:: with SMTP id f11mr23300581pgu.60.1547948119949; Sat, 19 Jan 2019 17:35:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547948119; cv=none; d=google.com; s=arc-20160816; b=YC6n38ACDYd+i9IZRK8+cclib8KmsYlTAdjqQShC/in+9f5XeMXNT0j+2bE97/jR2h rQq4K64wRfU/E2RZeiSRAq1Ye95jFjnYhr/eMLFIZFeSFvPz4cy2bVyla8BOavkiuwwx JCOvXSLV6r7B6B90fo2Vn2D2Ga7mFKe4R0N+ybGbTQtsZZdPPRWuvr4jZqjtwdXExfT6 K4cV9SikO1mW5rcphon8ceEi5lBl2QsS1HlG71cx5A7qluY11ErG9LPEXtlxOQMw32Gl iGuA6Bh/iVzFNpyfgVR7Op91rCEMbTdFxEOftA6kxWK3IvFaJeE/keuZuLakDKWg2OsJ s7qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=phMN8tdoE8CKEHHV7hRbc49SEXrcgU4GwLgLndOL8X4=; b=nhg5YUAZzX4TvJnj69F+qaCJLVlCWXkQmfxI7Gpjsee4bSRLa0+VafT0ONxYs0BmN2 o3su+AegGiSp913Mn8V2zm3JGTg/ArtwSwKlZcqAXa/sliGGy4MFG1U8EYAMx8cLzhje Bv/GVrJnyfUuM4DfFqP6VPPKAAvn6Xni4NR5EArqrd72/o3R0Yb+QmY7I7b4dHcCC/rl QlZs8U/cCylZ1gDJtNPXS/uGrAd9f7oI1xmjoYt0N+PDBnQo+3wmbQmvHK5HjR4zQDtm xYF+hyZxfd60r+bG7Z23cnmiEf+WidrEgwnEZwZMalrWkxfs3Ikw4yHTfWnw5FVjQVob qkjA== 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 4si8497494pla.299.2019.01.19.17.34.30; Sat, 19 Jan 2019 17:35:19 -0800 (PST) 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 S1730028AbfATBbb (ORCPT + 99 others); Sat, 19 Jan 2019 20:31:31 -0500 Received: from www.osadl.org ([62.245.132.105]:53349 "EHLO www.osadl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728596AbfATBba (ORCPT ); Sat, 19 Jan 2019 20:31:30 -0500 Received: from debian01.hofrr.at (178.115.242.59.static.drei.at [178.115.242.59]) by www.osadl.org (8.13.8/8.13.8/OSADL-2007092901) with ESMTP id x0K1V3HF022664; Sun, 20 Jan 2019 02:31:04 +0100 From: Nicholas Mc Guire To: Steve Wise Cc: Doug Ledford , Raju Rangoju , Jason Gunthorpe , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Nicholas Mc Guire Subject: [PATCH RFC] iw_cxgb4: drop check - dead code Date: Sun, 20 Jan 2019 02:27:13 +0100 Message-Id: <1547947633-10515-1-git-send-email-hofrat@osadl.org> X-Mailer: git-send-email 2.1.4 X-Spam-Status: No, score=-1.9 required=6.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on www.osadl.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The kmalloc is called with | __GFP_NOFAIL so there is no point in checking the return value - it either returns valid storage or it would hang/terminate there. But it is not possible to say if the use of __GFP_NOFAIL is really needed and the check should be removed or vice-versa (use of __GFP_NOFAIL should be only in exceptional cases as I understand it and alloc_srq_queue() is called in quite a few places) In either way it would need fixing. Signed-off-by: Nicholas Mc Guire Fixes: 6a0b6174d35a ("rdma/cxgb4: Add support for kernel mode SRQ's") --- Found during code review Patch was compile tested with: x86_64_defconfig + INFINIBAND=y, INFINIBAND_USER_ACCESS=y, CHELSIO_T4=y, INFINIBAND_CXGB4=y (with some unrelated sparse warnings) Q:This also has an interesting dependency with no effect: Depends on:... (INFINIBAND_USER_ACCESS [=n] || !INFINIBAND_USER_ACCESS [=n]) I assume htat INFINIBAND_USER_ACCESS=y should be required here ? Patch is against 5.0-rc2 (localversion-next is next-20190118) drivers/infiniband/hw/cxgb4/qp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c index 917ce5c..c2a12ba 100644 --- a/drivers/infiniband/hw/cxgb4/qp.c +++ b/drivers/infiniband/hw/cxgb4/qp.c @@ -2597,8 +2597,6 @@ static int alloc_srq_queue(struct c4iw_srq *srq, struct c4iw_dev_ucontext *uctx, wr_len = sizeof(*res_wr) + sizeof(*res); skb = alloc_skb(wr_len, GFP_KERNEL | __GFP_NOFAIL); - if (!skb) - goto err_free_queue; set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0); res_wr = (struct fw_ri_res_wr *)__skb_put(skb, wr_len); -- 2.1.4