From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753080AbdJLP2j (ORCPT ); Thu, 12 Oct 2017 11:28:39 -0400 Received: from mga07.intel.com ([134.134.136.100]:63593 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751712AbdJLP20 (ORCPT ); Thu, 12 Oct 2017 11:28:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,366,1503385200"; d="scan'208";a="1024511481" Date: Thu, 12 Oct 2017 08:28:25 -0700 From: Andi Kleen To: Michal Hocko Cc: Luis Felipe Sandoval Castro , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, vbabka@suse.cz, mingo@kernel.org, rientjes@google.com, n-horiguchi@ah.jp.nec.com, salls@cs.ucsb.edu, Cristopher Lameter Subject: Re: [PATCH v1] mm/mempolicy.c: Fix get_nodes() off-by-one error. Message-ID: <20171012152825.GJ5109@tassilo.jf.intel.com> References: <1507296994-175620-1-git-send-email-luis.felipe.sandoval.castro@intel.com> <1507296994-175620-2-git-send-email-luis.felipe.sandoval.castro@intel.com> <20171012084633.ipr5cfxsrs3lyb5n@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171012084633.ipr5cfxsrs3lyb5n@dhcp22.suse.cz> User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 12, 2017 at 10:46:33AM +0200, Michal Hocko wrote: > [CC Christoph who seems to be the author of the code] Actually you can blame me. I did the mistake originally. It was found many years ago, but then it was already too late to change. > Andi has voiced a concern about backward compatibility but I am not sure > the risk is very high. The current behavior is simply broken unless you > use a large maxnode anyway. What kind of breakage would you envision > Andi? libnuma uses the available number of nodes as max. So it would always lose the last one with your chance. Your change would be catastrophic. The only way to fix it really would be to define a new syscall. But I don't think it is needed, the existing maxnode+1 interface works (just should be properly documented) -Andi