* [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again
@ 2019-07-31 12:13 SunKe
2019-07-31 13:50 ` Josef Bacik
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: SunKe @ 2019-07-31 12:13 UTC (permalink / raw)
To: sunke32, josef, axboe, linux-block, nbd, linux-kernel, kamatam,
manoj.br, stable, dwmw
From: Munehisa Kamata <kamatam@amazon.com>
Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()")
once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere")
resurrected kill_bdev() and it has been there since then. So buffer_head
mappings still get killed on a server disconnection, and we can still
hit the BUG_ON on a filesystem on the top of the nbd device.
EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null)
block nbd0: Receive control failed (result -32)
block nbd0: shutting down sockets
print_req_error: I/O error, dev nbd0, sector 66264 flags 3000
EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block
print_req_error: I/O error, dev nbd0, sector 2264 flags 3000
EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block
EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure
------------[ cut here ]------------
kernel BUG at fs/buffer.c:3057!
invalid opcode: 0000 [#1] SMP PTI
CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4
Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017
RIP: 0010:submit_bh_wbc+0x18b/0x190
...
Call Trace:
jbd2_write_superblock+0xf1/0x230 [jbd2]
? account_entity_enqueue+0xc5/0xf0
jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2]
jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2]
? __switch_to_asm+0x40/0x70
...
? lock_timer_base+0x67/0x80
kjournald2+0x121/0x360 [jbd2]
? remove_wait_queue+0x60/0x60
kthread+0xf8/0x130
? commit_timeout+0x10/0x10 [jbd2]
? kthread_bind+0x10/0x10
ret_from_fork+0x35/0x40
With __invalidate_device(), I no longer hit the BUG_ON with sync or
unmount on the disconnected device.
Fixes: 29eaadc03649 ("nbd: stop using the bdev everywhere")
Cc: linux-block@vger.kernel.org
Cc: Ratna Manoj Bolla <manoj.br@gmail.com>
Cc: nbd@other.debian.org
Cc: stable@vger.kernel.org
Cc: David Woodhouse <dwmw@amazon.com>
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
---
I reproduced this phenomenon on the fat file system.
reproduce steps :
1.Establish a nbd connection.
2.Run two threads:one do mount and umount,anther one do clear_sock ioctl
3.Then hit the BUG_ON.
v2: Delete a link.
Signed-off-by: SunKe <sunke32@huawei.com>
drivers/block/nbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 9bcde23..e21d2de 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1231,7 +1231,7 @@ static void nbd_clear_sock_ioctl(struct nbd_device *nbd,
struct block_device *bdev)
{
sock_shutdown(nbd);
- kill_bdev(bdev);
+ __invalidate_device(bdev, true);
nbd_bdev_reset(bdev);
if (test_and_clear_bit(NBD_HAS_CONFIG_REF,
&nbd->config->runtime_flags))
--
2.7.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again
2019-07-31 12:13 [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again SunKe
@ 2019-07-31 13:50 ` Josef Bacik
2019-07-31 14:52 ` Jens Axboe
2019-07-31 23:38 ` Munehisa Kamata
2 siblings, 0 replies; 4+ messages in thread
From: Josef Bacik @ 2019-07-31 13:50 UTC (permalink / raw)
To: SunKe
Cc: josef, axboe, linux-block, nbd, linux-kernel, kamatam, manoj.br,
stable, dwmw
On Wed, Jul 31, 2019 at 08:13:10PM +0800, SunKe wrote:
> From: Munehisa Kamata <kamatam@amazon.com>
>
> Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()")
> once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere")
> resurrected kill_bdev() and it has been there since then. So buffer_head
> mappings still get killed on a server disconnection, and we can still
> hit the BUG_ON on a filesystem on the top of the nbd device.
>
> EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null)
> block nbd0: Receive control failed (result -32)
> block nbd0: shutting down sockets
> print_req_error: I/O error, dev nbd0, sector 66264 flags 3000
> EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block
> print_req_error: I/O error, dev nbd0, sector 2264 flags 3000
> EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block
> EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure
> ------------[ cut here ]------------
> kernel BUG at fs/buffer.c:3057!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4
> Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017
> RIP: 0010:submit_bh_wbc+0x18b/0x190
> ...
> Call Trace:
> jbd2_write_superblock+0xf1/0x230 [jbd2]
> ? account_entity_enqueue+0xc5/0xf0
> jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2]
> jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2]
> ? __switch_to_asm+0x40/0x70
> ...
> ? lock_timer_base+0x67/0x80
> kjournald2+0x121/0x360 [jbd2]
> ? remove_wait_queue+0x60/0x60
> kthread+0xf8/0x130
> ? commit_timeout+0x10/0x10 [jbd2]
> ? kthread_bind+0x10/0x10
> ret_from_fork+0x35/0x40
>
> With __invalidate_device(), I no longer hit the BUG_ON with sync or
> unmount on the disconnected device.
>
Jeeze I swear I see this same patch go by every 6 months or so, not sure what
happens to it. Anyway
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again
2019-07-31 12:13 [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again SunKe
2019-07-31 13:50 ` Josef Bacik
@ 2019-07-31 14:52 ` Jens Axboe
2019-07-31 23:38 ` Munehisa Kamata
2 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2019-07-31 14:52 UTC (permalink / raw)
To: SunKe, josef, linux-block, nbd, linux-kernel, kamatam, manoj.br,
stable, dwmw
On 7/31/19 6:13 AM, SunKe wrote:
> From: Munehisa Kamata <kamatam@amazon.com>
>
> Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()")
> once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere")
> resurrected kill_bdev() and it has been there since then. So buffer_head
> mappings still get killed on a server disconnection, and we can still
> hit the BUG_ON on a filesystem on the top of the nbd device.
>
> EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null)
> block nbd0: Receive control failed (result -32)
> block nbd0: shutting down sockets
> print_req_error: I/O error, dev nbd0, sector 66264 flags 3000
> EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block
> print_req_error: I/O error, dev nbd0, sector 2264 flags 3000
> EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block
> EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure
> ------------[ cut here ]------------
> kernel BUG at fs/buffer.c:3057!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4
> Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017
> RIP: 0010:submit_bh_wbc+0x18b/0x190
> ...
> Call Trace:
> jbd2_write_superblock+0xf1/0x230 [jbd2]
> ? account_entity_enqueue+0xc5/0xf0
> jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2]
> jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2]
> ? __switch_to_asm+0x40/0x70
> ...
> ? lock_timer_base+0x67/0x80
> kjournald2+0x121/0x360 [jbd2]
> ? remove_wait_queue+0x60/0x60
> kthread+0xf8/0x130
> ? commit_timeout+0x10/0x10 [jbd2]
> ? kthread_bind+0x10/0x10
> ret_from_fork+0x35/0x40
>
> With __invalidate_device(), I no longer hit the BUG_ON with sync or
> unmount on the disconnected device.
Applied, thanks.
--
Jens Axboe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again
2019-07-31 12:13 [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again SunKe
2019-07-31 13:50 ` Josef Bacik
2019-07-31 14:52 ` Jens Axboe
@ 2019-07-31 23:38 ` Munehisa Kamata
2 siblings, 0 replies; 4+ messages in thread
From: Munehisa Kamata @ 2019-07-31 23:38 UTC (permalink / raw)
To: SunKe, josef, axboe, linux-block, nbd, linux-kernel, manoj.br,
stable, dwmw
On 7/31/2019 5:13 AM, SunKe wrote:
> From: Munehisa Kamata <kamatam@amazon.com>
>
> Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()")
> once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere")
> resurrected kill_bdev() and it has been there since then. So buffer_head
> mappings still get killed on a server disconnection, and we can still
> hit the BUG_ON on a filesystem on the top of the nbd device.
>
> EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null)
> block nbd0: Receive control failed (result -32)
> block nbd0: shutting down sockets
> print_req_error: I/O error, dev nbd0, sector 66264 flags 3000
> EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block
> print_req_error: I/O error, dev nbd0, sector 2264 flags 3000
> EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block
> EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure
> ------------[ cut here ]------------
> kernel BUG at fs/buffer.c:3057!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4
> Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017
> RIP: 0010:submit_bh_wbc+0x18b/0x190
> ...
> Call Trace:
> jbd2_write_superblock+0xf1/0x230 [jbd2]
> ? account_entity_enqueue+0xc5/0xf0
> jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2]
> jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2]
> ? __switch_to_asm+0x40/0x70
> ...
> ? lock_timer_base+0x67/0x80
> kjournald2+0x121/0x360 [jbd2]
> ? remove_wait_queue+0x60/0x60
> kthread+0xf8/0x130
> ? commit_timeout+0x10/0x10 [jbd2]
> ? kthread_bind+0x10/0x10
> ret_from_fork+0x35/0x40
>
> With __invalidate_device(), I no longer hit the BUG_ON with sync or
> unmount on the disconnected device.
>
> Fixes: 29eaadc03649 ("nbd: stop using the bdev everywhere")
> Cc: linux-block@vger.kernel.org
> Cc: Ratna Manoj Bolla <manoj.br@gmail.com>
> Cc: nbd@other.debian.org
> Cc: stable@vger.kernel.org
> Cc: David Woodhouse <dwmw@amazon.com>
> Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
>
> ---
> I reproduced this phenomenon on the fat file system.
> reproduce steps :
> 1.Establish a nbd connection.
> 2.Run two threads:one do mount and umount,anther one do clear_sock ioctl
> 3.Then hit the BUG_ON.
>
> v2: Delete a link.
>
> Signed-off-by: SunKe <sunke32@huawei.com>
>
> drivers/block/nbd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 9bcde23..e21d2de 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -1231,7 +1231,7 @@ static void nbd_clear_sock_ioctl(struct nbd_device *nbd,
> struct block_device *bdev)
> {
> sock_shutdown(nbd);
> - kill_bdev(bdev);
> + __invalidate_device(bdev, true);
> nbd_bdev_reset(bdev);
> if (test_and_clear_bit(NBD_HAS_CONFIG_REF,
> &nbd->config->runtime_flags))
>
Hi SunKe,
I accidentally included the link in the original one. Sorry about that and thanks
for picking this up.
Regards,
Munehsia
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-07-31 23:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-31 12:13 [PATCH v2] nbd: replace kill_bdev() with __invalidate_device() again SunKe
2019-07-31 13:50 ` Josef Bacik
2019-07-31 14:52 ` Jens Axboe
2019-07-31 23:38 ` Munehisa Kamata
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).