On Tue, 2004-01-06 at 00:12, Valdis.Kletnieks@private wrote: > I never noticed anything odd, till I saw that 'ram0' there. Further checking shows > that there's lots of places the security/selinux/hooks.c code passes sb->s_id to > a "%s" format in a printk, even though only ram0 seems to actually set it. > > Is anybody at fault here? selinux for trying to print something almost certainly not set? > the filesystems for not initializing the pointer in the superblock? How badly will we oops > if we get a stray one, and do we care? ;) It is always initialized, but is often left as the empty string for pseudo filesystems. For typical filesystems, it will contain the block device name, e.g. hda1. Base kernel code uses it in the same manner, grep around for it. SELinux used to use kdevname(sb->s_dev), but that was a broken interface and was removed circa 2.5.67, at which point we converted SELinux over to using sb->s_id per the guidance on lkml. Nit: You might want to post such questions to the selinux mailing list, or at least cc it, rather than only posting them here. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2b30 : Tue Jan 06 2004 - 05:21:05 PST