Received: by 10.192.165.148 with SMTP id m20csp793477imm; Fri, 4 May 2018 21:31:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqKbLIQGyRqGS9A2wybf+e14y7w2+xTHa7esIlIhCn1d8zgvnnvg5VP+69o9FHSC/xUULkr X-Received: by 2002:a17:902:407:: with SMTP id 7-v6mr30465714ple.47.1525494711366; Fri, 04 May 2018 21:31:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525494711; cv=none; d=google.com; s=arc-20160816; b=bLxr0iO46gGB2FfQTyRCOvUuficaiKRJ1kC/0DTpC7t988e/fAK+9oYw3gaM0YwX6+ YknAIuMDL3Rl91folwf18Wl05WGZ2+ocgDBBu8zvJ6IY4Rmgysz0vg2XDop3gfUd8D6k Md69BIGrcQCtJDwmnL2bPFDIqWByojIGlfndFse8XVJkJ1mqdLamCq4WsNfy7eDxFGOb +BhTZNoplIZmfpbdLk8qJsGaWTNuE1g6UyAFiNIwrVkZAA2Q5+DNkRkKl7yHzXI276iY /c9yl/wxzSYWqDRRZAT7GFwUz12yOj8zo9zy3GDFBZWbIrCwmu+jOIbdhizZdIBdLevE sNdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=lwdy/dsFS0WPrx1FhZ1iCP1EVb7iape/ja9t9gPZRjU=; b=EZNW46/+SiS8PfliPufBc5GyVTCe/PY0aj5sgvgC+pseKWclF9bGWirc/yCwtX0FPL ICvBxE4aPmf4/nan7/oXGo6g7YkDwt3FkKnfSPpMPvB1ooR1d4CVfa7dlovPizCzqDoo idFH6WimmptoyolESvDgeIojf6mmZe9Mbelk727CArpaVei1EUg/0te+nlwPAA38wuIu JMtJnB0KswBqw4iE4BQaabh5T4WsDxH3ISbbXy1DE3aERHNa0jpzVL56W8N2ssnSRA0I WItJlGQnxZyy/5NZXBixA+cReUFBMybubY7jkAK272b8GSQUiTbNhPzjdBPc6939eWOJ Cnmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=hrwM0nox; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p188-v6si14089202pga.255.2018.05.04.21.31.36; Fri, 04 May 2018 21:31: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=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=hrwM0nox; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751096AbeEEEaT (ORCPT + 99 others); Sat, 5 May 2018 00:30:19 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:34842 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbeEEEaS (ORCPT ); Sat, 5 May 2018 00:30:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lwdy/dsFS0WPrx1FhZ1iCP1EVb7iape/ja9t9gPZRjU=; b=hrwM0nox2T+BDBxl9Pwh/60+U cWFGd7qOjiO0ykv9IbYRv9xFTlQQyIxq0FqCCeod7/jVcRpw/gc61EPIclFWL4SzseBVDinGcuJ5H JKO2sh+Popu/1tKCKv1qzDPbgvUce90i2jk8aNDYmI6kAvmvDU4e0axzqfdDrO6+UtxraWeC3H2OU Pgm9wMPgNJPpzrsAWzNdQU0VNK4zYyCRUk1uXTQZEPbNMFpNblH2ANuhBe6P5WMHDxu4Z2dK4lqW1 BnX4sYWi8QszXEghtIBzc7ScM6oTw/ojgwyO0WC8TFja5iT8Kpmhhl47MImwHtACYxBEmE4jap3zd spQOD2HDA==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1fEopr-0000ve-6i; Sat, 05 May 2018 04:30:15 +0000 Date: Fri, 4 May 2018 21:30:15 -0700 From: Matthew Wilcox To: Kees Cook Cc: Matthew Wilcox , Linux-MM , LKML , Rasmus Villemoes Subject: Re: *alloc API changes Message-ID: <20180505043015.GC20495@bombadil.infradead.org> References: <20180505034646.GA20495@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180505034646.GA20495@bombadil.infradead.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 04, 2018 at 08:46:46PM -0700, Matthew Wilcox wrote: > On Fri, May 04, 2018 at 06:08:23PM -0700, Kees Cook wrote: > > 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. > > dma_pool_alloc, page_frag_alloc, gen_pool_alloc, __alloc_bootmem_node, > cma_alloc, quicklist_alloc (deprecated), mempool_alloc > > > allocation method (not all available in all APIs): > > regular (kmalloc), zeroed (kzalloc), array (kmalloc_array), zeroed > > array (kcalloc) > > ... other initialiser (kmem_cache_alloc) I meant to say that we have a shocking dearth of foo_realloc() functions. Instead we have drivers and core parts of the kernel implementing their own stupid slow alloc-a-new-chunk-of-memory-and-memcpy-from-the-old-then- free when the allocator can probably do a better job (eg vmalloc may be able to expand the existing are, and if it can't do that, it can at least remap the underlying pages; the slab allocator may be able to resize without growing, eg if you krealloc from 1200 bytes to 2000 bytes, that's going to come out of the same slab). So, yeah, adding those increases the API permutations even further. And don't ask about what happens if you allocate with GFP_DMA then realloc with GFP_HIGHMEM.