> -----Original Message----- > From: Paul Moore <paul@xxxxxxxxxxxxxx> > Sent: Saturday, January 11, 2020 12:50 AM > On Fri, Jan 10, 2020 at 10:13 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > On 1/10/20 4:58 AM, Huaisheng Ye wrote: > > > From: Huaisheng Ye <yehs1@xxxxxxxxxx> > > > > > > selinux_msg_msg_alloc_security only calls msg_msg_alloc_security but > > > do nothing else. And also msg_msg_alloc_security is just used by the > > > former. > > > > > > Remove the redundant function to simplify the code. > > > > This seems to also be true of other _alloc_security functions, > > probably due to historical reasons. Further, at least some of these > > functions no longer perform any allocation; they are just > > initialization functions now that allocation has been taken to the LSM > > framework, so possibly could be renamed and made to return void at some point. > > I've noticed the same thing on a few occasions, I've just never bothered to put > the fixes into a patch. We might as well do that now, at least for the redundant > code bits; I'll leave the return code issue for another time as that would cross > LSM boundaries and that really isn't appropriate in the -rc5 timeframe IMHO. > > I'll put something together once I finish up the patch/review backlog from the > past few days. Looking quickly with a regex, it would appear that > inode_alloc_security(), file_alloc_security(), and > superblock_alloc_security() are all candidates. While not an allocator, we can > probably get rid of inode_doinit() as well. Besides, it looks like selinux_nlmsg_perm is candidate too. Just send a patch for this function. Cheers, Huaisheng Ye
