From patchwork Tue Jun 7 06:55:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pratyush Anand X-Patchwork-Id: 9159931 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 971B660467 for ; Tue, 7 Jun 2016 06:57:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8489C265F9 for ; Tue, 7 Jun 2016 06:57:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7722928326; Tue, 7 Jun 2016 06:57:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 957FE265F9 for ; Tue, 7 Jun 2016 06:57:32 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1bAAvW-0004YT-0H; Tue, 07 Jun 2016 06:55:50 +0000 Received: from mail-qk0-f174.google.com ([209.85.220.174]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1bAAvS-0004Ui-1W for linux-arm-kernel@lists.infradead.org; Tue, 07 Jun 2016 06:55:47 +0000 Received: by mail-qk0-f174.google.com with SMTP id s186so63995726qkc.1 for ; Mon, 06 Jun 2016 23:55:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=LKoff29iIyzwTB3/i2eBlplAryelKEu0Ev/g9YugVvw=; b=nOCzdO/+EwRliPtRhODpgDs3OA7Roo9MU0xnqnqoxnZQ5tEqwMApAfxBuZkj7LbnHe WqT0gze5QQU5HqW0W0HPL9n845lla+/geREOvlA6pozEhMSGOreS0MgxJGysh3vBUuBa RBYUoR+48QmGZwy2r0k83eaLPGhR84Sl+Qdm54JWM8cr/kIovQP0KV/McvXgFMM62clf 4cWzBkLiCBc2T6iHWOkQXrKJHNhaqmFtoEhi4Csp2LOjwfEYpvGNhAwN8x+KGeayHoFV KTfg3lBouoo7e07Ie3rzK6tNem2Fuje6fdtjn+m+OV5kWwFoAYDM3F//oKD9Jl30a4gP q5Qw== X-Gm-Message-State: ALyK8tKuAD4gefzLMoQ3xJueRubuPvNHtxk3T35fWMJG24pHcLk57kFNtFkJRitb9FDDnKYr X-Received: by 10.55.165.69 with SMTP id o66mr19954061qke.153.1465282524807; Mon, 06 Jun 2016 23:55:24 -0700 (PDT) Received: from localhost ([122.177.184.68]) by smtp.gmail.com with ESMTPSA id 34sm6823327qtm.36.2016.06.06.23.55.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 23:55:24 -0700 (PDT) Date: Tue, 7 Jun 2016 12:25:20 +0530 From: Pratyush Anand To: Will Deacon Subject: Re: Support for unaligned watchpoints in arm/arm64 Message-ID: <20160607065520.GD13643@dhcppc6> References: <20160531123827.GF24936@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160531123827.GF24936@arm.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160606_235546_189574_46069F9B X-CRM114-Status: GOOD ( 24.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, Pavel Labath , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 31/05/2016:01:38:27 PM, Will Deacon wrote: > On Thu, May 26, 2016 at 05:04:46PM +0100, Pavel Labath wrote: > > Hello all, > > Hi Pavel, > > > I've been wondering if there are any plans about adding support for > > unaligned watchpoints to the kernel. It seems quite a shame that > > applications are not able not use them, even though the hardware > > should support that feature. > > I'm actually coming round to the idea of ditching the perf hw_breakpoint > mechanism entirely and simply writing a ptrace back-end that can expose > the hardware features directly to userspace. The two issues with this > are: > > (1) It's a fair amount of work So, by the time this new interface would come, probably we can consider a fixup like following to resolve this issue at hand. Probably, things should work by just allowing hw_breakpoint.c to pass checks for unaligned offset when it is a WATCHPOINT, no? return 0; @@ -430,7 +435,11 @@ static int arch_build_bp_info(struct perf_event *bp) info->ctrl.len = ARM_BREAKPOINT_LEN_8; break; default: - return -EINVAL; + if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE + || bp->attr.bp_len < HW_BREAKPOINT_LEN_1 + || bp->attr.bp_len > HW_BREAKPOINT_LEN_8) + return -EINVAL; + info->ctrl.len = (1 << bp->attr.bp_len) - 1; } /* @Pavel, does above patch helps to resolve the issue. ~Pratyush > (2) We might already have users of the perf interface (including compat) > > I'm really not happy with the way hw_breakpoint worked out :( > > Will > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c index 26a6bf77d272..c803347c1413 100644 --- a/arch/arm64/kernel/hw_breakpoint.c +++ b/arch/arm64/kernel/hw_breakpoint.c @@ -384,7 +384,12 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl, *gen_len = HW_BREAKPOINT_LEN_8; @@ -384,7 +384,12 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl, *gen_len = HW_BREAKPOINT_LEN_8; break; default: - return -EINVAL; + if (ctrl.type == ARM_BREAKPOINT_EXECUTE + || ctrl.len & (ctrl.len + 1) + || ctrl.len < ARM_BREAKPOINT_LEN_1 + || ctrl.len > ARM_BREAKPOINT_LEN_8) + return -EINVAL; + *gen_len = ffs(ctrl.len + 1) - 1; }