Thread (26 messages) 26 messages, 7 authors, 2017-10-23

Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE

From: Bart Van Assche <hidden>
Date: 2017-10-19 15:47:08
Also in: lkml

On Thu, 2017-10-19 at 17:34 +0200, Thomas Gleixner wrote:
I really disagree with your reasoning completely

1) When lockdep was introduced more than ten years ago it was far from
   perfect and we spent a reasonable amount of time to improve it, analyze
   false positives and add the missing annotations all over the tree. That
   was a process which took years.

2) Surely nobody is interested in wasting time on analyzing false
   positives, but your (and other peoples) attidute of 'none of my
   business' is what makes kernel development extremly frustrating.

   It should be in the interest of everybody involved in kernel development
   to help with improving such features and not to lean back and wait for
   others to bring it into a shape which allows you to use it as you see
   fit.

That's not how community works and lockdep would not be in the shape it is
today, if only a handful of people would have used and improved it. Such
things only work when used widely and when we get enough information so we
can address the weak spots.
Hello Thomas,

It seems like you are missing my point. Cross-release checking is really
*broken* as a concept. It is impossible to improve it to the same reliability
level as the kernel v4.13 lockdep code. Hence my request to make it possible
to disable cross-release checking if PROVE_LOCKING is enabled.

Consider the following example from the cross-release documentation:

   TASK X			   TASK Y
   ------			   ------
				   acquire AX
   acquire B /* A dependency 'AX -> B' exists */
   release B
   release AX held by Y

My understanding is that the cross-release code will add (AX, B) to the lock
order graph after having encountered the above code. I think that's wrong
because if the following sequence (Y: acquire AX, X: acquire B, X: release B)
is encountered again that there is no guarantee that AX can only be released
by X. Any task other than X could release that synchronization object too.

Bart.��칻
�&ޱ��jg���
�+a�{.n�+����{��h����ܭ�f���h��/i�(�h�j+z)ߢ�ˊ{�0�
zm����	b��f����:'�隊V����j)m��'�K�rJ+�隊Y/i�(��
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help