Eddie Horng:
> Many thanks you fixed the issue. May I consult you the theory of your
> fixing? Does au_wkq_wait() put vfs_read to an interrupt free stat so that
> read can complete without interrupt error? Just curious.
Many thanx to you for your repeated tests.
The workqueue is a kernel thread,
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Eddie Horng:
> The patch works great! Applied the patch I can't reproduce the problem
> anymore, when func(file, buf.u, size, pos) returns -EINTR, "if (err ==
> -EINTR && !au_wkq_test() ..." entered and I never see i>1 case. Is this
> patch the final solution for this case?
Glad to hear that!
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Eddie Horng:
> I doubt that clang++.real has special file i/o or some signal handling that
> trigger the scenario, there're many kinds of processes are running in
> android building but the only busy looping process is always the same one
> in all my reproducing test. BTW, the return value from "
Eddie Horng:
> It seems all tasks are trying to lock sbinfo->si_xib_mtx, but log shows
> nobody is holding it. I also got similar problem in my codefs, but it's
> very rare, not like this case now I can almost always reproduce it. To
> isolate issue, I changed ro branch from codefs to ext4 and
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Eddie Horng:
> Log attached - related to previous mail
Thanx a lot.
But unfortunately there was not good info in the log.
I am still reviewing my aufs code. At the same time I start wondering
the problem may exist out of aufs. I know such probability is very
small.
Reviewing the code, I will
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Eddie Horng:
> Thanks the information, but I still can reproduce it with aufs-4.10 and the
> held lock patch.
Hmm...
I am totally confused and lost my way. I don't understand what is
happening. If anyone on this list has an idea which light up the way, I
will be gladly become all ears.
Your
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> But I have a suggestion for you.
>
> 1. upgrade your aufs to the latest aufs4.10.
>This is my very best recommendation.
:::
Ah, I forgot one thing.
Here is a debug patch to see the problem more clearly.
This is not a fix, but it may help to see more in the held lock list.
J. R.
sf...@users.sourceforge.net:
> Exactly.
> At the same time, I noticed that I made a mistake on my git-work. I
> thought there is something wrong with the commit
> e14748e 2017-02-19 UBUNTU: SAUCE: Import aufs driver
> in zesty because it doesn't match the commit
> 6c73f3b 2017-02-04
Eddie Horng:
> Yes, my kernel is git://kernel.ubuntu.com/ubuntu/ubuntu-zesty.git @tag:
> Ubuntu-4.10.0-34.38.
> I diff fs/aufs from my codebase, changes from zesty#1bfb6eb and
> aufs4#6c73f3b are:
> fs/aufs/cpup.c
> fs/aufs/vfsub.h
> for your reference if these diffs are as you expected.
Exactly.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Eddie Horng:
> I reproduced a hung case, maybe not exactly the same operation as original
> one but au_xino_delete_inode is appeared in call stake. Below dmesg log
> with lockdep enabled, please kindly check it.
Ok, I think I can find the AB-BA deadlock problem.
I will try fixing it asap. Please
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Hello Eddie,
Eddie Horng:
> I got hung to access to an aufs mount dir, dmesg shows mutex_lock call
> stack in aufs.
:::
> kernel version: 4.10.0-34-generic
> aufs version: 4.x-rcN-20170206
Hmm, your version is rather old, almost a year ago. But I don't think it
important.
> dmesg log:
21 matches
Mail list logo