linux-kernel - Re: [PATCH v1] usb: typec: tcpm: Add kernel config to wrap around tcpm logs

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: <ff111499-c871-e97d-0f0c-237cb0879aeb@roeck-us.net>
Date:   Mon, 10 Apr 2023 07:13:58 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Badhri Jagan Sridharan <badhri@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     heikki.krogerus@...ux.intel.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] usb: typec: tcpm: Add kernel config to wrap around
 tcpm logs

On 4/10/23 01:08, Badhri Jagan Sridharan wrote:
> On Mon, Apr 10, 2023 at 12:45 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>>
>> On Mon, Apr 10, 2023 at 07:31:34AM +0000, Badhri Jagan Sridharan wrote:
>>> This change adds CONFIG_TCPM_LOG_WRAPAROUND which when set allows the
>>> logs to be wrapped around. Additionally, when set, does not clear
>>> the TCPM logs when dumped.
>>>
>>> Signed-off-by: Badhri Jagan Sridharan <badhri@...gle.com>
>>> ---
>>>   drivers/usb/typec/tcpm/Kconfig | 6 ++++++
>>>   drivers/usb/typec/tcpm/tcpm.c  | 9 +++++++--
>>>   2 files changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
>>> index e6b88ca4a4b9..4dd2b594dfc9 100644
>>> --- a/drivers/usb/typec/tcpm/Kconfig
>>> +++ b/drivers/usb/typec/tcpm/Kconfig
>>> @@ -18,6 +18,12 @@ config TYPEC_TCPCI
>>>        help
>>>          Type-C Port Controller driver for TCPCI-compliant controller.
>>>
>>> +config TCPM_LOG_WRAPAROUND
>>> +     bool "Enable TCPM log wraparound"
>>> +     help
>>> +       When set, wraps around TCPM logs and does not clear the logs when dumped. TCPM logs by
>>> +       default gets cleared when dumped and does not wraparound when full.
>>
>> Kconfig help text needs to be wrapped at the properly width.
> 
> I assumed that the width is 100 characters, but it looks like it is
> 80. Will fix it in the next version.
>>
>> And you do not provide any hint here as to why this is not the default
>> option, or why someone would want this.
> 
> "TCPM logs by default gets cleared when dumped and does not wraparound
> when full." was intended
> to convey why someone would want to set this. Perhaps it's not effective.
> 
> Does the below look better:
> "TCPM logs by default gets cleared when dumped and does not wraparound
> when full. This can be overridden by setting this config.
> When the config is set, TCPM wraps around logs and does not clear the
> logs when dumped."
> 
> Also, I could make this default if that's OK with Guenter.
> 

The reason to not wrap around the buffer was that it tends to fill up quickly
if something goes wrong. Initially I had it wrap around and often ended up
seeing endless reset sequences in the log but not the actual problem.

>>
>> So, why is this not just the default operation anyway?  Why would you
>> ever want the logs cleared?
> 
> I remember Guenter mentioning that he was finding it useful to not
> wrap around the logs to fix problems
> during tcpm_register_port (init sequence). IMHO wrapping around the
> logs helps to triage interoperability
> issues uncovered during testing. So both approaches have their own advantages.
> 
Yes, except that "testing" at the time included connecting an arbitrary new
device to the type c port. Pretty much each of them had its own flaws.
This was also the reason for not using tracing, because I wanted to have a
log available _all_ the time, not just when explicitly enabled.

Maybe the protocol is now more stable than it used to be, and switching
to a wraparound buffer and/or to tracing makes more sense now.
I can't really say.

Guenter

> Thanks for taking the time to review !
> - Badhri
> 
>>
>> thanks,
>>
>> greg k-h