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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 5AD7DC3F2D7 for ; Wed, 4 Mar 2020 08:19:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 28D9F214D8 for ; Wed, 4 Mar 2020 08:19:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 28D9F214D8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF1706B0003; Wed, 4 Mar 2020 03:19:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA1846B0006; Wed, 4 Mar 2020 03:19:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB74D6B0007; Wed, 4 Mar 2020 03:19:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) by kanga.kvack.org (Postfix) with ESMTP id 9EB6B6B0003 for ; Wed, 4 Mar 2020 03:19:23 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 52AC21452E for ; Wed, 4 Mar 2020 08:19:23 +0000 (UTC) X-FDA: 76556980206.05.neck30_8c23b9d6fc308 X-HE-Tag: neck30_8c23b9d6fc308 X-Filterd-Recvd-Size: 2740 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Mar 2020 08:19:22 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7B386AE6F; Wed, 4 Mar 2020 08:19:21 +0000 (UTC) Subject: Re: [PATCH 2/2 v3] mm/compaction: Disable compact_unevictable_allowed on RT To: Andrew Morton , Sebastian Andrzej Siewior Cc: linux-mm@kvack.org, Thomas Gleixner , Luis Chamberlain , Kees Cook , Iurii Zaikin , Mel Gorman , Linux API References: <20200115161035.893221-1-bigeasy@linutronix.de> <4cf4507b-0632-34e6-5985-df933559af9f@suse.cz> <20200302173516.iysuejilava37psk@linutronix.de> <20200302132531.59a2c9dffe2515d78abaf909@linux-foundation.org> <20200303175910.ichnkjkgmz5y2ipb@linutronix.de> <20200303202054.gsosv7fsx2ma3cic@linutronix.de> <20200303202225.nhqc3v5gwlb7x6et@linutronix.de> <20200303155635.1955cb90451abd3ef8bfba63@linux-foundation.org> From: Vlastimil Babka Message-ID: Date: Wed, 4 Mar 2020 09:19:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200303155635.1955cb90451abd3ef8bfba63@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 3/4/20 12:56 AM, Andrew Morton wrote: >> @@ -2572,6 +2577,26 @@ int proc_dointvec(struct ctl_table *table, int write, >> return do_proc_dointvec(table, write, buffer, lenp, ppos, NULL, NULL); >> } >> >> +#ifdef CONFIG_COMPACTION >> +static int proc_dointvec_warn_RT_change(struct ctl_table *table, int write, >> + void __user *buffer, size_t *lenp, >> + loff_t *ppos) >> +{ >> + int ret, old; >> + >> + if (!IS_ENABLED(CONFIG_PREEMPT_RT) || !write) >> + return proc_dointvec(table, write, buffer, lenp, ppos); >> + >> + old = *(int *)table->data; >> + ret = proc_dointvec(table, write, buffer, lenp, ppos); >> + if (ret) >> + return ret; >> + WARN_ONCE(old != *(int *)table->data, "sysctl attribute %s changed.", >> + table->procname); > > The WARN will include a stack trace which just isn't interesting. A > pr_warn() would be better? Yeah, the only interesting part of full WARN would possibly be, which process changed it. That might be useful to print. >> + return ret; >> +} >> +#endif >