Re: hung_task_timeout: mutex_lock in aufs

2018-02-06 Thread sfjro--- via Aufs-users
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,

Re: hung_task_timeout: mutex_lock in aufs

2018-02-06 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-02-05 Thread sfjro--- via Aufs-users
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!

Re: hung_task_timeout: mutex_lock in aufs

2018-02-05 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-02-03 Thread sfjro--- via Aufs-users
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 "

Re: hung_task_timeout: mutex_lock in aufs

2018-02-03 Thread sfjro--- via Aufs-users
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

Re: hung_task_timeout: mutex_lock in aufs

2018-01-30 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-29 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-28 Thread sfjro--- via Aufs-users
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

Re: hung_task_timeout: mutex_lock in aufs

2018-01-24 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-24 Thread sfjro--- via Aufs-users
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

Re: hung_task_timeout: mutex_lock in aufs

2018-01-23 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-23 Thread sfjro--- via Aufs-users
> 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.

Re: hung_task_timeout: mutex_lock in aufs

2018-01-23 Thread sfjro--- via Aufs-users
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

Re: hung_task_timeout: mutex_lock in aufs

2018-01-22 Thread sfjro--- via Aufs-users
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.

Re: hung_task_timeout: mutex_lock in aufs

2018-01-22 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-22 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-22 Thread sfjro--- via Aufs-users
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

Re: hung_task_timeout: mutex_lock in aufs

2018-01-21 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-21 Thread Eddie Horng
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: hung_task_timeout: mutex_lock in aufs

2018-01-19 Thread sfjro--- via Aufs-users
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: