From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7D1D19F13F for ; Mon, 23 Sep 2024 17:52:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727113950; cv=none; b=Ql/z0xMvCfXqF9nOMbYpP+qVA5OV9hW70IkK87MJNlfyC2kRkU8VZ9pTCx1kp+SnsfBhaK1Uo/4n9dCrQo8phEdgkDQkBFBlf+/2lCtVDcZqJJPiNOiMN6hpLeUWBnhfxhhpcnp7QVVN5JDU46jnpo+To8y0f1KyqC6lyeSjt5o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727113950; c=relaxed/simple; bh=d012RvO8FEt4oNV/hdC2ORp0abycOdoKV3NqdL6MFLw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kIxQ1kvzF22N00LMiAfM13BdMK+wT/sjAhV5u5qqb4MWm0pgNwqeQflzRuaNlR7agCJ6yCWuhgo2yx8QBIq50dryKwvqiD/6nlGF9UUA7dnCbeY8u7QldnK2grsMsN7Np++KcTSdeOr0K71aDe3aJI9MtnppgtKu3Ex1AdGeiSQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=FdVzHMd4; arc=none smtp.client-ip=209.85.160.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="FdVzHMd4" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-45830ff5b70so37096511cf.1 for ; Mon, 23 Sep 2024 10:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1727113947; x=1727718747; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=d012RvO8FEt4oNV/hdC2ORp0abycOdoKV3NqdL6MFLw=; b=FdVzHMd4r7Lxr1flr8zsQ4ffKRk139iU4hQ/rTQvLexBYBtpMahYZz942euOlzFyVr 9vsKTVY8qoVtqPMPPNqjNrmTP5eaTWgQxiNRgVYPXuSu84NnHRFhTFdcMQkcWxqCEIWi tMG6mz4xRrvCJ8AvEmlh+WARdtVCMGUke1+QP8mMV9vOr61qj+bPB2EZSn7vX8Od3ELH O5lwKoOB6eBv5ajJSq5OHgLRg27uo1jrvG5GFnrM8g3Z4sHy+K6vfkxf9tEyi+KOLiUH IvfN7CntX285nGOA3rKFXXW/3uTUssrAdaPhcmrvHOLqA9B1Cwr/6Ad2jjTBcP9KsAco yLjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727113947; x=1727718747; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d012RvO8FEt4oNV/hdC2ORp0abycOdoKV3NqdL6MFLw=; b=YmJ6/Y924eHr+CEh22Sm8vdcOPOjgew5UgP2V86k3mRC/lB7whZjE9DDw8ndkvCofZ TmGS3bbN3Vb+nV7ENyPaK7HfB/vA3o14R9a+1XJyqOOKFXArJ9tgeoWR9VqwXQO6/AKr Dx7pSu4SWDq1r3kg3a8VmAryXUUPz95Kk4R+c27LcoBs7Y4JHjJLQERpzOd4fqSOypmm QHeX9JG09xSXoLvzUNUWD2QNBSj/nxaH+n9QSD8bkA2ql7i/0W0eL8N0b+SwNLmUuQxo +MAoZvDP6EkjhGD0AO7pwJdqLPMveiKtjPGGObIcarXva/wBHVtRx5h+D/dl3vzMNi/K v9fw== X-Forwarded-Encrypted: i=1; AJvYcCVN9vbcUyqqomHszKHvavCOh7TgdkehJnwUkdpKJd1H4WYVvMUHYPmbpmArwBXVCDlTglQ=@lists.linux.dev X-Gm-Message-State: AOJu0Yz4fcExjB+qQczeWvvhcZquE6kjt6kwPtgDvsLNBLRTqLM/kJbx osoGV4Bon1Ut3Rgi4bpjC5qmS/VhVNkXnlRbWm6i93t1H+E2TOmGyc/AcpDV5qM= X-Google-Smtp-Source: AGHT+IHVrqHIowyi3PGsNMuzErMWdcwmU1SRIkTjY6Vp086kbtdmtvbVDAGc60f4mvoOr4wDyCS+5A== X-Received: by 2002:a05:622a:107:b0:458:35f7:3950 with SMTP id d75a77b69052e-45b226f380cmr178883201cf.17.1727113947576; Mon, 23 Sep 2024 10:52:27 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-128-5.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.128.5]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-45b17888cdbsm49348071cf.49.2024.09.23.10.52.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Sep 2024 10:52:26 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1ssnEY-000LlC-32; Mon, 23 Sep 2024 14:52:26 -0300 Date: Mon, 23 Sep 2024 14:52:26 -0300 From: Jason Gunthorpe To: Yunsheng Lin Cc: Ilias Apalodimas , Jesper Dangaard Brouer , davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, liuyonglong@huawei.com, fanghaiqing@huawei.com, zhangkun09@huawei.com, Robin Murphy , Alexander Duyck , IOMMU , Wei Fang , Shenwei Wang , Clark Wang , Eric Dumazet , Tony Nguyen , Przemek Kitszel , Alexander Lobakin , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Shayne Chen , Sean Wang , Kalle Valo , Matthias Brugger , AngeloGioacchino Del Regno , Andrew Morton , imx@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, bpf@vger.kernel.org, linux-rdma@vger.kernel.org, linux-wireless@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH net 2/2] page_pool: fix IOMMU crash when driver has already unbound Message-ID: <20240923175226.GC9634@ziepe.ca> References: <20240918111826.863596-1-linyunsheng@huawei.com> <20240918111826.863596-3-linyunsheng@huawei.com> <894a3c2c-22f9-45b9-a82b-de7320066b42@kernel.org> <0e8c7a7a-0e2a-42ec-adbc-b29f6a514517@kernel.org> <2c5ccfff-6ab4-4aea-bff6-3679ff72cc9a@huawei.com> Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c5ccfff-6ab4-4aea-bff6-3679ff72cc9a@huawei.com> On Fri, Sep 20, 2024 at 02:14:02PM +0800, Yunsheng Lin wrote: > I am not sure what dose the API that allows netdev to "give" struct device > to page_pool look like or how to implement the API yet, but the obvious way > to stall the calling of device_del() is to wait for the inflight > page to It is not device_del() you need to stall, but the remove() function of the device driver. Once all drivers have been unbound the DMA API can be reconfigured and all existing DMA mappings must be concluded before this happens, otherwise there will be problems. So, stalling something like unregister_netdevice() would be a better target - though stalling forever on driver unbind would not be acceptable. Jason