I didn't have a concrete issue with that yet, though I consider it quite evil: Whenever lvmraid= is used, mdstart is executed even if there is an image to be resumed later. Couldn't it end up FUBAR, if (for example) mdstart initiates a raid resync just before a suspended image is resumed? Frankly, I don't know if mdstart is a read-only action (until some foo happens...). In that case, everything should be allright. Reproducible: Always
Nope. A RAID resync is done below the file-system layer. Remember that the resync is also a kernel thread, so the userland doesn't affect its underlying functioning. If you're willing to prove this, then I'll revisit it. The only way this would cause an issue is if things are not working as they're supposed to be, which would definitely be a bug in that code (not genkernel) and needs to be fixed. I'm marking this as INVALID since everything *should* be correct.
Well, that is not the point. According to its documentation (and common sense, too), suspend2 swaps the system's complete state, including the kernel. Therefore, even running kernel threads will be lost from the time of do_resume. No matter if it's in userspace or whereever. IMO, the only way this could not be harmful would be to ensure that the kernel under which mdstart is called, will do absolute no changes to the underlying block devices (until suspend2_resume has been passed without action). But I'm afraid it would initiate a resync immediately (if neccessary). Also, I wouldn't call it a bug in the code. It's widely known that any write access to drives used within a currently suspended session will most probably cause severe damage. This should apply to the file-system layer (i.e. mounting rw while suspended) as well as to other layers (i.e. assembling and modifying a RAID while it's already running, though suspended).
