Received: by 10.192.165.148 with SMTP id m20csp790889imm; Fri, 4 May 2018 21:27:31 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoZNM7CC5wGV6OFd3wk/NnaouJ3a8DLpOY3v08QMi42kYsZ9ekftqwcNDHdPk1As7UZy9rj X-Received: by 2002:a63:3c0c:: with SMTP id j12-v6mr25081693pga.203.1525494345984; Fri, 04 May 2018 21:25:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525494345; cv=none; d=google.com; s=arc-20160816; b=Wcu8PpuVvTIUMvk31XwG1ZmWc4rcaZvxL5wQ1tLUVwRvQeyJPzhbf1hjeh3Y6Hbewu BzPC321frQOtuTdlYKaykA43zF+CV0Ca2pyyEOfLEwa5oT4b7CQGzaN0f3mJe54Rlzdt HOMGcBDpOv/3htI8YmbD1ytHgfLbrPAOcvuLdAsbOpJVZk7scCpoerM/1F8sawH+XmtA iL9wCItYiRB+5MHGLBjMPylkeClmMu0Xh5Os5Y7fUuHHwAwKlrq+PH6JaygXpnZje77q LbtVQIA3BrO2pXXQYREVVPa6KfPMXjS5Q1fGMlCQTjv6UlwRob/k58LBpjxm/J1d80qD G7yQ== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=NgFKASv5lOqvoCI3Hq7e4CC7b6k42vJhSjKBh0RGypU=; b=lQ4aAk0MJ70eEBEfiEvdVKANlwDzczdtn82lGdiIpTb9DGlwVXn67I2oQONPn2cPhc d8AcjV9rUyuJtiZaMoEgCX9I5375QRqXTi4g5kheW1YhFRI9UeXnNtbtXZeJwj8BZB/9 9qDKFPi0dql8Lt5AqeZ2yMdnibAI65+bjtcjd40pHSS5xW4SnVdHU8YW0i9vo6pOv1qy FpCH/AkkNdYeCwjA0impcmdYX850Us7c/mVXvt6Ul2pHRl/Dsy79ovGYc+bxGQo5c0+P k7iZkcjljXvohtWtGaIAhqA8sGPhc/FXaeZ+wjc2rzN5J+5LQWtGApyHIbG+h2QMpZV+ JRgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cg5wEU5K; 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 h67si17935172pfk.15.2018.05.04.21.25.31; Fri, 04 May 2018 21:25:45 -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=cg5wEU5K; 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 S1751211AbeEEEZA (ORCPT + 99 others); Sat, 5 May 2018 00:25:00 -0400 Received: from mail-vk0-f43.google.com ([209.85.213.43]:42101 "EHLO mail-vk0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbeEEEY7 (ORCPT ); Sat, 5 May 2018 00:24:59 -0400 Received: by mail-vk0-f43.google.com with SMTP id j7-v6so14439685vkc.9 for ; Fri, 04 May 2018 21:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NgFKASv5lOqvoCI3Hq7e4CC7b6k42vJhSjKBh0RGypU=; b=cg5wEU5KzXA+I8oPyT8yMgnTQAeA2/ikXMl2tBIcedwHGpj8isyhUnB+WA4IQBxfsi FA5J2e6MuRTWittEAPWFBmKrl9PZls67qlOgUx+/k7v37lcoq9EykFf/CpXmsn9p9cx8 Rt8l/9rDFprZU1uAo8O0FP0Wgfw3AroAg3vZ4xcy1e0U/ApFmfkltUbADYEZOWu5S7n5 0fk9uLcWm6QQO2eV2rXVNDrtC07rjz5Y0i9mB2fKiIf1/EjGpxoFsSH2i1zcTkIfSXMs 3d98r2H0/HoRofHqxnsQl1TmFYQC4hTmVxAOQqc0R7xkaZbRFuuqfYJn0iuJYH5ooe2L shBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NgFKASv5lOqvoCI3Hq7e4CC7b6k42vJhSjKBh0RGypU=; b=JCrZCHFHZG6HNE0jsikFqcJ79/4Wo8VW0SxrzLTeSlHJaPXXYp2FU3QyisYkgeqQzP JSpqmwwSa6YA3gDxrNw4//u93oI0Xnlc3sI6nwVgXLcHSg//KzkaTH9VgqYPRMWL1cMn AjXxzFh6pS68Tnu+Nu5o9gTM1AHBqARCI66g5TFJ7fz30ZZhEEZTD7hVR9T15/Itg3r5 iCUkIZByRWmJuqhnfZdu6AxELI7XfrkRvrnHB7hC6Pco+A8Mj2JGMuFrak/vP/NqILVY qf2kDI884tXHlHXV681B27Y6Xwp9GcJ6NvbeBT+SSMxGN1S7OZzNKc6ZWUwvmHZ72lFq Ywig== X-Gm-Message-State: ALQs6tC7jaxI+ro5ozYTjhmsomwhk9oyC0qwV4SyMJjR5SpEOhKgk0lp k0hCWW8tfv/v2LE0FLCER9Q3pZ7OTdOsxM10GF0+Wg== X-Received: by 2002:a1f:ab47:: with SMTP id u68-v6mr26019320vke.158.1525494298067; Fri, 04 May 2018 21:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.11.209 with HTTP; Fri, 4 May 2018 21:24:56 -0700 (PDT) In-Reply-To: <20180505034646.GA20495@bombadil.infradead.org> References: <20180505034646.GA20495@bombadil.infradead.org> From: Kees Cook Date: Fri, 4 May 2018 21:24:56 -0700 Message-ID: Subject: Re: *alloc API changes To: Matthew Wilcox Cc: Matthew Wilcox , 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 On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: > and if you're counting f2fs_*alloc, there's a metric tonne of *alloc > wrappers out there. Yeah. *sob* > That's a little revisionist ;-) We had kmalloc before we had the slab > allocator (kernel 1.2, I think?). But I see your point, and that's > certainly how it's implemented these days. Okay, yes, that's true. I did think of that briefly. :) > I got shot down for proposing adding > #define malloc(x) kmalloc(x, GFP_KERNEL) > on the grounds that driver writers will then use malloc in interrupt > context. So I think our base version has to be foo_alloc(size, gfp_t). Okay, fair enough. > Right, I was thinking: > > static inline size_t mul_ab(size_t a, size_t b) > { > #if COMPILER_SUPPORTS_OVERFLOW > unsigned long c; > if (__builtin_mul_overflow(a, b, &c)) > return SIZE_MAX; > return c; > #else > if (b != 0 && a >= SIZE_MAX / b) > return SIZE_MAX; > return a * b; > #endif > } Rasmus, what do you think of a saturating version of your helpers? The only fear I have with the saturating helpers is that we'll end up using them in places that don't recognize SIZE_MAX. Like, say: size = mul(a, b) + 1; then *poof* size == 0. Now, I'd hope that code would use add(mul(a, b), 1), but still... it makes me nervous. > You don't need the size check here. We have the size check buried deep in > alloc_pages (look for MAX_ORDER), so kmalloc and then alloc_pages will try > a bunch of paths all of which fail before returning NULL. Good point. Though it does kind of creep me out to let a known-bad size float around in the allocator until it decides to reject it. I would think an early: if (unlikely(size == SIZE_MAX)) return NULL; would have virtually no cycle count difference... > I'd rather have a mul_ab(), mul_abc(), mul_ab_add_c(), etc. than nest > calls to mult(). Agreed. I think having exactly those would cover almost everything, and the two places where a 4-factor product is needed could just nest them. (bikeshed: the very common mul_ab() should just be mul(), IMO.) > Nono, Linus had the better proposal, struct_size(p, member, n). Oh, yes! I totally missed that in the threads. > Ooh, we could instantiate classes and ... yeah, no, not C++. We *could* > abuse the C preprocessor to autogenerate every variant, but I hate that > because you can't grep for it. Right, no. I think if we can ditch *calloc() and _array() by using saturating helpers, we'll have the API in a much better form: kmalloc(foo * bar, GFP_KERNEL); into kmalloc_array(foo, bar, GFP_KERNEL); into kmalloc(mul(foo, bar), GFP_KERNEL); and kmalloc(foo * bar, GFP_KERNEL | __GFP_ZERO); into kzalloc(foo * bar, GFP_KERNEL); into kcalloc(foo, bar, GFP_KERNEL); into kzalloc(mul(foo, bar), GFP_KERNEL); and the fun kzalloc(sizeof(*header) + count * sizeof(*header->element), GFP_KERNEL); into kzalloc(struct_size(header, element, count), GFP_KERNEL); modulo all *alloc* families... ? -Kees -- Kees Cook Pixel Security