[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegv3TxLbp9TsbXaPdjCFmVDKpvx2y0phSCfjd3B1jcgx4w@mail.gmail.com>
Date: Thu, 6 Oct 2016 10:01:35 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
"linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>
Subject: Re: [GIT PULL] overlayfs update for 4.9
On Thu, Oct 6, 2016 at 1:49 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Wed, Oct 05, 2016 at 09:52:10PM +0200, Miklos Szeredi wrote:
>> Hi Al,
>>
>> Please pull from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-viro
>>
>> This has an assortment of fixes and cleanups for overlayfs.
>>
>> It also touches the VFS:
>>
>> - add the vfs_get_link() helper for calling i_op->get_link();
>> - fix mnt_want_write_file() to freeze protect the underlying sb instead of
>> overlay sb;
>> - allow vfs_clone_file_range() to be called by overlayfs.
>
> Could you explain why e.g. fsetxattr() needs a different treatment in
> "vfs: mnt_want_write_file() should freeze protect underlying sb"?
Because setxattr is an i_op, not a f_op, so it's overlayfs that's
going to be called and will do the freeze protect on underlying layer
(not to mention, that it might be a different underlying sb that will
get the freeze protection in the end, due to copy up)
Thanks,
Miklos
Powered by blists - more mailing lists