Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

2023-09-29 Thread Christian Brauner
> It is a lot of churn though. I think that i_{a,c,m}time shouldn't be accessed directly by filesystems same as no filesystem should really access i_{g,u}id which we also provide i_{g,u}id_{read,write}() accessors for. The mode is another example where really most often should use helpers because

Re: [PATCH 87/87] fs: move i_blocks up a few places in struct inode

2023-09-29 Thread Christian Brauner
On Thu, Sep 28, 2023 at 10:41:34AM -0700, Linus Torvalds wrote: > On Thu, 28 Sept 2023 at 04:06, Jeff Layton wrote: > > > > Move i_blocks up above the i_lock, which moves the new 4 byte hole to > > just after the timestamps, without changing the size of the structure. > > I'm sure others have

Re: [PATCH v2 00/89] fs: new accessor methods for inode atime and mtime

2023-10-09 Thread Christian Brauner
On Wed, Oct 04, 2023 at 02:52:21PM -0400, Jeff Layton wrote: > v2: > - bugfix in mtime handling > - incorporate _sec and _nsec accessor functions (Chuck Lever) > - move i_generation to plug hole after changing timestamps (Amir Goldstein) > > While working on the multigrain timestamp changes,

Re: [RFC PATCH v2 2/3] fs: define a firmware security filesystem named fwsecurityfs

2022-06-28 Thread Christian Brauner
On Mon, Jun 27, 2022 at 09:37:28AM +0200, Greg Kroah-Hartman wrote: > On Sun, Jun 26, 2022 at 11:48:06AM -0400, Mimi Zohar wrote: > > On Thu, 2022-06-23 at 09:23 -0400, James Bottomley wrote: > > > On Thu, 2022-06-23 at 10:54 +0200, Greg Kroah-Hartman wrote: > > > [...] > > > > > diff --git

Re: [RFC PATCH 2/2] fs/xattr: wire up syscalls

2022-08-30 Thread Christian Brauner
On Tue, Aug 30, 2022 at 05:28:38PM +0200, Christian Göttsche wrote: > Enable the new added extended attribute related syscalls. > > Signed-off-by: Christian Göttsche > --- Fwiw, I think a while ago it was pointed out that for most syscall additions you can just fold the hookup patch in. It

Re: [PATCH v2 00/89] fs: new accessors for inode->i_ctime

2023-07-10 Thread Christian Brauner
On Fri, Jul 07, 2023 at 08:42:31AM -0400, Jeff Layton wrote: > On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote: > > v2: > > - prepend patches to add missing ctime updates > > - add simple_rename_timestamp helper function > > - rename ctime accessor functions as

Re: [PATCH v2 00/92] fs: new accessors for inode->i_ctime

2023-07-10 Thread Christian Brauner
On Wed, 05 Jul 2023 14:58:09 -0400, Jeff Layton wrote: > v2: > - prepend patches to add missing ctime updates > - add simple_rename_timestamp helper function > - rename ctime accessor functions as inode_get_ctime/inode_set_ctime_* > - drop individual inode_ctime_set_{sec,nsec} helpers > > I've

[PATCH 1/2] eventfd: simplify eventfd_signal()

2023-07-13 Thread Christian Brauner
Ever since the evenfd type was introduced back in 2007 in commit e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal() function only ever passed 1 as a value for @n. There's no point in keeping that additional argument. Signed-off-by: Christian Brauner --- arch/x86/kv

[PATCH 2/2] eventfd: simplify eventfd_signal_mask()

2023-07-13 Thread Christian Brauner
The eventfd_signal_mask() helper was introduced for io_uring and similar to eventfd_signal() it always passed 1 for @n. So don't bother with that argument at all. Signed-off-by: Christian Brauner --- drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- fs/eventfd.c | 9

[PATCH 0/2] eventfd: simplify signal helpers

2023-07-13 Thread Christian Brauner
Hey everyone, This simplifies the eventfd_signal() and eventfd_signal_mask() helpers by removing the count argument which is effectively unused. --- --- base-commit: 6be357f00aad4189130147fdc6f568cf776a4909 change-id: 20230713-vfs-eventfd-signal-0b0d167ad6ec

Re: [PATCH 2/2] eventfd: simplify eventfd_signal_mask()

2023-07-13 Thread Christian Brauner
On Thu, Jul 13, 2023 at 07:33:05AM -0700, Sean Christopherson wrote: > On Thu, Jul 13, 2023, Christian Brauner wrote: > > diff --git a/fs/eventfd.c b/fs/eventfd.c > > index dc9e01053235..077be5da72bd 100644 > > --- a/fs/eventfd.c > > +++ b/fs/eventfd.c > > @@ -

Re: [PATCH v3 2/5] fs: Add fchmodat4()

2023-07-11 Thread Christian Brauner
On Tue, Jul 11, 2023 at 01:42:19PM +0200, Arnd Bergmann wrote: > On Tue, Jul 11, 2023, at 13:25, Alexey Gladkov wrote: > > From: Palmer Dabbelt > > > > On the userspace side fchmodat(3) is implemented as a wrapper > > function which implements the POSIX-specified interface. This > > interface

Re: [PATCH v4 2/5] fs: Add fchmodat2()

2023-07-11 Thread Christian Brauner
On Tue, Jul 11, 2023 at 06:16:04PM +0200, Alexey Gladkov wrote: > On the userspace side fchmodat(3) is implemented as a wrapper > function which implements the POSIX-specified interface. This > interface differs from the underlying kernel system call, which does not > have a flags argument. Most

Re: (subset) [PATCH v4 0/5] Add a new fchmodat2() syscall

2023-07-11 Thread Christian Brauner
On Tue, 11 Jul 2023 18:16:02 +0200, Alexey Gladkov wrote: > In glibc, the fchmodat(3) function has a flags argument according to the > POSIX specification [1], but kernel syscalls has no such argument. > Therefore, libc implementations do workarounds using /proc. However, > this requires procfs to

Re: [PATCH v3 0/5] Add a new fchmodat4() syscall

2023-07-11 Thread Christian Brauner
On Tue, Jul 11, 2023 at 02:24:51PM +0200, Florian Weimer wrote: > * Alexey Gladkov: > > > This patch set adds fchmodat4(), a new syscall. The actual > > implementation is super simple: essentially it's just the same as > > fchmodat(), but LOOKUP_FOLLOW is conditionally set based on the flags. > >

Re: [PATCH v3 2/5] fs: Add fchmodat4()

2023-07-11 Thread Christian Brauner
On Tue, Jul 11, 2023 at 02:51:01PM +0200, Alexey Gladkov wrote: > On Tue, Jul 11, 2023 at 01:52:01PM +0200, Christian Brauner wrote: > > On Tue, Jul 11, 2023 at 01:42:19PM +0200, Arnd Bergmann wrote: > > > On Tue, Jul 11, 2023, at 13:25, Alexey Gladkov wrote: > >

Re: [PATCH 0/2] eventfd: simplify signal helpers

2023-07-14 Thread Christian Brauner
On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote: > On Thu, 13 Jul 2023 12:05:36 +0200 > Christian Brauner wrote: > > > Hey everyone, > > > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers > > by removing the count arg

Re: Add fchmodat2() - or add a more general syscall?

2023-07-26 Thread Christian Brauner
On Tue, Jul 25, 2023 at 07:39:51PM +0100, David Howells wrote: > Florian Weimer 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

Re: [PATCH v4 2/5] fs: Add fchmodat2()

2023-07-27 Thread Christian Brauner
> > I think it'd be much neater to do the conversion of AT_ flags here and > > pass 0 as a flags argument for all of the wrappers (this is how most of > > the other xyz(), fxyz(), fxyzat() syscall wrappers are done IIRC). I've fixed that up in-tree.

Re: [PATCH v4 3/5] arch: Register fchmodat2, usually as syscall 452

2023-07-27 Thread Christian Brauner
On Wed, Jul 26, 2023 at 02:43:41AM +1000, Aleksa Sarai wrote: > On 2023-07-11, Alexey Gladkov wrote: > > From: Palmer Dabbelt > > > > This registers the new fchmodat2 syscall in most places as nuber 452, > > with alpha being the exception where it's 562. I found all these sites > > by grepping

