linux-kernel - Re: [PATCH] block: paride: on26: Replace mdelay with msleep in on26_test

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2a3f0d10-824b-0d26-0046-6379a363b383@gmail.com>
Date:   Sat, 27 Jan 2018 12:13:30 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     tim@...erelk.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: paride: on26: Replace mdelay with msleep in
 on26_test_port



On 2018/1/27 1:31, Al Viro wrote:
> On Fri, Jan 26, 2018 at 11:42:25PM +0800, Jia-Ju Bai wrote:
>> After checking all possible call chains to on26_test_port() here,
>> my tool finds that this function is never called in atomic context,
>> namely never in an interrupt handler or holding a spinlock.
>> And on26_test_port() is only called by pi_probe_unit() that calls
>> wait_event() through pi_claim(),
>> so it indicates that on26_test_port() can call functions that can sleep.
>> Thus mdelay can be replaced with msleep to avoid busy wait.
> Sigh...  Here's how I would've written it:
>
> "
> on26_test_port() is never called from atomic contexts.
>
> It has no direct callers and it is reachable only via ->test_port.
> ->test_port has only one user:
> drivers/block/paride/paride.c:322:              max = pi->proto->test_port(pi);
> in pi_probe_unit().  That gets called only from pi_init(), called from
> p{d,cd,f,t,g}_detect(), called from module_init stuff, all of the above
> without entering atomic contexts along the way.
>
> Despite never getting called from atomic contexts, on26_test_port() contains
> mdelay(100), i.e. busy-loops for 0.1s; that's neither nice nor needed, since
> msleep() would serve just as well.
>
> Found by [reference to tool]"

Okay, thanks for your patient guidance :)
I will revise the description and send v2 patch, and follow the advice 
in my next patches.


Thanks,
Jia-Ju Bai