Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 May 2013 07:48:46 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: MPI vs. --fork

On 3 May, 2013, at 3:55 , Solar Designer <solar@...nwall.com> wrote:
> On Fri, May 03, 2013 at 12:20:20AM +0200, magnum wrote:
>> Resuming MPI is a little tricky. I think I'll have to "emulate" fork: first all nodes will read the unnumbered rec file (with lock=0, right?), and then re-read the correct one at the same point a -fork session would have actually forked and be doing that.
> 
> I'm not sure if you were asking that question, but just in case: with
> --fork, the main process currently reads its unnumbered .rec file with
> lock held.  Initially, it reads the .rec file's portion not specific to
> a cracking mode.  Then it forks its children, each of which closes the
> main process' .rec file descriptor and opens their own .rec file (also
> with locking, indeed).  The main process proceeds to read the rest of
> its .rec file (the cracking mode specific portion).  (Meanwhile, the
> children may be doing the same with their .rec files.)  Then the main
> process removes the lock on its .rec file and closes it.  Explicitly
> removing the lock is important in case one of the children has not yet
> closed its duplicate of the fd.  Finally, the main process proceeds with
> actual cracking, which involves re-opening and re-locking the .rec file.
> (This could be simplified to avoid the re-opening and re-locking, and
> thus avoid the window during which another invocation could lock the
> file, making this invocation fail to proceed further, but I did not
> bother re-working this historical implementation yet.)  The children
> also proceed with actual cracking, which also involves re-opening and
> re-locking the .rec file.
> 
> So the answer to your "with lock=0, right?" is probably "no", but I'm
> not sure what exactly you meant.

Thanks, yes I needed this explanation. Right now I do the above with only one process locking it at first. It will be safer having all of them lock it, in case some process get delayed a lot.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