Linux Container Development
 help / color / mirror / Atom feed
From: Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
To: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: Re: [PATCH 2/2] Add a cleanup routine for objhash socket objects
Date: Tue, 15 Sep 2009 17:51:14 -0400	[thread overview]
Message-ID: <4AB00C52.9040604@librato.com> (raw)
In-Reply-To: <87eiq8j653.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>


Dan Smith wrote:
> MH> Does it make sense to add a generic (cleanup) operation when only
> MH> one object type will make use of it?
> 
> In general, I agree with you, but I don't think this is an obscure
> case.
> 
> MH> If we add generic mechanisms for things without having multiple
> MH> uses then are we just obfuscating the special cases of the code?
> 
> MH> As an alternative, would it work if we kept a list of unattached
> MH> sockets in the ckpt context, removed them whenever they become
> MH> attached, and then use the generic "end of restart" deferqueue to
> MH> cleanup unattached sockets?
> 
> It would be more code to do it that way, it would inflate the context
> with another list, and would cause us to iterate these objects more
> than we already do.

I agree with Dan.

So the problem happens because the ref_drop() method cannot tell
whether it's called from restore_obj() to drop an extra reference, or
from obj_hash_clear(), to drop the last reference (from the objhash).

[Actually, the way it is now there is still a leak: if the call to
obj_new() from restore_obj() fails, then the subsequent ref_drop()
*is* intended to drop the last reference, but it will not].

I think that the root of this is that ref_drop() doesn't have enough
information about what's going on. Dan's patch suggested to solve it
by adding a specialized ref_drop() - a cleanup method.

However, now I think that it's probably better to modify the prototype
of ref_drop() to be, e.g.:   void ref_drop(void *ptr, int clean), so
it can be smarter.

>>> +	if (sk->sk_socket && !sk->sk_socket->file) {
> 
> MH> Would it make sense to add a little helper to explain this?
> 
> MH> 	if (!is_sk_attached(sk)) {
> 
> Does that make it more clear?  What's the socket attached to?  Another
> socket?  I could add more words to the helper to make it more obvious
> but IMHO, it's clearer to have it spelled out.
> 

Perhaps a comment to spell it out :)

Oren.

      parent reply	other threads:[~2009-09-15 21:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15 16:52 Avoid leaking unattached socket objects on restore Dan Smith
     [not found] ` <1253033531-6764-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-09-15 16:52   ` [PATCH 1/2] Add a 'cleanup' function to objhash object operations Dan Smith
2009-09-15 16:52   ` [PATCH 2/2] Add a cleanup routine for objhash socket objects Dan Smith
     [not found]     ` <1253033531-6764-3-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-09-15 20:04       ` Serge E. Hallyn
2009-09-15 20:21       ` Matt Helsley
     [not found]         ` <20090915202118.GC10922-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2009-09-15 20:38           ` Dan Smith
     [not found]             ` <87eiq8j653.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-09-15 21:51               ` Oren Laadan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AB00C52.9040604@librato.com \
    --to=orenl-rdfvbdnroixbdgjk7y7tuq@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox