linux-kernel - Re: [PATCH 0/3] fix-up free space earlier in mount

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: <BANLkTinu7dX5Tfhs0ak0BEfc212mpJKb+w@mail.gmail.com>
Date:	Tue, 31 May 2011 10:43:55 -0400
From:	"Matthew L. Creech" <mlcreech@...il.com>
To:	Ben Gardiner <bengardiner@...ometrics.ca>
Cc:	Artem Bityutskiy <dedekind1@...il.com>,
	Adrian Hunter <adrian.hunter@...ia.com>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] fix-up free space earlier in mount_ubifs()

On Mon, May 30, 2011 at 2:56 PM, Ben Gardiner
<bengardiner@...ometrics.ca> wrote:
> In testing Mattew Creech's free-space-fixup flag series I found that was unable
> to boot a da850evm which had flashed to it's NAND a ubinized image containing a
> UBIFS that has the free-space-fixup flag set.
>
> The cause of the problem was found to be the call to ubifs_write_master() from
> mount_ubifs() as is evidenced the backtrace produced by the assertion
> introduced in the first patch of this series; where the assertion introduced is
> that c->space_fixup is false when ubifs_write_node() is called.
>

Interesting - so the problem is that if ubifs_read_master() resizes
the master node, a subsequent attempt to read the first (c->mst_offs +
c->mst_node_alsz) bytes from the master LEB fails?

I wonder why this is the case when free-space fixup is enabled, and
not otherwise?  The -EBADMSG seems to imply that this is the original
problem that the fix-up is intended to solve - i.e. the master node
has empty pages with non-empty OOB values, and writing to them results
in a bogus ECC.

Do you happen to know if the same thing occurs when you uncleanly
reboot (so that recovery is needed on the next boot)?  It looks like
ubifs_recover_master_node() reads the same data that
fixup_leb_free_space() does, so I'd expect it to fail similarly if
that's what's happening, regardless of whether fix-up is performed or
not.

Just trying to fully understand the error.  :)  That aside, this patch
set makes sense to me.  Thanks!

-- 
Matthew L. Creech
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/