From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753165AbdBGHwH (ORCPT ); Tue, 7 Feb 2017 02:52:07 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40199 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751865AbdBGHwE (ORCPT ); Tue, 7 Feb 2017 02:52:04 -0500 Date: Tue, 7 Feb 2017 13:21:53 +0530 From: "Naveen N. Rao" To: Masami Hiramatsu Cc: Michael Ellerman , Anju T Sudhakar , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, ananth@in.ibm.com, mahesh@linux.vnet.ibm.com, paulus@samba.org, srikar@linux.vnet.ibm.com Subject: Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes References: <1482153507-17350-1-git-send-email-anju@linux.vnet.ibm.com> <1482153507-17350-2-git-send-email-anju@linux.vnet.ibm.com> <87a8a6dvwo.fsf@concordia.ellerman.id.au> <20170203193949.GD4090@naverao1-tp.localdomain> <20170207100541.7860e846f3def13a628bb05d@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170207100541.7860e846f3def13a628bb05d@kernel.org> User-Agent: Mutt/1.6.2 (2016-07-01) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17020707-0020-0000-0000-000000B4A00B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17020707-0021-0000-0000-0000026FB809 Message-Id: <20170207075153.GI4090@naverao1-tp.localdomain> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-07_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702070078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017/02/07 10:05AM, Masami Hiramatsu wrote: > On Sat, 4 Feb 2017 01:09:49 +0530 > "Naveen N. Rao" wrote: > > > Hi Michael, > > Thanks for the review! I'll defer to Anju on most of the aspects, but... > > > > On 2017/02/01 09:53PM, Michael Ellerman wrote: > > > Anju T Sudhakar writes: > > > > > > > +static void optimized_callback(struct optimized_kprobe *op, > > > > + struct pt_regs *regs) > > > > +{ > > > > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); > > > > + unsigned long flags; > > > > + > > > > + /* This is possible if op is under delayed unoptimizing */ > > > > + if (kprobe_disabled(&op->kp)) > > > > + return; > > > > + > > > > + local_irq_save(flags); > > > > > > What is that protecting against? Because on powerpc it doesn't actually > > > disable interrupts, it just masks some of them, the perf interrupt for > > > example can still run. > > > > That's an excellent catch, as always! :) > > > > This is meant to prevent us from missing kprobe hits while processing > > interrupts that arrive when this optprobe is being handled. And you are > > totally right -- we would miss kprobe hits during PMI handling with the > > current approach. We need a hard_irq_disable() there. > > One note: it depends on the arch implementation of kprobes, since this > is only for "emulating" the int3 behavior on x86 for compatibility. > On x86, int3 is disabling interrupt automatically, so all the kprobes > user handlers will be run under irq-disabled. This means that user may > write their code to run as such condition. They even can not know > that is optimized or not at programming timing, because the kprobe > will be optimized after a while from enabled it. > > So the important point is that you have to keep it compatible of > unoptimized kprobes. Thanks for the pointers, Masami. Yes, with unoptimized kprobes on powerpc, we run with interrupts hard disabled as well. So, we need to hard disable for optprobes too. Regards, Naveen