From: Yuri Tikhonov <yur@emcraft.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
<Geert.Uytterhoeven@sonycom.com>, <viro@zeniv.linux.org.uk>,
<dhowells@redhat.com>, <miltonm@bga.com>, <wd@denx.de>,
<dzu@denx.de>, <yanok@emcraft.com>
Subject: Re[2]: [PATCH][v2] fork_init: fix division by zero
Date: Fri, 12 Dec 2008 01:22:32 +0300 [thread overview]
Message-ID: <483237973.20081212012232@emcraft.com> (raw)
In-Reply-To: <20081211121635.ff58193f.akpm@linux-foundation.org>
Hello Andrew,
On Thursday, December 11, 2008 you wrote:
[snip]
> The expression you've chosen here can be quite inacccurate, because
> ((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number.
But why is it bad? We do multiplication to 'mempages', not division.
All the numbers in the multiplier are the power of 2, so both
expressions:
mempages * (PAGE_SIZE / (8 * THREAD_SIZE))
and
max_threads = (mempages * PAGE_SIZE) / (8 * THREAD_SIZE)
are finally equal.
> The way to preserve accuracy is
> max_threads = (mempages * PAGE_SIZE) / (8 * THREAD_SIZE);
> so how about avoiding the nasty ifdefs and doing
I'm OK with the approach below, but, leading resulting to the same,
this involves some overhead to the code where there was no this
overhead before this patch: e.g. your implementation is finally boils
down to ~5 times more processor instructions than there were before,
plus operations with stack for the 'm' variable.
On the other hand, my approach with nasty (I agree) ifdefs doesn't
lead to overheads to the code which does not need this: i.e. the most
common situation of small PAGE_SIZEs. Big PAGE_SIZE is the exception,
so I believe that the more common cases should not suffer because of
this.
> --- a/kernel/fork.c~fork_init-fix-division-by-zero
> +++ a/kernel/fork.c
> @@ -69,6 +69,7 @@
> #include <asm/mmu_context.h>
> #include <asm/cacheflush.h>
> #include <asm/tlbflush.h>
> +#include <asm/div64.h>
>
> /*
> * Protected counters by write_lock_irq(&tasklist_lock)
> @@ -185,10 +186,15 @@ void __init fork_init(unsigned long memp
>
> /*
> * The default maximum number of threads is set to a safe
> - * value: the thread structures can take up at most half
> - * of memory.
> + * value: the thread structures can take up at most
> + * (1/8) part of memory.
> */
> - max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> + {
> + /* max_threads = (mempages * PAGE_SIZE) / THREAD_SIZE / 8; */
> + u64 m = mempages * PAGE_SIZE;
> + do_div(m, THREAD_SIZE * 8);
> + max_threads = m;
> + }
>
> /*
> * we need to allow at least 20 threads to boot a system
> _
> ?
> The code is also inaccurate because it assumes that <whatever allocator
is used for threads>> will pack the thread_structs into pages with best
> possible density, which isn't necessarily the case. Let's not worry
> about that.
> OT:
> max_threads is widly wrong anyway.
> - the caller passes in num_physpages, which includes highmem. And we
> can't allocate thread structs from highmem.
> - num_physpages includes kernel pages and other stuff which can never
> be allocated via the page allocator.
> A suitable fix would be to switch the caller to the strangely-named
> nr_free_buffer_pages().
> If you grep the tree for `num_physpages', you will find a splendid
> number of similar bugs. num_physpages should be unexported, burnt,
> deleted, etc. It's just an invitation to write buggy code.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
next prev parent reply other threads:[~2008-12-11 22:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-10 16:50 [PATCH][v2] fork_init: fix division by zero Yuri Tikhonov
2008-12-11 20:16 ` Andrew Morton
2008-12-11 20:28 ` Al Viro
2008-12-11 20:43 ` Andrew Morton
2008-12-12 2:31 ` Nick Piggin
2008-12-12 2:47 ` Andrew Morton
2008-12-12 3:36 ` Nick Piggin
2008-12-11 22:22 ` Yuri Tikhonov [this message]
2008-12-11 22:26 ` Re[2]: " Andrew Morton
2008-12-12 0:48 ` Paul Mackerras
2008-12-12 1:07 ` Andrew Morton
2008-12-18 7:47 ` Yuri Tikhonov
2008-12-18 22:45 ` Andrew Morton
2008-12-19 5:49 ` Re[2]: " Yuri Tikhonov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=483237973.20081212012232@emcraft.com \
--to=yur@emcraft.com \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dzu@denx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=miltonm@bga.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wd@denx.de \
--cc=yanok@emcraft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox