After LU-20046 added sptlrpc.send_sepol to the parameters settable with lctl set_param -P, the following sequence does not do what it's supposed to do:

# On MGS                                                                               
lctl set_param -P sptlrpc.send_sepol=0                                                 
                                                                                       
# On client                                                                            
lctl set_param sptlrpc.send_sepol=-1                                                   
umount /mnt/lustre                                                                     
mount -t lustre ... /mnt/lustre                                                        
lctl get_param -n sptlrpc.send_sepol      # 0, not -1                       

The client local send_sepol=-1 is discarded during the mount: the client replays the MGS config log as part of connecting, and re-applies the persisted 0. To make a client-local setting survive a mount, the persistent entry has to be removed first: 

# On MGS                            
lctl set_param -P -d sptlrpc.send_sepol

sanity-selinux test_21c ("Persist send_sepol via lctl set_param -P", b5bbdb49fa) does exactly this in its cleanup: it sets -P send_sepol=0 instead of deleting the entry. Before 21c runs there is no such entry in the config log; afterwards there is one, and every subsequent mount in the suite replays it. Any later test that sets sptlrpc.send_sepol locally is silently zeroed, and since sptlrpc_sepol_get() returns NULL immediately when send_sepol is 0, the l_getsepol upcall is never invoked — the test exercises nothing while still appearing to pass.
As a result, restoring the value with set_param -P send_sepol=X then removing the entry with set_param -P -d from the MGS is necessary