: VM lookup the page again. Always. vm_fault already does this,
: in fact. We would clean up the code and document it to this effect.
:
: This change would allow us to immediately fix the self-referential
: deadlocks and I think it would also allow me to fix a similar bug
: A permanent vnode locking fix is many months away because core
: decided to ask Kirk to fix it, which was news to me at the time.
: However, I agree with the idea of having Kirk fix VNode locking.
:
: Actually, core did no such thing. Kirk told me a month or so ago that he
Matthew Dillon dil...@apollo.backplane.com writes:
:A permanent vnode locking fix is many months away because core
:decided to ask Kirk to fix it, which was news to me at the time.
:However, I agree with the idea of having Kirk fix VNode locking.
:
: Actually, core did no such
* We hack a fix to deal with the mmap/write case.
A permanent vnode locking fix is many months away because core
decided to ask Kirk to fix it, which was news to me at the time.
However, I agree with the idea of having Kirk fix VNode locking.
But since this
A permanent vnode locking fix is many months away because core
decided to ask Kirk to fix it, which was news to me at the time.
However, I agree with the idea of having Kirk fix VNode locking.
Actually, core did no such thing. Kirk told me a month or so ago that he
On Sun, 13 Jun 1999, John S. Dyson wrote:
Remember that you cannot assume that the mappings stay the same during
almost any I/O mechanism anymore. The issue of wiring pages and assuming
constant mapping has to be resolved. A careful definition of whether
or not one is doing I/O to an
Interesting. It's an overlapping same-process deadlock with mmap/write.
This bug also hits NFS, though in a slightly different way, and also
occurs with mmap/write when two processes are mmap'ing two files and
write()ing the other descriptor using the map as a buffer.
I see a
Interesting. It's an overlapping same-process deadlock with mmap/write.
This bug also hits NFS, though in a slightly different way, and also
occurs with mmap/write when two processes are mmap'ing two files and
write()ing the other descriptor using the map as a buffer.
I see a
Howard Goldstein said:
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman gr...@unixhelp.org
wrote:
: On Mon, 7 Jun 1999, Matthew Dillon wrote:
: ... what version of the operating system?
: 4.0-CURRENT
3.2R too...
I just checked the source (CVS) tree, and something bad
On Wed, 9 Jun 1999, John S. Dyson wrote:
Howard Goldstein said:
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman gr...@unixhelp.org
wrote:
: On Mon, 7 Jun 1999, Matthew Dillon wrote:
: ... what version of the operating system?
: 4.0-CURRENT
3.2R too...
I just
On Wed, 9 Jun 1999, John S. Dyson wrote:
Howard Goldstein said:
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
gr...@unixhelp.org wrote:
: On Mon, 7 Jun 1999, Matthew Dillon wrote:
: ... what version of the operating system?
: 4.0-CURRENT
3.2R too...
John S. Dyson writes:
Howard Goldstein said:
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
gr...@unixhelp.org wrote:
: 4.0-CURRENT
3.2R too...
I just checked the source (CVS) tree, and something bad happend
between 1.27 and 1.29 on ufs_readwrite.c. Unless
John S. Dyson writes:
Howard Goldstein said:
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
gr...@unixhelp.org wrote:
: 4.0-CURRENT
3.2R too...
I just checked the source (CVS) tree, and something bad happend
between 1.27 and 1.29 on ufs_readwrite.c.
Arun Sharma said:
bread
ffs_read
ffs_getpages
vnode_pager_getpages
vm_fault
---
slow_copyin
ffs_write
vn_write
dofilewrite
write
syscall
getblk finds that the buffer is marked B_BUSY and sleeps on it. But I
can't figure out who marked it busy.
This looks like the
One of the problems that would make it sensible to do a complete rewrite
of vfs_bio.c is this?
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
One of the problems that would make it sensible to do a complete rewrite
of vfs_bio.c is this?
Specifically for that reason, probably not. However, if the effort
was taken as an entire and encompassing effort, with the understanding
of what is really happening in the code regarding policy
Brian Feldman said:
In the long-standing tradition of deadlocks, I present to you all a new one.
This one locks in getblk, and causes other processes to lock in inode. It's
easy to induce, but I have no idea how I'd go about fixing it myself
(being very new to that part of the kernel.)
... what version of the operating system?
-Matt
: In the long-standing tradition of deadlocks, I present to you all a new one.
:This one locks in getblk, and causes other processes to lock in inode. It's
:easy to induce, but I have no idea how
On Mon, 7 Jun 1999, Matthew Dillon wrote:
... what version of the operating system?
-Matt
4.0-CURRENT
: In the long-standing tradition of deadlocks, I present to you all a new
one.
:This one locks in getblk, and causes other processes
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman gr...@unixhelp.org
wrote:
: On Mon, 7 Jun 1999, Matthew Dillon wrote:
: ... what version of the operating system?
: 4.0-CURRENT
3.2R too...
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the
In the long-standing tradition of deadlocks, I present to you all a new one.
This one locks in getblk, and causes other processes to lock in inode. It's
easy to induce, but I have no idea how I'd go about fixing it myself
(being very new to that part of the kernel.)
Here's the program which
Brian Feldman gr...@unixhelp.org writes:
In the long-standing tradition of deadlocks, I present to you all
a new one. This one locks in getblk, and causes other processes to
lock in inode. It's easy to induce, but I have no idea how I'd go
about fixing it myself (being very new to
22 matches
Mail list logo
