[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/6] xen: add reference counter support


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 16 Mar 2023 17:48:46 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YumcMgAKEThHn4zM1e4lKexF4p7jX4+RpZNEnLvP8Ng=; b=cwIX1nxWIquEnYXIkwmnsaD0X5gQMYxGmGVmLukaNKcvS884CGnMaDhkXfxuEGJL4mnWf3CfnNP9bbZyg2wqQMRltTuMlZB5+tnUFFEMrCn7dPoA2B31KN1lvhpOlh7BurQfMd5d2iSJBGPpfpeWR5mLCy7HSKnaHbTcEDcGm/dMQW8QfzopYat7G8wmPHS8i4pNNXRHw60zxrHn946J/1aEyrbMD7oML1mKEe8fotablSoUnYyeF3gAuSLWy9NuKFV2omqyfSNQnA48iCxL/yhDGp2TQotEgUcb3oTKF7j0hb19Zb4LXjFYrc3M2Uw4CKheH+jQNuitcFlkXC90FA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cxsfyPFp1l+9rLcDRXjxd0+6IvuATBqaCc0EQ4OAF2eHlCXfFkO1yCFQ3/ZA0iwKWYSyNy9CTBD9V38F8Y9JtTHZChnD1ISZb2WskPm4YG0fLL4C1k75ViNsOhHwkPoNPSBCRyJYam0qJoZ/2Qmcok5zJqqlod8Oid+J9O1lZmHV0MGVySs7E7sMMMnevOJwt1dmyJCuBMC7PYtoQUZK8AU3YUT/r0Qw0kJr5SJNGwObz26xMLWlAL6qxGUjNXPNi5ILypX7vkKjWRRKcgHvANKPSt2/VZdEUKfm7Z8Wj8veSx+Scvcxa9Mn+N7/AfDUQ/P+0fIWsGfqDhAoDbBSNg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Thu, 16 Mar 2023 16:49:18 +0000
  • Ironport-data: A9a23:RXu4vKwre3I7McZkZVt6t+fUxyrEfRIJ4+MujC+fZmUNrF6WrkUFx mYfD26EO66KZzbwKIt/a4i19B8Hu5fVxtBgSFRqqSAxQypGp/SeCIXCJC8cHc8wwu7rFxs7s ppEOrEsCOhuExcwcz/0auCJQUFUjP3OHfykTrafYEidfCc8IA85kxVvhuUltYBhhNm9Emult Mj75sbSIzdJ4RYtWo4vw//F+UMHUMja4mtC5QRlPK4T4zcyqlFOZH4hDfDpR5fHatE88t6SH 47r0Ly/92XFyBYhYvvNfmHTKxBirhb6ZGBiu1IOM0SQqkEqSh8ai87XAME0e0ZP4whlqvgqo Dl7WT5cfi9yVkHEsLx1vxC1iEiSN4UekFPMCSDXXcB+UyQq2pYjqhljJBheAGEWxgp4KThW3 +08Ag8UVTes2O7ry6O+QOtnxe12eaEHPKtH0p1h5RfwKK58BKvlGuDN79Ie2yosjMdTG/qYf 9AedTdkcBXHZVtIJ0sTD5U92uyvgxETcRUB8A7T+fVxvjeVkFEZPLvFabI5fvSQQspYhACAr 3/u9GXlGBAKcteYzFJp91r13raWwHmrA9p6+LuQzMNrjwTQnHUpUUcZZAW4/KGDkEnmVIcKQ 6AT0m90xUQoz2SpRNTgWxyzoFafowURHdFXFoUS+AyLj6bZ/QudLmwFVSJaLswrstcsQj4n3 UPPmMnmbRRtrbmURHS15rqS6zSoNkA9NnQebCUJSQ8E5djLo4wpiB/LCNF5H8adkdndCTz2h TeQo0AWubIXisIa0rShynrOiTmsu5vhQxY840PcWWfN0+9iTIusZojt8l6C6/9FdNydVgPZ4 CVCnNWC5ucTC53LjDaKXOgGALCu4bCCLSHYhllsWZIm8lxB5kKeQGyZ2xkmTG8BDyrOUWSBj JP70e+J2KJuAQ==
  • Ironport-hdrordr: A9a23:cVv2DaCatJuP7HPlHelg55DYdb4zR+YMi2TDtnoBMiC9F/bzqy nApoV46faZskd1ZJhYo6H8BEDiewKlyXcW2/h2AV7KZmCP0wuVxedZnO/fKlXbehEWndQtrJ uIHZIOb+EYOmIK9/oSIzPVLz/j+rS6GWyT6ts2n00dLj2Cs5sQnzuR0DzrbHGemTM2eabRyK Dsl/auyFKbCAsqhw2AaEU4Yw==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Mar 16, 2023 at 05:43:18PM +0100, Jan Beulich wrote:
> On 16.03.2023 17:39, Roger Pau Monné wrote:
> > On Thu, Mar 16, 2023 at 05:32:38PM +0100, Jan Beulich wrote:
> >> On 16.03.2023 17:19, Roger Pau Monné wrote:
> >>> On Tue, Mar 14, 2023 at 08:56:29PM +0000, Volodymyr Babchuk wrote:
> >>>> +static inline void refcnt_get(refcnt_t *refcnt)
> >>>> +{
> >>>> +    int old = atomic_add_unless(&refcnt->refcnt, 1, 0);
> >>>
> >>> Occurred to me while looking at the next patch:
> >>>
> >>> Don't you also need to print a warning (and saturate the counter
> >>> maybe?) if old == 0, as that would imply the caller is attempting
> >>> to take a reference of an object that should be destroyed? IOW: it
> >>> would point to some kind of memory leak.
> >>
> >> Hmm, I notice the function presently returns void. I think what to do
> >> when the counter is zero needs leaving to the caller. See e.g.
> >> get_page() which will simply indicate failure to the caller in case
> >> the refcnt is zero. (There overflow handling also is left to the
> >> caller ... All that matters is whether a ref can be acquired.)
> > 
> > Hm, likely.  I guess pages never go away even when it's refcount
> > reaches 0.
> > 
> > For the pdev case attempting to take a refcount on an object that has
> > 0 refcounts implies that the caller is using leaked memory, as the
> > point an object reaches 0 it supposed to be destroyed.
> 
> Hmm, my thinking was that a device would remain at refcnt 0 until it is
> actually removed, i.e. refcnt == 0 being a prereq for pci_remove_device()
> to be willing to do anything at all. But maybe that's not a viable model.

Right, I think the intention was for pci_remove_device() to drop the
refcount to 0 and do the removal, so the refcount should be 1 when
calling pci_remove_device().  But none of this is written down, so
it's mostly my assumptions from looking at the code.

I have some comments about the model in patch 2, I think we need to
clarify the intended usage on the commit log about pdev and refcounts.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.