Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 May 2013 14:14:43 +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:
> 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"


I tried this but I can't just use the original rec_restore_args(1) because it tries to give each MPI process an exclusive lock, which fails. So I still currently have it like this, which I presume might be dangerous:

	if (options.flags & FLG_RESTORE_CHK) {
		char *rec_name_orig = rec_name;
#ifndef HAVE_MPI
		rec_restore_args(1);
#else
		rec_restore_args(!mpi_id);
#endif

If the argument to rec_restore_args() was the actual lock mode (later or'ed with LOCK_NB), I could do rec_restore_args(LOCK_SH). Should I do this to Jumbo? Then I suppose I could do this instead of the above, without #ifdef MPI:

		rec_restore_args(john_main_process ? LOCK_EX : LOCK_SH);

Or maybe it's fine with just LOCK_SH at that place, MPI, fork, or not?

magnum

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.