[CRIU] [PATCH] mount: mnt_entry_alloc -- Don't forget to init @mnt_slave

Andrew Vagin avagin at odin.com
Tue Sep 1 03:47:14 PDT 2015


On Tue, Sep 01, 2015 at 01:12:07PM +0300, Cyrill Gorcunov wrote:
> On Tue, Sep 01, 2015 at 12:32:31PM +0300, Pavel Emelyanov wrote:
> > > 
> > > Because it's a separate routine called "mnt_entry_alloc",
> > > it has no clue how would we use any of this list entries.
> > > So I think it's better to init this entry, frankly its
> > > just a few cpu ops.
> > 
> > Kernel doesn't initialize list-entries without need either :) Only
> > heads. So I'd just add a comment somewhere saying this.
> 
> static struct mount *alloc_vfsmnt(const char *name)
> {
> 	struct mount *mnt = kmem_cache_zalloc(mnt_cache, GFP_KERNEL);
> 	...
> 		INIT_LIST_HEAD(&mnt->mnt_share);
> 		INIT_LIST_HEAD(&mnt->mnt_slave_list);
> 		INIT_LIST_HEAD(&mnt->mnt_slave);
> 	...
> }
> 
> Really, such kind of things are simply waiting for trigger the bugs.
> Instead of adding comment do a right thing and simply init the entry.

"Null pointer dereference" is better than wrong data in images.

> Yes, we have a couple of places in criu where we don't init list
> entries but the difference is that we allocate and add them immediately,
> not somewhere "later" in code. For example
> 
> open_remap_ghost
> 	gf = shmalloc(sizeof(*gf));
> 	...
> 	list_add_tail(&gf->list, &ghost_files);
> 
> that's fine, because we allocate and collect in one place.
> 
> Anyway, this aspect doesn't worth to waste time on it so if
> you both don't like it I can live with that, drop it.
> 
> 	Cyrill


More information about the CRIU mailing list