[prev in list] [next in list] [prev in thread] [next in thread]
List: dm-devel
Subject: Re: [dm-devel] multipath tools racy on RUN file.
From: christophe.varoqui () free ! fr
Date: 2004-10-19 9:24:03
Message-ID: 1098177843.4174dd33ac47d () imp1-q ! free ! fr
[Download RAW message or body]
> I was looking at the multipath/main.c source file. I notice at the
> beginning, it has code:
>
> /*
> * Don't run in parallel
> */
...
>
> This is racy. This isn't sufficient to guarantee that two multipath
> binaries will never run concurrently. The multipathd could just happen
> to begin execution at the same instant an administrator runs multipath.
> Both could find the RUN file not present. Both would then do the
> open(), and both would succeed.
>
Yes, I was aware of that but couldn't justify myself the need to serialize more
strictly. In other words, I was lazy to do better.
> Plus, you have the issue of removing this file when multipath exits.
> If multipath should exit abnormally (due to an exception for example),
> it leaves behind the RUN file.
>
Point taken : this is effectively a pain to keep track of this runfile
> I suggest doing something like:
>
...
ok merged
>
> There should be no need to remove the RUN file. If it already exists
> when entering this code, there's no harm done. If the binary exits
> abnormally, the record lock will be removed as part of the kernel's
> exit handling.
>
ok, done
> How does this sound to you?
>
seems good, thanks.
regards,
cvaroqui
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic