Re: Giantless VFS.

On Wed, Dec 01, 2004 at 05:51:11AM -0500, Jeff Roberson wrote:
> On Tue, 30 Nov 2004, Peter Holm wrote:
> 
> > On Tue, Nov 30, 2004 at 01:39:01AM -0500, Jeff Roberson wrote:
> > >
> > > On Tue, 23 Nov 2004, Peter Holm wrote:
> > >
> > > > On Mon, Nov 22, 2004 at 06:46:50AM -0500, Jeff Roberson wrote:
> > > > > On Mon, 22 Nov 2004, Ivan Voras wrote:
> > > > >
> > > > > > Jeff Roberson wrote:
> > > > > >
> > > > > > > The short description:
> > > > > > > This patch removes Giant from the read(), write(), and fstat() syscalls,
> > > > > > > as well as page faults, and bufdone (io interrupts) when using FFS.  It
> > > > > >
> > > > > > What is the plan re: RELENG_5? Will things like this (giantless vm, fs)
> > > > > > be merged into it?
> > > > >
> > > > > The giantless vm was already merged back to RELENG_5 and enabled on amd64,
> > > > > and i386.  I hope to merge the giantless vfs back after a month or so of
> > > > > no problems on -current.  I hope to commit it to -current this week.
> > > > >
> > > > > I haven't received any feedback from the list though.  I hope people are
> > > > > testing it.  Perhaps the silence indicates universal success? :-)
> > > > >
> > > >
> > > > Here's a problem I ran into during stress test:
> > > >
> > > > http://www.holm.cc/stress/log/jeff01.html
> > > >
> > > > Let me know if you need more gdb output.
> > >
> > > Thanks, this is the most serious bug of the couple that were reported.  It
> > > indicates a possible race to flush a buffer.  I'm still looking for this.
> > > What steps did you take to produce this panic?
> > >
> >
> > I ran my kernel stress test: http://www.holm.cc/stress/src/stress.tgz
> > I stopped using your patch after the two reported problems.
> > Let me know if you would like me to perform more testing with your patch.
> 
> Thanks, I think I may have fixed the problems that were exposed via your
> stress tool.  I'll post an updated patch to the list in a moment.

I'll test it ASAP.

> I was
> wondering if you have seen a panic in pmap_invalidate_range via sigexit()?
> It seems to have been caused by illegal calls to sigexit() from
> trapsignal().  If you have not reported it yet, I have a copy of a stack
> here and I can let the responsible people know.
> 

This is a problem I have not encountered, so please do.

Regards,

- Peter