linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Sagi Grimberg <sagi@grimberg.me>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-block <linux-block@vger.kernel.org>,
	dm-devel@redhat.com, Ilya Dryomov <idryomov@gmail.com>,
	wgh@torlan.ru, Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16
Date: Fri, 3 Aug 2018 11:20:34 -0400	[thread overview]
Message-ID: <20180803152034.GD32066@thunk.org> (raw)
In-Reply-To: <20180803133102.GA3092@redhat.com>

On Fri, Aug 03, 2018 at 09:31:03AM -0400, Mike Snitzer wrote:
> 
> Debian is notorious for having a stale and/or custom lvm2.
> Generally speaking, it is recommended that lvm2 not be older than the
> kernel (but the opposite is fine).

On Fri, Aug 03, 2018 at 03:31:18PM +0200, Zdenek Kabelac 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).

I'm going to have to strenuously disagree.

In *general* it's quite common for users to update their kernel
without updating their userspace.  For example, I as a *developer*, I
am often running bleeding kernels (e.g., at the moment I am running
something based on 4.18-rc6 on a Debian testing system; and it's not
at all uncommon for users to run a newer kernel on older
distribution).

This is the *first* I've heard that I should be continuously updating
lvm because I'm running bleeding edge kernels --- and I would claim
that this is entirely unreasonable.

I'll also note that very often users will update kernels while running
distribution userspace.  And if you are using Linode, very often
*Linode* will offer a newer kernel to better take advantage of the
Linode VM, and this is done without needing to install the Linode
kernel into the userspace.

It *used* to be the case that users running RHEL 2 or RHEL 3 could try
updating to the latest upstream kernel, and everything would break and
fall apart.  This was universally considered to be a failure, and a
Bad Thing.  So if LVM2 is not backwards compatible, and breaks in the
face of newer kernels running older distributions, that is a bug.

If there is a fundamental bug in the userspace API, and it can't be
fixed without a serious security bug, sometimes we need to have an
exception to the "you can't mandate newer userspace" rule.  But I
don't think this falls into this category; how would a user "exploit"
what people are calling a "security bug" to break root?

    	      	      	      	    		   	- Ted

  reply	other threads:[~2018-08-03 15:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 12:26 LVM snapshot broke between 4.14 and 4.16 WGH
2018-08-02 13:31 ` Ilya Dryomov
2018-08-02 15:10   ` WGH
2018-08-02 16:41     ` Linus Torvalds
2018-08-02 18:18       ` Ilya Dryomov
2018-08-02 18:32         ` Linus Torvalds
2018-08-02 21:32           ` WGH
2018-08-02 21:39             ` WGH
2018-08-02 21:52               ` Linus Torvalds
2018-08-03 13:31                 ` Mike Snitzer
2018-08-03 15:20                   ` Theodore Y. Ts'o [this message]
2018-08-03 18:39                     ` Mike Snitzer
2018-08-03 18:57                       ` Linus Torvalds
2018-08-03 19:06                         ` Mike Snitzer
2018-08-03 19:11                           ` Linus Torvalds
2018-08-03 19:33                             ` Mike Snitzer
2018-08-03 19:22                           ` Linus Torvalds
2018-08-04 10:01                             ` WGH
2018-08-04 17:04                               ` Linus Torvalds
2018-08-04 18:19                                 ` Mike Snitzer
2018-08-04 20:29                                 ` WGH
     [not found]                     ` <20180803195636.GA31444@agk-dp.fab.redhat.com>
     [not found]                       ` <20180803200817.GB31444@agk-dp.fab.redhat.com>
2018-08-03 20:42                         ` [dm-devel] " Linus Torvalds
2018-08-03 21:26                           ` Alasdair G Kergon
2018-08-03 13:31                 ` Zdenek Kabelac
2018-08-03 16:37                   ` Linus Torvalds
2018-08-03 18:54                     ` Mike Snitzer
2018-08-03 19:09                       ` Linus Torvalds
2018-08-03 19:30                         ` Mike Snitzer
2018-08-03 19:36                           ` Linus Torvalds
2018-08-04  5:20                           ` [dm-devel] " Theodore Y. Ts'o
2018-08-04  8:36                             ` Zdenek Kabelac
2018-08-04 16:22                               ` Theodore Y. Ts'o
2018-08-04 18:18                                 ` Mike Snitzer
2018-08-04 19:37                                   ` Theodore Y. Ts'o
2018-08-04 21:48                                     ` Mike Snitzer
2018-08-04 15:19                             ` Mike Snitzer
2018-08-03 19:18                     ` [dm-devel] " Zdenek Kabelac
2018-08-03 19:30                       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180803152034.GD32066@thunk.org \
    --to=tytso@mit.edu \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sagi@grimberg.me \
    --cc=snitzer@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=wgh@torlan.ru \
    --cc=zkabelac@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).