From: ebiederm@xmission.com (Eric W. Biederman)
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [git pull] mount API series
Date: Wed, 31 Oct 2018 10:38:17 -0500 [thread overview]
Message-ID: <87a7mut9cm.fsf@xmission.com> (raw)
In-Reply-To: <20181031053355.GQ32577@ZenIV.linux.org.uk> (Al Viro's message of "Wed, 31 Oct 2018 05:33:55 +0000")
Al Viro <viro@ZenIV.linux.org.uk> writes:
> mount API series from David Howells. Last cycle's objections
> had been of the "I'd do it differently" variety and with no such
> differently done variants having ever materialized over several
> cycles...
Absolutely not.
My objections fundamentally is that I can find real problems when I look
at the code. Further the changes have not been incremental changes that
have evolved the code from one state to another but complete
replacements of code that make code review very difficult and bisection
completely inapplicable.
I also object that this series completely fails to fix the worst but I
have ever seen in the mount API. Whit no real intrest shown in working
to fix it.
A couple of bugs that I can see quickly. Several of which I have
previously reported:
- There is an easily triggered NULL pointer deference with open_tree
and mount propagation.
- Bisection will not work with the cpuset filesystem patch. At least
cpuset looks like it may be mountable now.
- The setting of fc->user_ns on proc remains broken. In particular if you
create a child user namespace and attempt to mount proc it will succeed
instead of fail.
- The mqueue filesystem has the same issue as proc. fc->user_ns is misset.
I suspect I didn't report it well but I reported both the proc and the
mqueue filesystem weeks before the merge window opened.
I am going to stop there. I believe there are more issues in the code.
I am relieved that I am not seeing the loss of some of the security
hooks that I thought I saw last time I looked at the code.
Given both that I have reported bugs that remain unfixed and it's
non-evolutionary nature that makes this patchset hard to review I have
no confidence in this set of patches.
I think the scope has been too large for anyone to properly review the
code and it should be broken into smaller pieces. That there were
significant open_tree and move_mount issues being found just before the
merge window opened seems a testament to that. (AKA the first 3 or so
patches in the patchset and fundamental to the rest).
My apologies that we have not been able communication better and that I
have not been able to clearly point out all of the bugs. My apologies
I have not yet been able to give more constructive feedback.
Still at the end of the day there remain regressions of existing
functionality in that tree.
Eric
next prev parent reply other threads:[~2018-10-31 15:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 5:33 [git pull] mount API series Al Viro
2018-10-31 15:38 ` Eric W. Biederman [this message]
2018-10-31 16:18 ` Eric W. Biederman
2018-10-31 16:36 ` Al Viro
2018-11-01 16:51 ` Al Viro
2018-10-31 18:39 ` David Howells
2018-10-31 18:45 ` [PATCH] vfs: Fix incorrect user_ns assignment in proc and mqueue David Howells
2018-10-31 20:49 ` [git pull] mount API series Miklos Szeredi
2018-11-10 14:19 ` Steven Whitehouse
2018-11-12 2:07 ` Eric W. Biederman
2018-11-12 20:54 ` Al Viro
2018-12-17 23:10 ` Al Viro
2018-12-21 16:25 ` Eric W. Biederman
2018-10-31 16:18 ` Linus Torvalds
2018-11-01 10:53 ` Steven Whitehouse
2018-11-01 15:57 ` Linus Torvalds
2018-11-01 17:18 ` David Howells
2018-11-01 18:33 ` Linus Torvalds
2018-11-01 22:05 ` Al Viro
2018-11-01 22:07 ` Linus Torvalds
2018-11-01 23:59 ` David Howells
2018-11-02 4:07 ` Al Viro
2018-11-02 19:42 ` Al Viro
2018-11-03 6:14 ` Gao Xiang
2018-11-03 6:30 ` Gao Xiang
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=87a7mut9cm.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox