Re: [PATCH 3/6] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

ut... so, uh, I guess I'm fine with it. At worst it's easily reverted during -rc if it causes problems. Anyone have a stronger objection? Acked-by: Darrick J. Wong --D > -- > Michal Hocko > SUSE Labs

Re: [PATCH] xfs: fix semicolon.cocci warnings

ge details on log reservation > overrun") > CC: Brian Foster <bfos...@redhat.com> > Signed-off-by: Fengguang Wu <fengguang...@intel.com> Looks good, will test... Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com> --D > --- > > xfs_log.c |2 +- >

Re: [PATCH] xfs: fix semicolon.cocci warnings

ge details on log reservation > overrun") > CC: Brian Foster > Signed-off-by: Fengguang Wu Looks good, will test... Reviewed-by: Darrick J. Wong --D > --- > > xfs_log.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/fs/xfs/xfs_log.c >

[GIT PULL] xfs: updates for 4.12-rc7

) Changes since last update: - don't allow swapon on files on the realtime device, because the swap code will swap pages out to blocks on the data device, thereby corrupting the filesystem Darrick J. Wong (1): xfs: don't

[GIT PULL] xfs: updates for 4.12-rc7

) Changes since last update: - don't allow swapon on files on the realtime device, because the swap code will swap pages out to blocks on the data device, thereby corrupting the filesystem Darrick J. Wong (1): xfs: don't

Re: [PATCH 09/32] ext4: extended attribute value size limit is enforced by vfs

On Thu, Jun 22, 2017 at 06:27:08PM -0400, Theodore Ts'o wrote: > On Thu, Jun 22, 2017 at 01:40:25PM -0600, Andreas Dilger wrote: > > > > The EXT4_XATTR_MAX_LARGE_EA_SIZE limit of 1MB was also totally arbitrary, > > but a reasonable upper limit for the atomic get/set interface used by > > xattrs.

Re: [PATCH 09/32] ext4: extended attribute value size limit is enforced by vfs

On Thu, Jun 22, 2017 at 06:27:08PM -0400, Theodore Ts'o wrote: > On Thu, Jun 22, 2017 at 01:40:25PM -0600, Andreas Dilger wrote: > > > > The EXT4_XATTR_MAX_LARGE_EA_SIZE limit of 1MB was also totally arbitrary, > > but a reasonable upper limit for the atomic get/set interface used by > > xattrs.

Re: [PATCH 09/32] ext4: extended attribute value size limit is enforced by vfs

On Wed, Jun 21, 2017 at 02:21:19PM -0700, Tahsin Erdogan wrote: > EXT4_XATTR_MAX_LARGE_EA_SIZE definition in ext4 is currently unused. > Besides, vfs enforces its own 64k limit which makes the 1MB limit in > ext4 redundant. Remove it. Just FYI I believe the 64k VFS limit exists because XFS is the

Re: [PATCH 09/32] ext4: extended attribute value size limit is enforced by vfs

On Wed, Jun 21, 2017 at 02:21:19PM -0700, Tahsin Erdogan wrote: > EXT4_XATTR_MAX_LARGE_EA_SIZE definition in ext4 is currently unused. > Besides, vfs enforces its own 64k limit which makes the 1MB limit in > ext4 redundant. Remove it. Just FYI I believe the 64k VFS limit exists because XFS is the

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Thu, Jun 22, 2017 at 09:37:14AM +1000, Dave Chinner wrote: > On Mon, Jun 19, 2017 at 10:22:14PM -0700, Darrick J. Wong wrote: > > [add linux-xfs to the fray] > > > > On Fri, Jun 16, 2017 at 06:15:35PM -0700, Dan Williams wrote: > > > + spin_lock(

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Thu, Jun 22, 2017 at 09:37:14AM +1000, Dave Chinner wrote: > On Mon, Jun 19, 2017 at 10:22:14PM -0700, Darrick J. Wong wrote: > > [add linux-xfs to the fray] > > > > On Fri, Jun 16, 2017 at 06:15:35PM -0700, Dan Williams wrote: > > > + spin_lock(

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Tue, Jun 20, 2017 at 09:42:55AM -0600, Ross Zwisler wrote: > On Mon, Jun 19, 2017 at 10:22:14PM -0700, Darrick J. Wong wrote: > <> > > Fourth, the VFS entry points for things like read, write, truncate, > > utimes, fallocate, etc. all just bail out if S_IOMAP_FROZEN

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Tue, Jun 20, 2017 at 09:42:55AM -0600, Ross Zwisler wrote: > On Mon, Jun 19, 2017 at 10:22:14PM -0700, Darrick J. Wong wrote: > <> > > Fourth, the VFS entry points for things like read, write, truncate, > > utimes, fallocate, etc. all just bail out if S_IOMAP_FROZEN

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Wed, Jun 21, 2017 at 09:53:46AM +1000, Dave Chinner wrote: > On Tue, Jun 20, 2017 at 09:17:36AM -0700, Dan Williams wrote: > > On Tue, Jun 20, 2017 at 1:49 AM, Christoph Hellwig wrote: > > > [stripped giant fullquotes] > > > > > > On Mon, Jun 19, 2017 at 10:53:12PM -0700, Andy

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Wed, Jun 21, 2017 at 09:53:46AM +1000, Dave Chinner wrote: > On Tue, Jun 20, 2017 at 09:17:36AM -0700, Dan Williams wrote: > > On Tue, Jun 20, 2017 at 1:49 AM, Christoph Hellwig wrote: > > > [stripped giant fullquotes] > > > > > > On Mon, Jun 19, 2017 at 10:53:12PM -0700, Andy Lutomirski

Re: [PATCH] percpu_counter: Rename __percpu_counter_add to percpu_counter_add_batch

j: Minor updates to patch description for clarity. Cosmetic > indentation updates. > > Signed-off-by: Nikolay Borisov <nbori...@suse.com> > Signed-off-by: Tejun Heo <t...@kernel.org> > Cc: Chris Mason <c...@fb.com> > Cc: Josef Bacik <jba...@fb.com> > Cc: David Ster

Re: [PATCH] percpu_counter: Rename __percpu_counter_add to percpu_counter_add_batch

ption for clarity. Cosmetic > indentation updates. > > Signed-off-by: Nikolay Borisov > Signed-off-by: Tejun Heo > Cc: Chris Mason > Cc: Josef Bacik > Cc: David Sterba > Cc: Darrick J. Wong > Cc: Jan Kara > Cc: Jens Axboe > Cc: linux...@kvack.org > Cc: &

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[add linux-xfs to the fray] On Fri, Jun 16, 2017 at 06:15:35PM -0700, Dan Williams wrote: > To date, the full promise of byte-addressable access to persistent > memory has only been half realized via the filesystem-dax interface. The > current filesystem-dax mechanism allows an application to

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[add linux-xfs to the fray] On Fri, Jun 16, 2017 at 06:15:35PM -0700, Dan Williams wrote: > To date, the full promise of byte-addressable access to persistent > memory has only been half realized via the filesystem-dax interface. The > current filesystem-dax mechanism allows an application to

Re: [RFC PATCH 1/2] mm: introduce bmap_walk()

On Sun, Jun 18, 2017 at 09:51:52AM +0200, Christoph Hellwig wrote: > On Sat, Jun 17, 2017 at 05:29:23AM -0700, Dan Williams wrote: > > On Fri, Jun 16, 2017 at 10:22 PM, Christoph Hellwig wrote: > > > On Fri, Jun 16, 2017 at 06:15:29PM -0700, Dan Williams wrote: > > >> Refactor the

Re: [RFC PATCH 1/2] mm: introduce bmap_walk()

On Sun, Jun 18, 2017 at 09:51:52AM +0200, Christoph Hellwig wrote: > On Sat, Jun 17, 2017 at 05:29:23AM -0700, Dan Williams wrote: > > On Fri, Jun 16, 2017 at 10:22 PM, Christoph Hellwig wrote: > > > On Fri, Jun 16, 2017 at 06:15:29PM -0700, Dan Williams wrote: > > >> Refactor the core of

[GIT PULL] xfs: updates for 4.12-rc6

Hi Linus, I've one more bugfix for you for 4.12-rc6 to fix something that came up in an earlier rc. --Darrick The following changes since commit 63db7c815bc0997c29e484d2409684fdd9fcd93b: xfs: use ->b_state to fix buffer I/O accounting release race (2017-05-31 08:22:52 -0700) are available

[GIT PULL] xfs: updates for 4.12-rc6

Hi Linus, I've one more bugfix for you for 4.12-rc6 to fix something that came up in an earlier rc. --Darrick The following changes since commit 63db7c815bc0997c29e484d2409684fdd9fcd93b: xfs: use ->b_state to fix buffer I/O accounting release race (2017-05-31 08:22:52 -0700) are available

Re: [PATCH 29/31] ext4: reserve space for xattr entries/names

On Wed, Jun 14, 2017 at 10:23:26AM -0700, Tahsin Erdogan wrote: > New ea_inode feature allows putting large xattr values into external > inodes. struct ext4_xattr_entry and the attribute name however have to > remain in the inode extra space or external attribute block. Once that > space is

Re: [PATCH 29/31] ext4: reserve space for xattr entries/names

On Wed, Jun 14, 2017 at 10:23:26AM -0700, Tahsin Erdogan wrote: > New ea_inode feature allows putting large xattr values into external > inodes. struct ext4_xattr_entry and the attribute name however have to > remain in the inode extra space or external attribute block. Once that > space is

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Tue, Jun 06, 2017 at 04:12:58PM -0400, Jeff Layton wrote: > On Tue, 2017-06-06 at 10:17 -0700, Darrick J. Wong wrote: > > On Tue, Jun 06, 2017 at 08:23:25PM +0800, Eryu Guan wrote: > > > On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > > > > On Tue, 2

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Tue, Jun 06, 2017 at 04:12:58PM -0400, Jeff Layton wrote: > On Tue, 2017-06-06 at 10:17 -0700, Darrick J. Wong wrote: > > On Tue, Jun 06, 2017 at 08:23:25PM +0800, Eryu Guan wrote: > > > On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > > > > On Tue, 2

Re: [xfs] 63db7c815b: XFS: Assertion failed: spin_is_locked(>b_lock), file: fs/xfs/xfs_buf.c, line: 120

t; https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > > > commit 63db7c815bc0997c29e484d2409684fdd9fcd93b > > Author: Brian Foster <bfos...@redhat.com> > > AuthorDate: Wed May 31 08:22:52 2017 -0700 > > Commit: Darrick J. Wo

Re: [xfs] 63db7c815b: XFS: Assertion failed: spin_is_locked(>b_lock), file: fs/xfs/xfs_buf.c, line: 120

t; https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > > > commit 63db7c815bc0997c29e484d2409684fdd9fcd93b > > Author: Brian Foster > > AuthorDate: Wed May 31 08:22:52 2017 -0700 > > Commit: Darrick J. Wong > > CommitDate: Wed M

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Tue, Jun 06, 2017 at 08:23:25PM +0800, Eryu Guan wrote: > On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > > On Tue, 2017-06-06 at 16:58 +0800, Eryu Guan wrote: > > > On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote: > > > > I'm working on a set of kernel patches to

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Tue, Jun 06, 2017 at 08:23:25PM +0800, Eryu Guan wrote: > On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > > On Tue, 2017-06-06 at 16:58 +0800, Eryu Guan wrote: > > > On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote: > > > > I'm working on a set of kernel patches to

[GIT PULL] xfs: updates for 4.12-rc4

Hi Linus, I've one more bugfix for you for 4.12-rc4. --Darrick The following changes since commit a54fba8f5a0dc36161cacdf2aa90f007f702ec1a: xfs: Move handling of missing page into one place in xfs_find_get_desired_pgoff() (2017-05-25 09:42:25 -0700) are available in the git repository at:

[GIT PULL] xfs: updates for 4.12-rc4

Hi Linus, I've one more bugfix for you for 4.12-rc4. --Darrick The following changes since commit a54fba8f5a0dc36161cacdf2aa90f007f702ec1a: xfs: Move handling of missing page into one place in xfs_find_get_desired_pgoff() (2017-05-25 09:42:25 -0700) are available in the git repository at:

Re: [PATCH v2 27/28] ext4: xattr inode deduplication

On Fri, Jun 02, 2017 at 05:46:22AM -0700, Tahsin Erdogan wrote: > > Hmm... normally we'd supply sbi->s_csum_seed as the second argument so > > that the metadata checksum value also has the fs uuid stamped into it. > > I have thought about using sbi->s_csum_seed and was a little hesitant > because

Re: [PATCH v2 27/28] ext4: xattr inode deduplication

On Fri, Jun 02, 2017 at 05:46:22AM -0700, Tahsin Erdogan wrote: > > Hmm... normally we'd supply sbi->s_csum_seed as the second argument so > > that the metadata checksum value also has the fs uuid stamped into it. > > I have thought about using sbi->s_csum_seed and was a little hesitant > because

Re: [PATCH v2 27/28] ext4: xattr inode deduplication

On Wed, May 31, 2017 at 03:33:57PM -0700, Tahsin Erdogan wrote: > Ext4 now supports xattr values that are up to 64k in size (vfs limit). > Large xattr values are stored in external inodes each one holding a > single value. Once written the data blocks of these inodes are immutable. > > The real

Re: [PATCH v2 27/28] ext4: xattr inode deduplication

On Wed, May 31, 2017 at 03:33:57PM -0700, Tahsin Erdogan wrote: > Ext4 now supports xattr values that are up to 64k in size (vfs limit). > Large xattr values are stored in external inodes each one holding a > single value. Once written the data blocks of these inodes are immutable. > > The real

Re: [PATCH 01/28] ext4: xattr-in-inode support

On Wed, May 31, 2017 at 01:14:50AM -0700, Tahsin Erdogan wrote: > From: Andreas Dilger > > Large xattr support is implemented for EXT4_FEATURE_INCOMPAT_EA_INODE. > > If the size of an xattr value is larger than will fit in a single > external block, then the xattr

Re: [PATCH 01/28] ext4: xattr-in-inode support

On Wed, May 31, 2017 at 01:14:50AM -0700, Tahsin Erdogan wrote: > From: Andreas Dilger > > Large xattr support is implemented for EXT4_FEATURE_INCOMPAT_EA_INODE. > > If the size of an xattr value is larger than will fit in a single > external block, then the xattr value will be saved into the

Re: [PATCH 07/28] ext4: call journal revoke when freeing ea_inode blocks

On Wed, May 31, 2017 at 01:14:56AM -0700, Tahsin Erdogan wrote: > ea_inode contents are treated as metadata, that's why it is journaled > during initial writes. Failing to call revoke during freeing could cause > user data to be overwritten with original ea_inode contents during journal > replay.

Re: [PATCH 07/28] ext4: call journal revoke when freeing ea_inode blocks

On Wed, May 31, 2017 at 01:14:56AM -0700, Tahsin Erdogan wrote: > ea_inode contents are treated as metadata, that's why it is journaled > during initial writes. Failing to call revoke during freeing could cause > user data to be overwritten with original ea_inode contents during journal > replay.

Re: [PATCH 09/28] ext4: extended attribute value size limit is enforced by vfs

On Wed, May 31, 2017 at 01:14:58AM -0700, Tahsin Erdogan wrote: > EXT4_XATTR_MAX_LARGE_EA_SIZE definition in ext4 is currently unused. > Besides, vfs enforces its own 64k limit which makes the 1MB limit in > ext4 redundant. Remove it. > > Signed-off-by: Tahsin Erdogan > --- >

Re: [PATCH 09/28] ext4: extended attribute value size limit is enforced by vfs

On Wed, May 31, 2017 at 01:14:58AM -0700, Tahsin Erdogan wrote: > EXT4_XATTR_MAX_LARGE_EA_SIZE definition in ext4 is currently unused. > Besides, vfs enforces its own 64k limit which makes the 1MB limit in > ext4 redundant. Remove it. > > Signed-off-by: Tahsin Erdogan > --- > fs/ext4/ext4.h | 6

Re: [PATCH 27/28] ext4: xattr inode deduplication

On Wed, May 31, 2017 at 01:15:16AM -0700, Tahsin Erdogan wrote: > Ext4 now supports xattr values that are up to 64k in size (vfs limit). > Large xattr values are stored in external inodes each one holding a > single value. Once written the data blocks of these inodes are immutable. > > The real

Re: [PATCH 27/28] ext4: xattr inode deduplication

On Wed, May 31, 2017 at 01:15:16AM -0700, Tahsin Erdogan wrote: > Ext4 now supports xattr values that are up to 64k in size (vfs limit). > Large xattr values are stored in external inodes each one holding a > single value. Once written the data blocks of these inodes are immutable. > > The real

[GIT PULL] xfs: updates for 4.12-rc3

ting error on partial delalloc conversion Darrick J. Wong (4): xfs: BMAPX shouldn't barf on inline-format directories xfs: fix warnings about unused stack variables xfs: only return detailed fsmap info if the caller has CAP_SYS_ADMIN xfs: avoid mount-time deadlock in CoW ex

[GIT PULL] xfs: updates for 4.12-rc3

ting error on partial delalloc conversion Darrick J. Wong (4): xfs: BMAPX shouldn't barf on inline-format directories xfs: fix warnings about unused stack variables xfs: only return detailed fsmap info if the caller has CAP_SYS_ADMIN xfs: avoid mount-time deadlock in CoW ex

Re: [PATCH 12/23] xfs: remove uuid_getnodeuniq and xfs_uu_t

On Thu, May 18, 2017 at 08:26:54AM +0200, Christoph Hellwig wrote: > Directly use the v1 intepretation of uuid_t instead. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com> --D > --- &g

Re: [PATCH 12/23] xfs: remove uuid_getnodeuniq and xfs_uu_t

On Thu, May 18, 2017 at 08:26:54AM +0200, Christoph Hellwig wrote: > Directly use the v1 intepretation of uuid_t instead. > > Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong --D > --- > fs/xfs/uuid.c | 25 - > fs/xfs/uuid.h

Re: [PATCH 02/23] xfs: use uuid_be to implement the uuid_t type

On Thu, May 18, 2017 at 08:26:44AM +0200, Christoph Hellwig wrote: > Use the generic Linux definition to implement our UUID type, this will > allow using more generic infrastructure in the future. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Darrick

Re: [PATCH 02/23] xfs: use uuid_be to implement the uuid_t type

On Thu, May 18, 2017 at 08:26:44AM +0200, Christoph Hellwig wrote: > Use the generic Linux definition to implement our UUID type, this will > allow using more generic infrastructure in the future. > > Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong --D > --- &

Re: [PATCH 01/23] xfs: use uuid_copy() helper to abstract uuid_t

On Thu, May 18, 2017 at 08:26:43AM +0200, Christoph Hellwig wrote: > From: Amir Goldstein <amir7...@gmail.com> > > uuid_t definition is about to change. > > Signed-off-by: Amir Goldstein <amir7...@gmail.com> > Signed-off-by: Christoph Hellwig <h...@lst.

Re: [PATCH 01/23] xfs: use uuid_copy() helper to abstract uuid_t

On Thu, May 18, 2017 at 08:26:43AM +0200, Christoph Hellwig wrote: > From: Amir Goldstein > > uuid_t definition is about to change. > > Signed-off-by: Amir Goldstein > Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong > --- > fs/xfs/xfs_inode_item.

Re: [PATCH 04/23] uuid: rename uuid types

retained for > now, but will hopefully go away soon. The exception to that are the _cmp > helpers that will be replaced by better primites ASAP and thus don't I misread that as "better primates ASAP" :) (Assuming you meant 'primitives'?) Other than that, Reviewed-by: Darrick J. Wong &l

Re: [PATCH 04/23] uuid: rename uuid types

retained for > now, but will hopefully go away soon. The exception to that are the _cmp > helpers that will be replaced by better primites ASAP and thus don't I misread that as "better primates ASAP" :) (Assuming you meant 'primitives'?) Other than that, Reviewed-by: Darrick J. Wong

Re: [xfstests PATCH v2 2/3] ext4: allow ext4 to use $SCRATCH_LOGDEV

infrastructure for this (a'la $SCRATCH_LOGDEV), so wire > up the ext4 code so that it can do the same thing when _scratch_mkfs is > called. > > Signed-off-by: Jeff Layton <jlay...@redhat.com> Looks ok, Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com> --D > --- > comm

Re: [xfstests PATCH v2 2/3] ext4: allow ext4 to use $SCRATCH_LOGDEV

infrastructure for this (a'la $SCRATCH_LOGDEV), so wire > up the ext4 code so that it can do the same thing when _scratch_mkfs is > called. > > Signed-off-by: Jeff Layton Looks ok, Reviewed-by: Darrick J. Wong --D > --- > common/rc | 3 +++ > 1 file changed, 3 insertions(+) >

Re: [PATCH 1/2] dax: hide block device code in #ifdef

gmann <a...@arndb.de> > > > > Yup, the same one I came up with: > > > > https://patchwork.kernel.org/patch/9725513/ > > > > If you have a a pull request coming up soon you can add my Acked-by to > > both of these patches, otherwise I'll send what

Re: [PATCH 1/2] dax: hide block device code in #ifdef

th: > > > > https://patchwork.kernel.org/patch/9725513/ > > > > If you have a a pull request coming up soon you can add my Acked-by to > > both of these patches, otherwise I'll send what I have along at the > > end of the week. > > I didn't plan to send a

Re: [PATCH v2] xfs: avoid harmless gcc-7 warnings

o, so let's use that instead to shut up the warning. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com> --D > --- > fs/xfs/xfs_bmap_util.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH v2] xfs: avoid harmless gcc-7 warnings

o, so let's use that instead to shut up the warning. > > Signed-off-by: Arnd Bergmann Reviewed-by: Darrick J. Wong --D > --- > fs/xfs/xfs_bmap_util.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c > ind

[GIT PULL] xfs: updates for 4.12

xfs: fix __user annotations for xfs_ioc_getfsmap xfs: don't use bool values in trace buffers xfs: remove xfs_trans_ail_delete_bulk Darrick J. Wong (15): xfs: rework the inline directory verifiers xfs: fix kernel memory exposure problems xfs: fix over-copying of getb

[GIT PULL] xfs: updates for 4.12

xfs: fix __user annotations for xfs_ioc_getfsmap xfs: don't use bool values in trace buffers xfs: remove xfs_trans_ail_delete_bulk Darrick J. Wong (15): xfs: rework the inline directory verifiers xfs: fix kernel memory exposure problems xfs: fix over-copying of getb

Re: [PATCH 0/5] fs, xfs refcount conversions

On Thu, Apr 20, 2017 at 10:24:04AM -0700, Darrick J. Wong wrote: > On Thu, Apr 20, 2017 at 08:11:41AM +, Reshetova, Elena wrote: > > > > > > > v3: > > > * fixed header file inclusion > > > > I don't think I have heard anything back on thi

Re: [PATCH 0/5] fs, xfs refcount conversions

On Thu, Apr 20, 2017 at 10:24:04AM -0700, Darrick J. Wong wrote: > On Thu, Apr 20, 2017 at 08:11:41AM +, Reshetova, Elena wrote: > > > > > > > v3: > > > * fixed header file inclusion > > > > I don't think I have heard anything back on thi

Re: [PATCH 0/5] fs, xfs refcount conversions

On Thu, Apr 20, 2017 at 08:11:41AM +, Reshetova, Elena wrote: > > > > v3: > > * fixed header file inclusion > > I don't think I have heard anything back on this v3 patch set. > Is there still smth here to fix or could you take the changes in? Generally I think it looks ok; it's running

Re: [PATCH 0/5] fs, xfs refcount conversions

On Thu, Apr 20, 2017 at 08:11:41AM +, Reshetova, Elena wrote: > > > > v3: > > * fixed header file inclusion > > I don't think I have heard anything back on this v3 patch set. > Is there still smth here to fix or could you take the changes in? Generally I think it looks ok; it's running

4.11-rc7 crash when booting with 1 numa node?

Hi, When booting 4.11-rc7 on a qemu guest with a single numa node, I hit the following[1] crash on boot. If I configure more than one node, the problem goes away. I tracked the relevant line down to: (gdb) l *(irq_create_affinity_masks+0x237) 0x81103a87 is in irq_create_affinity_masks

4.11-rc7 crash when booting with 1 numa node?

Hi, When booting 4.11-rc7 on a qemu guest with a single numa node, I hit the following[1] crash on boot. If I configure more than one node, the problem goes away. I tracked the relevant line down to: (gdb) l *(irq_create_affinity_masks+0x237) 0x81103a87 is in irq_create_affinity_masks

[GIT PULL] xfs: fixes for 4.11-rc6

verifier to avoid crashes on disk corruption - Don't change file size when punching holes w/ KEEP_SIZE - Close a kernel memory exposure bug Calvin Owens (1): xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files Darrick J. Wong

[GIT PULL] xfs: fixes for 4.11-rc6

verifier to avoid crashes on disk corruption - Don't change file size when punching holes w/ KEEP_SIZE - Close a kernel memory exposure bug Calvin Owens (1): xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files Darrick J. Wong

Re: [PATCH v3] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

On Mon, Apr 03, 2017 at 10:15:31AM -0700, Darrick J. Wong wrote: > On Thu, Mar 30, 2017 at 09:18:00PM -0700, Calvin Owens wrote: > > When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will > > round the file size up to the nearest multiple of PAGE_SIZE: > &g

Re: [PATCH v3] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

On Mon, Apr 03, 2017 at 10:15:31AM -0700, Darrick J. Wong wrote: > On Thu, Mar 30, 2017 at 09:18:00PM -0700, Calvin Owens wrote: > > When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will > > round the file size up to the nearest multiple of PAGE_SIZE: > &g

Re: [PATCH v3] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

* smart enough to skip any holes, including those we just created, > + * but we must take care not to zero beyond EOF and enlarge i_size. >*/ > + > + if (offset >= XFS_ISIZE(ip)) > + return 0; > + > + if (offset + len > XFS_ISIZE(ip)) > +

Re: [PATCH v3] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

beyond EOF and enlarge i_size. >*/ > + > + if (offset >= XFS_ISIZE(ip)) > + return 0; > + > + if (offset + len > XFS_ISIZE(ip)) > + len = XFS_ISIZE(ip) - offset; > + I'll pick this up for 4.12. Reviewed-by: Darrick J. Wong --D >

Re: [PATCH 8/8] statx: Include a mask for stx_attributes in struct statx

On Fri, Mar 31, 2017 at 06:32:17PM +0100, David Howells wrote: > Include a mask in struct stat to indicate which bits of stx_attributes the > filesystem actually supports. > > This would also be useful if we add another system call that allows you to > do a 'bulk attribute set' and pass in a

Re: [PATCH 8/8] statx: Include a mask for stx_attributes in struct statx

On Fri, Mar 31, 2017 at 06:32:17PM +0100, David Howells wrote: > Include a mask in struct stat to indicate which bits of stx_attributes the > filesystem actually supports. > > This would also be useful if we add another system call that allows you to > do a 'bulk attribute set' and pass in a

[GIT PULL] xfs: fixes for 4.11-rc3

) Changes since last time: - Validate inline directory data to prevent buffer overruns due to corrupt metadata. Darrick J. Wong (1): xfs: verify inline directory data forks

[GIT PULL] xfs: fixes for 4.11-rc3

) Changes since last time: - Validate inline directory data to prevent buffer overruns due to corrupt metadata. Darrick J. Wong (1): xfs: verify inline directory data forks

Re: [PATCH v2] xfs: remove kmem_zalloc_greedy

On Wed, Mar 15, 2017 at 04:43:27PM +0100, Luis R. Rodriguez wrote: > On Wed, Mar 15, 2017 at 09:35:29AM +0100, Michal Hocko wrote: > > On Wed 15-03-17 01:14:27, Luis R. Rodriguez wrote: > > > On Tue, Mar 14, 2017 at 11:07:38AM -0700, Darrick J. Wong wrote: > > > >

Re: [PATCH v2] xfs: remove kmem_zalloc_greedy

On Wed, Mar 15, 2017 at 04:43:27PM +0100, Luis R. Rodriguez wrote: > On Wed, Mar 15, 2017 at 09:35:29AM +0100, Michal Hocko wrote: > > On Wed 15-03-17 01:14:27, Luis R. Rodriguez wrote: > > > On Tue, Mar 14, 2017 at 11:07:38AM -0700, Darrick J. Wong wrote: > > > >

Re: [PATCH v2] xfs: remove kmem_zalloc_greedy

On Tue, Mar 14, 2017 at 05:57:45PM +0100, Luis R. Rodriguez wrote: > On Tue, Mar 07, 2017 at 04:35:28PM -0800, Darrick J. Wong wrote: > > The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses > > it to grab 1-4 pages for staging of inobt records. Th

Re: [PATCH v2] xfs: remove kmem_zalloc_greedy

On Tue, Mar 14, 2017 at 05:57:45PM +0100, Luis R. Rodriguez wrote: > On Tue, Mar 07, 2017 at 04:35:28PM -0800, Darrick J. Wong wrote: > > The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses > > it to grab 1-4 pages for staging of inobt records. Th

[GIT PULL] xfs: fixes for 4.11-rc2

Hellwig (3): xfs: only reclaim unwritten COW extents periodically xfs: fix and streamline error handling in xfs_end_io xfs: try any AG when allocating the first btree block when reflinking Darrick J. Wong (1): xfs: remove kmem_zalloc_greedy Eryu Guan (1): iomap

[GIT PULL] xfs: fixes for 4.11-rc2

Hellwig (3): xfs: only reclaim unwritten COW extents periodically xfs: fix and streamline error handling in xfs_end_io xfs: try any AG when allocating the first btree block when reflinking Darrick J. Wong (1): xfs: remove kmem_zalloc_greedy Eryu Guan (1): iomap

[PATCH v2] xfs: remove kmem_zalloc_greedy

bulkstat somewhat more likely to ENOMEM if there's really no pages to spare, but eliminates a source of hangs. [1] http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com Signed-off-by: Darrick J. Wong <darrick.w...@oracle.com> --- v2: remove single-page fallback -

[PATCH v2] xfs: remove kmem_zalloc_greedy

bulkstat somewhat more likely to ENOMEM if there's really no pages to spare, but eliminates a source of hangs. [1] http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com Signed-off-by: Darrick J. Wong --- v2: remove single-page fallback --- fs/xfs/kmem.c | 18

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

hat small allocations actually never failed. > > Now that we have __GFP_RETRY_MAYFAIL flag which works independently on the > allocation request size we can map KM_MAYFAIL to it. The allocator will > try as hard as it can to fulfill the request but fails eventually if > the progress cann

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

actually never failed. > > Now that we have __GFP_RETRY_MAYFAIL flag which works independently on the > allocation request size we can map KM_MAYFAIL to it. The allocator will > try as hard as it can to fulfill the request but fails eventually if > the progress cannot be made. > &g

Re: [PATCH 4/5] fs, xfs: convert xfs_cui_log_item.cui_refcount from atomic_t to refcount_t

On Tue, Mar 07, 2017 at 05:33:14PM +, Reshetova, Elena wrote: > > Signed-off-by: Elena Reshetova > > > Signed-off-by: Hans Liljestrand > > > Signed-off-by: Kees Cook > > > Signed-off-by: David Windsor

Re: [PATCH 4/5] fs, xfs: convert xfs_cui_log_item.cui_refcount from atomic_t to refcount_t

On Tue, Mar 07, 2017 at 05:33:14PM +, Reshetova, Elena wrote: > > Signed-off-by: Elena Reshetova > > > Signed-off-by: Hans Liljestrand > > > Signed-off-by: Kees Cook > > > Signed-off-by: David Windsor > > > --- > > > fs/xfs/xfs_refcount_item.c | 4 ++-- > > > fs/xfs/xfs_refcount_item.h |

Re: [PATCH] xfs: remove kmem_zalloc_greedy

On Tue, Mar 07, 2017 at 01:07:54AM +0100, Christoph Hellwig wrote: > I like killing it, but shouldn't we just try a normal kmem_zalloc? > At least for the fallback it's the right thing, and even for an > order 2 allocation it seems like a useful first try. I'm confused -- kmem_zalloc_large tries

Re: [PATCH] xfs: remove kmem_zalloc_greedy

On Tue, Mar 07, 2017 at 01:07:54AM +0100, Christoph Hellwig wrote: > I like killing it, but shouldn't we just try a normal kmem_zalloc? > At least for the fallback it's the right thing, and even for an > order 2 allocation it seems like a useful first try. I'm confused -- kmem_zalloc_large tries

Re: [PATCH 4/5] fs, xfs: convert xfs_cui_log_item.cui_refcount from atomic_t to refcount_t

On Wed, Mar 01, 2017 at 10:47:39AM +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. >

Re: [PATCH 4/5] fs, xfs: convert xfs_cui_log_item.cui_refcount from atomic_t to refcount_t

On Wed, Mar 01, 2017 at 10:47:39AM +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. >

[PATCH] xfs: remove kmem_zalloc_greedy

bulkstat somewhat more likely to ENOMEM if there's really no pages to spare, but eliminates a source of hangs. [1] https://lkml.org/lkml/2017/2/28/832 Signed-off-by: Darrick J. Wong <darrick.w...@oracle.com> --- fs/xfs/kmem.c | 18 -- fs/xfs/kmem.h |2 --

[PATCH] xfs: remove kmem_zalloc_greedy

bulkstat somewhat more likely to ENOMEM if there's really no pages to spare, but eliminates a source of hangs. [1] https://lkml.org/lkml/2017/2/28/832 Signed-off-by: Darrick J. Wong --- fs/xfs/kmem.c | 18 -- fs/xfs/kmem.h |2 -- fs/xfs/xfs_itable.c | 14

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

On Sat, Mar 04, 2017 at 09:54:44AM +1100, Dave Chinner wrote: > On Thu, Mar 02, 2017 at 04:45:40PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Even though kmem_zalloc_greedy is documented it might fail the current > > code doesn't really implement this properly and

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

On Sat, Mar 04, 2017 at 09:54:44AM +1100, Dave Chinner wrote: > On Thu, Mar 02, 2017 at 04:45:40PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Even though kmem_zalloc_greedy is documented it might fail the current > > code doesn't really implement this properly and loops on the

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

other patch [1] is not that urgent. > > [1] http://lkml.kernel.org/r/20170302154541.16155-2-mho...@kernel.org Both patches look ok to me. I'll take both patches for rc2. Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com> (Annoyingly I missed the whole thread yesterday due to vg

<    5   6   7   8   9   10   11   12   13   14   >