From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753556AbdJaP0C (ORCPT ); Tue, 31 Oct 2017 11:26:02 -0400 Received: from merlin.infradead.org ([205.233.59.134]:49398 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751565AbdJaPZ5 (ORCPT ); Tue, 31 Oct 2017 11:25:57 -0400 Date: Tue, 31 Oct 2017 16:25:32 +0100 From: Peter Zijlstra To: Michal Hocko Cc: Byungchul Park , Dmitry Vyukov , syzbot , Andrew Morton , Dan Williams , Johannes Weiner , Jan Kara , jglisse@redhat.com, LKML , linux-mm@kvack.org, shli@fb.com, syzkaller-bugs@googlegroups.com, Thomas Gleixner , Vlastimil Babka , ying.huang@intel.com, kernel-team@lge.com Subject: Re: possible deadlock in lru_add_drain_all Message-ID: <20171031152532.uah32qiftjerc3gx@hirez.programming.kicks-ass.net> References: <089e0825eec8955c1f055c83d476@google.com> <20171027093418.om5e566srz2ztsrk@dhcp22.suse.cz> <20171027134234.7dyx4oshjwd44vqx@dhcp22.suse.cz> <20171030082203.4xvq2af25shfci2z@dhcp22.suse.cz> <20171030100921.GA18085@X58A-UD3R> <20171030151009.ip4k7nwan7muouca@hirez.programming.kicks-ass.net> <20171031131333.pr2ophwd2bsvxc3l@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171031131333.pr2ophwd2bsvxc3l@dhcp22.suse.cz> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 31, 2017 at 02:13:33PM +0100, Michal Hocko wrote: > > I can indeed confirm it's running old code; cpuhp_state is no more. > > Does this mean the below chain is no longer possible with the current > linux-next (tip)? I see I failed to answer this; no it will happen but now reads like: s/cpuhp_state/&_up/ Where we used to have a single lock protecting the hotplug stuff, we now have 2, one for bringing stuff up and one for tearing it down. This got rid of lock cycles that included cpu-up and cpu-down parts; those are false positives because we cannot do cpu-up and cpu-down concurrently. But this report only includes a single (cpu-up) part and therefore is not affected by that change other than a lock name changing.