linux-kernel - Re: -mm: xfs lockdep warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Oct 2010 17:15:50 +0200
From:	Torsten Kaiser <just.for.lkml@...glemail.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	lkml <linux-kernel@...r.kernel.org>
Subject: Re: -mm: xfs lockdep warning

On Thu, Oct 7, 2010 at 4:05 PM, Tejun Heo <tj@...nel.org> wrote:
> Hello,
>
> On 10/07/2010 03:21 PM, Torsten Kaiser wrote:
>>> Can you test whether the following patch fix the issue?
>>
>> Yes. After adding this patch to 2.6.36-rc6 it survived my testcase. It
>> first seems to get stuck again, but after less then a minute the
>> system recovered and all compiles finished successfully.
>>
>> I suspect the combination of CFLAGs, the gcc version and maybe even
>> changes in KOffice from 2.2.1 to 2.2.2 are import for my testcase. It
>> looks like at the start of the complies something is really eating an
>> enormous amount of memory and I did not hit such a case with earlier
>> kernels.
>
> It's great to hear that the patch helped but would you be able to

:-(
The second try with the patched 2.6.36-rc6 got stuck again.

> repeat the same test w/ 2.6.35 and see whether there's any noticeable
> difference?

I just tested vanilla 2.6.35, userspace and the testcase as with the
2.6.36-rc6 kernel.
Behavior was the same as with the first try of the patched 2.6.36-rc6:
The testcase started to build up CPU load and memory pressure, then
the mouse got stuck. After ~1 min the system recovered and KDE became
usable again. (Compile just finish OK)

vmstat 60 from 2.6.35:
 2  0      0 2365848   1060 742072    0    0   205     7 6467 12252 26  5 62  8
17  0      0 837936   1060 1079520    0    0  1025    24 2210 13483 69 20  8  2
18  0      0 694296   1060 1127728    0    0   231    14  626 1883 74 26  0  0
20  0      0 228540    124 998440    0    0    48    12  604 1820 72 28  0  0
23  1     24 195456     52 657216    0    0   339    11  563 1669 84 16  0  0
 0 42 937144  14004      0 164352    0 15617   290 15633  827 1254 24  9  1 66
21  1 861184 776104      0 149908  998 3852  2790  3902 1137 2454 45 15  0 40
21  0 798544 1131964      0 190004  212    0   530    15  599 1469 87 13  0  0
12  1 779488 1536772      0 225312  195    0   398    12  534 1087 88 12  0  0
11  0 620620 2201408      0 273976 1338    0  1638    40  851 2281 75 19  3  3
12  1 588196 1572564      0 344232  521    0  1326   152  787 1888 86 14  0  0
 8  0 510876 2286000      0 311464  127    0   442   398  758 1558 88 12  0  0

> Some level of stuttering is expected if the system is hit
> with sudden huge spike of memory pressure but let's see if it has
> regressed somehow.

Yes, if a swapstorm occurs, I can live with a (short) "lockup". For
example compiling openoffice on tmpfs is a case where I have seen
similar short periods of the mouse getting stuck. But with 2.6.36-rc5
it was the first time that the system did not seem to recover, so I
think it should count as a regression compared to 2.6.35.

As the second try with the patched 2.6.36-rc6 got stuck again, could
it be that your patch is incomplete?
>From drivers/md/dm-crypt.c:
        cc->io_queue = create_singlethread_workqueue("kcryptd_io");
        cc->crypt_queue = create_singlethread_workqueue("kcryptd");

Do these workqueues also need WQ_MEM_RECLAIM?

I have attached the SysRq-M output from the patched -rc6. The symptoms
were the same as with the unpatched kernel. The system got stuck, the
hung_task_timeout triggered for a numer of programs in sync_page() or
do_lookup() and one kworker/1:1:496 was probable the nail in the
coffin.

Do you want me to do more tests with 2.6.35 or the patched .36-rc6? Or
any other patch I should try?

Torsten

View attachment "hang-with-patch.txt" of type "text/plain" (33978 bytes)