| Message ID | 20210827163250.255325-1-hch@lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [for-5.14] cryptoloop: add a deprecation warning | expand |
On 8/27/21 10:32 AM, Christoph Hellwig wrote: > Support for cryptoloop has been officially marked broken and deprecated > in favor of dm-crypt (which supports the same broken algorithms if > needed) in Linux 2.6.4 (released in March 2004), and support for it has > been entirely removed from losetup in util-linux 2.23 (released in April > 2013). Add a warning and a deprecation schedule. Would probably look better to queue with the 5.15 patches at this point. Which then begs the question of whether we want to make the removal target 5.17 instead.
On Fri, Aug 27, 2021 at 10:37:41AM -0600, Jens Axboe wrote: > On 8/27/21 10:32 AM, Christoph Hellwig wrote: > > Support for cryptoloop has been officially marked broken and deprecated > > in favor of dm-crypt (which supports the same broken algorithms if > > needed) in Linux 2.6.4 (released in March 2004), and support for it has > > been entirely removed from losetup in util-linux 2.23 (released in April > > 2013). Add a warning and a deprecation schedule. > > Would probably look better to queue with the 5.15 patches at this point. > Which then begs the question of whether we want to make the removal > target 5.17 instead. File locking also just managed to sneak in a short-term deprecation for a very similar situation.
On 8/27/21 10:40 AM, Christoph Hellwig wrote: > On Fri, Aug 27, 2021 at 10:37:41AM -0600, Jens Axboe wrote: >> On 8/27/21 10:32 AM, Christoph Hellwig wrote: >>> Support for cryptoloop has been officially marked broken and deprecated >>> in favor of dm-crypt (which supports the same broken algorithms if >>> needed) in Linux 2.6.4 (released in March 2004), and support for it has >>> been entirely removed from losetup in util-linux 2.23 (released in April >>> 2013). Add a warning and a deprecation schedule. >> >> Would probably look better to queue with the 5.15 patches at this point. >> Which then begs the question of whether we want to make the removal >> target 5.17 instead. > > File locking also just managed to sneak in a short-term deprecation for > a very similar situation. But what's the point? Why not just wait for 5.15, it's not like we're in a mad dash to get it removed.
On Fri, Aug 27, 2021 at 10:42:59AM -0600, Jens Axboe wrote: > But what's the point? Why not just wait for 5.15, it's not like we're > in a mad dash to get it removed. Actually we kinda are :)
On 8/27/21 10:43 AM, Christoph Hellwig wrote: > On Fri, Aug 27, 2021 at 10:42:59AM -0600, Jens Axboe wrote: >> But what's the point? Why not just wait for 5.15, it's not like we're >> in a mad dash to get it removed. > > Actually we kinda are :) Because?
On Fri, Aug 27, 2021 at 10:43:53AM -0600, Jens Axboe wrote: > On 8/27/21 10:43 AM, Christoph Hellwig wrote: > > On Fri, Aug 27, 2021 at 10:42:59AM -0600, Jens Axboe wrote: > >> But what's the point? Why not just wait for 5.15, it's not like we're > >> in a mad dash to get it removed. > > > > Actually we kinda are :) > > Because? It causes trouble by interacting with the actual loop driver people use in really weird ways, while beeing broken and not actually supported by userspace tools for about a decade.
On 8/27/21 10:46 AM, Christoph Hellwig wrote: > On Fri, Aug 27, 2021 at 10:43:53AM -0600, Jens Axboe wrote: >> On 8/27/21 10:43 AM, Christoph Hellwig wrote: >>> On Fri, Aug 27, 2021 at 10:42:59AM -0600, Jens Axboe wrote: >>>> But what's the point? Why not just wait for 5.15, it's not like we're >>>> in a mad dash to get it removed. >>> >>> Actually we kinda are :) >> >> Because? > > It causes trouble by interacting with the actual loop driver people > use in really weird ways, while beeing broken and not actually supported > by userspace tools for about a decade. I don't disagree with that, but that's not a new situation. Hence my question on why there's this sudden mad rush to get it queued up for removal, literally a few days before a kernel release.
On Fri, Aug 27, 2021 at 10:48:09AM -0600, Jens Axboe wrote: > I don't disagree with that, but that's not a new situation. Hence my > question on why there's this sudden mad rush to get it queued up for > removal, literally a few days before a kernel release. Because this allows the very useful deprecation warning to go out ASAP. It's not like printing a message and adding a little Kconfig text has any risk.
On 8/27/21 10:50 AM, Christoph Hellwig wrote: > On Fri, Aug 27, 2021 at 10:48:09AM -0600, Jens Axboe wrote: >> I don't disagree with that, but that's not a new situation. Hence my >> question on why there's this sudden mad rush to get it queued up for >> removal, literally a few days before a kernel release. > > Because this allows the very useful deprecation warning to go out > ASAP. It's not like printing a message and adding a little Kconfig > text has any risk. You're still not explaining why it should go asap, just that yes it will provide this deprecation warning asap if we queue it up asap. Which is a given. As I said, I don't really care that much about it, but it would be nice to have some actual justification for WHY it should go out asap. It's not really about risk.
On Fri, Aug 27, 2021 at 10:52:52AM -0600, Jens Axboe wrote: > As I said, I don't really care that much about it, but it would be nice > to have some actual justification for WHY it should go out asap. It's > not really about risk. Because as part of the overall huge loop discussion it has resurfaces how broken it is, and how it is in the way of how the loop driver works. Milan for example has argued for just removing it ASAP because of that, but I guess providing at least a bit of time of deprecation would be nice. Then again given that state I'd be perfectly fine with just removing it in 5.16 without much of a warning either.
On 8/27/21 10:55 AM, Christoph Hellwig wrote: > On Fri, Aug 27, 2021 at 10:52:52AM -0600, Jens Axboe wrote: >> As I said, I don't really care that much about it, but it would be nice >> to have some actual justification for WHY it should go out asap. It's >> not really about risk. > > Because as part of the overall huge loop discussion it has resurfaces > how broken it is, and how it is in the way of how the loop driver works. > Milan for example has argued for just removing it ASAP because of that, > but I guess providing at least a bit of time of deprecation would > be nice. Then again given that state I'd be perfectly fine with just > removing it in 5.16 without much of a warning either. OK fair enough, I'll queue it for 5.14.
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 63056cfd4b62c..fbb3a558139fc 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -213,7 +213,7 @@ config BLK_DEV_LOOP_MIN_COUNT dynamically allocated with the /dev/loop-control interface. config BLK_DEV_CRYPTOLOOP - tristate "Cryptoloop Support" + tristate "Cryptoloop Support (DEPRECATED)" select CRYPTO select CRYPTO_CBC depends on BLK_DEV_LOOP @@ -225,7 +225,7 @@ config BLK_DEV_CRYPTOLOOP WARNING: This device is not safe for journaled file systems like ext3 or Reiserfs. Please use the Device Mapper crypto module instead, which can be configured to be on-disk compatible with the - cryptoloop device. + cryptoloop device. cryptoloop support will be removed in Linux 5.16. source "drivers/block/drbd/Kconfig" diff --git a/drivers/block/cryptoloop.c b/drivers/block/cryptoloop.c index 3cabc335ae744..f0a91faa43a89 100644 --- a/drivers/block/cryptoloop.c +++ b/drivers/block/cryptoloop.c @@ -189,6 +189,8 @@ init_cryptoloop(void) if (rc) printk(KERN_ERR "cryptoloop: loop_register_transfer failed\n"); + else + pr_warn("the cryptoloop driver has been deprecated and will be removed in in Linux 5.16\n"); return rc; }
Support for cryptoloop has been officially marked broken and deprecated in favor of dm-crypt (which supports the same broken algorithms if needed) in Linux 2.6.4 (released in March 2004), and support for it has been entirely removed from losetup in util-linux 2.23 (released in April 2013). Add a warning and a deprecation schedule. Signed-off-by: Christoph Hellwig <hch@lst.de> --- drivers/block/Kconfig | 4 ++-- drivers/block/cryptoloop.c | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-)