Discuss: accessing past end of object panic about zfs HOT 5 CLOSED

Further details on this, it would appear that both ZOL and FBSD relies on that uio is not yet updated by the time we call update_pages(). But in OS X, the uio has already been depleted by the call to dmu_write_uio_dbuf(). Since the num_ivecs is now 0, uio_update() no longer moves offset along as expected. (And all calls that rely on it, including uiomove())

Possibly a more correct solution is to put these lines near the top of zfs_write()

struct uio *uio_copy = NULL;

            if ( vn_has_cached_data(vp) )
                uio_copy = uio_duplicate(uio);

So that if we know we will call update_pages() (vn_has_cached_data is a test for z_is_mmapped) then make a copy of the uio before we start.

Use uio_copy in the call to update_pages() (as well as call uio_free()). This makes everything work the same as above without manual calls to uio_setoffset() to fix the offset.

As above, we still die later in the mismatched data check.

from zfs.

So at the moment, we make a uio copy.
another option is to change update_pages() to be like ZFS wants it, where we pass offset and len.

Either way is fine by me.

from zfs.

Very nice analysis. Although I am not sure I got the whole story, I think the current approach is fine. Adjusting update_pages() is something we can still do if it may reduce the overall set of changes or makes things simpler by some other way.

from zfs.

@lundman I guess we can safely close this issue by now?

from zfs.

fixed by now

from zfs.