On Fri, Apr 09, 2021 at 01:12:52PM +0200, Ondrej Mosnacek wrote:
> This series attempts to clean up part of the mess that has grown around
> the LSM mount option handling across different subsystems.
I would not describe growing another FS_... flag *AND* spreading the
FS_BINARY_MOUNTDATA further,
On Tue, Mar 16, 2021 at 02:21:45PM -0400, Paul Moore wrote:
> On Tue, Mar 16, 2021 at 10:48 AM Ondrej Mosnacek wrote:
> >
> > When SELinux security options are passed to btrfs via fsconfig(2) rather
> > than via mount(2), the operation aborts with an error. What happens is
> > roughly this sequenc
On Sat, Jan 23, 2021 at 03:50:55PM -0800, Andres Freund wrote:
> As there's only a shared lock, seems like both would end up with the
> same ctx->pos and end up updating f_pos to the same offset (assuming the
> same count).
>
> Am I missing something?
This:
f = fdget_pos(fd);
if
On Tue, Sep 24, 2019 at 09:55:06AM -0700, Linus Torvalds wrote:
> [ Sorry for html, I'm driving around ]
>
> On Mon, Sep 23, 2019, 19:52 Al Viro wrote:
>
> >
> > Argh... The things turned interesting. The tricky part is
> > where do we handle switching c
On Tue, Sep 24, 2019 at 11:26:28AM -0400, Josef Bacik wrote:
> On Tue, Sep 24, 2019 at 04:11:07PM +0100, Al Viro wrote:
> > On Tue, Sep 24, 2019 at 11:01:45AM -0400, Josef Bacik wrote:
> >
> > > Sorry I mis-read the code a little bit. This is purely for t
On Tue, Sep 24, 2019 at 11:01:45AM -0400, Josef Bacik wrote:
> Sorry I mis-read the code a little bit. This is purely for the subvolume link
> directories. We haven't wandered down into this directory yet. If the
> subvolume is being deleted and we still have the fake directory entry for it
> t
On Tue, Sep 24, 2019 at 09:30:26AM -0400, Josef Bacik wrote:
> > We pass next->d_name.name to dir_emit() (i.e. potentially to
> > copy_to_user()). And we have no warranty that it's not a long
> > (== separately allocated) name, that will be freed while
> > copy_to_user() is in progress. Sure, it
[btrfs and cifs folks Cc'd]
On Sat, Sep 21, 2019 at 03:07:31PM +0100, Al Viro wrote:
> No "take cursors out of the list" parts yet.
Argh... The things turned interesting. The tricky part is
where do we handle switching cursors away from something
that gets moved.
What I h
On Tue, Jun 25, 2019 at 07:33:31PM -0700, Darrick J. Wong wrote:
> --- a/fs/attr.c
> +++ b/fs/attr.c
> @@ -236,6 +236,9 @@ int notify_change(struct dentry * dentry, struct iattr *
> attr, struct inode **de
> if (IS_IMMUTABLE(inode))
> return -EPERM;
>
> + if (IS_SWAPFILE(
On Fri, Feb 15, 2019 at 02:39:25PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> d_tmpfile was introduced to instantiate an inode in the dentry cache as
> a temporary file. This helper decrements the inode's nlink count and
> dirties the inode, presumably so that filesystems could ca
alloc_fs_devices() can return ERR_PTR(-ENOMEM), so
dereferencing its result before the check for IS_ERR() is
a bad idea...
Fixes: d1a63002829a4
Signed-off-by: Al Viro
---
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 85149f27644d..72adc5643bde 100644
--- a/fs/btrfs/volumes.c
On Thu, Nov 22, 2018 at 02:40:50PM +0900, Eiichi Tsukata wrote:
> 2018年11月21日(水) 13:54 Al Viro :
> >
> > On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote:
> > > Some file systems (including ext4, xfs, ramfs ...) have the following
> > > problem as I&#
On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote:
> Some file systems (including ext4, xfs, ramfs ...) have the following
> problem as I've described in the commit message of the 1/4 patch.
>
> The commit ef3d0fd27e90 ("vfs: do (nearly) lockless generic_file_llseek")
> removed al
On Mon, Oct 22, 2018 at 03:37:41PM +1100, Dave Chinner wrote:
> Ok, this is a bit of a mess. the patches do not merge cleanly to a
> 4.19-rc1 base kernel because of all the changes to
> include/linux/fs.h that have hit the tree after this. There's also
> failures against Documentation/filesystems/
On Wed, Oct 17, 2018 at 09:47:18PM -0700, Darrick J. Wong wrote:
> > > +#define REMAP_FILE_DEDUP (1 << 0)
> > > +
> > > +/*
> > > + * These flags should be taken care of by the implementation (possibly
> > > using
> > > + * vfs helpers) but can be ignored by the implementation.
> > > + */
On Wed, Oct 17, 2018 at 03:45:17PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Combine the clone_file_range and dedupe_file_range operations into a
> single remap_file_range file operation dispatch since they're
> fundamentally the same operation. The differences between the two ca
On Wed, Oct 17, 2018 at 03:44:43PM -0700, Darrick J. Wong wrote:
> +static int generic_access_check_limits(struct file *file, loff_t pos,
> +loff_t *count)
> +{
> + struct inode *inode = file->f_mapping->host;
> +
> + /* Don't exceed the LFS limits. */
>
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 always have
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 majord...@vger.ker
_dentry_delete() does.
Signed-off-by: Al Viro
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)
return 0;
}
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,
> >
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,
> - dio_submit
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.
>
> Signed-off
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
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 p
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 Uecker */
> > #define __is_const
On Fri, Mar 16, 2018 at 01:15:27PM -0700, Linus Torvalds wrote:
> On Fri, Mar 16, 2018 at 1:12 PM, Al Viro wrote:
> >
> > That's C99, straight from N1256.pdf (C99-TC3)...
>
> I checked C90, since the error is
>
>ISO C90 forbids variable length array
>
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 pres
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
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. 1,
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
> capabil
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.
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 while performing
> direc
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 corruptio
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]
>
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 no
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 pip
one
> ref to dchild in nfsd_create(), but with the creation of nfsd_create_locked()
> we
> have a ref for dchild from the lookup in nfsd_create(), and then another ref
> in
> nfsd_create_locked(). The ref from the lookup in nfsd_create() is never
> dropped
> and results in
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
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
> > shoul
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 pa
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 us
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 "
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.
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 woul
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(&unnamed_dev_ida, GFP_ATOMIC) == 0)
Because set() callback of sget() runs under sb_lock - it must be atomic
wrt scanning the list of superbl
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
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 selection
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
> v
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 mandat
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 can't
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)
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 wrote:
> >
> > > Missing patch 2 of the 3-patch series?
> >
> > Yes. :-)
> >
> > Do ext4 and xfs support this, do you know?
>
> Yes. As do f2fs, oc
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
t
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 c
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. A
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)
> +{
> + retu
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(),
On Fri, Jan 30, 2015 at 12:14:24PM +0800, Miao Xie wrote:
> On Fri, 30 Jan 2015 02:14:45 +0000, 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?
> >
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.
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 --bin
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
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
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
> > do
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
> dis
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 goi
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
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 corre
end_pos = round_up(pos + iov->iov_len, root->sectorsize);
added in commit 3ac0d7b96a268a98bd474cab8bce3a9f125aaccf
Author: Qu Wenruo
Date: Thu Mar 27 02:51:58 2014 +
btrfs: Change the expanding write sequence to fix snapshot related bug.
doesn't look right - after all,
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
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
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 s
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
b
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,
>
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
> > th
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 al
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
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 wa
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
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 delay
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 filesy
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 withou
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
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 th
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 fo
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;
> > >
> > > http://thread.gmane.org/gmane.comp.file
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
> > Date: Fri Dec 9 11:18:51 2011 -0500
> >
> > Btrfs: fix how we
On Tue, Dec 06, 2011 at 04:39:50PM -0800, Casey Schaufler wrote:
> From: Casey Schaufler
>
> 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 = btrfs_add_nondi
> +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_u
On Sat, Nov 19, 2011 at 01:37:39AM +, Al Viro wrote:
> On Fri, Nov 18, 2011 at 08:20:56PM +0000, 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
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
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 wor
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 objec
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
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
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 l
Signed-off-by: Al Viro
---
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 btrfs_link(struct dentry
inode() ourselves.
Signed-off-by: Al Viro
---
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/inode.c
@@ -26
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 a
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"
>
> 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 weird
1 - 100 of 104 matches
Mail list logo
