On Mon, Sep 16, 2013 at 09:55:44PM +0000, KY Srinivasan wrote: > > > > -----Original Message----- > > From: Dan Carpenter [mailto:[email protected]] > > Sent: Monday, September 16, 2013 1:13 PM > > To: KY Srinivasan > > Cc: [email protected]; [email protected]; [email protected]; Dmitry > > Torokhov; [email protected]; [email protected]; linux- > > [email protected]; [email protected]; [email protected] > > Subject: Re: [PATCH 1/1] Drivers: input: serio: New driver to support > > Hyper-V > > synthetic keyboard > > > > On Mon, Sep 16, 2013 at 06:42:25PM +0000, KY Srinivasan wrote: > > > Dan, > > > > > > Rolling the changes you have indicated is not the issue; this can > > > trivially be > > done. > > > My contention is that it is not needed given that the underlying function > > > is > > already > > > doing that. Look at the function vmbus_recvpacket_raw() in > > drivers/hv/channel.c. > > > > > > > I'm confused. > > > > There is no mention of ->offset8 in vmbus_recvpacket_raw(). > > As you can see the vmbus_recvpacket_raw() ensures that the complete > packet is read and if the buffer specified is not large enough nothing is > read. The packet header has information about the length of the packet > and the offset where the payload is. > >
No one is talking about the ->len8. I'm saying that we should check ->offset8. > > It's a good idea to add a check there but the lower levels don't know > > about the sizeof(synth_kbd_protocol_response) so we would still need > > something like my check. > > Why would the lower level code need to know anything about the layout of a > particular message type. The lower level code is guaranteeing that a complete > packet has been read in and that should be sufficient - assuming we trust the > host. > Of course, we don't need to check anything if we trust the host. I said that already. Just add the check for robustness. > We have already spent more time on this than we should; I will make the > necessary > changes. Thank you. regards, dan carpenter _______________________________________________ devel mailing list [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
