linux-kernel - RE: [PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space

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:	Thu, 14 Apr 2016 14:41:41 +0300
From:	Felipe Balbi <balbi@...nel.org>
To:	"Du\, Changbin" <changbin.du@...el.com>
Cc:	"gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space


Hi,

"Du, Changbin" <changbin.du@...el.com> writes:
>> > At last, comparing with the FIFO/Queue info, I think software transfer
>> > Requests list, TRBs info, EVENTs history are much more useful for
>> debugging
>> > the driver. If you can also add these info to each EP folder, that is awesome!
>> > :)
>> 
>> I'll think about adding these but for the lifetime of requests and trbs
>> and events, etc, we have tracepoints for that. I usually do the
>> following when debugging:
>> 
>> # mount -t debugfs none /sys/kernel/debug
>> # cd /sys/kernel/debug/tracing
>> # echo 2048 > buffer_size_kb
>> # echo 1 > events/dwc3/enable
>> 
>> (do something to break it)
>> 
>> # cp trace /mnt/sdcard # or something like that
>> 
>> then read the file. You can make it as large or as small as you like
>> (given some constraints, of course ;-) but I've had no issues allocating
>> 128MiB in the past.
>> 
>> --
>> Balbi
>
> Thanks for the sharing, this is a good approach to capture dynamic
> behaviors. But a dump of current state has below advantages:
> 1. a quick view for the pending transfers. Then we can quickly 
>      checking the transfer status.
> 2. no side-effect. This is important in some case. We usually
>     encounter some transfer issues but very hard to reproduce
>     it. But we cannot enable trace all the time since performance
>     concern. Then I thought it was so great if I can have a look for
>     the trb status. :)

yeah, okay. We can definitely add "current state" of almost anything,
but if you need history, then debugfs is not the best interface and I'd
point you to tracepoints ;-)

I'll think about how I can add TRB state, seems like we'd need to dump
the entire endpoint ring, and that's 256 TRBs per endpoint :-p Then we
also need to know endpoint's dequeue and enqueue pointer. Oh well, let
me get this first setup of files out of the way, then we can add more
later much more easily.

-- 
balbi

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