linux-kernel - Re: dm-snapshot for system updates in Android

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] [day] [month] [year] [list]

Date:   Fri, 8 Nov 2019 07:31:44 -0500 (EST)
From:   Mikulas Patocka <mpatocka@...hat.com>
To:     Alessio Balsini <balsini@...roid.com>
cc:     Jens Axboe <axboe@...nel.dk>, Alasdair G Kergon <agk@...hat.com>,
        elsk@...gle.com, dvander@...gle.com, dm-devel@...hat.com,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-team@...roid.com
Subject: Re: dm-snapshot for system updates in Android



On Mon, 4 Nov 2019, Alessio Balsini wrote:

> > > -- Alignment
> > > 
> > > Our approach follows the solution proposed by Mikulas [1].
> > > Being the block alignment of file extents automatically managed by the
> > > filesystem, using FIEMAP should have no alignment-related performance issue.
> > > But in our implementation we hit a misalignment [2] branch which leads to
> > > dmwarning messages [3, 4].
> > > 
> > > I have a limited experience with the block layer and dm, so I'm still
> > > struggling in finding the root cause for this, either in user space or kernel
> > > space.
> > 
> > I don't know. What is the block size of the filesystem? Are all mappings 
> > aligned to this block size?
> 
> Here follows a just generated warning coming from a Pixel 4 kernel (4.14):
> 
> [ 3093.443808] device-mapper: table: 253:16: adding target device dm-15
> caused an alignment inconsistency: physical_block_size=4096,
> logical_block_size=4096, alignment_offset=61440, start=0
> 
> Does this contain all the info you asked for?

Look at the function blk_stack_limits - it has various checks that make it 
return -1. Insert some debugging printk's there and find out which check 
made the function return -1.

Based on this, we can find out which of the limits triggered the error 
message.

> I started investigating this issue, but since we didn't notice any
> performance degradation, I prioritized other things. I'll be hopefully
> able to get back to this warning in the next months.
> Please let me know if I can help you with that or if you need additional
> information.

Mikulas