Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp6118087pxb; Mon, 14 Feb 2022 16:02:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJz//q4LadAHj/r2SjDwm2kLoSIbZ+fnqNOI322PZVbRLcYAtGWdYxueuAjEL9ESaGyGVGoB X-Received: by 2002:a17:902:ced1:: with SMTP id d17mr1342142plg.78.1644883326309; Mon, 14 Feb 2022 16:02:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644883326; cv=none; d=google.com; s=arc-20160816; b=CF7gGZKhQi41klW6ocWEuPzoGBBMqh4OCnJJ6JnB6v/cY+yQBBXsh1xfRbKogqc2Zu l8PofO2gn82LKebKOgazyGVsEqO51CBaVf4tXD66F2V/eCQp5DT6vv0/OeGWQoJFk6/L /uTRWAsNtxYNqlD4VYHZbF9u5i/XVU9Lh47/flZGzLkyUMKYy+IRMNB099k0j3j39RCG FAF1JCGG2DzFokw7H7XNqy2IruQ/jxRLl8k1M28q/oIjSKWDbiWPAvVs9FfzqQR8q/ca nA7FGDKelSgr1ULwfEcCCMfTScE2INSJ2kJljfetTQuzFfe8mZHNttVIisHlFcndK3cs fs+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=9iLzCF2TaMCSxVJ++G7B9k6oyEfu4Hb24dWcp9NavGo=; b=cbVc9CGtfPxcm9JAvueVabGLe6k6AupfN6Ed0L0UpROXdvvW6ESu3dU8CMxl7PCXIM h1aWzefWx2/wYo5hZVWr0angSbe82Z5ldXtGQMAnLm9iUkuotsRpXEtigck99CHsFE6Z +ZcA420x0gbIQSfslIpaJ54ysMUh/YSJ3sIgjMB/kB2EaB7/XGafu06tDgDOYkgkxtVM +QZxHmwh3aEy6aEtWDhRBj0iQqVPlcfee7mlMqzYC6gVkMfSmeJiyRGW7ZNKMD3FvYR9 L9g56t0bXRrAfby1e3wm7dBaUNDAT1C1cKJjDnefOaohTfSWc7IRc9auc4HgwidfiQja AAdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bvMGtJIy; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f128si1132083pgc.440.2022.02.14.16.01.50; Mon, 14 Feb 2022 16:02:06 -0800 (PST) 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=@google.com header.s=20210112 header.b=bvMGtJIy; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230027AbiBNVfh (ORCPT + 99 others); Mon, 14 Feb 2022 16:35:37 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:33158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231482AbiBNVfX (ORCPT ); Mon, 14 Feb 2022 16:35:23 -0500 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40724160FF4 for ; Mon, 14 Feb 2022 13:33:43 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id v186so50260546ybg.1 for ; Mon, 14 Feb 2022 13:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9iLzCF2TaMCSxVJ++G7B9k6oyEfu4Hb24dWcp9NavGo=; b=bvMGtJIya6i3kldlZ68PIkQqYQHrWh9etw576kRgvqubMe8pOdz7mPqNNyEWu0qYpu K2+jd6xSBx5ppv4DQhtAnJ/C1/ar+hoh3j4AET1ped77vG9F4QpStWrR5C/ynxDK3vKN F4ftSIe8zSlM/Ns0STbrln5QJiVtN8Mb1FflduG9ZT54+xcqp70wfp9WWIW2Zk6aDtuu Djv4CpRkBWIv6K7ZeB7+p1MAM8FavXkccQBC2frvBkJ2JfvUDXYUQVZoWaiMCLK08wlH BGwhSfln6q5TY9QJ0CXJOGeU35akaI0qKxsYbaroT2gei4kFJSaQtHAN9gq7j5k3cA9G 1Q1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9iLzCF2TaMCSxVJ++G7B9k6oyEfu4Hb24dWcp9NavGo=; b=dvo/Wf88ROd2+cbAcqeZA5m5OtYQHC4fgBxyK3TB7+qsuwDnAIZE9cpPmA0OUXhy5j hj7qmCR33V01wgbRPNC1yOtICJlxWHywag4NJJiVGj6Cg6+PqDwXsj98Q/naL863j76u gwTCAH9Ak/PiwvnFV/MCwrWHngUh40A5eyt2mR+RvcFPueVgSRDGSPAH0VPfgL6T/Kfi /hJdreFs1xMroQpfgVII0j0yehre3QMGHnIQ2eTO8Pwkm+Wfhzrb/c9mF0NYxtUh7WOk VzDbD3/ZJbFEihF4q6AcpAemigFWKLMnXx4qOo7FGGQVBN8LfJyusTmENVroQXNxyORi Lrmw== X-Gm-Message-State: AOAM531GpGUfE8XZQNdRICrM1RylwoaytVwHVvszhxHZ/RdUUpAUlBJp FFEJRdOiKidPgwmKNUiuXhqIGSxia4ucaXuRReJ+Ernnvv1yLipx X-Received: by 2002:a25:6a55:: with SMTP id f82mr574637ybc.1.1644866971626; Mon, 14 Feb 2022 11:29:31 -0800 (PST) MIME-Version: 1.0 References: <20220211161831.3493782-1-tjmercier@google.com> <20220211161831.3493782-7-tjmercier@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 14 Feb 2022 11:29:20 -0800 Message-ID: Subject: Re: [RFC v2 6/6] android: binder: Add a buffer flag to relinquish ownership of fds To: Todd Kjos Cc: Greg Kroah-Hartman , "T.J. Mercier" , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Jonathan Corbet , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , John Stultz , Tejun Heo , Zefan Li , Johannes Weiner , Kalesh Singh , Kenny.Ho@amd.com, DRI mailing list , "open list:DOCUMENTATION" , LKML , linux-media , "moderated list:DMA BUFFER SHARING FRAMEWORK" , cgroups mailinglist Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Mon, Feb 14, 2022 at 10:33 AM Todd Kjos wrote: > > On Fri, Feb 11, 2022 at 11:19 PM Greg Kroah-Hartman > wrote: > > > > On Fri, Feb 11, 2022 at 04:18:29PM +0000, T.J. Mercier wrote: > > Title: "android: binder: Add a buffer flag to relinquish ownership of fds= " > > Please drop the "android:" from the title. > > > > This patch introduces a buffer flag BINDER_BUFFER_FLAG_SENDER_NO_NEED > > > that a process sending an fd array to another process over binder IPC > > > can set to relinquish ownership of the fds being sent for memory > > > accounting purposes. If the flag is found to be set during the fd arr= ay > > > translation and the fd is for a DMA-BUF, the buffer is uncharged from > > > the sender's cgroup and charged to the receiving process's cgroup > > > instead. > > > > > > It is up to the sending process to ensure that it closes the fds > > > regardless of whether the transfer failed or succeeded. > > > > > > Most graphics shared memory allocations in Android are done by the > > > graphics allocator HAL process. On requests from clients, the HAL pro= cess > > > allocates memory and sends the fds to the clients over binder IPC. > > > The graphics allocator HAL will not retain any references to the > > > buffers. When the HAL sets the BINDER_BUFFER_FLAG_SENDER_NO_NEED for = fd > > > arrays holding DMA-BUF fds, the gpu cgroup controller will be able to > > > correctly charge the buffers to the client processes instead of the > > > graphics allocator HAL. > > > > > > From: Hridya Valsaraju > > > Signed-off-by: Hridya Valsaraju > > > Co-developed-by: T.J. Mercier > > > Signed-off-by: T.J. Mercier > > > --- > > > changes in v2 > > > - Move dma-buf cgroup charge transfer from a dma_buf_op defined by ev= ery > > > heap to a single dma-buf function for all heaps per Daniel Vetter and > > > Christian K=C3=B6nig. > > > > > > drivers/android/binder.c | 26 ++++++++++++++++++++++++++ > > > include/uapi/linux/android/binder.h | 1 + > > > 2 files changed, 27 insertions(+) > > > > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c > > > index 8351c5638880..f50d88ded188 100644 > > > --- a/drivers/android/binder.c > > > +++ b/drivers/android/binder.c > > > @@ -42,6 +42,7 @@ > > > > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > > > > > +#include > > > #include > > > #include > > > #include > > > @@ -2482,8 +2483,10 @@ static int binder_translate_fd_array(struct li= st_head *pf_head, > > > { > > > binder_size_t fdi, fd_buf_size; > > > binder_size_t fda_offset; > > > + bool transfer_gpu_charge =3D false; > > > const void __user *sender_ufda_base; > > > struct binder_proc *proc =3D thread->proc; > > > + struct binder_proc *target_proc =3D t->to_proc; > > > int ret; > > > > > > fd_buf_size =3D sizeof(u32) * fda->num_fds; > > > @@ -2521,8 +2524,15 @@ static int binder_translate_fd_array(struct li= st_head *pf_head, > > > if (ret) > > > return ret; > > > > > > + if (IS_ENABLED(CONFIG_CGROUP_GPU) && > > > + parent->flags & BINDER_BUFFER_FLAG_SENDER_NO_NEED) > > > + transfer_gpu_charge =3D true; > > > + > > > for (fdi =3D 0; fdi < fda->num_fds; fdi++) { > > > u32 fd; > > > + struct dma_buf *dmabuf; > > > + struct gpucg *gpucg; > > > + > > > binder_size_t offset =3D fda_offset + fdi * sizeof(fd); > > > binder_size_t sender_uoffset =3D fdi * sizeof(fd); > > > > > > @@ -2532,6 +2542,22 @@ static int binder_translate_fd_array(struct li= st_head *pf_head, > > > in_reply_to); > > > if (ret) > > > return ret > 0 ? -EINVAL : ret; > > > + > > > + if (!transfer_gpu_charge) > > > + continue; > > > + > > > + dmabuf =3D dma_buf_get(fd); > > > + if (IS_ERR(dmabuf)) > > > + continue; > > > + > > > + gpucg =3D gpucg_get(target_proc->tsk); > > > + ret =3D dma_buf_charge_transfer(dmabuf, gpucg); > > > + if (ret) { > > > + pr_warn("%d:%d Unable to transfer DMA-BUF fd ch= arge to %d", > > > + proc->pid, thread->pid, target_proc->pi= d); > > > + gpucg_put(gpucg); > > > + } > > > + dma_buf_put(dmabuf); > > Since we are creating a new gpu cgroup abstraction, couldn't this > "transfer" be done in userspace by the target instead of in the kernel > driver? Then this patch would reduce to just a flag on the buffer > object. Are you suggesting to have a userspace accessible cgroup interface for transferring buffer charges and the target process to use that interface for requesting the buffer to be charged to its cgroup? I'm worried about the case when the target process does not request the transfer after receiving the buffer with this flag set. The charge would stay with the wrong process and accounting will be invalid. Technically, since the proposed cgroup supports charge transfer from the very beginning, the userspace can check if the cgroup is mounted and if so then it knows this feature is supported. > This also solves the issue that Greg brought up about > userspace needing to know whether the kernel implements this feature > (older kernel running with newer userspace). I think we could just > reserve some flags for userspace to use (and since those flags are > "reserved" for older kernels, this would enable this feature even for > old kernels) > > > > } > > > return 0; > > > } > > > diff --git a/include/uapi/linux/android/binder.h b/include/uapi/linux= /android/binder.h > > > index 3246f2c74696..169fd5069a1a 100644 > > > --- a/include/uapi/linux/android/binder.h > > > +++ b/include/uapi/linux/android/binder.h > > > @@ -137,6 +137,7 @@ struct binder_buffer_object { > > > > > > enum { > > > BINDER_BUFFER_FLAG_HAS_PARENT =3D 0x01, > > > + BINDER_BUFFER_FLAG_SENDER_NO_NEED =3D 0x02, > > > }; > > > > > > /* struct binder_fd_array_object - object describing an array of fds= in a buffer > > > -- > > > 2.35.1.265.g69c8d7142f-goog > > > > > > > How does userspace know that binder supports this new flag? And where > > is the userspace test for this new feature? Isn't there a binder test > > framework somewhere? > > > > thanks, > > > > greg k-h