linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* kstrdup_quotable_cmdline and gfp flags
@ 2018-11-05 21:32 Rasmus Villemoes
  2018-11-06  8:22 ` Michal Hocko
  0 siblings, 1 reply; 2+ messages in thread
From: Rasmus Villemoes @ 2018-11-05 21:32 UTC (permalink / raw)
  To: Kees Cook, Michal Hocko, Jordan Crouse; +Cc: LKML, Linux-MM

kstrdup_quotable_cmdline takes gfp flags and passes those on to
kstrdup_quotable, but before that it has done a kmalloc(PAGE_SIZE) with
a hard-coded GFP_KERNEL. There is one caller of kstrdup_quotable_cmdline
which passes GFP_ATOMIC, and the commit introducing that (65a3c2748e)
conveniently has this piece of history:

    v2: Use GFP_ATOMIC while holding the rcu lock per Chris Wilson

So, should the GFP_KERNEL in kstrdup_quotable_cmdline simply be changed
to use the passed-in gfp, or is there some deeper reason for the
GFP_KERNEL (in which case it doesn't really make sense to take gfp at
all...)? It came from a tree-wide GFP_TEMPORARY -> GFP_KERNEL conversion.

Rasmus

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: kstrdup_quotable_cmdline and gfp flags
  2018-11-05 21:32 kstrdup_quotable_cmdline and gfp flags Rasmus Villemoes
@ 2018-11-06  8:22 ` Michal Hocko
  0 siblings, 0 replies; 2+ messages in thread
From: Michal Hocko @ 2018-11-06  8:22 UTC (permalink / raw)
  To: Rasmus Villemoes; +Cc: Kees Cook, Jordan Crouse, LKML, Linux-MM

On Mon 05-11-18 22:32:07, Rasmus Villemoes wrote:
> kstrdup_quotable_cmdline takes gfp flags and passes those on to
> kstrdup_quotable, but before that it has done a kmalloc(PAGE_SIZE) with
> a hard-coded GFP_KERNEL. There is one caller of kstrdup_quotable_cmdline
> which passes GFP_ATOMIC, and the commit introducing that (65a3c2748e)
> conveniently has this piece of history:
> 
>     v2: Use GFP_ATOMIC while holding the rcu lock per Chris Wilson
> 
> So, should the GFP_KERNEL in kstrdup_quotable_cmdline simply be changed
> to use the passed-in gfp, or is there some deeper reason for the
> GFP_KERNEL (in which case it doesn't really make sense to take gfp at
> all...)?

I would just drop the gfp argument and move comm = kstrdup(task->comm, GFP_ATOMIC);
before rcu read lock

The code in its current form is buggy.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-11-06  8:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-05 21:32 kstrdup_quotable_cmdline and gfp flags Rasmus Villemoes
2018-11-06  8:22 ` Michal Hocko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).