linux-kernel - Re: [PATCH 5/9] XArray: entry in last level is not expected to be a node

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]

Message-ID: <20200406011406.aeccnuh4owmm53xs@master>
Date:   Mon, 6 Apr 2020 01:14:06 +0000
From:   Wei Yang <richard.weiyang@...il.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Wei Yang <richard.weiyang@...il.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/9] XArray: entry in last level is not expected to be a
 node

On Sun, Apr 05, 2020 at 02:56:36PM -0700, Matthew Wilcox wrote:
>On Sun, Apr 05, 2020 at 11:07:43AM +0000, Wei Yang wrote:
>> Occasionally, I see this error message without my change on 5.6.
>
>I've never seen this one before.  Maybe my test machine is insufficient ...
>
>> random seed 1586068185
>> running tests
>> XArray: 21151201 of 21151201 tests passed
>> =================================================================
>> ==6040==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c0031bce81 at pc 0x00000040b4b3 bp 0x7f95e87f9bb0 sp 0x7f95e87f9ba0
>> READ of size 1 at 0x60c0031bce81 thread T11
>>     #0 0x40b4b2 in xas_find_marked ../../../lib/xarray.c:1182
>>     #1 0x45318e in tagged_iteration_fn /root/git/linux/tools/testing/radix-tree/iteration_check.c:77
>>     #2 0x7f95ef2464e1 in start_thread (/lib64/libpthread.so.0+0x94e1)
>>     #3 0x7f95ee8026d2 in clone (/lib64/libc.so.6+0x1016d2)
>> 
>> 0x60c0031bce81 is located 1 bytes inside of 128-byte region [0x60c0031bce80,0x60c0031bcf00)
>> freed by thread T1 here:
>>     #0 0x7f95ef36c91f in __interceptor_free (/lib64/libasan.so.5+0x10d91f)
>>     #1 0x43e4ba in kmem_cache_free /root/git/linux/tools/testing/radix-tree/linux.c:64
>> 
>> previously allocated by thread T13 here:
>>     #0 0x7f95ef36cd18 in __interceptor_malloc (/lib64/libasan.so.5+0x10dd18)
>>     #1 0x43e1af in kmem_cache_alloc /root/git/linux/tools/testing/radix-tree/linux.c:44
>> 
>> Thread T11 created by T0 here:
>>     #0 0x7f95ef299955 in pthread_create (/lib64/libasan.so.5+0x3a955)
>>     #1 0x454862 in iteration_test /root/git/linux/tools/testing/radix-tree/iteration_check.c:178
>> 
>> Thread T1 created by T0 here:
>>     #0 0x7f95ef299955 in pthread_create (/lib64/libasan.so.5+0x3a955)
>>     #1 0x7f95ef235b89  (/lib64/liburcu.so.6+0x3b89)
>> 
>> Thread T13 created by T0 here:
>>     #0 0x7f95ef299955 in pthread_create (/lib64/libasan.so.5+0x3a955)
>>     #1 0x4548a4 in iteration_test /root/git/linux/tools/testing/radix-tree/iteration_check.c:186
>> 
>> This is not always like this. Didn't figure out the reason yet. Hope you many
>> have some point.
>
>How often are you seeing it?
>

Didn't do a strict analysis. My intuition feels 30% of reproduction.

>T1 (the thread which frees the memory) is the RCU thread, so the freeing
>went through RCU.  For some reason, T11 (the iterating thread) isn't
>preventing the freeing by its use of the RCU read lock.

Maybe this is the RCU problem. I didn't manage to install liburcu from rpm,
but build it from source.

-- 
Wei Yang
Help you, Help me