Shouldn't this be a KASSERT? I mean, from what I understand it's the kernel code that returns those; it can be expected to provide valid ones.

The prefixes are missing. Also, the code generally uses size_t for those. And some spares perhaps?

Again, why not size_t?

s/iLLegal/illegal/

I'm going to change cxgbei in the near future to report different limits based on the type of card in the system, and maybe even have user-tunable knobs (in cxgbei, not global) to have it report different limits.

I'll add the prefix in the next update to this review.

The existing code isn't very consistent about using size_t for these parameters. For example, struct iscsi_session_state uses int and not size_t. Also, I was hoping to get this into 11 and the spare fields available were all ints, so ...

All these values are required by the RFC to be 0 or between 512 and 2^24 - 1. So it is guaranteed that they'll fit in an int. I'd actually like to change them to int all over to compact all the data structures. If that's ok I'd also like to rename foo_data_segment_length variables to foo_dsl during my sweep.

Takes twice the size on amd64. See reply to previous inline comment too.

Good catch, thanks. I'll fix it in the next iteration of the patch.

Okay, but my point is: can't cxgbei, and other ICL modules, be trusted to not return invalid values to the stack?

Ah, ok then - cleaning up the types is always welcome :-) Make sure you don't miss any checks. As for renaming - I'm not a huge fan of shortening stuff this way, to be honest.

If a driver makes these limits user-tunable within some bounds (I'm thinking of doing this eventually in cxgbei) then it makes sense to catch illegal values. The range checks could be in the driver(s) or in one central place for all. Putting them in one place is better imho.