linux-kernel - Re: [PATCH] Round up huge page count to avoid allocating too little memory when 'size' argument is not a multiple of the huge page size.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 26 Feb 2012 18:46:45 -0500
From:	Steven Truelove <steven.truelove@...ronto.ca>
To:	"wli@...omorphy.com" <wli@...omorphy.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Round up huge page count to avoid allocating too little
 memory when 'size' argument is not a multiple of the huge page size.

Well, PAGE_ALIGN(addr) is already defined as  ALIGN(addr, PAGE_SIZE), so 
ALIGN can be used with the huge page size easily enough.

In this case however, the code is calculating a number of pages, not an 
address, so I feel my patch is appropriate.

FYI, I ran into this issue while allocating huge pages as shared memory 
in userspace.  shmget would always succeed, but shmat would fail unless 
the requested size mapped closely to the huge page size.  shmget would 
round up to the nearest PAGE_SIZE, but when allocating huge pages this 
obviously isn't enough.

On systems with multiple huge page sizes, it isn't obvious what the huge 
page size will be for a shmget request.  It only becomes obvious in 
hugetlbfs, so that is where I made the change.

Regards,

Steven Truelove

On 26/02/2012 4:24 PM, wli@...omorphy.com wrote:
>
> It might be a good idea to introduce a hugepage analogue of 
> PAGE_ALIGN() for this purpose.
>
> I'll try to get a more normal email setup at some point.
>
> -- wli
>
>
> On February 23, 2012 at 8:28 AM Steven Truelove 
> <steven.truelove@...ronto.ca> wrote:
>
> > Signed-off-by: Steven Truelove <steven.truelove@...ronto.ca>
> > ---
> >  fs/hugetlbfs/inode.c |    8 +++++---
> >  1 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> > index 1e85a7a..fce2527 100644
> > --- a/fs/hugetlbfs/inode.c
> > +++ b/fs/hugetlbfs/inode.c
> > @@ -938,6 +938,8 @@ struct file *hugetlb_file_setup(const char 
> *name, size_t size,
> >          struct path path;
> >          struct dentry *root;
> >          struct qstr quick_string;
> > +        struct hstate *hstate;
> > +        int num_pages;
> >
> >          *user = NULL;
> >          if (!hugetlbfs_vfsmount)
> > @@ -967,10 +969,10 @@ struct file *hugetlb_file_setup(const char 
> *name, size_t size,
> >          if (!inode)
> >                  goto out_dentry;
> >
> > +        hstate = hstate_inode(inode);
> > +        num_pages = (size + huge_page_size(hstate) - 1) >> 
> huge_page_shift(hstate);
> >          error = -ENOMEM;
> > -        if (hugetlb_reserve_pages(inode, 0,
> > -                        size >> 
> huge_page_shift(hstate_inode(inode)), NULL,
> > -                        acctflag))
> > +        if (hugetlb_reserve_pages(inode, 0, num_pages, NULL, 
> acctflag))
> >                  goto out_inode;
> >
> >          d_instantiate(path.dentry, inode);
> > --
> > 1.7.3.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/