On Mon, Nov 21, 2016 at 12:16 PM, Miklos Szeredi wrote:
> On Mon, Nov 21, 2016 at 11:13 AM, Amir Goldstein wrote:
>> On Mon, Nov 21, 2016 at 11:54 AM, Miklos Szeredi wrote:
>>> On Fri, Nov 18, 2016 at 4:37 PM, Amir Goldstein wrote:
>>>
Found one typo and one bug in error that can cause cra
On Mon, Nov 21, 2016 at 11:13 AM, Amir Goldstein wrote:
> On Mon, Nov 21, 2016 at 11:54 AM, Miklos Szeredi wrote:
>> On Fri, Nov 18, 2016 at 4:37 PM, Amir Goldstein wrote:
>>
>>> Found one typo and one bug in error that can cause crash on
>>> dput(ERR_PTR(err)):
>>
>> Thanks.
>>
>> Fixes force
On Mon, Nov 21, 2016 at 11:54 AM, Miklos Szeredi wrote:
> On Fri, Nov 18, 2016 at 4:37 PM, Amir Goldstein wrote:
>
>> Found one typo and one bug in error that can cause crash on
>> dput(ERR_PTR(err)):
>
> Thanks.
>
> Fixes force pushed to overlayfs-next.
All right. I had the (wrong) impression
On Fri, Nov 18, 2016 at 4:37 PM, Amir Goldstein wrote:
> Found one typo and one bug in error that can cause crash on
> dput(ERR_PTR(err)):
Thanks.
Fixes force pushed to overlayfs-next.
Also pushed the redirect patches to overlayfs-next, as they seem to
have matured enough.
Thanks,
Miklos
On Fri, Nov 18, 2016 at 5:37 PM, Amir Goldstein wrote:
> On Thu, Nov 17, 2016 at 12:00 AM, Miklos Szeredi wrote:
>>
>> On Mon, Nov 14, 2016 at 5:25 PM, Amir Goldstein wrote:
>> > On Sun, Nov 13, 2016 at 12:00 PM, Amir Goldstein
>> > wrote:
>>
>> >> Looks goods, except for the case of change fr
On Thu, Nov 17, 2016 at 12:00 AM, Miklos Szeredi wrote:
>
> On Mon, Nov 14, 2016 at 5:25 PM, Amir Goldstein wrote:
> > On Sun, Nov 13, 2016 at 12:00 PM, Amir Goldstein wrote:
>
> >> Looks goods, except for the case of change from relative to absolute
> >> redirect of the victim dentry. IIUC, ovl
On Mon, Nov 14, 2016 at 5:25 PM, Amir Goldstein wrote:
> On Sun, Nov 13, 2016 at 12:00 PM, Amir Goldstein wrote:
>> Looks goods, except for the case of change from relative to absolute
>> redirect of the victim dentry. IIUC, ovl_set_redirect() will return
>> immediately
>> because ovl_dentry_is
On Sun, Nov 13, 2016 at 12:00 PM, Amir Goldstein wrote:
> On Fri, Nov 11, 2016 at 12:39 AM, Miklos Szeredi wrote:
>> New version is at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git #redirect
>>
>> News:
>> - it actually should work in all cases
>> - when rename is not cros
On Fri, Nov 11, 2016 at 12:39 AM, Miklos Szeredi wrote:
> New version is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git #redirect
>
> News:
> - it actually should work in all cases
> - when rename is not cross directory, just store the new name instead
> of a full path, as
On Fri, Nov 11, 2016 at 2:42 PM, Amir Goldstein wrote:
> On Fri, Nov 11, 2016 at 12:06 PM, Miklos Szeredi wrote:
>> On Fri, Nov 11, 2016 at 10:46 AM, Konstantin Khlebnikov
>> wrote:
>>> On Fri, Nov 11, 2016 at 1:56 AM, Amir Goldstein wrote:
On Mon, Nov 7, 2016 at 3:38 PM, Amir Goldstein w
On Fri, Nov 11, 2016 at 12:06 PM, Miklos Szeredi wrote:
> On Fri, Nov 11, 2016 at 10:46 AM, Konstantin Khlebnikov
> wrote:
>> On Fri, Nov 11, 2016 at 1:56 AM, Amir Goldstein wrote:
>>> On Mon, Nov 7, 2016 at 3:38 PM, Amir Goldstein wrote:
On Mon, Nov 7, 2016 at 12:08 PM, Konstantin Khlebni
On Fri, Nov 11, 2016 at 10:46 AM, Konstantin Khlebnikov
wrote:
> On Fri, Nov 11, 2016 at 1:56 AM, Amir Goldstein wrote:
>> On Mon, Nov 7, 2016 at 3:38 PM, Amir Goldstein wrote:
>>> On Mon, Nov 7, 2016 at 12:08 PM, Konstantin Khlebnikov
>>> wrote:
On Mon, Nov 7, 2016 at 1:04 PM, Miklos Sze
On Fri, Nov 11, 2016 at 1:56 AM, Amir Goldstein wrote:
> On Mon, Nov 7, 2016 at 3:38 PM, Amir Goldstein wrote:
>> On Mon, Nov 7, 2016 at 12:08 PM, Konstantin Khlebnikov
>> wrote:
>>> On Mon, Nov 7, 2016 at 1:04 PM, Miklos Szeredi wrote:
On Mon, Nov 7, 2016 at 10:58 AM, Konstantin Khlebnik
On Fri, Nov 11, 2016 at 1:39 AM, Miklos Szeredi wrote:
> New version is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git #redirect
>
> News:
> - it actually should work in all cases
> - when rename is not cross directory, just store the new name instead
> of a full path, as s
On Mon, Nov 7, 2016 at 3:38 PM, Amir Goldstein wrote:
> On Mon, Nov 7, 2016 at 12:08 PM, Konstantin Khlebnikov
> wrote:
>> On Mon, Nov 7, 2016 at 1:04 PM, Miklos Szeredi wrote:
>>> On Mon, Nov 7, 2016 at 10:58 AM, Konstantin Khlebnikov
>>> wrote:
>>>
I've stumbled on somehow related prob
New version is at:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git #redirect
News:
- it actually should work in all cases
- when rename is not cross directory, just store the new name instead
of a full path, as suggested by Amir
- when redirect path is too long fall back to EXDEV (
On Mon, Nov 7, 2016 at 12:08 PM, Konstantin Khlebnikov wrote:
> On Mon, Nov 7, 2016 at 1:04 PM, Miklos Szeredi wrote:
>> On Mon, Nov 7, 2016 at 10:58 AM, Konstantin Khlebnikov
>> wrote:
>>
>>> I've stumbled on somehow related problem - concurrent copy-ups are
>>> strictly serialized by rename l
On Mon, 07 Nov 2016, Konstantin Khlebnikov wrote:
> > Why? (I don't have the feeling that your subsequent paragraphs answer this
> > question... unless "overlayfs mounting is hard, let's complicate it even
> > more" is your answer)
>
> Mixing flags from mount options, xattrs and emptiness of upper
On Mon, Nov 7, 2016 at 2:03 PM, Raphael Hertzog wrote:
> Hello,
>
> On Sun, 06 Nov 2016, Konstantin Khlebnikov wrote:
>> > - If upper is nonempty, then leave redirect feature alone except when
>> > mount option "-oredirect=on" is used to force enabling it.
>> > - If upper is empty, then enable red
Hello,
On Sun, 06 Nov 2016, Konstantin Khlebnikov wrote:
> > - If upper is nonempty, then leave redirect feature alone except when
> > mount option "-oredirect=on" is used to force enabling it.
> > - If upper is empty, then enable redirect feature except when mount
> > option "-oredirect=off" is u
On Mon, Nov 7, 2016 at 1:04 PM, Miklos Szeredi wrote:
> On Mon, Nov 7, 2016 at 10:58 AM, Konstantin Khlebnikov
> wrote:
>
>> I've stumbled on somehow related problem - concurrent copy-ups are
>> strictly serialized by rename locks.
>> Obviously, file copying could be done in parallel: locks are
On Mon, Nov 7, 2016 at 10:58 AM, Konstantin Khlebnikov wrote:
> I've stumbled on somehow related problem - concurrent copy-ups are
> strictly serialized by rename locks.
> Obviously, file copying could be done in parallel: locks are required
> only for final rename.
> Because of that overlay slow
On Mon, Nov 7, 2016 at 11:07 AM, Miklos Szeredi wrote:
> On Sun, Nov 6, 2016 at 8:14 PM, Konstantin Khlebnikov
> wrote:
>> On Wed, Oct 26, 2016 at 2:12 PM, Miklos Szeredi wrote:
>>> On Tue, Oct 25, 2016 at 1:57 PM, Raphael Hertzog wrote:
>>>
Do you plan to make it the default in the futur
On Sun, Nov 6, 2016 at 8:14 PM, Konstantin Khlebnikov wrote:
> On Wed, Oct 26, 2016 at 2:12 PM, Miklos Szeredi wrote:
>> On Tue, Oct 25, 2016 at 1:57 PM, Raphael Hertzog wrote:
>>
>>> Do you plan to make it the default in the future when it has been
>>> available for a while?
>>>
>>> Barring any
On Wed, Oct 26, 2016 at 2:12 PM, Miklos Szeredi wrote:
> On Tue, Oct 25, 2016 at 1:57 PM, Raphael Hertzog wrote:
>
>> Do you plan to make it the default in the future when it has been
>> available for a while?
>>
>> Barring any regression introduced by your patch, it seems that the feature
>> is
On Fri, Nov 4, 2016 at 10:29 AM, Amir Goldstein wrote:
> You did not address my comment about the 'stack' allocation overflow
> in ovl_lookup
> I believe the (possible) overflow is demonstrated by the following debug
> patch:
Oops, missed that. Good spotting!
And there's more shit that unionf
On Thu, Nov 3, 2016 at 5:50 PM, Miklos Szeredi wrote:
> On Fri, Oct 28, 2016 at 6:15 PM, Al Viro wrote:
>> On Tue, Oct 25, 2016 at 09:34:47AM +0200, Miklos Szeredi wrote:
...
>>
>> I'm not sure if vfs_path_lookup() is the right tool here. It might be
>> usable for making such a tool, but as it i
On Fri, Oct 28, 2016 at 6:15 PM, Al Viro wrote:
> On Tue, Oct 25, 2016 at 09:34:47AM +0200, Miklos Szeredi wrote:
>> Current code returns EXDEV when a directory would need to be copied up to
>> move. We could copy up the directory tree in this case, but there's
>> another solution: point to old l
On Tue, Oct 25, 2016 at 09:34:47AM +0200, Miklos Szeredi wrote:
> Current code returns EXDEV when a directory would need to be copied up to
> move. We could copy up the directory tree in this case, but there's
> another solution: point to old lower directory from moved upper directory.
>
> This i
On Fri, Oct 28, 2016 at 2:56 PM, Raphael Hertzog wrote:
> Hi,
>
> On Wed, 26 Oct 2016, Miklos Szeredi wrote:
>> On Tue, Oct 25, 2016 at 1:57 PM, Raphael Hertzog wrote:
>
> [ redirect feature enabled by default ]
>
>> I think it would be safe to make it the default if upperdir is empty.
>> Nonempt
Hi,
On Wed, 26 Oct 2016, Miklos Szeredi wrote:
> On Tue, Oct 25, 2016 at 1:57 PM, Raphael Hertzog wrote:
[ redirect feature enabled by default ]
> I think it would be safe to make it the default if upperdir is empty.
> Nonempty implies that it was created with old kernel (or it was
> crafted by
On Wed, Oct 26, 2016 at 2:26 PM, Miklos Szeredi wrote:
> On Tue, Oct 25, 2016 at 2:49 PM, Amir Goldstein wrote:
>
>>> @@ -880,31 +913,34 @@ static int ovl_rename(struct inode *olddir, struct
>>> dentry *old,
>>> if (WARN_ON(olddentry->d_inode == newdentry->d_inode))
>>> g
On Wed, Oct 26, 2016 at 2:11 PM, Amir Goldstein wrote:
> On Wed, Oct 26, 2016 at 2:26 PM, Miklos Szeredi wrote:
>> On Tue, Oct 25, 2016 at 2:49 PM, Amir Goldstein wrote:
>>
@@ -880,31 +913,34 @@ static int ovl_rename(struct inode *olddir, struct
dentry *old,
if (WARN_ON(o
On Wed, Oct 26, 2016 at 2:26 PM, Miklos Szeredi wrote:
> On Tue, Oct 25, 2016 at 2:49 PM, Amir Goldstein wrote:
>
>>> @@ -880,31 +913,34 @@ static int ovl_rename(struct inode *olddir, struct
>>> dentry *old,
>>> if (WARN_ON(olddentry->d_inode == newdentry->d_inode))
>>> g
On Tue, Oct 25, 2016 at 2:49 PM, Amir Goldstein wrote:
>> @@ -880,31 +913,34 @@ static int ovl_rename(struct inode *olddir, struct
>> dentry *old,
>> if (WARN_ON(olddentry->d_inode == newdentry->d_inode))
>> goto out_dput;
>>
>> - if (is_dir && !old_opaque && ovl_lo
On Tue, Oct 25, 2016 at 1:57 PM, Raphael Hertzog wrote:
> Do you plan to make it the default in the future when it has been
> available for a while?
>
> Barring any regression introduced by your patch, it seems that the feature
> is best available by default since it allows legitimate operations
On Tue, Oct 25, 2016 at 10:34 AM, Miklos Szeredi wrote:
> Current code returns EXDEV when a directory would need to be copied up to
> move. We could copy up the directory tree in this case, but there's
> another solution: point to old lower directory from moved upper directory.
>
> This is achiev
Hello Miklos,
thanks for your work on this patch set!
On Tue, 25 Oct 2016, Miklos Szeredi wrote:
> +renaming directories
> +
> +
> +When renaming a directory that is on the lower layer or merged (i.e. the
> +directory was not created on the upper layer to start with) overlayfs
Current code returns EXDEV when a directory would need to be copied up to
move. We could copy up the directory tree in this case, but there's
another solution: point to old lower directory from moved upper directory.
This is achieved with a "trusted.overlay.redirect" xattr storing the path
relati
39 matches
Mail list logo