From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 3 Mar 2017 15:34:03 -0800 From: Andrew Morton To: Pavel Tatashin Cc: linux-mm@kvack.org, sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org, David Miller Subject: Re: [PATCH v3 1/4] sparc64: NG4 memset 32 bits overflow Message-Id: <20170303153403.182c7088b14fa8401b9cf8b3@linux-foundation.org> In-Reply-To: <1488432825-92126-2-git-send-email-pasha.tatashin@oracle.com> References: <1488432825-92126-1-git-send-email-pasha.tatashin@oracle.com> <1488432825-92126-2-git-send-email-pasha.tatashin@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: On Thu, 2 Mar 2017 00:33:42 -0500 Pavel Tatashin wrote: > Early in boot Linux patches memset and memcpy to branch to platform > optimized versions of these routines. The NG4 (Niagra 4) versions are > currently used on all platforms starting from T4. Recently, there were M7 > optimized routines added into UEK4 but not into mainline yet. So, even with > M7 optimized routines NG4 are still going to be used on T4, T5, M5, and M6 > processors. > > While investigating how to improve initialization time of dentry_hashtable > which is 8G long on M6 ldom with 7T of main memory, I noticed that memset() > does not reset all the memory in this array, after studying the code, I > realized that NG4memset() branches use %icc register instead of %xcc to > check compare, so if value of length is over 32-bit long, which is true for > 8G array, these routines fail to work properly. > > The fix is to replace all %icc with %xcc in these routines. (Alternative is > to use %ncc, but this is misleading, as the code already has sparcv9 only > instructions, and cannot be compiled on 32-bit). > > This is important to fix this bug, because even older T4-4 can have 2T of > memory, and there are large memory proportional data structures in kernel > which can be larger than 4G in size. The failing of memset() is silent and > corruption is hard to detect. > > Signed-off-by: Pavel Tatashin > Reviewed-by: Babu Moger It sounds like this fix should be backported into -stable kernels? If so, which version(s)? Also, what are the user-visible runtime effects of this change? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Date: Fri, 03 Mar 2017 23:34:03 +0000 Subject: Re: [PATCH v3 1/4] sparc64: NG4 memset 32 bits overflow Message-Id: <20170303153403.182c7088b14fa8401b9cf8b3@linux-foundation.org> List-Id: References: <1488432825-92126-1-git-send-email-pasha.tatashin@oracle.com> <1488432825-92126-2-git-send-email-pasha.tatashin@oracle.com> In-Reply-To: <1488432825-92126-2-git-send-email-pasha.tatashin@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Pavel Tatashin Cc: linux-mm@kvack.org, sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org, David Miller On Thu, 2 Mar 2017 00:33:42 -0500 Pavel Tatashin wrote: > Early in boot Linux patches memset and memcpy to branch to platform > optimized versions of these routines. The NG4 (Niagra 4) versions are > currently used on all platforms starting from T4. Recently, there were M7 > optimized routines added into UEK4 but not into mainline yet. So, even with > M7 optimized routines NG4 are still going to be used on T4, T5, M5, and M6 > processors. > > While investigating how to improve initialization time of dentry_hashtable > which is 8G long on M6 ldom with 7T of main memory, I noticed that memset() > does not reset all the memory in this array, after studying the code, I > realized that NG4memset() branches use %icc register instead of %xcc to > check compare, so if value of length is over 32-bit long, which is true for > 8G array, these routines fail to work properly. > > The fix is to replace all %icc with %xcc in these routines. (Alternative is > to use %ncc, but this is misleading, as the code already has sparcv9 only > instructions, and cannot be compiled on 32-bit). > > This is important to fix this bug, because even older T4-4 can have 2T of > memory, and there are large memory proportional data structures in kernel > which can be larger than 4G in size. The failing of memset() is silent and > corruption is hard to detect. > > Signed-off-by: Pavel Tatashin > Reviewed-by: Babu Moger It sounds like this fix should be backported into -stable kernels? If so, which version(s)? Also, what are the user-visible runtime effects of this change?