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 787FEC001DF for ; Tue, 25 Jul 2023 16:11:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229498AbjGYQLe (ORCPT ); Tue, 25 Jul 2023 12:11:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230078AbjGYQL2 (ORCPT ); Tue, 25 Jul 2023 12:11:28 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 877A3E51 for ; Tue, 25 Jul 2023 09:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690301439; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=G/zZPwexsp4seUyrA2hhadzoNaw+twMBRSn/pl5a3MA=; b=JM6L3/vKtayxm0VjmB4nuFSLmMmsUCU7X8fvcWDZs6vI3h6lc3oPkuRz7KBCWMuJ4hUs0U n8pRn6Ew86Prd84b8SJrrl7rK6yGPIHjX/Hny09Gslel819n0nCMriNF7M5Jz0jeQGCKgX i79LpHe4WN2Tr9vJrRVA8oZmw/YUGNs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-643-m3013xXfOhOnk-HZgCSlEQ-1; Tue, 25 Jul 2023 12:10:36 -0400 X-MC-Unique: m3013xXfOhOnk-HZgCSlEQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 828B8104458F; Tue, 25 Jul 2023 16:10:34 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.194.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 87CF610E5E; Tue, 25 Jul 2023 16:10:23 +0000 (UTC) From: Florian Weimer To: David Howells Cc: Alexey Gladkov , James.Bottomley@HansenPartnership.com, acme@kernel.org, alexander.shishkin@linux.intel.com, axboe@kernel.dk, benh@kernel.crashing.org, borntraeger@de.ibm.com, bp@alien8.de, catalin.marinas@arm.com, christian@brauner.io, dalias@libc.org, davem@davemloft.net, deepa.kernel@gmail.com, deller@gmx.de, fenghua.yu@intel.com, geert@linux-m68k.org, glebfm@altlinux.org, gor@linux.ibm.com, hare@suse.com, hpa@zytor.com, ink@jurassic.park.msu.ru, jhogan@kernel.org, kim.phillips@arm.com, ldv@altlinux.org, linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux@armlinux.org.uk, linuxppc-dev@lists.ozlabs.org, luto@kernel.org, mattst88@gmail.com, mingo@redhat.com, monstr@monstr.eu, mpe@ellerman.id.au, namhyung@kernel.org, paulus@samba.org, peterz@infradead.org, ralf@linux-mips.org, sparclinux@vger.kernel.org, stefan@agner.ch, tglx@linutronix.de, tony.luck@intel.com, tycho@tycho.ws, will@kernel.org, x86@kernel.org, ysato@users.sourceforge.jp, LKML , Arnd Bergmann , linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk Subject: Re: Add fchmodat2() - or add a more general syscall? References: <104971.1690300714@warthog.procyon.org.uk> Date: Tue, 25 Jul 2023 18:10:22 +0200 In-Reply-To: <104971.1690300714@warthog.procyon.org.uk> (David Howells's message of "Tue, 25 Jul 2023 16:58:34 +0100") Message-ID: <87fs5c3rbl.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org * David Howells: > Rather than adding a fchmodat2() syscall, should we add a "set_file_attrs()" > syscall that takes a mask and allows you to set a bunch of stuff all in one > go? Basically, an interface to notify_change() in the kernel that would allow > several stats to be set atomically. This might be of particular interest to > network filesystems. Do you mean atomically as in compare-and-swap (update only if old values match), or just a way to update multiple file attributes with a single system call? Thanks, Florian