Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp492524pxb; Thu, 20 Jan 2022 18:18:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJynXcUeB3tcxOqtHHVvV921Exn7hn0BmD4guLK7y5TIpLBfyNUTedSO0V6dXCAfAYevKGiK X-Received: by 2002:a17:90a:cb8b:: with SMTP id a11mr2284398pju.75.1642731496356; Thu, 20 Jan 2022 18:18:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642731496; cv=none; d=google.com; s=arc-20160816; b=G6/jQ/gKjU9ZuXj/oE6PUynPHILjNYQHsuZUMppmaS+dlISmjZokRHTlxiQB7FHOlA QgrfdOvtqB9Zc7BeWfFiR1SDS+P0+szXsZCOF5rMKEGndMtYWbJFX47+qFxUCQRTKlvd rZND1igEYCgL7282gbYDPWGdV3N78iXIjNZDJ4SJKqgKs/UMdN7a5lMZG+8Tvlw/gHrQ HERbYGtNYdcmxKPjz+KOfl7t9PYbup/U9jsNsn7Pd5yCVxfS5sWPNXPffVeY5ab8S8p6 aCXBDnuEWu90Rqk/dA0meZGOg/pijJ0SlEhapjpPMppHYUT2Zia8x7MIJE1VRCVU9KeJ uzKA== 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=QuweckTQS4ipVDvmzbXJd32fRhDvTN+WDj7gwwJ5UoU=; b=emi21zTy1w+n3RQVaDGPpAQA94I0yM9+hJVPenPo4dBM4jB02ds3FeFd2sFKLGcCMS MplZf0DAU6MqQo232r5waagwm7xNK5aAr3vFbm0hTL6BW18Y5ps5VvR7ArQUWQBUx4Pu jVGvieImJiefW0DheVaZPXFPYNWgJbOpeRQXW1DyjTc+wKkXuf6W9ledCUGYuD2A7Rle qGyb6ecU/oIL2Z3eUqbmjHVyrlnlOttQD8RrabELZpVpnGdtVKU1rvs7/oXsxML+oD5b +HXrCBfAmKalBRV43RRStu1e3eCuNcYLkVT5IOgEtNZB8Tp7GtZHDXEBs/rqimqyNUF7 YvQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jQFQQg8x; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n37si5757926pgl.324.2022.01.20.18.18.04; Thu, 20 Jan 2022 18:18:16 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20210112 header.b=jQFQQg8x; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245026AbiARSyz (ORCPT + 99 others); Tue, 18 Jan 2022 13:54:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348444AbiARSyx (ORCPT ); Tue, 18 Jan 2022 13:54:53 -0500 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F2EAC061574 for ; Tue, 18 Jan 2022 10:54:52 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id g81so58899557ybg.10 for ; Tue, 18 Jan 2022 10:54:52 -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=QuweckTQS4ipVDvmzbXJd32fRhDvTN+WDj7gwwJ5UoU=; b=jQFQQg8xNBNZ796rZm7JSGtcgk/RVRlUMQOrW3OprZAwIy/2ezKxTUPzerHa5MEWoA +kfQjBOqWihjoI8v514cV21UvUHS5JntgpKuZ/16liMkZGbbSOZYF4w1r6JCuqamghHv vowP4DYmSxtE//fgZqRAITszSqg91cqu9Gg64FsXe9W1savFkk2plmXtLm5fBBA0jF0b oImfjSzLxxePgVhSUZSsFU9ZJ84ZiyGtkbd0T7VyhnxMEoyDyxlSw/pOQe3BAymEfuQ2 L/UK5sx9cvQq7XnTqbleIw48nFYsStzQLbt2Y29R65fkhq5UTeKah55mvbCMv7n+zmyV rtAA== 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=QuweckTQS4ipVDvmzbXJd32fRhDvTN+WDj7gwwJ5UoU=; b=gjPLNCAzdKW2qGd+FZvB9Lqwwbd0Y+4HEspZ3YyksRMl7wqgr07FJaRGeNT9GuqbIY J/SP9MDqfCWNRCbBCVP7YXg6dHpzL3KrKqFyBtZrmAZe8hmhaPRfTSsE+8/pU1QW0hK/ HmaQT1clBVBBxST2lbhZCO0LVDLzeE58c93p6DcU0q7+l8Eys+O4rW1uvlgbrdMcz0pt 36ir7X0QPzEiOXTXueQbmbjOc7CLDMENByYr6y9Ci4bqalFGbEI65VF0gYKHF5zTzSzC f/9tsvT5jkuRasW3v8Il3l4Eeli8ldGWAeOlcU+QFxLPTm3yHQnt6jU1ygbmE3mZMA08 CVog== X-Gm-Message-State: AOAM532ou9JXwXH5jiWhPz+Xxqy7dnFYH0EXJR6POCF9HRiwwHBM+uqH T+C8wQIUFq3Z5MORbeX+9T/Jt8Uy/wqlHFwXWUkC7Q== X-Received: by 2002:a25:388a:: with SMTP id f132mr35653202yba.102.1642532092017; Tue, 18 Jan 2022 10:54:52 -0800 (PST) MIME-Version: 1.0 References: <20220115010622.3185921-1-hridya@google.com> <20220115010622.3185921-5-hridya@google.com> In-Reply-To: From: Hridya Valsaraju Date: Tue, 18 Jan 2022 10:54:16 -0800 Message-ID: Subject: Re: [RFC 4/6] dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup. To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Jonathan Corbet , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Suren Baghdasaryan , Sumit Semwal , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , John Stultz , Tejun Heo , Zefan Li , Johannes Weiner , Dave Airlie , Jason Ekstrand , Matthew Auld , Matthew Brost , Li Li , Marco Ballesio , Miguel Ojeda , Hang Lu , Wedson Almeida Filho , Masahiro Yamada , Andrew Morton , Nathan Chancellor , Kees Cook , Nick Desaulniers , Chris Down , Vipin Sharma , Daniel Borkmann , Vlastimil Babka , Arnd Bergmann , 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, Kenny.Ho@amd.com, daniels@collabora.com, kaleshsingh@google.com, tjmercier@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 16, 2022 at 11:46 PM Christian K=C3=B6nig wrote: > > Am 15.01.22 um 02:06 schrieb Hridya Valsaraju: > > The optional exporter op provides a way for processes to transfer > > charge of a buffer to a different process. This is essential for the > > cases where a central allocator process does allocations for various > > subsystems, hands over the fd to the client who > > requested the memory and drops all references to the allocated memory. > > > > Signed-off-by: Hridya Valsaraju > > --- > > include/linux/dma-buf.h | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > > index 7ab50076e7a6..d5e52f81cc6f 100644 > > --- a/include/linux/dma-buf.h > > +++ b/include/linux/dma-buf.h > > @@ -13,6 +13,7 @@ > > #ifndef __DMA_BUF_H__ > > #define __DMA_BUF_H__ > > > > +#include > > #include > > #include > > #include > > @@ -285,6 +286,23 @@ struct dma_buf_ops { > > > > int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map); > > void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map); > > + > > + /** > > + * @charge_to_cgroup: > > + * > > + * This is called by an exporter to charge a buffer to the specif= ied > > + * cgroup. > > Well that sentence makes absolutely no sense at all. > > The dma_buf_ops are supposed to be called by the DMA-buf subsystem on > behalves of the importer and never by the exporter itself. > > I hope that this is just a documentation mixup. Thank you for taking a look Christian! Yes, that was poor wording, sorry about that. It should instead say that the op would be called by the process the buffer is currently charged to in order to transfer the buffer's charge to a different cgroup. This is helpful in the case where a process acts as an allocator for multiple client processes and we would like the allocated buffers to be charged to the clients who requested their allocation(instead of the allocating process as is the default behavior). In Android, the graphics allocator HAL process[1] does most of the graphics allocations on behalf of various clients. After allocation, the HAL process passes the fd to the client over binder IPC and the binder driver invokes the charge_to_cgroup() DMA-BUF op to uncharge the buffer from the HAL process and charge it to the client process instead. [1]: https://source.android.com/devices/graphics/arch-bq-gralloc Regards, Hridya > > Regards, > Christian. > > > The caller must hold a reference to @gpucg obtained via > > + * gpucg_get(). The DMA-BUF will be uncharged from the cgroup it = is > > + * currently charged to before being charged to @gpucg. The calle= r must > > + * belong to the cgroup the buffer is currently charged to. > > + * > > + * This callback is optional. > > + * > > + * Returns: > > + * > > + * 0 on success or negative error code on failure. > > + */ > > + int (*charge_to_cgroup)(struct dma_buf *dmabuf, struct gpucg *gpu= cg); > > }; > > > > /** >