Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5983685pxb; Mon, 14 Feb 2022 12:20:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJxu4RIXRz8TTH1u+6o87lin97IVGHE7RaBuurCKj+3kIDTjPJS8lSfWSr2NIt78R0grst6B X-Received: by 2002:a65:6392:: with SMTP id h18mr665598pgv.102.1644870028164; Mon, 14 Feb 2022 12:20:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644870028; cv=none; d=google.com; s=arc-20160816; b=JjgPUPRcCMZ9po5Ah2i9T7ZY5dETbsYkPbBMeq2L+1p56nTlm0oBrdaysviCbqPAQ0 rvK+abf+lzE8mEBelWJ37evE3JZ95W08WpA10cQKkeltMt3cRmw68lsowdAPoq7turHs tMpjpcjC7k4/9IK9p7ithxCDCGEIF3CEI7IeYYX209gdFxCjn8Nc/Bna7RKXm1ua8GrN Vxfs4cnctCFV6pozaFsVGSy5nDXMay7SFIJXwoibvM9UtSPiaWxpx9rvuO59saL0qC0Y ODomBOVxkI/D22fOpl/MnP7Cf7WDXIw8Si1SRfbPv6btsLQRZ96FsJkPLHWpMeYuyLAC ZS/w== 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=+UXFaXNtu58P+/quLcAfHAU/S4vyiJKyaqPdTSKWST8=; b=ovhjgrx6J27v56wkEuDuO8NC1PxYzziiiixS7KmRp/y8OLTKl5TNFUP2kl+xdbNQQp hy4inU98gnC+K3R7jbilHq4gZ/o2WmgFpCjSBPI5uMMrQstKBarLE0bFS+4cir/mVQHq vYsyycW1GYbfGLZtxZUlJ1jfGeH1XyJI8Ood+OhxQ9/J3A3B+3Ub+XqUVxYalvifXZ2o 3uTd5919S1SqhkluTss1Kb86AFk/MpUAmjhtXiigTdYa3UzdDwHU1LuE7MSZCr+/iWbY dVvEHqwyDpWGCQYEWz+kA8BzZfIq1pH2mZx0f/CVOl5EbCKQXfM1x+S76vIayzt5CmDw 7bNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sFWvgW3k; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id m1si797609pgu.534.2022.02.14.12.20.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 12:20:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sFWvgW3k; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A884612E760; Mon, 14 Feb 2022 11:54:07 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357489AbiBNSdu (ORCPT + 99 others); Mon, 14 Feb 2022 13:33:50 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:40548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357482AbiBNSds (ORCPT ); Mon, 14 Feb 2022 13:33:48 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47560652E9 for ; Mon, 14 Feb 2022 10:33:40 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id bu29so27165288lfb.0 for ; Mon, 14 Feb 2022 10:33:40 -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=+UXFaXNtu58P+/quLcAfHAU/S4vyiJKyaqPdTSKWST8=; b=sFWvgW3k1pSL7Awgb8qEobnrOdmxWAQzBkRi13UyvlHolBMEQeW1vZwFUQObSIyQ5+ WwxOX5EZ2YssQReVrEIaLaKMtZDW45gNyPiqD+FzwuWMiiJQKLoUgq5bk9eGeCgq7fWV Nex4LYQZ0zfuPsfJ5Do35sWOxMSXkP2F/ldXGgcURzQ7QzCfQkf3gBgtLjSTlL56o0f7 6/dWI8Ilo2YFMJgNivikdUb843ij4RWNUXAhKRBoVTLsZ49MA+kNqzBUYGk0l3fUxFtG i6XHAhuqsKFUywKLl0k0he5kFM40nP/it0yBh1AIb2ocynTZ86LQIzxv4JaSp1egrbGJ ak1Q== 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=+UXFaXNtu58P+/quLcAfHAU/S4vyiJKyaqPdTSKWST8=; b=6lSElxKHwUrOh/Oo8BCUN57WD+Vcmbjj2SMW8OAgEu3MPqZNvOj3D+Z1mMvXCutNz7 XDh48SWVBBnKTc1PY5WCeSwEemsuqH6/CSm5o6P5gsC9/EpWWShqJer0yFkX0rNi/lKL 6ckvM4FYAqSNfBZg4PLb1lgblAcW7Z6wkJ7ECd+STIOQrfoXdEQeQRbH2ttFJ+6tJ+Kc Pr7gTAOHTjt/xEOF85bb/M5mjA22dCt6dzC+S0I42U0KPCcI9ezTBQ6r3n4oXBG7gyb0 aOd/635YlKAoj+SyOGNLeaF9s/u050oXQDwCL5UQ+4QoT4begjLdSGWHiLUF0MXN/OKX 7z4g== X-Gm-Message-State: AOAM530hX1/V56RphoTG3xJDpaNnNi9bHIPlmn6b97SI5p8VjOi9lhjP zL/h+KCP9wsyGQVtHAGMMuerDxoRMXxxDhYAPObkwA== X-Received: by 2002:a05:6512:1154:: with SMTP id m20mr249590lfg.682.1644863618292; Mon, 14 Feb 2022 10:33:38 -0800 (PST) MIME-Version: 1.0 References: <20220211161831.3493782-1-tjmercier@google.com> <20220211161831.3493782-7-tjmercier@google.com> In-Reply-To: From: Todd Kjos Date: Mon, 14 Feb 2022 10:33:25 -0800 Message-ID: Subject: Re: [RFC v2 6/6] android: binder: Add a buffer flag to relinquish ownership of fds To: Greg Kroah-Hartman Cc: "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 , Suren Baghdasaryan , 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 , kaleshsingh@google.com, Kenny.Ho@amd.com, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL 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 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 array > > 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 proce= ss > > 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 ever= y > > 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 list= _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 list= _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 list= _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 char= ge to %d", > > + proc->pid, thread->pid, target_proc->pid)= ; > > + 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. 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/a= ndroid/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 i= n 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