ena: Add completion descriptor corruption check

[osamaabb_amazon.com]

Summary

Adding a check of the MBZ (Must Be Zero) fields in the
incoming tx and rx completion descriptors in order to
identify corrupted descriptors.

Approved by: cperciva
MFC after: 2 weeks
Sponsored by: Amazon, Inc.

[cperciva]

Is returning an error the right response here? My initial reaction is that this should be a kernel panic, but maybe it's easier to track down such faults if the system keeps running?

[osamaabb_amazon.com]

In D46337#1064449, @cperciva wrote:

Is returning an error the right response here? My initial reaction is that this should be a kernel panic, but maybe it's easier to track down such faults if the system keeps running?

I feel like a kernel panic is a bit of an overkill here, for these cases we currently reset the driver with ENA_REGS_RESET_RX_DESCRIPTOR_MALFORMED reset reason
We aim for recovery to maintain network availability

[cperciva]

In D46337#1065887, @osamaabb_amazon.com wrote:

In D46337#1064449, @cperciva wrote:

Is returning an error the right response here? My initial reaction is that this should be a kernel panic, but maybe it's easier to track down such faults if the system keeps running?

I feel like a kernel panic is a bit of an overkill here, for these cases we currently reset the driver with ENA_REGS_RESET_RX_DESCRIPTOR_MALFORMED reset reason
We aim for recovery to maintain network availability

Ok, your call. I think there's tension here between availability and integrity -- my general position is "if we detected that one thing is corrupted, who knows how much undetected corruption has happened, so we should panic and reboot into a clean state rather than trusting anything about the currently running system". But obviously it's a tradeoff and you know the context of the system better than I do.