Matthew Dillon 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 thing. Kirk told me a
:> 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
:in
:> 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
>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
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
> 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
inten
>
> * 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
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
> John S. Dyson writes:
> > Howard Goldstein said:
> > > On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> 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.
John S. Dyson writes:
> Howard Goldstein said:
> > On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> > 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 other th
> On Wed, 9 Jun 1999, John S. Dyson wrote:
>
> > Howard Goldstein said:
> > > On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> > > wrote:
> > > : On Mon, 7 Jun 1999, Matthew Dillon wrote:
> > > : > ... what version of the operating system?
> > > : 4.0-CURRENT
> > >
> > > 3.2R too
On Wed, 9 Jun 1999, John S. Dyson wrote:
> Howard Goldstein said:
> > On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> > wrote:
> > : On Mon, 7 Jun 1999, Matthew Dillon wrote:
> > : > ... what version of the operating system?
> > : 4.0-CURRENT
> >
> > 3.2R too...
> >
> I just ch
Howard Goldstein said:
> On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> 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 happend
between
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
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 body of the mess
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 pro
... 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
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.)
>
>
> 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
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! _ __ | _ \._ \ |) |
http://www.freebs
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 l
Brian Feldman 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 that part of 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 ind
22 matches
Mail list logo
