Re: linux-next: Tree for Jul 4

[Greg Kroah-Hartman]

On Sat, Jul 06, 2019 at 08:17:29PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Sat, 6 Jul 2019 11:46:47 +0200 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Sat, Jul 06, 2019 at 07:44:12PM +1000, Stephen Rothwell wrote:
> > > 
> > > On Sat, 6 Jul 2019 10:34:33 +0200 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:  
> > > >
> > > > On Thu, Jul 04, 2019 at 10:24:50PM +1000, Stephen Rothwell wrote:  
> > > > > 
> > > > > This release produces a whole lot (over 200) of this message in my qemu
> > > > > boot tests:
> > > > > 
> > > > > [    1.698497] debugfs: File 'sched' already present!
> > > > > 
> > > > > Introduced by commit
> > > > > 
> > > > >   43e23b6c0b01 ("debugfs: log errors when something goes wrong")
> > > > > 
> > > > > from the driver-core tree.  I assume that the error(?) was already
> > > > > happening, but it is now being reported.    
> > > > 
> > > > What are you passing to qemu to get this?  I just tried it myself and
> > > > see no error reports at all.  Have a .config I can use to try to
> > > > reproduce this?  
> > > 
> > > It is a powerpc pseries_le_defconfig kernel and I run qemu like this:
> > > 
> > > qemu-system-ppc64 -M pseries -m 2G -vga none -nographic -kernel vmlinux -initrd rootfs.cpio.gz  
> > 
> > Hm, I think my rootfs initrd might be quite simple compared to yours (it
> > drops me into a busybox shell).  Any pointers to where you created yours
> > from?
> 
> Michael Ellerman gave it to me.  It is very simple.  Its /init is just
> 
> $ cat init
> #!/bin/sh
> # devtmpfs does not get automounted for initramfs
> /bin/mount -t devtmpfs devtmpfs /dev
> exec 0</dev/console
> exec 1>/dev/console
> exec 2>/dev/console
> exec /sbin/init $*
> 
> and /sbin/init is a link to /bin/busybox
> 
> It is all run by an expect script that just waits for the login:
> prompt, logs in a root and runs "halt".
> 
> All the debugfs messages appear before the kernel finished booting.

Thanks, this helped.  Looks like it is the loop device causing this.  Or
at least I can trigger it here with that module.

And it seems that the debugfs code for those devices never worked, let
me unwind the mess of pointers to try to find the real solution here...

thanks,

greg k-h