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

fs: dlm: change dflags to use atomic bits

2023-03-06T21:49:07Z

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:07Z

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:41Z

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:45Z

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

dlm: use __le types for rcom messages

2022-04-06T19:02:32Z

This patch changes to use __le types directly in the dlm rcom structure which is casted at the right dlm message buffer positions. The main goal what is reached here is to remove sparse warnings regarding to host to little byte order conversion or vice versa. Leaving those sparse issues ignored and always do it in out/in functionality tends to leave it unknown in which byte order the variable is being handled. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: use __le types for dlm header

2022-04-06T19:02:28Z

This patch changes to use __le types directly in the dlm header structure which is casted at the right dlm message buffer positions. The main goal what is reached here is to remove sparse warnings regarding to host to little byte order conversion or vice versa. Leaving those sparse issues ignored and always do it in out/in functionality tends to leave it unknown in which byte order the variable is being handled. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: use dlm_recovery_stopped instead of test_bit

2021-11-02T19:39:20Z

This patch will change to use dlm_recovery_stopped() which is the dlm way to check if the LSFL_RECOVER_STOP flag in ls_flags by using the helper. It is an atomic operation but the check is still as before to fetch the value if ls_recover_lock is held. There might be more further investigations if the value can be changed afterwards and if it has any side effects. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: cleanup and remove _send_rcom

2021-07-19T16:53:43Z

The _send_rcom() can be removed and we call directly dlm_rcom_out(). As we doing that we removing the struct dlm_ls parameter which isn't used. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: rename socket and app buffer defines

2021-06-02T16:53:04Z

This patch renames DEFAULT_BUFFER_SIZE to DLM_MAX_SOCKET_BUFSIZE and LOWCOMMS_MAX_TX_BUFFER_LEN to DLM_MAX_APP_BUFSIZE as they are proper names to define what's behind those values. The DLM_MAX_SOCKET_BUFSIZE defines the maximum size of buffer which can be handled on socket layer, the DLM_MAX_APP_BUFSIZE defines the maximum size of buffer which can be handled by the DLM application layer. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: Fix memory leak of object mh

2021-05-26T14:49:04Z

There is an error return path that is not kfree'ing mh after it has been successfully allocates. Fix this by moving the call to create_rcom to after the check on rc_in->rc_id check to avoid this. Thanks to Alexander Ahring Oder Aring for suggesting the correct way to fix this. Addresses-Coverity: ("Resource leak") Fixes: a070a91cf140 ("fs: dlm: add more midcomms hooks") Signed-off-by: Colin Ian King Signed-off-by: David Teigland