> Thank you for your very detailed reply! I'm going to send a V2 which > should address all your comments. Appreciated. (Well, it might be worth to give other people/reviewers some more time to process v1 and this discussion... ;) ) > Provided that there are indeed drivers (hv_storvsc and hv_netvsc) > which explicitly account for vmpacket_descriptor header, changing > max_pkt_size for individual drivers makes more sense. > However in this case I'm not sure about our reasoning of 'pkt_offset' > above. In drivers/scsi/storvsc_drv.c: > > #define STORVSC_MAX_PKT_SIZE (sizeof(struct vmpacket_descriptor) +\ > sizeof(struct vstor_packet)) > > Should I also change this 'sizeof(struct vmpacket_descriptor)' to > VMBUS_MAX_PKT_DESCR_SIZE? Otherwise this would not match the check in > hv_pkt_iter_first. AFAICT, the above #define is fine, i.e., it represents an upper bound on pkt_len as used in hv_pkt_iter_first() (this is all is required on max_pkt_size, cf. the memcpy() in hv_pkt_iter_first()). The same consideration, AFAICT, holds for NETVSC_MAX_PKT_SIZE. The remarks about pkt_offset targetted the cases, such as hv_balloon, where we can somehow upper bound (pkt_len - pkt_offset) (the "packet payload"), since then an upper bound on pkt_offset would give us an upper bound on pkt_len "for free" (associativity): ptk_len = (pkt_len - pkt_offset) + pkt_offset Andrea
