linux-kernel - kstrdup_quotable_cmdline and gfp flags

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Message-ID: <84197642-f414-81dc-ee68-1a4c1cdea5ae@rasmusvillemoes.dk>
Date:   Mon, 5 Nov 2018 22:32:07 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Kees Cook <keescook@...omium.org>, Michal Hocko <mhocko@...e.cz>,
        Jordan Crouse <jcrouse@...eaurora.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>
Subject: kstrdup_quotable_cmdline and gfp flags

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