Bug#77857: hurd: write_node assertion failed building emacs

[Marcus Brinkmann]

On Thu, Nov 23, 2000 at 10:34:53PM -0500, Roland McGrath wrote:
> The first thing to figure out is what the code path looks like that reaches
> getblk when it sets dn_set_mtime there (I think it should be
> pager_unlock_page that is doing it, but you should check).

pager_unlock_page and diskfs_grow are the only callers of ext2_getblk with
create = 1, so those are the only code paths here. Does it matter if it is
one or the other?

> 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.

> But we can't do that before we make sure it's really true that the code
> path that does the problematic mutation of dn_set_mtime is going to handle
> it properly in due course and with all appropriate synchronization.  (I
> would have to read the 1003.1 rules to be sure what the requirements are.)

Please do so. I don't understand what your concerns are. The way I see it,
every failure condition with the assertion removed can also happen with the
assertion, if it happens directly after the assertion check instead shortly
before. I am probably overlooking something. In any way I am not seeing how
one could approach if there actually is a failure condition to worry about.

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