Re: Tmpfs panic in -current

Konstantin Belousov wrote:
> 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.

As I mentioned, I'm running -CURRENT on a number of systems.
I haven't seen tmpfs panics on machines running FreeBSD 9.

	Kevin