linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, bugzilla-daemon@bugzilla.kernel.org,
	iceman_dvd@yahoo.com,
	Steven Truelove <steven.truelove@utoronto.ca>
Subject: Re: [Bug 56881] New: MAP_HUGETLB mmap fails for certain sizes
Date: Wed, 24 Apr 2013 19:26:00 -0400	[thread overview]
Message-ID: <20130424232600.GB18686@cmpxchg.org> (raw)
In-Reply-To: <1366844735-kqynvvnu-mutt-n-horiguchi@ah.jp.nec.com>

On Wed, Apr 24, 2013 at 07:05:35PM -0400, Naoya Horiguchi wrote:
> On Wed, Apr 24, 2013 at 11:39:51AM -0400, Johannes Weiner wrote:
> > On Wed, Apr 24, 2013 at 11:16:39AM -0400, Naoya Horiguchi wrote:
> > > On Wed, Apr 24, 2013 at 04:14:54AM -0400, Johannes Weiner wrote:
> > > > @@ -491,10 +491,13 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
> > > >  
> > > >  	sprintf (name, "SYSV%08x", key);
> > > >  	if (shmflg & SHM_HUGETLB) {
> > > > +		unsigned int hugesize;
> > > > +
> > > >  		/* hugetlb_file_setup applies strict accounting */
> > > >  		if (shmflg & SHM_NORESERVE)
> > > >  			acctflag = VM_NORESERVE;
> > > > -		file = hugetlb_file_setup(name, 0, size, acctflag,
> > > > +		hugesize = ALIGN(size, huge_page_size(&default_hstate));
> > > > +		file = hugetlb_file_setup(name, hugesize, acctflag,
> > > >  				  &shp->mlock_user, HUGETLB_SHMFS_INODE,
> > > >  				(shmflg >> SHM_HUGE_SHIFT) & SHM_HUGE_MASK);
> > > >  	} else {
> > > 
> > > Would it be better to find proper hstate instead of using default_hstate?
> > 
> > You are probably right, I guess we can't assume default_hstate anymore
> > after page_size_log can be passed in.
> > 
> > Can we have hugetlb_file_setup() return an adjusted length, or an
> > alignment requirement?
> 
> Yes, it's possible if callers pass the pointer of size (length) to
> hugetlb_file_setup() and make it adjusted inside the function.
> And as for alignment, I think it's not a hugetlb_file_setup's job,
> so we don't have to do it in this function.
> 
> > Or pull the hstate lookup into the callsites (since they pass in
> > page_size_log to begin with)?
> 
> This is also a possible solution, where we might need to define and
> export a function converting hugepage order to hstate.

After thinking about it some more, I would actually prefer this.  The
callsites have all the information and the file setup code should not
really care about the alignment requirements of the callers.

I.e. export something like get_hstate_idx() but which returns hstate,
then make the callers look it up, do the alignment, pass in the
aligned size and hstate instead of page_size_log.  Then they are free
to use the aligned size (mmap) or use the original size (shm).

> I like the former one, so wrote a patch like below.
> # I added your Signed-off-by: because this's based on your draft patch.
> # if you don't like it, please let me know.

Thanks, I appreciate it.  But usually if you take and modify a patch
add the original From: line to the changelog to give credit, then add
your own signoff and only add other people's signoff after they agree.

> @@ -929,9 +929,8 @@ static struct dentry_operations anon_ops = {
>  	.d_dname = hugetlb_dname
>  };
>  
> -struct file *hugetlb_file_setup(const char *name, unsigned long addr,
> -				size_t size, vm_flags_t acctflag,
> -				struct user_struct **user,
> +struct file *hugetlb_file_setup(const char *name, size_t *sizeptr,
> +				vm_flags_t acctflag, struct user_struct **user,
>  				int creat_flags, int page_size_log)
>  {
>  	struct file *file = ERR_PTR(-ENOMEM);
> @@ -939,9 +938,8 @@ struct file *hugetlb_file_setup(const char *name, unsigned long addr,
>  	struct path path;
>  	struct super_block *sb;
>  	struct qstr quick_string;
> -	struct hstate *hstate;
> -	unsigned long num_pages;
>  	int hstate_idx;
> +	size_t size;
>  
>  	hstate_idx = get_hstate_idx(page_size_log);
>  	if (hstate_idx < 0)
> @@ -951,6 +949,10 @@ struct file *hugetlb_file_setup(const char *name, unsigned long addr,
>  	if (!hugetlbfs_vfsmount[hstate_idx])
>  		return ERR_PTR(-ENOENT);
>  
> +	size = 1 << hstate_index_to_shift(hstate_idx);
> +	if (sizeptr)
> +		*sizeptr = ALIGN(*sizeptr, size);

You always assume the file will just be one hugepage in size?

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

  parent reply	other threads:[~2013-04-24 23:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-56881-27@https.bugzilla.kernel.org/>
2013-04-23 20:25 ` Andrew Morton
2013-04-23 22:26   ` Naoya Horiguchi
2013-04-24  8:20     ` Jianguo Wu
2013-04-24 14:17       ` Naoya Horiguchi
2013-04-24  8:14   ` Johannes Weiner
2013-04-24 15:16     ` Naoya Horiguchi
2013-04-24 15:39       ` Johannes Weiner
2013-04-24 23:05         ` Naoya Horiguchi
2013-04-24 23:13           ` Naoya Horiguchi
2013-04-24 23:44             ` Johannes Weiner
2013-04-24 23:26           ` Johannes Weiner [this message]
2013-04-25 21:00             ` Naoya Horiguchi
2013-04-26  4:35               ` [PATCH v2] hugetlbfs: fix mmap failure in unaligned size request Naoya Horiguchi
2013-04-30 16:45                 ` Johannes Weiner
2013-04-30 17:02                   ` [PATCH v3] " Naoya Horiguchi
2013-05-01  8:00                     ` Sam Ben
2013-04-25  3:02           ` [Bug 56881] New: MAP_HUGETLB mmap fails for certain sizes Jianguo Wu
2013-04-25 21:03             ` Naoya Horiguchi
2013-06-12 12:16           ` Aneesh Kumar K.V
2013-06-13 21:29             ` Andrew Morton
2013-06-18 11:14               ` Aneesh Kumar K.V

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=20130424232600.GB18686@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=iceman_dvd@yahoo.com \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=steven.truelove@utoronto.ca \
    /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