From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751749AbbLZMcR (ORCPT ); Sat, 26 Dec 2015 07:32:17 -0500 Received: from mout.gmx.net ([212.227.15.15]:55837 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbbLZMcO (ORCPT ); Sat, 26 Dec 2015 07:32:14 -0500 Subject: Re: [GIT PULL] parisc huge page support for v4.4 To: Mikulas Patocka References: <20151122115153.GA28471@p100.box> <5654892D.1030707@gmx.de> <20151124170020.GA13198@p100.box> Cc: Linus Torvalds , linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org, James Bottomley , John David Anglin From: Helge Deller Message-ID: <567E88BA.4010607@gmx.de> Date: Sat, 26 Dec 2015 13:31:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4TDcNBorHLQIdnEXx3YvrcfyscTMN4FeUo5GteKUQXNs+RPm7lb h3+azX6CrcFdse8XBXK8NLslsLzHH4/zqHFa9S3KhIp25ObvfM4LRYMpS1U06o4M1xOmR9k gKIn6Ty1+bWFk/OQxMvRTJDoxp5moRzec6SnBcxGUfgTp49L2gpF36xapdmnRrDqZvJFsnx ZXJdmwd6HLpWDpucZeSiA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Xk022KtEKeo=:sI9FY7tE4MeH2rxvrVUEOR oiOsk4I9n9Ux40Ia5Lil+O/joqTaPp8naFt3ZKAGP9nsmKAZ8zLmnGO2jYm/WFVljX4lmnsd6 osw2r8yeLejBplLF6Szw6JmLrnENDFrO36lqTLZ0QDVZgpGfqh5e56U6hfNFsy4vvETYm3soA 0vankvFJViqq8H7yEwNxWjhWjba5eVS93W+ueZzRSnVEKIWHpu3rWJqvS1J1iJ57N62e0b3qd 2pJYM4smcu5fnMOh3tXFR+ilYRDfvSNnTx88rIZcycf3cCFL5b91uMIRFhBB5wMI1vTwzPCWS L+w77GiTF7xSwrdagYmq+akoaqPim6rYApJ/IS99SuDur56i3zm1+Nr5FuMqnxUy897hHTCxG uHqsRQVudPosfs7ZN/fmgixsK2HCvIWI2a53skPP7GoC+D2dLNRcNTcMPproy68K3GYADN1PJ udQvndBoHpl5WNp5Em4tmADwJ9lg2rp+1opncCjAfH3PYVo60K1SB6lGHlM7M+Z4sCZnTYZiQ KE90UShNKWTGD6RT+ZuwnfitsCkJ9YfqWC8zgdRA9VKElJ31jNMQHrKjhY6Fre82DQbUTurVs XmSOWpSvJIgxbh8GhMndFe3OXf1iFavIublpGAgpJI+WSC0/kia0yDsodpyjGq7kVlUtv9pz1 s/ODkC3VeHB1pn01oE5FvPXNJ9P334yVJ5tsWN9lk+h1weym74Dkdv/YIq3jHXJlJguhS3d43 KE1OOcixz/CPRLytg/uV2aV0S+JUjB3N4nDcKCjWnT2N21rO8lB4nsNXOZRp33X5b8F+pTsYY /xylRWp Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26.12.2015 13:09, Mikulas Patocka wrote: >> On Tue, 24 Nov 2015, Helge Deller wrote: >>> * Mikulas Patocka : >>>> On Tue, 24 Nov 2015, Helge Deller wrote: >>>>>> Hi >>>>>> >>>>>> Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. >>>>>> When I revert this patchset, the crashes are gone. >>>>> >>>>>> [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online >>>>> >>>>> Hi Mikulas, >>>>> >>>>> Yes, I've seen this as well. >>>>> It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. >>>>> I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. >>>>> I'm still investigating why it only affects the PA8900 CPUs, but I assume >>>>> it's related to the cache aliasing of those CPUs. >>>>> I'll keep you updated. >>>>> >>>>> Helge >>>> >>>> The PA-RISC specification doesn't allow aliasing on non-equaivalent >>>> addresses. Can the kernel map a piece of kernel data to other virtual >>>> address? If yes, we can't use big pages to map kernel data. >>> >>> Can you please try the two patches below? >>> The first one disables mapping kernel text/data on huge pages on >>> PA8800/PA8900 CPUs. Patch works for me on my Mako PA8800. >>> >>> Independend of my huge page patch the second patch disables the tlb >>> flush optimization we added earlier. It seems calling flush_tlb_all() >>> doesn't reliably flushes tlbs on all CPUs so it's better to fall back to >>> the loop implementation. >>> >>> Helge >> >> The kernel with these patches works fine so far. >> >> Mikulas > > BTW. I looked at this in arch/parisc/mm/hugetlbpage.c:set_huge_pte_at > "*ptep = entry;" and it seems like a bad bug. PA-RISC doesn't have atomic > instructions to modify page table entries, so it takes spinlock in the TLB > handler and modifies the page table entry non-atomically. If you modify > the page table entry without the spinlock, you may race with TLB handler > on another CPU and your modification may be lost. Right. > The comment says something about double locking on pa_tlb_lock, but > pa_tlb_lock isn't held when that function is called. I have a work-in-progress patch for that in one of my trees, e.g.: http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=parisc-next&id=5c76b525cbdb097401f46522b27b1eb6244f34f9 It's lightly tested though. Helge