On Wed, Jul 23, 2014 at 1:40 PM, Klaus Kreil wrote:
> >
>> Is there some hint in the dmesg output?
>>
> The messag from dmesg reads as follows:
> [1.323319] overlayfs: failed to resolve '/.work': -2
>
> Now that I find strange because an ls -la /mnt/root_rw from the emergency
> shell started f
On Wed, Jul 23, 2014 at 1:48 PM, Miklos Szeredi wrote:
> On Wed, Jul 23, 2014 at 1:40 PM, Klaus Kreil wrote:
>> >
>>> Is there some hint in the dmesg output?
>>>
>> The messag from dmesg reads as follows:
>> [1.323319] overlayfs: failed to resol
On Wed, Jul 23, 2014 at 1:57 PM, Klaus Kreil wrote:
>> You need to give absolute paths:
>>
>> mount -t overlayfs overlayfs -o
>> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw/upper,workdir=/mnt/root_rw/work
>> /mnt/root
>>
> Thanks Miklos,
> I had tried that before, but that did not/does not work a
On Wed, Jul 23, 2014 at 2:15 PM, Klaus Kreil wrote:
> On Mi, 23.07.2014, 14:02, Miklos Szeredi wrote:
>> On Wed, Jul 23, 2014 at 1:57 PM, Klaus Kreil
>> wrote:
>>
>>>> You need to give absolute paths:
>>>>
>>>> mount -t overlayfs over
On Thu, Jul 24, 2014 at 5:30 PM, Christoph Hellwig wrote:
> If there's anything else for 3.17 please send it my way.
(linux-unionfs CC-d)
overlayfs? I think it's mature enough, but I thought that a year ago,
and there's been a format change since then... So how do people feel?
Thanks,
Miklos
On Mon, Aug 11, 2014 at 4:37 PM, David Howells wrote:
> In the for-loop in the middle, if you ascend any levels at all, how are you
> protected from racing with copy-ups taking place on those more rootwards
> dentries?
>
> I can see ovl_copy_up_one() using lock_rename() on the workdir and upperdi
ok (1):
overlayfs: implement show_options
Miklos Szeredi (11):
vfs: add i_op->dentry_open()
vfs: export do_splice_direct() to modules
vfs: export __inode_permission() to modules
vfs: introduce clone_private_mount()
vfs: export check_sticky()
vfs: add whiteout
On Tue, Sep 30, 2014 at 6:54 AM, J. R. Okajima wrote:
>
> David Howells:
>> Miklos Szeredi wrote:
>>
>> > I'd like to propose overlayfs for inclusion into 3.18.
>> >
>> > Al, would you mind giving it a review?
>> >
>> > Git tre
iklos
---
Andy Whitcroft (1):
overlayfs: add statfs support
Erez Zadok (1):
overlayfs: implement show_options
Miklos Szeredi (11):
vfs: add i_op->dentry_open()
vfs: export do_splice_direct() to modules
vfs: export __inode_permission() to modules
vfs: i
On Fri, Oct 24, 2014 at 5:24 AM, Al Viro wrote:
> On Fri, Oct 24, 2014 at 03:20:55AM +0100, Al Viro wrote:
>> Why the hell do you hold ->i_mutex across the entire opening of underlying
>> directory? All you need is to serialize one assignment; the side that loses
>> the race will simply fput() wh
On Sat, Oct 25, 2014 at 10:18 AM, Al Viro wrote:
> On Fri, Oct 24, 2014 at 09:24:45AM +0200, Miklos Szeredi wrote:
>
>> The reason I didn't do your "fix" is that it
>>
>> - adds more lines than it takes,
>>
>> - I wasn't sure at all i
[Paul McKenney added to CC]
On Sat, Oct 25, 2014 at 7:06 PM, Al Viro wrote:
> On Sat, Oct 25, 2014 at 11:53:52AM +0200, Miklos Szeredi wrote:
>
>> Yes, but it's not about race with copy-up (which the ovl_path_upper()
>> protects against), but race of two fsync cal
ovl_cache_entry.name is now an array not a pointer, so it makes no sense
test for it being NULL.
Detected by coverity.
From: Miklos Szeredi
Fixes: 68bf8611076a ("overlayfs: make ovl_cache_entry->name an array instead of
pointer")
Signed-off-by: Miklos Szeredi
---
fs/overla
D'oh, I must remember to review own patches *before* sending them, not after...
Here's an updated one.
Thanks,
Miklos
---
Subject: ovl: fix check for cursor
From: Miklos Szeredi
ovl_cache_entry.name is now an array not a pointer, so it makes no sense
test for it being NULL.
D
On Mon, Oct 27, 2014 at 02:05:18PM +, David Howells wrote:
> Using my testsuite, I see the attached moan from lockdep. Unfortunately, it
> doesn't cause the testsuite to actually fail, so I'm going to have to manually
> try and isolate the failing test.
>
> David
>
>
On Mon, Oct 27, 2014 at 02:39:21PM +, David Howells wrote:
> Miklos Szeredi wrote:
>
> > Uh-oh. We changed nesting late in the cycle and I didn't retest with
> > lockdep.
> >
> > And it's actually harmless, but AFAICS needs another level of ne
On Thu, Oct 30, 2014 at 3:10 PM, David Howells wrote:
> ovl_fill_merge() effectively directly casts the buf pointer to an
> ovl_readdir_data struct pointer, but the pointer actually points to the
> dir_context struct contained therein.
>
> So use container_of() instead.
>
> Signed-off-by: David Ho
On Thu, Oct 30, 2014 at 02:47:06PM +, David Howells wrote:
> Miklos Szeredi wrote:
>
> > Okay, but why don't we have a typed argument of actor then?
>
> You should ask that one to Al.
Subject: vfs: make first argument of dir_context.actor typed
From: Miklos Szeredi
From: Miklos Szeredi
Reported-by: David Howells
Signed-off-by: Miklos Szeredi
---
Here's one that actually compiles... My only excuse for last night's one is the
general chaos after my 2 year old drank an unknown amount of rum (he's all
right, apparently he had the sense
From: Miklos Szeredi
Signed-off-by: Miklos Szeredi
---
This goes on top of "ovl: fix check for cursor".
fs/overlayfs/readdir.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -93,6 +93,7 @@ static struct ovl_cache_entry
tp://jordipujol.ddns.net/debian/testing-overlayfs-3.18-rc3/
Thanks for the report. Could you please try the following patch, which should
fix the Oops.
Thanks,
Miklos
---
Subject: ovl: don't poison cursor
From: Miklos Szeredi
ovl_cache_put() can be called from ovl_dir_reset() if the cache
Apparently this is the top feature request, and is relateively easy to do.
This is the first iteration of the patch, and quite possibly buggy. Testing
and review is welcome.
Usage: -olowerdirs=/top:/middle:/bottom...
Now the upperdir and workdir options can be omitted to get a read-only overlay
Thanks to everyone for testing.
Here's an updated patch to fix the statfs Oops.
Maybe it wasn't clear, but the number of lower layers isn't limited by
FILESYSTEM_MAX_STACK_DEPTH, only by the max size of the mount option buffer in
the kernel (1 page, usually 4096bytes). So you could have a hundre
Hi Stephen,
Could you please add the following branch to -next:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kernel.org
More ma
On Thu, Nov 13, 2014 at 10:35 AM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> Could you please add the following branch to -next:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
>> overlayfs-next
>
> Did you mean the branch
On Fri, Nov 14, 2014 at 9:55 AM, Jordi Pujol Palomer
wrote:
> EL Mon, 10 Nov 2014 10:09:54 +0100
> Miklos Szeredi escrigué:
>
>> Maybe it wasn't clear, but the number of lower layers isn't limited by
>> FILESYSTEM_MAX_STACK_DEPTH,
> sorry, you have been clear, i
[CC-ing mailing lists, Al and Linus for wider exposure]
This issue is this: Ubuntu and SUSE carry an "old" format of overlayfs
while mainline has a "new" format. The differences are:
- whiteouts are represented differently (symlink + xattr in the old
format, chardev in the new)
- new one need
On Wed, Nov 19, 2014 at 2:59 AM, Al Viro wrote:
> On Tue, Nov 18, 2014 at 03:28:03PM +0100, Miklos Szeredi wrote:
>
>> So from mainline we need two things:
>>
>> - when mounting distinguish between old and new format.
>>
>> - userspace can detect which
On Tue, Nov 18, 2014 at 03:28:03PM +0100, Miklos Szeredi wrote:
> If we'd have a different filesystem type for the old and new formats,
> then that would solve both (checking /proc/filesystems would indicate
> which one is supported).
>
> Unfortunately that would mean having
ine one. Also fix a couple of copy-up races and allow escaping comma
character in filenames.
Thanks,
Miklos
---
Miklos Szeredi (8):
ovl: rename filesystem type to "overlay"
ovl: fix remove/copy-up race
ovl: fix race in private xattr checks
ovl: allow filen
chset if someone wants that).
Thanks,
Miklos
---
Miklos Szeredi (12):
ovl: check whiteout while reading directory
ovl: make path-type a bitmap
ovl: dont replace opaque dir
ovl: add mutli-layer infrastructure
ovl: helper to iterate layers
ovl: multi-layer re
On Fri, Nov 21, 2014 at 11:43 AM, Sedat Dilek wrote:
>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
>> overlayfs-current
>>
>
> This seems to be the place where overlayfs-fixes are collected for a
> git-pull request.
> Can you add a "T:" line with the Git tree into MAINTAINER
On Fri, Nov 21, 2014 at 12:32 PM, Hans-Peter Jansen wrote:
> Dear Miklos,
>
> On Donnerstag, 20. November 2014 17:45:31 Miklos Szeredi wrote:
>>
>> The biggest change is to rename the filesystem from "overlayfs" to
>> "overlay". This will allow l
On Mon, Nov 24, 2014 at 11:16 AM, hujianyang wrote:
> I'd like to introduce some of my work.
>
> 1) Use macros to indicate overlayfs_private_xattr.
Okay.
> 2) Enable overlayfs_private_xattr setting an removing in userspace.
>* I'm not clear with this one
No, I don't think this makes any se
On Thu, Oct 23, 2014 at 1:56 PM, Sedat Dilek wrote:
> Is the documentation up2date?
Should be. If you find any issues, please let me know (patch is also welcome).
> Some files below fs/overlayfs/ have copyright pointing to year 2011 by
> Novell - needs an update?
Not even sure who's my employ
Hello David,
Following patch fixes testsuite to use the right fstype. This was changed in
linux tree by
ef94b1864d1e ovl: rename filesystem type to "overlay"
Thanks,
Miklos
---
mount_union.py |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mount_union.py
+++ b/mount_union.p
On Wed, Nov 26, 2014 at 10:07 AM, hujianyang wrote:
> Hi Miklos,
>
> Will you apply my previous patch "ovl: Use macros to present
> ovl_xattr"? These two patches(previous one and this one) are
> based on branch *overlayfs-current* and conflict with each
> other.
>
> I don't know which branch I sho
On Sat, Nov 29, 2014 at 11:11 AM, hujianyang wrote:
> Hi Miklos,
>
> Sorry for disturb you. I'm confused with *cursor* in struct
> ovl_dir_file. I know this struct ovl_cache_entry *cursor* is
> presented to indicate current pos when performing readdir at
> a MERGE type directory.
>
> Why this addi
On Fri, Dec 5, 2014 at 10:47 AM, hujianyang wrote:
> On 2014/12/1 23:26, Miklos Szeredi wrote:
>
> Do you think it's valuable to discard the using of *cursor* and
> use a pointer instead? Or maybe we will enable some remove
> operations for ovl_dir_cache in the future so w
[Cc linux-unionfs]
On Thu, Dec 4, 2014 at 3:39 PM, Dean Roe wrote:
> Miklos,
>
> We have started using overlayfs on our systems, and have found that
> a known shortcoming is causing us grief. From the Documentation file:
>
> Symlinks in /proc/PID/ and /proc/PID/fd which point to a non-director
Al,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next
This adds support for multiple read-only layers to overlayfs. It also makes the
writable upper layer optional.
Thanks,
Miklos
---
Miklos Szeredi (12):
ovl: check whiteout while reading
overlayfs - how do you create whiteouts there? That, AFAICS, applies to
> the current mainline as well...
It really doesn't make sense to make upper layer an overlayfs. It won't work,
but it shouldn't crash. Should we blacklist it, so any such stupidity is found
out at mount t
On Wed, Jan 7, 2015 at 4:04 PM, Seunghun Lee wrote:
>> On 2015/1/6 22:02, Seunghun Lee wrote:
>>> After patch:
>>> root@qemux86:~# mount -t overlay overlay -olowerdir=lower:lower2 merged
>>> mount: warning: merged seems to be mounted read-only.
>>> root@qemux86:~# mount | grep overlay
>>> overlay
On Tue, Jan 6, 2015 at 5:52 AM, hujianyang wrote:
> The function ovl_fill_super() in recently multi-layer support
> version will incorrectly return 0 at error handling path and
> then cause kernel panic.
Applied.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Tue, Jan 6, 2015 at 9:10 AM, hujianyang wrote:
> Current multi-layer support overlayfs has a regression in
> .lookup(). If there is a directory in upperdir and a regular
> file has same name in lowerdir in a merged directory, lower
> file is hidden and upper directory is set to opaque in former
On Wed, Jan 7, 2015 at 3:22 AM, hujianyang wrote:
> It seems different in overlayfs. A left-hand lowerdir take precedence
> over any right-hand one in the option line.
Documentation added.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a
On Fri, Jan 9, 2015 at 2:43 AM, hujianyang wrote:
> How do you feel about this cleanup?
Pushed a modified version.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger
On Wed, Jan 14, 2015 at 3:45 AM, hujianyang wrote:
> Hi Miklos,
>
> I was considering the "FIXME: workdir is not needed for a R/O mount"
> you left in ovl_fill_super() these days.
>
> Actually Seunghun (Seunghun Lee ) has sent a patch
> about these problem. But I have some different ideas. I think
On Tue, Feb 10, 2015 at 7:26 PM, Caldwell, Blake A. wrote:
> Thanks. That could help in the short-term. I'd hope to see see this in
> mainline eventually. If someone could elaborate on the blanket exclusion of
> d_revalidate, I'd like to see if the task to add read-only NFS support is
> reasona
.
Thanks,
Miklos
---
Miklos Szeredi (16):
ovl: check whiteout while reading directory
ovl: make path-type a bitmap
ovl: dont replace opaque dir
ovl: add mutli-layer infrastructure
ovl: helper to iterate layers
ovl: multi-layer readdir
ovl: multi-layer lookup
On Wed, Feb 11, 2015 at 10:30:39AM +0100, Miklos Szeredi wrote:
> Al,
>
> Please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
> overlayfs-next
>
> This adds support for multiple read-only layers to overlayfs. It also makes
>
Atom2,
> The use case behind that is to be able to backup only files from the
> upperdir for several systems sharing a common lowerdir filesystem. I have
> used that (scripted approach via rsync) now for quiet some time and a few
> kernels back and it seemed to have worked very well.
Why don't yo
On Mon, Feb 9, 2015 at 8:23 AM, 王旭 wrote:
> Do not cache the overlay file dentries in dentry lru. For the fs dentry of
> overlay is fake, the real operations happen either lower dentry or upper
> dentry.
> So it's not helpful to performance.
Lookup of an uncached dentry causes acquisition of par
On Tue, Mar 3, 2015 at 6:12 PM, Atom2 wrote:
> Mikolos,
> thanks for joining the party.
>
> Am 03.03.15 um 16:14 schrieb Miklos Szeredi:
>
>> Atom2,
>>
>>> The use case behind that is to be able to backup only files from the
>>> upperdir for several sy
On Thu, Feb 5, 2015 at 11:01 AM, 王旭 wrote:
> Hi,
> I read the source code of overlay fs, it's amazing, but a few
> confusion for the rename2 function.
>
> Here is the code:
> 799 if (overwrite) {
>
> 800 if (old_opaque) {
> 801 if (new->d_inode || !new_opaque) {
> 802
On Mon, Feb 2, 2015 at 7:53 AM, hujianyang wrote:
> Hi Miklos,
>
> I was backporting overlayfs for linux 3.16 last week and
> found a small issue in the patch:
>
> commit c771d683: vfs: introduce clone_private_mount()
>
> this patch adds *struct path* to include/linux/mount.h,
> but actually *stru
The three patches are queued at
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next
This fixes minor issues with the multi-layer update in v4.0.
Thanks,
Miklos
---
hujianyang (3):
ovl: print error message for invalid mount options
ovl: check lowerdir amount
On Fri, Mar 20, 2015 at 09:41:25AM -0400, Josh Boyer wrote:
> On Fri, Mar 20, 2015 at 9:29 AM, Karel Zak wrote:
> >
> > Hi,
> >
> > kernel-4.0.0-0.rc4.git1.3.fc23 (I have nothing more recent right now,
> > sorry it the problem is already fixed).
>
> That equates to Linux v4.0-rc4-88-g7b09ac704
On Fri, Mar 20, 2015 at 04:25:58PM +, Al Viro wrote:
> On Fri, Mar 20, 2015 at 05:01:23PM +0100, Miklos Szeredi wrote:
>
> > But it does take care of the majority of f_path users that actually want the
> > covering path.
>
> Bloody bad idea, IMO. I have no o
On Fri, Mar 20, 2015 at 5:53 PM, Miklos Szeredi wrote:
> On Fri, Mar 20, 2015 at 04:25:58PM +, Al Viro wrote:
>> On Fri, Mar 20, 2015 at 05:01:23PM +0100, Miklos Szeredi wrote:
>>
>> > But it does take care of the majority of f_path users that actually want
>
On Wed, Mar 25, 2015 at 3:45 PM, David Howells wrote:
> Supply two functions to test whether a filesystem's own dentries are positive
> or negative (d_really_is_positive() and d_really_is_negative()).
>
> The problem is that the DCACHE_ENTRY_TYPE field of dentry->d_flags may be
> overridden by the
On Fri, Mar 27, 2015 at 3:42 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> I think this is confusing as hell, there needs to be more consistency
>> in the naming. E.g. d_backing_is_positive() vs. d_is_positive(). I
>> know it's the other way round n
On Wed, Apr 15, 2015 at 10:50 AM, Andrew Vagin wrote:
> Hello Miklos and Everyone else,
>
> We have a report that a container with overlayfs can't be checkpointed.
>
> To dump file descriptors we get information from /proc/pid/fd/ and
> /proc/pid/fdinfo.
>
> But in case of overlayfs we see unexpe
On Thu, Apr 16, 2015 at 4:43 PM, David Howells wrote:
> Convert ->d_inode to d_backing_inode() or d_is_xxx() when it is being used to
> access an inode on a subordinate filesystem of an overlay - even if that
> subordinate is itself an overlay.
Why?
What if foo is on another overlay and there's
[linux-unionfs added to Cc]
On Tue, May 19, 2015 at 09:51:20AM +0200, Bastian Bittorf wrote:
> Hi Miklos,
>
> sorry for writing directly to you, feel free to forward
> this to the appropriate mailinglist.
>
> we have a problem with mainline overlay filesystem on kernel 3.18:
> https://dev.openwr
[Al Viro and linux-unionfs added to Cc]
On Tue, May 19, 2015 at 11:30 PM, steve landiss wrote:
>
> On Tuesday, May 19, 2015 2:12 AM, Miklos Szeredi wrote:
> >
> >
> > On Mon, May 18, 2015 at 10:35 PM, steve landiss
> > wrote:
> >
> >> A data con
On Tue, May 19, 2015 at 1:29 PM, sa wrote:
> Hello!
>
> Are there plans for NFS lowerdir in mainline kernel?
Shouldn't be too difficult. WIll look into it.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kerne
OpenWRT folks.
Thanks,
Miklos
---
Miklos Szeredi (2):
ovl: don't remove non-empty opaque directory
ovl: mount read-only if workdir can't be created
---
fs/overlayfs/copy_up.c | 3 +++
fs/overlayfs/dir.c | 33 -
fs/overlayfs/super.c | 10 +++
On Mon, Jun 1, 2015 at 3:52 PM, David Howells wrote:
> In ovl_dentry_open(), ovl_drop_write() is called after vfs_open() - but is
> this actually necessary? Can't we just drop it post-copyup? After all,
> that's all we wanted the write lock for, right?
Hmm, that could result in a race where re
On Mon, Jun 1, 2015 at 5:45 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> > In ovl_dentry_open(), ovl_drop_write() is called after vfs_open() - but is
>> > this actually necessary? Can't we just drop it post-copyup? After all,
>> > that
Two small patches implementing this follow. Comments and testing welcome.
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next
Thanks,
Miklos
---
Miklos Szeredi (2):
ovl: don't traverse automount points
ovl: allow distributed fs as lower layer
--
From: Miklos Szeredi
Allow filesystems with .d_revalidate as lower layer(s), but not as upper
layer.
For local filesystems the rule was that modifications on the layers
directly while being part of the overlay results in undefined behavior.
This can easily be extended to distributed
From: Miklos Szeredi
NFS and other distributed filesystems may place automount points in the
tree. Previoulsy overlayfs refused to mount such filesystems types (based
on the existence of the .d_automount callback), even if the actual export
didn't have any automount points.
It cann
On Fri, Jun 05, 2015 at 01:07:15AM +0100, Al Viro wrote:
> Umm... Cosmetical point is that this
>
> > +static bool ovl_remote(struct dentry *root)
> > +{
> > + const struct dentry_operations *dop = root->d_op;
> > +
> > + return dop && (dop->d_revalidate || dop->d_weak_revalidate);
> > +}
>
On Sun, Jun 7, 2015 at 3:02 AM, Eric W. Biederman wrote:
> A nasty corner case to be aware of (and I think this is part of what Al
> was warning about). /proc/sys/net is different depending upon which
> current->nsproxy->net_ns.
Ah, I'm beginning to grasp what's going on there: mulitple dentrie
On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi wrote:
> On 7 May 2015 at 15:49, Felix Fietkau wrote:
>> On 2015-05-07 08:01, Wojciech Dubowik wrote:
>>> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on
>>> readdir. As far as I remember
>>
On Mon, Jun 15, 2015 at 10:24:28AM +0200, Felix Fietkau wrote:
> On 2015-06-15 10:20, Miklos Szeredi wrote:
> > On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi wrote:
> >> On 7 May 2015 at 15:49, Felix Fietkau wrote:
> >>> On 2015-05-07 08:01, Wojciech Dubowik
On Fri, Jun 19, 2015 at 9:20 AM, Al Viro wrote:
> On Thu, Jun 18, 2015 at 02:32:15PM +0100, David Howells wrote:
>>
>> The attached patches provide security support for unioned files where the
>> security involves an object-label-based LSM (such as SELinux) rather than a
>> path-based LSM.
>>
>> T
On Fri, Jun 19, 2015 at 08:59:03AM +0100, Al Viro wrote:
> On Fri, Jun 19, 2015 at 09:52:55AM +0200, Miklos Szeredi wrote:
> > Brave.
> >
> > What's going to happen to all those f_path.dentry uses where the
> > filesystem thinks it's getting its own dentry?
&
From: Miklos Szeredi
Turn
d_path(&file->f_path, ...);
into
file_path(file, ...);
Signed-off-by: Miklos Szeredi
---
arch/arc/kernel/troubleshoot.c | 10 +++---
arch/blackfin/kernel/trace.c |2 +-
arch/tile/kernel/
From: Miklos Szeredi
Turn
seq_path(..., &file->f_path, ...);
into
seq_file_path(..., file, ...);
Signed-off-by: Miklos Szeredi
---
drivers/md/bitmap.c |2 +-
fs/proc/nommu.c |2 +-
fs/proc/task_mmu.c |4 ++--
fs/proc/task_nommu.c
On Fri, Jun 19, 2015 at 10:29 AM, Al Viro wrote:
> Directory, probably?
>
>> - dentry = lookup_one_len(name, parent->dentry, namelen);
>> + dentry = lookup_one_len(name, parent, namelen);
>
> ... it would better be one.
My point is: without a bloody accessor, there's no way to warn if the
On Thu, Jun 18, 2015 at 4:43 PM, Jan Olszak wrote:
>
>
> On 06/18/2015 03:39 PM, David Howells wrote:
>>
>> Jan Olszak wrote:
>>
>>> I was wondering about a small improvement to overlayfs - optional, per
>>> file
>>> copy of write.
>>>
>>> 1. By default overlayfs would work as usual.
>>> 2. If a
On Mon, Jun 22, 2015 at 3:45 PM, Jan Olszak wrote:
> The lower fs is most likely ext4.
> Unfortunately making a file immutable won't solve the problem. There's
> nothing wrong in modifying the file and it should stay possible.
>
> I just want to switch off copy on write for some files. Can you se
On Mon, Jun 22, 2015 at 4:26 PM, Jan Olszak wrote:
>> You can bind mount individual files from the lower layer to the
>> overlay. That fixes the "allow modification" part.
>
> Well bind mounting every file that should have COW is unmaintainable - if
> new files appear admin has to mount each one.
On Sun, Jun 28, 2015 at 05:38:35PM +0300, sa wrote:
> On 04.06.2015 16:29, Miklos Szeredi wrote:
>
> >Two small patches implementing this follow. Comments and testing welcome.
> > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
> > overlayfs-next
idate" requirement. Also a bad interaction with jffs2
locking has been fixed.
Thanks,
Miklos
---
Miklos Szeredi (3):
ovl: don't traverse automount points
ovl: allow distributed fs as lower layer
ovl: lookup whiteouts outside iterate_dir()
---
fs/overlayfs/
On Thu, Aug 6, 2015 at 10:25 AM, Alkis Georgopoulos wrote:
> From https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt:
> mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged
>
> How can I specify that I want e.g. lower2 to be mounted at merged/home?
>
> If all lower*
Hi David,
Applied both patches.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
below for a fix. Please let me know if you see any issues.
Thanks,
Miklos
---
Subject: ovl: fix open in stacked overlay
From: Miklos Szeredi
If two overlayfs filesystems are stacked on top of each other, then we need
recursion in ovl_d_select_inode().
I guess d_backing_inode() is supp
nux-kvm.org/page/9p_virtio
> [In guest os]
> 4. cd /mnt
> 5. mkdir 1
> 6. rm -rf 1; mkdir 1
In the stack trace above I don'[t see overlayfs calls. So apparently
the mkdir goes directly to the 9p filesystem. So where's overlayfs in
all this?
Thanks,
Miklos
>
> Cc:
On Mon, Aug 24, 2015 at 03:57:18PM +0300, Konstantin Khlebnikov wrote:
> This fixes small memory leak after mount.
Both patches queued.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Mon, Sep 28, 2015 at 4:18 PM, David Howells wrote:
> Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for
> catching 32-bit userspace dealing with a file large enough that it'll be
> mishandled if the application isn't aware that there might be an integer
> overflow. Insid
On Fri, Aug 21, 2015 at 9:23 PM, Neal Gompa wrote:
> Hello,
>
> For those who have received this message twice already, I sincerely apologize.
>
> Yesterday I filed an issue in the CentOS bug tracker (#9297[1]) and
> the Red Hat Bugzilla (#1255512[2]) about OverlayFS with Btrfs as the
> upper laye
On Sat, Oct 3, 2015 at 9:19 PM, Dominique Martinet
wrote:
> Vincent Bernat wrote on Sat, Oct 03, 2015:
>> Did you get any feedback on this? The problem is unfortunately still
>> present in 4.3-rc3.
>
> Sorry, haven't got any reply but I bet it is :(
>
> I've been meaning to ask again after a while
On Mon, Jul 6, 2015 at 7:45 PM, Saied Kazemi wrote:
> On Wed, Apr 15, 2015 at 8:07 AM, Miklos Szeredi wrote:
>> On Wed, Apr 15, 2015 at 10:50 AM, Andrew Vagin wrote:
>>> Hello Miklos and Everyone else,
>>>
>>> We have a report that a container with overlay
On Mon, Oct 12, 2015 at 7:47 PM, Dominique Martinet
wrote:
> Miklos Szeredi wrote on Mon, Oct 12, 2015:
>> The solution depends on how 9p handles hard links. If any dentry will
>> do then d_find_any_alias() will get you a dentry (any dentry) from the
>> inode.
>>
: fix dentry reference leak
Konstantin Khlebnikov (2):
ovl: free stack of paths in ovl_fill_super
ovl: free lower_mnt array in ovl_put_super
Miklos Szeredi (1):
ovl: fix open in stacked overlay
---
fs/overlayfs/copy_up.c | 6 +++---
fs/overlayfs/inode.c | 3 +++
fs/overlayfs
On Thu, Oct 22, 2015 at 12:41 AM, Vito Caputo wrote:
> Greetings,
>
> We've been receiving reports of ooms triggered by the high-order allocation
> in the overlayfs ovl_copy_xattr() implementation.
>
> The bug is in the handling of direct-reclaim high-order allocations (and
> appears to be known a
1 - 100 of 104 matches
Mail list logo
