Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp862568imm; Fri, 3 Aug 2018 12:57:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcD/3G58LRhDfvwqdkZ027NxA9aA17DncJhTtQsqBPxOB9z+d8/CJJwpWD48QeS4SQvcBTl X-Received: by 2002:a63:e355:: with SMTP id o21-v6mr5127264pgj.251.1533326263713; Fri, 03 Aug 2018 12:57:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533326263; cv=none; d=google.com; s=arc-20160816; b=F7OvKIUBZTozpod7yHQYUOMnYYq1JQFfCe1P1+QrS9dkqrIvFoYrw4m2y7rLRYjdVj QcEdP66U4LS7LsrCqayyrAJllmejsBjW4GplaEIPxVqp3Op/n8s3EcGVNboFhTz84NC/ dgQ8FMp9gOWVXlUX1/zElg5xs2sdig0rAiURCmDRcUzePkA98wwHGSD4OIjjip5spt2d 3wHwVDDP9m+LoQx18o9vp03j1TqmpN2xPIP/AK0R3cS6cnC1NNuAf+IUyhSfTffLUPa3 rDfhx/M98SzV0V8RmOvOhrQcasHwn0Ee3/Fa9o8g2yfOIBWUZt+mJJpenyeGcrpqL9Fa y7kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=kXCWrE1quoU4oxwu1AK0m85GqDpkfD83WVOW6IjKopU=; b=Iis0yEzC6IpZbHYBBULbrKD3Lla08EcAyHR06jtqygn3+35lTsI1huN4ErZ/jAuZho 0pq9gE2T1us+Jlp0o2eSUEPxwLb4iYIgfRz6SSujR/Q4c3NfC07wCQQsDq/ZPfCUiVU3 9cWvVXnTqriffm4C3LAr4YRYLts8Ed9prqm8w1jHBtl5Tq2bOQYMjJY6BDu9/FbJzCUt QjbzjzrDTfz0TAaQhbHnPABI9MrKUAX3PFOru8E4lE3oc9S5QkWrqZ5MLwKaO33enFui ZyElS0dQ3B1bQJeOQ7cbdkuePGn9nS/wPp0qGlHBCcz0jx4Zb4v29t3m8hjizqNyKwlZ 7PAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si4418273plu.65.2018.08.03.12.57.28; Fri, 03 Aug 2018 12:57:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731932AbeHCVyX (ORCPT + 99 others); Fri, 3 Aug 2018 17:54:23 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59552 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729796AbeHCVyX (ORCPT ); Fri, 3 Aug 2018 17:54:23 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4D28BF2B40; Fri, 3 Aug 2018 19:56:38 +0000 (UTC) Received: from agk-dp.fab.redhat.com (agk-dp.fab.redhat.com [10.33.15.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ABEBD2026D65; Fri, 3 Aug 2018 19:56:37 +0000 (UTC) Received: from agk by agk-dp.fab.redhat.com with local (Exim 4.69) (envelope-from ) id 1flgBg-0008H5-HC; Fri, 03 Aug 2018 20:56:36 +0100 Date: Fri, 3 Aug 2018 20:56:36 +0100 From: Alasdair G Kergon To: "Theodore Y. Ts'o" Cc: Mike Snitzer , Linus Torvalds , Jens Axboe , Sagi Grimberg , Linux Kernel Mailing List , linux-block , dm-devel@redhat.com, Ilya Dryomov , wgh@torlan.ru, Zdenek Kabelac Subject: Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16 Message-ID: <20180803195636.GA31444@agk-dp.fab.redhat.com> Mail-Followup-To: "Theodore Y. Ts'o" , Mike Snitzer , Linus Torvalds , Jens Axboe , Sagi Grimberg , Linux Kernel Mailing List , linux-block , dm-devel@redhat.com, Ilya Dryomov , wgh@torlan.ru, Zdenek Kabelac References: <93bff248-6897-4867-841b-2dace11597de@torlan.ru> <1ec0a220-d5b0-1c27-e63b-c4d3f4ce9d77@torlan.ru> <20180803133102.GA3092@redhat.com> <20180803152034.GD32066@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180803152034.GD32066@thunk.org> Organization: Red Hat UK Ltd. Registered in England and Wales, number 03798903. Registered Office: Peninsular House, 30-36 Monument Street, 4th Floor, London, England, EC3R 8NB. User-Agent: Mutt/1.5.18 (2008-05-17) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 03 Aug 2018 19:56:38 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 03 Aug 2018 19:56:38 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'agk@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 03, 2018 at 11:20:34AM -0400, Theodore Y. Ts'o wrote: > 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. Brings back memories! For those who wonder what this is all about, with LVM1, if the version of kernel and userspace didn't match it simply stopped. No booting into the previous version of your kernel after upgrading unless you reverted userspace as well! Led to all sorts of not-so-fancy workarounds. As a reaction to this, LVM2 (through libdevmapper and anything else using the dm ioctls as documented in dm-ioctl.h) passes a version number up to the kernel (to say "I know about kernels with dm up to and including version x.y.z"), so there is an option for an in-kernel workaround here to limit its compatibility mode to the broken userspace versions. Anything passing in version 4.37.0 or earlier (which is the version in dm-ioctl.h when this kernel patch was applied) could be assumed to require the old behaviour. check_version() is where this version is seen, so it would either store it for later checking or do the check and store a flag to invoke compatible behaviour later. Alasdair