[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59278B13.4070304@huawei.com>
Date: Fri, 26 May 2017 09:55:31 +0800
From: zhong jiang <zhongjiang@...wei.com>
To: Wei Yang <richard.weiyang@...il.com>
CC: <akpm@...ux-foundation.org>, <mhocko@...e.com>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area()
On 2017/5/26 9:36, Wei Yang wrote:
> On Thu, May 25, 2017 at 11:04:44AM +0800, zhong jiang wrote:
>> I hit the overlap issue, but it is hard to reproduced. if you think it is safe. and the situation
>> is not happen. AFAIC, it is no need to add the code.
>>
>> if you insist on the point. Maybe VM_WARN_ON is a choice.
>>
> Do you have some log to show the overlap happens?
Hi wei
cat /proc/vmallocinfo
0xf1580000-0xf1600000 524288 raw_dump_mem_write+0x10c/0x188 phys=8b901000 ioremap
0xf1638000-0xf163a000 8192 mcss_pou_queue_init+0xa0/0x13c [mcss] phys=fc614000 ioremap
0xf528e000-0xf5292000 16384 n_tty_open+0x10/0xd0 pages=3 vmalloc
0xf5000000-0xf9001000 67112960 devm_ioremap+0x38/0x70 phys=40000000 ioremap
0xfe001000-0xfe002000 4096 iotable_init+0x0/0xc phys=20001000 ioremap
0xfe200000-0xfe201000 4096 iotable_init+0x0/0xc phys=1a000000 ioremap
0xff100000-0xff101000 4096 iotable_init+0x0/0xc phys=2000a000 ioremap
I hit the above issue, but the log no more useful info. it just is found by accident.
and it is hard to reprodeced. no more info can be supported for further investigation.
therefore, it is no idea for me.
Thanks
zhongjinag
Powered by blists - more mailing lists