On 7/6/21 9:49 AM, Jason Gunthorpe wrote:
On Tue, Jul 06, 2021 at 09:39:29AM -0400, Tony Krowiak wrote:
On 7/5/21 10:13 AM, Jason Gunthorpe wrote:
On Thu, Jul 01, 2021 at 10:28:52AM -0400, Tony Krowiak wrote:
I think Jason was talking about open coding locks in general.
That may be so, but his comments were in support of his
statement that the mutex + wait_queue did not resolve
the issue reported vai the lockdep splat because it turned
off lockdep.
Rgiht, if this used to be proper locks and lockdep complained then
whatever potential deadlock it found is not magically removed by going
to a wait_queue. It just removes the lockdep annotations that would
identify the issue early.
This is why people should not open code locks, it completely defeats
lockdep. That alone is merit enough for this patch.
When you use the phrase "open code locks", to what are you
specifically referring? I am confused by the use of the phrase
"open code" in this context because open coding, at least as
I understand it, has to do with data analysis.
"open code" here means you write the algorithm of a standard lock in
your own functions instead of calling the standard library.
Testing/setting the busy and sleeping on a wait_event is exactly a
standard lock.
Ie if I write
for (len = 0; str[len] != 0; len++)
;
Then I have open coded strlen()
Jason
Thanks for the explanation.
