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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 6779EECE58D for ; Wed, 9 Oct 2019 16:23:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40D9420B7C for ; Wed, 9 Oct 2019 16:23:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570638224; bh=wMxhG9s5h9fA1Vfah8Q8baDQgL2AYa2Qv5Jd6Hxq1gQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KM14W0N3qo9SUmI6pNs/Za9MuaYg7J/AbgOnknmUh3mn4XixyYcwRTly5xz/LDe6N 5V1EXz+xwVXlfZu64KHFTSEPMtuFv8hF41StPcTM3cK+xHqhTup5FtW51Du6JkzM2s oBw2pzkXEHojupQoB4Pw2dh7NgD2qk62JQ7mZsqk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731715AbfJIQXn (ORCPT ); Wed, 9 Oct 2019 12:23:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:50350 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731173AbfJIQXn (ORCPT ); Wed, 9 Oct 2019 12:23:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6725EB03D; Wed, 9 Oct 2019 16:23:40 +0000 (UTC) Date: Wed, 9 Oct 2019 18:23:39 +0200 From: Michal Hocko To: Qian Cai Cc: Petr Mladek , Christian Borntraeger , Heiko Carstens , sergey.senozhatsky.work@gmail.com, rostedt@goodmis.org, peterz@infradead.org, linux-mm@kvack.org, john.ogness@linutronix.de, akpm@linux-foundation.org, Vasily Gorbik , Peter Oberparleiter , david@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191009162339.GI6681@dhcp22.suse.cz> References: <20191008191728.GS6681@dhcp22.suse.cz> <1570563324.5576.309.camel@lca.pw> <20191009114903.aa6j6sa56z2cssom@pathway.suse.cz> <1570626402.5937.1.camel@lca.pw> <20191009132746.GA6681@dhcp22.suse.cz> <1570628593.5937.3.camel@lca.pw> <20191009135155.GC6681@dhcp22.suse.cz> <1570630784.5937.5.camel@lca.pw> <20191009143439.GF6681@dhcp22.suse.cz> <1570633715.5937.10.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1570633715.5937.10.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 09-10-19 11:08:35, Qian Cai wrote: > On Wed, 2019-10-09 at 16:34 +0200, Michal Hocko wrote: > > On Wed 09-10-19 10:19:44, Qian Cai wrote: > > > On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote: > > > > [...] > > > > Can you paste the full lock chain graph to be sure we are on the same > > > > page? > > > > > > WARNING: possible circular locking dependency detected > > > 5.3.0-next-20190917 #8 Not tainted > > > ------------------------------------------------------ > > > test.sh/8653 is trying to acquire lock: > > > ffffffff865a4460 (console_owner){-.-.}, at: > > > console_unlock+0x207/0x750 > > > > > > but task is already holding lock: > > > ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at: > > > __offline_isolated_pages+0x179/0x3e0 > > > > > > which lock already depends on the new lock. > > > > > > > > > the existing dependency chain (in reverse order) is: > > > > > > -> #3 (&(&zone->lock)->rlock){-.-.}: > > >        __lock_acquire+0x5b3/0xb40 > > >        lock_acquire+0x126/0x280 > > >        _raw_spin_lock+0x2f/0x40 > > >        rmqueue_bulk.constprop.21+0xb6/0x1160 > > >        get_page_from_freelist+0x898/0x22c0 > > >        __alloc_pages_nodemask+0x2f3/0x1cd0 > > >        alloc_pages_current+0x9c/0x110 > > >        allocate_slab+0x4c6/0x19c0 > > >        new_slab+0x46/0x70 > > >        ___slab_alloc+0x58b/0x960 > > >        __slab_alloc+0x43/0x70 > > >        __kmalloc+0x3ad/0x4b0 > > >        __tty_buffer_request_room+0x100/0x250 > > >        tty_insert_flip_string_fixed_flag+0x67/0x110 > > >        pty_write+0xa2/0xf0 > > >        n_tty_write+0x36b/0x7b0 > > >        tty_write+0x284/0x4c0 > > >        __vfs_write+0x50/0xa0 > > >        vfs_write+0x105/0x290 > > >        redirected_tty_write+0x6a/0xc0 > > >        do_iter_write+0x248/0x2a0 > > >        vfs_writev+0x106/0x1e0 > > >        do_writev+0xd4/0x180 > > >        __x64_sys_writev+0x45/0x50 > > >        do_syscall_64+0xcc/0x76c > > >        entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > This one looks indeed legit. pty_write is allocating memory from inside > > the port->lock. But this seems to be quite broken, right? The forward > > progress depends on GFP_ATOMIC allocation which might fail easily under > > memory pressure. So the preferred way to fix this should be to change > > the allocation scheme to use the preallocated buffer and size it from a > > context when it doesn't hold internal locks. It might be a more complex > > fix than using printk_deferred or other games but addressing that would > > make the pty code more robust as well. > > I am not really sure if doing a surgery in pty code is better than fixing the > memory offline side as a short-term fix. If this was only about the memory offline code then I would agree. But we are talking about any printk from the zone->lock context and that is a bigger deal. Besides that it is quite natural that the printk code should be more universal and allow to be also called from the MM contexts as much as possible. If there is any really strong reason this is not possible then it should be documented at least. -- Michal Hocko SUSE Labs 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=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 ECAA6C4360C for ; Sun, 13 Oct 2019 03:28:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6A25B20882 for ; Sun, 13 Oct 2019 03:28:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A25B20882 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 09EB66B0003; Sat, 12 Oct 2019 23:28:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 04FA76B0005; Sat, 12 Oct 2019 23:28:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5B166B0006; Sat, 12 Oct 2019 23:28:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id B32666B0003 for ; Sat, 12 Oct 2019 23:28:36 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 0D1222C1E for ; Sun, 13 Oct 2019 03:28:36 +0000 (UTC) X-FDA: 76037329032.29.sky49_2ddc374ce6149 X-HE-Tag: sky49_2ddc374ce6149 X-Filterd-Recvd-Size: 15283 Received: from listssympa-test.colorado.edu (listssympa-test.colorado.edu [128.138.129.156]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Sun, 13 Oct 2019 03:28:34 +0000 (UTC) Received: from listssympa-test.colorado.edu (localhost [127.0.0.1]) by listssympa-test.colorado.edu (8.15.2/8.15.2/MJC-8.0/sympa) with ESMTPS id x9D3Ri8h002607 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Oct 2019 21:27:44 -0600 Received: (from root@localhost) by listssympa-test.colorado.edu (8.15.2/8.15.2/MJC-8.0/submit) id x9D3RhNY002558; Sat, 12 Oct 2019 21:27:43 -0600 Received: from CY4PR03MB2421.namprd03.prod.outlook.com (2603:10b6:a03:1d0::17) by BYAPR03MB4376.namprd03.prod.outlook.com with HTTPS via BY5PR04CA0007.NAMPRD04.PROD.OUTLOOK.COM; Wed, 9 Oct 2019 17:50:28 +0000 Received: from MWHPR03CA0015.namprd03.prod.outlook.com (2603:10b6:300:117::25) by CY4PR03MB2421.namprd03.prod.outlook.com (2603:10b6:903:3f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.23; Wed, 9 Oct 2019 17:38:05 +0000 Received: from BY2NAM01FT057.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::205) by MWHPR03CA0015.outlook.office365.com (2603:10b6:300:117::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16 via Frontend Transport; Wed, 9 Oct 2019 17:38:05 +0000 Received: from ipmx3.colorado.edu (128.138.67.74) by BY2NAM01FT057.mail.protection.outlook.com (10.152.68.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16 via Frontend Transport; Wed, 9 Oct 2019 17:38:04 +0000 Received: from ipmx2.colorado.edu ([128.138.128.232]) by mx.colorado.edu with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2019 10:59:11 -0600 Received: from vger.kernel.org ([209.132.180.67]) by mx.colorado.edu with ESMTP; 09 Oct 2019 10:23:44 -0600 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731715AbfJIQXn (ORCPT ); Wed, 9 Oct 2019 12:23:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:50350 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731173AbfJIQXn (ORCPT ); Wed, 9 Oct 2019 12:23:43 -0400 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6725EB03D; Wed, 9 Oct 2019 16:23:40 +0000 (UTC) Authentication-Results: spf=none (sender IP is 128.138.67.74) smtp.mailfrom=vger.kernel.org; o365.colorado.edu; dkim=none (message not signed) header.d=none;o365.colorado.edu; dmarc=fail action=none header.from=kernel.org; Received-SPF: None (protection.outlook.com: vger.kernel.org does not designate permitted sender hosts) Authentication-Results-Original: mx.colorado.edu; dkim=none (message not signed) header.i=none IronPort-SDR: iLi2UkgEtClesRlILOIPlzYMaJDrbaggSZbk6l5kgUp/cV5sAC1lnDr1D4flN0rNW0f55Uks5E BKPkh2ZntBd6za3F3aR1o6isqXCdCYoSI= IronPort-SDR: umDyieENp/dB3LwtysLYZxGRK/4STgLgtAjhzrlyfa9WMrha6cFvQ08jmlEOwFYgRRXG6k/y4A MREoZpxlNGg7gifLbcZbIZ8ibZoObRFsg= IronPort-PHdr: =?us-ascii?q?9a23=3AcKkZOR0vkcrQTm8DsmDT+zVfTzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLSKm44pD+JxKGt/B9ylTOWYLB4v5DzefarvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrJyw3FchPThlkqne8N0VY?= IronPort-PHdr: =?us-ascii?q?9a23=3AXa5wxhLOWk8GDle6F9mcpTVXNAE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN56u5InmIFeBvKdonBnCWoHc8ftIjKzbv72zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLmQ6Ec1OWUUj/iS9Nk5YFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0FCAABLGZ5dbeiAioBlGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgXsCghkFbIEFKodtixKCD488i2IRAQE?= =?us-ascii?q?BAQEBAQEBCBgDEgIBAQGHESM4EwIDCQEBAQMBAQECAQUCAQECAhALDQkGK4U?= =?us-ascii?q?0DEIBDAGDYCyBRQEFAQIkCwFGBgkBAQoYCRMSAwwFSRiDHoJ3BLFXM4N6hQC?= =?us-ascii?q?BSIE0AYwNGIFAP4ERgxI+ijAEjQWgPoIshwiFGIhtDBuDLIpcizgtp16BaYF?= =?us-ascii?q?7MxoIKAiDJwlHEBSME4QEQTGBCIgah3kBAQ?= X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0FMAACpDJ5dh0O0hNFlGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgXsCghlwVDEqh22LEYIPFI8oi2IRAQE?= =?us-ascii?q?BAQEBAQEBIAMRAQIBAQGHESM4EwIDCQEBAQMBAQECAQUCAQECAhABAQEKCwk?= =?us-ascii?q?IKYU0DEIBDAGDYCyBRQECAwECJAsBRgYJAQEKGAkTEgMMBUkYgx0BggoEsWg?= =?us-ascii?q?zg3qFAoFIgTQBjA0YgUA/gRGDEj6KKgSNBaA+giyHCIUYiG0MG4MsilyLOC2?= =?us-ascii?q?pR4F7MxoIKAiDJwlHEBSME4QEQDKBBgEBi0+IDgEB?= X-IPAS-Result: =?us-ascii?q?A0FCAABLGZ5dbeiAioBlGQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QEBAQEBAQEBAQEBgXsCghkFbIEFKodtixKCD488i2IRAQEBAQEBAQEBCBgDE?= =?us-ascii?q?gIBAQGHESM4EwIDCQEBAQMBAQECAQUCAQECAhALDQkGK4U0DEIBDAGDYCyBR?= =?us-ascii?q?QEFAQIkCwFGBgkBAQoYCRMSAwwFSRiDHoJ3BLFXM4N6hQCBSIE0AYwNGIFAP?= =?us-ascii?q?4ERgxI+ijAEjQWgPoIshwiFGIhtDBuDLIpcizgtp16BaYF7MxoIKAiDJwlHE?= =?us-ascii?q?BSME4QEQTGBCIgah3kBAQ?= X-IPAS-Result: =?us-ascii?q?A0FMAACpDJ5dh0O0hNFlGQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QEBAQEBAQEBAQEBgXsCghlwVDEqh22LEYIPFI8oi2IRAQEBAQEBAQEBIAMRA?= =?us-ascii?q?QIBAQGHESM4EwIDCQEBAQMBAQECAQUCAQECAhABAQEKCwkIKYU0DEIBDAGDY?= =?us-ascii?q?CyBRQECAwECJAsBRgYJAQEKGAkTEgMMBUkYgx0BggoEsWgzg3qFAoFIgTQBj?= =?us-ascii?q?A0YgUA/gRGDEj6KKgSNBaA+giyHCIUYiG0MG4MsilyLOC2pR4F7MxoIKAiDJ?= =?us-ascii?q?wlHEBSME4QEQDKBBgEBi0+IDgEB?= X-IronPort-AV: E=Sophos;i="5.67,277,1566885600"; d="scan'208";a="369337680" X-IronPort-AV: E=Sophos;i="5.67,276,1566885600"; d="scan'208";a="414125948" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown X-Original-Recipients: migi9492@g.colorado.edu X-Virus-Scanned: by amavisd-new at test-mx.suse.de Date: Wed, 9 Oct 2019 18:23:39 +0200 From: "Michal Hocko" To: "Qian Cai" Cc: "Petr Mladek" , "Christian Borntraeger" , "Heiko Carstens" , "sergey.senozhatsky.work@gmail.com" , "rostedt@goodmis.org" , "peterz@infradead.org" , "linux-mm@kvack.org" , "john.ogness@linutronix.de" , "akpm@linux-foundation.org" , "Vasily Gorbik" , "Peter Oberparleiter" , "david@redhat.com" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191009162339.GI6681@dhcp22.suse.cz> References: <20191008191728.GS6681@dhcp22.suse.cz> <1570563324.5576.309.camel@lca.pw> <20191009114903.aa6j6sa56z2cssom@pathway.suse.cz> <1570626402.5937.1.camel@lca.pw> <20191009132746.GA6681@dhcp22.suse.cz> <1570628593.5937.3.camel@lca.pw> <20191009135155.GC6681@dhcp22.suse.cz> <1570630784.5937.5.camel@lca.pw> <20191009143439.GF6681@dhcp22.suse.cz> <1570633715.5937.10.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1570633715.5937.10.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-MS-Exchange-Organization-ExpirationStartTime: 09 Oct 2019 17:38:04.6791 (UTC) X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000 X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit X-MS-Exchange-Organization-Network-Message-Id: 344e25a8-2168-4941-47b2-08d74cdf709a X-EOPAttributedMessage: 0 X-MS-Exchange-Organization-MessageDirectionality: Originating X-Forefront-Antispam-Report: CIP:128.138.67.74;IPV:CAL;CTRY:US;EFV:NLI;SFV:SKN;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:CY4PR03MB2421;H:ipmx3.colorado.edu;FPR:;SPF:None;LANG:en;;SKIP:1; X-MS-Exchange-Organization-AuthSource: BY2NAM01FT057.eop-nam01.prod.protection.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-OriginatorOrg: colorado.edu X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 344e25a8-2168-4941-47b2-08d74cdf709a X-MS-TrafficTypeDiagnostic: CY4PR03MB2421:|CY4PR03MB2421: X-MS-Exchange-Organization-SCL: -1 X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Microsoft-Antispam: BCL:0; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2019 17:38:04.4589 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 344e25a8-2168-4941-47b2-08d74cdf709a X-MS-Exchange-CrossTenant-Id: 3ded8b1b-070d-4629-82e4-c0b019f46057 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3ded8b1b-070d-4629-82e4-c0b019f46057;Ip=[128.138.67.74];Helo=[ipmx3.colorado.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2421 X-MS-Exchange-Transport-EndToEndLatency: 00:12:25.4104357 X-MS-Exchange-Processed-By-BccFoldering: 15.20.2347.014 X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;ex:0;auth:0;dest:I;ENG:(750127)(520002050)(944506383)(944626516); X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?ocmrnBwK8t/OcXqFJ9CYFb8g/0NMOPY+cJyFBTHKH5JjoJSsLcZ72iCIr6F/?= =?us-ascii?Q?FvJMRRFgpEwk+6QaBk9tBo8qZQMv9/NGyBY4VCcneni064T3AKG6BINT5YzA?= =?us-ascii?Q?LklLOJaRs0faQ4Aw0wuzfr7F1HtghJjlg2eJyyX/H/Zt5noW72Gu71CUJMTe?= =?us-ascii?Q?cLDdwgGV9lV8JCGuu3j+a0H6kv+oJfOBRDhoKogevHv76c8OedA92TfS9W+F?= =?us-ascii?Q?V4xPEoVc+Jmx0noFbmu4jVwndLKzGBcjmflpJ/9eh2Z6o/YlbES6ZoYgr48q?= =?us-ascii?Q?1Cwakq/yNVbCoApHUvRw+dEhJfi+RSJjnuu9BZ1mcDycSV9n9U/JYiKHreTx?= =?us-ascii?Q?YWSZQ/zOhKmxAp5WamqpqryED57S7glDxhrqFL5tvXefQq7QY+lrgSeMHCXq?= =?us-ascii?Q?9nfTwF8DtjLahOxvCgwPKcw3QSsbvu52s6mLEKKVQqumJdxzvsUeT9794uRM?= =?us-ascii?Q?t9NoFY7Aa9PZ3asZUJk2qK9PZcEnb7U2Lm8x0s/k/Lw4bPwVemyHMBZZhHo3?= =?us-ascii?Q?Nb0Pa3Ti9UK87BwxbLMDMHYnDfgQhpcV2/PSdIe4PqubWL62/Ybee3v7Vjvf?= =?us-ascii?Q?uS0KPNiUMbPI3RdNibIRWWcRIuQn8WU1TA5N7eUxQZJaDLyK+sxKvAumv/V+?= =?us-ascii?Q?2TDq71sDsYKGYMuFup5lwHmIxpOVpFKVEXgirHTEb4Bu+Ukk/uc1EN8b5gU+?= =?us-ascii?Q?j+tktbB27XGBDld2IkXQgVtc0rR+5EdsoDXBre9vcXSdrrpywJJewCx13DAn?= =?us-ascii?Q?SUgll1xTgaTC8IpYDEsyK1JnWgaByQhucqN1ZgRlOET67lg2ckgJ0Y2pAy7J?= =?us-ascii?Q?MjXAtLjBb4spwNLu0+zvMs39fr2hCN5zmzzwkQ6QRq+PQMLrj9K8FRAQcU6D?= =?us-ascii?Q?m4Y1lCCRtvb/OXOU+15fSttbTddu+WIbtBNAoIb9SuN3a4MKGWi6H0ZUyAxj?= =?us-ascii?Q?Ta/cjzRAvfQRR+lWzA8xwiiC6Vxgngi2+IJivqVI51ZjSj0ZqI0cYHT8z72N?= =?us-ascii?Q?BjIZQ480do3/QSmmKPA+ocxb3gwWfDsQrFIBUAikpL9jpA+E2I4NNRYN1vTs?= =?us-ascii?Q?JAKQds60EHM6FEYjNY4IfUle88x1EXBDcpa9JuJVhV+gUFy8tH8=3D?= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Message-ID: <20191009162339.p71IUWLPzTq4eR6U4OzC1pApqqtqzqPzwZEzJewXse0@z> On Wed 09-10-19 11:08:35, Qian Cai wrote: > On Wed, 2019-10-09 at 16:34 +0200, Michal Hocko wrote: > > On Wed 09-10-19 10:19:44, Qian Cai wrote: > > > On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote: > >=20 > > [=2E=2E=2E] > > > > Can you paste the full lock chain graph to be sure we are on the sa= me > > > > page? > > >=20 > > > WARNING: possible circular locking dependency detected > > > 5=2E3=2E0-next-20190917 #8 Not tainted > > > ------------------------------------------------------ > > > test=2Esh/8653 is trying to acquire lock: > > > ffffffff865a4460 (console_owner){-=2E-=2E}, at: > > > console_unlock+0x207/0x750 > > >=20 > > > but task is already holding lock: > > > ffff88883fff3c58 (&(&zone->lock)->rlock){-=2E-=2E}, at: > > > __offline_isolated_pages+0x179/0x3e0 > > >=20 > > > which lock already depends on the new lock=2E > > >=20 > > >=20 > > > the existing dependency chain (in reverse order) is: > > >=20 > > > -> #3 (&(&zone->lock)->rlock){-=2E-=2E}: > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__lock_acquire+0x5b3/0xb40 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lock_acquire+0x126/0x280 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0_raw_spin_lock+0x2f/0x40 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0rmqueue_bulk=2Econstprop=2E2= 1+0xb6/0x1160 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0get_page_from_freelist+0x89= 8/0x22c0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__alloc_pages_nodemask+0x2f= 3/0x1cd0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0alloc_pages_current+0x9c/0x= 110 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0allocate_slab+0x4c6/0x19c0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0new_slab+0x46/0x70 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0___slab_alloc+0x58b/0x960 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__slab_alloc+0x43/0x70 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__kmalloc+0x3ad/0x4b0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__tty_buffer_request_room+0= x100/0x250 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tty_insert_flip_string_fixe= d_flag+0x67/0x110 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pty_write+0xa2/0xf0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0n_tty_write+0x36b/0x7b0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tty_write+0x284/0x4c0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__vfs_write+0x50/0xa0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0vfs_write+0x105/0x290 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0redirected_tty_write+0x6a/0= xc0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0do_iter_write+0x248/0x2a0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0vfs_writev+0x106/0x1e0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0do_writev+0xd4/0x180 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__x64_sys_writev+0x45/0x50 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0do_syscall_64+0xcc/0x76c > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0entry_SYSCALL_64_after_hwfr= ame+0x49/0xbe > >=20 > > This one looks indeed legit=2E pty_write is allocating memory from insi= de > > the port->lock=2E But this seems to be quite broken, right? The forward= > > progress depends on GFP_ATOMIC allocation which might fail easily under= > > memory pressure=2E So the preferred way to fix this should be to change= > > the allocation scheme to use the preallocated buffer and size it from a= > > context when it doesn't hold internal locks=2E It might be a more compl= ex > > fix than using printk_deferred or other games but addressing that would= > > make the pty code more robust as well=2E >=20 > I am not really sure if doing a surgery in pty code is better than fixing= the > memory offline side as a short-term fix=2E If this was only about the memory offline code then I would agree=2E But we are talking about any printk from the zone->lock context and that is a bigger deal=2E Besides that it is quite natural that the printk code should be more universal and allow to be also called from the MM contexts as much as possible=2E If there is any really strong reason this is not possible then it should be documented at least=2E --=20 Michal Hocko SUSE Labs