Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp819917pxb; Tue, 12 Apr 2022 14:21:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweE/FwJJU9i4luqCJdZ0woJFGNitd+4c2bTWdHVyVLYAzBbFwCE2jaXs2OwcRv/5J2D83A X-Received: by 2002:a17:903:1246:b0:155:c376:e5a0 with SMTP id u6-20020a170903124600b00155c376e5a0mr38296094plh.167.1649798470105; Tue, 12 Apr 2022 14:21:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649798470; cv=none; d=google.com; s=arc-20160816; b=Zg2B/rE4Ux78MJfWnsbO7Jq1w3mtMPx4M1ODUgDDF1h8phjP1JUPmrR4xVGN3cQJkw 0RPjF9Z9IONe4VusUimaJKE/gp6u4A+tU8d9002QrnEs8LRTmfGjEkpuGSTZpKbLSy2C nNcjo46Q7/KDMw1ZX3FwzwNzNENffxpA293F3T7EYkGqmAUmYyHCVboqQEYRSHYtcd1a X+7I92WRe3YzK25ntKf/IJKfa7w7FG65rmTFZUbzCIZfrHasSG8jSlRNlSG1F895KUph aaF1OB3OOUA5+V+T/DuiAsuzdfh4dngMNS9+tnwZPQ1gwvgKCC3biBJBP/nYi1lxyPsJ gGYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=2gp4nv3usmnEknAJenn5vKfEAoQJGK8jnmImm19d6ro=; b=x9JpEHZ3lQHgUQ3ntdpiM61D6qWIBNHwokxWx5M/ivSGZSIBF6v0/e5MN9H6Drivu9 hZ9hNvol7FkhWAZvd+0WrkcPpdbMUh373EUwKJIWyUO2+RMrIY+y/zG3/Mkk2/OeW2tK 3T7fqEuerE3nbdLLyraMIwgvzAq4O1DT7ulydjHMXSvsb3ZguSVPxvZ1cjoEskCwH1sF V05paqHy39M0Wx6xmouZcB+HtkYpvwDvgpkl95vcXtnDOKpv5TLGA/KQCXZMlBSNnbCe s2Q66Vudf5a3cs6a32DNmeUQyLVFLZELNpgjzpJ8s10FvNp5z2JCapOIv88mqr/uqD6Q wPtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=IDSUsTAl; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id mi7-20020a17090b4b4700b001c6f4558b06si9529994pjb.179.2022.04.12.14.21.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 14:21:10 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=IDSUsTAl; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A71C910FDA; Tue, 12 Apr 2022 13:35:03 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356692AbiDLOlZ (ORCPT + 99 others); Tue, 12 Apr 2022 10:41:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354554AbiDLOlX (ORCPT ); Tue, 12 Apr 2022 10:41:23 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7467E51 for ; Tue, 12 Apr 2022 07:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649774345; x=1681310345; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=GZj64pjcWXoZ+UWhUertM7DeZpkX/WIgVteyu9EF33A=; b=IDSUsTAlQ9zt0b59jP0LV/+kgzTpNpUVrcv4R4vwjuWWqkLvIUWN6qWP 0X9Xst9cA+3JzUBxiV7xW+e8YTSz/je7YsVi3RE/KvcGa8dDLZ3M+jGip GxfuQqAp49x+N/L0iASjUVLK+OIynSP3cvmCJ6kbiJzbV+qk0RK8IhdTr FCsgRq221UNAaspkkLundKvDYQ7GCx9UO7424jbX28NRNrb3+CPBUDuP3 yuNJmtmESZU2UmE0hUd3tA51ty1e31xnJGkN7qhZOGlMVyz1LuWqiiWk5 S45mql+/HkpC5q6YIlTZIFJBtY4EyAtt5lWDtgccpkdpPlhYg9Hn1NtYJ A==; X-IronPort-AV: E=McAfee;i="6400,9594,10315"; a="348826558" X-IronPort-AV: E=Sophos;i="5.90,254,1643702400"; d="scan'208";a="348826558" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2022 07:39:05 -0700 X-IronPort-AV: E=Sophos;i="5.90,254,1643702400"; d="scan'208";a="551735814" Received: from vtelkarx-mobl.amr.corp.intel.com (HELO [10.209.191.73]) ([10.209.191.73]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2022 07:39:04 -0700 Message-ID: <2cd3132b-2c24-610e-1a96-591f2803404c@intel.com> Date: Tue, 12 Apr 2022 07:39:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Fenghua Yu , "zhangfei.gao@foxmail.com" Cc: 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 References: <20220207230254.3342514-1-fenghua.yu@intel.com> <20220207230254.3342514-6-fenghua.yu@intel.com> <56ed509d-a7cf-1fde-676c-a28eb204989b@intel.com> From: Dave Hansen Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 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.