From: zhong jiang <zhongjiang@huawei.com> To: Wei Yang <richard.weiyang@gmail.com> Cc: <akpm@linux-foundation.org>, <mhocko@suse.com>, <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area() Date: Fri, 2 Jun 2017 10:26:06 +0800 [thread overview] Message-ID: <5930CCBE.4030802@huawei.com> (raw) In-Reply-To: <20170602014549.GA10347@WeideMBP.lan> On 2017/6/2 9:45, Wei Yang wrote: > On Fri, May 26, 2017 at 09:55:31AM +0800, zhong jiang wrote: >> 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 > These two ranges overlap. > > This is hard to say where is the problem. From the code point of view, I don't > see there is possibility to allocate an overlapped range. > > Which version of your kernel? > Hard to reproduce means just see once? yes, just once. I have also no see any problem from the code. The kernel version is linux 4.1. but That indeed exist. Thanks zhongjiang >> 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 >>
WARNING: multiple messages have this Message-ID (diff)
From: zhong jiang <zhongjiang@huawei.com> To: Wei Yang <richard.weiyang@gmail.com> Cc: akpm@linux-foundation.org, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area() Date: Fri, 2 Jun 2017 10:26:06 +0800 [thread overview] Message-ID: <5930CCBE.4030802@huawei.com> (raw) In-Reply-To: <20170602014549.GA10347@WeideMBP.lan> On 2017/6/2 9:45, Wei Yang wrote: > On Fri, May 26, 2017 at 09:55:31AM +0800, zhong jiang wrote: >> 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 > These two ranges overlap. > > This is hard to say where is the problem. From the code point of view, I don't > see there is possibility to allocate an overlapped range. > > Which version of your kernel? > Hard to reproduce means just see once? yes, just once. I have also no see any problem from the code. The kernel version is linux 4.1. but That indeed exist. Thanks zhongjiang >> 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 >> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-06-02 2:26 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-24 10:03 [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area() Wei Yang 2017-05-24 10:03 ` Wei Yang 2017-05-24 12:11 ` Michal Hocko 2017-05-24 12:11 ` Michal Hocko 2017-05-24 15:07 ` Wei Yang 2017-05-25 5:39 ` Michal Hocko 2017-05-25 5:39 ` Michal Hocko 2017-05-25 3:04 ` zhong jiang 2017-05-25 3:04 ` zhong jiang 2017-05-26 1:36 ` Wei Yang 2017-05-26 1:55 ` zhong jiang 2017-05-26 1:55 ` zhong jiang 2017-06-02 1:45 ` Wei Yang 2017-06-02 2:26 ` zhong jiang [this message] 2017-06-02 2:26 ` zhong jiang 2017-06-03 2:28 ` Wei Yang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5930CCBE.4030802@huawei.com \ --to=zhongjiang@huawei.com \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.com \ --cc=richard.weiyang@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.