loader: dosfs can corrupt memory

[tsoome]

Summary

Apparently the libstand dosfs optimization is a bit too optimistic
and did introduce possible memory corruption.

This patch is backing out the bad part and since this results in
dosfs reading full blocks now, we can also remove extra offset argument
from dv_strategy callback.

In addition, fixed list of cstyle issues in dosfs related to return keyword
usage.

The proposed patch is from:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214423

[allanjude]

Does this also catch the bits that were done as followup commits? It looks like you got pc98, but we don't want to break the build again.

[tsoome]

In D8644#179270, @allanjude wrote:

Does this also catch the bits that were done as followup commits? It looks like you got pc98, but we don't want to break the build again.

I did search and walk over entire libstand and boot tree, I think I got them all (including md module;)

[tsoome]

missed memcpy.

[Mikhail.Kupchik_gmail.com]

I have tested this patch in my environment and confirm that it works as expected (fixes PR214423).

[imp]

Hmmm, I'll have to see if I can get my pc98 machine back up and running to test this...

[tsoome]

btw: I did build this update + part device rewrite and did verify by reading the loader.efi reading the EFI system partition - part update because the CURRENT does eat the part devices and did leave only one (from illumos disk) visible... Also I did test on illumos, and confirmed there is no visible load performance degradation.

[tsoome]

update after r309369

[bapt]

LGTM I would like to see a test on pc98 but given this is mostly a revert and a cleanup I'm pretty confident

[allanjude]

We stopped shipping install media and downgraded PC98 to Tier2 with FreeBSD 9.0

I think we are ok to go ahead with this

[allanjude]

Approved for commit