Page MenuHomeFreeBSD
Differential D26034

zfs: fix EIO accessing dataset after resuming interrupted receive
ClosedPublic
Actions

Authored by asomers on Aug 11 2020, 8:36 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 8, 2:47 AM
Unknown Object (File)
Wed, Mar 5, 8:03 AM
Unknown Object (File)
Wed, Mar 5, 7:34 AM
Unknown Object (File)
Wed, Mar 5, 2:28 AM
Unknown Object (File)
Jan 18 2025, 6:47 AM
Unknown Object (File)
Nov 22 2024, 11:18 AM
Unknown Object (File)
Nov 14 2024, 9:09 AM
Unknown Object (File)
Nov 4 2024, 4:11 PM
View All 42 Files
Subscribers
delphij
imp

Details

Reviewers
freqlabs
avg
mmacy
Commits
rS364978: MFC r364412:
rS364974: MFC r364412:
rS364412: zfs: fix EIO accessing dataset after resuming interrupted receive
Summary

zfs: fix EIO accessing dataset after resuming interrupted receive

ZFS unmounts a dataset while receiving into it and remounts it afterwards.
But if ZFS is resuming an incomplete receive, it screws up and ends up with
a dataset that is mounted, but returns EIO for every access. This commit
fixes that condition.

While the vulnerable code also exists in OpenZFS, the problem is not
reproducible there. Apparently OpenZFS doesn't unmount the destination
dataset during receive, like FreeBSD does.

PR: 248606

Test Plan

ZFS test suite, plus instructions attached to PR

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 32927
Build 30325: arc lint + arc unit

Revision Contents
Changeset List

PathSize
cddl/
contrib/
opensolaris/
lib/
libzfs/
common/
2 lines

Diff 75701

View Options

cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c

Context not available.
JAVA="%%LOCALBASE%%/bin/java" JAVA="%%LOCALBASE%%/bin/java"
JARPATH="%%JAVALIBDIR%%" JARPATH="%%JAVALIBDIR%%"
export JAVA_VERSION="%%JAVA_VERSION%%"
glewisUnsubmitted
Not Done
Inline Actions

Note that this may cause a subtle change in behaviour if either the ports tree is not present on a system or if javavmwrapper is otherwise instructed to use it's own internal logic (e.g. if JAVAVM_FALLBACK_ONLY is set).

> env JAVAVM_FALLBACK_ONLY=yes JAVA_VERSION=1.6+ /usr/local/bin/java -version                                                                       openjdk version "12.0.2" 2019-07-16

> env JAVAVM_FALLBACK_ONLY=yes /usr/local/bin/java -version 
openjdk version "13.0.1" 2019-10-15

This will depend on what versions the user has installed. This is actually more of a bug in javavmwrapper which I'll look into (it doesn't understand JDK 13 yet). It also doesn't have a default version (e.g. 8) and uses the "newest" one if no version is supplied. If a version is supplied then it uses the newest version that it understands.

An alternative to all these script changes would be to have bsd.java.mk always add JAVA_VERSION to SUB_LIST, using the version it ends up deciding on if none is set.

glewis: Note that this may cause a subtle change in behaviour if either the ports tree is not present…
jkimAuthorUnsubmitted
Not Done
Inline Actions

AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page says:

However, this option, when used with scripts installed by a port,
may result in Java VM selection inconsistent with that intended
by the script author.
jkim: AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page…
glewisUnsubmitted
Not Done
Inline Actions

As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY that you may get different behaviour from what you do when the ports tree is present.

What is a bug is that the presence of "JAVA_VERSION=1.6+" in the two command lines above shouldn't make a difference. Whether it is present or not, the fallback logic should choose the same version. That is what I was pointing out. So by removing that line from the invocation, this change may affect what version is chosen in that situation, even though it shouldn't. The likelihood of this impacting people is quite low though, so I'm not overly concerned. I also have a fix I can commit after this change (I don't want to commit while this is in flight since it will conflict with changes here).

glewis: As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY…
jkimAuthorUnsubmitted
Not Done
Inline Actions

Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any difference with or without the ports tree as the PR167799 said.

jkim: Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any…
exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@" exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"
Context not available.