Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1458241imm; Wed, 20 Jun 2018 19:14:31 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK0pjjrXSn+0s9wfyma6RNIV2kuMFKqnvU2nSZBOoajdv+9FbkkUVlucIZp62Ho1kKjHF7z X-Received: by 2002:a63:a809:: with SMTP id o9-v6mr21315166pgf.313.1529547271639; Wed, 20 Jun 2018 19:14:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529547271; cv=none; d=google.com; s=arc-20160816; b=qVr84TfBbiBPoX4zjUakpkoFoDen+anHVV8wWQQdhnPoSeLS6BlHSzYtn7NdK5w5Fj 9kyS0dWgqf+r3J8jU05hDZ1FivVohxINLYn2+MBaFFF8LSKV/zVK/0dYNdqV/kTxNlHm Jab2W+JvYTlcrkY2RSaNfaHXLJPssu5rvzssP7lLPAZnMYfwSKznN98egTF72Lxgxh28 HRAqcDeKMSjdvGgtuDbmg96zMXVHVs1azCbKK8ZXT/Xx+nT0Bib8z/ao/ZMjUWKX3+JU CzUJLCYpJ73voynSQxBKfA44ZqG3ujI9o59UiralcPssnMXAmO6aUUCrf9mlHtQJfC2D PTOw== 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=8/BbNkeTQGJYJ7zwuZwhEAr+TWj53ZmWFG9LfxVnadY=; b=zHZBpmXIPOIwZc08DJjja2qAairORZ+eWLmeAmSwknvDIGH5Za5t6GTtydpUvMYFsA jZXKdUoy9kuMuAe9QUpDmNng6Z4Tl1pnkiLDTKZsHATNGiwzEvRJm84bINENp7dNKd9m M4mVBS6D86BKrZqDcua3ZbuJ7Ledsv03ixihQ94ywiC4HMEOvcohRpCfVZqF9bMFClSQ 32LIq5WCNDHeC+Kv5+JkZ6MumNNexkaHRcK6nL5Mi0PG0sWygLUTB8VDPHN0PzHJZy/s dcXylqbwWm0+rTR20tULtcvYPJR1iqC37S/ot4KralB7BIZdy6mvARw20BHx1jzJi/z3 lVcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TuWxKvHD; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g7-v6si858939pll.83.2018.06.20.19.14.17; Wed, 20 Jun 2018 19:14:31 -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=@gmail.com header.s=20161025 header.b=TuWxKvHD; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754480AbeFUCNn (ORCPT + 99 others); Wed, 20 Jun 2018 22:13:43 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:44271 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754245AbeFUCNl (ORCPT ); Wed, 20 Jun 2018 22:13:41 -0400 Received: by mail-ua0-f194.google.com with SMTP id f30-v6so1009233uab.11; Wed, 20 Jun 2018 19:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8/BbNkeTQGJYJ7zwuZwhEAr+TWj53ZmWFG9LfxVnadY=; b=TuWxKvHDdccSovocCOOBr3Wj2k+sPa/PLbXPeiPGTyTeuhXBFKL5eM0P1s57f4upgD B49oIVtxaSCA+VzQnhTJ4wZu802AwY931Ct5AHjaUhMIs+Nm1roHrKzuWJPNiGHnpo4q zAuzABVU6mDJaHBoiKtZ19olJ6CjEI8i5MNlI6GvphIjfTNUSM3pw5ot3ciL0hT8gino wZhwOZ1lOLuxrgePLP+/pFAJ6GrAkFvWcEcBANow2zKGg+eDHMymUAyPzhus5alIwNK9 znZh5IodJyD4Ij2jzMBoup2LYTf4o42GF7Rl19f6W6hSk7e3BcZvLGVO18H/71xbhv9b NjgQ== 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=8/BbNkeTQGJYJ7zwuZwhEAr+TWj53ZmWFG9LfxVnadY=; b=aFVgfAhEs+N+416Joiz9Zqz+MRw2C5v7ib+hAnV80ZoMMUA7o2f5SVtZNynj61lwxx 0dUFGTS2cHuAP9fUpKOYv3GHF5JI5CHip4M4Jg498leVD+ByOgNBpJBA2RPzw/8ti0X0 OV4h4XPApZA1UNT1WzVqXCE+P8q4lTC6lBZiAYkpBCx0HeCmbBA2pKaDCIeajbd0ezrI g2zQcDXaY30WT6OG5eF5Y7oYTwdj9pXBG1NBMTbb05Xx7nDRpNB3dEwbfrstDpIi+pyD KJTvQ6UAwwYwqZkb6xCtY2Xp2rI1Wz4WeM6zu7CSmKnJ70Et33Svk3Cx9PM2QOZcLnhB CMgg== X-Gm-Message-State: APt69E1mAKXGgVAvk19qmkOoJea3QNk63Bx0H2UpCNMC/KqB1B9RKfYx 2QAqqGQe/CSKFyhOUVCi7Ke9j1BH7dmSviiZc8w= X-Received: by 2002:ab0:15ad:: with SMTP id i42-v6mr14757516uae.199.1529547220033; Wed, 20 Jun 2018 19:13:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:8b02:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 19:13:39 -0700 (PDT) In-Reply-To: <20180618161056.e52efd0e8bd36211e60705a2@linux-foundation.org> References: <20180618131003.88110-1-andriy.shevchenko@linux.intel.com> <20180618131003.88110-4-andriy.shevchenko@linux.intel.com> <20180618141404.68124daab97bd0f3a3051544@linux-foundation.org> <20180618161056.e52efd0e8bd36211e60705a2@linux-foundation.org> From: Andy Shevchenko Date: Thu, 21 Jun 2018 05:13:39 +0300 Message-ID: Subject: Re: [PATCH v3 3/5] bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free() To: Andrew Morton Cc: Dmitry Torokhov , Andy Shevchenko , agk@redhat.com, Mike Snitzer , device-mapper development , shli@kernel.org, linux-raid@vger.kernel.org, "linux-input@vger.kernel.org" , Yury Norov , lkml , Mika Westerberg , Joe Perches 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, Jun 19, 2018 at 2:10 AM, Andrew Morton wrote: > On Mon, 18 Jun 2018 15:01:43 -0700 Dmitry Torokhov wrote: >> We can't as we end up including bitmap.h (by the way of cpumask.h) >> form slab.h, so we gen circular dependency. > It's not just so easy. See below. > That info should have been in the changelog, and probably a code > comment. > >> Maybe if we removed memcg >> stuff from slab.h so we do not need to include workqueue.h... > > Or move the basic slab API stuff out of slab.h into a new header. Or > create a new, standalone work_struct.h - that looks pretty simple. I tried to move out work_struct, it didn't help. There are actually several circular dependencies that ends in bitmap.h either way or another. First one is slab.h -> gfp.h -> mmzone.h -> nodemask.h -> bitmap.h And so on... Splitting out kXalloc stuff to a separate header won't help, I think, because of the above. Splitting out struct work_struct is just a tip of an iceberg. Splitting out memcg stuff won't help in the similar way. I'm all ears for (a better) solution. -- With Best Regards, Andy Shevchenko