Received: by 10.223.185.116 with SMTP id b49csp2225712wrg; Thu, 15 Feb 2018 08:22:40 -0800 (PST) X-Google-Smtp-Source: AH8x226cidlpkofXp0X0TOm9X2xJQN5HXPD/zQbe941e8+JT7KBpIpQwcUPL7prOA4r89PIws+Ko X-Received: by 10.98.194.18 with SMTP id l18mr3176243pfg.118.1518711760212; Thu, 15 Feb 2018 08:22:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518711760; cv=none; d=google.com; s=arc-20160816; b=XlCyAyZpNWpq1/erDPwXGJHChAJ4dX2pCxhXQ/GzuO0Q0kRGTZGh2JFqRw28y3Tx3Q 0BgHVIx2qt0QtnwdVKrPBhz8skbFcPNCy+NYoScaM19EdY7eNY3MfzH7Yh/6gUzOUfj9 my9dnJiDQe9NgF9wOUoJSVgddeRLetL3usmfOZ3AcsEWjyo6hryokIASRHyt+BAsbghB VgOBeUo82NIgYTDtk/3iBLV6dM935v4wxjp/+AZMksU1pLheJ5LELbX551vahxcAfRcb daZlyooRwHeJdRE1sPyDLgbkiGpfZfR3/X9OjTB4XqNp01QTNwqRKobqpOHFUQDUK8zp OhFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=ld2rrrfQYmBRO+yn2IE8qZIKX35szJmObVJE5uB/vtE=; b=EPJs283yPmXPChJBhhZXEY+LrMq32hNknLjGxei4MIzYATSnMxmG900MJTtD3W+lic Uj97RkiHkB0w1j+C66mRMYf48MJwhYglUJV0tse7MNAml6N5YxHqPCItHYntgQQzSgPr Mlajc856wmC5SNwY6F30485AG4a3lZ2eoneWmEWisVp6wWxQbRRfpU+YegM7Z0yA4BEY V963gNulmYbWpUzjEvFtJfLx4OUSFZI3V3Yxznws0PTKkZLMSOi4BAgaRS7ywCIZAPfB AFkOC/tw3J6mouC1MmEA9s/TcBZpvZv2wdSxXBOY0BOo5hpM2r7Y2hHJ1PlD8kKp3O2V rtZA== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p33-v6si607673pld.310.2018.02.15.08.22.24; Thu, 15 Feb 2018 08:22:40 -0800 (PST) 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425670AbeBOQVN (ORCPT + 99 others); Thu, 15 Feb 2018 11:21:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54688 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424438AbeBOQVK (ORCPT ); Thu, 15 Feb 2018 11:21:10 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 977E437E8E; Thu, 15 Feb 2018 16:21:10 +0000 (UTC) Received: from w520.home (ovpn-117-203.phx2.redhat.com [10.3.117.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id DFA8C60C8B; Thu, 15 Feb 2018 16:21:09 +0000 (UTC) Date: Thu, 15 Feb 2018 09:21:09 -0700 From: Alex Williamson To: Linu Cherian Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linu.cherian@cavium.com, Sunil.Goutham@cavium.com Subject: Re: Handling active DMA during a VFIO application crash Message-ID: <20180215092109.51dc7a1a@w520.home> In-Reply-To: <20180215110406.GA15219@virtx40> References: <20180215110406.GA15219@virtx40> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 15 Feb 2018 16:21:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 15 Feb 2018 16:34:06 +0530 Linu Cherian wrote: > Hi, > > Was exploring the implications of an application crash while DMA > is active from a vfio PCI device; the DMA being configured and > started by the application using vfio APIs. > > The expectation is that, DMA is stopped/reset before we tear down the IOMMU mappings > and finally free the mmapped pages(on which DMA is happening). > > From the below stack trace(with dump_stack in vfio_pci_release), > [ 201.564273] [] vfio_pci_release+0x80/0x458 > [ 201.564276] [] vfio_device_fops_release+0x2c/0x50 > [ 201.564279] [] __fput+0x9c/0x218 > [ 201.564283] [] ____fput+0x20/0x30 > [ 201.564286] [] task_work_run+0xa0/0xc8 > [ 201.564289] [] do_exit+0x2bc/0x9c8 > [ 201.564293] [] do_group_exit+0x3c/0xa8 > [ 201.564296] [] get_signal+0x3e4/0x538 > [ 201.564299] [] do_signal+0x70/0x660 > [ 201.564302] [] do_notify_resume+0xe0/0x120 > > > PCI device is disabled/reset from vfio_pci_release invoked as part of > device fd release. The fd releases are in turn invoked from exit_files > and exit_task_work. > > But exit_mm, gets called before exit_files/exit_task_work in do_exit. > > Assuming all pages allocated/mmaped to a process gets freed in exit_mm, > is there is a possibility that user pages configured for DMA can get freed > to kernel before the vfio device is stopped/reset ? Pages mapped through the IOMMU are still pinned, so they have an elevated reference count and I believe therefore cannot "get freed to kernel". Nothing should therefore be able to allocate those pages until the container is released, which happens even after the device is released. Thanks, Alex