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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 0095CC33CB6 for ; Thu, 16 Jan 2020 16:05:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8AF9207FF for ; Thu, 16 Jan 2020 16:05:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="cA5hZxgL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8AF9207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 37F108E007C; Thu, 16 Jan 2020 11:05:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 330498E003F; Thu, 16 Jan 2020 11:05:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21FAB8E007C; Thu, 16 Jan 2020 11:05:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 0AA918E003F for ; Thu, 16 Jan 2020 11:05:14 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id A33D5824805A for ; Thu, 16 Jan 2020 16:05:13 +0000 (UTC) X-FDA: 76383971706.24.ghost74_67b13d3ca7606 X-HE-Tag: ghost74_67b13d3ca7606 X-Filterd-Recvd-Size: 5414 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jan 2020 16:05:12 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id a203so19594198qkc.3 for ; Thu, 16 Jan 2020 08:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ITaNl5uhW3c9BKNTq8iRAEvkIWnU2UBbLTn/vPzRoLQ=; b=cA5hZxgLV8TglORvyg0085ms28N2KFsehz1HccdQ+b8D6gGcE/l9pMVBsfHG2NdpZZ BPS5/JgO630LRfOFUn0ueikrsL6qloec0K9nrnfK0AGnXmwt5fxB6+80zoB0NSOBAMj6 9y+wRs5ATLmhvf9SMIw2j6a3InaRYeN8hsxw8Hr5hGE1tcUhuqQjdKmTYF89pjsUoKIf iMUwQtQsOfKekzFlxNodWBCCjqnYhmAlysbytpovNItzcYKQBdXGn5Qgc57La8srw8Cw rzOUykEN01a6LSbDjOA9uNlYeaYMWqI1a+ICYuq9YFU3TlMJBRsdcLdNMHL5q/f0dDKa e8ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ITaNl5uhW3c9BKNTq8iRAEvkIWnU2UBbLTn/vPzRoLQ=; b=h8zFv8KlUah1PhaBRoZV0KK4hM3vkGF6Y8BRuT8KCqYTQlQozXrlQGhI2SbaEju3ka fInw4Ex4OPOtV+r2TKBOxmrcKRbp3ykF7jwPHFzRS/2yx5Mp/4Sevtll5/7a4Ox/oJUN ZDUDaq65ra+81NwmH6YzxMKTmFfWPViMk2D76d12bHNROZeXcDcqF+L8YEX4TFLQxwKT oYJenDA1Be1YarswniYIZ+3T7lI2P11zIReG1UWbvfKyEkWB2qqt/Cn9jNO23BPkFvfO tCPRNo9A6TRVAsso5v/9bkNnjZHCOVjsrrRtfmP89wf2zFEdDFI8zUE1RDb0/n0QRfIs uGFg== X-Gm-Message-State: APjAAAVruvKbuE54ASc14cyXcBM0KPu5b1XYaM4xcEX2ophGwXiZ8tD1 hr20jHFU5aVcj6zDqy4RHJbCuw== X-Google-Smtp-Source: APXvYqwHrEB389KjskFiGUF8kyhbYBlghm23dwqZDY69ig+dAuXl3+ikQWqlKYjMEOigNodubJr5WQ== X-Received: by 2002:a37:814:: with SMTP id 20mr32808216qki.314.1579190711795; Thu, 16 Jan 2020 08:05:11 -0800 (PST) Received: from [192.168.1.153] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id b35sm11465407qtc.9.2020.01.16.08.05.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 08:05:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: [PATCH -next v3] mm/hotplug: silence a lockdep splat with printk() From: Qian Cai In-Reply-To: <20200116155434.GB19428@dhcp22.suse.cz> Date: Thu, 16 Jan 2020 11:05:07 -0500 Cc: Andrew Morton , Sergey Senozhatsky , pmladek@suse.com, rostedt@goodmis.org, peterz@infradead.org, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200115172916.16277-1-cai@lca.pw> <20200116142827.GU19428@dhcp22.suse.cz> <162DFB9F-247F-4DCA-9B69-535B9D714FBB@lca.pw> <20200116155434.GB19428@dhcp22.suse.cz> To: Michal Hocko X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Jan 16, 2020, at 10:54 AM, Michal Hocko wrote: >=20 > On Thu 16-01-20 09:53:13, Qian Cai wrote: >>=20 >>=20 >>> On Jan 16, 2020, at 9:28 AM, Michal Hocko wrote: >>>=20 >>> On Wed 15-01-20 12:29:16, Qian Cai wrote: >>>> It is guaranteed to trigger a lockdep splat if calling printk() = with >>>> zone->lock held because there are many places (tty, console = drivers, >>>> debugobjects etc) would allocate some memory with another lock >>>> held which is proved to be difficult to fix them all. >>>=20 >>> I am still not happy with the above much. What would say about = something >>> like below instead? >>> " >>> It is not that hard to trigger lockdep splats by calling printk from >>> under zone->lock. Most of them are false positives caused by lock = chains >>> introduced early in the boot process and they do not cause any real >>> problems. There are some console drivers which do allocate from the >>> printk context as well and those should be fixed. In any case false >>> positives are not that trivial to workaround and it is far from = optimal >>> to lose lockdep functionality for something that is a non-issue. >>> >>> " >>=20 >> I feel like I repeated myself too many times. A call trace for one = lock dependency >> is sometimes from early boot process because lockdep will save the = first one it >> encountered, but it does not mean the lock dependency will only not = happen in >> early boot. I spent some time to study those early boot call traces = in the given >> lockdep splats, and it looks to me the lock dependency is also = possible after >> the boot. >=20 > Then state it explicitly with an example of the trace and explanation > that the deadlock is real. If the deadlock is real then it shouldn't = be > really terribly hard to notice even without lockdep splats which get > disabled after the first false positive, right? A deadlock could be really hard to trigger though which needs a perfect timing between multiple threads.=