Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161472AbdDUUdT (ORCPT ); Fri, 21 Apr 2017 16:33:19 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33564 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1036998AbdDUUdQ (ORCPT ); Fri, 21 Apr 2017 16:33:16 -0400 Date: Fri, 21 Apr 2017 22:33:12 +0200 From: Frederic Weisbecker To: Linus Torvalds Cc: Mel Gorman , Jesper Dangaard Brouer , Andrew Morton , Tariq Toukan , LKML , linux-mm , "netdev@vger.kernel.org" , Peter Zijlstra Subject: Re: Heads-up: two regressions in v4.11-rc series Message-ID: <20170421203311.GD2586@lerouge> References: <20170420110042.73d01e0f@redhat.com> <20170420143033.3nzi6nruqd5s3n7f@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1547 Lines: 31 On Fri, Apr 21, 2017 at 10:52:29AM -0700, Linus Torvalds wrote: > On Thu, Apr 20, 2017 at 7:30 AM, Mel Gorman wrote: > >> The end result was a revert, and this is waiting in AKPMs quilt queue: > >> http://ozlabs.org/~akpm/mmots/broken-out/revert-mm-page_alloc-only-use-per-cpu-allocator-for-irq-safe-requests.patch > >> > > > > This was flagged to Andrew that it should go in for either 4.11 or if > > there were concerns about how close to the release we are then put it in > > for 4.11-stable. At worst, I can do a resubmit to -stable myself after > > it gets merged in the next window if it falls between the cracks. > > This got merged (commit d34b0733b452: "Revert "mm, page_alloc: only > use per-cpu allocator for irq-safe requests""). > > The other issue (caused by commit a499a5a14dbd: "sched/cputime: > Increment kcpustat directly on irqtime account") is still open. > > Frederic? Revert? But I guess it's something we can delay for > backporting, it's presumably not possible to hit maliciously except on > some fast local network attacker just causing an effective DoS. I can't tell about the security impact. But indeed I think we should rather delay for backporting if we can't manage to fix it in the upcoming days. Especially as you can't revert this patch alone, it's part of a whole series of ~ 30 commits that removed cputime_t and it's in the middle of the series, so those that come after depend on it and those that come before just don't make sense alone. But I'll fix this ASAP. Thanks.