Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1621121 > unrolled thread

Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link() Amir Goldstein <amir73il@gmail.com> - 2017-04-11 12:30 +0200
    Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link() Richard Weinberger <richard@nod.at> - 2017-04-11 13:00 +0200
      Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link() Amir Goldstein <amir73il@gmail.com> - 2017-04-11 17:10 +0200
        Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link() Ralph Sennhauser <ralph.sennhauser@gmail.com> - 2017-04-17 17:30 +0200
          Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link() Richard Weinberger <richard@nod.at> - 2017-04-17 18:00 +0200

#1621121 — Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link()

On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
>>> Were you able to make any progress? still working on this?
>>> If this is too complicated to get in for this cycle, better send a patch
>>> to disable O_TMPFILE support for ubifs and fix the problem properly on
>>> followup merge cycle.
>>> Because right now ubifs O_TMPFILE support is broken and breaks overlayfs mount.
>>
>> I have a test and currently testing it. As it looks the situation is less worse
>> than I thought first. :-)
>
> s/test/patch :)
>

Richard,

Maybe it's not my business to interfere with ubifs development and I
haven't seen your patch.

But on the face of it, it doesn't sound like fixing O_TMPFILE is a
trivial fix, so not sure
it is wise to send a patch for -rc7?...

How about sending the patch to disable O_TMPFILE for -rc7 and queuing
your fix for v4.12?
Without any patch, v4.11 is going to have a regression with overlayfs+ubifs.

Amir.

[toc] | [next] | [standalone]

#1621149

Hi!

Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger <richard@nod.at> wrote:
>> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
>>>> Were you able to make any progress? still working on this?
>>>> If this is too complicated to get in for this cycle, better send a patch
>>>> to disable O_TMPFILE support for ubifs and fix the problem properly on
>>>> followup merge cycle.
>>>> Because right now ubifs O_TMPFILE support is broken and breaks overlayfs mount.
>>>
>>> I have a test and currently testing it. As it looks the situation is less worse
>>> than I thought first. :-)
>>
>> s/test/patch :)
>>
> 
> Richard,
> 
> Maybe it's not my business to interfere with ubifs development and I
> haven't seen your patch.
> 
> But on the face of it, it doesn't sound like fixing O_TMPFILE is a
> trivial fix, so not sure
> it is wise to send a patch for -rc7?...
> 
> How about sending the patch to disable O_TMPFILE for -rc7 and queuing
> your fix for v4.12?
> Without any patch, v4.11 is going to have a regression with overlayfs+ubifs.

No need to panic.
I verified some stuff and my first patch does the right thing but not in a nice way,
except in oneerror patch. In will land in -rc7.

For the next merge window I prepare patches that introduce a new journal function
for handling tmpfiles.

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1621398

On Tue, Apr 11, 2017 at 1:50 PM, Richard Weinberger <richard@nod.at> wrote:
> Hi!
>
> Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
>> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger <richard@nod.at> wrote:
>>> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
>>>>> Were you able to make any progress? still working on this?
>>>>> If this is too complicated to get in for this cycle, better send a patch
>>>>> to disable O_TMPFILE support for ubifs and fix the problem properly on
>>>>> followup merge cycle.
>>>>> Because right now ubifs O_TMPFILE support is broken and breaks overlayfs mount.
>>>>
>>>> I have a test and currently testing it. As it looks the situation is less worse
>>>> than I thought first. :-)
>>>
>>> s/test/patch :)
>>>
>>
>> Richard,
>>
>> Maybe it's not my business to interfere with ubifs development and I
>> haven't seen your patch.
>>
>> But on the face of it, it doesn't sound like fixing O_TMPFILE is a
>> trivial fix, so not sure
>> it is wise to send a patch for -rc7?...
>>
>> How about sending the patch to disable O_TMPFILE for -rc7 and queuing
>> your fix for v4.12?
>> Without any patch, v4.11 is going to have a regression with overlayfs+ubifs.
>
> No need to panic.

Who? me?  ;-)

> I verified some stuff and my first patch does the right thing but not in a nice way,
> except in oneerror patch. In will land in -rc7.
>

That patch looks simple enough.
I though you had a more complex patch in mind.

> For the next merge window I prepare patches that introduce a new journal function
> for handling tmpfiles.
>

Thanks for the update.
Cheers,
Amir.

[toc] | [prev] | [next] | [standalone]

#1624712

On Tue, 11 Apr 2017 18:04:50 +0300
Amir Goldstein <amir73il@gmail.com> wrote:

> On Tue, Apr 11, 2017 at 1:50 PM, Richard Weinberger <richard@nod.at>
> wrote:
> > Hi!
> >
> > Am 11.04.2017 um 12:20 schrieb Amir Goldstein:  
> >> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger
> >> <richard@nod.at> wrote:  
> >>> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:  
> >>>>> Were you able to make any progress? still working on this?
> >>>>> If this is too complicated to get in for this cycle, better
> >>>>> send a patch to disable O_TMPFILE support for ubifs and fix the
> >>>>> problem properly on followup merge cycle.
> >>>>> Because right now ubifs O_TMPFILE support is broken and breaks
> >>>>> overlayfs mount.  
> >>>>
> >>>> I have a test and currently testing it. As it looks the
> >>>> situation is less worse than I thought first. :-)  
> >>>
> >>> s/test/patch :)
> >>>  
> >>
> >> Richard,
> >>
> >> Maybe it's not my business to interfere with ubifs development and
> >> I haven't seen your patch.
> >>
> >> But on the face of it, it doesn't sound like fixing O_TMPFILE is a
> >> trivial fix, so not sure
> >> it is wise to send a patch for -rc7?...
> >>
> >> How about sending the patch to disable O_TMPFILE for -rc7 and
> >> queuing your fix for v4.12?
> >> Without any patch, v4.11 is going to have a regression with
> >> overlayfs+ubifs.  
> >
> > No need to panic.  
> 
> Who? me?  ;-)
> 
> > I verified some stuff and my first patch does the right thing but
> > not in a nice way, except in oneerror patch. In will land in -rc7.
> >  

Hi Amir, Richard

Looks like the fix didn't make it into 4.11-rc7 either, isn't it time
to just disable O_TMPFILE support in ubifs for now? Giving plenty
time for the proper fix.

Thanks
Ralph

> 
> That patch looks simple enough.
> I though you had a more complex patch in mind.
> 
> > For the next merge window I prepare patches that introduce a new
> > journal function for handling tmpfiles.
> >  
> 
> Thanks for the update.
> Cheers,
> Amir.

[toc] | [prev] | [next] | [standalone]

#1624725

Am 17.04.2017 um 17:27 schrieb Ralph Sennhauser:
> Hi Amir, Richard
> 
> Looks like the fix didn't make it into 4.11-rc7 either, isn't it time
> to just disable O_TMPFILE support in ubifs for now? Giving plenty
> time for the proper fix.

As I said to Amir, don't panic. I'm *very* busy right now with non-computer stuff.
My first fix is correct, I was wrong about the testing, it does the right thing,
although it was not so clear.
Except that my fix misses one error case which I wanted to push tomorrow since today
is a official holiday here in Austria.
For the next merge window I have a better approach which is better than (ab)using
ubifs_jnl_update() for O_TMPFILE.

Thanks,
//richard

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web