size by xattr. If xattr
reaches the limit, then several operation in overlayfs will be unusable.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
-3.x series), there is no essential
changes about whiteout since aufs2.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
an approach of a file mode, but I am
+afraid several utilities (find(1) or something) will have to support it.
Why the devil should find(1) even see them?
It is the case when find(1) for the layer-fs/branch-fs directly.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux
. For example, repeat ln fileA $very_lng_filename, then btrfs
returns EMLINK so soon.
And aufs refers the common set of inode attribute. I mean attrs declared
in VFS. Also I know some filesystems don't maintain attrs on each
operation. For such fs, aufs calls vfs_getattr() internally.
J. R. Okajima
to be merged.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
of server and client. Of
course, the server may be other than linux. Even if FS is local, users
may setup dual-boot. And the other OS has to recognize the new d_type
value.
I still doubt it is a good approach.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
that the target name is still available for copyup
- make the completed file visible by -link()
It is ineteresting to -link() with the unlinked file. While
vfs_unlink() rejects such case, it may not matter for the underlying fs.
Need to verify FS including jounals.
J. R. Okajima
--
To unsubscribe
is not implemented as a fs, the solution will not
be so easy. I am afraid UnionMount will need to introduce a new counter
(or a new flag) to indicate the task entered the union, and adjust the
lock class or decide to call lockdep_off() for sb_writers. I don't think
it is a good idea.
J. R. Okajima
-i_mutex);
:::
sb_end_write(inode-i_sb);
Process C would block *BEFORE* i_mutex by sb_start_write()? No?
Honestly speaking I didn't pay attention about the freeze feature since
I don't use it. I am making aufs to support it now. But I don't know how
to test it...
J. R. Okajima
whiteouted name.
The demerit is that aufs has to limit the length of the name.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
, then I'd ask people to consider merging
aufs as well as overlayfs.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
to the request from Ubuntu people.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
is
implemented in aufs. I guess you will try another one. That is what I am
interesed.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
in detail.
[RFC 0/5] pathconf(3) with _PC_LINK_MAX
http://marc.info/?l=linux-kernelm=126008634810706w=2
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
to consider merging aufs as well as overlayfs.
but I am not sure whether LKML people are still waiting for UnionMount
and rejecting aufs.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
core?
If it is true, we may need a rule no new resources for decompressing
since users may prefer the slow but successful decompression than
getting ENOMEM.
If this mail is totaly pointless, please ignore.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
for every whiteout? I'd suggest making a
hardlink. For some filesystems which don't support hardlinks, we have to
consume an inode per whiteout. But when the fs supports hardlinks, we
can re-use the inode and consume a few inodes only.
J. R. Okajima
--
To unsubscribe from this list: send the line
There is a regression in
208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
which deletes an nfserrno() call in nfsd_setattr() (by accident,
probably), and NFSD becomes ignoring an error from VFS.
Here is a patch to fix it.
J. R. Okajima
diff --git a/fs/nfsd/vfs.c b/fs
and returns an error. If all are
succeeded, aufs registers a function to remove the whiteouted unique
temporary name completely and asynchronously to the system global
workqueue.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
=140197128121026w=2
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IMA?
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
as IMA needs to read the file, we should merge the merge.
Or we should wait for your another patch.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
.
- of course, O_DIRECT_HAVELOCK should be complied only when CONFIG_IMA
is enabled too.
I can guess that several people thinks that is still ugly locking, but
the deadlock is much ugly in real world. And we need some workaround for
it.
J. R. Okajima
--
To unsubscribe from this list: send the line
J. R. Okajima:
do_blockdev_direct_IO(), I'd suggest
- make two new static inline functions like
r = ima_aware_file_inode_mutex_lock(file) and ..._unlock(r, file).
- these new functions are complied when CONFIG_IMA is enabled, otherwise
they are plain mutex_lock/unlock
fsuuid=...
I prefer such approach or anything addressing in IMA only, so it makes
sense.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d_lockref.lock held. It must be the
same result, isn't it? Or does it mean that denty can be handled by
lockref_mark_dead() even if d_lockref.lock is held?
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
for the latter case,
I think the patch is good.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
of /u/fileA?
And all tests should be done by a superuser?
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
J. R. Okajima:
- readlink.test,
fs_op readlink $file -R $testdir/direct_dir_sym100 ${termslash:+-E
EINVAL}
It expects $testdir/direct_dir_sym100. Does it mean UnionMount
converts the target path?
For example,
- /u = /rw + /ro
- /rw/symlinkA doesn't exist
- /ro/symlinkA
commit fixed the path.
No problemo.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
overlayfs, then I'd ask to consier aufs
too. The basic design is unchanged since when I posted a few years ago.
http://marc.info/?l=linux-kernelm=123934927611907w=2
And latest one is
http://aufs.sourceforge.net
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
met the problem (like me)?
In other words, should I wait for another lock free solution from Dmitry
Kasatkin?
By the way, the mail is not delivered to stable-ML while there is
Cc: stable... line in the commit log.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux
J. Bruce Fields:
On Wed, Feb 19, 2014 at 12:27:53AM +0900, J. R. Okajima wrote:
There is a regression in
208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
which deletes an nfserrno() call in nfsd_setattr() (by accident,
probably), and NFSD becomes ignoring an error
stopped, then I'd ask people to consider merging
aufs as well as overlayfs.
http://aufs.sf.net
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
-20130428$ git log1 --no-merges fs/aufs/*.c |
wc -l
20
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
patch. Just FYI, here attached.
J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
, struct path *path)
{
return seq_path(seq, path, au_esc_chars);
}
module_init(void)
{
:::
p = au_esc_chars;
for (i = 1; i = ' '; i++)
*p++ = i;
*p++ = '\\';
*p++ = '\x7f';
*p = 0;
:::
}
J. R. Okajima
--
To unsubscribe
Trond Myklebust:
> On Sun, Sep 27, 2015 at 8:47 AM, J. R. Okajima <hooanon...@gmail.com> wrote:
> > I don't know whether this is a known issue or not (since I was off from
> > development for a few months), but I've got a "general protection fault:
> >
is really the
trigger of this issue.
J. R. Okajima
--
#!/bin/sh
set -eu
Stat() # path
{
stat -f --printf="%n %T\n" $1
}
uname -a
s=/dev/shm
Stat $s
c=/tmp/c
mkdir -p $c
showmount -e > /tmp/e
sudo exportfs -i -o rw
OCKDEP stubs for ;-)
Ok, here is the update.
Just one line added.
J. R. Okajima
commit 6874cbfb3c4f757efecbeb800bfd4db1050698f6
Author: J. R. Okajima <hooanon...@gmail.com>
Date: Thu Feb 2 23:41:38 2017 +0900
lockdep: new annotation lock_downgrade()
=
The commit
f831948
raditional AB-BA deadlock warning, don't they?
J. R. Okajima
r !LOCKDEP build bits are necessary or not.
J. R. Okajima
y = lookup_one_len()
if (d_inode->i_nlink != 1)
shiftfs_inode = ilookup();
if (!shiftfs_inode) {
shiftfs_inode = new_inode();
shiftfs_inode->i_ino = bakend_dentry->d_inode->i_ino;
}
J. R. Okajima
se they will be limited to when the target dir is huge and/or
system memory is low. As long as the inode cache is large enough to hold
all necessary inodes, the problem won't happen.
If shiftfs will supports exporting via NFS in the future, the
consistency of inum will be important too.
J. R. Okajima
3149=2
Signed-off-by: J. R. Okajima <hooanon...@gmail.com>
---
include/linux/lockdep.h | 2 ++
kernel/locking/lockdep.c | 55
kernel/locking/rwsem.c | 6 ++
3 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/include/linux
A simple consolidataion. The behaviour should not change.
Signed-off-by: J. R. Okajima <hooanon...@gmail.com>
---
kernel/locking/lockdep.c | 39 +--
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/l
A simple consolidataion. The behaviour should not change.
Signed-off-by: J. R. Okajima <hooanon...@gmail.com>
---
kernel/locking/lockdep.c | 114 ++-
1 file changed, 54 insertions(+), 60 deletions(-)
diff --git a/kernel/locking/lockdep.c b/
of an internal
array, you can change it freely.
J. R. Okajima
commit 030361e78d327d9d89254dc3b320c092221c7cd0
Author: J. R. Okajima <hooanon...@gmail.com>
Date: Tue Jan 31 00:01:16 2017 +0900
parser: match_u64, short string optimization
=
When the given string is short enough,
5)
+#define MAX_STACK_TRACE_ENTRIES(524288UL << 5)
J. R. Okajima
id/gid before calling
backend fs' ->setattr(). It is good too.
But how about acl? Won't such conversion be necessary for acl too?
J. R. Okajima
no is unchanged from git index.
But such filesystem looks weird.
J. R. Okajima
(almost?)
always cause a deadlock?
Who I can ask to check this log?
I am not sure whether this is related, but I added a workqueue for my
development. There is no such message in the log about my workqueue, but
I am afraid my development is related to any change around workqueue.
J. R. Okajima
Jani Nikula:
> On Thu, 15 Jun 2017, "J. R. Okajima" <hooanon...@gmail.com> wrote:
> > How about v4.11.x series?
> > I got v4.11.5, but it doesn't contain the fix.
> > Do you have a plan?
>
> The upstream commit has the proper Cc: stable and Fi
"J. R. Okajima":
> I don't know whether the fix is good to me or not yet. I will test your
> fix, but I am busy now and my test will be a few weeks later. Other
> people may want the fix soon. So I'd suggest you to reproduce the
> problem on your side. I guess "mem=
c RCU during shrinking
How about v4.11.x series?
I got v4.11.5, but it doesn't contain the fix.
Do you have a plan?
J. R. Okajima
was not
merged before v4.11 comes out. I know v4.11 will appear soon. So I'd ask
i915 developers, would you test Andrea Arcangeli's fix and release it as
v4.11.1 as soon as possible?
J. R. Okajima
t calling synchronize_rcu_expedited().
J. R. Okajima
s "mem=1G" or "mem=512M" will make it easier
to reproduce the problem.
Of course, if you are sure the fix is correct, then you don't have to
wait for my test. Release it soon for other people.
J. R. Okajima
PPEND() on real upper inode
v4.13
ad0af71 2017-07-04 vfs: introduce inode 'inuse' lock
J. R. Okajima
iel,
Aufs is not in mainline, so I don't think it is appropriate to book the
report into kernel bugzilla. Read aufs README file please.
J. R. Okajima
rameter is always set to 0.
--
If you post the details of your environment to aufs-users ML, then I
may be able to describe more.
J. R. Okajima
tter idea,
also it works for many years. You can get the patch in
aufs4-standalone.git on sourceforge if you want.
J. R. Okajima
r=3D~/tca_agent/container_rw_dir/51509032=
:::
(very long command line)
For such long branches, try "remount,append" option.
# mount -t aufs -o br=br0:br1:br2...:brN none /mntpnt
# mount -o remount,append=brN+1 /mntpnt
# mount -o remount,append=brN+2 /mntpnt
:::
J. R. Okajima
ental solution. Docker=20
Can't it be a solution?
# mount -o bind /long/path0 /br0
# mount -o bind /long/path1 /br1
:::
# mount -t aufs -o br=/br0:/br1:... none /mntpnt
or
# ln -s /long/path0 /br0
# ln -s /long/path1 /br1
:::
# mount -t aufs -o br=/br0:/br1:... none /mntpnt
J. R. Okajima
ert such as
fea6d2a6 2017-02-14 vfs: Use upper filesystem inode in bprm_fill_uid()
Here is another question.
Does overlayfs support atomic_open?
I remember implementing atomic_open on aufs was rather tricky many years
ago, and I am interested in how overlayfs addresses it.
J. R. Okajima
e time,
then does squashfs simply return ENOMEM because the memory shrinker
cannot run on any core?
If it is true, we may need a rule "no new resources for decompressing"
since users may prefer the "slow but successful decompression" than
getting ENOMEM.
If this mail is totaly poi
turn from
btrfs. For example, repeat "ln fileA $very_lng_filename", then btrfs
returns EMLINK so soon.
And aufs refers the common set of inode attribute. I mean attrs declared
in VFS. Also I know some filesystems don't maintain attrs on each
operation. For such fs, aufs calls vfs_get
would be
harder to be merged.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
orting. When the FS is a network filesystem,
the new d_type has to be available on both of server and client. Of
course, the server may be other than linux. Even if FS is local, users
may setup dual-boot. And the other OS has to recognize the new d_type
value.
I still doubt it is a good approach.
J. R. Okaji
ked file. While
vfs_unlink() rejects such case, it may not matter for the underlying fs.
Need to verify FS including jounals.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ning feature is not implemented as a fs, the solution will not
be so easy. I am afraid UnionMount will need to introduce a new counter
(or a new flag) to indicate the task entered the union, and adjust the
lock class or decide to call lockdep_off() for sb_writers. I don't think
it is a good idea.
J
_pos);
mutex_unlock(>i_mutex);
:::
sb_end_write(inode->i_sb);
Process C would block *BEFORE* i_mutex by sb_start_write()? No?
Honestly speaking I didn't pay attention about the freeze feature since
I don't use it. I am making aufs to support it now. But I do
h one more prefix, the name loses the role of
whiteout. Aufs simply ignores such doubly whiteouted name.
The demerit is that aufs has to limit the length of the name.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
There is a regression in
208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
which deletes an nfserrno() call in nfsd_setattr() (by accident,
probably), and NFSD becomes ignoring an error from VFS.
Here is a patch to fix it.
J. R. Okajima
diff --git a/fs/nfsd/vfs.c b/fs
an inode for every whiteout? I'd suggest making a
hardlink. For some filesystems which don't support hardlinks, we have to
consume an inode per whiteout. But when the fs supports hardlinks, we
can re-use the inode and consume a few inodes only.
J. R. Okajima
--
To unsubscribe from this list: send
actual rename on a branch and then handles other actions (make it opaque,
update the attributes, etc). If an error happens in these actions, aufs
simply renames the whiteouted name back and returns an error. If all are
succeeded, aufs registers a function to remove the whiteouted unique
tempor
to mainline, but if the development
of UnionMount is really stopped, then I'd ask people to consider merging
aufs as well as overlayfs.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
little.
Filesystems may have a limit for the consumed size by xattr. If xattr
reaches the limit, then several operation in overlayfs will be unusable.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
ersion is aufs3 (for linux-3.x series), there is no essential
changes about whiteout since aufs2.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/m
esented
> > +by its filename. UnionMount takes an approach of a file mode, but I am
> > +afraid several utilities (find(1) or something) will have to support it.
>
> Why the devil should find(1) even see them?
It is the case when find(1) for the layer-fs/branch-fs directly.
J.
the file from IMA?
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
h
took, as long as IMA needs to read the file, we should merge the merge.
Or we should wait for your another patch.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
m blindly.
- of course, O_DIRECT_HAVELOCK should be complied only when CONFIG_IMA
is enabled too.
I can guess that several people thinks that is still "ugly locking", but
the deadlock is much ugly in real world. And we need some workaround for
it.
J. R. Okajima
--
To unsubscribe f
"J. R. Okajima":
> do_blockdev_direct_IO(), I'd suggest
> - make two new static inline functions like
> r = ima_aware_file_inode_mutex_lock(file) and ..._unlock(r, file).
> - these new functions are complied when CONFIG_IMA is enabled, otherwise
> they ar
for me. It
checks d_lockref.count twice during d_lockref.lock held. It must be the
same result, isn't it? Or does it mean that denty can be handled by
lockref_mark_dead() even if d_lockref.lock is held?
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
w how to reproduce the problem for the latter case,
I think the patch is good.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
x-fsdevel=140197128121026=2
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"J. Bruce Fields":
> On Wed, Feb 19, 2014 at 12:27:53AM +0900, J. R. Okajima wrote:
> >
> > There is a regression in
> > 208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
> > which deletes an nfserrno() call in nfsd_setattr() (by acci
f LKML people consider merging overlayfs, then I'd ask to consier aufs
too. The basic design is unchanged since when I posted a few years ago.
http://marc.info/?l=linux-kernel=123934927611907=2
And latest one is
http://aufs.sourceforge.net
J. R. Okajima
--
To unsubscribe from this list: se
ro/symlinkA points to /ro/fileA
Does readlink(2) return "/u/fileA" instead of "/u/fileA"?
And all tests should be done by a superuser?
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
"J. R. Okajima":
> - readlink.test,
> fs_op readlink $file -R $testdir/direct_dir_sym100 ${termslash:+-E
> EINVAL}
> It expects "$testdir/direct_dir_sym100". Does it mean UnionMount
> converts the target path?
> For example,
> - /u = /
> /mnt/a/direct_dir_sym100
Now I've found your latest commit fixed the path.
No problemo.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordo
ppraise bprm_check directio fsuuid=...
I prefer such approach or anything addressing in IMA only, so it makes
sense.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
hoever have met the problem (like me)?
In other words, should I wait for another lock free solution from Dmitry
Kasatkin?
By the way, the mail is not delivered to stable-ML while there is
"Cc: stable..." line in the commit log.
J. R. Okajima
--
To unsubscribe from this list: send the l
ert such as
fea6d2a6 2017-02-14 vfs: Use upper filesystem inode in bprm_fill_uid()
Here is another question.
Does overlayfs support atomic_open?
I remember implementing atomic_open on aufs was rather tricky many years
ago, and I am interested in how overlayfs addresses it.
J. R. Okajima
iel,
Aufs is not in mainline, so I don't think it is appropriate to book the
report into kernel bugzilla. Read aufs README file please.
J. R. Okajima
de
v4.13
ad0af71 2017-07-04 vfs: introduce inode 'inuse' lock
J. R. Okajima
Jani Nikula:
> On Thu, 15 Jun 2017, "J. R. Okajima" wrote:
> > How about v4.11.x series?
> > I got v4.11.5, but it doesn't contain the fix.
> > Do you have a plan?
>
> The upstream commit has the proper Cc: stable and Fixes: tags in place,
> it just
thread in detail.
[RFC 0/5] pathconf(3) with _PC_LINK_MAX
<http://marc.info/?l=linux-kernel=126008634810706=2>
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
) to
GIT on SourceForge due to the request from Ubuntu people.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1 - 100 of 142 matches
Mail list logo
