<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/dlm/lock.c, branch v6.6.134</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.134</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.134'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-12-14T19:00:02+00:00</updated>
<entry>
<title>dlm: fix possible lkb_resource null dereference</title>
<updated>2024-12-14T19:00:02+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>aahringo@redhat.com</email>
</author>
<published>2024-10-04T15:13:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6fbdc3980b70e9c1c86eccea7d5ee68108008fa7'/>
<id>urn:sha1:6fbdc3980b70e9c1c86eccea7d5ee68108008fa7</id>
<content type='text'>
[ Upstream commit b98333c67daf887c724cd692e88e2db9418c0861 ]

This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb-&gt;lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.

The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.

In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists.

Signed-off-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Signed-off-by: David Teigland &lt;teigland@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</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.radix-linux.su/kernel/linux.git/commit/?id=1151935182b40bbe398905850f6f7f4fbb262e06'/>
<id>urn:sha1: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>
</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.radix-linux.su/kernel/linux.git/commit/?id=b9d2f6ada0083bad46f37a1238fea718b575e0fa'/>
<id>urn:sha1: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>
</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.radix-linux.su/kernel/linux.git/commit/?id=c4f4e135c27b503d325d414819831909023b113d'/>
<id>urn:sha1: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>
</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.radix-linux.su/kernel/linux.git/commit/?id=75a7d60134ce84209f2c61ec4619ee543aa8f466'/>
<id>urn:sha1: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>
</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.radix-linux.su/kernel/linux.git/commit/?id=70cf2fecf87354be09c0ab4c233fccea36256d3c'/>
<id>urn:sha1: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>
</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.radix-linux.su/kernel/linux.git/commit/?id=7a40f1f18a88c6d43c8725d7f45146480a79fde1'/>
<id>urn:sha1: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>
</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.radix-linux.su/kernel/linux.git/commit/?id=1361737f102d898330fd61efa5940c1ee0812da1'/>
<id>urn:sha1: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>
</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.radix-linux.su/kernel/linux.git/commit/?id=46d6e722d8b1cf07d21662f6b29bcd8e72f77305'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>fs: dlm: move internal flags 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:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1af8728f600f648be1f552552e834c170a0244c'/>
<id>urn:sha1:e1af8728f600f648be1f552552e834c170a0244c</id>
<content type='text'>
This patch will move the lkb_flags value to the recently introduced
lkb_iflags value. For lkb_iflags we use atomic bit operations because
some flags like DLM_IFL_CB_PENDING are used while non rsb lock is held
to avoid issues with other flag manipulations which might run at the
same time we switch to atomic bit operations. Snapshot the bit values to
an uint32_t value is only used for debugging/logging use cases and don't
need to be 100% correct.

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