All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
To: Dave Hansen <dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org>,
	Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Subject: Re: [RFC v10][PATCH 09/13] Restore open file descriprtors
Date: Mon, 01 Dec 2008 16:00:54 -0500	[thread overview]
Message-ID: <49345086.4@cs.columbia.edu> (raw)
In-Reply-To: <1228164873.2971.95.camel@nimitz>



Dave Hansen wrote:
> On Mon, 2008-12-01 at 15:41 -0500, Oren Laadan wrote:
>>>>> +   fd = cr_attach_file(file);      /* no need to cleanup 'file' below */
>>>>> +   if (fd < 0) {
>>>>> +           filp_close(file, NULL);
>>>>> +           ret = fd;
>>>>> +           goto out;
>>>>> +   }
>>>>> +
>>>>> +   /* register new <objref, file> tuple in hash table */
>>>>> +   ret = cr_obj_add_ref(ctx, file, parent, CR_OBJ_FILE, 0);
>>>>> +   if (ret < 0)
>>>>> +           goto out;
>>>> Who said that file still exists at that point?
>> Correct. This call should move higher up befor ethe call to cr_attach_file()
> 
> Is that sufficient?  It seems like we're depending on the fd's reference
> to the 'struct file' to keep it valid in the hash.  If something happens
> to the fd (like the other thread messing with it) the 'struct file' can
> still go away.
> 
> Shouldn't we do another get_file() for the hash's reference?

When a shared object is inserted to the hash we automatically take another
reference to it (according to its type) for as long as it remains in the
hash. See:  'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'.  So by moving that
call higher up, we protect the struct file.

Oren.

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Oren Laadan <orenl@cs.columbia.edu>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Linus Torvalds <torvalds@osdl.org>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC v10][PATCH 09/13] Restore open file descriprtors
Date: Mon, 01 Dec 2008 16:00:54 -0500	[thread overview]
Message-ID: <49345086.4@cs.columbia.edu> (raw)
In-Reply-To: <1228164873.2971.95.camel@nimitz>



Dave Hansen wrote:
> On Mon, 2008-12-01 at 15:41 -0500, Oren Laadan wrote:
>>>>> +   fd = cr_attach_file(file);      /* no need to cleanup 'file' below */
>>>>> +   if (fd < 0) {
>>>>> +           filp_close(file, NULL);
>>>>> +           ret = fd;
>>>>> +           goto out;
>>>>> +   }
>>>>> +
>>>>> +   /* register new <objref, file> tuple in hash table */
>>>>> +   ret = cr_obj_add_ref(ctx, file, parent, CR_OBJ_FILE, 0);
>>>>> +   if (ret < 0)
>>>>> +           goto out;
>>>> Who said that file still exists at that point?
>> Correct. This call should move higher up befor ethe call to cr_attach_file()
> 
> Is that sufficient?  It seems like we're depending on the fd's reference
> to the 'struct file' to keep it valid in the hash.  If something happens
> to the fd (like the other thread messing with it) the 'struct file' can
> still go away.
> 
> Shouldn't we do another get_file() for the hash's reference?

When a shared object is inserted to the hash we automatically take another
reference to it (according to its type) for as long as it remains in the
hash. See:  'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'.  So by moving that
call higher up, we protect the struct file.

Oren.


WARNING: multiple messages have this Message-ID (diff)
From: Oren Laadan <orenl@cs.columbia.edu>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Linus Torvalds <torvalds@osdl.org>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC v10][PATCH 09/13] Restore open file descriprtors
Date: Mon, 01 Dec 2008 16:00:54 -0500	[thread overview]
Message-ID: <49345086.4@cs.columbia.edu> (raw)
In-Reply-To: <1228164873.2971.95.camel@nimitz>



