sting 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 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/
ding overlayfs into 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.
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
:::
Latest version 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 h
at is represented
> > +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 direc
to an error return 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
ew fs, otherwise it 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/
tion completes supporting. 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 goo
nd its thread in detail.
[RFC 0/5] pathconf(3) with _PC_LINK_MAX
<http://marc.info/?l=linux-kernel&m=126008634810706&w=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 m
e the
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
temp
sage. But, as long as
the unioning 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&
io_write(iocb, iov, nr_segs, &iocb->ki_pos);
mutex_unlock(&inode->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 mak
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 ma
(and releases) 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/
s. One approach 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.kerne
nMount is really stopped, then I'd ask people
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
th
G_SYSFS is disable, this parameter 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
is approach, but I don't have another better idea,
also it works for many years. You can get the patch in
aufs4-standalone.git on sourceforge if you want.
J. R. Okajima
& !rcu_access_pointer(class->key)
&& list_empty(&class->lock_entry)
&& hlist_unhashed(&class->hash_entry);
}
Though a new function list_del_init_rcu() for zap_class() will be
necessary.
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
undamental 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
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
By the commit,
a52458b48af1 2018-12-19 NFS/NFSD/SUNRPC: replace generic creds with 'struct
cred'.
struct rpc_cred machine_cred was converted to struct cred, but
machine_cred.magic is still uninitialized. Without initializing it, I
got 'Invalid credentials' error. It is necessary when
CONFIG_DEB
By the commit,
a52458b48af1 2018-12-19 NFS/NFSD/SUNRPC: replace generic creds with 'struct
cred'.
struct rpc_cred machine_cred was converted to struct cred, but
machine_cred.magic is still uninitialized. Without initializing it, I
got 'Invalid credentials' error. It is necessary when
CONFIG_DEB
do we need 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 unsubsc
luding overlayfs into mainline, but if the development
of UnionMount is really 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
th
y-up. It has only 20 commits.
aufs3-linux.git#mainline-v3.9-rc8-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 h
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
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
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/
patch
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 i
can call them 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 unsu
"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
gt;
> dont_appraise 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 majordom
"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
NFS-exporting
http://marc.info/?l=linux-fsdevel&m=140197128121026&w=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/
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
ow 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.
tly
- etc...
If 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&m=123934927611907&w=2
And latest one is
http://aufs.sourceforge.net
J. R. Okajima
--
To unsubsc
n't exist
- /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 mess
"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/ma
e same 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 total
q_path(struct seq_file *seq, 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
nd their thread.
For tmpfs, I have another patch. Just FYI, here attached.
J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
commit 1e83f8634c6efe7dd4e6036ee202ca10bdbca0b3
Author: J. R. Okajima
Date: Sat May 25 18:35:13 2019 +0900
concrete /proc/mounts
When the size of /proc/mounts exceeds PAGE_SIZE, seq_read() has to
release namespace_sem via mounts_op.m_stop(). It means if someone else
pt unchanged before/after read()?
J. R. Okajima
ing of these attributes is to ignore the error from setting
XATTR on that branch.
Note that aufs tries copying all XATTR unconditionally, and ignores the
error from the dst branch according to the specified attributes.
But recent nfs4 got changed its behaviour around ACL, and it didn't pass
my local tests. I had posted about that, but got no reply.
J. R. Okajima
+#define MAX_LOCKDEP_ENTRIES(32768UL << 5)
+#define MAX_LOCKDEP_CHAINS_BITS(16 + 5)
+#define MAX_STACK_TRACE_ENTRIES(524288UL << 5)
J. R. Okajima
_read(&sem->dep_map, 0, 0, _RET_IP_);
produce a traditional AB-BA deadlock warning, don't they?
J. R. Okajima
ze of an internal
array, you can change it freely.
J. R. Okajima
commit 030361e78d327d9d89254dc3b320c092221c7cd0
Author: J. R. Okajima
Date: Tue Jan 31 00:01:16 2017 +0900
parser: match_u64, short string optimization
=
When the given string is short enough, we can skip kmalloc/
g as dev:ino is unchanged from git index.
But such filesystem looks weird.
J. R. Okajima
rts uid/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
Of course 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
kend_dentry = 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
now whether !LOCKDEP build bits are necessary or not.
J. R. Okajima
The commit
f831948 2016-11-30 locking/lockdep: Provide a type check for
lock_is_held
didn't fully support rwsem. Here downgrade_write() supports the added type.
Originally-written-by: Peter Zijlstra
See-also: http://marc.info/?l=linux-kernel&m=148581164003149&w=2
Signed
A simple consolidataion. The behaviour should not change.
Signed-off-by: J. R. Okajima
---
kernel/locking/lockdep.c | 39 +--
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index b7a2001
A simple consolidataion. The behaviour should not change.
Signed-off-by: J. R. Okajima
---
kernel/locking/lockdep.c | 114 ++-
1 file changed, 54 insertions(+), 60 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index
at you need !LOCKDEP stubs for ;-)
Ok, here is the update.
Just one line added.
J. R. Okajima
commit 6874cbfb3c4f757efecbeb800bfd4db1050698f6
Author: J. R. Okajima
Date: Thu Feb 2 23:41:38 2017 +0900
lockdep: new annotation lock_downgrade()
=
The commit
f831948 2016-11-
-mount 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 exportf
Trond Myklebust:
> On Sun, Sep 27, 2015 at 8:47 AM, J. R. Okajima 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:
> > " message from linux-
nsole (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. Ok
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 jus
"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 &qu
cate check IS_APPEND() on real upper inode
v4.13
ad0af71 2017-07-04 vfs: introduce inode 'inuse' lock
J. R. Okajima
l,
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
oduce the
problem on your side. I guess "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
re not calling synchronize_rcu_expedited().
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
Do not sync 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
Commit-ID: 41c2c5b86a5e1a691ddacfc03b631b87a0b19043
Gitweb: http://git.kernel.org/tip/41c2c5b86a5e1a691ddacfc03b631b87a0b19043
Author: J. R. Okajima
AuthorDate: Fri, 3 Feb 2017 01:38:15 +0900
Committer: Ingo Molnar
CommitDate: Thu, 16 Mar 2017 09:57:06 +0100
locking/lockdep: Factor
Commit-ID: e969970be033841d4c16b2e8ec8a3608347db861
Gitweb: http://git.kernel.org/tip/e969970be033841d4c16b2e8ec8a3608347db861
Author: J. R. Okajima
AuthorDate: Fri, 3 Feb 2017 01:38:16 +0900
Committer: Ingo Molnar
CommitDate: Thu, 16 Mar 2017 09:57:07 +0100
locking/lockdep: Factor
Commit-ID: 6419c4af777a773a45a1b1af735de0fcd9a7dcc7
Gitweb: http://git.kernel.org/tip/6419c4af777a773a45a1b1af735de0fcd9a7dcc7
Author: J. R. Okajima
AuthorDate: Fri, 3 Feb 2017 01:38:17 +0900
Committer: Ingo Molnar
CommitDate: Thu, 16 Mar 2017 09:57:07 +0100
locking/lockdep: Add new
74 matches
Mail list logo
