On Mon, Sep 16, 2013 at 09:55:44PM +0000, KY Srinivasan wrote: > > > > -----Original Message----- > > From: Dan Carpenter [mailto:dan.carpenter@xxxxxxxxxx] > > Sent: Monday, September 16, 2013 1:13 PM > > To: KY Srinivasan > > Cc: olaf@xxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; jasowang@xxxxxxxxxx; Dmitry > > Torokhov; linux-kernel@xxxxxxxxxxxxxxx; vojtech@xxxxxxx; linux- > > input@xxxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx > > 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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
