From: "Mickaël Salaün" <mic@digikod.net>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: procfs/d_invalidate break userland
Date: Thu, 23 Apr 2015 09:00:15 +0200 [thread overview]
Message-ID: <5538987F.5090402@digikod.net> (raw)
In-Reply-To: <20150422235135.GY889@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
On 04/23/2015 01:51 AM, Al Viro wrote:
> On Thu, Apr 23, 2015 at 01:41:02AM +0200, Mickaël Salaün wrote:
>> Hi,
>>
>> For your information, the commit bbd5192412fdedbae00888316bfe350bf89d0458 (proc: Update proc_flush_task_mnt to use d_invalidate), in the v3.17, break some userland use of procfs.
>>
>> In a user namespace, I'm using /proc/<pid>/task/<tid>/fdinfo to mount a tmpfs, chdir into it, terminate the <tid> thread, and use the tmpfs as a private working directory for PID 1. This trick is useful to disconnect/d_drop a directory from the current file system and make it inaccessible to the other processes (kind of an O_TMPFILE for directory).
>>
>> With the v3.17 this is no more possible because it's no more possible to mount anything in this tmpfs nor use the previously mounted file systems in this tmpfs.
>>
>> The new d_invalidate is really good to lazily invalidate/umount an entire hierarchy but I'm not sure the intention was to remove this useful "feature" ;)
>
> And what will happen if you mount stuff there and exit? Dirty filesystem
> after reboot?
>
I didn't notice any but only do tmpfs or bind mounts because of user namespace anyway.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
prev parent reply other threads:[~2015-04-23 8:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 23:41 procfs/d_invalidate break userland Mickaël Salaün
2015-04-22 23:51 ` Al Viro
2015-04-23 7:00 ` Mickaël Salaün [this message]
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=5538987F.5090402@digikod.net \
--to=mic@digikod.net \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@ZenIV.linux.org.uk \
/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.