Thread (20 messages) 20 messages, 11 authors, 2017-01-25

Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants

From: Kees Cook <hidden>
Date: 2017-01-12 17:26:28
Also in: linux-mm, lkml

On Thu, Jan 12, 2017 at 7:37 AM, Michal Hocko [off-list ref] wrote:
quoted hunk ↗ jump to hunk
From: Michal Hocko <mhocko@suse.com>

There are many code paths opencoding kvmalloc. Let's use the helper
instead. The main difference to kvmalloc is that those users are usually
not considering all the aspects of the memory allocator. E.g. allocation
requests < 64kB are basically never failing and invoke OOM killer to
satisfy the allocation. This sounds too disruptive for something that
has a reasonable fallback - the vmalloc. On the other hand those
requests might fallback to vmalloc even when the memory allocator would
succeed after several more reclaim/compaction attempts previously. There
is no guarantee something like that happens though.

This patch converts many of those places to kv[mz]alloc* helpers because
they are more conservative.

Cc: Martin Schwidefsky <redacted>
Cc: Heiko Carstens <redacted>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Anton Vorontsov <redacted>
Cc: Colin Cross <redacted>
Cc: Kees Cook <redacted>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Rafael J. Wysocki" <redacted>
Cc: Ben Skeggs <redacted>
Cc: Kent Overstreet <redacted>
Cc: Santosh Raspatur <redacted>
Cc: Hariprasad S <redacted>
Cc: Tariq Toukan <redacted>
Cc: Yishai Hadas <redacted>
Cc: Dan Williams <redacted>
Cc: Oleg Drokin <redacted>
Cc: Andreas Dilger <redacted>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Sterba <dsterba@suse.com>
Cc: "Yan, Zheng" <redacted>
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Eric Dumazet <redacted>
Cc: netdev@vger.kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 arch/s390/kvm/kvm-s390.c                           | 10 ++-----
 crypto/lzo.c                                       |  4 +--
 drivers/acpi/apei/erst.c                           |  8 ++---
 drivers/char/agp/generic.c                         |  8 +----
 drivers/gpu/drm/nouveau/nouveau_gem.c              |  4 +--
 drivers/md/bcache/util.h                           | 12 ++------
 drivers/net/ethernet/chelsio/cxgb3/cxgb3_defs.h    |  3 --
 drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 25 ++--------------
 drivers/net/ethernet/chelsio/cxgb3/l2t.c           |  2 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c    | 31 ++++----------------
 drivers/net/ethernet/mellanox/mlx4/en_tx.c         |  9 ++----
 drivers/net/ethernet/mellanox/mlx4/mr.c            |  9 ++----
 drivers/nvdimm/dimm_devs.c                         |  5 +---
 .../staging/lustre/lnet/libcfs/linux/linux-mem.c   | 11 +------
 drivers/xen/evtchn.c                               | 14 +--------
 fs/btrfs/ctree.c                                   |  9 ++----
 fs/btrfs/ioctl.c                                   |  9 ++----
 fs/btrfs/send.c                                    | 27 ++++++-----------
 fs/ceph/file.c                                     |  9 ++----
 fs/select.c                                        |  5 +---
 fs/xattr.c                                         | 27 ++++++-----------
 kernel/bpf/hashtab.c                               | 11 ++-----
 lib/iov_iter.c                                     |  5 +---
 mm/frame_vector.c                                  |  5 +---
 net/ipv4/inet_hashtables.c                         |  6 +---
 net/ipv4/tcp_metrics.c                             |  5 +---
 net/mpls/af_mpls.c                                 |  5 +---
 net/netfilter/x_tables.c                           | 34 ++++++----------------
 net/netfilter/xt_recent.c                          |  5 +---
 net/sched/sch_choke.c                              |  5 +---
 net/sched/sch_fq_codel.c                           | 26 ++++-------------
 net/sched/sch_hhf.c                                | 33 ++++++---------------
 net/sched/sch_netem.c                              |  6 +---
 net/sched/sch_sfq.c                                |  6 +---
 security/keys/keyctl.c                             | 22 ++++----------
 35 files changed, 96 insertions(+), 319 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 4f74511015b8..e6bbb33d2956 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1126,10 +1126,7 @@ static long kvm_s390_get_skeys(struct kvm *kvm, struct kvm_s390_skeys *args)
        if (args->count < 1 || args->count > KVM_S390_SKEYS_MAX)
                return -EINVAL;

-       keys = kmalloc_array(args->count, sizeof(uint8_t),
-                            GFP_KERNEL | __GFP_NOWARN);
-       if (!keys)
-               keys = vmalloc(sizeof(uint8_t) * args->count);
+       keys = kvmalloc(args->count * sizeof(uint8_t), GFP_KERNEL);
Before doing this conversion, can we add a kvmalloc_array() API? This
conversion could allow for the reintroduction of integer overflow
flaws. (This particular situation isn't at risk since ->count is
checked, but I'd prefer we not create a risky set of examples for
using kvmalloc.)

Besides that: yes please. Less open coding. :)

-Kees

-- 
Kees Cook
Nexus Security

--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help