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]
Date:   Wed, 15 Feb 2017 10:56:39 +0200
From:   Felipe Balbi <felipe.balbi@...ux.intel.com>
To:     Lu Baolu <baolu.lu@...ux.intel.com>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events


Hi,

Lu Baolu <baolu.lu@...ux.intel.com> writes:
>> Lu Baolu <baolu.lu@...ux.intel.com> writes:
>>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>>> index 1ac2cdf..c31eeaf 100644
>>> --- a/drivers/usb/host/xhci-trace.h
>>> +++ b/drivers/usb/host/xhci-trace.h
>>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
>>>  	TP_ARGS(urb)
>>>  );
>>>  
>>> +DECLARE_EVENT_CLASS(xhci_log_cmd,
>>> +	TP_PROTO(struct xhci_command *cmd),
>>> +	TP_ARGS(cmd),
>>> +	TP_STRUCT__entry(
>>> +		__field(struct xhci_command *, cmd)
>>> +		__field(struct xhci_container_ctx *, in_ctx)
>>> +		__field(union xhci_trb *, cmd_trb)
>>> +		__field(int, slot_id)
>>> +		__field(int, status)
>>> +		__field(int, type)
>>> +	),
>>> +	TP_fast_assign(
>>> +		__entry->cmd = cmd;
>>> +		__entry->in_ctx = cmd->in_ctx;
>>> +		__entry->cmd_trb = cmd->command_trb;
>>> +		__entry->slot_id = cmd->slot_id;
>>> +		__entry->status = cmd->status;
>>> +		__entry->type = TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
>>> +	),
>>> +	TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
>>> +		__entry->cmd, xhci_trb_type_string(__entry->type),
>>> +		__entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
>>> +		__entry->status
>>> +	)
>>> +);
>> we already have a generic TRB tracer that decodes every single TRB. What
>> is this bringing that the previous doesn't provide?
>
> This tracer traces the life cycle of a command. It gives,
>
> 1) Which function started an xhci command?
> 2) What was name of that command?
> 3) Did hardware respond to it, or timed out?
> 4) If hardware responded, what was the execution result?
> 5) If timed out, did 'abort command ring operation' abort it successfully?
> 6) Was the command structure freed at last?

We already have all that, AFAICT. Command is enqueued, then an event
triggers for command completion, then we look at results. The only thing
missing for completeness is slot/EP context tracers (which I've pointed
you to) so we can see what changes each command cause to the different
contexts.

Frankly, I don't think printing out context pointers brings
anything. What can you do with that address? :-p Same goes for cmd
pointer, it brings nothing; gives no insight into the problem
whatsoever.

We certainly need to know which command was enqueued, the slot, etc. But
addresses... not so sure.

>> BTW, I also have
>> ready Slot and EP context tracers, I didn't send before because I
>> already had quite a large series pending for Mathias :-p
>
> Sorry for the duplication.

no need to apologize, you didn't know :-)

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