From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753378AbbBRUYm (ORCPT ); Wed, 18 Feb 2015 15:24:42 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:59790 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752510AbbBRUYl (ORCPT ); Wed, 18 Feb 2015 15:24:41 -0500 Date: Wed, 18 Feb 2015 12:23:55 -0800 From: Guenter Roeck To: Heinrich Schuchardt Cc: Andrew Morton , "Kirill A. Shutemov" , Peter Zijlstra , Oleg Nesterov , Rik van Riel , Vladimir Davydov , Thomas Gleixner , David Rientjes , Kees Cook , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1 v2] kernel/fork.c: avoid division by zero Message-ID: <20150218202355.GA6645@roeck-us.net> References: <1424199698-7607-1-git-send-email-xypron.glpk@gmx.de> <20150217151511.95143a25ff83c165f4199d08@linux-foundation.org> <20150218193814.GB32179@roeck-us.net> <54E4ECFD.6070401@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E4ECFD.6070401@gmx.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-CTCH-PVer: 0000001 X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A020203.54E4F508.0225,ss=1,re=0.001,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-CTCH-Score: 0.001 X-CTCH-ScoreCust: 0.000 X-CTCH-Rules: C_4847, X-CTCH-SenderID: linux@roeck-us.net X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 11 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-TotalRecipients: 0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from get_relayhosts_entry X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 18, 2015 at 08:50:21PM +0100, Heinrich Schuchardt wrote: > On 18.02.2015 20:38, Guenter Roeck wrote: > > On Tue, Feb 17, 2015 at 03:15:11PM -0800, Andrew Morton wrote: > >> On Tue, 17 Feb 2015 20:01:38 +0100 Heinrich Schuchardt wrote: > >> > >>> PAGE_SIZE is not guaranteed to be equal to or less than 8 times the > >>> THREAD_SIZE. > >>> > >>> E.g. architecture hexagon may have page size 1M and thread size 4096. > >>> > >>> This would lead to a division by zero. > >>> > >>> The futex implementation assumes that tids fit into the FUTEX_TID_MASK. > >>> This limits the number of allowable threads. > >>> > >>> ... > >>> > >>> --- a/kernel/fork.c > >>> +++ b/kernel/fork.c > >>> @@ -74,6 +74,7 @@ > >>> #include > >>> #include > >>> #include > >>> +#include > >>> > >>> #include > >>> #include > >>> @@ -255,6 +256,8 @@ void __init __weak arch_task_cache_init(void) { } > >>> > >>> void __init fork_init(unsigned long mempages) > >>> { > >>> + u64 temp; > >> > >> That's a really poor name. We should always try to make names > >> meaningful. Here, something like "threads" would be better. > >> > >>> #ifndef CONFIG_ARCH_TASK_STRUCT_ALLOCATOR > >>> #ifndef ARCH_MIN_TASKALIGN > >>> #define ARCH_MIN_TASKALIGN L1_CACHE_BYTES > >>> @@ -273,7 +276,16 @@ void __init fork_init(unsigned long mempages) > >>> * value: the thread structures can take up at most half > >>> * of memory. > >>> */ > >>> - max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE); > >>> + temp = div64_u64((u64) mempages * (u64) PAGE_SIZE, > >>> + (u64) THREAD_SIZE * 8UL); > >>> + > >>> + /* > >>> + * The futex code assumes that tids fit into the FUTEX_TID_MASK. > >>> + */ > >>> + if (temp < FUTEX_TID_MASK) > >>> + max_threads = temp; > >>> + else > >>> + max_threads = FUTEX_TID_MASK; > >> > >> Seems rather complicated. How about > >> > >> max_threads = mempages / (8 * THREAD_SIZE); > > > > Apparently it is possible that > > mempages < 8 * THREAD_SIZE > > which would result in max_threads == 0. > > > > How about the following ? > > > > max_threads = mempages / DIV_ROUND_UP(8 * THREAD_SIZE, PAGE_SIZE); > > For PAGE_SIZE 2MB and THREAD_SIZE 4kB this is wrong by factor 64. > That really depends on the definition of "wrong", doesn't it ? It would ensure that max_threads is never larger than mempages, which is more defensive. One could also use max_threads = mempages / (max(1, 8 * THREAD_SIZE / PAGE_SIZE)); to solve the original problem without introducing 64 bit operations and without affecting the result for more common architectures. Guenter