From mboxrd@z Thu Jan 1 00:00:00 1970 From: cuibixuan@huawei.com (Bixuan Cui) Date: Tue, 17 Oct 2017 20:42:24 +0800 Subject: =?UTF-8?B?44CQQlVH44CRVGhlIGtlcm5lbCBzdGFydCBmYWlsIHdoZW4gZW4=?= =?UTF-8?B?YWJsZSBDT05GSUdfQVJNNjRfTFNFX0FUT01JQ1MgYW5kIEtDT1ZfSU5TVFJVTUU=?= =?UTF-8?B?TlRfQUxM?= In-Reply-To: <20171017110210.fz7srr2p5jiawvkg@lakrids.cambridge.arm.com> References: <59E59B1B.9030206@huawei.com> <20171017110210.fz7srr2p5jiawvkg@lakrids.cambridge.arm.com> Message-ID: <59E5FAB0.5030801@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > This is a known issue [1,2] that's being worked on at the moment. > > The problem is that the out-of-line LL/SC atomics are built with a > special ABI, but KCOV inserts calls to other code that does not follow > this ABI, resulting in register corruption. > > When I saw this happen, this resulted in cmpxchg() spuriously failing > somewhere in the page init code, which looks similar to what you're > seeing. > > The patch at [1] is sufficient to work around this for the time being. Thank you for your explanation :-D . Thanks, Bixuan Cui > > Thanks, > Mark. > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-September/533105.html > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/537018.html > >> >> After I try kernel v4.13 and it's the same result. >> I trace the code and find it stop at the end of '__init_single_page(page, pfn, zone, nid)' in memmap_init_zone() of mm/page_alloc.c ? >> >> static void __meminit __init_single_page(struct page *page, unsigned long pfn, >> unsigned long zone, int nid) >> { >> set_page_links(page, zone, nid, pfn); >> init_page_count(page); >> page_mapcount_reset(page); >> page_cpupid_reset_last(page); >> >> INIT_LIST_HEAD(&page->lru); >> >> #ifdef WANT_PAGE_VIRTUAL >> /* The shift won't overflow because ZONE_NORMAL is below 4G. */ >> if (!is_highmem_idx(zone)) >> set_page_address(page, __va(pfn << PAGE_SHIFT)); >> #endif >> // printk("stop here\n"); >> } >> >> Anyone can give me advice? >> >> Thanks, >> Bixuan Cui >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > . > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758719AbdJQMpD (ORCPT ); Tue, 17 Oct 2017 08:45:03 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:8481 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758013AbdJQMpC (ORCPT ); Tue, 17 Oct 2017 08:45:02 -0400 Message-ID: <59E5FAB0.5030801@huawei.com> Date: Tue, 17 Oct 2017 20:42:24 +0800 From: Bixuan Cui User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Rutland CC: , "Libin (Huawei)" , Subject: Re: =?UTF-8?B?44CQQlVH44CRVGhlIGtlcm5lbCBzdGFydCBmYWlsIHdoZW4gZW4=?= =?UTF-8?B?YWJsZSBDT05GSUdfQVJNNjRfTFNFX0FUT01JQ1MgYW5kIEtDT1ZfSU5TVFJVTUU=?= =?UTF-8?B?TlRfQUxM?= References: <59E59B1B.9030206@huawei.com> <20171017110210.fz7srr2p5jiawvkg@lakrids.cambridge.arm.com> In-Reply-To: <20171017110210.fz7srr2p5jiawvkg@lakrids.cambridge.arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.177.222.129] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59E5FB20.011A,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 94c0740376453643fc07d008e98e064a Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > This is a known issue [1,2] that's being worked on at the moment. > > The problem is that the out-of-line LL/SC atomics are built with a > special ABI, but KCOV inserts calls to other code that does not follow > this ABI, resulting in register corruption. > > When I saw this happen, this resulted in cmpxchg() spuriously failing > somewhere in the page init code, which looks similar to what you're > seeing. > > The patch at [1] is sufficient to work around this for the time being. Thank you for your explanation :-D . Thanks, Bixuan Cui > > Thanks, > Mark. > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-September/533105.html > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/537018.html > >> >> After I try kernel v4.13 and it's the same result. >> I trace the code and find it stop at the end of '__init_single_page(page, pfn, zone, nid)' in memmap_init_zone() of mm/page_alloc.c ： >> >> static void __meminit __init_single_page(struct page *page, unsigned long pfn, >> unsigned long zone, int nid) >> { >> set_page_links(page, zone, nid, pfn); >> init_page_count(page); >> page_mapcount_reset(page); >> page_cpupid_reset_last(page); >> >> INIT_LIST_HEAD(&page->lru); >> >> #ifdef WANT_PAGE_VIRTUAL >> /* The shift won't overflow because ZONE_NORMAL is below 4G. */ >> if (!is_highmem_idx(zone)) >> set_page_address(page, __va(pfn << PAGE_SHIFT)); >> #endif >> // printk("stop here\n"); >> } >> >> Anyone can give me advice? >> >> Thanks, >> Bixuan Cui >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > . >