Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp3618205pxb; Tue, 19 Apr 2022 06:42:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyIE1ByauIDW2wGKAoNuDGAgGbHb7mxXjSEZEfZ8RA066Wyuxen2yGSi80QgccbRJ3fo8fG X-Received: by 2002:a05:6402:514:b0:41d:787f:b99d with SMTP id m20-20020a056402051400b0041d787fb99dmr17277579edv.76.1650375761167; Tue, 19 Apr 2022 06:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650375761; cv=none; d=google.com; s=arc-20160816; b=mRqCxf34iB3P64kJcb4ydgUvs15ndmzwASbOopk+r0xRqhmj9WZ//8yx9R7Cf2D4xc AXfDFEDtDr8djQWL+3ZMUD13A+3E4poIyWgEmoQT1eJun0tBAM6WYKdGoc2mCYpsOSe4 Oq5GXKWPuK4qHfsvQY+tLc5BO+C8nvLq2Tp4vqKqISmIEImxS9LxP6om3W4N+v7bETy/ 2s3ivMl42JcQZ3IoxrakHBBTFSgV3HOfmgRWPxO42/d+r14w5CFPhgZDa6XtDm348Biu Ir3whWy2EwHhjIkJcLobtkLXzz69Jw1NqDjtsgtbrmok06R/2PY1eCfQlITTaDogiUKB o+3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:from:references:cc:to :subject:message-id:dkim-signature; bh=yQw6ERdnn3s8Fdav1zgTS27N91rjx8DazpHXI6e3k9g=; b=Jj+nxL1Oy3tKyT+YAjajxtkFAOxxm6BOWf0NcYxe5JxEJ2Q4CLSjsgieTnNSP0qUTx y+fFsg3bkDoNGssE4qxRUvcAFvHUSA7zW/pZasXpgKeZoJXyeV6LBp7ZNBhM7CVWsalq 3du7AwUgVgdNF+hIkeZ1ynpIM6Mgr4V6NPyEmDUOq7fyJh/YkvoZPmFccYHx6rf2Rnbv tKccLwmXZzcAhun/ZJCQmkjMe5VA6uKeuNKE4BHA1yRwRUyTKJ6rBm6CWzWiOq7CblpC kXKZoH/2T7bpr17pN6KkX0ijZnsPeRLfFUntZssz+odI/adJe6Q3+ORiXUl1tuzMMvh9 fazA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foxmail.com header.s=s201512 header.b=wX9u6xnU; 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=foxmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 17-20020a508e11000000b0041d053799bdsi8374444edw.493.2022.04.19.06.42.17; Tue, 19 Apr 2022 06:42:41 -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=@foxmail.com header.s=s201512 header.b=wX9u6xnU; 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=foxmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244484AbiDSBFp (ORCPT + 99 others); Mon, 18 Apr 2022 21:05:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235301AbiDSBFo (ORCPT ); Mon, 18 Apr 2022 21:05:44 -0400 Received: from out203-205-251-72.mail.qq.com (out203-205-251-72.mail.qq.com [203.205.251.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FACA286EF for ; Mon, 18 Apr 2022 18:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1650330179; bh=yQw6ERdnn3s8Fdav1zgTS27N91rjx8DazpHXI6e3k9g=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=wX9u6xnU+1iU+RQWEeun9aJ9e0cu4jgZXT5HiunHslNoszXVkxD5tspBoz/oGw8JJ U7JkwdLi1Y7TtDD7V4xC27RSkWmWyhEEhlQNSvrME0oKhjWH6OqB3h/Pu8I83MAVVl 8T0bqwywbYMlJ4UIkhTL7TbaGkbI1i5bv/gr1R8I= Received: from [IPv6:240e:362:460:400:41fe:9861:6ad0:79fe] ([240e:362:460:400:41fe:9861:6ad0:79fe]) by newxmesmtplogicsvrsza9.qq.com (NewEsmtp) with SMTP id B6A6E5A; Tue, 19 Apr 2022 09:02:54 +0800 X-QQ-mid: xmsmtpt1650330174tqi25minl Message-ID: X-QQ-XMAILINFO: Nt+cTZuZCMyik92w9EY9stqsGSh/CDo9X0G+qzdUtdySpM/m5C070YTOea1dBJ +2Bs3QwRxH60eS6D7F55+CEt7KqH6xFEoI+us5qSfF6MTwwKKMLoDplJJxWPzhxL5PtsjJYIcABA tyS4ORs0Bh/+sQe/P8QvmDPxqZBvsjzrpGRdERBJRB16184gIJixl7GwBBe5xeXNwLssJf6oWeU1 pzeozIytl6psXz6SqUVdsbEGdwzR/2xDAa+cVTTrwZlXfM+VLY5KtTHfgqSsvqGtlV/81EjzdeTi RtVsm15vD6fgfbB+g2u5KRIuQXPJH7YuyeWSXdRrZuWk/jUkY47XnjBxy71UjGppv+vWxByeCXcp C6ikojnvEotPwJBE2N8ZGP70yEOzEzhUVgvP4RbrQO4cy9ttzMrO4CmIhUwoRC2gvo81J4J8yMu/ 08KS4CfdPd3plqPxrap8bvkZUo8P7wHwiuoHlVhqD5efu8yn37EH28CDuK6OfpnawbgpHeXGIsjy QrVPvheS0keXO6ngqUT3xL2r/351F/FKZ1ff1PC1IEzq6MCajzFU6n9V3pBfiw1KGywAvJMmlvWd 8pV6RywoXRqfVZY4RloXNrf3Li6qQ0+UV65yxTC0X6Fmm96V25Je7wpSn7EJFiaIzPbIOgBCcMIA QzQFxTQuajKPH2t7ESXO/b0K4WrwBJU4M8MFdp7ZIXbdTaviwruDwb49si0xunA++m7pHLOYIR/F O9OmQ3Q3Yn8YDe62mwY51wrbiCDgi4doT+rUPIc7QJ5fRoKAhSoUQ5ezsp8/5xLKk7rLGQG9WRNi 662Yx4nqx01lztk+5WARBDC8GGUqSjRrpekBEj01iay773/sptva6nTwTwhAzA82irt2ELAf0Usw RB2kCusSp/lydO6n2m3C6XwV0pBGSaCeyLpGtzi1cGqiQ/BlFIKVcYNvV0yeEI1KesL7VanIT6jN SctJrB4XE= Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit To: Jacob Pan Cc: Fenghua Yu , Ravi V Shankar , Tony Luck , Ashok Raj , jean-philippe , Peter Zijlstra , Dave Hansen , x86 , linux-kernel , Dave Hansen , iommu , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner References: <99bcb9f5-4776-9c40-a776-cdecfa9e1010@foxmail.com> <20220415140002.7c12b0d2@jacob-builder> <20220418111456.2f1a1285@jacob-builder> From: "zhangfei.gao@foxmail.com" X-OQ-MSGID: <16001fe9-34b1-e3aa-9aa6-ebcc9793c966@foxmail.com> Date: Tue, 19 Apr 2022 09:02:52 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20220418111456.2f1a1285@jacob-builder> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_MUA_MOZILLA, FREEMAIL_FROM,HELO_DYNAMIC_IPADDR,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, RDNS_DYNAMIC,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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 2022/4/19 上午2:14, Jacob Pan wrote: > Hi zhangfei.gao@foxmail.com, > > On Sat, 16 Apr 2022 09:43:07 +0800, "zhangfei.gao@foxmail.com" > wrote: > >> On 2022/4/16 上午5:00, Jacob Pan wrote: >>> Hi zhangfei.gao@foxmail.com, >>> >>> On Fri, 15 Apr 2022 19:52:03 +0800, "zhangfei.gao@foxmail.com" >>> wrote: >>> >>>>>>> A PASID might be still used even though it is freed on mm exit. >>>>>>> >>>>>>> process A: >>>>>>> sva_bind(); >>>>>>> ioasid_alloc() = N; // Get PASID N for the mm >>>>>>> fork(): // spawn process B >>>>>>> exit(); >>>>>>> ioasid_free(N); >>>>>>> >>>>>>> process B: >>>>>>> device uses PASID N -> failure >>>>>>> sva_unbind(); >>>>>>> >>>>>>> Dave Hansen suggests to take a refcount on the mm whenever binding >>>>>>> the PASID to a device and drop the refcount on unbinding. The mm >>>>>>> won't be dropped if the PASID is still bound to it. >>>>>>> >>>>>>> Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID >>>>>>> allocation and free it on mm exit") >>>>>>> >>> Is process A's mm intended to be used by process B? Or you really should >>> use PASID N on process B's mm? If the latter, it may work for a while >>> until B changes mapping. >>> >>> It seems you are just extending the life of a defunct mm? >> From nginx code, the master process init resources, then fork daemon >> process to take over, >> then master process exit by itself. >> >> src/core/nginx.c >> main >> ngx_ssl_init(log);    -> openssl engine -> bind_fn -> sva_bind() >> ngx_daemon(cycle->log) >> >> src/os/unix/ngx_daemon.c >> ngx_daemon(ngx_log_t *log) >> { >>      int  fd; >> >>      switch (fork()) { >>      case -1: >>          ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "fork() failed"); >>          return NGX_ERROR; >> >>      case 0: >>         // the fork daemon process >>          break; >> > Does this child process call sva_bind() again to get another PASID? Or it > will keep using the parent's PASID for DMA? The master process call sva_bind (PASID A), fork daemon process, then exit. The daemon process does not call sva_bind again, only for managing worker processes. The worker process will call sva_bind for new PASID (B), for real transaction. The worker process will free the PASID (B) when worker process exit like nginx quit. nginx -s quit does not free PASID A via callback, which may should be freed by signal handler in engine itself, still in check. Thanks