Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4826058imm; Fri, 18 May 2018 11:17:44 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrozmiiKm+0SAkICXHPo9bQd/1NLMHDHnLIWy2zHkHCwWfPBC+rf1gqFNdfv68/GMuiA+aG X-Received: by 2002:a62:4d02:: with SMTP id a2-v6mr10412242pfb.2.1526667464632; Fri, 18 May 2018 11:17:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526667464; cv=none; d=google.com; s=arc-20160816; b=lr59iUuH3zPPfhJ1i+7jACiNjiepjHAwNr8fynyanTxbt4cTx0jp3lHXQIYCUAplNA OqeIfBbo6nv71FI7xFEohPY0ZKR4oPNHwPJ3YyxbaoMQsberFmX17Ko5SbxI7HseJmuW +b/XA/xX93P5ZZMm9YyR6WnJ90RvY6Pj147cNkxtf6xAR62JikMCjR4SeCWFszwSZ4WB xa7XA0GDsmrCxkU0vm2pzaG4BoRn+kDyqrI/2QrG7pn4xWvDCiv0+Lop4H2zoGnAoZSu umilLUWnUmOgIobtgxzyPeWG3qAQdqvoB+SQs0tDhvCoju5gc+k9HRLwMMigW+sD1klB ODHg== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=KiMsuIgDNJ6RkgytYL6v1o4kOR5DZ3kIe75UOVUaFto=; b=0mu0yDeqLHkzlSsZewl+gKM2MHaGcg+ehLkoMAprw7J0kWpKUyiSaSr9Kqh/2ffzS2 Ac5NRAllr17qIh90TBdKdYn/HY8En3i1QevH+gCwU9CBtwsiDPjqKMsMTEHPRlClfclX 3pnBru63JFn6BCU3GaxHUFyt+cnx+ZQ8nMTQuVqVGTUFNJIhZYdgZMy/yauf9I4Mev4M 3/QHxGerpxjKR9JZOcirVFSu3MNWjpTOn4t9WsPiZeRu0LzOJNE9Cx+n0jWZlvyWcUBC s2PtCPRijSU8MNHA6cFvK8BvHZqNDJJmCDjR4E+dkQNABGwn/4GNXDL48R7jnxg1Ajd/ rx+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m2Z0GHCR; 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 bj1-v6si7652224plb.395.2018.05.18.11.17.29; Fri, 18 May 2018 11:17:44 -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=m2Z0GHCR; 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 S1751790AbeERSPT (ORCPT + 99 others); Fri, 18 May 2018 14:15:19 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:32791 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751221AbeERSPR (ORCPT ); Fri, 18 May 2018 14:15:17 -0400 Received: by mail-pl0-f68.google.com with SMTP id n10-v6so5033935plp.0; Fri, 18 May 2018 11:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KiMsuIgDNJ6RkgytYL6v1o4kOR5DZ3kIe75UOVUaFto=; b=m2Z0GHCRDBUHWVP+hgksEb6RQ31d20z2H6DuV+8gldaJYT1W7l+4sGHtnSCxI3dW5U tCQAgDZu9282iP0/x4Ax92bRsYiTUPNZnJ5nI+uoB827ZPCgvk8UtpFggwmj79JhuWX7 7YqXFzosZ8J2CI1TkdbAUJgBECALBDVmkAHkET2l93kovrW0jyr3vjZmC7LEvkgBry4r PEYFyfODdfBR1DaBGGDmvXRKQJJ0jqGhK+4X9jMzV3CGUDHOOp+G/xbmY3OkmIGCdiFw JrwZPfR0jhxV4+V62d1mM5pCb8d3P0GgZ+erp+p6sdnYrKgI948dt+d0z2CHm8RPiauM Xa1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KiMsuIgDNJ6RkgytYL6v1o4kOR5DZ3kIe75UOVUaFto=; b=a1MJizLAmL7g02zWaGpgCK5SmRSnPyc3Nby2/HHIISg9bbqQOEKKVEe/KbHOz0Ppwl 1WWW82znin7KmOWYj6Qt0doXDLJGmVRHkJydgXZLhQT72Ylz4cdk7rGslf8kSMLbVmn5 JzXJMEoEzFMAEX+HLtQMkSOzsAWbJGzPalG9mDgZflUHaabpVH+QuYFo7Ryb3s53wnnN SzA+oK1D2qZwsF9WAa8+OXBq6Eqy5T8O4tO1q/M510meHIIHAv4ly+2sOA4FDcOLxHHb avNFGysOXCKRjgmnciGg5AUZ0qPRyETG3uBy0DCsLQSu7siwsbUDjCWCYuLBpNuO6bPP gBfw== X-Gm-Message-State: ALKqPweBXw37gx1m4aAZ0qs0mY7fBdL/h6v/4UjtCKYmNC54ayC6M4b+ tCVmX3IwzH65FH55liJhzY6pub+5wFPeKBcO6cY= X-Received: by 2002:a17:902:8541:: with SMTP id d1-v6mr10977333plo.106.1526667316935; Fri, 18 May 2018 11:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:bd8f:0:0:0:0 with HTTP; Fri, 18 May 2018 11:14:56 -0700 (PDT) In-Reply-To: References: <1169121702.2774727.1526614091337.JavaMail.zimbra@redhat.com> From: Steve French Date: Fri, 18 May 2018 11:14:56 -0700 Message-ID: Subject: Re: [PATCHv2][SMB3] Add kernel trace support To: ronnie sahlberg Cc: Ronnie Sahlberg , CIFS , LKML , samba-technical , linux-fsdevel 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, May 18, 2018 at 1:00 AM, ronnie sahlberg wrote: > Fair enough. > > Onto a second point then, for future patches. > > There are a lot of places where we do not (yet) pass a tcon as argument. > Can we make a policy decision to mandate that every tracepoint MUST > log tid, sid? > > And thus, if you need a new tracepoint in a function where tcon is not > available you then first > have to do the plumbing to pass the tcon all the way down to the tracepoint? I think this can be relaxed in a few cases (not just session setup), but is a good general rule. If only the parent function needs to be changed it is easy decision, but if changes more than two layers, perhaps not. > Ideally we should pass tcon into any and every leaf function for > tracepoints as well as debug logging. We also have to - log the tid and session id somewhere in human readable form - perhaps allow an IOCtl to retrieve the UNC name from the tid, and similarly something human readable for the session id (server and username) (or add the tid and session id to what is displayed in /proc/fs/cifs/DebugData so we can extract it from the DebugData output) > On Fri, May 18, 2018 at 4:19 PM, Steve French wrote: >> On Thu, May 17, 2018 at 10:28 PM, Ronnie Sahlberg wrote: >>> Very nice. >>> >>> Acked-by: Ronnie Sahlberg >>> >>> Possibly change the output from >>> pid=6633 tid=0x0 sid=0x0 cmd=0 mid=0 >>> to >>> cmd=0 mid=0 pid=6633 tid=0x0 sid=0x0 >>> >>> just to make it easier for human-searching. I think the cmd will be useful much more often than pid/tid/sid >>> and this would make it easier to look for as all cmd= entries will be aligned to the same column. >> >> My instinct is to preserve the consistency by beginning with the the >> fields that will be in 90% of the commands: tree id and session id >> (tid and sid), which would cause pid to move after sid or after cmd, >> but I would prefer to wait on reordering fields and fixing alignment >> till we add another set of tracepoints (e.g. in FreeXid, and in >> SMB2_open and in the caller of negprot/sessionsetup) - we should then >> have a better idea what formatting would make it slightly more >> consistent and readable. -- Thanks, Steve