Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp523186ybh; Wed, 15 Jul 2020 08:12:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzepgyneJ65CER9IkOrQSRY13YnAK82Odsvc9ImYE1iX3RsRhLaRNwzqYZ5hysYVCs9fJaw X-Received: by 2002:aa7:da8a:: with SMTP id q10mr71733eds.139.1594825945290; Wed, 15 Jul 2020 08:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594825945; cv=none; d=google.com; s=arc-20160816; b=JsFYlx9s0mr0CEKcZS3ZAKDWpS0XdpkIJ2o0V4uVdiOTNaYesmoSEMTnmAnPxzg0+7 UDCwffTnq5L7y2WplvYInmSLnFn4IYNLESRdKw4kxmBmMjlHbvpT6Vl9dhUR74DsGL+q Pzut/yc9B/bdiHdd4/t/IpfwOAR6aKkfjSwwVP3b0/hvV5A6oA5QZPfLdqYcUiO6CliN mRsbua45+YY7CtK6B+TSEecDA6xx9sPFAwHwe3Rb4uPWoliUeCgUDQ3/Ciwmu8P30vH6 MP9qvBvqhi/b5Js9Inigng7T7ymBOnFMIjGLIlnPsp04Otxilk59umQF+g6QdqV8WZYF ZYgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:in-reply-to:cc:references:message-id :date:subject:mime-version:from:content-transfer-encoding :dkim-signature; bh=yhR2xx3ll78zXx4v/LleHZDLIGASUAw7oXjwdcYoQnM=; b=zLobL/bfXSQJNZlvvNovLJrKShdZldvOCK6MZLq1+G1KacYYqnTfDi102ztrI0psa1 XdL29CYBht5HqW+jjhg5bhoL8xbH+rDNFgtnpJ+yjsglDgwDT9J7uCRHkg6kGGP8R1g8 9cxwozAweh1Owa1x+RmB4TEyE8fLvaoQrLsVZUmgntFcEXilkDq9We6eQgli8f4PIJr2 X4O5i+F1k9B0EKPf0bClbAb4e3trPKCocfKWn+OfhOhWGlXg7r1hdFMrT+SlZU24Hfqc GRXW0F6/I6zPkkl8fL0mLkqY6P5L6q5xS7sNym1CrVqknoIi3H/bKN6XGms15gk42I5q NRYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=MBTmhayG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l5si1407631ejc.351.2020.07.15.08.12.02; Wed, 15 Jul 2020 08:12:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=MBTmhayG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729092AbgGOOf5 (ORCPT + 99 others); Wed, 15 Jul 2020 10:35:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729053AbgGOOfz (ORCPT ); Wed, 15 Jul 2020 10:35:55 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A308DC08C5DD for ; Wed, 15 Jul 2020 07:35:55 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id k4so2459196pld.12 for ; Wed, 15 Jul 2020 07:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=yhR2xx3ll78zXx4v/LleHZDLIGASUAw7oXjwdcYoQnM=; b=MBTmhayGzIbypNDEFm2+paSuwfcC+PzqE85tReoauMa8/vlEuTbLPAXgN9+8qVkcNT yGNU7gl/zluURp9BUENw3LJ4rFqKK/8Ff3aRUbs7uTkYSeZwW3aDJgw4Kt3y+YyUVgap 0Zoy3gWJ2MC50r6ZcK2DVZ/eywPJseJ4IQfjEcO37x2ua0wTNQCE2y3Qf9A5N9IFiZH3 TV20PfmuxIw8NVCsuD+kmZ/Sgqsg/HqB0qdOSMeiMCizUz5tGze/hYcp6asxJeM5mtMB DgMTMy20N6K6A7ufGOkrKyndioWzeqygDTq2Q7VudYC1FYDBSTz+eJgpCU7AeeAih/Ao uuaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=yhR2xx3ll78zXx4v/LleHZDLIGASUAw7oXjwdcYoQnM=; b=ePnacpqsmxPHKHoFdCdlKI+CzSFnrYqWf9wUU8dpX3iWJ1j8Q768eMPyeMvBSQtotk 2pFmol367oEbBUN3qEksOGVUpUyd4QsZ5GC4SfGPS38pOFpcmyiTE4Bra6G5eMdLyIzX ODxCFDW67XFAecvfDV/pSCHIlP59bazmb/6YGbLyGyyNrcV/cZRH/Nt4p1N4Opi76whv JLlBzUev4xCGDGjAucvlhZAICxW1+IrgUQeMeqH4DHGeZM0B8I4dMZGophKjzEwq2s6C zvmrXZ/49g7eSxMMZwTAnJly+qc56YlIla3JBvRMq09Bbg21CAAs/vhp2P+1/6XyLSi6 G8Aw== X-Gm-Message-State: AOAM5303rQBsqVBRCgDgY08z/+QmAM2k2qYKhnCmWoaa0geIfPDKFOjY ++maJKjGd2RmMDfB5ld6FpucmpnDpBdanw== X-Received: by 2002:a17:90a:7406:: with SMTP id a6mr9616376pjg.152.1594823753194; Wed, 15 Jul 2020 07:35:53 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:14c:4e33:547f:e274? ([2601:646:c200:1ef2:14c:4e33:547f:e274]) by smtp.gmail.com with ESMTPSA id y7sm2101353pfq.69.2020.07.15.07.35.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2020 07:35:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: strace of io_uring events? Date: Wed, 15 Jul 2020 07:35:50 -0700 Message-Id: References: Cc: strace-devel@lists.strace.io, io-uring@vger.kernel.org, Pavel Begunkov , Linux API , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: To: Miklos Szeredi , Kees Cook , Christian Brauner X-Mailer: iPhone Mail (17F80) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jul 15, 2020, at 4:12 AM, Miklos Szeredi wrote: >=20 > =EF=BB=BFHi, >=20 > This thread is to discuss the possibility of stracing requests > submitted through io_uring. I'm not directly involved in io_uring > development, so I'm posting this out of interest in using strace on > processes utilizing io_uring. >=20 > io_uring gives the developer a way to bypass the syscall interface, > which results in loss of information when tracing. This is a strace > fragment on "io_uring-cp" from liburing: >=20 > io_uring_enter(5, 40, 0, 0, NULL, 8) =3D 40 > io_uring_enter(5, 1, 0, 0, NULL, 8) =3D 1 > io_uring_enter(5, 1, 0, 0, NULL, 8) =3D 1 > ... >=20 > What really happens are read + write requests. Without that > information the strace output is mostly useless. >=20 > This loss of information is not new, e.g. calls through the vdso or > futext fast paths are also invisible to strace. But losing filesystem > I/O calls are a major blow, imo. >=20 > What do people think? >=20 > =46rom what I can tell, listing the submitted requests on > io_uring_enter() would not be hard. Request completion is > asynchronous, however, and may not require io_uring_enter() syscall. > Am I correct? >=20 > Is there some existing tracing infrastructure that strace could use to > get async completion events? Should we be introducing one? >=20 >=20 Let=E2=80=99s add some seccomp folks. We probably also want to be able to ru= n seccomp-like filters on io_uring requests. So maybe io_uring should call i= nto seccomp-and-tracing code for each action.=