[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.
|