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

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

[Gao Xiang]

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 at kernel.org/
       https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at huawei.com/

Thanks,
Gao Xiang

 drivers/staging/erofs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/erofs/Kconfig b/drivers/staging/erofs/Kconfig
index 96f6149..663b755 100644
--- a/drivers/staging/erofs/Kconfig
+++ b/drivers/staging/erofs/Kconfig
@@ -2,7 +2,7 @@
 
 config EROFS_FS
 	tristate "EROFS filesystem support"
-	depends on BROKEN
+	depends on BLOCK
 	help
 	  EROFS(Enhanced Read-Only File System) is a lightweight
 	  read-only file system with modern designs (eg. page-sized
-- 
1.9.1

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

[Gao Xiang]

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/

Thanks,
Gao Xiang

 drivers/staging/erofs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/erofs/Kconfig b/drivers/staging/erofs/Kconfig
index 96f6149..663b755 100644
--- a/drivers/staging/erofs/Kconfig
+++ b/drivers/staging/erofs/Kconfig
@@ -2,7 +2,7 @@
 
 config EROFS_FS
 	tristate "EROFS filesystem support"
-	depends on BROKEN
+	depends on BLOCK
 	help
 	  EROFS(Enhanced Read-Only File System) is a lightweight
 	  read-only file system with modern designs (eg. page-sized
-- 
1.9.1

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

[Greg Kroah-Hartman]

On Tue, Aug 28, 2018@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 at kernel.org/
>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at huawei.com/

I applied those patch sets to my -next branch already, right?  So those
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
linux-next so that 4.20 has a solid base to start with?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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
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
linux-next so that 4.20 has a solid base to start with?

thanks,

greg k-h

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

[Gao Xiang]

Hi Greg,

On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
> On Tue, Aug 28, 2018@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 at kernel.org/
>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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
> 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 at 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.

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...


I would like to hear your and Chao's suggestions....Thanks in advance...

Thanks,
Gao Xiang

> thanks,
> 
> greg k-h
> 

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

[Gao Xiang]

Hi Greg,

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
> 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.

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...


I would like to hear your and Chao's suggestions....Thanks in advance...

Thanks,
Gao Xiang

> thanks,
> 
> greg k-h
> 

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

[Chao Yu]

Hi Greg,

On 2018/8/28 14:28, Gao Xiang wrote:
> Hi Greg,
> 
> On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
>> On Tue, Aug 28, 2018@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 at kernel.org/
>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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.
> 
> 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...
> 
> 
> I would like to hear your and Chao's suggestions....Thanks in advance...
> 
> Thanks,
> Gao Xiang
> 
>> thanks,
>>
>> greg k-h
>>
> 
> .
> 

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

[Chao Yu]

Hi Greg,

On 2018/8/28 14:28, Gao Xiang wrote:
> Hi Greg,
> 
> 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.
> 
> 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...
> 
> 
> I would like to hear your and Chao's suggestions....Thanks in advance...
> 
> Thanks,
> Gao Xiang
> 
>> thanks,
>>
>> greg k-h
>>
> 
> .
> 

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

[Greg Kroah-Hartman]

On Tue, Aug 28, 2018@04:56:43PM +0800, Chao Yu wrote:
> Hi Greg,
> 
> On 2018/8/28 14:28, Gao Xiang wrote:
> > Hi Greg,
> > 
> > On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
> >> On Tue, Aug 28, 2018@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 at kernel.org/
> >>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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,

greg k-h

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

[Greg Kroah-Hartman]

On Tue, Aug 28, 2018 at 04:56:43PM +0800, Chao Yu wrote:
> Hi Greg,
> 
> On 2018/8/28 14:28, Gao Xiang wrote:
> > Hi Greg,
> > 
> > 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,

greg k-h

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

[Gao Xiang]

Hi Greg,

On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
> On Tue, Aug 28, 2018@04:56:43PM +0800, Chao Yu wrote:
>> Hi Greg,
>>
>> On 2018/8/28 14:28, Gao Xiang wrote:
>>> Hi Greg,
>>>
>>> On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
>>>> On Tue, Aug 28, 2018@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 at kernel.org/
>>>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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.

I am so happy to see that, thanks for understanding :)

> 
>>> 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.
> 
That is so helpful for us... :)

Thanks,
Gao Xiang

> thanks,
> 
> greg k-h
> 

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

[Gao Xiang]

Hi Greg,

On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
> On Tue, Aug 28, 2018 at 04:56:43PM +0800, Chao Yu wrote:
>> Hi Greg,
>>
>> On 2018/8/28 14:28, Gao Xiang wrote:
>>> Hi Greg,
>>>
>>> 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.

I am so happy to see that, thanks for understanding :)

> 
>>> 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.
> 
That is so helpful for us... :)

Thanks,
Gao Xiang

> thanks,
> 
> greg k-h
> 

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

[Chao Yu]

