Another mmap / jffs2 problem (was RE: 2.5.59-rmk1: unmap_vmas: VMA list is not sorted correctly!)

Another mmap / jffs2 problem (was RE: 2.5.59-rmk1: unmap_vmas: VMA list is not sorted correctly!)

[Christopher Hoover]

> I'm getting "unmap_vmas: VMA list is not sorted
> correctly!" with 2.5.59-rmk1 on a badgepad4 
> (SA-1110).  I take it that this is bad.  :-)

I tracked this down to the use of mmap within pppd
(ppp-2.4.1/pppd/tdb.c) on a file in jffs2.  That last part -*- the
mmap'ed file is in jffs2 -*- is key.

I don't always get the "VMA list is not sorted message", but pppd always
segfaults when it starts mucking with the mmap'ed file data.

If I place the file in /tmp, which is a ramfs file system in my setup,
pppd behaves.

Here's the segfault:

pppd-with-mmap: unhandled page fault at 0x000001e3, code 0xc334f007
pgd = c334c000
[000001e3] *pgd=c238b011, *pte=00000000, *ppte=00000000
pc : [<40057f7c>]    lr : [<00026ad4>]    Not tainted
sp : befffd14  ip : befffd28  fp : 00000000
r10: 933f4b6e  r9 : 00000007  r8 : 000438c8
r7 : befffd28  r6 : 0004df80  r5 : 00000004  r4 : 000001e4
r3 : ffffffff  r2 : 00000004  r1 : 000001e3  r0 : befffd28
Flags: nzCv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: C334F17F  Table: C334F17F  DAC: 00000015



Details: 2.5.59-rmk1, uClibc-0.9.19, ppp-2.4.1, gcc-3.2.2

-ch
mailto:ch-at-murgatroid.com

Another mmap / jffs2 problem (was RE: 2.5.59-rmk1: unmap_vmas: VMA list is not sorted correctly!)

[Russell King - ARM Linux]

On Thu, Mar 06, 2003 at 02:47:35PM -0800, Christopher Hoover wrote:
> 
> > I'm getting "unmap_vmas: VMA list is not sorted
> > correctly!" with 2.5.59-rmk1 on a badgepad4 
> > (SA-1110).  I take it that this is bad.  :-)
> 
> I tracked this down to the use of mmap within pppd
> (ppp-2.4.1/pppd/tdb.c) on a file in jffs2.  That last part -*- the
> mmap'ed file is in jffs2 -*- is key.
> 
> I don't always get the "VMA list is not sorted message", but pppd always
> segfaults when it starts mucking with the mmap'ed file data.
> 
> If I place the file in /tmp, which is a ramfs file system in my setup,
> pppd behaves.
> 
> Here's the segfault:
> 
> pppd-with-mmap: unhandled page fault at 0x000001e3, code 0xc334f007
> pgd = c334c000
> [000001e3] *pgd=c238b011, *pte=00000000, *ppte=00000000
> pc : [<40057f7c>]    lr : [<00026ad4>]    Not tainted
> sp : befffd14  ip : befffd28  fp : 00000000
> r10: 933f4b6e  r9 : 00000007  r8 : 000438c8
> r7 : befffd28  r6 : 0004df80  r5 : 00000004  r4 : 000001e4
> r3 : ffffffff  r2 : 00000004  r1 : 000001e3  r0 : befffd28
> Flags: nzCv  IRQs on  FIQs on  Mode USER_32  Segment user
> Control: C334F17F  Table: C334F17F  DAC: 00000015

This is a long standing problem - and, has been reported many times
here.  I don't remember the details, but I seem to remember that
pppd is buggy.

I think, if you strace pppd, you'll find that it tries to mmap something
just before it receives a segfault.  It receives the segfault because
the mmap failed and, iirc, it ignores the mmap failure.

As far as the unmap_vmas message, if you could get a copy of the
/proc/<pid>/maps file while pppd is running, it might provide some
clues.

Another mmap / jffs2 problem (was RE: 2.5.59-rmk1: unmap_vmas: VMA list is not sorted correctly!)

[Christopher Hoover]

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C2E406.21A31DB0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit


> This is a long standing problem - and, has been reported many times
> here.  I don't remember the details, but I seem to remember that
> pppd is buggy.

Ah.  I looked at the code -- it seems that someone thought that mmap(2)
returns 0 on error.  A couple of checks for -1 fixed it.  I'll forward a
patch to the maintainers (attached here for anyone encountering this
problem who finds this note).

Incidentally why does the mmap fail with EINVAL against a jffs2 file and
succeed against a tmpfs file?  Is that by design?


> As far as the unmap_vmas message, if you could get a copy of the
> /proc/<pid>/maps file while pppd is running, it might provide some
> clues.

I'm still getting the occasion unmap_vmas message; I'll grab that info
next time I see it.

Thanks again.

Cheers,
-ch

------=_NextPart_000_0036_01C2E406.21A31DB0
Content-Type: application/octet-stream;
	name="ppp-2.4.1-mmap.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="ppp-2.4.1-mmap.diff"

--- ppp-2.4.1.orig/pppd/tdb.c	2000-04-03 23:27:13.000000000 -0700=0A=
+++ ppp-2.4.1/pppd/tdb.c	2003-03-06 17:11:51.000000000 -0800=0A=
@@ -210,6 +210,8 @@=0A=
 	tdb->map_ptr =3D (void *)mmap(NULL, tdb->map_size, =0A=
 				    tdb->read_only?PROT_READ:PROT_READ|PROT_WRITE,=0A=
 				    MAP_SHARED | MAP_FILE, tdb->fd, 0);=0A=
+	if (tdb->map_ptr =3D=3D (void *) -1)=0A=
+		tdb->map_ptr =3D 0;=0A=
 #endif	=0A=
 	return 0;=0A=
 }=0A=
@@ -373,6 +375,8 @@=0A=
             tdb->map_ptr =3D (void *)mmap(NULL, tdb->map_size, =0A=
                                         PROT_READ|PROT_WRITE,=0A=
                                         MAP_SHARED | MAP_FILE, tdb->fd, =
0);=0A=
+	    if (tdb->map_ptr =3D=3D (void *) -1)=0A=
+		tdb->map_ptr =3D 0;=0A=
         }=0A=
 #endif=0A=
 =0A=
@@ -1180,6 +1184,8 @@=0A=
             tdb.map_ptr =3D (void *)mmap(NULL, st.st_size, =0A=
                                        tdb.read_only? PROT_READ : =
PROT_READ|PROT_WRITE,=0A=
                                        MAP_SHARED | MAP_FILE, tdb.fd, =
0);=0A=
+	    if (tdb.map_ptr =3D=3D (void *) -1)=0A=
+		tdb.map_ptr =3D 0;=0A=
         }=0A=
 #endif=0A=
 =0A=

------=_NextPart_000_0036_01C2E406.21A31DB0--

Another mmap / jffs2 problem (was RE: 2.5.59-rmk1: unmap_vmas: VMA list is not sorted correctly!)

[Christopher Hoover]

BTW, this is fixed in the ppd CVS:

http://www.samba.org/cgi-bin/cvsweb/ppp/pppd/tdb.c?r1=1.1&r2=1.2

-ch


> -----Original Message-----
> From: linux-arm-kernel-admin at lists.arm.linux.org.uk 
> [mailto:linux-arm-kernel-admin at lists.arm.linux.org.uk] On 
> Behalf Of Christopher Hoover
> Sent: Thursday, March 06, 2003 5:31 PM
> To: 'Russell King - ARM Linux'
> Cc: linux-arm-kernel at lists.arm.linux.org.uk; 'linux-mtd'
> Subject: RE: Another mmap / jffs2 problem (was RE: 
> 2.5.59-rmk1: unmap_vmas: VMA list is not sorted correctly!)
> 
> 
> 
> > This is a long standing problem - and, has been reported many times
> > here.  I don't remember the details, but I seem to remember that
> > pppd is buggy.
> 
> Ah.  I looked at the code -- it seems that someone thought 
> that mmap(2)
> returns 0 on error.  A couple of checks for -1 fixed it.  
> I'll forward a
> patch to the maintainers (attached here for anyone encountering this
> problem who finds this note).
> 
> Incidentally why does the mmap fail with EINVAL against a 
> jffs2 file and
> succeed against a tmpfs file?  Is that by design?
> 
> 
> > As far as the unmap_vmas message, if you could get a copy of the
> > /proc/<pid>/maps file while pppd is running, it might provide some
> > clues.
> 
> I'm still getting the occasion unmap_vmas message; I'll grab that info
> next time I see it.
> 
> Thanks again.
> 
> Cheers,
> -ch
> 

Another mmap / jffs2 problem (was RE: 2.5.59-rmk1: unmap_vmas: VMA list is not sorted correctly!)

[David Woodhouse]

On Fri, 2003-03-07 at 01:30, Christopher Hoover wrote:
> > This is a long standing problem - and, has been reported many times
> > here.  I don't remember the details, but I seem to remember that
> > pppd is buggy.
> 
> Ah.  I looked at the code -- it seems that someone thought that mmap(2)
> returns 0 on error.  A couple of checks for -1 fixed it.  I'll forward a
> patch to the maintainers (attached here for anyone encountering this
> problem who finds this note).

I already bugged paulus about it last year sometime.

> Incidentally why does the mmap fail with EINVAL against a jffs2 file and
> succeed against a tmpfs file?  Is that by design?

Yes. We don't do shared writable mmap.

Except briefly in 2.5.5something where Linus broke the sys_mmap() logic
so it'd _appear_ to succeed but in fact give you a read-only mmap, and
then the process would die upon trying to write to it.

We fixed it -- I didn't track the fix so it might not have got applied.
I think it's in the archives of both lists. Look for posts from Andrew
Morton.

-- 
dwmw2