lkml.org 
[lkml]   [2018]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Revert "staging: erofs: disable compiling temporarile"
Hi all,

On Wed, 29 Aug 2018 09:44:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 28 Aug 2018 22:13:02 +0800 Chao Yu <yuchao0@huawei.com> wrote:
> >
> > On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 28, 2018 at 04:56:43PM +0800, Chao Yu wrote:
> > >>
> > >> On 2018/8/28 14:28, Gao Xiang wrote:
> > >>>
> > >>> On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
> > >>>> On Tue, Aug 28, 2018 at 11:39:48AM +0800, Gao Xiang wrote:
> > >>>>> This reverts commit 156c3df8d4db4e693c062978186f44079413d74d.
> > >>>>>
> > >>>>> Since XArray and the new mount apis aren't merged in 4.19-rc1
> > >>>>> merge window, the BROKEN mark can be reverted directly without
> > >>>>> any problems.
> > >>>>>
> > >>>>> Fixes: 156c3df8d4db ("staging: erofs: disable compiling temporarile")
> > >>>>> Cc: Matthew Wilcox <willy@infradead.org>
> > >>>>> Cc: David Howells <dhowells@redhat.com>
> > >>>>> Reviewed-by: Chao Yu <yuchao0@huawei.com>
> > >>>>> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
> > >>>>> ---
> > >>>>>
> > >>>>> Hi Greg,
> > >>>>>
> > >>>>> Could you please apply this patch to enable EROFS from 4.19-rc2, thanks...
> > >>>>>
> > >>>>> p.s. We would like to provide a more stable EROFS when linux-4.19 is out,
> > >>>>> and there are also two patchsets (the one is already sent out by Chao
> > >>>>> and me, the other is previewing in linux-erofs mailing list and it will
> > >>>>> be sent out after gathering enough testdata and feedback from community
> > >>>>> and carefully reviewed), could you also please consider applying these
> > >>>>> two patchsets in the later 4.19-rc (both >2, or the first patchset
> > >>>>> could be in rc2 in advance) if it is convenient to do so, or the next
> > >>>>> 4.20 is also ok...
> > >>>>>
> > >>>>> LINK: https://lore.kernel.org/lkml/20180821144937.20555-1-chao@kernel.org/
> > >>>>> https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25@huawei.com/
> > >>>>
> > >>>> I applied those patch sets to my -next branch already, right? So those
> > >>>
> > >>> Yes, Thank you for applying those patches. :)
> > >>>
> > >>>> would be going into 4.20-rc1, it is time now for "bugfixes only" for
> > >>>> 4.19-final.
> > >>>>
> > >>>> So perhaps we should just leave it as "BROKEN" for now for 4.19 and add
> > >>>> this to my tree now and let people work on it for the next few months in
> > >>
> > >> I'm worry about that once we plan to reenable erofs in next x.xx-rc1, in the
> > >> merge window, if there are any other features change common api or structure in
> > >> vfs/mm/block, but related patch didn't cover erofs, that would make conflict
> > >> with erofs.
> > >>
> > >> So if that happens, we can just reminder them to cover erofs? or we should
> > >> handle this by just delay removing 'BROKEN' state?
> > >>
> > >> Thanks,
> > >>
> > >>>> linux-next so that 4.20 has a solid base to start with?
> > >>>>
> > >>>
> > >>> EROFS is be marked as "BROKEN" just because of conflict with
> > >>> XArray and the new mount apis, as Stephen Rothwell suggested in
> > >>>
> > >>> https://lore.kernel.org/lkml/20180802010705.24a72730@canb.auug.org.au/
> > >>>
> > >>>> It might be easiest for Greg to add the disabling CONFIG_EROFS_FS patch
> > >>>> to the staging tree itself for his first pull request during the merge
> > >>>> window and then send a second pull request (after the vfs and maybe the
> > >>>> Xarray stuff has been merged by Linus) with these patches followed by a
> > >>>> revert of the disabling patch.
> > >>>
> > >>> But these two features was still discussing in the mailing list even at the
> > >>> last time of 4.19-rc1 merge window. I cannot decide whether they were eventually
> > >>> get merged in 4.19 or not. But it seems that it is regretful that linux-4.19
> > >>> is out without XArray and the new mount apis.
> > >>>
> > >>> Therefore, I think EROFS should work for linux-4.19 without any modification
> > >>> if just revert the BROKEN mark.
> > >
> > > Ok, you are right, I'll go apply this.
> > >
> > >>> EROFS works fine with the 4.19-rc1 code except that it has some __GFP_NOFAIL
> > >>> and BUG_ONs on error handling paths and very rarely race between memory
> > >>> reclaiming and decompression... :( I personally think it is complete enough
> > >>> for people to test since it is an independent and staging filesystem driver (no
> > >>> other influence...) Anyway, removing EROFS BROKEN mark at 4.20 is also ok of course...
> > >>>
> > >>> On the other head, if XArray and the new mount apis is still pending for 4.20,
> > >>> should EROFS uses the same policy as Stephen suggested? I have no idea how to do next...
> > >
> > > As the code is now part of the common tree that everyone works off of,
> > > any filesystem changes that happen will normally cover erofs as well.
> > > So this shouldn't be an issue anymore.
> >
> > Thanks very much for the help and explanation, we will keep an eye on those vfs
> > changes. :)
>
> Unfortunately, those vfs changes are still in the vfs tree in
> linux-next and cause a build failure in the erofs code. I have
> disabled the build of erofs again for today.
>
> Dave, Al, it would be good if you could add a patch/revise the series
> that adds the necessary erofs changes.

I still have to disable erofs .....

--
Cheers,
Stephen Rothwell
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-09-06 01:26    [W:0.093 / U:1.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site