On 9/26/18 2:00 AM, Helen Koike wrote:
> This series is reviving an old patchwork.
> Booting from a mapped device requires an initramfs. This series is
> allows for device-mapper targets to be configured at boot time for
> use early in the boot process (as the root device or otherwise).
>
> Exa
This series is reviving an old patchwork.
Booting from a mapped device requires an initramfs. This series is
allows for device-mapper targets to be configured at boot time for
use early in the boot process (as the root device or otherwise).
Example, the following could be added in the boot paramet
From: Enric Balletbo i Serra
Add a dm_ioctl_cmd to issue the equivalent of a DM ioctl call in kernel.
Signed-off-by: Enric Balletbo i Serra
---
drivers/md/dm-ioctl.c | 50 +++
include/linux/device-mapper.h | 6 +
2 files changed, 56 insertions(+)
d
From: Will Drewry
Add a dm= kernel parameter modeled after the md= parameter from
do_mounts_md. It allows for device-mapper targets to be configured at
boot time for use early in the boot process (as the root device or
otherwise).
Signed-off-by: Will Drewry
Signed-off-by: Kees Cook
[rework to
On Tue, Aug 7, 2018 at 11:18 PM Kees Cook wrote:
>
> In the quest to remove all stack VLA usage from the kernel[1], this uses
> the new upper bound for the stack buffer. Also adds a sanity check.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.co
On Tue, Sep 25, 2018 at 5:07 AM Dan Carpenter wrote:
> The patch a739ff3f543a: "dm verity: add support for forward error
> correction" from Dec 3, 2015, leads to the following static checker
> warning:
Has something changed since the last time you reported this warning?
https://www.redhat.com/ar
Hi DM devs,
The patch a739ff3f543a: "dm verity: add support for forward error
correction" from Dec 3, 2015, leads to the following static checker
warning:
drivers/md/dm-verity-fec.c:147 fec_decode_bufs()
warn: 'par' can also be NULL
drivers/md/dm-verity-fec.c
124 /*
125
Hi! I met a problem of dm-thin: a thin-pool has no volumes but its
nr_free_blocks_data is not zero. I guess the scene of this problem like:
a. create a thin volume thin01, size is 10GB;
b. write 10GB to thin01;
c. create a snapshot thin01-snap, orig is thin01;
d. write 10GB to thin01-snap;
e. for
