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.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,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 85DC3C83003 for ; Thu, 30 Apr 2020 01:59:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1409320757 for ; Thu, 30 Apr 2020 01:59:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="U/bgW78L"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=fluxnic.net header.i=@fluxnic.net header.b="jpEXcJur" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1409320757 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fluxnic.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9548E8E0005; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 904A58E0001; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 842488E0005; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 6D7228E0001 for ; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3A9734DB2 for ; Thu, 30 Apr 2020 01:59:49 +0000 (UTC) X-FDA: 76762865298.30.feet91_8fe039068cb4d X-HE-Tag: feet91_8fe039068cb4d X-Filterd-Recvd-Size: 5628 Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Apr 2020 01:59:48 +0000 (UTC) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F416F4999C; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=sasl; bh=ErazowRay1P/AwFSRhYIU6Y2Vtg=; b=U/bgW7 8LRuDwed7cFJI+OLHcNjS2azezYw4bDECsXxOtmXzamJa8j9tAdCdRFr37MXprd5 ErxVxpe2KVIBpAKAVf2dKTwzyPiZ3RDGm+EfMP70RzW2Zf/0ARTOupK3h0F1z+hz mQJPY4L14N4+MX2vB7h1kvD7/e18IFTZLuIv8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EA42A4999B; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type; s=2016-12.pbsmtp; bh=OH9QgA1zs57t3X+399BRoLLVjiVfyd9x67bP0Lvx9VY=; b=jpEXcJureDScwgQSTF9eHzcwhmQuFrOHxRs892SZDNVkINIFS5TbHDpabFpo7Gs7IHlBnmskokz8D4i2YY5ViibSy+NBswTJ776BfV1BmS29V/WPbozOzfLFQDTEEXWotrT//LfOGQVTKKoMRDg2y4UW+ua6jfMPr/mLDlS+tJQ= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6E06D4999A; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 91EAD2DA0A91; Wed, 29 Apr 2020 21:59:46 -0400 (EDT) Date: Wed, 29 Apr 2020 21:59:46 -0400 (EDT) From: Nicolas Pitre To: Russell King - ARM Linux admin cc: Jann Horn , Andrew Morton , Linus Torvalds , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Alexander Viro , "Eric W . Biederman" , Oleg Nesterov , linux-arm-kernel@lists.infradead.org, Mark Salter , Aurelien Jacquiot , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Rich Felker , linux-sh@vger.kernel.org, Christophe Lyon Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there In-Reply-To: <20200429215620.GM1551@shell.armlinux.org.uk> Message-ID: References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Pobox-Relay-ID: 44EB08B6-8A86-11EA-B6B5-D1361DBA3BAF-78420484!pb-smtp2.pobox.com 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 Wed, 29 Apr 2020, Russell King - ARM Linux admin wrote: > On Wed, Apr 29, 2020 at 11:49:49PM +0200, Jann Horn wrote: > > At the moment, we have that rather ugly mmget_still_valid() helper to > > work around : ELF core dumping > > doesn't take the mmap_sem while traversing the task's VMAs, and if > > anything (like userfaultfd) then remotely messes with the VMA tree, > > fireworks ensue. So at the moment we use mmget_still_valid() to bail > > out in any writers that might be operating on a remote mm's VMAs. > > > > With this series, I'm trying to get rid of the need for that as > > cleanly as possible. > > In particular, I want to avoid holding the mmap_sem across unbounded > > sleeps. > > > > > > Patches 1, 2 and 3 are relatively unrelated cleanups in the core > > dumping code. > > > > Patches 4 and 5 implement the main change: Instead of repeatedly > > accessing the VMA list with sleeps in between, we snapshot it at the > > start with proper locking, and then later we just use our copy of > > the VMA list. This ensures that the kernel won't crash, that VMA > > metadata in the coredump is consistent even in the presence of > > concurrent modifications, and that any virtual addresses that aren't > > being concurrently modified have their contents show up in the core > > dump properly. > > > > The disadvantage of this approach is that we need a bit more memory > > during core dumping for storing metadata about all VMAs. > > > > After this series has landed, we should be able to rip out > > mmget_still_valid(). > > > > > > Testing done so far: > > > > - Creating a simple core dump on X86-64 still works. > > - The created coredump on X86-64 opens in GDB, and both the stack and the > > exectutable look vaguely plausible. > > - 32-bit ARM compiles with FDPIC support, both with MMU and !MMU config. > > > > I'm CCing some folks from the architectures that use FDPIC in case > > anyone wants to give this a spin. > > I've never had any reason to use FDPIC, and I don't have any binaries > that would use it. Nicolas Pitre added ARM support, so I guess he > would be the one to talk to about it. (Added Nicolas.) It's been a while since I worked with it. However Christophe Lyon (in CC) added support for ARM FDPIC to mainline gcc recently, so hopefully he might still be set up and able to help. Nicolas