Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2258857pxb; Fri, 17 Sep 2021 06:03:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwnYj+S/RIIY6D0d1i5Qh1t0xhGwMMzzylWn/rfCy0UvwirshZokcafjkKMUrCWnN675k48 X-Received: by 2002:a92:d0d2:: with SMTP id y18mr8098230ila.80.1631883821735; Fri, 17 Sep 2021 06:03:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631883821; cv=none; d=google.com; s=arc-20160816; b=efC/iWffDuhxLtpEguVe980YtdlD0DRvMRvgpre0pmsZVbYfeStpgMWnIVH3tdXMgz 1kq6XStJP+q9YmJ2oC84jkbxuAE9bKXGNLfeY/mGEMiZe1wRA8rIsVYcy4t3GWPAn597 dLpeY+Rim9A53bbth95OIpcjLUjx0NlHuexE54XbsjDfKg8XiESMPfP4dF+D60+cXAhj CnsINZJU/pUT3FMRYhqKL+2FP/Ew8mMpFyuaJBjZFuHqXzZFrrgYPuZOnGwEkS1xSQc9 /bJ7FrrnCCxdkCtrLzqpmaAkOQie3xntCGZ12G5+kGRTqDpb9njNBPB9fpuforaoiMGt OqSg== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=SIvgFsOAJwaNagReBvXsvMiZ17sqk/wFkqWt5kVAoq8=; b=bZoN0e4m0NlbgtXcsQxSPmE3el1UEaeValf2uRr8U9pmY19h1Vqx0n7Il42BOPHvBH kNicmzas8LzGBVweSfIxaX+XI7YJsT7LCyk88OgrTQBtNAbzDvEiqliJfkVdx9FjbCys 5qS1Hz/iBC9a/ifowhB5j9mRb55n4yzMQDKjeCu/gHkQNz/6Qy/VryztekOUZlsDuwWc MECa6GFZsYMK2KZjb4pPcL/0aVj0YnH5YHryyWmOEWjVcJPHkI7vxqFelBd1SGAjDEbv Mp5Br+pPpx/Fava2WEHbB7Wu0MRBcTjj7MhGhHteGIMCC+O6ah6zV2tFJu3/u0HNM3hb 6P5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: 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 g19si5963772ilb.43.2021.09.17.06.03.06; Fri, 17 Sep 2021 06:03:41 -0700 (PDT) Received-SPF: pass (google.com: 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: 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 S234157AbhIQHqG (ORCPT + 99 others); Fri, 17 Sep 2021 03:46:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:37332 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231263AbhIQHqF (ORCPT ); Fri, 17 Sep 2021 03:46:05 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7B04C60F38; Fri, 17 Sep 2021 07:44:42 +0000 (UTC) Date: Fri, 17 Sep 2021 09:44:40 +0200 From: Christian Brauner To: Christoph Hellwig Cc: Mike Christie , stefanha@redhat.com, jasowang@redhat.com, mst@redhat.com, sgarzare@redhat.com, virtualization@lists.linux-foundation.org, axboe@kernel.dk, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/8] fork: add helper to clone a process Message-ID: <20210917074440.qwo6anrtxa7lj657@wittgenstein> References: <20210916212051.6918-1-michael.christie@oracle.com> <20210916212051.6918-2-michael.christie@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 17, 2021 at 07:00:35AM +0100, Christoph Hellwig wrote: > On Thu, Sep 16, 2021 at 04:20:44PM -0500, Mike Christie wrote: > > The vhost layer has similar requirements as io_uring where its worker > > threads need to access the userspace thread's memory, want to inherit the > > parents's cgroups and namespaces, and be checked against the parent's > > RLIMITs. Right now, the vhost layer uses the kthread API which has > > kthread_use_mm for mem access, and those threads can use > > cgroup_attach_task_all for v1 cgroups, but there are no helpers for the > > other items. > > > > This adds a helper to clone a process so we can inherit everything we > > want in one call. It's a more generic version of create_io_thread which > > will be used by the vhost layer and io_uring in later patches in this set. > > > > This patch also exports __set_task_comm and wake_up_new_task which is > > needed by modules to use the new helper. io_uring calls these functions > > already but its always built into the kernel so was not needed before. > > Can you build proper APIs please? e.g. the set_task_comm users > generally want a printf-like varargs caling conventions. I'd also > much prefer to hide as much as possible in the actual helper. That is > build a helper that gets the name, a flag to ignore the singals etc > instead of exporting all these random low-level helpers. Yes, I think that's really what we want here.