<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div style="font-family:Calibri,sans-serif">
<div dir="ltr">Thanks Bob,</div>
<br>
<div dir="ltr">We're having a look at the bit that Tim sent earlier to see if switching the call order makes the schedule_timeout never occur.</div>
<br>
<div dir="ltr">As Steven said, it would be nice if we didn't have to worry about waiting for "dead" glocks to be cleaned up but that would require some considerable care to ensure that we don't just get the opposite race and get a newly created glock freed
 and deleted.</div>
<br>
<div dir="ltr">Mark </div>
<hr>
<b>From:</b> Bob Peterson <rpeterso@redhat.com><br>
<b>Sent:</b> Monday, 8 October 2018 21:10<br>
<b>To:</b> Mark Syms <Mark.Syms@citrix.com><br>
<b>CC:</b> cluster-devel@redhat.com,Ross Lagerwall <ross.lagerwall@citrix.com>,Tim Smith <tim.smith@citrix.com><br>
<b>Subject:</b> Re: [Cluster-devel] [PATCH 2/2] GFS2: Flush the GFS2 delete workqueue before stopping the kernel threads<br>
<br>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">----- Original Message -----<br>
> From: Tim Smith <tim.smith@citrix.com><br>
> <br>
> Flushing the workqueue can cause operations to happen which might<br>
> call gfs2_log_reserve(), or get stuck waiting for locks taken by such<br>
> operations.  gfs2_log_reserve() can io_schedule(). If this happens, it<br>
> will never wake because the only thing which can wake it is gfs2_logd()<br>
> which was already stopped.<br>
> <br>
> This causes umount of a gfs2 filesystem to wedge permanently if, for<br>
> example, the umount immediately follows a large delete operation.<br>
> <br>
> When this occured, the following stack trace was obtained from the<br>
> umount command<br>
> <br>
> [<ffffffff81087968>] flush_workqueue+0x1c8/0x520<br>
> [<ffffffffa0666e29>] gfs2_make_fs_ro+0x69/0x160 [gfs2]<br>
> [<ffffffffa0667279>] gfs2_put_super+0xa9/0x1c0 [gfs2]<br>
> [<ffffffff811b7edf>] generic_shutdown_super+0x6f/0x100<br>
> [<ffffffff811b7ff7>] kill_block_super+0x27/0x70<br>
> [<ffffffffa0656a71>] gfs2_kill_sb+0x71/0x80 [gfs2]<br>
> [<ffffffff811b792b>] deactivate_locked_super+0x3b/0x70<br>
> [<ffffffff811b79b9>] deactivate_super+0x59/0x60<br>
> [<ffffffff811d2998>] cleanup_mnt+0x58/0x80<br>
> [<ffffffff811d2a12>] __cleanup_mnt+0x12/0x20<br>
> [<ffffffff8108c87d>] task_work_run+0x7d/0xa0<br>
> [<ffffffff8106d7d9>] exit_to_usermode_loop+0x73/0x98<br>
> [<ffffffff81003961>] syscall_return_slowpath+0x41/0x50<br>
> [<ffffffff815a594c>] int_ret_from_sys_call+0x25/0x8f<br>
> [<ffffffffffffffff>] 0xffffffffffffffff<br>
> <br>
> Signed-off-by: Tim Smith <tim.smith@citrix.com><br>
> Signed-off-by: Mark Syms <mark.syms@citrix.com><br>
> ---<br>
Hi Mark, Tim, and all,<br>
<br>
I pushed patch 2/2 upstream. For now I'll hold off on 1/2 but keep it<br>
on my queue, pending our investigation.<br>
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=b7f5a2cd27b76e96fdc6d77b060dfdd877c9d0a9">https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=b7f5a2cd27b76e96fdc6d77b060dfdd877c9d0a9</a><br>
<br>
Regards,<br>
<br>
Bob Peterson<br>
</div>
</span></font>
</body>
</html>