[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug#77857: hurd: write_node assertion failed building emacs
From: |
Marcus Brinkmann |
Subject: |
Bug#77857: hurd: write_node assertion failed building emacs |
Date: |
Sun, 3 Dec 2000 06:22:24 +0100 |
User-agent: |
Mutt/1.1.4i |
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