Received: by 10.192.165.156 with SMTP id m28csp831391imm; Wed, 11 Apr 2018 07:57:19 -0700 (PDT) X-Google-Smtp-Source: AIpwx48U0KuG5/xC6tY8wBBdRyDRY4FTAGRcpxk06pTMxh/82JPw9O5irlMPh2b3dgGahnbSaZGp X-Received: by 2002:a17:902:a582:: with SMTP id az2-v6mr1953573plb.210.1523458639908; Wed, 11 Apr 2018 07:57:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523458639; cv=none; d=google.com; s=arc-20160816; b=Szu8+zB9STHRCIpNqtXuMwQyl37KEzd4R7moJH/yvrVBNMoHNRSmIZPgGfZmO6rkD7 24dcr180agF+LtoTE2z0P0Rrhxzxs/8E/GPbYYBby+wZh65URoK8Zzve23i2OuQB/Niz UkU3dGr47bKTJakyJRK+rsubCfhRrRuNr5dg4hbGF0Q2FcqesZY2qDCT9Orgf5y1fMiY A97uqvQYqeluZkY5gkPrHMRfpW5k9pNsflUbtUYlrrgCgsozC62JRJanTYs348OTJTye C2ONtuQxd8jgEyOs/tN/DhrY/dFZiWA27WIubZx/b+qfV6UCSlwsLDMrX/TKY5vzwvjU 20VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=kKny+HnP3kUqgX5dSbSQfoNds1Zzqh+Mdu/SpP5wolI=; b=vXWciFiILoQKTwBEyc71VwY8irEKgd+5REMj2VquNzVdBEXlArLnhBDCcYawEickve WGZHtNmUn8zTrVnsSr+kk+r2+JxyVshcxXW/6LlDxdtSUT2oh03/DX2SYmXG9ffpzGQB gbF7FqIlwhGeWvrYsachuPyGUr0OTMsMZCyrj5jvzz2DLSBQWwymSIVCM6/+mfrPekVr pAxy2K80M50rIEMc7NNdTE2kFP3mjBFlL3CiNjDQqvSHzuYMsLpaBOyivjix6lCPhreX gVxRzaMOReKfEsSc78IULZ8CPqleaDSyrmY6bkQK1nh6NE3bmXbvd2fcsVcIHQ3OnT9G EbHg== 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 a23si945820pfa.95.2018.04.11.07.56.42; Wed, 11 Apr 2018 07:57:19 -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 S1753550AbeDKOxQ (ORCPT + 99 others); Wed, 11 Apr 2018 10:53:16 -0400 Received: from mga04.intel.com ([192.55.52.120]:26021 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752735AbeDKOxO (ORCPT ); Wed, 11 Apr 2018 10:53:14 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2018 07:53:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,436,1517904000"; d="scan'208";a="219587946" Received: from rogerhay-mobl1.amr.corp.intel.com (HELO [10.252.134.245]) ([10.252.134.245]) by fmsmga006.fm.intel.com with ESMTP; 11 Apr 2018 07:53:13 -0700 Subject: Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4 To: Jia-Ju Bai , faisal.latif@intel.com, shiraz.saleem@intel.com, dledford@redhat.com, sean.hefty@intel.com, hal.rosenstock@gmail.com Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org References: <1523431945-3508-1-git-send-email-baijiaju1990@gmail.com> From: Dennis Dalessandro Message-ID: Date: Wed, 11 Apr 2018 10:53:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1523431945-3508-1-git-send-email-baijiaju1990@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/11/2018 3:32 AM, Jia-Ju Bai wrote: > i40iw_add_mqh_4() is never called in atomic context, because it > calls rtnl_lock() that can sleep. > > Despite never getting called from atomic context, > i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC, > which does not sleep for allocation. > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > which can sleep and improve the possibility of sucessful allocation. Just a general comment. I don't know that this is the greatest idea. I can imagine instances where sleeping is OK as far as how the code is written, but for performance reasons you would rather fail than sleep. As to whether that is the case here I'll let the i40iw folks comment. > This is found by a static analysis tool named DCNS written by myself. > And I also manually check it. You should probably post a pointer to your tool. -Denny