Dave Hansen wrote:
> On Mon, 2008-12-01 at 15:41 -0500, Oren Laadan wrote:
>>>>> +   fd = cr_attach_file(file);      /* no need to cleanup 'file' below */
>>>>> +   if (fd < 0) {
>>>>> +           filp_close(file, NULL);
>>>>> +           ret = fd;
>>>>> +           goto out;
>>>>> +   }
>>>>> +
>>>>> +   /* register new <objref, file> tuple in hash table */
>>>>> +   ret = cr_obj_add_ref(ctx, file, parent, CR_OBJ_FILE, 0);
>>>>> +   if (ret < 0)
>>>>> +           goto out;
>>>> Who said that file still exists at that point?
>> Correct. This call should move higher up befor ethe call to cr_attach_file()
> 
> Is that sufficient?  It seems like we're depending on the fd's reference
> to the 'struct file' to keep it valid in the hash.  If something happens
> to the fd (like the other thread messing with it) the 'struct file' can
> still go away.
> 
> Shouldn't we do another get_file() for the hash's reference?

When a shared object is inserted to the hash we automatically take another
reference to it (according to its type) for as long as it remains in the
hash. See:  'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'.  So by moving that
call higher up, we protect the struct file.

Oren.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-12-01 21:00 UTC|newest]

Thread overview: 138+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27  1:04 [RFC v10][PATCH 00/13] Kernel based checkpoint/restart Oren Laadan
2008-11-27  1:04 ` Oren Laadan
2008-11-27  1:04 ` Oren Laadan
     [not found] ` <1227747884-14150-1-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-11-27  1:04   ` [RFC v10][PATCH 01/13] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 02/13] Checkpoint/restart: initial documentation Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
     [not found]     ` <1227747884-14150-3-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-11-28 10:45       ` Al Viro
2008-11-28 10:45         ` Al Viro
2008-11-28 10:45         ` Al Viro
     [not found]         ` <20081128104554.GP28946-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2008-12-01 18:15           ` Dave Hansen
2008-12-01 18:15           ` Dave Hansen
2008-12-01 18:15             ` Dave Hansen
2008-12-01 18:15             ` Dave Hansen
2008-11-28 10:45       ` Al Viro
2008-11-27  1:04   ` [RFC v10][PATCH 03/13] General infrastructure for checkpoint restart Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 04/13] x86 support for checkpoint/restart Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 05/13] Dump memory address space Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
     [not found]     ` <1227747884-14150-6-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-11-28 10:53       ` Al Viro
2008-11-28 10:53         ` Al Viro
2008-11-28 10:53         ` Al Viro
     [not found]         ` <20081128105351.GQ28946-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2008-12-01 18:00           ` Dave Hansen
2008-12-01 18:00             ` Dave Hansen
2008-12-01 18:00             ` Dave Hansen
2008-12-01 20:57             ` Oren Laadan
2008-12-01 20:57               ` Oren Laadan
2008-12-01 20:57               ` Oren Laadan
2008-12-01 20:57             ` Oren Laadan
2008-12-01 18:00           ` Dave Hansen
2008-11-28 10:53       ` Al Viro
2008-11-27  1:04   ` [RFC v10][PATCH 06/13] Restore " Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 07/13] Infrastructure for shared objects Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 08/13] Dump open file descriptors Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
     [not found]     ` <1227747884-14150-9-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-11-28 10:19       ` Al Viro
2008-11-28 10:19       ` Al Viro
2008-11-28 10:19         ` Al Viro
2008-11-28 10:19         ` Al Viro
     [not found]         ` <20081128101919.GO28946-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2008-12-01 17:47           ` Dave Hansen
2008-12-01 17:47             ` Dave Hansen
2008-12-01 17:47             ` Dave Hansen
2008-12-01 20:23             ` Oren Laadan
2008-12-01 20:23             ` Oren Laadan
2008-12-01 20:23               ` Oren Laadan
2008-12-01 20:23               ` Oren Laadan
     [not found]               ` <493447DD.7010102-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-12-01 20:51                 ` Dave Hansen
2008-12-01 20:51                 ` Dave Hansen
2008-12-01 20:51                   ` Dave Hansen
2008-12-01 20:51                   ` Dave Hansen
2008-12-01 21:02                   ` Linus Torvalds
2008-12-01 21:02                     ` Linus Torvalds
2008-12-01 21:02                     ` Linus Torvalds
     [not found]                     ` <alpine.LFD.2.00.0812011258390.3256-nfNrOhbfy2R17+2ddN/4kux8cNe9sq/dYPYVAmT7z5s@public.gmane.org>
2008-12-01 21:25                       ` Dave Hansen
2008-12-01 21:25                       ` Dave Hansen
2008-12-01 21:25                         ` Dave Hansen
2008-12-01 21:25                         ` Dave Hansen
2008-12-01 21:02                   ` Linus Torvalds
2008-12-01 21:20                   ` Oren Laadan
2008-12-01 21:20                     ` Oren Laadan
2008-12-01 21:20                   ` Oren Laadan
2008-12-01 17:47           ` Dave Hansen
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 09/13] Restore open file descriprtors Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
     [not found]     ` <1227747884-14150-10-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-11-28 11:27       ` Al Viro
2008-11-28 11:27         ` Al Viro
2008-11-28 11:27         ` Al Viro
     [not found]         ` <20081128112745.GR28946-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2008-12-01 19:22           ` Dave Hansen
2008-12-01 19:22           ` Dave Hansen
2008-12-01 19:22             ` Dave Hansen
2008-12-01 19:22             ` Dave Hansen
2008-12-01 20:41             ` Oren Laadan
2008-12-01 20:41             ` Oren Laadan
2008-12-01 20:41               ` Oren Laadan
2008-12-01 20:41               ` Oren Laadan
     [not found]               ` <49344C11.6090204-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-12-01 20:54                 ` Dave Hansen
2008-12-01 20:54                   ` Dave Hansen
2008-12-01 20:54                   ` Dave Hansen
2008-12-01 21:00                   ` Oren Laadan [this message]
2008-12-01 21:00                     ` Oren Laadan
2008-12-01 21:00                     ` Oren Laadan
     [not found]                     ` <49345086.4-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-12-01 21:07                       ` Dave Hansen
2008-12-01 21:07                       ` Dave Hansen
2008-12-01 21:07                         ` Dave Hansen
2008-12-01 21:07                         ` Dave Hansen
2008-12-02  1:31                         ` Dave Hansen
2008-12-02  1:31                         ` Dave Hansen
2008-12-02  1:31                           ` Dave Hansen
2008-12-02  1:31                           ` Dave Hansen
2008-12-02  1:12                       ` Dave Hansen
2008-12-02  1:12                         ` Dave Hansen
2008-12-02  1:12                         ` Dave Hansen
2008-12-02  1:12                       ` Dave Hansen
2008-12-01 21:00                   ` Oren Laadan
2008-12-01 20:54                 ` Dave Hansen
2008-11-28 11:27       ` Al Viro
2008-11-27  1:04   ` [RFC v10][PATCH 10/13] External checkpoint of a task other than ourself Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 11/13] Track in-kernel when we expect checkpoint/restart to work Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 12/13] Checkpoint multiple processes Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04   ` [RFC v10][PATCH 13/13] Restart " Oren Laadan
2008-11-27  1:04   ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-11-27  1:04     ` Oren Laadan
2008-12-03 23:58   ` [RFC v10][PATCH 00/13] Kernel based checkpoint/restart Serge E. Hallyn
2008-12-03 23:58   ` Serge E. Hallyn
2008-12-03 23:58     ` Serge E. Hallyn
2008-12-03 23:58     ` 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=49345086.4@cs.columbia.edu \
    --to=orenl-eqauephvms7envbuuze7ea@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mingo-X9Un+BFzKDI@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    --cc=torvalds-3NddpPZAyC0@public.gmane.org \
    --cc=viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.