Date: Sun, 28 Feb 1999 19:02:52 +0300 From: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG Subject: Re: tail /proc/map/* Message-ID: <199902281602.TAA00795@tejblum.dnttm.rssi.ru> In-Reply-To: Your message of "Sun, 28 Feb 1999 23:13:37 %2B1100." <199902281213.XAA22562@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902281602.TAA00795>