public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* unable to read RDB block due to b9684a71fca793
@ 2022-07-06  2:53 Bagas Sanjaya
  2022-07-06  8:09 ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Bagas Sanjaya @ 2022-07-06  2:53 UTC (permalink / raw)
  To: linux-block; +Cc: Christoph Hellwig, Ming Lei, Jens Axboe, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3682 bytes --]

Hi,

I first noticed this issue on v5.18.9, and still found on v5.19-rc5.

Looking at dmesg, I see error message on loop8 device:

[   41.319699] Dev loop8: unable to read RDB block 8
[   41.320566]  loop8: unable to read partition table
[   41.320597] loop8: partition table beyond EOD, truncated

My Debian 11 laptop is also run LXD (as development server).

Bisecting between v5.18 and v5.19-rc5, the culprit is commit b9684a71fca793
("block, loop: support partitions without scanning").

Here's the bisection log:

git bisect start '--term-good=ok' '--term-bad=oops'
# status: waiting for both good and bad commits
# oops: [88084a3df1672e131ddc1b4e39eeacfd39864acf] Linux 5.19-rc5
git bisect oops 88084a3df1672e131ddc1b4e39eeacfd39864acf
# status: waiting for good commit(s), bad commit known
# ok: [4b0986a3613c92f4ec1bdc7f60ec66fea135991f] Linux 5.18
git bisect ok 4b0986a3613c92f4ec1bdc7f60ec66fea135991f
# ok: [fbe86daca0ba878b04fa241b85e26e54d17d4229] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect ok fbe86daca0ba878b04fa241b85e26e54d17d4229
# ok: [2536b2ca15418c517e3629cc3dd757f811ce52b2] virtio: use virtio_device_ready() in virtio_device_restore()
git bisect ok 2536b2ca15418c517e3629cc3dd757f811ce52b2
# oops: [6f9b5ed8caddfbc94af8307c557ed57a8ec5c65c] Merge tag 'char-misc-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect oops 6f9b5ed8caddfbc94af8307c557ed57a8ec5c65c
# oops: [04d93b2b8bc7a68ec45a6a156f34a611ede5aa60] Merge tag 'spdx-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx
git bisect oops 04d93b2b8bc7a68ec45a6a156f34a611ede5aa60
# ok: [55fe92179058406fe00bff2167c94443a7b2e07a] Merge tag 'i3c/for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux
git bisect ok 55fe92179058406fe00bff2167c94443a7b2e07a
# ok: [96479c09803b21d195c95fd4b145cd3a5a591ba0] Merge tag 'arm-multiplatform-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect ok 96479c09803b21d195c95fd4b145cd3a5a591ba0
# ok: [ab18b7b36a82b1900687c5718f7d46f0d8e77d86] Merge tag 'drm-next-2022-06-03-1' of git://anongit.freedesktop.org/drm/drm
git bisect ok ab18b7b36a82b1900687c5718f7d46f0d8e77d86
# ok: [5ac8bdb9ad47334a9590e29daf7e4149b0a34729] Merge tag 'io_uring-5.19-2022-06-02' of git://git.kernel.dk/linux-block
git bisect ok 5ac8bdb9ad47334a9590e29daf7e4149b0a34729
# oops: [aacae8c469f9ce4b303a2eb61593ff522c1420bc] block: null_blk: Fix null_zone_write()
git bisect oops aacae8c469f9ce4b303a2eb61593ff522c1420bc
# oops: [7d6b902ea0e02b2a25c480edf471cbaa4ebe6b3c] bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()
git bisect oops 7d6b902ea0e02b2a25c480edf471cbaa4ebe6b3c
# ok: [df7e7f2ba0781528e63f04b108819a4ab9889c72] Merge branch 'md-next' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md into for-5.19/drivers
git bisect ok df7e7f2ba0781528e63f04b108819a4ab9889c72
# ok: [80db4e4707e78cb22287da7d058d7274bd4cb370] bcache: remove incremental dirty sector counting for bch_sectors_dirty_init()
git bisect ok 80db4e4707e78cb22287da7d058d7274bd4cb370
# oops: [b9684a71fca793213378dd410cd11675d973eaa1] block, loop: support partitions without scanning
git bisect oops b9684a71fca793213378dd410cd11675d973eaa1
# ok: [32feee36c30ea06e38ccb8ae6e5c44c6eec790a6] bcache: avoid journal no-space deadlock by reserving 1 journal bucket
git bisect ok 32feee36c30ea06e38ccb8ae6e5c44c6eec790a6
# first oops commit: [b9684a71fca793213378dd410cd11675d973eaa1] block, loop: support partitions without scanning

