<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/dlm/lock.c, branch v6.9</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>dlm: add comments about forced waiters reset</title>
<updated>2024-03-15T22:11:39+00:00</updated>
<author>
<name>David Teigland</name>
<email>teigland@redhat.com</email>
</author>
<published>2024-03-15T22:11:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c53309b912fdd652eb3c2de44626aac4b0fc9bf9'/>
<id>c53309b912fdd652eb3c2de44626aac4b0fc9bf9</id>
<content type='text'>
When a lock is waiting for a reply for a remote operation, and recovery
interrupts this "waiters" state, the remote operation is voided by the
recovery, and no reply will be processed.  The lkb waiters state for the
remote operation is forcibly reset/cleared, so that the lock operation
can be restarted after recovery.  Improve the comments describing this.

Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a lock is waiting for a reply for a remote operation, and recovery
interrupts this "waiters" state, the remote operation is voided by the
recovery, and no reply will be processed.  The lkb waiters state for the
remote operation is forcibly reset/cleared, so that the lock operation
can be restarted after recovery.  Improve the comments describing this.

Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dlm: revert atomic_t lkb_wait_count</title>
<updated>2024-03-15T19:39:28+00:00</updated>
<author>
<name>David Teigland</name>
<email>teigland@redhat.com</email>
</author>
<published>2024-03-15T19:11:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=484b4f90c28f441e71e9d7df407c5b76578d2658'/>
<id>484b4f90c28f441e71e9d7df407c5b76578d2658</id>
<content type='text'>
Revert "fs: dlm: handle lkb wait count as atomic_t"
This reverts commit 75a7d60134ce84209f2c61ec4619ee543aa8f466.

This counter does not need to be atomic.  As the comment in
the reverted commit mentions, the counter is protected by
the rsb lock.

Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Revert "fs: dlm: handle lkb wait count as atomic_t"
This reverts commit 75a7d60134ce84209f2c61ec4619ee543aa8f466.

This counter does not need to be atomic.  As the comment in
the reverted commit mentions, the counter is protected by
the rsb lock.

Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: constify receive buffer</title>
<updated>2023-08-10T15:33:03+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-08-01T18:09:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1151935182b40bbe398905850f6f7f4fbb262e06'/>
<id>1151935182b40bbe398905850f6f7f4fbb262e06</id>
<content type='text'>
The dlm receive buffer should be never manipulated as DLM is the last
instance of parsing layer. This patch constify the whole receive buffer
so we are sure it never gets manipulated when it's being parsed.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The dlm receive buffer should be never manipulated as DLM is the last
instance of parsing layer. This patch constify the whole receive buffer
so we are sure it never gets manipulated when it's being parsed.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: drop rxbuf manipulation in dlm_recover_master_copy</title>
<updated>2023-08-10T15:33:03+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-08-01T18:09:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b9d2f6ada0083bad46f37a1238fea718b575e0fa'/>
<id>b9d2f6ada0083bad46f37a1238fea718b575e0fa</id>
<content type='text'>
Currently dlm_recover_master_copy() manipulates the receive buffer of an
rcom lock message and modifies it on the fly so a later memcpy() to a
new rcom message with the same message has those new values. This patch
avoids manipulating the received rcom message by store the values for
the new rcom message in paremter assigned with call by reference. Later
when dlm_send_rcom_lock() constructs a new message and memcpy() the
receive buffer those values will be set on the new constructed message.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently dlm_recover_master_copy() manipulates the receive buffer of an
rcom lock message and modifies it on the fly so a later memcpy() to a
new rcom message with the same message has those new values. This patch
avoids manipulating the received rcom message by store the values for
the new rcom message in paremter assigned with call by reference. Later
when dlm_send_rcom_lock() constructs a new message and memcpy() the
receive buffer those values will be set on the new constructed message.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: get recovery sequence number as parameter</title>
<updated>2023-08-10T15:33:03+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-08-01T18:09:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c4f4e135c27b503d325d414819831909023b113d'/>
<id>c4f4e135c27b503d325d414819831909023b113d</id>
<content type='text'>
This patch removes a read of the ls-&gt;ls_recover_seq uint64_t number in
_create_rcom(). If the ls-&gt;ls_recover_seq is readed the ls_recover_lock
need to held. However this number was always readed before when any rcom
message is received and it's not necessary to read it again from a per
lockspace variable to use it for the replying message. This patch will
pass the sequence number as parameter so another read of ls-&gt;ls_recover_seq
and holding the ls-&gt;ls_recover_lock is not required.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes a read of the ls-&gt;ls_recover_seq uint64_t number in
_create_rcom(). If the ls-&gt;ls_recover_seq is readed the ls_recover_lock
need to held. However this number was always readed before when any rcom
message is received and it's not necessary to read it again from a per
lockspace variable to use it for the replying message. This patch will
pass the sequence number as parameter so another read of ls-&gt;ls_recover_seq
and holding the ls-&gt;ls_recover_lock is not required.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: handle lkb wait count as atomic_t</title>
<updated>2023-06-14T15:17:33+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-05-29T21:44:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=75a7d60134ce84209f2c61ec4619ee543aa8f466'/>
<id>75a7d60134ce84209f2c61ec4619ee543aa8f466</id>
<content type='text'>
Currently the lkb_wait_count is locked by the rsb lock and it should be
fine to handle lkb_wait_count as non atomic_t value. However for the
overall process of reducing locking this patch converts it to an
atomic_t value.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the lkb_wait_count is locked by the rsb lock and it should be
fine to handle lkb_wait_count as non atomic_t value. However for the
overall process of reducing locking this patch converts it to an
atomic_t value.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: warn about messages from left nodes</title>
<updated>2023-06-14T15:17:33+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-05-29T21:44:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=70cf2fecf87354be09c0ab4c233fccea36256d3c'/>
<id>70cf2fecf87354be09c0ab4c233fccea36256d3c</id>
<content type='text'>
This patch warns about messages which are received from nodes who
already left the lockspace resource signaled by the cluster manager.
Before commit 489d8e559c65 ("fs: dlm: add reliable connection if
reconnect") there was a synchronization issue with the socket
lifetime and the cluster event of leaving a lockspace and other
nodes did not stop of sending messages because the cluster manager has a
pending message to leave the lockspace. The reliable session layer for
dlm use sequence numbers to ensure dlm message were never being dropped.
If this is not corrected synchronized we have a problem, this patch will
use the filter case and turn it into a WARN_ON_ONCE() so we seeing such
issue on the kernel log because it should never happen now.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch warns about messages which are received from nodes who
already left the lockspace resource signaled by the cluster manager.
Before commit 489d8e559c65 ("fs: dlm: add reliable connection if
reconnect") there was a synchronization issue with the socket
lifetime and the cluster event of leaving a lockspace and other
nodes did not stop of sending messages because the cluster manager has a
pending message to leave the lockspace. The reliable session layer for
dlm use sequence numbers to ensure dlm message were never being dropped.
If this is not corrected synchronized we have a problem, this patch will
use the filter case and turn it into a WARN_ON_ONCE() so we seeing such
issue on the kernel log because it should never happen now.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: stop unnecessarily filling zero ms_extra bytes</title>
<updated>2023-04-21T16:46:47+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-04-21T15:55:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7a40f1f18a88c6d43c8725d7f45146480a79fde1'/>
<id>7a40f1f18a88c6d43c8725d7f45146480a79fde1</id>
<content type='text'>
Commit 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr")
fixes an issue when the lkb-&gt;lkb_lvbptr set to an dangled pointer and an
followed memcpy() would fail. It was fixed by an additional check of
DLM_LKF_VALBLK flag. The mentioned commit forgot to add an additional check
if DLM_LKF_VALBLK is set for the additional amount of LVB data allocated
in a dlm message. This patch is changing the message allocation to check
additionally if DLM_LKF_VALBLK is set otherwise a dangled lkb-&gt;lkb_lvbptr
pointer would allocated zero LVB message data which not gets filled with
actual data.

This patch is however only a cleanup to reduce the amount of zero bytes
transmitted over network as receive_lvb() will only evaluates message LVB
data if DLM_LKF_VALBLK is set.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr")
fixes an issue when the lkb-&gt;lkb_lvbptr set to an dangled pointer and an
followed memcpy() would fail. It was fixed by an additional check of
DLM_LKF_VALBLK flag. The mentioned commit forgot to add an additional check
if DLM_LKF_VALBLK is set for the additional amount of LVB data allocated
in a dlm message. This patch is changing the message allocation to check
additionally if DLM_LKF_VALBLK is set otherwise a dangled lkb-&gt;lkb_lvbptr
pointer would allocated zero LVB message data which not gets filled with
actual data.

This patch is however only a cleanup to reduce the amount of zero bytes
transmitted over network as receive_lvb() will only evaluates message LVB
data if DLM_LKF_VALBLK is set.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: switch lkb_sbflags to atomic ops</title>
<updated>2023-03-06T21:49:07+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-03-06T20:48:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1361737f102d898330fd61efa5940c1ee0812da1'/>
<id>1361737f102d898330fd61efa5940c1ee0812da1</id>
<content type='text'>
This patch moves lkb_sbflags handling to atomic bits ops. This should
prepare for a possible manipulating of lkb_sbflags flags at the same
time by concurrent execution.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch moves lkb_sbflags handling to atomic bits ops. This should
prepare for a possible manipulating of lkb_sbflags flags at the same
time by concurrent execution.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: dlm: rsb hash table flag value to atomic ops</title>
<updated>2023-03-06T21:49:07+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2023-03-06T20:48:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=46d6e722d8b1cf07d21662f6b29bcd8e72f77305'/>
<id>46d6e722d8b1cf07d21662f6b29bcd8e72f77305</id>
<content type='text'>
This patch moves the rsb hash table handling to atomic flag operations.
The flag operations for DLM_RTF_SHRINK are protected by
ls-&gt;ls_rsbtbl[b].lock. However we switch to atomic ops if new possible
flags will be used in a different way and don't assume such lock
dependencies.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch moves the rsb hash table handling to atomic flag operations.
The flag operations for DLM_RTF_SHRINK are protected by
ls-&gt;ls_rsbtbl[b].lock. However we switch to atomic ops if new possible
flags will be used in a different way and don't assume such lock
dependencies.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
