Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp2645031ima; Mon, 22 Oct 2018 13:21:00 -0700 (PDT) X-Google-Smtp-Source: ACcGV62c+twI0PZG3uApo3vknPzZcv1UgkWbfjNR8r0VxMd8iRnhSCFMqs1lYnqWlHDJpw4Lf7UR X-Received: by 2002:a17:902:7203:: with SMTP id ba3-v6mr35881301plb.321.1540239660549; Mon, 22 Oct 2018 13:21:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540239660; cv=none; d=google.com; s=arc-20160816; b=Scly6TIdt7H4w69JPt2WfjGFf7oBkdAPSnLkguba2vSNG+cnhPLLSgJ16ZwtamZRsR rFwzilVC3hiCi4jhZ3HtzBd8fA9/9vyfg53sKq1xTs2VIMBe8S0CIKf4md6rPvKZ5qXy 3dxUrjmidkdfn7Zs3PnjeQMOv19Ql3gckVZUX+nsOS0qXEi8J6G0pv1T2nV5CcCxlXrv Nlt+WHQwaVjqqb9x+pR8ksvE63rWKEz73/KYGR1fNX0uUG2RBJBsoAJ+Cyji3prrKGIl tULY2bOD9AfqBxntk/8CYk1NmPb8zJAlcjfKZjRoHzz5dEBst2LK09iuNMTz6XKnsp6Y kJKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:in-reply-to:references:date :from:cc:to:subject; bh=HhLGMqHXPhN37OxH9xQzYON6LTZTM0jTD0rBQD5tCmM=; b=FzVFZbcuCaDfmQjCFI004PtEB63LKw3RGAYxOdZLjOaC+9li9l5Jw5/xBelwHVQ38g XsqEWl9zXrgs3C/esv7IV7j9v0/FID84Py3asUflqmboa6r4yoTJSgoC34ZfNTiZ/ZF9 iAnLnrbBFAQm/uBJ5WcCtclqAimZhbGKFmFZyqAnBpFQC7FB50rrDr6kpd1wELoT1WoM QRf3qRKEuMVG9HVDZbTR/tLgqruFJVQHBXp21EQu57Apyq/VNTzaJ10Yxdovt6tZvnHa VpVJ1Fjyu++k0OTql7gf7t3GGlB5w2aNisgbiO3Dg5rlsRLHdInXQNRb3vb8WKDzl3hN bX0A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w71-v6si33909627pgd.163.2018.10.22.13.20.45; Mon, 22 Oct 2018 13:21:00 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728653AbeJWEih (ORCPT + 99 others); Tue, 23 Oct 2018 00:38:37 -0400 Received: from mga04.intel.com ([192.55.52.120]:43389 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725788AbeJWEif (ORCPT ); Tue, 23 Oct 2018 00:38:35 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 13:18:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,413,1534834800"; d="scan'208";a="83268375" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.77.144]) by orsmga007.jf.intel.com with ESMTP; 22 Oct 2018 13:18:37 -0700 Subject: [PATCH 1/9] mm/resource: return real error codes from walk failures To: linux-kernel@vger.kernel.org Cc: Dave Hansen , dan.j.williams@intel.com, dave.jiang@intel.com, zwisler@kernel.org, vishal.l.verma@intel.com, thomas.lendacky@amd.com, akpm@linux-foundation.org, mhocko@suse.com, linux-nvdimm@lists.01.org, linux-mm@kvack.org, ying.huang@intel.com, fengguang.wu@intel.com From: Dave Hansen Date: Mon, 22 Oct 2018 13:13:19 -0700 References: <20181022201317.8558C1D8@viggo.jf.intel.com> In-Reply-To: <20181022201317.8558C1D8@viggo.jf.intel.com> Message-Id: <20181022201319.471D7B85@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org walk_system_ram_range() can return an error code either becuase *it* failed, or because the 'func' that it calls returned an error. The memory hotplug does the following: ret = walk_system_ram_range(..., func); if (ret) return ret; and 'ret' makes it out to userspace, eventually. The problem is, walk_system_ram_range() failues that result from *it* failing (as opposed to 'func') return -1. That leads to a very odd -EPERM (-1) return code out to userspace. Make walk_system_ram_range() return -EINVAL for internal failures to keep userspace less confused. This return code is compatible with all the callers that I audited. Cc: Dan Williams Cc: Dave Jiang Cc: Ross Zwisler Cc: Vishal Verma Cc: Tom Lendacky Cc: Andrew Morton Cc: Michal Hocko Cc: linux-nvdimm@lists.01.org Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: Huang Ying Cc: Fengguang Wu --- b/kernel/resource.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN kernel/resource.c~memory-hotplug-walk_system_ram_range-returns-neg-1 kernel/resource.c --- a/kernel/resource.c~memory-hotplug-walk_system_ram_range-returns-neg-1 2018-10-22 13:12:21.000930395 -0700 +++ b/kernel/resource.c 2018-10-22 13:12:21.003930395 -0700 @@ -375,7 +375,7 @@ static int __walk_iomem_res_desc(resourc int (*func)(struct resource *, void *)) { struct resource res; - int ret = -1; + int ret = -EINVAL; while (start < end && !find_next_iomem_res(start, end, flags, desc, first_lvl, &res)) { @@ -453,7 +453,7 @@ int walk_system_ram_range(unsigned long unsigned long flags; struct resource res; unsigned long pfn, end_pfn; - int ret = -1; + int ret = -EINVAL; start = (u64) start_pfn << PAGE_SHIFT; end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1; _