[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230726-arztbesuch-division-ee0343632e3c@brauner>
Date: Wed, 26 Jul 2023 15:30:51 +0200
From: Christian Brauner <brauner@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Florian Weimer <fweimer@...hat.com>,
Alexey Gladkov <legion@...nel.org>,
James.Bottomley@...senPartnership.com, acme@...nel.org,
alexander.shishkin@...ux.intel.com, axboe@...nel.dk,
benh@...nel.crashing.org, borntraeger@...ibm.com, bp@...en8.de,
catalin.marinas@....com, christian@...uner.io, dalias@...c.org,
davem@...emloft.net, deepa.kernel@...il.com, deller@....de,
fenghua.yu@...el.com, geert@...ux-m68k.org, glebfm@...linux.org,
gor@...ux.ibm.com, hare@...e.com, hpa@...or.com,
ink@...assic.park.msu.ru, jhogan@...nel.org, kim.phillips@....com,
ldv@...linux.org, linux-alpha@...r.kernel.org,
linux-arch@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org,
linux-parisc@...r.kernel.org, linux-s390@...r.kernel.org,
linux-sh@...r.kernel.org, linux@...linux.org.uk,
linuxppc-dev@...ts.ozlabs.org, luto@...nel.org, mattst88@...il.com,
mingo@...hat.com, monstr@...str.eu, mpe@...erman.id.au,
namhyung@...nel.org, paulus@...ba.org, peterz@...radead.org,
ralf@...ux-mips.org, sparclinux@...r.kernel.org, stefan@...er.ch,
tglx@...utronix.de, tony.luck@...el.com, tycho@...ho.ws,
will@...nel.org, x86@...nel.org, ysato@...rs.sourceforge.jp,
LKML <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>, linux-api@...r.kernel.org,
linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: Add fchmodat2() - or add a more general syscall?
On Tue, Jul 25, 2023 at 07:39:51PM +0100, David Howells wrote:
> Florian Weimer <fweimer@...hat.com> wrote:
>
> > > 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
That system call would likely be blocked in seccomp sandboxes completely
as seccomp cannot filter structs. I don't consider this an argument to
block new good functionality in general as that would mean arbitrarily
limiting us but it is something to keep in mind. If there's additional
benefit other than just being able to set mutliple values at once then
yeah might be something to discuss.
> > > 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?
>
> I was thinking more in terms of the latter. AFAIK, there aren't any network
> filesystems support a CAS interface on file attributes like that. To be able
> to do a CAS operation, we'd need to pass in the old values as well as the new.
>
> Another thing we could look at is doing "create_and_set_attrs()", possibly
> allowing it to take a list of xattrs also.
That would likely require variable sized pointers in a struct which is
something we really try to stay away from. I also think it's not a good
idea to lump xattrs toegether with generic file attributes. They should
remain a separate api imho.
Powered by blists - more mailing lists