[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a7mut9cm.fsf@xmission.com>
Date: Wed, 31 Oct 2018 10:38:17 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [git pull] mount API series
Al Viro <viro@...IV.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
Powered by blists - more mailing lists