• Konrad Rzeszutek Wilk's avatar
    xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it. · b2c75c44
    Konrad Rzeszutek Wilk authored
    Commit 10a7a077 ("xen: tmem: enable Xen
    tmem shim to be built/loaded as a module") allows the tmem module
    to be loaded any time. For this work the frontswap API had to
    be able to asynchronously to call tmem_frontswap_init before
    or after the swap image had been set. That was added in git
    commit 905cd0e1
    ("mm: frontswap: lazy initialization to allow tmem backends to build/run as modules").
    Which means we could do this (The common case):
     modprobe tmem		[so calls frontswap_register_ops, no ->init]
    			 modifies tmem_frontswap_poolid = -1
     swapon /dev/xvda1	[__frontswap_init, calls -> init, tmem_frontswap_poolid is
    			 < 0 so tmem hypercall done]
    Or the failing one:
     swapon /dev/xvda1	[calls __frontswap_init, sets the need_init bitmap]
     modprobe tmem		[calls frontswap_register_ops, -->init calls, finds out
    			tmem_frontswap_poolid is 0, does not make a hypercall.
    			Later in the module_init, sets tmem_frontswap_poolid=-1]
    Which meant that in the failing case we would not call the hypercall
    to initialize the pool and never be able to make any frontswap
    backend calls.
    Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
    fixes it.
    Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: default avatarBob Liu <bob.liu@oracle.com>
tmem.c 10.6 KB