And the nit-du-jour is.. - printk %s being passed a NULL or something..

From: Valdis.Kletnieks@private
Date: Mon Jan 05 2004 - 21:12:05 PST

  • Next message: Stephen Smalley: "Re: And the nit-du-jour is.. - printk %s being passed a NULL or something.."

    Found in my console logs:
    
    Jan  5 04:53:00 turing-police kernel: SELinux:  Setting up existing superblocks.
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type selinuxfs), uses genfs_contexts
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev ram0, type ext2), uses xattr
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type usbfs), not configured for labeling
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type usbdevfs), not configured for labeling
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type devfs), not configured for labeling
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type devpts), uses transition SIDs
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type eventpollfs), not configured for labeling
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type pipefs), uses task SIDs
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type tmpfs), uses transition SIDs
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type futexfs), not configured for labeling
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type sockfs), uses task SIDs
    Jan  5 04:53:00 turing-police kernel: SELinux: initialized (dev , type proc), uses genfs_contexts
    Jan  5 04:53:01 turing-police kernel: SELinux: initialized (dev , type bdev), not configured for labeling
    Jan  5 04:53:01 turing-police kernel: SELinux: initialized (dev , type rootfs), uses genfs_contexts
    Jan  5 04:53:01 turing-police kernel: SELinux: initialized (dev , type sysfs), uses genfs_contexts
    
    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? ;)
    
    
    



    This archive was generated by hypermail 2b30 : Mon Jan 05 2004 - 21:13:57 PST