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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78393C433EF for ; Thu, 14 Apr 2022 03:23:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA9BC6B0071; Wed, 13 Apr 2022 23:23:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C31986B0073; Wed, 13 Apr 2022 23:23:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD1F96B0074; Wed, 13 Apr 2022 23:23:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 978126B0071 for ; Wed, 13 Apr 2022 23:23:22 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6A92022FFC for ; Thu, 14 Apr 2022 03:23:22 +0000 (UTC) X-FDA: 79354039044.10.5A5D1DE Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 927921C0002 for ; Thu, 14 Apr 2022 03:23:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=siGjlGOP8a8aVEoY/7zrcxACP5zMOSpeZmIpk9cPz9o=; b=OBPd6/ohI1DvqAySC5Djju6KPg hI8+2jr7e3hswGtVmaZMCLOC9g/uGxrA5UxYe9JRriY8q8QI53otU5SaIoSpJWJW0JvsgGRA/f15M ag4tYSwnQAho9a20SBVj+sQbPM9ndSYDBtpo7jFAgMgl+RewVNLc8vtMi6skIDP5iN7ngsabAYSVd KvCjW1D0RV1s/9PdOe+DVBh9VH+DvvTJ+5PiNagSuspV1dmFSMBPFBaZmcEuMbY6aKpcr8a3I5hds c3ZlWb5RJ4b+Ey6/OSic2zcSU6YFv0UIEPqJ93WgG9q+XnJtyqGdC5jhha1AdnQPNMTMEHb36nDy/ O8Cbyh6Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1neq4f-00EmtJ-GQ; Thu, 14 Apr 2022 03:23:13 +0000 Date: Thu, 14 Apr 2022 04:23:13 +0100 From: Matthew Wilcox To: Andrew Morton Cc: "Alex Xu (Hello71)" , Alexey Dobriyan , Daniel Colascione , linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Vlastimil Babka Subject: Re: [PATCH] mm/smaps_rollup: return empty file for kthreads instead of ESRCH Message-ID: References: <20220413211357.26938-1-alex_y_xu.ref@yahoo.ca> <20220413211357.26938-1-alex_y_xu@yahoo.ca> <20220413142748.a5796e31e567a6205c850ae7@linux-foundation.org> <1649886492.rqei1nn3vm.none@localhost> <20220413160613.385269bf45a9ebb2f7223ca8@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220413160613.385269bf45a9ebb2f7223ca8@linux-foundation.org> Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="OBPd6/oh"; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 927921C0002 X-Stat-Signature: shgrr71xc85agjjxx5s4n63qojj7way3 X-HE-Tag: 1649906601-92712 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 13, 2022 at 04:06:13PM -0700, Andrew Morton wrote: > On Wed, 13 Apr 2022 18:25:53 -0400 "Alex Xu (Hello71)" wrote: > > > 258f669e7e88 was 4 years ago, so I guess a -stable backport isn't > > > really needed. > > > > Current behavior (4.19+): [...] > > Pre-4.19 and post-patch behavior: > > I don't think this will work very well. smaps_rollup is the sort of > system tuning thing for which organizations will develop in-house > tooling which never get relesaed externally. > > > 3. As mentioned previously, this was already the behavior between 4.14 > > and 4.18 (inclusive). > > > > Yup. Hm, tricky. I'd prefer to leave it alone if possible. How > serious a problem is this, really? I don't think "It's been like this for four years" is as solid an argument as you might like. Certain distributions (of the coloured millinery variety, for example) haven't updated their kernel since then and so there may well be many organisations who have not been exposed to the current behaviour. Even my employers distribution, while it offers a 5.4 based kernel, still has many customers who have not moved from the 4.14 kernel. Inertia is a real thing, and restoring this older behaviour might well be an improvement.