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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 2422EC10F13 for ; Mon, 8 Apr 2019 17:03:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F3ED920880 for ; Mon, 8 Apr 2019 17:03:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727023AbfDHRDJ (ORCPT ); Mon, 8 Apr 2019 13:03:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54426 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726726AbfDHRDJ (ORCPT ); Mon, 8 Apr 2019 13:03:09 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E864E3076C61; Mon, 8 Apr 2019 17:03:08 +0000 (UTC) Received: from lorien.usersys.redhat.com (ovpn-116-161.phx2.redhat.com [10.3.116.161]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BA16F4DC; Mon, 8 Apr 2019 17:03:07 +0000 (UTC) Date: Mon, 8 Apr 2019 13:03:05 -0400 From: Phil Auld To: Sasha Levin Cc: tip-bot for Phil Auld , linux-tip-commits@vger.kernel.org, mingo@kernel.org, efault@gmx.de, Anton Blanchard , Ben Segall , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , stable@vger.kernel.org Subject: Re: [tip:sched/core] sched/fair: Limit sched_cfs_period_timer loop to avoid hard lockup Message-ID: <20190408170305.GI6584@lorien.usersys.redhat.com> References: <20190405141524.05DDA2186A@mail.kernel.org> <20190408134214.GC6584@lorien.usersys.redhat.com> <20190408145026.GG4689@sasha-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190408145026.GG4689@sasha-vm> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Mon, 08 Apr 2019 17:03:09 +0000 (UTC) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Apr 08, 2019 at 10:50:26AM -0400 Sasha Levin wrote: > On Mon, Apr 08, 2019 at 09:42:14AM -0400, Phil Auld wrote: > > On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote: > > > Hi, > > > > > > [This is an automated email] > > > > > > This commit has been processed because it contains a -stable tag. > > > The stable tag indicates that it's relevant for the following trees: all > > > > > > The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138. > > > > > > v5.0.6: Failed to apply! Possible dependencies: > > > c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking") > > > > > > v4.19.33: Failed to apply! Possible dependencies: > > > c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking") > > > > > > v4.14.110: Failed to apply! Possible dependencies: > > > c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking") > > > > > > > This is a minor context difference. There is no actual dependency on the > > c0ad4aa4d841 patch. It would be easy to produce new version that could > > go in these trees. I'm not sure what the right action is in that case. > > Should I spin a new version with the different locking in the context? > > Please do :) > Sure. I'm just not sure how to post it. It only shows up in this tip-bot email and on gitweb. It's not in tip.git and not in Linus' upstream tree. I've updated the patch at it will apply now to v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178 all with increasing offsets but nothing else. v3.18.138 won't take it without more work. I'd be inclined to skip that one. > The algorithm does the dependency analysis by looking at surrounding > code rather than actual functional dependency. That's pretty cool though :) Cheers, Phil > > -- > Thanks, > Sasha --