Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jun 2012 13:24:25 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Kevin Lo <kevlo@kevlo.org>
Cc:        freebsd-fs@freebsd.org, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: Tmpfs panic in -current
Message-ID:  <20120626102424.GL2337@deviant.kiev.zoral.com.ua>
In-Reply-To: <1340685505.2170.5.camel@nsl>
References:  <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl>

next in thread | previous in thread | raw e-mail | index | archive | help

--ZvISnaQ8JYKZply4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
> > >=20
> > > Does this look at all familiar to anyone?
> >=20
> > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 addr=
ess
> > in your kernel ?
>=20
> Sure.
>=20
> > The screenshot looks strange. The instruction on which the kernel trapp=
ed
> > is int 0x28 which should not appear in the compiled code.
>=20
> # 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
>=20
> In tmpfs_subr.c:
>  999                         if (m !=3D NULL) {
> 1000                                 if ((m->oflags & VPO_BUSY) !=3D 0 ||
> 1001                                     m->busy !=3D 0) {
> 1002                                         vm_page_sleep(m, "tmfssz");
> 1003                                         goto retry;
> 1004                                 }
> 1005                                 MPASS(m->valid =3D=3D VM_PAGE_BITS_A=
LL);
> 1006                         } else if (vm_pager_has_page(uobj, idx, NULL=
, NU
> LL)) {
>=20
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.

--ZvISnaQ8JYKZply4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAk/pjdgACgkQC3+MBN1Mb4hFsgCeOI3iGrL11NcdF3tnpSzitJhl
c9cAoLhqZmq1SyxQR4zwqIlQdL4uEX3O
=Y8sb
-----END PGP SIGNATURE-----

--ZvISnaQ8JYKZply4--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120626102424.GL2337>