From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755149AbcHXBNs (ORCPT ); Tue, 23 Aug 2016 21:13:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38878 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753269AbcHXBNq (ORCPT ); Tue, 23 Aug 2016 21:13:46 -0400 Date: Tue, 23 Aug 2016 21:13:00 -0400 From: Jessica Yu To: Masami Hiramatsu , Petr Mladek Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: livepatch/kprobes incompatibility Message-ID: <20160824011300.GA31704@packer-debian-8-amd64.digitalocean.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 24 Aug 2016 01:13:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Masami, Petr, I'm trying to figure out where we are exactly with fixing the problems with livepatch + kprobes, and I was wondering if there will be any more updates to the ipmodify patchset that was originally merged back in 2014 (See: https://lkml.org/lkml/2014/11/20/808). It seems that patch 4/5 ("kprobes: Set IPMODIFY flag only if the probe can change regs->ip") wasn't merged due to other ongoing work, and this patch in particular was needed to enforce a hard conflict between livepatch and jprobes while still enabling livepatch and kprobes to co-exist. Currently, it looks like livepatch/kpatch and kprobes are still in direct conflict, since both kprobe_ftrace_ops and klp_ops have FTRACE_OPS_FL_IPMODIFY set. *But* it seems like this mutual exclusion wasn't 100% implemented; I'm not sure if this was intentional, but kprobes registration will still return success even when ftrace registration fails due to an ipmodify conflict, and instead we just get WARNs (See: arm_kprobe_ftrace()). So we still end up with buggy situations like the following: (1) livepatch patches meminfo_proc_show [ succeeds ] (2) systemtap probes meminfo_proc_show (using kprobes) [ fails ] * BUT from the user's perspective, it would look like systemtap succeeded, since register_kprobe() returned success, but the handler will never fire and only when we look at dmesg do we see that something went wrong (i.e. ftrace registration had failed since livepatch already reserved ipmodify in step 1). >>From what I understand though, there was work being planned to limit this direct conflict to just livepatch and jprobes, since most of the time kprobes doesn't change regs->ip. Just wondering what the current state of this work is. Thanks, Jessica