Received: by 10.192.165.148 with SMTP id m20csp677143imm; Fri, 4 May 2018 18:08:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoQOHOQJz+6fADEsTthHscYbLZD6KwvpgUKQiPUejvL5Yc1Lc+VAcnGoHgX8KgQdwxBs6Qe X-Received: by 2002:a17:902:9a9:: with SMTP id 38-v6mr30272462pln.114.1525482531833; Fri, 04 May 2018 18:08:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525482531; cv=none; d=google.com; s=arc-20160816; b=b8z2fKKUBVVwRtHR/qZIlakr7fLrhEGHCCb6lEdEsX1MB82hw26VikBniTHug+dqNr HJOCK5aXiel1SH6a2ksYO3QHaW3pNweRbpT6LxkfSkP6O1g1+WcR15vQiDq+3Sk/+GvV BHnJSbnOaAUtW96Blc6x+Y8b0xkKkxO7BbCTD0eTVLTSReimVasDfjXyGDtA9KKXFTC5 Qo2YSIuKXoIR+iof4kwODQzo7EVU0Mw0Iw7AEpu07Ruv625Fa8aoX9lnq9RD1wFU6pWZ Ztnl8YtJkhhKvWuaNqKYc2UIsPhi/JlrFEf4hVOkL4QS767Xr3ETt3P6XqaWxJCG+fIB 8jEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :mime-version:dkim-signature:arc-authentication-results; bh=EAnEZRkYyd4eLCO4CzoG4MvCmzeVdvj7HRosn5wCFfE=; b=pMCFRd1XGFUuI0WaUrg0ypXB67O/Garh+QYyuA0/AOiEotA3o9VSBiHa7mTYKcj48f JssYN/VA7BA1Ld0HYOWMC1e/qcxMBK1ryR5NH5fiFf9v5L6n90QJZ6mgs9dlXPRTcgHY 00SMGY5yRnFxcpmRdbWngzRonF2tvq6FCfMN4WZMsaCGYNg1qSZQZL1Hdv6Ty/0B8ZqG 5dy5y1xEfPdCUkag8GqbdPsTBTyoV60pP/ldk3c4OF5NPKEUGjn9weoR3Hy7RU1Sytz8 fr/NJcBC5jO7CYFpnvKQXiMKWezojQjurtnfbOS3TT8p7Jrh2sEsVvkSMY57z1YAdgY1 TyRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Q2DMgEPh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l13-v6si13967415pgq.201.2018.05.04.18.08.36; Fri, 04 May 2018 18:08:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Q2DMgEPh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846AbeEEBI0 (ORCPT + 99 others); Fri, 4 May 2018 21:08:26 -0400 Received: from mail-ua0-f175.google.com ([209.85.217.175]:35667 "EHLO mail-ua0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751747AbeEEBIZ (ORCPT ); Fri, 4 May 2018 21:08:25 -0400 Received: by mail-ua0-f175.google.com with SMTP id a2so14727825uak.2 for ; Fri, 04 May 2018 18:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=EAnEZRkYyd4eLCO4CzoG4MvCmzeVdvj7HRosn5wCFfE=; b=Q2DMgEPhGjHO7veIhFn/LG+U50HuD7BTKkZSUXxlbzYJZJwI4bvIqL6LUro559H23f 2OWRlYKYBwZNsJcPcGgTl/d0dw3p70XvoAbSP5M01gP8vpxlFqTRv+Lso71Rn4G4EGj3 6V6mWv+Qg+JkCJhhulDYBDBrXwQnI27avXUZgx1evSKurud88zDSn8smTjb8y86R6yoS mqjgKC5BKtpJN3eSJNZYCXhSDACgpU40NGYuxk8xXtwJY43r6wmwVDttgmihLAj8ghHh GYyb8lL9PmjIN7xjMR7UVv2AQLW9Vdxr00IZzm/jnHa+N1+Syii0oIJ62E55gIV90gse 05MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=EAnEZRkYyd4eLCO4CzoG4MvCmzeVdvj7HRosn5wCFfE=; b=LNTRjdJEUl+5KJCc9eh0/vxw1QJXiFr6tmZYSHjptmxttjL/7olyOaMaUh2NQ0z4lE 3tbXd/miqU7OT9PfH+j2tKNLXn5ckJRJJLYUdur7G5oMkDoVPZZmgzcC8P3DYDmJ7XSg vLTmseR0nO8LA20Pp2mvtk0J5A5JFzNEKpNeOJ7djQlk+Up7DcjCrw+5SJn78+hkXz0D 9+nfPwHorsaRLJVfphm4DdUixuHfFyLr6BWx7HkdIht8xXRCgnryiQ5vaodmo/eEZGV1 IrlsVMy1TjHbTZaw4DqJcyBo9anVtY/IvT0yDWPWMJeJKMs7Jm+ZIVBbpGEoWr5y6zyg 6SeA== X-Gm-Message-State: ALQs6tAW0VUGb8KW3sNvk41k/+ztZXqCqXRs/XMFohpPdYlc8C4W7mb4 zTJRLfEY+wLcrVk13Y8sNj2Qd3NhL9rJJG0yxrtd8ftxR3c= X-Received: by 10.176.0.178 with SMTP id 47mr26106301uaj.74.1525482504674; Fri, 04 May 2018 18:08:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.11.209 with HTTP; Fri, 4 May 2018 18:08:23 -0700 (PDT) From: Kees Cook Date: Fri, 4 May 2018 18:08:23 -0700 Message-ID: Subject: *alloc API changes To: Matthew Wilcox Cc: Linux-MM , LKML , Rasmus Villemoes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, After writing up this email, I think I don't like this idea, but I'm still curious to see what people think of the general observations... The number of permutations for our various allocation function is rather huge. Currently, it is: system or wrapper: kmem_cache_alloc, kmalloc, vmalloc, kvmalloc, devm_kmalloc, dma_alloc_coherent, pci_alloc_consistent, kmem_alloc, f2fs_kvalloc, and probably others I haven't found yet. allocation method (not all available in all APIs): regular (kmalloc), zeroed (kzalloc), array (kmalloc_array), zeroed array (kcalloc) with or without node argument: +_node so, for example, we have things like: kmalloc_array_node() or pci_zalloc_consistent() Using some attempts at static analysis with git grep and coccinelle, nearly all of these take GFP flags, but something near 80% of functions are using GFP_KERNEL. Roughly half of the callers are including a sizeof(). Only 20% are using zeroing, 15% are using products as a size, and 3% are using ..._node, etc. I wonder if we might be able to rearrange our APIs for the general case and include a common "kitchen sink" API for the less common options. I.e. why do we have an entire set of _node() APIs, 2 sets for zeroing (kzalloc, kcalloc), etc. kmalloc()-family was meant to be a simplification of kmem_cache_alloc(). vmalloc() duplicated the kmalloc()-family, and kvmalloc() does too. Then we have "specialty" allocators (devm, dma, pci, f2fs, xfs's kmem) that have subsets and want to perform other actions around the base allocators or have their own entirely (e.g. dma). Instead of all the variations, it seems like we just want a per-family alloc() and alloc_attrs(), where alloc_attrs() could handle the less common stuff (e.g. gfp, zero, node). kmalloc(size, GFP_KERNEL) becomes a nice: kmalloc(size) However, then kzalloc(size, GFP_KERNEL) becomes the ugly: kmalloc_attrs(size, GFP_KERNEL, ALLOC_ZERO, NUMA_NO_NODE); (But I guess we could make macro wrappers for zeroing, or node?) But this doesn't solve the multiplication overflow case at all, which is my real goal. Trying to incorporate some of the ideas from other threads, maybe we could have a multiplication helper that would saturate and the allocator would see that as a signal to return NULL? e.g.: inline size_t mult(size_t a, size_t b) { if (b != 0 && a >= SIZE_MAX / b) return SIZE_MAX; return a * b; } (really, this kind of helper should be based on Rasmus's helpers which do correct type handling) void *kmalloc(size_t size) { if (size == SIZE_MAX) return NULL; kmalloc_attrs(size, GFP_KERNEL, ALLOC_NOZERO, NUMA_NO_NODE); } then we get: var = kmalloc(mult(num, sizeof(*var))); we could drop the *calloc(), *zalloc(), and *_array(), leaving only *alloc() and *alloc_attrs() for all the allocator families. I honestly can't tell if this is worse than doing all the family conversions to *calloc() and *_array() for the 1000ish instances of 2-factor products used for size arguments in the *alloc() functions. We could still nest them for the 3-factor ones? var = kmalloc(multi(row, mult(column, sizeof(*var)))); But now we're just pretending to be LISP. And really, I'd like to keep the nicer *alloc_struct() with all its type checking. But then do we do *zalloc_struct(), *alloc_struct_node(), etc, etc? Bleh. C sucks for this. -Kees -- Kees Cook Pixel Security