From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E39BEC433FE for ; Tue, 15 Feb 2022 07:30:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234823AbiBOHbD (ORCPT ); Tue, 15 Feb 2022 02:31:03 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233296AbiBOHa7 (ORCPT ); Tue, 15 Feb 2022 02:30:59 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AD0610F23C; Mon, 14 Feb 2022 23:30:49 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1A1B6B817DF; Tue, 15 Feb 2022 07:30:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F634C340EC; Tue, 15 Feb 2022 07:30:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1644910246; bh=d7O0LjAMCqSVPzrmAjEUAUrhTljBtokM4lMRkzTZRn4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nI9BT8e7bH53D6xl7GN7ShLijc1GUvEbq4aQlISk6014ej3GYNqf5qP80x8gmm/C9 0guWhIB8CG6B5zuHuf00vQIZDZHrwIIKCzcTJ9SwAxgKSiayqHfUjljXOt3LauL8UI VXdXc4rXKsY/KwXxCm704rsBDZEywjRr3as+lK1g= Date: Tue, 15 Feb 2022 08:30:43 +0100 From: Greg Kroah-Hartman To: Suren Baghdasaryan Cc: "T.J. Mercier" , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Jonathan Corbet , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , 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 Subject: Re: [RFC v2 6/6] android: binder: Add a buffer flag to relinquish ownership of fds Message-ID: References: <20220211161831.3493782-1-tjmercier@google.com> <20220211161831.3493782-7-tjmercier@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 14, 2022 at 11:19:35PM -0800, Suren Baghdasaryan wrote: > On Mon, Feb 14, 2022 at 11:01 PM Greg Kroah-Hartman > wrote: > > > > On Mon, Feb 14, 2022 at 02:25:47PM -0800, T.J. Mercier wrote: > > > On Fri, Feb 11, 2022 at 11:19 PM Greg Kroah-Hartman > > > > > --- 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 = 0x01, > > > > > + BINDER_BUFFER_FLAG_SENDER_NO_NEED = 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? > > > > > > Sorry, I don't completely follow even after Todd's comment. Doesn't > > > the presence of BINDER_BUFFER_FLAG_SENDER_NO_NEED in the header do > > > this? > > > > There is no "header" when running a new kernel on an old userspace, > > right? How about the other way around, old kernel, new userspace? > > 1. new kernel + old userspace = kernel supports the feature but > userspace does not use it. The old userspace won't even mount the new > cgroup controller, accounting is not performed, charge is not > transferred. > 2. old kernel + new userspace = the new cgroup controller is not > supported by the kernel, accounting is not performed, charge is not > transferred. > 3. old kernel + old userspace = same as #2 > 4. new kernel + new userspace = cgroup is mounted, feature is > supported and used. > Does that work or do we need a separate indication of whether binder > driver supports the charge transfer feature? Ok, if that's all working, this is fine, it just seemed odd to add a new type like this. Perhaps this can go into the changelog text... thanks, greg k-h