Al Viro writes:
> On Mon, Nov 12, 2018 at 08:54:39PM +, Al Viro wrote:
>> On Sun, Nov 11, 2018 at 08:07:20PM -0600, Eric W. Biederman wrote:
>> > Steven Whitehouse writes:
>>
>> > > Can you share some details of what this NULL dereference is? David and
>> > > Al have been working on the cha
On Mon, Nov 12, 2018 at 08:54:39PM +, Al Viro wrote:
> On Sun, Nov 11, 2018 at 08:07:20PM -0600, Eric W. Biederman wrote:
> > Steven Whitehouse writes:
>
> > > Can you share some details of what this NULL dereference is? David and
> > > Al have been working on the changes as requested by Linu
On Sun, Nov 11, 2018 at 08:07:20PM -0600, Eric W. Biederman wrote:
> Steven Whitehouse writes:
> > Can you share some details of what this NULL dereference is? David and
> > Al have been working on the changes as requested by Linus later in
> > this thread, and they'd like to tidy up this issue t
Steven Whitehouse writes:
> Hi,
>
>
> On 31/10/18 15:38, Eric W. Biederman wrote:
>> Al Viro 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 materialize
Hi,
On 31/10/18 15:38, Eric W. Biederman wrote:
Al Viro 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.
M
Hi Al,
On 2018/11/2 12:07, Al Viro wrote:
> On Thu, Nov 01, 2018 at 11:59:23PM +, David Howells wrote:
>
>> (*) mount-api-core. These are the internal-only patches that add the
>> fs_context, the legacy wrapper and the security hooks and make certain
>> filesystems make use of it.
Hi Al,
On 2018/11/3 3:42, Al Viro wrote:
> On Fri, Nov 02, 2018 at 04:07:01AM +, Al Viro wrote:
>> On Thu, Nov 01, 2018 at 11:59:23PM +, David Howells wrote:
>>
>>> (*) mount-api-core. These are the internal-only patches that add the
>>> fs_context, the legacy wrapper and the securi
On Fri, Nov 02, 2018 at 04:07:01AM +, Al Viro wrote:
> On Thu, Nov 01, 2018 at 11:59:23PM +, David Howells wrote:
>
> > (*) mount-api-core. These are the internal-only patches that add the
> > fs_context, the legacy wrapper and the security hooks and make certain
> > filesystem
On Thu, Nov 01, 2018 at 11:59:23PM +, David Howells wrote:
> (*) mount-api-core. These are the internal-only patches that add the
> fs_context, the legacy wrapper and the security hooks and make certain
> filesystems make use of it.
FWIW, while rereading that series I'd spotted so
Linus Torvalds wrote:
> So if the patch series can be split up into a prep-phase that doesn't
> change any user-visible semantics (including the security side), but
> that uses the fs_context internally and allows the filesystems to be
> converted to the new world order, than that would make merg
On Thu, Nov 1, 2018 at 3:05 PM Al Viro wrote:
>
> Do you mind if we end up with work.mount rebased?
> The usual objections re testing in -next do not apply in this case,
> AFAICS...
I was assuming that the work.mount branch would be entirely re-done, yes.
Linus
On Thu, Nov 01, 2018 at 11:33:31AM -0700, Linus Torvalds wrote:
> Al - can I ask you to look at helping David with something like that?
> You tend to be very good at generating those patch-series with
> "obviously no changes" for the individual patches, but the end result
> ends up being totally d
On Thu, Nov 1, 2018 at 10:18 AM David Howells wrote:
>
> No. What we have upstream now is most definitely *not* atomic. That said,
> some of the steps of the sequence are atomic in their own right:
It's more that what we have traditionally is atomic wrt user space.
Use space does *one* indivisi
Linus Torvalds wrote:
> Exactly because it splits up what used to be an atomic sequence,
No. What we have upstream now is most definitely *not* atomic. That said,
some of the steps of the sequence are atomic in their own right:
- Creation and initialisation of the superblock
- Creation of t
On Wed, Oct 31, 2018 at 04:36:01PM +, Al Viro wrote:
> On Wed, Oct 31, 2018 at 10:38:17AM -0500, Eric W. Biederman wrote:
> > 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
On Thu, Nov 1, 2018 at 3:53 AM Steven Whitehouse wrote:
>
> When I look at the discussions I'm seeing two main issues (please
> correct me if you think I'm wrong about this) which are (a) whether the
> design is correct and (b) whether there are still bugs in the current
> patch set.
>
> Which of
Hi,
On 31/10/18 16:18, Linus Torvalds wrote:
On Tue, Oct 30, 2018 at 10:34 PM Al Viro wrote:
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
On Wed, Oct 31, 2018 at 7:39 PM, David Howells wrote:
>> My objections fundamentally is that I can find real problems when I look
>> at the code.
I think the big risk with such a change is not that there are bugs,
but that we get the API wrong, and have to keep supporting a broken
API forever.
W
> My objections fundamentally is that I can find real problems when I look
> at the code.
Eric.
You have repeatedly stated that there are "thinkos, typos and bugs" in the
code, but you have not been very forthcoming in actually disclosing *what*
those things are.
You had a go at rewriting it for
On Wed, Oct 31, 2018 at 10:38:17AM -0500, Eric W. Biederman wrote:
> 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.
What the hell? If the fixes that went
ebied...@xmission.com (Eric W. Biederman) writes:
> 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.
Bah. Now I see the missing security hook.
On Tue, Oct 30, 2018 at 10:34 PM Al Viro wrote:
>
> 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...
Having just lurked on the disc
Al Viro 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 r
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...
Conflicts: two trivial ones in
drivers/infiniband/Kconfig (removal of select ANON
24 matches
Mail list logo
