linux-kernel - Re: [PATCH v6 00/99] XArray version 6

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:   Thu, 18 Jan 2018 08:48:43 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     dsterba@...e.cz, linux-kernel@...r.kernel.org,
        Matthew Wilcox <mawilcox@...rosoft.com>, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-nilfs@...r.kernel.org, linux-btrfs@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-usb@...r.kernel.org,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Stefano Stabellini <sstabellini@...nel.org>,
        iommu@...ts.linux-foundation.org, linux-remoteproc@...r.kernel.org,
        linux-s390@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
        cgroups@...r.kernel.org, linux-sh@...r.kernel.org,
        David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v6 00/99] XArray version 6

On Thu, Jan 18, 2018 at 05:07:50PM +0100, David Sterba wrote:
> On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox <mawilcox@...rosoft.com>
> > 
> > This version of the XArray has no known bugs.
> 
> I've booted this patchset on 2 boxes, both had random problems during
> boot. On one I was not able to diagnose what went wrong. On the other
> one the system booted up to userspace and failed to set up networking.
> Serial console worked and the network service complained about wrong
> format of /usr/share/wicked/schema/team.xml . That's supposed to be a
> text file, though hexdump showed me lots of zeros. Trimmed output:
> 
> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> (similar output here)
> *
> 00000a10  00 00 00 00 00 00 00 00  11 03 00 00 00 00 00 00  |................|
> 00000a20  20 8b 7f 01 00 00 00 00  a0 84 7d 01 00 00 00 00  | .........}.....|
> 00000a30  00 00 00 00 00 00 00 00  10 89 7f 01 00 00 00 00  |................|
> 00000a40  a0 84 7d 01 00 00 00 00  00 00 00 00 00 00 00 00  |..}.............|
> 00000a50  80 8a 7f 01 00 00 00 00  e0 cf 7d 01 00 00 00 00  |..........}.....|
> 00000a60  00 00 00 00 00 00 00 00  60 8a 7f 01 00 00 00 00  |........`.......|
> 00000a70  a0 84 7d 01 00 00 00 00  00 00 00 00 00 00 00 00  |..}.............|
> 00000a80  30 89 7f 01 00 00 00 00  a0 84 7d 01 00 00 00 00  |0.........}.....|
> 00000a90  00 00 00 00 00 00 00 00  60 f2 7f 01 00 00 00 00  |........`.......|
> 00000aa0  40 fd 7e 01 00 00 00 00  00 00 00 00 00 00 00 00  |@...............|
> 00000ab0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00001000  3e 0a 20 20 3c 2f 6d 65  74 68 6f 64 3e 0a 3c 2f  |>.  </method>.</|
> 00001010  73 65 72 76 69 63 65 3e  0a                       |service>.|
> 
> There's something at the end of the file that does look like a xml fragment.
> The file size is 4121. This looks to me like exactly the first page of the file
> was not read correctly.
> 
> The xml file is supposed to be read-only during startup, so there was no write
> in flight. 'rpm -Vv' reported only this file corrupted. Booting to other
> kernels was fine, network up, and the file was ok again. So the
> corruption happened only in memory, which leads me to conclusion that
> there is an unknown bug in your patchset.

Thank you!  I shall attempt to debug.  Was this with a btrfs root
filesystem?  I'm most suspicious of those patches right now, since they've
received next to no testing.  I'm going to put together a smaller patchset
which just does the page cache conversion and nothing else in the hope
that we can get that merged this year.