Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3788977imm; Tue, 29 May 2018 13:47:46 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp7+ml+r/1ShZZQRHX45LTj3H4pCPvn1vnaswLEGpyqf3Ne7T/g4eVIjXSliGe8XJJ7NSZL X-Received: by 2002:a63:730c:: with SMTP id o12-v6mr14935220pgc.1.1527626866298; Tue, 29 May 2018 13:47:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527626866; cv=none; d=google.com; s=arc-20160816; b=V3t+/AdFVs8hNSCvI9cRSO+uy5DJdp2AldsaqVLN67S7bslc5LqOJNT/xQqX3bZ7Cq LFqEDIZ1LZ7zl8B7h/T3hSU2Zv2qCkEBLR8RmUvUrKnCo2VskSLHlT6mE3iwO8RHfdJg Tx+A2fWWLUL643o+tJVnVcyf/XAm1w7cr48rfy5W+JQqNP1Yk8BpjX6uPeFqeiJrNq00 9NSr4cG9tAYGy126iRu7O6uaN1tinyo6uRSS7uioJjyoBkZU0hb0vL1ehGkV+aNNGvjZ TubRdoxOU4eMXDyGhW1/HwcugaWeYMjt5Oy6GS2JDGues65NfJ03km3dM9zVCZvjqBj7 WyGA== 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 :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=GiVahP+4cME4Pt+HSEG/dgi8s/Qu51P4vCoY1Gnva5g=; b=P918WCz1weG/cfaq8NXdBfj9GPqPsbXX/98uoPiqcccJRLMRerThko3FMHLidj9kTM 0AZczr/QWWUrpjq3kmGakf8g4RUPjSfMxwf9Q6niPB7SKJabN0uMaNi1q/99GgT+oCjn sAK2HIer7+3Gw9pWXtPnzUBQrGSJbDAciZ3QITwAlTD7hI/ww7eUZZI1LcU64OyHD5mY 9UrWbd2c4wyLaEoEeqqJlARyqnqdQlChXHQ4YE1W9kDqqEe/APIkFRJTOv/n+82rh45H XlE7+VqAwjj5028yXq7m/8Zy4S04RVmXIUK9ft/r2dD/6Bxhj31yWju2raubDCh0wPkD yn5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=fWZkE8x3; 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 a66-v6si35090736pfb.81.2018.05.29.13.47.31; Tue, 29 May 2018 13:47:46 -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=@linux-foundation.org header.s=google header.b=fWZkE8x3; 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 S966949AbeE2Uqj (ORCPT + 99 others); Tue, 29 May 2018 16:46:39 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:36959 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966767AbeE2Uqh (ORCPT ); Tue, 29 May 2018 16:46:37 -0400 Received: by mail-io0-f193.google.com with SMTP id e20-v6so19244058iof.4; Tue, 29 May 2018 13:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GiVahP+4cME4Pt+HSEG/dgi8s/Qu51P4vCoY1Gnva5g=; b=fWZkE8x3Rg4hv/pwzYGYs6xwxyPYBNmbR3QSrRgYsJe9QQMP07ll+mr0yzprwBkkI+ v6xjhO9OABpV2Vg4/cfQeSdWRM36BtR3E+QDUEPhK3O3n+AKEbInKicuPF0Kv/Ee5262 z6IHDEjE7YRGjIzJJ6lzy+m+y2aCUnfe+p1kI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GiVahP+4cME4Pt+HSEG/dgi8s/Qu51P4vCoY1Gnva5g=; b=YoPV4FOZgobycpzwTzZMfgJDoClztr1vtRzl1jQcYtQoNHvcm8Udh6UkGQXRPDW48Q 2iaWaF3HZhYX4SZqoz2XLW0bg56ku9xEc81b87JRkAEGCjeieWo+frhHq2v5woGNmLpo irIFOuYmKS9Tbk5H016ed4RzHaQ4jAcfOxVf5wVYbjPDvy2OotM0sqwC8rYx2ituF/J+ aFIC63qJ1faSX/86B/lPndmktgirXwwjXW7axypQFDUyv6zQ/IuLaoZS47RBno4hxsov MBi6wbQn/7CpK5ZV78mxtOzgx6NLak4z0YYu6ecZW2reA04orLTPP84BdhO9XN6GhKfc VTnQ== X-Gm-Message-State: ALKqPwf2gWjflrcEOeVzBD5FLIy272QSjv5nvgc2jf1RwwScfn1OvoPg pKoM09P+THifoVNd6ZQMjacQRjHesVIRdu7dQfY= X-Received: by 2002:a6b:b354:: with SMTP id c81-v6mr16710369iof.259.1527626796514; Tue, 29 May 2018 13:46:36 -0700 (PDT) MIME-Version: 1.0 References: <20180524211135.27760-1-dave@stgolabs.net> <20180524211135.27760-4-dave@stgolabs.net> <20180529144317.GA20910@dhcp22.suse.cz> <20180529145106.GV27180@dhcp22.suse.cz> In-Reply-To: <20180529145106.GV27180@dhcp22.suse.cz> From: Linus Torvalds Date: Tue, 29 May 2018 15:46:25 -0500 Message-ID: Subject: Re: [PATCH 3/6] lib/bucket_locks: use kvmalloc_array() To: Michal Hocko Cc: Davidlohr Bueso , Andrew Morton , Thomas Graf , Herbert Xu , Manfred Spraul , guillaume.knispel@supersonicimagine.com, Linux API , Linux Kernel Mailing List , Davidlohr Bueso 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 Tue, May 29, 2018 at 9:51 AM Michal Hocko wrote: > In other words, what about the following? > + WARN_ON_ONCE((flags & (__GFP_FS|__GFP_IO)) != (__GFP_FS|__GFP_IO)); I still don't understand the point of this warning. It's only stupid. It basically says "this function is garbage, so let me warn about the fact that I'm a moron". If we all needed to warn about ourselves being morons, there would be a hell of a lot of big blinking signs everywhere. And the *ONLY* thing that warning has ever caused is just stupid code that does if (flags == GFP_KERNEL) .. do kvmalloc .. else .. do kmalloc() .. which is a *STUPID* pattern. In other words, the WARN_ON() is bogus garbage. It's bogus exactly because NOBODY CARES and all everybody will ever do is to just avoid it by writing worse code. The whole and ONLY point of "kvmalloc()" and friends is to make it easy to write code and _not_ have those idiotic "let's do kmalloc or kvmalloc depending on the phase of the moon" garbage. So the warning has literally destroyed the only value that function has! > + if (!gfpflags_allow_blocking(flags)) > + return NULL; > + And no. Now all the code *above* this check is just wrong. All the code that modifies the gfp_flags with the intention of falling back on vmalloc() is just wrong, since we're not falling back on vmalloc any more. So I really think the semantics should be simple: - if we don't allow GFP_KERNEL, then the code becomes just "kmalloc()", since there is no valid fallback to vmalloc. vmalloc does GFP_KERNEL. - otherwise, we do what we used to do (except now the warning is gone, because we already handled the case it warned about). Nothing else. No stupid other cases. The *only* thing that function should ask itself is "can I fall back on vmalloc or not", and if it can't then it should just be a kmalloc. Because otherwise we'll continue to have people that just check in the caller instead. Linus