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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 C2E3FC33CA1 for ; Mon, 20 Jan 2020 07:42:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E9DA2073D for ; Mon, 20 Jan 2020 07:42:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E9DA2073D 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 299966B05B7; Mon, 20 Jan 2020 02:42:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24AB66B05B9; Mon, 20 Jan 2020 02:42:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13B6D6B05BA; Mon, 20 Jan 2020 02:42:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id F3AC06B05B7 for ; Mon, 20 Jan 2020 02:42:26 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id A1FBB180AD80F for ; Mon, 20 Jan 2020 07:42:26 +0000 (UTC) X-FDA: 76397219892.03.sink72_15491bd922a03 X-HE-Tag: sink72_15491bd922a03 X-Filterd-Recvd-Size: 3887 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jan 2020 07:42:26 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id q10so28359294wrm.11 for ; Sun, 19 Jan 2020 23:42:26 -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:user-agent; bh=oYPv014C6O3vR5nrvfR9UKHGQnNqmP0rTFCUylko2hY=; b=pJiX8HLazyIe0xnRg2hSpF3+MuAtaanJJDIjytWEns+ZoFhXEIuE1/DVLrXa+GrJG6 ewSoJkJtsZiX0ReW53nGXuh0Q4TgwmbE0FzpMCtoXXzmjbZnf6fJEZTae0d5AxkuZNgU cJPGB3ty4zy6TV4tf/bbdNPkNkUU2kFU+FgojnRMqutPO2aBylw3LmEdvAF0myDZsdHG HbnViz6iTEMMHpvvAoGY+6myexeLesOEKcuMnUw9m91R63KQzBdo5cCDe7WSRiLEWJCV aRznm5DYCmn40Ip1exo07qyRkc+/n1oOkxOMenWo0lvSZmOW4xMZm38nceuCvx7m/U2M /yMw== X-Gm-Message-State: APjAAAWkFFC5STs2SJSls1rh1swMozPJ/MQLC/g1o0ZkaCpCsO19vOPU 8tcM0ggnc/Y5WP33i/4fmPc= X-Google-Smtp-Source: APXvYqyxHbwCf1rEwyiPliE2VJRRsUpskKzOCC9hpd3QOUPFNfJx3XHUPNjrUjzx9oPxyxEzRGSxTg== X-Received: by 2002:adf:f847:: with SMTP id d7mr16568464wrq.35.1579506145143; Sun, 19 Jan 2020 23:42:25 -0800 (PST) Received: from localhost (ip-37-188-138-155.eurotel.cz. [37.188.138.155]) by smtp.gmail.com with ESMTPSA id d14sm49499767wru.9.2020.01.19.23.42.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jan 2020 23:42:24 -0800 (PST) Date: Mon, 20 Jan 2020 08:42:22 +0100 From: Michal Hocko To: Anshuman Khandual Cc: Qian Cai , akpm@linux-foundation.org, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -mm] mm/page_isolation: fix potential warning from user Message-ID: <20200120074222.GF18451@dhcp22.suse.cz> References: <20200120034252.1558-1-cai@lca.pw> <91ba5997-b227-7ae2-8459-310e18b9bb87@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91ba5997-b227-7ae2-8459-310e18b9bb87@arm.com> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Mon 20-01-20 09:50:33, Anshuman Khandual wrote: > Hello Qian, > > On 01/20/2020 09:12 AM, Qian Cai wrote: > > It makes sense to call the WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE) > > from the offlining path, but should avoid triggering it from userspace, > > i.e, from is_mem_section_removable(). > > Could you elaborate why it makes sense not to warn about an unmovable > ZONE_MOVABLE page when an user tries to query about a memory block > device's movability through sysfs ? Because somebody might have panic_on_warn and then this is unlikely (but not impossible) way to put the system down by arbitrary user. Besides that it is stupid to warn when we convey the information to the userspace anyway. [...] > > + } else { > > + if (isol_flags & MEMORY_OFFLINE) > > + WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);> + > > + if ((isol_flags & REPORT_FAILURE) && !IS_ERR(unmovable)) > > + /* > > + * printk() with zone->lock held will likely trigger a > > + * lockdep splat, so defer it here. > > + */ > > + dump_page(unmovable, "unmovable page"); > > + } > > + > > + return !!unmovable; > > } > > > > static void unset_migratetype_isolate(struct page *page, unsigned migratetype) > > set_migratetype_isolate() gets called from CMA as well as HugeTLB > allocation paths, so its not only during offline. Hence the commit > message should be changed to reflect this. We should just report for all those cases I believe. -- Michal Hocko SUSE Labs