linux-kernel - Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

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:   Tue, 24 Jan 2017 12:44:39 +0800
From:   Lu Baolu <baolu.lu@...ux.intel.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>, tglx@...utronix.de,
        peterz@...radead.org, linux-usb@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo,

On 01/22/2017 05:04 PM, Ingo Molnar wrote:
> * Lu Baolu <baolu.lu@...ux.intel.com> wrote:
>
>>>> +static void xdbc_runtime_delay(unsigned long count)
>>>> +{
>>>> +	udelay(count);
>>>> +}
>>>> +static void (*xdbc_delay)(unsigned long) = xdbc_early_delay;
>>> Is this udelay() complication really necessary? udelay() should work fine even in 
>>> early code. It might not be precisely calibrated, but should be good enough.
>> I tried udelay() in the early code. It's not precise enough for the
>> hardware handshaking.
> Possibly because on x86 early udelay() did not work at all - i.e. there's no delay 
> whatsoever.

Yes.

>
> Could you try it on top of this commit in tip:timers/core:
>
>   4c45c5167c95 x86/timer: Make delay() work during early bootup
>
> ?

I tried tip:timers/core. It's not precise enough for my context either.

__const_udelay().

157 inline void __const_udelay(unsigned long xloops)
158 {
159         unsigned long lpj = this_cpu_read(cpu_info.loops_per_jiffy) ? : loops_per_jiffy;
160         int d0;
161
162         xloops *= 4;
163         asm("mull %%edx"
164                 :"=d" (xloops), "=&a" (d0)
165                 :"1" (xloops), "0" (lpj * (HZ / 4)));
166
167         __delay(++xloops);
168 }


In my early  code, loops_per_jiffy is not initialized yet. Hence "lpj" for the asm line
is 4096 (default value).

The  cpu_info.loops_per_jiffy actually reads 8832000 after initialization. They are
about 2000 times different.

I did a hacky test in kernel to check the difference between these two different
"lpj" values. (The hacky patch is attached.) Below is the output for 100ms delay.

[    2.494751] udelay_test uninitialized ---->start
[    2.494820] udelay_test uninitialized ---->end
[    2.494828] udelay_test initialized ---->start
[    2.595234] udelay_test initialized ---->end

For 100ms delay, udelay() with uninitialized loops_per_jiffy only gives a delay of
only 69us.

Best regards,
Lu Baolu

View attachment "kernel-hack.patch" of type "text/x-patch" (2326 bytes)