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]
Date:   Wed, 11 Mar 2020 18:51:23 +0800
From:   Chao Yu <yuchao0@...wei.com>
To:     Ondřej Jirman <megi@....cz>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-f2fs-devel@...ts.sourceforge.net>
Subject: Re: [f2fs-dev] Writes stoped working on f2fs after the compression
 support was added

Hi,

On 2020/3/11 18:33, Ondřej Jirman wrote:
> Hello,
> 
> On Wed, Mar 11, 2020 at 05:02:10PM +0800, Chao Yu wrote:
>> Hi,
>>
>> Sorry for the delay.
>>
>> On 2020/3/6 20:02, Ondřej Jirman wrote:
>>> Hello,
>>>
>>> On Thu, Feb 27, 2020 at 10:01:50AM +0800, Chao Yu wrote:
>>>> On 2020/2/27 2:05, Ondřej Jirman wrote:
>>>>>
>>>>> No issue after 7h uptime either. So I guess this patch solved it for some
>>>>> reason.
>>>>
>>>> I hope so as well, I will send a formal patch for this.
>>>
>>> So I had it happen again, even with the patches. This time in f2fs_rename2:
>>
>> Oops, it looks previous fix patch just cover the root cause... :(
>>
>> Did this issue still happen frequently? If it is, would you please apply patch
>> that prints log during down/up semaphore.
> 
> Not frequently. Just once. I couldn't afford FS corruption during update,

Alright.

> so I reverted the compression support shortly after.

What I can see is that filesystem was just stuck, rather than image became
corrupted, I guess the condition is not such bad, anyway, it's okay to just
revert compression support for now to keep fs stable.

> 
> But I wasn't stressing the system much with FS activity after applying the
> initial fix.
> 
>> And once we revert compression support patch, this issue will disappear, right?
> 
> Yes, AFAIK. I reverted it and run a few cycles of install 500MiB worth of
> packages, uninstall the packages with pacman. And it didn't re-occur. I never
> saw any issues with compression support patch reverted.

Okay, compression support may increase stack usage during page writeback, it
shouldn't overflow the stack, otherwise it could cause panic in somewhere else,
but still can find any clue why this is related to compression support patch...

> 
>> Btw, did you try other hardware which is not Arm v7?
> 
> Yes, but I didn't ever see it on anything else. Just on two 8 core cortexes A7.
> (2 clusters)

Not sure, maybe this issue is related to arm v7 architecture.

Thanks,

> 
> regards,
> 	o.
> .
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