linux-kernel - Re: [PATCHv2][SMB3] Add kernel trace support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH2r5muy_+dMNfW6dPg4U-66R4kFbGKGSDu-==uizGJfLYoA9w@mail.gmail.com>
Date:   Fri, 18 May 2018 11:14:56 -0700
From:   Steve French <smfrench@...il.com>
To:     ronnie sahlberg <ronniesahlberg@...il.com>
Cc:     Ronnie Sahlberg <lsahlber@...hat.com>,
        CIFS <linux-cifs@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        samba-technical <samba-technical@...ts.samba.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCHv2][SMB3] Add kernel trace support

On Fri, May 18, 2018 at 1:00 AM, ronnie sahlberg
<ronniesahlberg@...il.com> 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 <smfrench@...il.com> wrote:
>> On Thu, May 17, 2018 at 10:28 PM, Ronnie Sahlberg <lsahlber@...hat.com> wrote:
>>> Very nice.
>>>
>>> Acked-by: Ronnie Sahlberg <lsahlber@...hat.com>
>>>
>>> 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