From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933015AbcLGVdb convert rfc822-to-8bit (ORCPT ); Wed, 7 Dec 2016 16:33:31 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:45552 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932423AbcLGVd2 (ORCPT ); Wed, 7 Dec 2016 16:33:28 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Ian Kent Cc: Al Viro , Andrew Morton , autofs mailing list , Kernel Mailing List , linux-fsdevel , Omar Sandoval References: <148029910861.27779.4517883721395202453.stgit@pluto.themaw.net> <20161203051322.GA24765@ZenIV.linux.org.uk> <1481017056.4589.21.camel@themaw.net> Date: Thu, 08 Dec 2016 10:30:24 +1300 In-Reply-To: <1481017056.4589.21.camel@themaw.net> (Ian Kent's message of "Tue, 06 Dec 2016 17:37:36 +0800") Message-ID: <8737hzv34f.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1cEjq4-0007ja-Nr;;;mid=<8737hzv34f.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=101.100.131.98;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18IC4oKxz+YLYvjRxcTqBMRq0rLizkR944= X-SA-Exim-Connect-IP: 101.100.131.98 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.5 XMGappySubj_01 Very gappy subject * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_04 7+ unique symbols in subject * 0.1 XM_H_SpoofStaff3 XMission Staff Spoof * 0.2 T_XMDrugObfuBody_14 obfuscated drug references * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Ian Kent X-Spam-Relay-Country: X-Spam-Timing: total 5306 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.4 (0.1%), b_tie_ro: 2.4 (0.0%), parse: 0.96 (0.0%), extract_message_metadata: 12 (0.2%), get_uri_detail_list: 1.83 (0.0%), tests_pri_-1000: 4.9 (0.1%), tests_pri_-950: 1.26 (0.0%), tests_pri_-900: 1.04 (0.0%), tests_pri_-400: 24 (0.5%), check_bayes: 23 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 8 (0.2%), b_comp_prob: 2.6 (0.0%), b_tok_touch_all: 2.7 (0.1%), b_finish: 0.71 (0.0%), tests_pri_0: 297 (5.6%), check_dkim_signature: 0.74 (0.0%), check_dkim_adsp: 3.2 (0.1%), tests_pri_500: 4959 (93.5%), poll_dns_idle: 4946 (93.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and path_is_mountpoint_rcu() X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ian Kent writes: > On Sat, 2016-12-03 at 05:13 +0000, Al Viro wrote: >> FWIW, I've folded that pile into vfs.git#work.autofs. >> >> Problems: > > snip ... > >> * the last one (propagation-related) is too ugly to live - at the >> very least, its pieces should live in fs/pnode.c; exposing propagate_next() >> is simply wrong.  I hadn't picked that one at all, and I would suggest >> coordinating anything in that area with ebiederman - he has some work >> around fs/pnode.c and you risk stepping on his toes. > > The earlier patches seem to be ok now so how about we talk a little about this > last one. > > Eric, Al mentioned that you are working with fs/pnode.c and recommended I co- > ordinate with you. > > So is my working on this this (which is most likely going to live in pnode.c if > I can can get something acceptable) going to cause complications for you? > Is what your doing at a point were it would be worth doing as Al > suggests? > > Anyway, the problem that this patch is supposed to solve is to check if any of > the list of mnt_mounts or any of the mounts propagated from each are in use. > > One obvious problem with it is the propagation could be very large. > > But now I look at it again there's no reason to have to every tree because if > one tree is busy then the the set of trees is busy. But every tree would be > visited if the not busy so it's perhaps still a problem. > > The difficult thing is working out if a tree is busy, more so because there > could be a struct path holding references within any the trees so I don't know > of a simpler, more efficient way to check for this. So coordination seems to be in order. Not so much because of your current implementation (which won't tell you what you want to know) but because an implementation that tells you what you are looking for has really bad > O(N^2) complexity walking the propagation tree in the worst case. To be correct you code would need to use next_mnt and walk the tree and on each mount use propagate_mnt_busy to see if that entry can be unmounted. Possibly with small variations to match your case. Mounts in one part of the tree may propagate to places that mounts in other parts of the tree will not. I am assuming you are not worried about MNT_DETACH, as that case would not need may_umount_tree at all. I am researching how to make walking propagation for multiple mounts efficient but it is a non-trivial problem. > Anyone have any suggestions at all? In the short term I recommend just not doing this, but if you want to see if you can find an efficient algorithm with me, I am happy to bring you up to speed on all of the gory details. Eric