From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1035050AbcIWO6R (ORCPT ); Fri, 23 Sep 2016 10:58:17 -0400 Received: from sender153-mail.zoho.com ([74.201.84.153]:25390 "EHLO sender153-mail.zoho.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1035014AbcIWO6N (ORCPT ); Fri, 23 Sep 2016 10:58:13 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:cc:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=EB12P2Y6AyWzMGucm89zmmgXuT8r3DnfCVjhsQWtS7gHAwW2s3cYFeHicmzmNaTEzdOCYJkvsTJ8 Z1hN2AjJ4qNxdeGXqrNaN+Es6ZbwX3AMhjYjd0SzrnH4mHlSCz/2 Subject: Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges To: Michal Hocko References: <57E20A69.5010206@zoho.com> <20160922124735.GB11204@dhcp22.suse.cz> <35661a34-c3e0-0ec2-b58f-ee59bef4e4d4@zoho.com> <20160923084551.GG4478@dhcp22.suse.cz> <20160923124244.GN4478@dhcp22.suse.cz> <57E52762.9000702@zoho.com> <20160923133330.GO4478@dhcp22.suse.cz> <20160923142700.GS4478@dhcp22.suse.cz> Cc: zijun_hu@htc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , tj@kernel.org, mingo@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, mgorman@techsingularity.net From: zijun_hu Message-ID: Date: Fri, 23 Sep 2016 22:58:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160923142700.GS4478@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/9/23 22:27, Michal Hocko wrote: > On Fri 23-09-16 22:14:40, zijun_hu wrote: >> On 2016/9/23 21:33, Michal Hocko wrote: >>> On Fri 23-09-16 21:00:18, zijun_hu wrote: >>>> On 09/23/2016 08:42 PM, Michal Hocko wrote: >>>>>>>> no, it don't work for many special case >>>>>>>> for example, provided PMD_SIZE=2M >>>>>>>> mapping [0x1f8800, 0x208800) virtual range will be split to two ranges >>>>>>>> [0x1f8800, 0x200000) and [0x200000,0x208800) and map them separately >>>>>>>> the first range will cause dead loop >>>>>>> >>>>>>> I am not sure I see your point. How can we deadlock if _both_ addresses >>>>>>> get aligned to the page boundary and how does PMD_SIZE make any >>>>>>> difference. >>>>>>> >>>>>> i will take a example to illustrate my considerations >>>>>> provided PUD_SIZE == 1G, PMD_SIZE == 2M, PAGE_SIZE == 4K >>>>>> it is used by arm64 normally >>>>>> >>>>>> we want to map virtual range [0xffffffff_ffc08800, 0xffffffff_fffff800) by >>>>>> ioremap_page_range(),ioremap_pmd_range() is called to map the range >>>>>> finally, ioremap_pmd_range() will call >>>>>> ioremap_pte_range(pmd, 0xffffffff_ffc08800, 0xffffffff_fffe0000) and >>>>>> ioremap_pte_range(pmd, 0xffffffff_fffe0000, 0xffffffff fffff800) separately >>>>> >>>>> but those ranges are not aligned and it ioremap_page_range fix them up >>>>> to _be_ aligned then there is no problem, right? So either I am missing >>>>> something or we are talking past each other. >>>>> >>>> my complementary considerations are show below >>>> >>>> why not to round up the range start boundary to page aligned? >>>> 1, it don't remain consistent with the original logic >>>> take map [0x1800, 0x4800) as example >>>> the original logic map range [0x1000, 0x2000), but rounding up start boundary >>>> don't mapping the range [0x1000, 0x2000) >>> >>> just look at how we do that for the mmap... >> >> okay >> i don't familiar with mmap code very well now > > mmap basically does addr &= PAGE_MASK (modulo mmap_min_addr) and > len = PAGE_ALIGN(len). > > this is [star, end) raher than [start, start+len) but you should get the > point I guess. > you are right this patch is consistent with that you pointed for map virtual range [0x80000800, 0x80007800) to physical area[0x20000800, 0x20007800) it actually map range [0x80000000, 0x80008000) to physical area[0x20000000, 0x20008000) maybe expanding range [0x80000800, 0x80007800) to [0x80000000, 0x80008000) is better than shrinking to [0x80001000, 0x80007000) because the following reasons 1. if a user is mapping [0x80000800, 0x80007800) -> [0x20000800, 0x20007800), he/she expect to access physical address 0x20000800 by virtual address 0x80000800, expanding range do the right thing but shrinking will cause address fault 2. shrinking will cause not enough virtual range [0x80001000, 0x80007000) to mapping physical area [0x20000800, 0x20007800) 3. this is no need to round up parameter end to page boundary to expand the end limit, it has less modification for code BTW there are many page table operations to using this similar logic, maybe a universal fixing is used to all, not just lib/ioremap.c or mm/vmalloc.c