kernel/linux.git/fs/dlm/rcom.c, branch linux-6.19.y

dlm: use spin_lock_bh for message processing

2024-04-09T16:45:23+00:00

Use spin_lock_bh for all spinlocks involved in message processing, in preparation for softirq message processing. DLM lock requests from user space involve dlm processing in user context, in addition to the standard kernel context, necessitating bh variants. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: remove allocation parameter in msg allocation

2024-04-09T14:58:14+00:00

Remove the context parameter for message allocations and always use GFP_ATOMIC. This prepares for softirq message processing. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: don't use RCOM_NAMES for version detection

2023-08-10T15:33:03+00:00

Currently RCOM_STATUS and RCOM_NAMES inclusive their replies are being used to determine the DLM version. The RCOM_NAMES messages are triggered in DLM recovery when calling dlm_recover_directory() only. At this time the DLM version need to be determined. I ran some tests and did not expirenced some issues. When the DLM version detection was developed probably I run once in a case of RCOM_NAMES and the version was not detected yet. However it seems to be not necessary. For backwards compatibility we still need to accept RCOM_NAMES messages which are not protected regarding the DLM message reliability layer aka stateless message. This patch changes that RCOM_NAMES we are sending out after this patch are not stateless anymore. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: constify receive buffer

2023-08-10T15:33:03+00:00

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 Signed-off-by: David Teigland

fs: dlm: drop rxbuf manipulation in dlm_recover_master_copy

2023-08-10T15:33:03+00:00

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 Signed-off-by: David Teigland

fs: dlm: get recovery sequence number as parameter

2023-08-10T15:33:03+00:00

This patch removes a read of the ls->ls_recover_seq uint64_t number in _create_rcom(). If the ls->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->ls_recover_seq and holding the ls->ls_recover_lock is not required. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: change dflags to use atomic bits

2023-03-06T21:49:07+00:00

Currently manipulating lkb_dflags assumes to held the rsb lock assigned to the lkb. This is held by dlm message processing after certain time to lookup the right rsb from the received lkb message id. For user space locks flags, which is currently the only use case for lkb_dflags, flags are also being set during dlm character device handling without holding the rsb lock. To minimize the risk that bit operations are getting corrupted we switch to atomic bit operations. This patch will also introduce helpers to snapshot atomic bit values in an non atomic way. There might be still issues with the flag handling e.g. running in case of manipulating bit ops and snapshot them at the same time, but this patch minimize them and will start to use atomic bit operations. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: store lkb distributed flags into own value

2023-03-06T21:49:07+00:00

This patch stores lkb distributed flags value in an separate value instead of sharing internal and distributed flags in lkb->lkb_flags value. This has the advantage to not mask/write back flag values in receive_flags() functionality. The dlm debug_fs does not provide the distributed flags anymore, those can be added in future. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fd: dlm: trace send/recv of dlm message and rcom

2022-11-08T18:59:41+00:00

This patch adds tracepoints for send and recv cases of dlm messages and dlm rcom messages. In case of send and dlm message we add the dlm rsb resource name this dlm messages belongs to. This has the advantage to follow dlm messages on a per lock basis. In case of recv message the resource name can be extracted by follow the send message sequence number. The dlm message DLM_MSG_PURGE doesn't belong to a lock request and will not set the resource name in a dlm_message trace. The same for all rcom messages. There is additional handling required for this debugging functionality which is tried to be small as possible. Also the midcomms layer gets aware of lock resource names, for now this is required to make a connection between sequence number and lock resource names. It is for debugging purpose only. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: cast resource pointer to uintptr_t

2022-04-07T14:54:45+00:00

This patch fixes the following warning when doing a 32 bit kernel build when pointers are 4 byte long: In file included from ./include/linux/byteorder/little_endian.h:5, from ./arch/x86/include/uapi/asm/byteorder.h:5, from ./include/asm-generic/qrwlock_types.h:6, from ./arch/x86/include/asm/spinlock_types.h:7, from ./include/linux/spinlock_types_raw.h:7, from ./include/linux/ratelimit_types.h:7, from ./include/linux/printk.h:10, from ./include/asm-generic/bug.h:22, from ./arch/x86/include/asm/bug.h:87, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/gfp.h:5, from ./include/linux/slab.h:15, from fs/dlm/dlm_internal.h:19, from fs/dlm/rcom.c:12: fs/dlm/rcom.c: In function ‘dlm_send_rcom_lock’: ./include/uapi/linux/byteorder/little_endian.h:32:43: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] #define __cpu_to_le64(x) ((__force __le64)(__u64)(x)) ^ ./include/linux/byteorder/generic.h:86:21: note: in expansion of macro ‘__cpu_to_le64’ #define cpu_to_le64 __cpu_to_le64 ^~~~~~~~~~~~~ fs/dlm/rcom.c:457:14: note: in expansion of macro ‘cpu_to_le64’ rc->rc_id = cpu_to_le64(r); The rc_id value in dlm rcom is handled as u64. The rcom implementation uses for an unique number generation the pointer value of the used dlm_rsb instance. However if the pointer value is 4 bytes long -Wpointer-to-int-cast will print a warning. We get rid of that warning to cast the pointer to uintptr_t which is either 4 or 8 bytes. There might be a very unlikely case where this number isn't unique anymore if using dlm in a mixed cluster of nodes and sizeof(uintptr_t) returns 4 and 8. However this problem was already been there and this patch should get rid of the warning. Fixes: 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") Reported-by: kernel test robot Signed-off-by: Alexander Aring Signed-off-by: David Teigland