From owner-freebsd-current Sun Feb 28 8:16: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from helios.dnttm.ru (dnttm-gw.rssi.ru [193.232.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 941811523C for ; Sun, 28 Feb 1999 08:15:46 -0800 (PST) (envelope-from dima@tejblum.dnttm.rssi.ru) Received: (from uucp@localhost) by helios.dnttm.ru (8.9.1/8.9.1/IP-3) with UUCP id TAA16421; Sun, 28 Feb 1999 19:06:21 +0300 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.9.3/8.9.1) with ESMTP id TAA00795; Sun, 28 Feb 1999 19:02:52 +0300 (MSK) (envelope-from dima@tejblum.dnttm.rssi.ru) Message-Id: <199902281602.TAA00795@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: tail /proc/map/* In-reply-to: Your message of "Sun, 28 Feb 1999 23:13:37 +1100." <199902281213.XAA22562@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Feb 1999 19:02:52 +0300 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > tail(1) assumes that mmap(2) works on works on regular files. mmap(2) on > the irregular regular files /proc/*/map returns success but doesn't work. IMO, it ought to work. There should be no reason why regular files on procfs are more "irregular" than regular files on NFS. > The first access to the mmapped memory usually causes the kernel to > printf messages like the following: > > vnode_pager: *** WARNING *** stale FS getpages (Still no such messages here. I still don't run the Terry's submission that just introduced the message and spread a lot of same trivial getpages/putpages routines over the kernel... I hope to clean out all this junk some day, (when everyone will finally forget that matter ;-) The message is not quite relevant to the problem, though.) > No strategy for buffer at 0xf12828e8 > : 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF) > tag VT_PROCFS, type 11, pid 591, mode 124, flags 0 > : 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF) > tag VT_PROCFS, type 11, pid 591, mode 124, flags 0 > vnode_pager_getpages: I/O read error That is because procfs define a bogus BMAP operation, but don't define a STRATEGY operation. The BMAP operation apparently only useful to break mmap(2). After the BMAP code removed, another procfs bugs become apparent. procfs claim that /proc/*/map files are all sizeof(struct regs)( == 76) bytes length (:-|), but don't allow read only 76 bytes from the 'map' file. It confuse the vm code that conver mmap to read, but it also may confuse other things. If I change the size of the 'map' file to something larger, tail /proc/*/map output something quite reasonable. I think procfs_domap should do what requested, and should not try to guarantee "atomicity", as now: anyhow, any file may change it content between reads, not just under procfs. Also, procfs could compute 'map' file size more accurately. Apparently, such a mmap implementation has coherency problems. But I don't think that they are more difficult to solve (or more serious) than in NFS case. Dima P.S. This is the changes that allow me to see a reasonable good result from 'tail /proc/*/map'. --- procfs_vnops.c Sun Feb 28 15:33:52 1999 +++ procfs_vnops.c Sun Feb 28 17:29:22 1999 @@ -560,6 +560,12 @@ case Ptype: case Pmap: + vap->va_bytes = vap->va_size = 4096; + vap->va_nlink = 1; + vap->va_uid = procp->p_ucred->cr_uid; + vap->va_gid = procp->p_ucred->cr_gid; + break; + case Pregs: vap->va_bytes = vap->va_size = sizeof(struct reg); vap->va_nlink = 1; @@ -982,7 +988,7 @@ { &vop_abortop_desc, (vop_t *) procfs_abortop }, { &vop_access_desc, (vop_t *) procfs_access }, { &vop_advlock_desc, (vop_t *) procfs_badop }, - { &vop_bmap_desc, (vop_t *) procfs_bmap }, + /*{ &vop_bmap_desc, (vop_t *) procfs_bmap },*/ { &vop_close_desc, (vop_t *) procfs_close }, { &vop_create_desc, (vop_t *) procfs_badop }, { &vop_getattr_desc, (vop_t *) procfs_getattr }, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message