Bug#77857: hurd: write_node assertion failed building emacs

[Marcus Brinkmann]

On Sat, Dec 02, 2000 at 11:32:56PM -0500, Roland McGrath wrote:
> > > It matters to understand whether or not that code is going to
> > > eventually call set_node_times before it matters that the mtime update
> > > be reflected.  If so, then it doesn't matter whether that mtime update
> > > happens before or after the node sync, as long as it doesn't get lost.
> > > That should be achievable by rewriting diskfs_set_node_times so it
> > > does:
> > > 
> > >   if (np->dn_set_mtime)
> > >     {
> > >       ...
> > >       np->dn_set_mtime = 0;
> > >       np->dn_stat_dirty = 1;
> > >     }
> > > 
> > > instead of the separate tests done now (and same for the other two).  That
> > > way, dn_set_mtime is only touched if it was just acted upon--if it gets 
> > > set
> > > right after the test, then it will remain set for later.  Then it would be
> > > safe to just remove that assert and let the update take place later.
> > 
> > Mmh. This makes the race window smaller, but doesn't do away with it
> > entirely.
> 
> I don't know what you mean.  Please cite the precise race scenario you are
> concerned with.  I see no race in the sequence above: if dn_set_mtime is
> clear at the time of the test and then set immediately after the test, the
> test fails and it won't be cleared by the sequence.

Quite true, but what if dn_set_mtime is set before the test, and set again
immediately after it? Then it would be cleared, although the time value
stored in the timespec would be a bit out of date (as the mapped time is
read out before the test). Is this something to care about?

[...]
> I really don't know what you mean by "failure condition" here.

Nothing different than above, I just got even more vague, sorry.
 
> For diskfs_grow we need to verify that diskfs_set_node_times (or
> diskfs_node_update, which calls it) gets called eventually afterward.  I
> think that it certainly does, but I haven't checked all the code carefully.

I can try to do some of the leg work here. In fact, I even started this, but
got uncertain (as you could clearly see from my mail) about the one thing I
try to explain above.

> So I think that, in fact, if we eliminate races that could lose update
> marks (as opposed to just delaying their processing) then there will be no
> danger.  The assert is then overaggressive and can be removed.

Sounds good!

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de