From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out03.mta.xmission.com ([166.70.13.233]:59364 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758018AbdAKCbE (ORCPT ); Tue, 10 Jan 2017 21:31:04 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Krister Johansen Cc: Al Viro , linux-fsdevel@vger.kernel.org, containers@lists.linux-foundation.org References: <20170111012454.GB2497@templeofstupid.com> Date: Wed, 11 Jan 2017 15:27:05 +1300 In-Reply-To: <20170111012454.GB2497@templeofstupid.com> (Krister Johansen's message of "Tue, 10 Jan 2017 17:24:54 -0800") Message-ID: <87fukqwcue.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Possible bug: detached mounts difficult to cleanup Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Krister Johansen writes: > Gents, > > I wondered if a naive solution could re-walk the list of mounts > processed in umount_tree() and if all of the detached but locked mounts > had a refcount that indicated they're unused, they could be unlocked and > unmounted. At least in the case of the containers I'm dealing with, the > the container software should be ensuring that nothing in the container > has a reference on anything that's under the detached portion of the > tree. However, there's probably a better way to do this. So if the code is working correctly that should already happen. The design is for the parent mount to hold a reference to the submounts. And when the reference on the parent drops to 0. The references on all of the submounts will also be dropped. I was hoping to read the code and point it out to you quickly, but I am not seeing it now. I am wondering if in all of the refactoring of that code something was dropped/missed :( Somewhere there is supposed to be the equivalent of: pin_insert_group(&p->mnt_umount, &p->mnt_parent->mnt, &unmounted); when we unhash those mounts because the last count has gone away. Either it is very sophisticated or I am missing it. Grr.... Eric