On Wed, 15 Aug 2012 17:40:19 +0300, "Michael S. Tsirkin" [off-list ref] wrote:

On Wed, Aug 15, 2012 at 09:34:58AM -0300, Rafael Aquini wrote:

quoted

On Tue, Aug 14, 2012 at 10:31:09PM +0300, Michael S. Tsirkin wrote:

quoted

quoted

quoted

now CPU1 executes the next instruction:

}

which would normally return to function's caller,
but it has been overwritten by CPU2 so we get corruption.

No?

At the point CPU2 is unloading the module, it will be kept looping at the
snippet Rusty pointed out because the isolation / migration steps do not mess
with 'vb->num_pages'. The driver will only unload after leaking the total amount
of balloon's inflated pages, which means (for this hypothetical case) CPU2 will
wait until CPU1 finishes the putaback procedure.

Yes but only until unlock finishes. The last return from function
is not guarded and can be overwritten.

CPU1 will be returning to putback_balloon_page() which code is located at core
mm/compaction.c, outside the driver.

Sorry, I don't seem to be able to articulate this clearly.
But this is a correctness issue so I am compelled to try again.

But if there are 0 balloon pages, how is it migrating a page?

In the end the rule is simple: you can not
prevent module unloading from within module
itself. It always must be the caller of your
module that uses some lock to do this.

Not quite.  If you clean up everything in your cleanup function, it also
works, which is what this does, right?

Cheers,
Rusty.