Page MenuHomeFreeBSD

[PowerPC64] Don't mark module data as static on PowerPC64 - Fixes panic when loading ipfw.ko and if_epair.ko built with modern compiler.
ClosedPublic

Authored by alfredo.junior_eldorado.org.br on May 29 2019, 12:50 PM.

Details

Summary

Similar to arm64 and riscv, when using a modern compiler (!gcc4.2), code generated tries to access data in the wrong location, causing kernel panic (data storage interrupt trap) when loading if_epair and ipfw.

Issue was reproduced with kernel/module compiled using gcc8 and clang8. It affects both ELFv1 and ELFv2 ABI environments.

PR: 232387

Test Plan

Load/Unload if_epair.ko manually
Run FreeBSD TestSuite

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

This change will probably also be needed for DPCPU. Can that be tested as well?

alfredo.junior_eldorado.org.br retitled this revision from [PowerPC64] Don't mark module data as static on PowerPC64 - Fixes panic when loading if_epair.ko built with modern compiler. to [PowerPC64] Don't mark module data as static on PowerPC64 - Fixes panic when loading ipfw.ko and if_epair.ko built with modern compiler..
alfredo.junior_eldorado.org.br edited the summary of this revision. (Show Details)

Same affects DPCPU too and makes ipfw.ko crash during load.
Patch updated fixing this module as well

bz added a subscriber: bz.Jun 13 2019, 7:12 PM

Does this patch fix your issues?
https://svnweb.freebsd.org/base?view=revision&revision=336909 has a brief explanation of the problem; can you look at the code and see if you get a similar problem, just to confirm (and for you to understand as-to why that is?

In D20461#445840, @bz wrote:

Does this patch fix your issues?
https://svnweb.freebsd.org/base?view=revision&revision=336909 has a brief explanation of the problem; can you look at the code and see if you get a similar problem, just to confirm (and for you to understand as-to why that is?

Yes. Interestingly, modifying D17512 to apply for powerpc64, kernel won't panic anymore but module loading is aborted with error message complaining about missing paddings.

emaste added a subscriber: emaste.Jun 15 2019, 1:01 PM
jhibbits accepted this revision.Jun 18 2019, 3:48 PM

We should probably evaluate D17512 again for this at some point, but you demonstrated as-is it's not the complete fix for this problem.

This revision is now accepted and ready to land.Jun 18 2019, 3:48 PM
This revision was automatically updated to reflect the committed changes.