Hi Linus,
please consider pulling the following two gfs2 fixes for 5.17-rc4.
Thanks,
Andreas
The following changes since commit 74382e277ae97b4bcfac6f8b61df7a500d392500:
gfs2: dump inode object for iopen glocks (2022-01-11 16:52:44 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git tags/gfs2-v5.16-rc3-fixes2
for you to fetch changes up to d3add1a9519dcacd6e644ecac741c56cf18b67f5:
gfs2: Fix gfs2_release for non-writers regression (2022-02-11 17:44:42 +0100)
----------------------------------------------------------------
gfs2 fixes:
* Revert debug commit that causes unexpected data corruption.
* Fix muti-block reservation regression.
----------------------------------------------------------------
Andreas Gruenbacher (1):
Revert "gfs2: check context in gfs2_glock_put"
Bob Peterson (1):
gfs2: Fix gfs2_release for non-writers regression
fs/gfs2/file.c | 7 ++++---
fs/gfs2/glock.c | 3 ---
2 files changed, 4 insertions(+), 6 deletions(-)
The pull request you sent on Fri, 11 Feb 2022 18:05:22 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git tags/gfs2-v5.16-rc3-fixes2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8ce964b520ad0ad626cb1ee93a444aedceed5425
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Fri, Feb 11, 2022 at 9:05 AM Andreas Gruenbacher <[email protected]> wrote:
>
> * Revert debug commit that causes unexpected data corruption.
Well, apparently not just unexpected, but unexplained too.
That's a bit worrisome. It sounds like the corruption cause is still
there, just hidden by the lack of __cond_resched()?
Linus
On Fri, Feb 11, 2022 at 8:48 PM Linus Torvalds
<[email protected]> wrote:
> On Fri, Feb 11, 2022 at 9:05 AM Andreas Gruenbacher <[email protected]> wrote:
> >
> > * Revert debug commit that causes unexpected data corruption.
>
> Well, apparently not just unexpected, but unexplained too.
>
> That's a bit worrisome. It sounds like the corruption cause is still
> there, just hidden by the lack of __cond_resched()?
Yes, that's what it looks like. My initial suspicion was that we're
somewhere using gfs2_glock_dq() in non-sleepable context when we know
that we're not dropping the last reference and so gfs2_glock_dq()
won't sleep, but there's no such instance in the code, and testing
would also have revealed such cases. The corruption we've seen always
affects whole pages/blocks. Maybe it's an ordering / memory barrier
issue.
Thanks,
Andreas