linux-kernel - Re: LVM snapshot broke between 4.14 and 4.16

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: <20180803190617.GA4498@redhat.com>
Date:   Fri, 3 Aug 2018 15:06:17 -0400
From:   Mike Snitzer <snitzer@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Theodore Ts'o <tytso@....edu>, Jens Axboe <axboe@...nel.dk>,
        Sagi Grimberg <sagi@...mberg.me>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>, dm-devel@...hat.com,
        Ilya Dryomov <idryomov@...il.com>, wgh@...lan.ru,
        Zdenek Kabelac <zkabelac@...hat.com>
Subject: Re: LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 03 2018 at  2:57pm -0400,
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, Aug 3, 2018 at 11:39 AM Mike Snitzer <snitzer@...hat.com> wrote:
> >
> > Please stop with the overreaction and making this something it isn't.
> 
> It's not an overreaction when people get their scripts broken, and
> some developers then argue "that's not a serious bug".
> 
> Guys, this needs to be fixed.  With all the stupid and fundamentyally
> incorrect excuses, I am now no longer even willing to maintain any
> other course of action.
> 
> If you develop for the Linux kernel, you need to realize that
> "breaking user space" is simply not acceptable. And if you cannot live
> with that, then you should stop working on the kernel. Because I will
> refuse to continue to pull from you as a developer.

WTF!?

> At worst, I'll just revert the original commit entirely. I was hoping
> we'd be able to avoid that, partly because the commit looks fine, but
> partly because it also doesn't revert cleanly.
> 
> Or I'll just do something like this, since it seems like it's the lvm
> people who have the hardest time with understanding the simple rules:

I'll be your whipping boy all you like.

But you're making Zdenek's response into mine and threathening to no
longer pull from me.

Over what?

A block regression that an lvm2 developer papered over.

> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
> index b810ea77e6b1..fcfab812e025 100644
> --- a/drivers/md/dm-ioctl.c
> +++ b/drivers/md/dm-ioctl.c
> @@ -1049,7 +1049,12 @@ static int do_resume(struct dm_ioctl *param)
>                         return PTR_ERR(old_map);
>                 }
> 
> -               if (dm_table_get_mode(new_map) & FMODE_WRITE)
> +               /*
> +                * This used to do
> +                *    dm_table_get_mode(new_map) & FMODE_WRITE
> +                * but the lvm tools got this wrong, and will
> +                * continue to write to "read-only" volumes.
> +               if (0)
>                         set_disk_ro(dm_disk(md), 0);
>                 else
>                         set_disk_ro(dm_disk(md), 1);
> 
> which seems to target the actual problem more directly.

How does that pass for a fix to this issue?

That'll unilaterally mark all dm device's readonly.