[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: Bug in tmem: refcount leak leaves zombie saved domains
Keir -- I'd like to do a get_domain_by_id() without doing a get_domain() as the tmem code need only get_domain() once on first use and put_domain() once when destroying, but frequently needs to lookup a domain by id. It looks like rcu_lock_domain_by_id() does what I need, but I don't need any rcu critical sections (outside of the domain lookup itself) and am fearful that if rcu locking ever is fully implemented, my use of rcu_lock_domain_by_id() would become incorrect and I may have a problem. Should I create an equivalent get_domain_by_id_no_ref()? Or am I misunderstanding something? Semi-related, rcu_lock_domain_by_id() has a "return d" inside the for loop without an rcu_read_unlock(). I see that this is irrelevant now because rcu_read_unlock() is a no-op anyway, but maybe this should be cleaned up for the same reason -- in case rcu locking is ever fully implemented. Thanks, Dan > -----Original Message----- > From: Dan Magenheimer > Sent: Thursday, June 10, 2010 7:08 AM > To: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: [Xen-devel] RE: Bug in tmem: refcount leak leaves zombie saved > domains > > OK, will take a look. > > IIRC, Jan's work to fix the domain reference stuff just > before 4.0 shipped was a heavy hammer but since it seemed > to work, I didn't want to mess with it so close to release... > really there's only a need to take a reference once on > first use and release it at shutdown, rather than > take/release frequently. IIRC, I had used a macro that > took references when they weren't really needed and > Jan placed the matching macros that did the release. > > Dan > > > -----Original Message----- > > From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] > > Sent: Thursday, June 10, 2010 3:47 AM > > To: xen-devel@xxxxxxxxxxxxxxxxxxx > > Cc: Dan Magenheimer > > Subject: Bug in tmem: refcount leak leaves zombie saved domains > > > > Dan, > > > > Just doing some save/restore testing on xen-unstable tip, I noticed > > that: > > # xm create ./pv_config > > # xm save PV1 > > > > Would leave the saved guest as a zombie in the DOMDYING_dead state > with > > no > > pages, yet with refcnt=1. This happens absolutely consistently. Just > as > > consistently, it does not happen when I boot Xen with no-tmem. My > > conclusion > > is that tmem is leaking a domain reference count during domain save. > > This > > doesn't happen if I merely "xm create ...; xm destroy ...". > > > > My pv_config file contains nothing exciting: > > kernel = "/nfs/keir/xen/xen64.hg/dist/install/boot/vmlinuz-2.6.18.8- > > xenU" > > memory = 750 > > name = "PV1" > > vcpus = 2 > > vif = [ 'mac=00:1a:00:00:01:01' ] > > disk = [ 'phy:/dev/VG/Suse10.1_64_1,sda1,w' ] > > root = "/dev/sda1 ro xencons=tty" > > extra = "" > > tsc_native = 1 > > on_poweroff = 'destroy' > > on_reboot = 'restart' > > on_crash = 'preserve' > > > > The dom{0,U} kernels are tip of linux-2.6.18-xen, default -xen{0,U} > > configs. > > > > -- Keir > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |