Patchset to add asynchronous open/close to master

[David Collier-Brown]

Actually one can verify it, with considerable care, on a whiteboard.  A
prof of mine taught it, in a course on safety-critical systems.

To oversimplify, you draw a DFA of the individual atomic changes that
make up the sequence you want on the wall, and then make an exhaustive
list of all the events that could affect any.  For each node, you ask
what problem the external events could cause, and if they're not
handled, you add steps to ensure that are fixed, drawn as an arc that
leads back to the node, with a time written on it.  Those are the times
in which the system will be in a "bad" state before it is fixed. You
obviously prefer "0 milliseconds".  Then you go through and make sure
the non-zero periods can be protected by an external means, like a lock.

I did these for three years, and "ran out of memory" was the usual
problem with a non-zero repair time, and the period tended to be
@$^!&#(##*!~ (excessively) long.


--dave (now I DO feel old!) c-b



On 06/20/2012 01:07 PM, Jeremy Allison wrote:
> On Wed, Jun 20, 2012 at 06:58:05PM +0200, Volker Lendecke wrote:
>> The explanation fully describes what the patch is doing. It
>> is just that I disagree that we should do it this way.
> Well that's a problem. I'm asking you to trust my technical
> judgement on this. If you don't trust that, then there's
> little I can do to convince you by rational argument.
>
>> It can happen that files are created where a normal create
>> would not have been possible due to kernel-based
>> permissions. Imagine a become_root() at an inopportune time
>> while an async open as a non-privileged user is just about
>> to be scheduled. This is a classic time-of-check -
>> time-of-use race from my point of view.
> As I just replied to Simo, we already check in the
> CreateFile path. The only way to avoid any races
> is to have a kernel CreateFile call.
>
> Jeremy.
>


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-8968