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>
next prev parent 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.