All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier@cisco.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Li Zefan <lizf@cn.fujitsu.com>,
	adobriyan@gmail.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH -v2] memdup_user(): introduce
Date: Sat, 07 Mar 2009 08:54:14 -0800	[thread overview]
Message-ID: <adaeix9ff49.fsf@cisco.com> (raw)
In-Reply-To: <20090307084805.7cf3d574@infradead.org> (Arjan van de Ven's message of "Sat, 7 Mar 2009 08:48:05 -0800")

 > I would like to question the use of the gfp argument here;
 > copy_from_user sleeps, so you can't use GFP_ATOMIC anyway.
 > You can't use GFP_NOFS etc, because the pagefault path will happily do
 > things that are equivalent, if not identical, to GFP_KERNEL.

That's a convincing argument, and furthermore, strndup_user() does not
take a gfp parameter, so interface consistency also argues that the
function prototype should just be

void *memdup_user(const void __user *src, size_t len);

(By the way, the len parameter of strndup_user() is declared as long,
which seems strange, since it matches neither the userspace strndup()
nor the kernel kstrndup(), which both use size_t.  So using size_t for
memdup_user() and possibly fixing strndup_user() to use size_t as well
seems like the sanest thing)

 - R.



WARNING: multiple messages have this Message-ID (diff)
From: Roland Dreier <rdreier@cisco.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Li Zefan <lizf@cn.fujitsu.com>,
	adobriyan@gmail.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH -v2] memdup_user(): introduce
Date: Sat, 07 Mar 2009 08:54:14 -0800	[thread overview]
Message-ID: <adaeix9ff49.fsf@cisco.com> (raw)
In-Reply-To: <20090307084805.7cf3d574@infradead.org> (Arjan van de Ven's message of "Sat, 7 Mar 2009 08:48:05 -0800")

 > I would like to question the use of the gfp argument here;
 > copy_from_user sleeps, so you can't use GFP_ATOMIC anyway.
 > You can't use GFP_NOFS etc, because the pagefault path will happily do
 > things that are equivalent, if not identical, to GFP_KERNEL.

That's a convincing argument, and furthermore, strndup_user() does not
take a gfp parameter, so interface consistency also argues that the
function prototype should just be

void *memdup_user(const void __user *src, size_t len);

(By the way, the len parameter of strndup_user() is declared as long,
which seems strange, since it matches neither the userspace strndup()
nor the kernel kstrndup(), which both use size_t.  So using size_t for
memdup_user() and possibly fixing strndup_user() to use size_t as well
seems like the sanest thing)

 - R.


--
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:[~2009-03-07 16:54 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06  7:04 [RFC][PATCH] kmemdup_from_user(): introduce Li Zefan
2009-03-06  7:04 ` Li Zefan
2009-03-06  7:23 ` Américo Wang
2009-03-06  7:23   ` Américo Wang
2009-03-06  7:37   ` KOSAKI Motohiro
2009-03-06  7:37     ` KOSAKI Motohiro
2009-03-06  8:03     ` KOSAKI Motohiro
2009-03-06  8:03       ` KOSAKI Motohiro
2009-03-06  7:39   ` Li Zefan
2009-03-06  7:39     ` Li Zefan
2009-03-06  8:20 ` Alexey Dobriyan
2009-03-06  8:20   ` Alexey Dobriyan
2009-03-06  8:27   ` Li Zefan
2009-03-06  8:27     ` Li Zefan
2009-03-06  8:39     ` Andrew Morton
2009-03-06  8:39       ` Andrew Morton
2009-03-06  8:57       ` Alexey Dobriyan
2009-03-06  8:57         ` Alexey Dobriyan
2009-03-06  9:09         ` KOSAKI Motohiro
2009-03-06  9:09           ` KOSAKI Motohiro
2009-03-06  9:01       ` Li Zefan
2009-03-06  9:01         ` Li Zefan
2009-03-06  9:15         ` Andrew Morton
2009-03-06  9:15           ` Andrew Morton
2009-03-06  9:49           ` [PATCH -v2] memdup_user(): introduce Li Zefan
2009-03-06  9:49             ` Li Zefan
2009-03-06 23:03             ` Andrew Morton
2009-03-06 23:03               ` Andrew Morton
2009-03-07 16:48               ` Arjan van de Ven
2009-03-07 16:48                 ` Arjan van de Ven
2009-03-07 16:54                 ` Roland Dreier [this message]
2009-03-07 16:54                   ` Roland Dreier
2009-03-07 18:27                 ` Andrew Morton
2009-03-07 18:27                   ` Andrew Morton
2009-03-09  2:22                 ` Li Zefan
2009-03-09  2:22                   ` Li Zefan
2009-03-09  3:00                   ` Andrew Morton
2009-03-09  3:00                     ` Andrew Morton
2009-03-09  3:30                     ` Li Zefan
2009-03-09  3:30                       ` Li Zefan
2009-03-09  3:45                       ` Andrew Morton
2009-03-09  3:45                         ` Andrew Morton
2009-03-06  9:03     ` [RFC][PATCH] kmemdup_from_user(): introduce Alexey Dobriyan
2009-03-06  9:03       ` Alexey Dobriyan
2009-03-06  9:02       ` Li Zefan
2009-03-06  9:02         ` Li Zefan

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=adaeix9ff49.fsf@cisco.com \
    --to=rdreier@cisco.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.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.