1. 27 6月, 2013 8 次提交
  2. 26 6月, 2013 20 次提交
  3. 12 6月, 2013 5 次提交
  4. 11 6月, 2013 6 次提交
  5. 10 6月, 2013 1 次提交
    • K
      xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it. · b2c75c44
      Konrad Rzeszutek Wilk 提交于
      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: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NBob Liu <bob.liu@oracle.com>
      b2c75c44