public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuri Tikhonov <yur@emcraft.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	wd@denx.de, dzu@denx.de, linux-kernel@vger.kernel.org,
	miltonm@bga.com, linuxppc-dev@ozlabs.org,
	viro@zeniv.linux.org.uk, Geert.Uytterhoeven@sonycom.com,
	yanok@emcraft.com
Subject: Re: [PATCH][v2] fork_init: fix division by zero
Date: Thu, 18 Dec 2008 10:47:50 +0300	[thread overview]
Message-ID: <200812181047.50332.yur@emcraft.com> (raw)
In-Reply-To: <18753.46301.944770.779390@cargo.ozlabs.ibm.com>

Hello Paul,

On Friday 12 December 2008 03:48, Paul Mackerras wrote:
> Andrew Morton writes:
> 
> > > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > >  	max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > > +#else
> > > +	max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
> > > +#endif
> > 
> > The expression you've chosen here can be quite inacccurate, because
> > ((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number.  The way to
> > preserve accuracy is
> 
> The assumption is that THREAD_SIZE is a power of 2, as is PAGE_SIZE.
> 
> I think Yuri should be increasing THREAD_SIZE for the larger page
> sizes he's implementing, because we have on-stack arrays whose size
> depends on the page size.  I suspect that having THREAD_SIZE less than
> 1/8 of PAGE_SIZE risks stack overflows, and the better fix is for Yuri
> to make sure THREAD_SIZE is at least 1/8 of PAGE_SIZE.  (In fact, more
> may be needed - someone should work out what fraction is actually
> needed.)

  Right, thanks for pointing this. I guess, I was just lucky since didn't run into
problems with stack overflows. So, I agree that we should increase the 
THREAD_SIZE in case of 256KB pages up to 1/8 of PAGE_SIZE, that is up 
to 32KB.

 There is one more warning from the common code when I use 256KB pages:

   CC      mm/shmem.o
mm/shmem.c: In function 'shmem_truncate_range':
mm/shmem.c:613: warning: division by zero
mm/shmem.c:619: warning: division by zero
mm/shmem.c:644: warning: division by zero
mm/shmem.c: In function 'shmem_unuse_inode':
mm/shmem.c:873: warning: division by zero

 The problem here is that ENTRIES_PER_PAGEPAGE becomes 0x1.0000.0000
when PAGE_SIZE is 256K.

 How about the following fix ?

diff --git a/mm/shmem.c b/mm/shmem.c
index 0ed0752..99d7c91 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -57,7 +57,7 @@
 #include <asm/pgtable.h>
 
 #define ENTRIES_PER_PAGE (PAGE_CACHE_SIZE/sizeof(unsigned long))
-#define ENTRIES_PER_PAGEPAGE (ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
+#define ENTRIES_PER_PAGEPAGE ((unsigned long long)ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
 #define BLOCKS_PER_PAGE  (PAGE_CACHE_SIZE/512)
 
 #define SHMEM_MAX_INDEX  (SHMEM_NR_DIRECT + (ENTRIES_PER_PAGEPAGE/2) * (ENTRIES_PER_PAGE+1))
@@ -95,7 +95,7 @@ static unsigned long shmem_default_max_inodes(void)
 }
 #endif
 
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
 			 struct page **pagep, enum sgp_type sgp, int *type);
 
 static inline struct page *shmem_dir_alloc(gfp_t gfp_mask)
@@ -533,7 +533,7 @@ static void shmem_truncate_range(struct inode *inode, loff_t start, loff_t end)
 	int punch_hole;
 	spinlock_t *needs_lock;
 	spinlock_t *punch_lock;
-	unsigned long upper_limit;
+	unsigned long long upper_limit;
 
 	inode->i_ctime = inode->i_mtime = CURRENT_TIME;
 	idx = (start + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
@@ -1175,7 +1175,7 @@ static inline struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
  * vm. If we swap it in we mark it dirty since we also free the swap
  * entry since a page cannot live in both the swap and page cache
  */
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
 			struct page **pagep, enum sgp_type sgp, int *type)
 {
 	struct address_space *mapping = inode->i_mapping;

Regards, Yuri

  parent reply	other threads:[~2008-12-18  7:58 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   ` Re[2]: " Yuri Tikhonov
2008-12-11 22:26     ` Andrew Morton
2008-12-12  0:48   ` Paul Mackerras
2008-12-12  1:07     ` Andrew Morton
2008-12-18  7:47     ` Yuri Tikhonov [this message]
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=200812181047.50332.yur@emcraft.com \
    --to=yur@emcraft.com \
    --cc=Geert.Uytterhoeven@sonycom.com \
    --cc=akpm@linux-foundation.org \
    --cc=dzu@denx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.org \
    --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