Re: Tmpfs panic in -current

On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
> Kevin Lo wrote:
> > Konstantin Belousov wrote:
> > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
> > > > Konstantin Belousov wrote:
> > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
> > > > > > I've observed a panic in recent -current several times but I only
> > > > > > have a picture of the backtrace:
> > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
> > > > > > 
> > > > > > Does this look at all familiar to anyone?
> > > > > 
> > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
> > > > > in your kernel ?
> > > > 
> > > > Sure.
> > > > 
> > > > > The screenshot looks strange. The instruction on which the kernel trapped
> > > > > is int 0x28 which should not appear in the compiled code.
> > > > 
> > > > # gdb tmpfs.ko
> > > > (gdb) l *tmpfs_reg_resize+0x627
> > > > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
> > > > 1000    in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
> > > > 
> > > > In tmpfs_subr.c:
> > > >  999                         if (m != NULL) {
> > > > 1000                                 if ((m->oflags & VPO_BUSY) != 0 ||
> > > > 1001                                     m->busy != 0) {
> > > > 1002                                         vm_page_sleep(m, "tmfssz");
> > > > 1003                                         goto retry;
> > > > 1004                                 }
> > > > 1005                                 MPASS(m->valid == VM_PAGE_BITS_ALL);
> > > > 1006                         } else if (vm_pager_has_page(uobj, idx, NULL, NU
> > > > LL)) {
> > > > 
> > > Hm, can you get a core and
> > > - obtain backtrace in kgdb;
> > > - print the *m content for the page that triggered the assertion ?
> > > 
> > > The only possible 'new size' value for the truncation from open(2) is zero,
> > > so I do not understand why the asserted block was executed at all.
> > 
> > Thanks for looking into it. Unfortunately I can't get a crash dump 
> > due to lack of disk space and memory.
> 
> I triggered the KASSERT on a different machine in the last hour.
It is not 'the' KASSERT, it is something different.

Are you sure that you do not have some systematic build issues on your
machines ? Although I do not think that tmpfs is 'ready for production use'
for arbitrary low value of this statement, there is no steady flow of
similar reports from other users. This makes me somewhat suspicious that
either you might have inconsistent build issues, or unrelated memory
corruption problems.

> 
> panic: Assertion (vp) !=NULL && (vp)->v_data != NULL failed at 
> _at_/fs/tmpfs/tmpfs.h:527
> 
> The bad news is my coworker rebooted that machine after panic :-(
> 
> 	Kevin