Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp961789pxb; Fri, 15 Apr 2022 16:43:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5j35w5pxFRQWdnvkgtkNqbehFaf2ewtI3HSGMh9x/Mz8Ixc9Fy/nilxNzGWHcYlGfppsA X-Received: by 2002:a05:6402:42ca:b0:423:8082:6cd3 with SMTP id i10-20020a05640242ca00b0042380826cd3mr904809edc.85.1650066195630; Fri, 15 Apr 2022 16:43:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650066195; cv=none; d=google.com; s=arc-20160816; b=QfkfWaSXR/O9U741bv5T8MuM4ucUj8mHr8t1xycbdR2h84X3to7jBx8dpWLpt7u6A2 ULFSuUe5OWNopY4BeeuMcnPBKZ920sx6u2TgaBQYRkVtu1eQfZOgXB7vBjz9TjtDvKpj AhNzIxiwpukRWxwtH8XwOEJSnEidbvyeBESK37kdY7Nx2snZb+RLPzB+LHdciNz1hJOa R1ta+ceGjgn38xEdLDtAPjCAmuvbr7+zwZvOJ7vJHLDxfPAR8lLM+QGuMo/JSRdEMMoo h4OU684/jKg4knvAx2GQh3hflAGjRbrs2y0ouk0A8klwMS7+ci4k3cDIjFVt2se2i2uh WuvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=NbwYQ85ISVEPGpcln5GImUAzhClny0UN/YLxk8qKvPI=; b=aXY2uAlu+ynNwXttDUPtMBwRwU0cbD2uibkxMDEjWHuTG/933f5d2kYbOKP0Pj5VsK pvGn+Q6J26X7C1QX5mDGAxZNGArzwmvJMn41MzJs3GElKbApG5E40r7RBGAUsd3qXh+6 Azbk2FqRaw35+NPxWZxiUyreeCd4RtAaPGcipN626uur4L4zQBu8zUuQ6B0LYMlTLo5o dZknUVKLQH++2v6gx0C9c8rlnoXLOaEeyv2VmNmaN6Lqx/cLc4W/U2Qx3k4dDOl5muSS TFvnd4fTQiUnypGVoX1NjgnoF79pWzSDSofPzVeQM6F/q+z7/FDI7EAhonFirtz7KxHf kDHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VCizJMMS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cw6-20020a170906c78600b006e89691632bsi1826767ejb.919.2022.04.15.16.42.50; Fri, 15 Apr 2022 16:43:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VCizJMMS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232756AbiDOKBZ (ORCPT + 99 others); Fri, 15 Apr 2022 06:01:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234932AbiDOKBY (ORCPT ); Fri, 15 Apr 2022 06:01:24 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4E5DBAB84 for ; Fri, 15 Apr 2022 02:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650016736; x=1681552736; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=CuY8lQWVqoDyp5M/6RY1Ni6Xf6rVDsquQgEJnRIkY8k=; b=VCizJMMSv3YSjZLSSE1pHQABelIsM/0Cn5hIj03X9TmU9FxVHB5Pqb1A s7+CDAcwn0DlxZ7uRm3Sy2uu4D0XYudmycr8+esTfnT6A3KW8rygtzFuv TZCOaDQSaPj9hUlp/Gb4+iYebvYb5cDXXgVR2JV72WUnpRdNIcbjMVzZQ CBSHLDBteqpCI8uh3O4xSzkBeBiWxYk7HrRTc9g9f01IwI7RoxXM96GjW sQc1iYPirZpKSrX4EZ3PmyOGsuxf893/8J8z/+Gje2jyQgxa0Azd/25YY XgeN8dtVrxv+czrJ8QQY/iJL8XCxV6uIHENMs+qWL+Qygj1SE2h6vuRTW w==; X-IronPort-AV: E=McAfee;i="6400,9594,10317"; a="243062798" X-IronPort-AV: E=Sophos;i="5.90,262,1643702400"; d="scan'208";a="243062798" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 02:58:56 -0700 X-IronPort-AV: E=Sophos;i="5.90,262,1643702400"; d="scan'208";a="527811351" Received: from fyu1.sc.intel.com ([172.25.103.126]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 02:58:56 -0700 Date: Fri, 15 Apr 2022 02:59:32 -0700 From: Fenghua Yu To: Dave Hansen Cc: "zhangfei.gao@foxmail.com" , Joerg Roedel , jean-philippe , Ravi V Shankar , Tony Luck , Ashok Raj , Peter Zijlstra , Dave Hansen , x86 , linux-kernel , iommu , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit Message-ID: References: <56ed509d-a7cf-1fde-676c-a28eb204989b@intel.com> <2cd3132b-2c24-610e-1a96-591f2803404c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2cd3132b-2c24-610e-1a96-591f2803404c@intel.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Dave, On Tue, Apr 12, 2022 at 07:39:10AM -0700, Dave Hansen wrote: > On 4/12/22 06:41, Fenghua Yu wrote: > >> master process quit, mmput ->? mm_pasid_drop->ioasid_free > >> But this ignore driver's iommu_sva_unbind_device function, > >> iommu_sva_bind_device and iommu_sva_unbind_device are not pair,? So driver > >> does not know ioasid is freed. > >> > >> Any suggestion? > > ioasid is per process or per mm. A daemon process shouldn't share the same > > ioasid with any other process with even its parent process. Its parent gets > > an ioasid and frees it on exit. The ioasid is gone and shouldn't be used > > by its child process. > > > > Each daemon process should call driver -> iommu_sva_bind_device -> ioasid_alloc > > to get its own ioasid/PASID. On daemon quit, the ioasid is freed. > > > > That means nqnix needs to be changed. > > Fenghua, please step back for a second and look at what you are saying. > Your patch caused userspace to break. Now, you're telling someone that > they need to go change that userspace to work around something that your > patch. How, exactly, are you suggesting that nginx could change to fix > this? What, specifically, was it doing with *fork()* that was wrong? > > It sounds to me like you're saying that it's OK to break userspace. You are right. The patch should not break userspace. I follow your suggestion to fix the issue by mmget() in binding and mmput() in unbinding. The RFC patch was sent out in another thread. Please review it. Thank you very much for your advice. -Fenghua