[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc71118d-3003-6260-6ab3-ddcc4277aeed@redhat.com>
Date: Fri, 3 Aug 2018 21:18:35 +0200
From: Zdenek Kabelac <zkabelac@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jens Axboe <axboe@...nel.dk>, Sagi Grimberg <sagi@...mberg.me>,
Mike Snitzer <snitzer@...hat.com>,
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
Subject: Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16
Dne 3.8.2018 v 18:37 Linus Torvalds napsal(a):
> [ Dammit. I haven't had to shout and curse at people for a while, but
> this is ABSOLUTELY THE MOST IMPORTANT THING IN THE UNIVERSE WHEN IT
> COMES TO SOFTWARE DEVELOPMENT ]
>
> On Fri, Aug 3, 2018 at 6:31 AM Zdenek Kabelac <zkabelac@...hat.com> wrote:
>>
>> IMHO (as the author of fixing lvm2 patch) user should not be upgrading kernels
>> and keep running older lvm2 user-land tool (and there are very good reasons
>> for this).
>
> Yeah, HELL NO!
>
> Guess what? You're wrong. YOU ARE MISSING THE #1 KERNEL RULE.
>
> We do not regress, and we do not regress exactly because your are 100% wrong.
>
Hi Linus
Sorry to hear you so crazy about this :) - but my comment was mainly targeted
to 'distribution maintainers' trying to push the latest kernel and preserving
old tools (not providing upgraded packages). If it's worth to upgrade
kernel - it should be worth to upgrade surrounding packages, especially if
they are very tightly bind to work with kernel.
I just think you are overreacting here and you could trust me I personally do
A LOT to keep everything as much usable & compatible in lvm2 as we can across
all kernels, all distributions and many architectures.
Lvm2 is always tracking individual bugs in kernel and reports them to user or
tries to bypass...
>> Kernel had a bug which has been fixed
>
> That is *ENTIRELY* immaterial.
>
> Guys, whether something was buggy or not DOES NOT MATTER.
>
> Why?
>
> Bugs happen. That's a fact of life. Arguing that "we had to break
> something because we were fixing a bug" is completely insane. We fix
> tens of bugs every single day, thinking that "fixing a bug" means that
> we can break something is simply NOT TRUE.
From my userland POV - leaving kernel write to devices that are supposed to
be read-only 'just because' it's kernel is wrong - the fact it has NOT been
discover for so long means - there are not many users and not many testers of
this combination.
But if kernel people do want to make a big stress case about this - I'm the
last one to object - I'm just unsure what kind of bugs are supposed to be
preserved and how it's going to be recognized which bugs are usable and which
are fixable....
On a funny note - security exploits had also many users - so why fixing them....
> So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
> without upgrading some other random binary, then we have a problem.
It's was not meant as a rule, just recommendation - and I think we can end up
this fight over nothing here - there is probably very low number of users of
this combination....
Regards
Zdenek
Powered by blists - more mailing lists