Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4073289ybg; Fri, 25 Oct 2019 12:56:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxBux+7XGy0ju3xMZkKBXFSrzJUEz0WVuTO7bnVBKlr8ynujasYTV5jiP85/XDgw2nmsiRk X-Received: by 2002:a50:cc43:: with SMTP id n3mr6028413edi.287.1572033403942; Fri, 25 Oct 2019 12:56:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572033403; cv=none; d=google.com; s=arc-20160816; b=hSE2mrG0ccpGbYIJDpUf6GlgQn8mmq30o1lnMHMI0x0jZqSlf1nFHhUgKkpPDaR/8d F0hG/IJ0pLVpdv6ocTXbULQjU4N4y05fJ5AVLYECyks6dS1aKMSgP0h4UhYSWu02jLpC IoSHXjWuzLvhSjjDFj4aouhiwPNaR46Ce3bcpcBz/Stbbh7yFMSbcYIItgeIm/RNT9PW JY+DJFE3RizSLcWn0/ovu92gHYu500lgYyiB6yfK/n4F+N+jPz3fr7DhvIcTNVCZQCNl 082a2mHXgpzd3VTpbGyaCurlfpYJyYt3uGuDuTp2NbJFVues1cOuq2ZgE+nFOlEJ9Rtg s52Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=lBgqUmtwx8V7THzBu9Fi0keGEMLjtZvYmWld1/jN2JY=; b=0S+vKt7BC901OB4DpvA8DQcXXaP40XRb7F6A+533yp5vy08PBFMw4mzh0CdMqg43qN XFWjmvlvyVngAE/3k6Nubl8Jye0cRW8DkXkF+Isu5NQnplRGDyU64Ts7ephLhdujeZMu gEeSr5meIekc0unDdmuubCeEYqAno48oVzZz6iduZrqJjsCIR5cvb0r2VrUP4zdHebL0 iwJMoALkpUec3dy75s+vWyS7mWJUlJ0wy0JH0xpP7xzWW+M/PXlVFVKLm7Bjr6Yhsjh4 cllVplwPx1n+fJJCeFmjUQ/IhvE9ejjAYwUM+UBG9osjUIkpXj4V7LxSR2FIiE0+Gabp tHbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z2si1399300ejb.162.2019.10.25.12.56.20; Fri, 25 Oct 2019 12:56:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502110AbfJYLqg (ORCPT + 99 others); Fri, 25 Oct 2019 07:46:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:42326 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730372AbfJYLqg (ORCPT ); Fri, 25 Oct 2019 07:46:36 -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 570B6B454; Fri, 25 Oct 2019 11:46:34 +0000 (UTC) Date: Fri, 25 Oct 2019 13:46:33 +0200 From: Michal Hocko To: snazy@snazy.de Cc: Randy Dunlap , linux-kernel@vger.kernel.org, Linux MM , Andrew Morton , "Potyra, Stefan" Subject: Re: mlockall(MCL_CURRENT) blocking infinitely Message-ID: <20191025114633.GE17610@dhcp22.suse.cz> References: <4576b336-66e6-e2bb-cd6a-51300ed74ab8@snazy.de> <20191025092143.GE658@dhcp22.suse.cz> <70393308155182714dcb7485fdd6025c1fa59421.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70393308155182714dcb7485fdd6025c1fa59421.camel@gmx.de> 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 Fri 25-10-19 13:02:23, Robert Stupp wrote: > On Fri, 2019-10-25 at 11:21 +0200, Michal Hocko wrote: > > On Thu 24-10-19 16:34:46, Randy Dunlap wrote: > > > [adding linux-mm + people] > > > > > > On 10/24/19 12:36 AM, Robert Stupp wrote: > > > > Hi guys, > > > > > > > > I've got an issue with `mlockall(MCL_CURRENT)` after upgrading > > > > Ubuntu 19.04 to 19.10 - i.e. kernel version change from 5.0.x to > > > > 5.3.x. > > > > > > > > The following simple program hangs forever with one CPU running > > > > at 100% (kernel): > > > > Can you capture everal snapshots of proc/$(pidof $YOURTASK)/stack > > while > > this is happening? > > Sure, > > Approach: > - one shell running > while true; do cat /proc/$(pidof test)/stack; done > - starting ./test in another shell + ctrl-c quite some times > > Vast majority of all ./test invocations return an empty 'stack' file. > Some tries, maybe 1 out of 20, returned these snapshots. > Was running 5.3.7 for this test. > > > [<0>] __handle_mm_fault+0x4c5/0x7a0 > [<0>] handle_mm_fault+0xca/0x1f0 > [<0>] __get_user_pages+0x230/0x770 > [<0>] populate_vma_page_range+0x74/0x80 > [<0>] __mm_populate+0xb1/0x150 > [<0>] __x64_sys_mlockall+0x11c/0x190 > [<0>] do_syscall_64+0x5a/0x130 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [<0>] __handle_mm_fault+0x4c5/0x7a0 > [<0>] handle_mm_fault+0xca/0x1f0 > [<0>] __get_user_pages+0x230/0x770 > [<0>] populate_vma_page_range+0x74/0x80 > [<0>] __mm_populate+0xb1/0x150 > [<0>] __x64_sys_mlockall+0x11c/0x190 > [<0>] do_syscall_64+0x5a/0x130 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > [<0>] __handle_mm_fault+0x4c5/0x7a0 > [<0>] handle_mm_fault+0xca/0x1f0 > [<0>] __get_user_pages+0x230/0x770 > [<0>] populate_vma_page_range+0x74/0x80 > [<0>] __mm_populate+0xb1/0x150 > [<0>] __x64_sys_mlockall+0x11c/0x190 > [<0>] do_syscall_64+0x5a/0x130 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > [<0>] __do_fault+0x3c/0x130 > [<0>] do_fault+0x248/0x640 > [<0>] __handle_mm_fault+0x4c5/0x7a0 > [<0>] handle_mm_fault+0xca/0x1f0 > [<0>] __get_user_pages+0x230/0x770 > [<0>] populate_vma_page_range+0x74/0x80 > [<0>] __mm_populate+0xb1/0x150 > [<0>] __x64_sys_mlockall+0x11c/0x190 > [<0>] do_syscall_64+0x5a/0x130 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > This is expected. > // doubt this one is relevant > [<0>] __wake_up_common_lock+0x7c/0xc0 > [<0>] __wake_up_sync_key+0x1e/0x30 > [<0>] __wake_up_parent+0x26/0x30 > [<0>] do_notify_parent+0x1cc/0x280 > [<0>] do_exit+0x703/0xaf0 > [<0>] do_group_exit+0x47/0xb0 > [<0>] get_signal+0x165/0x880 > [<0>] do_signal+0x34/0x280 > [<0>] exit_to_usermode_loop+0xbf/0x160 > [<0>] do_syscall_64+0x10f/0x130 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Hmm, this means that the task has exited so how come there are other syscalls happening. Are you sure you are collecting stacks for the correct task? -- Michal Hocko SUSE Labs