> -----Original Message----- > From: vaughan [mailto:vaughan.cao@xxxxxxxxxx] > Sent: Tuesday, March 05, 2013 7:48 AM > To: KY Srinivasan > Cc: devel@xxxxxxxxxxxxxxxxxxxxxx; Haiyang Zhang; xitao.cao@xxxxxxxxx > Subject: hyperv: is register a mandatory phase by hypervkvpd? > > I guess I found a bug -- hypervkvpd running alone without hv_utils > loaded encounters segfault when service cgred start on RHEL6.4. It > occurs with both 0.8 and 0.9, regardless of i686 or x86_64. > > I read in hv_kvp_daemon.c that the user mode componet should first > registers with the kernel component. > But in my test, the hand shake phase has been ignored. > Things happens like this: > hv_utils.ko and hv_vmbus.ko is not loaded, start hypervkvpd is fine. > Then, I start cgred with the default configuration. cgroup also use > NETLINK_CONNECTOR protocol and send messages with cb_id{1,1}. Hypervkvpd > receive messages without checking their source. Some messages with > cb_id{1,1} were receviced and blindly interpreted as hv_kvp_msg. Since > the hand_shake check is as below: > if ((in_hand_shake) && (op == KVP_OP_REGISTER1)) { > ... > continue; > } > //handle kvp messages > switch (op) { ... } > Register phase is also skipped. > Everytime the KVP_OP_SET opcode is reached, kvp_key_add_or_modify() is > invoked with an very large key_size. After several iterations, segfault > occurs in memcpy(record[i].key, key, key_size) (key_size is negative now). > > I'm not very familiar with connector. But I ran the sample in > Documentation/connector/ and found that a NETLINK_CONNECTOR socket > would > always some messages with cb_id{1,1}. So blindly suppose all messages > are kvp_msg is not correct. hypervkvpd should check the source of > messages and perhaps even check nlmsg_type in the nlmsghdr. > The current code does use recvfrom() and checks the sending PID to see if it is trusted. What version of the code are you testing with. Regards, K. Y > -- > Regards, > Vaughan > > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel