Re: [PATCH 2/4] nfs: check for NULL vfsmount in nfs_getattr

On Tue, Jul 31, 2018 at 10:51:57PM +, Mark Fasheh wrote: > Hi Al, > > On Tue, Jul 31, 2018 at 11:16:05PM +0100, Al Viro wrote: > > On Tue, Jul 31, 2018 at 02:10:43PM -0700, Mark Fasheh wrote: > > > ->getattr from inside the kernel won't al

Re: [PATCH 2/4] nfs: check for NULL vfsmount in nfs_getattr

On Tue, Jul 31, 2018 at 02:10:43PM -0700, Mark Fasheh wrote: > ->getattr from inside the kernel won't always have a vfsmount, check for > this. Really? Where would that happen? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

[RFC][PATCH] btrfs: take the last remnants of ->d_fsdata use out

ry_delete() does. Signed-off-by: Al Viro <v...@zeniv.linux.org.uk> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e064c49c9a9a..c6b2b0a20561 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -5842,11 +5842,6 @@ static int btrfs_dentry_delete(const struct dentry *dentry)

Re: [PATCH 1/3] fs: add initial bh_result->b_private value to __blockdev_direct_IO()

On Fri, May 11, 2018 at 01:30:01PM -0700, Omar Sandoval wrote: > On Fri, May 11, 2018 at 09:05:38PM +0100, Al Viro wrote: > > On Thu, May 10, 2018 at 11:30:10PM -0700, Omar Sandoval wrote: > > > do_blockdev_direct_IO(struct kiocb *iocb, struct inode *inode, > >

Re: [PATCH 1/3] fs: add initial bh_result->b_private value to __blockdev_direct_IO()

On Thu, May 10, 2018 at 11:30:10PM -0700, Omar Sandoval wrote: > do_blockdev_direct_IO(struct kiocb *iocb, struct inode *inode, > struct block_device *bdev, struct iov_iter *iter, > get_block_t get_block, dio_iodone_t end_io, > -

Re: [PATCH 1/2 V2] fs: hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote: > Move the btrfs label ioctls up to the vfs for general use. > > This retains 256 chars as the maximum size through the interface, which > is the btrfs limit and AFAIK exceeds any other filesystem's maximum > label size. > >

Re: d_instantiate() and unlock_new_inode() order in btrfs_mkdir()

On Thu, Apr 19, 2018 at 01:06:13AM +0100, Al Viro wrote: > On Wed, Apr 18, 2018 at 05:00:29PM -0700, Eric Biggers wrote: > > Hi Chris and other btrfs folks, > > > > btrfs_mkdir() calls d_instantiate() before unlock_new_inode(), which is > > wrong > > becaus

Re: d_instantiate() and unlock_new_inode() order in btrfs_mkdir()

On Wed, Apr 18, 2018 at 05:00:29PM -0700, Eric Biggers wrote: > Hi Chris and other btrfs folks, > > btrfs_mkdir() calls d_instantiate() before unlock_new_inode(), which is wrong > because it exposes the inode to lookups before it's been fully initialized. Huh? It *is* fully initialized by that

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Tue, Mar 20, 2018 at 04:26:52PM -0700, Linus Torvalds wrote: > On Tue, Mar 20, 2018 at 4:23 PM, Linus Torvalds > wrote: > > > > Hmm. So thanks to the diseased mind of Martin Uecker, there's a better > > test for "__is_constant()": > > > > /* Glory to Martin

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 01:15:27PM -0700, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:12 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > > > > That's C99, straight from N1256.pdf (C99-TC3)... > > I checked C90, since the error is > >ISO C90 forbids

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 12:27:23PM -0700, Linus Torvalds wrote: > But it sure isn't "variable" either as far as the standard is > concerned, because the standard doesn't even have that concept (it > uses "variable" for argument numbers and for variables). Huh? 6.7.5.2p4: If the size is not

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 05:55:02PM +, Al Viro wrote: > On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: > >t.c: In function ‘test’: > >t.c:6:6: error: argument to variable-length array is too large > > [-Werror=vla-larger-than=] > > int a

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: >t.c: In function ‘test’: >t.c:6:6: error: argument to variable-length array is too large > [-Werror=vla-larger-than=] > int array[(1,100)]; > > Gcc people are crazy. That's not them, that's C standard regarding ICE.

Re: [PATCH 0/10 v11] No wait AIO

On Mon, Jun 12, 2017 at 11:14:31PM -0700, Christoph Hellwig wrote: > On Mon, Jun 12, 2017 at 05:38:13PM -0500, Goldwyn Rodrigues wrote: > > We had FS_NOWAIT in filesystem type flags (in v3), but retracted it > > later in v4. > > A per-fs flag is wrong as file_operation may have different >

Re: [PATCH 0/10 v11] No wait AIO

On Thu, Jun 08, 2017 at 12:39:10AM -0700, Christoph Hellwig wrote: > As already indicated this whole series looks fine to me. > > Al: are you going to pick this up? Or Andrew? The main issue here is "let's bail out from ->write_iter() instances" patch. It very obviously has holes in coverage.

Re: [PATCH 04/10] fs: Introduce RWF_NOWAIT

On Tue, Jun 06, 2017 at 06:19:33AM -0500, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > RWF_NOWAIT informs kernel to bail out if an AIO request will block > for reasons such as file allocations, or a writeback triggered, > or would block while allocating requests

Re: btrfs bio linked list corruption.

On Tue, Oct 11, 2016 at 10:45:08AM -0400, Dave Jones wrote: > This is from Linus' current tree, with Al's iovec fixups on top. Those iovec fixups are in the current tree... TBH, I don't see anything in splice-related stuff that could come anywhere near that (short of some general memory

Re: btrfs_direct_IO oops

On Mon, Oct 10, 2016 at 09:11:22AM -0400, Dave Jones wrote: > My compiler choked on that, but I fixed it up. The printk didn't > trigger though.. > > idx = 0, offset = 0 > curbuf = 0, nrbufs = 1, buffers = 16 > [b9a21100 ea00126019c0 0 4096] > [ (null) ea0013746440 0 0]

Re: btrfs_direct_IO oops

On Sun, Oct 09, 2016 at 11:11:06AM -0400, Dave Jones wrote: > idx = 0, offset = 0 == starts at slot 0, nothing put into it yet, but > curbuf = 0, nrbufs = 1, buffers = 16 > [9fa21100 ea00065f6d80 0 4096] the underlying pipe has something stored into slot 0. That definitely should

Re: btrfs_direct_IO oops

On Sat, Oct 08, 2016 at 02:08:06PM -0400, Dave Jones wrote: > That code: matches this dissembly: > > for (i = seg + 1; i < iter->nr_segs; i++) { *whoa* OK, that loop in check_direct_IO() should be done *ONLY* for iovec iter - even for a bvec one it's completely bogus, and for

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

; dropped > and results in dentries still in use at unmount. > > Signed-off-by: Josef Bacik <jba...@fb.com> [sorry, had been off-line since yesterday] Patch looks sane; feel free to slap Acked-by: Al Viro <v...@zeniv.linux.org.uk> on it. I think it should go through

Re: [PATCH] Btrfs: fix ->iterate_shared() by upgrading i_rwsem for delayed nodes

On Wed, May 25, 2016 at 04:22:26PM -0400, Chris Mason wrote: > On Wed, May 25, 2016 at 10:11:29PM +0200, David Sterba wrote: > > On Fri, May 20, 2016 at 01:50:33PM -0700, Omar Sandoval wrote: > > > Commit fe742fd4f90f ("Revert "btrfs: switch to ->iterate_shared()"") > > > backed out the conversion

Re: kernel BUG when fsync'ing file in a overlayfs merged dir, located on btrfs

On Thu, Mar 24, 2016 at 03:20:43PM +, Al Viro wrote: > > ocfs2_prepare_inode_for_write uses file->f_path.dentry for > > should_remove_suid (due to needing to do it early since cluster locking > > is unknown in setattr, according to the commit). Having > >

Re: kernel BUG when fsync'ing file in a overlayfs merged dir, located on btrfs

On Thu, Nov 05, 2015 at 11:03:58PM -0500, Jeff Mahoney wrote: > I suppose the irony here is that, AFAIK, that code is to ensure a file > doesn't get lost between transactions due to rename. > > Isn't the file->f_path.dentry relationship stable otherwise, though? The > name might change and the

Re: loop subsystem corrupted after mounting multiple btrfs sub-volumes

On Fri, Feb 26, 2016 at 10:36:50PM +0100, Stanislav Brabec wrote: > It should definitely report error whenever trying -oloop on top of > anything else than a file. Or at least a warning. > > Well, even losetup should report a warning. Keep in mind that with crypto in the game it just might be

Re: loop subsystem corrupted after mounting multiple btrfs sub-volumes

On Fri, Feb 26, 2016 at 09:37:22PM +0100, Stanislav Brabec wrote: > Do I understand, that you are saying: > > Yes, mounting multiple loop devices associated with one file is a > legitimate use, but mount(8) should never do it, because it has other > ugly side effects? It's on the same level as

Re: loop subsystem corrupted after mounting multiple btrfs sub-volumes

On Fri, Feb 26, 2016 at 03:05:27PM -0500, Austin S. Hemmelgarn wrote: > >Where is /mnt/2? > It's kind of interesting, but I can't reproduce _any_ of this > behavior with either ext4 or BTRFS when I manually set up the loop > devices and point mount(8) at those instead of using -o loop on a > file.

Re: loop subsystem corrupted after mounting multiple btrfs sub-volumes

On Fri, Feb 26, 2016 at 11:39:11AM -0500, Austin S. Hemmelgarn wrote: > That's just it though, from what I can tell based on what I've seen > and what you said above, mount(8) isn't doing things correctly in > this case. If we were to do this with something like XFS or ext4, > the filesystem

Re: Can you help explain these OOM crashes?

On Thu, Feb 25, 2016 at 02:42:51PM -0500, Chris Mason wrote: > Al, any ideas why get_anon_bdev is doing an atomic allocation here? > > if (ida_pre_get(_dev_ida, GFP_ATOMIC) == 0) Because set() callback of sget() runs under sb_lock - it must be atomic wrt scanning the list of superblock in

Re: [PATCH 1/4] locks: new locks_mandatory_area calling convention

On Tue, Dec 08, 2015 at 03:54:53PM +0100, Christoph Hellwig wrote: > On Tue, Dec 08, 2015 at 04:05:04AM +0000, Al Viro wrote: > > Where the hell would truncate(2) get struct file, anyway? IOW, the inode > > argument is _not_ pointless; re-added. > > Oh, right. Intere

Re: [PATCH 1/4] locks: new locks_mandatory_area calling convention

On Thu, Dec 03, 2015 at 12:59:49PM +0100, Christoph Hellwig wrote: > Pass a loff_t end for the last byte instead of the 32-bit count > parameter to allow full file clones even on 32-bit architectures. > While we're at it also drop the pointless inode argument and simplify > the read/write

Re: [PATCH v9 0/4] VFS: In-kernel copy system call

On Tue, Nov 10, 2015 at 04:53:29PM -0500, Anna Schumaker wrote: > Copy system calls came up during Plumbers a while ago, mostly because several > filesystems (including NFS and XFS) are currently working on copy acceleration > implementations. We haven't heard from Zach Brown in a while, so I >

Re: [PATCH v8 4/4] vfs: Add vfs_copy_file_range() support for pagecache copies

On Fri, Nov 06, 2015 at 04:18:20PM -0500, Anna Schumaker wrote: > I moved the rw_verify_area() calls into the fallback code since some > filesystems can handle reflinking a large range. Take a look at rw_verify_area() - it does a lot more than "trim down to 2Gb" - starting with "deal with

Re: kernel BUG when fsync'ing file in a overlayfs merged dir, located on btrfs

On Thu, Nov 05, 2015 at 09:57:35PM -0500, Jeff Mahoney wrote: > So now file_operations callbacks can't assume that file->f_path.dentry > belongs to the same file system that implements the callback. More than > that, any code that could ultimately get a dentry that comes from an > open file

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Fri, Sep 04, 2015 at 04:25:27PM -0600, Andreas Dilger wrote: > This is a bit of a surprising result, since in my testing in the > past, copy_{to/from}_user() is a major consumer of CPU time (50% > of a CPU core at 1GB/s). What backing filesystem did you test on? While we are at it, was cp(1)

Re: [PATCH 3/3] btrfs: set FS_SUPPORTS_SEEK_HOLE flag.

On Mon, Apr 20, 2015 at 02:48:55AM -0700, Christoph Hellwig wrote: On Mon, Apr 20, 2015 at 10:46:49AM +0100, David Howells wrote: NeilBrown ne...@suse.de wrote: Missing patch 2 of the 3-patch series? Yes. :-) Do ext4 and xfs support this, do you know? Yes. As do f2fs, ocfs2,

Re: [RFC PATCH 0/5] Remove rw parameter from direct_IO()

On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote: Hi, Al, here's some cleanup that you mentioned back in December that I got around to (https://lkml.org/lkml/2014/12/15/28). Applied. See #for-next -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the

Re: [RFC PATCH 1/5] new helper: iov_iter_rw()

On Tue, Mar 17, 2015 at 10:31:51AM +0100, David Sterba wrote: Agreed, but the proposed define is rather cryptic and I was not able to understand the meaning on the first glance. #define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK) This worked for me, does not compile

Re: [RFC PATCH 1/5] new helper: iov_iter_rw()

On Mon, Mar 16, 2015 at 04:33:49AM -0700, Omar Sandoval wrote: Get either READ or WRITE out of iter-type. Umm... + * Get one of READ or WRITE out of iter-type without any other flags OR'd in + * with it. + */ +static inline int iov_iter_rw(const struct iov_iter *i) +{ + return

Re: [RFC PATCH 0/5] Remove rw parameter from direct_IO()

On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote: Hi, Al, here's some cleanup that you mentioned back in December that I got around to (https://lkml.org/lkml/2014/12/15/28). In summary, the rw parameter to a_ops-direct_IO() is redundant with .type in struct iov_iter.

Re: [PATCH RESEND v4 6/8] vfs: Add get_vfsmount_sb() function to get vfsmount from a given sb.

On Thu, Jan 29, 2015 at 01:37:58PM +0100, David Sterba wrote: Adding Al Viro into CC On Thu, Jan 29, 2015 at 10:24:39AM +0800, Qu Wenruo wrote: +struct vfsmount *get_vfsmount_sb(struct super_block *sb) +{ + struct vfsmount *ret_vfs = NULL; + struct mount *mnt; + int ret = 0

Re: [PATCH RESEND v4 6/8] vfs: Add get_vfsmount_sb() function to get vfsmount from a given sb.

On Fri, Jan 30, 2015 at 09:44:03AM +0800, Qu Wenruo wrote: This shouldn't happen. If someone is ro, the whole fs should be ro, right? Wrong. Individual vfsmounts over an r/w superblock might very well be r/o. As for that trylock... What for? It invites transient failures for no good reason.

Re: [PATCH RESEND v4 6/8] vfs: Add get_vfsmount_sb() function to get vfsmount from a given sb.

On Fri, Jan 30, 2015 at 09:11:26AM +0800, Qu Wenruo wrote: For the mounted ro case, that's not a problem, since if one instance is mounted ro, other instances are also mounted ro, so that's not a problem. Not really. root@satch:~# cd /tmp/ root@satch:~# mkdir /tm/a root@satch:~# mount --bind

Re: [PATCH RESEND v4 6/8] vfs: Add get_vfsmount_sb() function to get vfsmount from a given sb.

On Fri, Jan 30, 2015 at 12:14:24PM +0800, Miao Xie wrote: On Fri, 30 Jan 2015 02:14:45 +, Al Viro wrote: On Fri, Jan 30, 2015 at 09:44:03AM +0800, Qu Wenruo wrote: This shouldn't happen. If someone is ro, the whole fs should be ro, right? Wrong. Individual vfsmounts over an r/w

Re: [PATCH RESEND v4 6/8] vfs: Add get_vfsmount_sb() function to get vfsmount from a given sb.

On Fri, Jan 30, 2015 at 01:34:41PM +0800, Miao Xie wrote: First of all, -s_umount is not a mutex; it's rwsem. So you mean down_read_trylock(). As for the transient failures - grep for down_write on it... E.g. have somebody call mount() from the same device. We call sget(), which

Re: General Question: ctime, mtime, and xattrs

On Fri, Dec 05, 2014 at 03:28:58PM -0800, Robert White wrote: Ah... I've been thinking ctime is/was (still) create time. It seems that somewhere in the last couple decades it became change time; Or that I picked up that incorrect create time idea back in the UNIX Sys V R 3 days and just

Re: [PATCH] btrfs: Don't check for file-private_data on open(). It is set by the core.

On Wed, Nov 12, 2014 at 07:34:50PM +0100, Martin Kepplinger wrote: Btrfs uses this in the transaction start ioctl to record the transaction handle being started. Ceph is the main user of the ioctl, and we could setup a hash table if needed. But which call path in miscdevice is doing

Re: Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags

On Tue, Sep 16, 2014 at 11:05:00PM -0400, Shea Levy wrote: Hi all, What work would be required to mark btrfs_fs_type with FS_USERNS_MOUNT so that btrfs images can be mounted by unprivileged users within a user namespace (along with something like [1])? I'd like to be able to create disk

Re: [RFC v3 0/2] vfs / btrfs: add support for ustat()

On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote: Christoph had noted that this seemed associated to the problem that the btrfs uses different assignments for st_dev than s_dev, but much as I'd like to see that changed based on discussions so far its unclear if this is going

[RFC] odd thing in btrfs_file_aio_write()

end_pos = round_up(pos + iov-iov_len, root-sectorsize); added in commit 3ac0d7b96a268a98bd474cab8bce3a9f125aaccf Author: Qu Wenruo quwen...@cn.fujitsu.com Date: Thu Mar 27 02:51:58 2014 + btrfs: Change the expanding write sequence to fix snapshot related bug. doesn't

Re: [RFC] odd thing in btrfs_file_aio_write()

On Mon, Apr 14, 2014 at 10:35:08AM +0800, Qu Wenruo wrote: Oh, that's my fault, I forgot that iov can be chained. I should use 'pos + count' instead. BTW, will there be any difference if 10Mb write starts one byte before EOF? IOW, is that if (start_pos i_size_read(inode)) { in there correct

Re: [RFC] odd thing in btrfs_file_aio_write()

On Mon, Apr 14, 2014 at 11:36:53AM +0800, Qu Wenruo wrote: IOW, is that if (start_pos i_size_read(inode)) { in there correct these days? And what'll happen if we hit e.g. an unmapped page in the middle of the data being written? That will result in short write, but will it truncate what's

Re: btrfs send 'leaks' open files

On Sun, Oct 20, 2013 at 11:33:56AM +0100, Phil Davis wrote: The reason I think btrfs send is leaking open files is if you watch /proc/sys/fs/file-nr you see the number of open files increasing but if you kill the btrfs send process then the open files count reduces back down. In fact

Re: btrfs send 'leaks' open files

On Tue, Oct 22, 2013 at 06:22:49PM +0100, Al Viro wrote: On Sun, Oct 20, 2013 at 11:33:56AM +0100, Phil Davis wrote: The reason I think btrfs send is leaking open files is if you watch /proc/sys/fs/file-nr you see the number of open files increasing but if you kill the btrfs send

Re: btrfs send 'leaks' open files

On Tue, Oct 22, 2013 at 06:22:49PM +0100, Al Viro wrote: On Sun, Oct 20, 2013 at 11:33:56AM +0100, Phil Davis wrote: The reason I think btrfs send is leaking open files is if you watch /proc/sys/fs/file-nr you see the number of open files increasing but if you kill the btrfs send

Re: [PATCH 2/4] fsfreeze: manage kill signal when sb_start_write is called

On Sat, Apr 06, 2013 at 12:04:52PM +0200, Marco Stornelli wrote: In every place where sb_start_write was called now we must manage the error code and return -EINTR. Now go and look for callers of mnt_want_write() ;-/ The really painful one is in do_last(), but kern_path_create() is not much

Re: [RESEND PATCH] fs/super.c set_anon_super calling optimization

On Fri, Oct 26, 2012 at 11:14:41AM -0200, Carlos Maiolino wrote: Hi, On Thu, Oct 25, 2012 at 05:08:19PM +0530, Abhijit Pawar wrote: Hi, set_anon_super is called by many filesystems. Some call directly and some call through the wrapper. Many of them in the wrapper's call to this

Re: [RESEND PATCH] fs/super.c set_anon_super calling optimization

On Fri, Nov 30, 2012 at 11:10:02AM +0530, Abhijit Pawar wrote: Because we want it to be a valid sget() callback. I doubt that this optimization is worth doing, though - might even micro-pessimize the things on architectures where all arguments are passed in registers. Al, Yes. it

Re: [patch 05/10] vfs: pass data to alloc_inode super operation

On Tue, Oct 30, 2012 at 04:14:39PM -0400, Jeff Moyer wrote: This patch passes a data pointer along to the alloc_inode super_operations function. The value will initially be used by bdev_alloc_inode to allocate the bdev_inode on the same numa node as the device to which it is tied. Yecchhh...

Re: [patch 05/10] vfs: pass data to alloc_inode super operation

On Tue, Oct 30, 2012 at 08:51:42PM +, Al Viro wrote: On Tue, Oct 30, 2012 at 04:14:39PM -0400, Jeff Moyer wrote: This patch passes a data pointer along to the alloc_inode super_operations function. The value will initially be used by bdev_alloc_inode to allocate the bdev_inode

Re: [PATCH 00/27 v6] Fix filesystem freezing deadlocks

On Sat, Jun 02, 2012 at 12:30:14AM +0200, Jan Kara wrote: Hello, here is the sixth iteration of my patches to improve filesystem freezing. The change since last iteration is that filesystem can be frozen with open but unlinked files. After some thinking, I've decided that the best way to

Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems

On Sat, Jun 09, 2012 at 01:14:46AM +0300, Kirill A. Shutemov wrote: The implementation would be less unpleasant if we could do the rcu_barrier() in kmem_cache_destroy(). I can't see a way of doing that without adding a dedicated slab flag, which would require editing all the filesystems

Re: [RFC, PATCH] fs: push rcu_barrier() from deactivate_locked_super() to filesystems

On Fri, Jun 08, 2012 at 03:06:20PM -0700, Linus Torvalds wrote: .. hmm. I think you may be right. Even if we do move it up, we probably shouldn't use it. We don't even want SLAB_DESTROY_BY_RCU, since we do the delayed RCU free for other reasons anyway, so it would duplicate the RCU delaying

Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems

On Fri, Jun 08, 2012 at 03:25:50PM -0700, Andrew Morton wrote: A neater implementation might be to add a kmem_cache* argument to unregister_filesystem(). If that is non-NULL, unregister_filesystem() does the rcu_barrier() and destroys the cache. That way we get to delete (rather than add) a

Re: [PATCH 1/2] Revert [PATCH] vfs: switch -show_devname() to struct dentry *

On Thu, May 31, 2012 at 06:25:11PM +0800, Miao Xie wrote: This reverts commit d861c630e99febe5ce6055290085556c5b714b06 It is done to fix the wrong mount information of btrfs in /proc. Btrfs is an interesting filesystem that can be made by several disks, and we can remove any disk from the

Re: [PATCH 2/2] Btrfs: fix wrong the mount information in /proc

On Thu, May 31, 2012 at 06:25:14PM +0800, Miao Xie wrote: +#include ../mount.h No. + struct mount *r = real_mount(mnt); And even more so. Find a way to do that without layering violations or live with the current behaviour. Both patches NAKed with extreme prejudice. Don't bring them

Re: [PATCH 2/2] Btrfs: fix wrong the mount information in /proc

On Thu, May 31, 2012 at 03:36:05PM +0100, Al Viro wrote: On Thu, May 31, 2012 at 06:25:14PM +0800, Miao Xie wrote: +#include ../mount.h No. + struct mount *r = real_mount(mnt); And even more so. Find a way to do that without layering violations or live with the current behaviour

Re: [RFC PATCH 1/2] vfs: add an interface to do some preparation for umount

On Thu, Mar 22, 2012 at 11:13:15AM +0800, Miao Xie wrote: Some file systems can do some works in the background by kthreads, we'd better stop those works before we umount the file system, or it is easy to introduce some problems. So we add an interface that is used to do some preparation for

Re: subvolume info in /proc/mounts

On Mon, Feb 06, 2012 at 07:18:24AM -0500, Christoph Hellwig wrote: On Mon, Feb 06, 2012 at 12:53:21PM +0100, David Sterba wrote: On Sun, Feb 05, 2012 at 12:30:42PM +0200, Nikos Voutsinas wrote: It's quite old, but what was this about;

Re: Possible btrfs deadlock coused by commit 660d3f6c

On Mon, Jan 16, 2012 at 09:26:00AM -0500, Josef Bacik wrote: On Mon, Jan 16, 2012 at 09:53:23AM +0100, Stanislaw Gruszka wrote: Hi Josef, commit 660d3f6cde552323578b85fc5a09a6742f1fe804 Author: Josef Bacik jo...@redhat.com Date: Fri Dec 9 11:18:51 2011 -0500 Btrfs: fix how

Re: [PATCH] BTRFS: Establish i_ops before calling d_instantiate

On Tue, Dec 06, 2011 at 04:39:50PM -0800, Casey Schaufler wrote: From: Casey Schaufler ca...@schaufler-ca.com The Smack LSM hook for security_d_instantiate checks the inode's i_op-getxattr value to determine if the [snip] + inode-i_op = btrfs_special_inode_operations; + err =

Re: [PATCH 2/2] Btrfs: fix deadlock on sb-s_umount when doing umount

+void btrfs_writeback_inodes_sb_nr(struct btrfs_root *root, + unsigned long nr_pages) +{ + struct super_block *sb = root-fs_info-sb; + + if (writeback_in_progress(sb-s_bdi)) + return; + + /* + * If we can not get s_umount, it

Re: [PATCH] Btrfs: fix num_start_workers count if we fail to make an alloc

On Fri, Nov 18, 2011 at 02:38:54PM -0500, Josef Bacik wrote: Al pointed out that if we fail to start a worker for whatever reason (ENOMEM basically), we could leak our count for num_start_workers, and so we'd think we had more workers than we actually do. This could cause us to shrink

Re: [PATCH] Btrfs: fix num_start_workers count if we fail to make an alloc

On Fri, Nov 18, 2011 at 08:20:56PM +, Al Viro wrote: On Fri, Nov 18, 2011 at 02:38:54PM -0500, Josef Bacik wrote: Al pointed out that if we fail to start a worker for whatever reason (ENOMEM basically), we could leak our count for num_start_workers, and so we'd think we had more

Re: [PATCH] Btrfs: fix num_start_workers count if we fail to make an alloc

On Sat, Nov 19, 2011 at 01:37:39AM +, Al Viro wrote: On Fri, Nov 18, 2011 at 08:20:56PM +, Al Viro wrote: On Fri, Nov 18, 2011 at 02:38:54PM -0500, Josef Bacik wrote: Al pointed out that if we fail to start a worker for whatever reason (ENOMEM basically), we could leak our

Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation

On Wed, Dec 08, 2010 at 02:45:27PM -0500, Eric Paris wrote: SELinux would like to implement a new labeling behavior of newly created inodes. We currently label new inodes based on the parent and the creating process. This new behavior would also take into account the name of the new object

Re: [PATCH 1/2] fs: add a DCACHE_NEED_LOOKUP flag for d_flags V2

On Mon, May 23, 2011 at 12:13:07PM -0400, Josef Bacik wrote: On 05/21/2011 10:11 PM, Al Viro wrote: On Fri, May 20, 2011 at 01:44:30PM -0400, Josef Bacik wrote: + if (unlikely(d_need_lookup(dentry))) { + if (nameidata_dentry_drop_rcu(nd, dentry

Re: [PATCH 1/2] fs: add a DCACHE_NEED_LOOKUP flag for d_flags V2

On Fri, May 20, 2011 at 01:44:30PM -0400, Josef Bacik wrote: + if (unlikely(d_need_lookup(dentry))) { + if (nameidata_dentry_drop_rcu(nd, dentry)) + return -ECHILD; + dput(dentry); + dentry =

Re: [RFC] a couple of i_nlink fixes in btrfs

On Mon, Mar 07, 2011 at 11:58:13AM -0500, Chris Mason wrote: Thanks, these both look good but I'll test here as well. Are you planning on pushing for .38? No, but .39 would be nice ;-) Do you want that to go through btrfs tree or through vfs one? -- To unsubscribe from this list: send the

[RFC] a couple of i_nlink fixes in btrfs

a) rename() plays with i_nlink of old_inode; bad, since it's not locked. I'd add a variant of btrfs_unlink_inode() that would leave btrfs_drop_nlink()/btrfs_update_inode() to callers and use it instead. b) btrfs_link() doesn't check for i_nlink overflows. I don't know if there's

[PATCH 1/2] btrfs: don't mess with i_nlink of unlocked inode in rename()

() ourselves. Signed-off-by: Al Viro v...@zeniv.linux.org.uk --- fs/btrfs/inode.c | 36 +--- 1 files changed, 25 insertions(+), 11 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 0efdb65..099d64c 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs

[PATCH 2/2] btrfs: check link counter overflow in link(2)

Signed-off-by: Al Viro v...@zeniv.linux.org.uk --- fs/btrfs/inode.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 099d64c..8a6df03 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4826,6 +4826,9 @@ static int

Re: [patch] fix up lock order reversal in writeback

On Wed, Nov 17, 2010 at 10:06:13PM -0500, Ted Ts'o wrote: This makes sense to me as well. Acked-by: Theodore Ts'o ty...@mit.edu So how do we want to send this patch to Linus? It's a writeback change, so through some mm tree? Or it lives in fs/fs-writeback.c (which I always thought was

Re: [patch 5/11] btrfs: remove unneeded null check in btrfs_rename()

On Sat, May 29, 2010 at 11:01:56AM -0700, Mike Fedyk wrote: I think code like this is here because there are still a lot of features that are being added to btrfs and it's easier to have the additional checks than continually adding and removing them as the code changes. _What_ features?

Re: Cleancache [PATCH 2/7] (was Transcendent Memory): core files

On Thu, Apr 22, 2010 at 06:28:09AM -0700, Dan Magenheimer wrote: +struct cleancache_ops { + int (*init_fs)(unsigned long); unsigned long? Really? Not even size_t? + int (*init_shared_fs)(char *uuid, unsigned long); Ditto. + int (*get_page)(int, unsigned long, unsigned long,