From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755858AbbFBGyi (ORCPT ); Tue, 2 Jun 2015 02:54:38 -0400 Received: from m13-125.163.com ([220.181.13.125]:44084 "EHLO m13-125.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752814AbbFBGya (ORCPT ); Tue, 2 Jun 2015 02:54:30 -0400 X-Originating-IP: [113.240.220.93] Date: Tue, 2 Jun 2015 14:54:27 +0800 (CST) From: weiqi To: linux-kernel@vger.kernel.org Subject: PROBLEM: infinite loop do_sparc64_fault with fault_code 2 X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20150119(59087.7062) Copyright (c) 2002-2015 www.mailtech.cn 163com Content-Type: text/plain; charset=UTF-8 MIME-Version: 1.0 Message-ID: <5a046f53.195cb.14db30cc3a3.Coremail.wei_qi_k@163.com> X-CM-TRANSID: fcGowECpu0IkU21VcaMsAA--.1580W X-CM-SenderInfo: 5zhls1xlbnqiywtou0bp/1tbipRMN21UL40g8mwABsz X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t526sgl9018038 Hello,    Everyone        Nearly, I'm working on a sparc64 machine with linux-2.6.32 (32 cores, SMP) ,64bit kernel and userspace is 32bit.        when I run LTP test case with command :"./kill10 -c100 -g 1 -n 1",  It will trap in  an infinite page_fault   loop  occasionally.  and  one of the kill10 process will  use 100% CPU . (easy to repeat, just run command again and again)        After some debug, I find :       1) the fault address is the same, and always at kill10's user-stack, for example "0xffb0b470".       2) the fault  happend when kill10 handle signal at  put_user()  , code path: arch/sparc/kernel/signal32.c: setup_frame32()  --> put_user().       3) The first  fault is handled by do_wp_page() because of COW,  and then do_wp_page() found PageAnon(old_page)  then reuse old_page.      4) then go into  infinite loop  fault  with fault_code 2 (D-TLB miss), and  handled by handle_pte_fault() out at flush_tlb_page()  which has a comment :                 /*                  * This is needed only for protection faults but the arch code                  * is not yet telling us if this is a protection fault or not.                  * This still avoids useless tlb flushes for .text page faults                  * with threads.                  */                    if (flags & FAULT_FLAG_WRITE)                         flush_tlb_page(vma, address);      I'v also tested  with linux-3.10,  and almost same result.      I know sparc has software tlb process,  In the function do_wp_page(), it will call flush_tlb_page() and update_mmu_cache() , but It seems  no effect, just   D-TLB miss  infinitely at same address {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I