Hi all,
I tried using wake_up_var() today and accidentally noticed that it
didn't imply an smp_mb() and specifically requires it through
wake_up_bit() / waitqueue_active().
Now, wake_up_bit() doesn't imply the barrier because it is assumed to be
used with the atomic bitops API which either implie
Peter Zijlstra wrote:
> I tried using wake_up_var() today and accidentally noticed that it
> didn't imply an smp_mb() and specifically requires it through
> wake_up_bit() / waitqueue_active().
Thinking about it again, I'm not sure why you need to add the barrier when
wake_up() (which this is a w
(sorry for cross-posting to moderated lists btw, I've since
acquired a patch to get_maintainers.pl that wil exclude them
in the future)
On Tue, Jun 25, 2019 at 08:51:01AM +0100, David Howells wrote:
> Peter Zijlstra wrote:
>
> > I tried using wake_up_var() today and accidentally noticed that
Peter,
thanks for the fixes.
On Mon, 24 Jun 2019 at 18:53, Peter Zijlstra wrote:
> Hi all,
>
> I tried using wake_up_var() today and accidentally noticed that it
> didn't imply an smp_mb() and specifically requires it through
> wake_up_bit() / waitqueue_active().
>
> Now, wake_up_bit() doesn't i
On Mon, Jun 24, 2019 at 08:22:43PM +0200, Andreas Gruenbacher wrote:
> That would work, but I don't like how this leaves us with a vfs function
> that updates i_size without bothering to dirty the inode very much.
This isn't a VFS function, it is a helper library.
>
> How about if we move the __
On Tue, Jun 25, 2019 at 11:19:35AM +0200, Andreas Gruenbacher wrote:
> > diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
> > index cf4c767005b1..29ea5da7 100644
> > --- a/fs/gfs2/glops.c
> > +++ b/fs/gfs2/glops.c
> > @@ -227,6 +227,7 @@ static void gfs2_clear_glop_pending(struct gfs2_inode
> >
> That seems way more complicated. I'd much rather go with something
> like may patch plus maybe a big fat comment explaining that persisting
> the size update is the file systems job. Note that a lot of the modern
> file systems don't use the VFS inode tracking for that, besides XFS
> that inclu
On Fri, Jun 21, 2019 at 04:56:21PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Create a generic checking function for the incoming FS_IOC_SETFLAGS flag
> values so that we can standardize the implementations that follow ext4's
> flag values.
>
> Signed-off-by: Darrick J. Wong
> Re
On Fri, Jun 21, 2019 at 04:56:29PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Create a generic checking function for the incoming FS_IOC_FSSETXATTR
> fsxattr values so that we can standardize some of the implementation
> behaviors.
>
> Signed-off-by: Darrick J. Wong
> Reviewed-by
On Fri, Jun 21, 2019 at 04:56:37PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Standardize the project id checks for FSSETXATTR.
>
> Signed-off-by: Darrick J. Wong
> Reviewed-by: Jan Kara
Looks good,
Reviewed-by: Christoph Hellwig
On Fri, Jun 21, 2019 at 04:56:45PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Move the extent size hint checks that aren't xfs-specific to the vfs.
>
> Signed-off-by: Darrick J. Wong
> Reviewed-by: Jan Kara
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, 25 Jun 2019 at 12:36, Peter Zijlstra wrote:
> On Tue, Jun 25, 2019 at 11:19:35AM +0200, Andreas Gruenbacher wrote:
> > > diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
> > > index cf4c767005b1..29ea5da7 100644
> > > --- a/fs/gfs2/glops.c
> > > +++ b/fs/gfs2/glops.c
> > > @@ -227,6 +227
On Tue, Jun 25, 2019 at 02:12:22PM +0200, Andreas Gruenbacher wrote:
> > Only if we do as David suggested and make clean_and_wake_up_bit()
> > provide the RELEASE barrier.
>
> (It's clear_and_wake_up_bit, not clean_and_wake_up_bit.)
Yes, typing hard.
> > That is, currently clear_and_wake_up_bit
On Tue, 25 Jun 2019 at 11:57, Christoph Hellwig wrote:
> On Mon, Jun 24, 2019 at 08:22:43PM +0200, Andreas Gruenbacher wrote:
> > That would work, but I don't like how this leaves us with a vfs function
> > that updates i_size without bothering to dirty the inode very much.
>
> This isn't a VFS fu
On Tue, Jun 25, 2019 at 03:57:25AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 21, 2019 at 04:56:29PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > Create a generic checking function for the incoming FS_IOC_FSSETXATTR
> > fsxattr values so that we can standardize some of the i
On Fri, Jun 21, 2019 at 04:56:21PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Create a generic checking function for the incoming FS_IOC_SETFLAGS flag
> values so that we can standardize the implementations that follow ext4's
> flag values.
I checked a few samples what's the type
On Tue, Jun 25, 2019 at 07:02:48PM +0200, David Sterba wrote:
> On Tue, Jun 25, 2019 at 03:57:25AM -0700, Christoph Hellwig wrote:
> > On Fri, Jun 21, 2019 at 04:56:29PM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong
> > >
> > > Create a generic checking function for the incoming FS_IO
On Tue, Jun 25, 2019 at 10:16:16AM -0700, Darrick J. Wong wrote:
> On Tue, Jun 25, 2019 at 07:02:48PM +0200, David Sterba wrote:
> > On Tue, Jun 25, 2019 at 03:57:25AM -0700, Christoph Hellwig wrote:
> > > On Fri, Jun 21, 2019 at 04:56:29PM -0700, Darrick J. Wong wrote:
> > > > From: Darrick J. Won
On Tue, Jun 25, 2019 at 07:12:54PM +0200, David Sterba wrote:
> On Fri, Jun 21, 2019 at 04:56:21PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > Create a generic checking function for the incoming FS_IOC_SETFLAGS flag
> > values so that we can standardize the implementations tha
On Tue, 25 Jun 2019 at 12:50, Christoph Hellwig wrote:
>
> > That seems way more complicated. I'd much rather go with something
> > like may patch plus maybe a big fat comment explaining that persisting
> > the size update is the file systems job. Note that a lot of the modern
> > file systems d
From: Darrick J. Wong
Standardize the project id checks for FSSETXATTR.
Signed-off-by: Darrick J. Wong
Reviewed-by: Jan Kara
---
fs/ext4/ioctl.c| 27 ---
fs/f2fs/file.c | 27 ---
fs/inode.c | 13 +
fs/xfs/xfs_io
Hi all,
The FS_IOC_SETFLAGS and FS_IOC_FSSETXATTR ioctls were promoted from ext4
and XFS, respectively, into the VFS. However, we didn't promote any of
the parameter checking code from those filesystems, which lead to a mess
where each filesystem open-codes whatever parameter checks they want and
From: Darrick J. Wong
Create a generic function to check incoming FS_IOC_SETFLAGS flag values
and later prepare the inode for updates so that we can standardize the
implementations that follow ext4's flag values.
Signed-off-by: Darrick J. Wong
Reviewed-by: Jan Kara
Reviewed-by: Christoph Hellw
From: Darrick J. Wong
Create a generic checking function for the incoming FS_IOC_FSSETXATTR
fsxattr values so that we can standardize some of the implementation
behaviors.
Signed-off-by: Darrick J. Wong
Reviewed-by: Jan Kara
---
fs/btrfs/ioctl.c | 18 ++---
fs/ext4/ioctl.c|
From: Darrick J. Wong
Move the extent size hint checks that aren't xfs-specific to the vfs.
Signed-off-by: Darrick J. Wong
Reviewed-by: Jan Kara
---
fs/inode.c | 18 +
fs/xfs/xfs_ioctl.c | 70 ++--
2 files changed, 47 ins
From: Darrick J. Wong
The DAX flag only applies to files and directories, so don't let it get
set for other types of files.
Signed-off-by: Darrick J. Wong
---
fs/inode.c |8
1 file changed, 8 insertions(+)
diff --git a/fs/inode.c b/fs/inode.c
index 670d5408d022..f08711b34341 100
On Tue, Jun 25, 2019 at 07:32:10PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Create a generic function to check incoming FS_IOC_SETFLAGS flag values
> and later prepare the inode for updates so that we can standardize the
> implementations that follow ext4's flag values.
Change i
On Tue, Jun 25, 2019 at 07:32:18PM -0700, Darrick J. Wong wrote:
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -373,10 +373,9 @@ static int check_xflags(unsigned int flags)
> static int btrfs_ioctl_fsgetxattr(struct file *file, void __user *arg)
> {
> struct btrfs_inode *binode = B
On Tue, Jun 25, 2019 at 08:13:29PM +0200, Andreas Gruenbacher wrote:
> On Tue, 25 Jun 2019 at 12:50, Christoph Hellwig wrote:
> >
> > > That seems way more complicated. I'd much rather go with something
> > > like may patch plus maybe a big fat comment explaining that persisting
> > > the size up
29 matches
Mail list logo
