mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sam Vilain <sam@vilain.net>
To: Kirill Korotaev <dev@sw.ru>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	xemul@sw.ru, ebiederm@xmission.com, haveblue@us.ibm.com,
	linux-kernel@vger.kernel.org, herbert@13thfloor.at,
	devel@openvz.org, serue@us.ibm.com
Subject: Re: [RFC][PATCH 1/2] Virtualization of UTS
Date: Tue, 28 Mar 2006 15:45:56 +1200	[thread overview]
Message-ID: <1143517556.7156.9.camel@localhost.localdomain> (raw)
In-Reply-To: <44242CE7.3030905@sw.ru>

On Fri, 2006-03-24 at 20:31 +0300, Kirill Korotaev wrote:
> +static inline void get_uts_ns(struct uts_namespace *ns)
> +{
> +	atomic_inc(&ns->cnt);
> +}
> +
> +static inline void put_uts_ns(struct uts_namespace *ns)
> +{
> +	if (atomic_dec_and_test(&ns->cnt))
> +		free_uts_ns(ns);
> +}

I think somebody already said this, but this is probably better using
kobject as I was asked to for the vx_info.  (Documentation/kobject.txt)

Also I think it might be useful to have a count of tasks that refer to
the structure, in addition to the count of actual references.  In this
way you can know whether the resource is "free" before its kobject
destructor is called (as the vserver vx_info does).

Perhaps that abstraction is best to put in when it becomes "useful",
like you have a situation where you want to do something when the last
process with a utsname exits, but before the last kthread referencing
the structure stops (eg, a sleeping process reading /proc somewhere).

Otherwise, nice and simple; I could quite easily at this point plug this
into the syscall infrastructure I posted earlier (once it is reworked
based on people's comments), and provide tests for this.

Sam.


  parent reply	other threads:[~2006-03-28  3:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24 17:23 [RFC] Virtualization patches for IPC/UTS. 2nd step Kirill Korotaev
2006-03-24 17:31 ` [RFC][PATCH 1/2] Virtualization of UTS Kirill Korotaev
2006-03-24 19:09   ` Eric W. Biederman
2006-03-24 19:35     ` Kirill Korotaev
2006-03-24 19:50       ` Eric W. Biederman
2006-03-27 19:40       ` Eric W. Biederman
2006-03-24 20:28   ` James Morris
2006-03-28  3:45   ` Sam Vilain [this message]
2006-03-24 17:35 ` [RFC][PATCH 2/2] Virtualization of IPC Kirill Korotaev
2006-03-24 19:13   ` Dave Hansen
2006-03-24 21:27     ` Herbert Poetzl
2006-03-28  5:26       ` Sam Vilain
2006-03-24 20:09   ` Eric W. Biederman
2006-03-27 15:33   ` Serge E. Hallyn

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=1143517556.7156.9.camel@localhost.localdomain \
    --to=sam@vilain.net \
    --cc=akpm@osdl.org \
    --cc=dev@sw.ru \
    --cc=devel@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serue@us.ibm.com \
    --cc=torvalds@osdl.org \
    --cc=xemul@sw.ru \
    /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

Powered by JetHome