linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Yuri Tikhonov <yur@emcraft.com>
Cc: wd@denx.de, dzu@denx.de, linux-kernel@vger.kernel.org,
	miltonm@bga.com, linuxppc-dev@ozlabs.org, paulus@samba.org,
	viro@zeniv.linux.org.uk, Hugh Dickins <hugh@veritas.com>,
	Geert.Uytterhoeven@sonycom.com, yanok@emcraft.com
Subject: Re: [PATCH][v2] fork_init: fix division by zero
Date: Thu, 18 Dec 2008 14:45:53 -0800	[thread overview]
Message-ID: <20081218144553.91226f50.akpm@linux-foundation.org> (raw)
In-Reply-To: <200812181047.50332.yur@emcraft.com>

On Thu, 18 Dec 2008 10:47:50 +0300
Yuri Tikhonov <yur@emcraft.com> wrote:

> 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;
> 

Looks sane.  But to apply this I'd prefer a changelog, a signoff and a
grunt from Hugh.

Thanks.

  reply	other threads:[~2008-12-18 22:47 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
2008-12-18 22:45       ` Andrew Morton [this message]
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=20081218144553.91226f50.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Geert.Uytterhoeven@sonycom.com \
    --cc=dzu@denx.de \
    --cc=hugh@veritas.com \
    --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 \
    --cc=yur@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;
as well as URLs for NNTP newsgroup(s).