From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934020AbaD2MYK (ORCPT ); Tue, 29 Apr 2014 08:24:10 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:56331 "EHLO e23smtp05.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932982AbaD2MYJ (ORCPT ); Tue, 29 Apr 2014 08:24:09 -0400 Message-ID: <535F997B.3000500@linux.vnet.ibm.com> Date: Tue, 29 Apr 2014 17:52:19 +0530 From: Anshuman Khandual User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Neuling CC: avagin@openvz.org, roland@redhat.com, oleg@redhat.com, Linux PPC dev , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] Add new ptrace request macros on PowerPC References: <1396422144-11032-1-git-send-email-khandual@linux.vnet.ibm.com> <533BD922.4070009@linux.vnet.ibm.com> <535F4E10.2020300@linux.vnet.ibm.com> <535F5BDE.2030309@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14042912-1396-0000-0000-000004C202C6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/29/2014 01:52 PM, Michael Neuling wrote: > That's not what that patch does. It shouldn't make any user visible changes > to DSCR or PPR. It may not when it runs uninterrupted but after the tracee process has stopped, thread.dscr reflects the default DSCR value as mentioned before. This can be proved by changing the "dscr_default" value in arch/powerpc/sysfs.c file. > > Over syscall PPR and DSCR may change. Depending on your test case, that may > be your problem. I would guess when the tracee process stops for ptrace analysis, tm_reclaim or tm_recheckpoint path might be crossed which is causing this dscr_default value to go into thread_struct. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id B0058140098 for ; Tue, 29 Apr 2014 22:24:06 +1000 (EST) Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 Apr 2014 22:24:05 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id B6A6D2CE8047 for ; Tue, 29 Apr 2014 22:24:01 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s3TCNkkb9634188 for ; Tue, 29 Apr 2014 22:23:46 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s3TCO0E3016182 for ; Tue, 29 Apr 2014 22:24:00 +1000 Message-ID: <535F997B.3000500@linux.vnet.ibm.com> Date: Tue, 29 Apr 2014 17:52:19 +0530 From: Anshuman Khandual MIME-Version: 1.0 To: Michael Neuling Subject: Re: [PATCH 0/3] Add new ptrace request macros on PowerPC References: <1396422144-11032-1-git-send-email-khandual@linux.vnet.ibm.com> <533BD922.4070009@linux.vnet.ibm.com> <535F4E10.2020300@linux.vnet.ibm.com> <535F5BDE.2030309@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Cc: Linux PPC dev , linux-kernel@vger.kernel.org, avagin@openvz.org, roland@redhat.com, oleg@redhat.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 04/29/2014 01:52 PM, Michael Neuling wrote: > That's not what that patch does. It shouldn't make any user visible changes > to DSCR or PPR. It may not when it runs uninterrupted but after the tracee process has stopped, thread.dscr reflects the default DSCR value as mentioned before. This can be proved by changing the "dscr_default" value in arch/powerpc/sysfs.c file. > > Over syscall PPR and DSCR may change. Depending on your test case, that may > be your problem. I would guess when the tracee process stops for ptrace analysis, tm_reclaim or tm_recheckpoint path might be crossed which is causing this dscr_default value to go into thread_struct.