Re: Add fchmodat2() - or add a more general syscall?

2023-07-27 Thread Christian Brauner
On Wed, Jul 26, 2023 at 08:57:10PM -0700, Eric Biggers wrote: > On Tue, Jul 25, 2023 at 04:58:34PM +0100, David Howells 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?

Re: [PATCH v4 2/5] fs: Add fchmodat2()

2023-07-27 Thread Christian Brauner
On Thu, Jul 27, 2023 at 06:28:53PM +0200, Andreas Schwab wrote: > On Jul 27 2023, David Laight wrote: > > > From: Aleksa Sarai > >> Sent: 25 July 2023 17:36 > > ... > >> We almost certainly want to support AT_EMPTY_PATH at the same time. > >> Otherwise userspace will still need to go through

Re: [PATCH v4 2/5] fs: Add fchmodat2()

2023-07-27 Thread Christian Brauner
On Thu, Jul 27, 2023 at 01:13:37PM -0400, dal...@libc.org wrote: > On Thu, Jul 27, 2023 at 07:02:53PM +0200, Christian Brauner wrote: > > On Thu, Jul 27, 2023 at 06:28:53PM +0200, Andreas Schwab wrote: > > > On Jul 27 2023, David Laight wrote: > > > > > > &g

Re: [PATCH v3 0/5] Add a new fchmodat4() syscall

2023-07-25 Thread Christian Brauner
On Tue, Jul 25, 2023 at 01:05:40PM +0200, Alexey Gladkov wrote: > On Tue, Jul 11, 2023 at 05:14:24PM +0200, Christian Brauner wrote: > > On Tue, Jul 11, 2023 at 02:24:51PM +0200, Florian Weimer wrote: > > > * Alexey Gladkov: > > > > > > > This patch set adds

Re: [PATCH 00/79] fs: new accessors for inode->i_ctime

2023-06-23 Thread Christian Brauner
On Wed, Jun 21, 2023 at 03:52:27PM -0400, Jeff Layton wrote: > On Wed, 2023-06-21 at 15:21 -0400, Steven Rostedt wrote: > > On Wed, 21 Jun 2023 10:45:05 -0400 > > Jeff Layton wrote: > > > > > Most of this conversion was done via coccinelle, with a few of the more > > > non-standard accesses done

Re: [RFC PATCH v2] fs/xattr: add *at family syscalls

2023-05-15 Thread Christian Brauner
On Thu, May 11, 2023 at 05:08:02PM +0200, Christian Göttsche wrote: > Add the four syscalls setxattrat(), getxattrat(), listxattrat() and > removexattrat(). Those can be used to operate on extended attributes, > especially security related ones, either relative to a pinned directory > or on a

Re: [RFC PATCH v2] fs/xattr: add *at family syscalls

2023-05-15 Thread Christian Brauner
On Mon, May 15, 2023 at 04:04:21PM +0300, Amir Goldstein wrote: > On Mon, May 15, 2023 at 1:33 PM Christian Brauner wrote: > > > > On Thu, May 11, 2023 at 05:08:02PM +0200, Christian Göttsche wrote: > > > Add the four syscalls setxattrat(), getxattrat(), listxattrat()

Re: [PATCH] procfs: consolidate arch_report_meminfo declaration

2023-05-17 Thread Christian Brauner
On Tue, 16 May 2023 21:57:29 +0200, Arnd Bergmann wrote: > The arch_report_meminfo() function is provided by four architectures, > with a __weak fallback in procfs itself. On architectures that don't > have a custom version, the __weak version causes a warning because > of the missing prototype. >

Re: [PATCH v2 2/4] eventfd: simplify eventfd_signal()

2024-02-08 Thread Christian Brauner
On Wed, Feb 07, 2024 at 03:34:59PM +0100, Paolo Bonzini wrote: > On Wed, Nov 22, 2023 at 1:49 PM Christian Brauner wrote: > > > > Ever since the evenfd type was introduced back in 2007 in commit > > e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_

Re: [linus:master] [file] 0ede61d858: will-it-scale.per_thread_ops -2.9% regression

2023-11-28 Thread Christian Brauner
On Mon, Nov 27, 2023 at 09:10:54AM -0800, Linus Torvalds wrote: > On Mon, 27 Nov 2023 at 02:27, Christian Brauner wrote: > > > > So I've picked up your patch (vfs.misc). It's clever alright so thanks > > for the comments in there otherwise I would've stared at this for far &g

Re: [PATCH v2 0/4] eventfd: simplify signal helpers

2023-11-24 Thread Christian Brauner
On Wed, 22 Nov 2023 13:48:21 +0100, Christian Brauner wrote: > Hey everyone, > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers > significantly. They can be made void and not take any unnecessary > arguments. > > I've added a few more simplifica

Re: [PATCH v2 2/4] eventfd: simplify eventfd_signal()

2023-11-23 Thread Christian Brauner
> > * eventfd_signal - Adds @n to the eventfd counter. > > This still refers to @n here, and in patch 4. Fixed and folded. Thanks!

Re: [PATCH v2 1/4] i915: make inject_virtual_interrupt() void

2023-11-23 Thread Christian Brauner
> > + if (!vgpu->msi_trigger) > > + return; > > + eventfd_signal(vgpu->msi_trigger, 1); > > } > > I think it's a little simpler to write as > if (vgpu->msi_trigger) > eventfd_signal(vgpu->msi_trigger, 1); Good point. I folded that suggestion into the patch.

[PATCH v2 2/4] eventfd: simplify eventfd_signal()

2023-11-22 Thread Christian Brauner
Ever since the evenfd type was introduced back in 2007 in commit e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal() function only ever passed 1 as a value for @n. There's no point in keeping that additional argument. Signed-off-by: Christian Brauner --- arch/x86/kv

[PATCH v2 3/4] eventfd: simplify eventfd_signal_mask()

2023-11-22 Thread Christian Brauner
The eventfd_signal_mask() helper was introduced for io_uring and similar to eventfd_signal() it always passed 1 for @n. So don't bother with that argument at all. Signed-off-by: Christian Brauner --- fs/eventfd.c| 7 --- include/linux/eventfd.h | 5 ++--- io_uring/io_uring.c

Re: [linus:master] [file] 0ede61d858: will-it-scale.per_thread_ops -2.9% regression

2023-11-27 Thread Christian Brauner
> I took a look at the code generation, and honestly, I think we're > better off just making __fget_files_rcu() have special logic for this > all, and not use __get_file_rcu(). My initial massaging of the patch did that btw. Then I sat there wondering whether it would matter if we just made it

Re: [linus:master] [file] 0ede61d858: will-it-scale.per_thread_ops -2.9% regression

2023-11-27 Thread Christian Brauner
> So that nobody else would waste any time on this, attached is a new > attempt. This time actually tested *after* the changes. So I've picked up your patch (vfs.misc). It's clever alright so thanks for the comments in there otherwise I would've stared at this for far too long. It's a little

[PATCH v2 4/4] eventfd: make eventfd_signal{_mask}() void

2023-11-22 Thread Christian Brauner
No caller care about the return value. Signed-off-by: Christian Brauner --- fs/eventfd.c| 40 +++- include/linux/eventfd.h | 16 +++- 2 files changed, 22 insertions(+), 34 deletions(-) diff --git a/fs/eventfd.c b/fs/eventfd.c index

[PATCH v2 1/4] i915: make inject_virtual_interrupt() void

2023-11-22 Thread Christian Brauner
The single caller of inject_virtual_interrupt() ignores the return value anyway. This allows us to simplify eventfd_signal() in follow-up patches. Signed-off-by: Christian Brauner --- drivers/gpu/drm/i915/gvt/interrupt.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff

[PATCH v2 0/4] eventfd: simplify signal helpers

2023-11-22 Thread Christian Brauner
Hey everyone, This simplifies the eventfd_signal() and eventfd_signal_mask() helpers significantly. They can be made void and not take any unnecessary arguments. I've added a few more simplifications based on Sean's suggestion. Signed-off-by: Christian Brauner Changes in v2: - further

<    1   2