From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CDE8C3F2D1 for ; Thu, 5 Mar 2020 14:18:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 292CC20732 for ; Thu, 5 Mar 2020 14:18:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 292CC20732 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 624166B0003; Thu, 5 Mar 2020 09:18:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D4B66B0005; Thu, 5 Mar 2020 09:18:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EA006B0007; Thu, 5 Mar 2020 09:18:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 30B2A6B0003 for ; Thu, 5 Mar 2020 09:18:50 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 151B82494 for ; Thu, 5 Mar 2020 14:18:50 +0000 (UTC) X-FDA: 76561514820.22.crown59_874efa112e347 X-HE-Tag: crown59_874efa112e347 X-Filterd-Recvd-Size: 3349 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Mar 2020 14:18:49 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id v11so5275075wrm.9 for ; Thu, 05 Mar 2020 06:18:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rWJ2ZlSxIkaxSxkCwz25+2vXHAwKGZKzs8QIO832cQQ=; b=RduQqIYIs9zTrELRc8TTI33hSpTWqoW+dVrYATokJBSrA6KCPTjUuRioge49Hauki6 MMKGEvl+A36y4v0pOmvxXRe/ph16zC/nSLY11Y+2+SctCFw8sErxA0NhcxnQmdlvQOli DJ2YbhnKIzEaPvaqhFmTw6+6BP2FeBJvgFTmu/OFXGiJ8GP8XVcx9rwD2Evg3pdhVDzB QlsWILZCOberN8QnWaKd6OqgmOkYJlDGro/agvNu94Qv11ve7mBCk5sL3rncin0acMBq wi+Bw+Ji0QXbyCOw+E4DmEE8Ywcvma4ExHZcQABdOxXTAZBkIFMWFykZkFqJ+9/rqO6C pemA== X-Gm-Message-State: ANhLgQ2yfoBBgm6trj5ayRFOnRLmArhKCbAF2n0bwEW3Z8DlAaCZZH7t fSrxqQsB46jrVElB7q6uLkExfR5N X-Google-Smtp-Source: ADFU+vtH94zikoX75hnruOksDPDvYJmpWPGT2ZWAveIETS75sC34iW1Ksl4YSW8m9d5DeokNkVD9JQ== X-Received: by 2002:adf:ef92:: with SMTP id d18mr767658wro.193.1583417928448; Thu, 05 Mar 2020 06:18:48 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id f17sm24030443wrm.3.2020.03.05.06.18.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2020 06:18:47 -0800 (PST) Date: Thu, 5 Mar 2020 15:18:45 +0100 From: Michal Hocko To: Vincenzo Frascino Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner , Vladimir Davydov , Andrew Morton Subject: Re: [PATCH] mm: Make mem_cgroup_id_get_many dependent on MMU and MEMCG_SWAP Message-ID: <20200305141845.GZ16139@dhcp22.suse.cz> References: <20200304142348.48167-1-vincenzo.frascino@arm.com> <20200304165336.GO16139@dhcp22.suse.cz> <8c489836-b824-184e-7cfe-25e55ab73000@arm.com> <20200305100023.GR16139@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 05-03-20 10:46:21, Vincenzo Frascino wrote: [...] > I am aware of this. I was just exploring if there was a possibility of > addressing the warning, since if we leave all the warnings in scenarios like > randconfig can cause confusion in between real and non real issues. I would very much like to address _real_ warnings. This one is just bugus. I do not see a fix that would be sensible. Wrapping the helper by ifdefs is just going to make the resulting code worse because there is nothing really specific to swap there. Marking it __maybe_unused will just paper over the report and allow the function to bitrot when it is not used anymore. So for now I would just live with the warning unless it is really causing any real problems. -- Michal Hocko SUSE Labs