Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp71001ybz; Wed, 15 Apr 2020 04:44:57 -0700 (PDT) X-Google-Smtp-Source: APiQypIXImPwp+BMwON2w/JPzMmf4SU9PlYfVFFzD2KcnskeKTN65EhZL2EWly0boIme3yqJJ7HR X-Received: by 2002:a50:cb84:: with SMTP id k4mr25233745edi.89.1586951097774; Wed, 15 Apr 2020 04:44:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586951097; cv=none; d=google.com; s=arc-20160816; b=eXgPGNiwBQWZsvYuZ7QPRQ7RiNt5pVWstXWLEVz1y3T5dT+e70B8oVsub5yrFDYURA cL+f15Zi45ocKgZORw5UgwVfI3y4nTyGUDRtNeQL4VtHTrqZFdU58xDRg41L1hb0831p 5gtdSFwjaQqby/zU7QClBvxLBq+SsbslXNxwjWPof5P0zABVokPd3Y5DJ8vNODU9t9If OPugINQeemSkn7vPgYef3Zg/eY0Uis8l9cjofjAiMOuwaX0l/xBL2Fz/M2HmmLvXSW57 6LaH8dnqQI/34OXx8l+bMGzPpTt2oLKDWIL+zgkyHKwkrgRBcCHTqkFr47dOezHN8Vbq UaXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xRv3zHjgsvNf6oxcYZAPAfBG9R2sYUYELJv9kttB0vE=; b=JOHrw6UWrj7yt/o8iDS4W3wN664NPou6qyGtKYYVeTfS/wFtZdJxF815QR4A9/JV2X HoyJKiOz31fTijnkj1IWt7HBXEJbPNW+npZujpJ+n7yzRLMYjPLwFdW5Z0aGoWwUOrkV 0qcdU0hksElDMxdCba43r5Y+kA+IaksqUx+s3G08xVtdkIErNe7dkuIP7/trfYhbS8DT oy5rF7Jz2fWhQGXisq6Gft32CRqNgkYtl79ZmX7/vltm4UZ9ExIcT7Gbk+5L9rpn7eWc cBH9b6jV2FKSgN7VbDNb//iqPMw6WusK14FDhxTBiExbAwThlwVard+d5drVvSRDHjyf 2AwA== 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 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ba27si10049358edb.586.2020.04.15.04.44.34; Wed, 15 Apr 2020 04:44:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406187AbgDNHAV (ORCPT + 99 others); Tue, 14 Apr 2020 03:00:21 -0400 Received: from verein.lst.de ([213.95.11.211]:37725 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728471AbgDNHAT (ORCPT ); Tue, 14 Apr 2020 03:00:19 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 024D068BEB; Tue, 14 Apr 2020 09:00:13 +0200 (CEST) Date: Tue, 14 Apr 2020 09:00:13 +0200 From: Christoph Hellwig To: Yan Zhao Cc: Christoph Hellwig , Jens Axboe , Felipe Balbi , "Michael S. Tsirkin" , Jason Wang , intel-gvt-dev@lists.freedesktop.org, Felix Kuehling , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, io-uring@vger.kernel.org, linux-mm@kvack.org, Zhenyu Wang , intel-gfx@lists.freedesktop.org, linux-fsdevel@vger.kernel.org, Alex Deucher , Andrew Morton , virtualization@lists.linux-foundation.org, Linus Torvalds , Zhi Wang , Al Viro Subject: Re: [PATCH 2/6] i915/gvt/kvm: a NULL ->mm does not mean a thread is a kthread Message-ID: <20200414070013.GA23680@lst.de> References: <20200404094101.672954-1-hch@lst.de> <20200404094101.672954-3-hch@lst.de> <20200407030845.GA10586@joy-OptiPlex-7040> <20200413132730.GB14455@lst.de> <20200414000410.GE10586@joy-OptiPlex-7040> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200414000410.GE10586@joy-OptiPlex-7040> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 13, 2020 at 08:04:10PM -0400, Yan Zhao wrote: > > I can't think of another way for a kernel thread to have a mm indeed. > for example, before calling to vfio_dma_rw(), a kernel thread has already > called use_mm(), then its current->mm is not null, and it has flag > PF_KTHREAD. > in this case, we just want to allow the copy_to_user() directly if > current->mm == mm, rather than call another use_mm() again. > > do you think it makes sense? I mean no other way than using use_mm. That being said nesting potentional use_mm callers sounds like a rather bad idea, and we should avoid that.