All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	"zhangyi (F)" <yi.zhang@huawei.com>,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	mawilcox@microsoft.com, viro@zeniv.linux.org.uk,
	miaoxie@huawei.com
Subject: Re: [PATCH] dax: fix potential overflow on 32bit machine
Date: Tue, 5 Dec 2017 12:19:28 -0700	[thread overview]
Message-ID: <20171205191928.GB21010@linux.intel.com> (raw)
In-Reply-To: <20171205173713.GA26021@bombadil.infradead.org>

On Tue, Dec 05, 2017 at 09:37:13AM -0800, Matthew Wilcox wrote:
> On Tue, Dec 05, 2017 at 10:07:09AM -0700, Ross Zwisler wrote:
> > >  /* The 'colour' (ie low bits) within a PMD of a page offset.  */
> > >  #define PG_PMD_COLOUR	((PMD_SIZE >> PAGE_SHIFT) - 1)
> > > +#define PG_PMD_NR	(PMD_SIZE >> PAGE_SHIFT)
> > 
> > I wonder if it's confusing that PG_PMD_COLOUR is a mask, but PG_PMD_NR is a
> > count?  Would "PAGES_PER_PMD" be clearer, in the spirit of
> > PTRS_PER_{PGD,PMD,PTE}? 
> 
> Maybe.  I don't think that 'NR' can ever be confused with a mask.
> I went with PG_PMD_NR because I didn't want to use HPAGE_PMD_NR, but
> in retrospect I just needed to go to sleep and leave thinking about
> hard problems like naming things for the morning.  I decided to call it
> 'colour' rather than 'mask' originally because I got really confused with
> PMD_MASK masking off the low bits.  If you ask 'What colour is this page
> within the PMD', you know you're talking about the low bits.
> 
> I actually had cause to define PMD_ORDER in a separate unrelated patch
> I was working on this morning.  How does this set of definitions grab you?
> 
> #define PMD_ORDER	(PMD_SHIFT - PAGE_SHIFT)
> #define PMD_PAGES	(1UL << PMD_ORDER)
> #define PMD_PAGE_COLOUR	(PMD_PAGES - 1)
> 
> and maybe put them in linux/mm.h so everybody can see them?

Yep, I personally like these better, and putting them in a global header seems
like the right way to go.

> > Also, can we use the same define both in fs/dax.c and in mm/truncate.c,
> > instead of the latter using HPAGE_PMD_NR?
> 
> I'm OK with the latter using HPAGE_PMD_NR because it's explicitly "is
> this a huge page?"  But I'd kind of like to get rid of a lot of the HPAGE_*
> definitions, so 

I would also like to get rid of them if possible, but quick grep makes me
think that unfortunately they may not be entirely equivalent to other defines
we have?

i.e:

arch/metag/include/asm/page.h:# define HPAGE_SHIFT      13
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      14
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      15
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      16
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      17
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      18
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      19
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      20
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      21
arch/metag/include/asm/page.h:# define HPAGE_SHIFT      22

this arch has no PMD_SHIFT definition...

I'm not really familiar with the HPAGE defines, though, so maybe it's not as
complex as it seems.

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-12-05 19:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05  3:32 [PATCH] dax: fix potential overflow on 32bit machine zhangyi (F)
2017-12-05  5:24 ` Matthew Wilcox
2017-12-05  5:24   ` Matthew Wilcox
2017-12-05  8:40   ` zhangyi (F)
2017-12-05  8:40     ` zhangyi (F)
2017-12-05 17:07   ` Ross Zwisler
2017-12-05 17:37     ` Matthew Wilcox
2017-12-05 19:19       ` Ross Zwisler [this message]
2017-12-05 19:54         ` Matthew Wilcox

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=20171205191928.GB21010@linux.intel.com \
    --to=ross.zwisler@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mawilcox@microsoft.com \
    --cc=miaoxie@huawei.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=yi.zhang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.