[PATCH] Revert "staging: erofs: disable compiling temporarile"

[Chao Yu]

Hi Stephen,

To make sure, did -next tree enable erofs compiling now?

Xiang has made two patches to fix integration issue with other vfs changes,
and Greg and David have already picked them in their tree.

staging: erofs: rename superblock flags (MS_xyz -> SB_xyz)
staging: erofs: update .mount and .remount_sb

On 2018/9/6 7:25, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 29 Aug 2018 09:44:03 +1000 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>>
>> On Tue, 28 Aug 2018 22:13:02 +0800 Chao Yu <yuchao0 at 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 at infradead.org>
>>>>>>>> Cc: David Howells <dhowells at redhat.com>
>>>>>>>> Reviewed-by: Chao Yu <yuchao0 at huawei.com>
>>>>>>>> Signed-off-by: Gao Xiang <gaoxiang25 at 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 .....
>