Attached is the config to reproduce.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 41164 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: unable to read RDB block due to b9684a71fca793
  2022-07-06  2:53 unable to read RDB block due to b9684a71fca793 Bagas Sanjaya
@ 2022-07-06  8:09 ` Christoph Hellwig
  2022-07-06 10:16   ` Bagas Sanjaya
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2022-07-06  8:09 UTC (permalink / raw)
  To: Bagas Sanjaya
  Cc: linux-block, Christoph Hellwig, Ming Lei, Jens Axboe,
	linux-kernel

On Wed, Jul 06, 2022 at 09:53:36AM +0700, Bagas Sanjaya wrote:
> Hi,
> 
> I first noticed this issue on v5.18.9, and still found on v5.19-rc5.
> 
> Looking at dmesg, I see error message on loop8 device:
> 
> [   41.319699] Dev loop8: unable to read RDB block 8
> [   41.320566]  loop8: unable to read partition table
> [   41.320597] loop8: partition table beyond EOD, truncated
> 
> My Debian 11 laptop is also run LXD (as development server).
> 
> Bisecting between v5.18 and v5.19-rc5, the culprit is commit b9684a71fca793
> ("block, loop: support partitions without scanning").

Which just restores the previous behavior of optionally allowing to
scan for partitions on all loop devices.  So that error had been
there before and just disappeared due to a regression.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: unable to read RDB block due to b9684a71fca793
  2022-07-06  8:09 ` Christoph Hellwig
@ 2022-07-06 10:16   ` Bagas Sanjaya
  2022-07-06 12:00     ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Bagas Sanjaya @ 2022-07-06 10:16 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-block, Ming Lei, Jens Axboe, linux-kernel

On 7/6/22 15:09, Christoph Hellwig wrote:
>> Bisecting between v5.18 and v5.19-rc5, the culprit is commit b9684a71fca793
>> ("block, loop: support partitions without scanning").
> 
> Which just restores the previous behavior of optionally allowing to
> scan for partitions on all loop devices.  So that error had been
> there before and just disappeared due to a regression.

OK.

Can partition scanning for loop devices be disabled? If so, how?

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: unable to read RDB block due to b9684a71fca793
  2022-07-06 10:16   ` Bagas Sanjaya
@ 2022-07-06 12:00     ` Christoph Hellwig
  0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2022-07-06 12:00 UTC (permalink / raw)
  To: Bagas Sanjaya
  Cc: Christoph Hellwig, linux-block, Ming Lei, Jens Axboe,
	linux-kernel

On Wed, Jul 06, 2022 at 05:16:06PM +0700, Bagas Sanjaya wrote:
> On 7/6/22 15:09, Christoph Hellwig wrote:
> >> Bisecting between v5.18 and v5.19-rc5, the culprit is commit b9684a71fca793
> >> ("block, loop: support partitions without scanning").
> > 
> > Which just restores the previous behavior of optionally allowing to
> > scan for partitions on all loop devices.  So that error had been
> > there before and just disappeared due to a regression.
> 
> OK.
> 
> Can partition scanning for loop devices be disabled? If so, how?

It is disabled by default.  But some tools force partitions rescans,
which is what that commit enabled.  parted was the original reproducer.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-07-06 12:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-06  2:53 unable to read RDB block due to b9684a71fca793 Bagas Sanjaya
2022-07-06  8:09 ` Christoph Hellwig
2022-07-06 10:16   ` Bagas Sanjaya
2022-07-06 12:00     ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox