From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751075AbdEaPqa (ORCPT ); Wed, 31 May 2017 11:46:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13495 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954AbdEaPq2 (ORCPT ); Wed, 31 May 2017 11:46:28 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 83BDA8047B Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=aarcange@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 83BDA8047B Date: Wed, 31 May 2017 17:46:25 +0200 From: Andrea Arcangeli To: Michal Hocko Cc: Mike Rapoprt , Vlastimil Babka , "Kirill A. Shutemov" , Andrew Morton , Arnd Bergmann , "Kirill A. Shutemov" , Pavel Emelyanov , linux-mm , lkml , Linux API Subject: Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE Message-ID: <20170531154625.GC302@redhat.com> References: <20170530074408.GA7969@dhcp22.suse.cz> <20170530101921.GA25738@rapoport-lnx> <20170530103930.GB7969@dhcp22.suse.cz> <20170530140456.GA8412@redhat.com> <20170530143941.GK7969@dhcp22.suse.cz> <20170530154326.GB8412@redhat.com> <20170531120822.GL27783@dhcp22.suse.cz> <8FA5E4C2-D289-4AF5-AA09-6C199E58F9A5@linux.vnet.ibm.com> <20170531141809.GB302@redhat.com> <20170531143216.GR27783@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170531143216.GR27783@dhcp22.suse.cz> User-Agent: Mutt/1.8.2 (2017-04-18) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 31 May 2017 15:46:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 31, 2017 at 04:32:17PM +0200, Michal Hocko wrote: > I would assume such a patch would be backported to stable trees because > to me it sounds like the current semantic is simply broken and needs > fixing anyway but it shouldn't be much different from any other bugs. So the program would need then to check also for the -stable minor number where the patch was backported to in addition of any enterprise kernel backport versioning. > This is far from ideal from the "guarantee POV" of course. Agree it's far from ideal and lack of guarantee at least for CRIU means silent random memory corruption.