fore/after read()?
J. R. Okajima
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
f 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
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
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
_access_pointer(class->key)
&& list_empty(>lock_entry)
&& hlist_unhashed(>hash_entry);
}
Though a new function list_del_init_rcu() for zap_class() will be
necessary.
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
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
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
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
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
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
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
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
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
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
PPEND() on real upper inode
v4.13
ad0af71 2017-07-04 vfs: introduce inode 'inuse' lock
J. R. Okajima
de
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
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
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
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
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
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
"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=
"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=
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
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
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
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
t calling synchronize_rcu_expedited().
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
(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
Commit-ID: 6419c4af777a773a45a1b1af735de0fcd9a7dcc7
Gitweb: http://git.kernel.org/tip/6419c4af777a773a45a1b1af735de0fcd9a7dcc7
Author: J. R. Okajima <hooanon...@gmail.com>
AuthorDate: Fri, 3 Feb 2017 01:38:17 +0900
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 16
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
Commit-ID: 41c2c5b86a5e1a691ddacfc03b631b87a0b19043
Gitweb: http://git.kernel.org/tip/41c2c5b86a5e1a691ddacfc03b631b87a0b19043
Author: J. R. Okajima <hooanon...@gmail.com>
AuthorDate: Fri, 3 Feb 2017 01:38:15 +0900
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 16
Commit-ID: e969970be033841d4c16b2e8ec8a3608347db861
Gitweb: http://git.kernel.org/tip/e969970be033841d4c16b2e8ec8a3608347db861
Author: J. R. Okajima <hooanon...@gmail.com>
AuthorDate: Fri, 3 Feb 2017 01:38:16 +0900
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 16
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
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
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
no is unchanged from git index.
But such filesystem looks weird.
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
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
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
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
OCKDEP 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-30 locking
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/
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
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
---
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
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
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=148581164003149=2
Signed-off-by: J. R
r !LOCKDEP build bits are necessary or not.
J. R. Okajima
r !LOCKDEP build bits are necessary or not.
J. R. Okajima
raditional AB-BA deadlock warning, don't they?
J. R. Okajima
raditional AB-BA deadlock warning, don't they?
J. R. Okajima
5)
+#define MAX_STACK_TRACE_ENTRIES(524288UL << 5)
J. R. Okajima
5)
+#define MAX_STACK_TRACE_ENTRIES(524288UL << 5)
J. R. Okajima
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,
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/kfree
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-4.3-rc
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
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
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';
*p = 0;
, 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
mpfs, I have another patch. Just FYI, here attached.
J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
patch. Just FYI, here attached.
J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
its.
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 http://vger.kernel.org/maj
-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
ng 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
the body of a mes
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
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
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
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
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/
=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/
> /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
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/
"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 = /
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
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
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
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
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
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
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
"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
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
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
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
1 - 100 of 142 matches
Mail list logo
