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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0c701b3c-5553-cf4c-c0b3-ad151b84662c@huawei.com>
Date:   Tue, 28 Aug 2018 14:28:02 +0800
From:   Gao Xiang <gaoxiang25@...wei.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     <devel@...verdev.osuosl.org>, LKML <linux-kernel@...r.kernel.org>,
        <linux-erofs@...ts.ozlabs.org>,
        Matthew Wilcox <willy@...radead.org>,
        "David Howells" <dhowells@...hat.com>,
        Chao Yu <yuchao0@...wei.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Miao Xie <miaoxie@...wei.com>, <weidu.du@...wei.com>
Subject: Re: [PATCH] Revert "staging: erofs: disable compiling temporarile"

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@...radead.org>
>> Cc: David Howells <dhowells@...hat.com>
>> Reviewed-by: Chao Yu <yuchao0@...wei.com>
>> Signed-off-by: Gao Xiang <gaoxiang25@...wei.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
>