On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
> On Tue, Aug 28, 2018@04:56:43PM +0800, Chao Yu wrote:
>> Hi Greg,
>>
>> On 2018/8/28 14:28, Gao Xiang wrote:
>>> Hi Greg,
>>>
>>> On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
>>>> On Tue, Aug 28, 2018@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 at kernel.org/
>>>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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. :)

Thanks,

> 
> thanks,
> 
> greg k-h
> 
> .
> 

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

[Chao Yu]

On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
> On Tue, Aug 28, 2018 at 04:56:43PM +0800, Chao Yu wrote:
>> Hi Greg,
>>
>> On 2018/8/28 14:28, Gao Xiang wrote:
>>> Hi Greg,
>>>
>>> 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. :)

Thanks,

> 
> thanks,
> 
> greg k-h
> 
> .
> 

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

[Stephen Rothwell]

Hi all,

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:  
> >> Hi Greg,
> >>
> >> On 2018/8/28 14:28, Gao Xiang wrote:  
> >>> Hi Greg,
> >>>
> >>> 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 at kernel.org/
> >>>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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.

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20180829/10930a47/attachment.sig>

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5225 bytes --]

Hi all,

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:  
> >> Hi Greg,
> >>
> >> On 2018/8/28 14:28, Gao Xiang wrote:  
> >>> Hi Greg,
> >>>
> >>> 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Gao Xiang]

On 2018/8/29 7:44, Stephen Rothwell wrote:
> 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.

feel a bit loss after hear that... :'(

> 
> Dave, Al, it would be good if you could add a patch/revise the series
> that adds the necessary erofs changes.

Hi Dave, Al, could you please kindly fix EROFS in vfs tree if it is
convenient...

Here is my patches which were intended for 4.19 (they could be rewritten
if needed...)
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000284.html

Thanks in advance...

Thanks,
Gao Xiang

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

[Gao Xiang]

On 2018/8/29 7:44, Stephen Rothwell wrote:
> 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.

feel a bit loss after hear that... :'(

> 
> Dave, Al, it would be good if you could add a patch/revise the series
> that adds the necessary erofs changes.

Hi Dave, Al, could you please kindly fix EROFS in vfs tree if it is
convenient...

Here is my patches which were intended for 4.19 (they could be rewritten
if needed...)
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000284.html

Thanks in advance...

Thanks,
Gao Xiang

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

[Stephen Rothwell]

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 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 at kernel.org/
> > >>>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20180906/92ea290b/attachment.sig>

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5563 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Gao Xiang]

Hi David, Al,

On 2018/9/6 7:25, Stephen Rothwell wrote:
> 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 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 at kernel.org/
>>>>>>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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 .....
> 

Is there some plan to fix erofs in the new mount-api patchset?
Or should I send erofs patches based on the dhowells/mount-api branch? and could you please help review and merge them?

Thanks in advance.

Thanks,
Gao Xiang

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

[Gao Xiang]

Hi David, Al,

On 2018/9/6 7:25, Stephen Rothwell wrote:
> 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 .....
> 

Is there some plan to fix erofs in the new mount-api patchset?
Or should I send erofs patches based on the dhowells/mount-api branch? and could you please help review and merge them?

Thanks in advance.

Thanks,
Gao Xiang

[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@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 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 at kernel.org/
>>>>>>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25 at 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 at 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 .....
> 

Re: [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@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 .....
> 

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

[Stephen Rothwell]

Hi Chao,

On Wed, 12 Sep 2018 15:19:16 +0800 Chao Yu <yuchao0@huawei.com> wrote:
>
> To make sure, did -next tree enable erofs compiling now?

Yes, from yesterday.

> 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

I noticed, thanks.

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20180912/18acb99c/attachment.sig>

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Hi Chao,

On Wed, 12 Sep 2018 15:19:16 +0800 Chao Yu <yuchao0@huawei.com> wrote:
>
> To make sure, did -next tree enable erofs compiling now?

Yes, from yesterday.

> 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

I noticed, thanks.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Chao Yu]

Hi Stephen,

On 2018/9/12 15:34, Stephen Rothwell wrote:
> Hi Chao,
> 
> On Wed, 12 Sep 2018 15:19:16 +0800 Chao Yu <yuchao0@huawei.com> wrote:
>>
>> To make sure, did -next tree enable erofs compiling now?
> 
> Yes, from yesterday.

Great, thanks for your help. :)

> 
>> 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
> 
> I noticed, thanks.
> 

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

[Chao Yu]

Hi Stephen,

On 2018/9/12 15:34, Stephen Rothwell wrote:
> Hi Chao,
> 
> On Wed, 12 Sep 2018 15:19:16 +0800 Chao Yu <yuchao0@huawei.com> wrote:
>>
>> To make sure, did -next tree enable erofs compiling now?
> 
> Yes, from yesterday.

Great, thanks for your help. :)

> 
>> 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
> 
> I noticed, thanks.
>