Hi all, I'm currently implementing a new IPv4 option in 2.4.23 kernel, and my problem is to set the value of an IP option in the dedicated field opt->__data of the ip_options structure. AFAIK, setting an IP option is done by the ip_setsockopt( ) function, which in turn calls ip_options_get( ), always with the user parameter set to 1 .This function ip_options_get( ) aims at storing the option chain parameter data in the field opt->__data. Copying the chain data in opt->__data is realized through the copy_from_user( ) function. If I'm wrong with this stuff, please let me know... The copy_from_user() call matters, since it's defined both as preprocessor macro (in include/asm-i386/uaccess.h, line 584) and as a function (in include/linux/compatmac.h, line 80). Currently, the preprocessor macro code is called by ip_options_get( ), and this always provokes a non-null return value, synonym of an error for ip_options_get( ) (the preprocessor macro is defined as __generic_copy_from_user( ) ). Wouldn't it make sense to call the copy_from_user( ) function instead of the preprocessor macro ? In fact, the copy_from_user( ) function calls memcpy( ) function and that would copy the data chain in opt->__data with a correct non-null return value. Using this function instead of the macro seems to allow setting an ip_option with the ip_options_get( ) function. To sum up, is it normal that the copy from_user( ) call in ip_options_get( ) reaches the macro and not the function? Do I have any responsability in that or is it a bug ? If normal, is it possible to create a correct ip_options structure calling ip_options_get( ) ? Or should I consider another way to create an sk_buff structure containing a correct ip_options in the field sk->protinfo.af_inet.opt ? Thanks in advance for all your comments and suggestions. Best regards, Samuel Clouet France Telecom R&D Caen - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
