Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3411480ybl; Mon, 19 Aug 2019 18:27:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+wrwSzNSA3toc00cALcnXGWYxHtxo62ZkjGb/dfPMIblNI9Ec5P1VhXci0vfEie4qtqpb X-Received: by 2002:a17:90a:1b41:: with SMTP id q59mr20009223pjq.114.1566264453085; Mon, 19 Aug 2019 18:27:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566264453; cv=none; d=google.com; s=arc-20160816; b=A0yfJFMJapba9kz3rODnXEbprbrTdGqobRTHm8wBcpRX+jAV/lWxa59uPGMbuLo0vR GBg9J2t+rbGncEgWVhs1W6WM9R737uhWnLekLHtBDN2GFQp1gbhuUXfzcltOdiqUX4P3 41gBOtr3+L32s9Z9oc1jcBYfACsxj1/KDpZVTbRHz1c8lnNlJCfQtI4lWeVz9IFdLhv4 8U5AxEPHBWoqihYuA6D598rtr5RpQHvcgt3UEBHw6CgFiB9y71MapR/dzFJjOPltrbFN pRi2ZN4puf7pIsmC1ukP7/wvqXkvUNPMnougxHJZOi8y2pJWjcjy1/gc2n3FkoKXrNfc IOzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=nIUbOMmJ/E0/oxoqpCDRKKZSlsVwBIRmIfZMOXNreVE=; b=grPkEBQZTKb89p6Svpmit/G63LwH7cdvsAFAG/7hEfChFZnczK3qQXsSZUReHr31iW qt8zHV009w+QJ2qGpUKTSxgrVxUEjtpMIJplzNTaz8Mo+6aWpQ8J/h701feifDEecP8P Ah7KFBsmVtqZ+bvd+9yY1DThxbM9t83djugZeoQ5Qaus50DXtew1sYr9V6EM08jWN8LH UU0jAk4XdzVkaOyRjjj2dPuUPfxJUXukF60GbJS449TunoM8PrSgRnwPKXyQKv/Ky1Xf a/hU5VYKGdne0vyZT6B+6jq3pIyR8X+54sjUPk87f3HnheNYSxpyS6n3kdL6CpBC8/0g HqGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FNpmXbZ1; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 98si11296386ple.6.2019.08.19.18.27.17; Mon, 19 Aug 2019 18:27:33 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FNpmXbZ1; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728832AbfHTB0X (ORCPT + 99 others); Mon, 19 Aug 2019 21:26:23 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:32894 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728647AbfHTB0X (ORCPT ); Mon, 19 Aug 2019 21:26:23 -0400 Received: by mail-lj1-f193.google.com with SMTP id z17so3522218ljz.0; Mon, 19 Aug 2019 18:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nIUbOMmJ/E0/oxoqpCDRKKZSlsVwBIRmIfZMOXNreVE=; b=FNpmXbZ1lx/YCyO+nTSN7Qo/7qg1MM89bnr70fjrzymPENeBcOICjeJMcFkkgXo5UN 99nDxSYp7P79RZp2sP/akN1J8yzP85m7joZMHJcVh3c3bOymor3nQCsmsLpuULw/WSFI aF3KXevj+HDEH8LZKni4dh7O49aWotJZwRwOqjQdreFFsKq++QZduGyLYKajQZStXBng 84uVJ3H5LvsB6clrLmSrE9hxrmdvi7KTJTQqdR3T1ShnWHwUnEkQDMcJXrF4g6MUBatO jRenCyz5oQ0JQL5J/xpvdrJHwI/ABdmB6BSglQJzF4EXulgiiatyJuT94XzJE6mqo4OU Hk+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nIUbOMmJ/E0/oxoqpCDRKKZSlsVwBIRmIfZMOXNreVE=; b=bC4Meyca6iMS5fj7/zS2VkpfEhglC0ar/bLTeeC4lntDD8YVm2vXvCf559kfXpaVoe 43GD5YDxFgON1SNAGcvrMHyCZqZaFe7SGv2AKcfh204JMkG9KOiA8y4nlCO30PmFzf5c c9U4fO+Qbwr8gVoMOFmpTA4Yyr1WefjVZbQAunMApl8V2wHDJ2IBYuMZ6WAPVGABA4em LN5oVOddBm8gXejksajidnFdmxKA7Qx03VDrPC5np95/qBZpaoc/FBwzCZzW9wF/NRgK BnAcELwjNRPvoaSw8DcgAyMYBBDC2Sm/cr1EYeGTMhK6Xv/ertRpiqRL0+Yk5pehni+n bkXA== X-Gm-Message-State: APjAAAU0jV7Y4vzHGPeS6IchkrG4grn8eZ24vLFtRdVw2bIRsGd9bU0D WGIh6XHgUVLs8HhUl6IeBGihtTkXsVAQH4/5Xrk= X-Received: by 2002:a2e:89da:: with SMTP id c26mr850927ljk.214.1566264381062; Mon, 19 Aug 2019 18:26:21 -0700 (PDT) MIME-Version: 1.0 References: <20190816223149.5714-1-dxu@dxuuu.xyz> <20190816223149.5714-2-dxu@dxuuu.xyz> In-Reply-To: <20190816223149.5714-2-dxu@dxuuu.xyz> From: Alexei Starovoitov Date: Mon, 19 Aug 2019 18:26:09 -0700 Message-ID: Subject: Re: [PATCH v3 bpf-next 1/4] tracing/probe: Add PERF_EVENT_IOC_QUERY_PROBE ioctl To: Daniel Xu Cc: bpf , Song Liu , Yonghong Song , Andrii Nakryiko , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexei Starovoitov , Alexander Shishkin , Jiri Olsa , Namhyung Kim , LKML , Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 16, 2019 at 3:33 PM Daniel Xu wrote: > > It's useful to know [uk]probe's nmissed and nhit stats. For example with > tracing tools, it's important to know when events may have been lost. > debugfs currently exposes a control file to get this information, but > it is not compatible with probes registered with the perf API. > > While bpf programs may be able to manually count nhit, there is no way > to gather nmissed. In other words, it is currently not possible to > retrieve information about FD-based probes. > > This patch adds a new ioctl that lets users query nmissed (as well as > nhit for completeness). We currently only add support for [uk]probes > but leave the possibility open for other probes like tracepoint. > > Signed-off-by: Daniel Xu ... > +int perf_kprobe_event_query(struct perf_event *event, void __user *info) > +{ > + struct perf_event_query_probe __user *uquery = info; > + struct perf_event_query_probe query = {}; > + struct trace_event_call *call = event->tp_event; > + struct trace_kprobe *tk = (struct trace_kprobe *)call->data; > + u64 ncopy; > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + if (copy_from_user(&query, uquery, > + offsetofend(struct perf_event_query_probe, size))) > + return -EFAULT; > + > + ncopy = min_t(u64, query.size, sizeof(query)); > + query.nhit = trace_kprobe_nhit(tk); > + query.nmissed = tk->rp.kp.nmissed; > + > + if (copy_to_user(uquery, &query, ncopy)) > + return -EFAULT; shouldn't kernel update query.size before copying back? Otherwise how user space would know which fields were populated?