Received: by 10.223.164.202 with SMTP id h10csp3250205wrb; Tue, 28 Nov 2017 08:23:44 -0800 (PST) X-Google-Smtp-Source: AGs4zMZYnAGIifB1sbwSixz/OPRqXfx0e23//aHdn+imtLxgsG3C5bX5EIfyQeghlCuuJwbSpFGh X-Received: by 10.84.128.98 with SMTP id 89mr17033045pla.40.1511886224663; Tue, 28 Nov 2017 08:23:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511886224; cv=none; d=google.com; s=arc-20160816; b=gcL/KhnQqEOF3mKeEVZ0gH9RkaGu/p/9/99+7cHnT7LGE/r8BtcqP7c22AYy7tttoz tB0s+xNjwlMhYhxA5gr3FhENrfUhfRld9EQqOp5PW0wr0VmDi+h8TUZvKl/W7BWDGcjS gQPwcx9UvHkaWIZZrDNujLP+O9nsbZB2v68ejoLTBMgZw1LoWydq0cPMzm7W6s8+vMSf q286R1p2UwH+8FO4E4X3fcafQnGB/Ayz3CM1Ewxy80CbuhjZmKqwxM1dm5ckYUFIihUj E4b7yBFeJOYCq3cU7frk85UEtbqq++cpMYlnoDeqtHEyk3RVp3U1FFsC4sZ9CphP+3BH EC+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=RjJT8WR8e6AvKggtUJLjIfF2QFdTy+faUUQstmXcutY=; b=KwmMTSgJdsz2bGZrXIIlnsGHGaJzVawFpk2Eriuyx5qvsTMmAAKEaG6719pRCKy2DX NbQXkyCDVM0gr0trL4hf9kx/MrUqXNHWXNPxKUN0rGixnXucKosbHV5ljppEtqUyioBC pGuGpCHGYGJNgmQ6jypuEfzx+IwUWOlczkhadQ136EeE+wWe3pE7L+/2F7SNDkM0VQIG LiO3wxjMsGagc4HhT97ibGF175FacUs3E/6WWCCiYD81gc08Ki6heivGz394dlKj6co4 WFlwM3Lq8jEfIhNxZ5A5LQCUna9eG+sV1BjKw776fQsX1dS0kxGV2UbXfobHBNC5GMiT KigA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q11si6408256pli.140.2017.11.28.08.23.32; Tue, 28 Nov 2017 08:23:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753434AbdK1QWr (ORCPT + 77 others); Tue, 28 Nov 2017 11:22:47 -0500 Received: from www62.your-server.de ([213.133.104.62]:52790 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752402AbdK1QWp (ORCPT ); Tue, 28 Nov 2017 11:22:45 -0500 Received: from [194.230.159.120] (helo=localhost.localdomain) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.85_2) (envelope-from ) id 1eJied-0004jm-Ij; Tue, 28 Nov 2017 17:22:39 +0100 Subject: Re: [PATCH v7 0/4] Add the ability to do BPF directed error injection To: Josef Bacik , rostedt@goodmis.org, mingo@redhat.com, davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, kernel-team@fb.com, linux-btrfs@vger.kernel.org References: <1511385814-20863-1-git-send-email-josef@toxicpanda.com> From: Daniel Borkmann Message-ID: Date: Tue, 28 Nov 2017 17:22:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1511385814-20863-1-git-send-email-josef@toxicpanda.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.99.2/24081/Tue Nov 28 10:07:12 2017) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/22/2017 10:23 PM, Josef Bacik wrote: > This is hopefully the final version, I've addressed the comment by Igno and > added his Acks. > > v6->v7: > - moved the opt-in macro to bpf.h out of kprobes.h. > > v5->v6: > - add BPF_ALLOW_ERROR_INJECTION() tagging for functions that will support this > feature. This way only functions that opt-in will be allowed to be > overridden. > - added a btrfs patch to allow error injection for open_ctree() so that the bpf > sample actually works. > > v4->v5: > - disallow kprobe_override programs from being put in the prog map array so we > don't tail call into something we didn't check. This allows us to make the > normal path still fast without a bunch of percpu operations. > > v3->v4: > - fix a build error found by kbuild test bot (I didn't wait long enough > apparently.) > - Added a warning message as per Daniels suggestion. > > v2->v3: > - added a ->kprobe_override flag to bpf_prog. > - added some sanity checks to disallow attaching bpf progs that have > ->kprobe_override set that aren't for ftrace kprobes. > - added the trace_kprobe_ftrace helper to check if the trace_event_call is a > ftrace kprobe. > - renamed bpf_kprobe_state to bpf_kprobe_override, fixed it so we only read this > value in the kprobe path, and thus only write to it if we're overriding or > clearing the override. > > v1->v2: > - moved things around to make sure that bpf_override_return could really only be > used for an ftrace kprobe. > - killed the special return values from trace_call_bpf. > - renamed pc_modified to bpf_kprobe_state so bpf_override_return could tell if > it was being called from an ftrace kprobe context. > - reworked the logic in kprobe_perf_func to take advantage of bpf_kprobe_state. > - updated the test as per Alexei's review. > > - Original message - > > A lot of our error paths are not well tested because we have no good way of > injecting errors generically. Some subystems (block, memory) have ways to > inject errors, but they are random so it's hard to get reproduceable results. > > With BPF we can add determinism to our error injection. We can use kprobes and > other things to verify we are injecting errors at the exact case we are trying > to test. This patch gives us the tool to actual do the error injection part. > It is very simple, we just set the return value of the pt_regs we're given to > whatever we provide, and then override the PC with a dummy function that simply > returns. > > Right now this only works on x86, but it would be simple enough to expand to > other architectures. Thanks, Ok, given the remaining feedback from Ingo was addressed and therefore the series acked, I've applied it to bpf-next tree, thanks Josef. From 1584817768373798619@xxx Thu Nov 23 01:20:01 +0000 2017 X-GM-THRID: 1584803484086682204 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread