Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp4501399ybx; Mon, 4 Nov 2019 14:27:03 -0800 (PST) X-Google-Smtp-Source: APXvYqy67r745gE0iBRBO3XFAzFd7LOqOyul4MgfM5vdY8BbWD4iaDYLDmdhK3sdTGVIJWGMA6NW X-Received: by 2002:aa7:db55:: with SMTP id n21mr23628079edt.113.1572906423345; Mon, 04 Nov 2019 14:27:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572906423; cv=none; d=google.com; s=arc-20160816; b=yWY4z1T3OfJxHTTa+uiW+8vT2OrlQMjsDu0yavKq2xzWjdo6KP3XqGLxvszgrIxvdj 5zOkzS1EZrWwmonCcx43gz5/snAzpmwmyB2dPxRnSWImca0NAcKjMHn2SlBXYY+o/AcG IR7aphLUainit6t9MBnbUTxX/g9KvFKA1cMgYoqat9/y8Fqkghp+GtrS6UkJT/0T7GUP LyMfIhfhJMVrOEGazBlatoLKogXxuh6l2NtwMJNf0+15qcJvAEzmKsRfzc5+EyhtoaQU uvkR2laalBLx6oSJA0434RIQnTt/4F3Qi3jT+kHea56sMH3J7lVjJ1GusFvdG5wLTLoM NJyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=bHzFpby5nBvLQoa1A3N45Iv5pE3sE4p/UO4W7iuituU=; b=lyYZ37G+KTTOL7rq9K/mbSxvq57MAf64oIwM5hotOUtzfPZYdU1PG0eSlPYoO4AFOB zStFqxJURKYuwHU3TS9s3G6Kxnv9au//rP/HlIoJQd0vxj76VAOek8je4wPTPyOI8+tl NvB9+4csalI1a+t2ZgUafTVNNsJbkHeAa0gsLg4r9rvZf4izwmclFO4g747zGhlGlytS iSJbSuoRCRxgLe2UerwJHeL0izaLX4NXK8U0lRwAi/5C3r/8OpnOFyT3J+0GoRlN7FJm 3cTNsNwMtNAklzVlFWoQy6jYRxaWwmMoZvAnJydZP1judapQu9rt4o57mowAiFt/y3D8 l+Mg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=Pp8aTcTc; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g40si8313440edb.369.2019.11.04.14.26.32; Mon, 04 Nov 2019 14:27:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=Pp8aTcTc; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730499AbfKDVvX (ORCPT + 99 others); Mon, 4 Nov 2019 16:51:23 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:35544 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730489AbfKDVvX (ORCPT ); Mon, 4 Nov 2019 16:51:23 -0500 Received: by mail-pf1-f194.google.com with SMTP id d13so13434676pfq.2 for ; Mon, 04 Nov 2019 13:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=bHzFpby5nBvLQoa1A3N45Iv5pE3sE4p/UO4W7iuituU=; b=Pp8aTcTc4J8HQHJfK7XYOvTKX+0OBvRsnX5l3y4u4g4MM3j86RHYT5E3CyfwGjTx4M OY4am3V6P04tfgMJdWaiBA4U4MVXNNXBLNBBKKsjLvm6Py+danTKFeA58zni2EwrZJ4a LNM/Y81H3MGNqRtK9pfeV0H03aM+7nND2Zei+zqEbD1s4PqBPprHUisrBeteBubsbwSy TVQ544cT0wpbyLgolGEW1xWW2VpX+SzNMXEAx14Fcr5iUkFTIem+fgkabRMzppRp0uwa f1TaCzq6xMl1AGXBK5nQcB2Aq9iUTjOhumPtO956o84HKT+keZUKHTeZ+X7Z6JqxV9xJ DqlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bHzFpby5nBvLQoa1A3N45Iv5pE3sE4p/UO4W7iuituU=; b=btFTM/KvAB8qEpBimqFJz50wjWdlH9Wb6LIWs9HiKfJ7faUJElgjjsbVEoRaXk6qD+ Ja89ieFM+lcbyiTT5yDrDwY35P1MPqCN+4sxT5DNjSouUhk2TOVgrVUyvNPz+Nvhs+tw CSqgcmI5Bqs6/1UkK4vTdovyDZqlKae9IvAUyDlZ8gY4Qd746dXPvOKtMgx2H2MyUSMD 0XTMGQyhRBkYvkCGC8ljPx/1nDwjzDZ0jFbrEMQKBjJX0XcAMgj6jC8xtuQecEptiNuK CzFXYqaMsmh6ByCqV1sZ2vUwUGOsQ1lIInHRzN9sfJO+P5X/n88TTsIeKdhkhBWb1/UC l27A== X-Gm-Message-State: APjAAAVysuUO21DsyLmbtUBtwyDJyuS73z8tdB5/xfYy3jZUY+nNvvDm sEamOc/A1G1nqwfoxmDc16cQ+Q== X-Received: by 2002:a63:dc45:: with SMTP id f5mr32464004pgj.250.1572904282035; Mon, 04 Nov 2019 13:51:22 -0800 (PST) Received: from nebulus.mtv.corp.google.com ([2620:15c:211:200:5404:91ba:59dc:9400]) by smtp.googlemail.com with ESMTPSA id z7sm10567610pgk.10.2019.11.04.13.51.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Nov 2019 13:51:21 -0800 (PST) Subject: Re: [PATCH v14 1/5] Add flags option to get xattr method paired to __vfs_getxattr To: Amir Goldstein , Andreas Dilger Cc: Greg Kroah-Hartman , Linux Kernel Mailing List , linux-doc@vger.kernel.org, CIFS , kernel-team@android.com, selinux@vger.kernel.org, Linux FS-devel Mailing List , Jonathan Corbet , Ext4 Developers List , Stephen Smalley , overlayfs , Andreas Gruenbacher , ecryptfs@vger.kernel.org, LSM List , Alexander Viro , Christoph Hellwig References: <20191022204453.97058-1-salyzyn@android.com> <20191022204453.97058-2-salyzyn@android.com> <8CE5B6E8-DCB7-4F0B-91C1-48030947F585@dilger.ca> From: Mark Salyzyn Message-ID: <7b5f2964-10ce-021b-01f7-6b662bf0c09a@android.com> Date: Mon, 4 Nov 2019 13:51:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 10/23/19 9:57 PM, Amir Goldstein wrote: > [excessive CC list reduced] > > On Wed, Oct 23, 2019 at 11:07 AM Andreas Dilger via samba-technical > wrote: >> >> On Oct 22, 2019, at 2:44 PM, Mark Salyzyn wrote: >>> Replace arguments for get and set xattr methods, and __vfs_getxattr >>> and __vfs_setaxtr functions with a reference to the following now >>> common argument structure: >>> >>> struct xattr_gs_args { >>> struct dentry *dentry; >>> struct inode *inode; >>> const char *name; >>> union { >>> void *buffer; >>> const void *value; >>> }; >>> size_t size; >>> int flags; >>> }; >>> Mark, >>> >>> I do not see the first patch on fsdevel >>> and I am confused from all the suggested APIs >>> I recall Christoph's comment on v8 for not using xattr_gs_args >>> and just adding flags to existing get() method. >>> I agree to that comment. >> As already responded, third (?) patch version was like that, > The problem is that because of the waaay too long CC list, most revisions > of the patch and discussion were bounced from fsdevel, most emails > I did not get and cannot find in archives, so the discussion around > them is not productive. > > Please resend patch to fsdevel discarding the auto added CC list > of all fs maintainers. git send-email is not my friend :-( >> gregkh@ >> said it passed the limit for number of arguments, is looking a bit silly > Well, you just matched get() to set() args list, so this is not a strong > argument IMO. > >> (my paraphrase), and that it should be passed as a structure. Two others >> agreed. We gained because both set and get use the same structure after >> this change (this allows a simplified read-modify-write cycle). > That sounds like a nice benefit if this was user API, but are there any > kernel users that intend to make use of that read-modify-write cycle? > I don't think so. (one user) > >> We will need a quorum on this, 3 (structure) to 2 (flag) now (but really >> basically between Greg and Christoph?). Coding style issue: Add a flag, >> or switch to a common xattr argument structure? >> > IIRC, Christoph was asking why the silly struct and not simply add flags > (as did I). He probably did not see Greg's comments due to the list bounce > issue. If I read your second hand description of Greg's reaction correctly, > it doesn't sound so strong opinionated as well. > Me, I can live with flags or struct - I don't care, but... > > Be prepared that if you are going ahead with struct you are going to > suffer from bike shedding, which has already started and you will be > instructed (just now) to also fix all the relevant and missing Documentation. > If, on the other hand, you can get Greg and the rest to concede to adding > flags arg and match get() arg list to set() arg list, you will have a much > easier job and the patch line count, especially in fs code will be *much* > smaller - just saying. Respining back to the v4 version of the series incorporating some of the fixes on the way. Automated testing in kernel not yet handled and will be noted in the respin. > Thanks, > Amir. Mark