> Luoqi Chen said:
> > >
> > Do you still have that piece of code? Does it handle the case involves more
> > than one process? For example, process 1 mmaps file B and reads file A into
> > the mmapped region, while process 2 mmaps file A and reads file B, this
> > could
> > also result in a deadl
Luoqi Chen said:
> >
> Do you still have that piece of code? Does it handle the case involves more
> than one process? For example, process 1 mmaps file B and reads file A into
> the mmapped region, while process 2 mmaps file A and reads file B, this could
> also result in a deadlock.
>
It used t
> Luoqi Chen said:
> > >
> > This seems to be the good old vnode deadlock during vm_fault() that has been
> > reported a couple of times, and there's still no satisfactory solution to
> > it:
> > fgrep does something like this: (don't ask me why)
> >
> > addr = mmap(0, len, PROT_READ|PROT_WR
Alexander N. Kabaev wrote:
ANK> The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE
ANK> as of today) to lookup.
2.2.8 and 3.0-RELEASE are not vulnerable, by the way.
ANK> Shortly after this script is started, all disk
ANK> activity stops and any attempt to create new proces
> On Mon, 22 Feb 1999, Alexander N. Kabaev wrote:
>
> > The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE
> > as of today) to lookup. Shortly after this script is started, all disk
> > activity
> >
> > stops and any attempt to create new process causes system to freese. Wh
Luoqi Chen said:
> >
> This seems to be the good old vnode deadlock during vm_fault() that has been
> reported a couple of times, and there's still no satisfactory solution to it:
> fgrep does something like this: (don't ask me why)
>
> addr = mmap(0, len, PROT_READ|PROT_WRITE, MAP_PRIVATE,
> On Mon, 22 Feb 1999, Alexander N. Kabaev wrote:
>
> > The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE
> > as of today) to lookup. Shortly after this script is started, all disk
> > activity
> >
> > stops and any attempt to create new process causes system to freese. Wh
On Mon, 22 Feb 1999, Alexander N. Kabaev wrote:
> The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE
> as of today) to lookup. Shortly after this script is started, all disk
> activity
>
> stops and any attempt to create new process causes system to freese. While in
> DDB,
The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE
as of today) to lookup. Shortly after this script is started, all disk activity
stops and any attempt to create new process causes system to freese. While in
DDB, ps command
shows, that all ten fgrep processes are sleeping
