Netlink socket returns NULL in vmx.c kernel file
Dear All, I am posting again the same problem that is "Netlink socket creation returns NULL" when I try to create it in handle_ept_violation() in the vmx.c file. Actually, I am trying to use netlink to send information (i.e., guest physical address) from kernel space to user space. The netlink socket creation is not working in the context of vmx.c, but it works perfectly when I test my code in a kernel module and load it. Code is in the attachement. I have tested many things such as shared memory, kernel thread, sleep function, etc. but nothing worked out. Can you please what's the problem? *What's the best too/way that can provide full duplex (two-way) communication between kernel and user spaces in any context (from any kernel source file)*. Thank you. -- *Best Regards,* *Mr. Irfan Ullah* PhD Candidate Data and Knowledge Engineering(DKE) Lab Department of Computer Science and Engineering Kyung Hee University, South Korea. +82-010-591-51651 <+82%2010-3877-8867> sahibzada.iu@gmail.com sahibzada_irfanullah
On Wed, 23 Oct 2019 11:43:22 +0900, Irfan Ullah said:
Can you please what's the problem?
To be brutally honest, your code is too unreadable to figure out what the problem is. First off, fix your code formatting to match Linux kernel indenting. Second, there's a lot of code in your .h file that should be in a .c file. Third, functions should be static when feasible.
I have tested code from different aspects. I have searched a lot in two weeks, but still I am facing the same problem. Can you please check out what is the problem with my code. Code is in the attached zipped file. Thank you very much. On Wed, Oct 23, 2019 at 2:38 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Wed, 23 Oct 2019 11:43:22 +0900, Irfan Ullah said:
Can you please what's the problem?
To be brutally honest, your code is too unreadable to figure out what the problem is.
First off, fix your code formatting to match Linux kernel indenting.
Second, there's a lot of code in your .h file that should be in a .c file.
Third, functions should be static when feasible.
-- *Best Regards,* *Mr. Irfan Ullah* PhD Candidate Data and Knowledge Engineering(DKE) Lab Department of Computer Science and Engineering Kyung Hee University, South Korea. +82-010-591-51651 <+82%2010-3877-8867> sahibzada.iu@gmail.com sahibzada_irfanullah
On Tue, Nov 05, 2019 at 12:29:56PM +0900, Irfan Ullah (울라 이르판) wrote:
I have tested code from different aspects. I have searched a lot in two weeks, but still I am facing the same problem. Can you please check out what is the problem with my code. Code is in the attached zipped file.
Random compressed files are not the easiest way to review code. Just attach the files inline if you wish people to be able to review them easily, like all kernel development happens. thanks, greg k-h
Thank you for the response. Attached are the files for kernel-user spaces communication. On Tue, Nov 5, 2019 at 4:22 PM Greg KH <greg@kroah.com> wrote:
On Tue, Nov 05, 2019 at 12:29:56PM +0900, Irfan Ullah (울라 이르판) wrote:
I have tested code from different aspects. I have searched a lot in two weeks, but still I am facing the same problem. Can you please check out what is the problem with my code. Code is in the attached zipped file.
Random compressed files are not the easiest way to review code. Just attach the files inline if you wish people to be able to review them easily, like all kernel development happens.
thanks,
greg k-h
-- *Best Regards,* *Mr. Irfan Ullah* PhD Candidate Data and Knowledge Engineering(DKE) Lab Department of Computer Science and Engineering Kyung Hee University, South Korea. +82-010-591-51651 <+82%2010-3877-8867> sahibzada.iu@gmail.com sahibzada_irfanullah
On Tue, 05 Nov 2019 17:59:43 +0900, Irfan Ullah said:
Thank you for the response. Attached are the files for kernel-user spaces communication.
//when I remove this wait the code does not work msleep(3000);
If your code doesn't work, but sticking in random delays makes it start working, you almost certainly have a race condition or synchronization issue that should be fixed using proper locking.
void hello_exit(void) { //netlink_kernel_release(nl_sk);
Congratulations. You just leaked a socket here, which is going to make it difficult to use that socket until you either reboot or find a way to close it properly before trying to create it again.
(code generates some warnings, but it is not severe and could be ignored for the time being).
You should do the following: 1) Understand your code well enough so you understand *why* the compiler issued the warning. 2) Correct your code so the compiler doesn't complain. It almost certainly understands C better than you do. gcc 9.2.1 emits one warning on the kernel module code at default warning levels. And it's one you *really* need to fix, because it indicates that you and the compiler are not on the same page about what types your variables are. Since it's going to go ahead and generate code based on what types *it* thinks your variables are, you will have nothing but pain and anguish debugging if you thought they were some other type.... In fact, you may want to compile the kernel module with 'make W=1' to get more warnings. If your system has sparse, you should use 'make W=1 C=1'. And all the warnings this generates are things that shouldn't be seen in clean kernel code. I didn't bother looking closely at your userspace. I gave up when I saw this: 14 int sock_fd; (...) 68 void user_space_receiver() 69 { (...) 96 user_space_receiver(sock_fd); There's 2 basic ways to pass a variable to a function. You're trying to use both of them here. Pick one and use it properly. Oh - and there's no possible way to reach the close(sock_fd); on line 77, because the rest of the function infinite loops without a break. At the very least, you should be checking the return code from recvmsg() and exiting the while(1) loop if there's an issue. Bottom line: You need to get a *lot* more experience writing proper C code in userspace before you try to write kernel code.
Thank you very much. I am trying to rewrite the code. and fix these issues. On Tue, Nov 5, 2019 at 7:43 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Tue, 05 Nov 2019 17:59:43 +0900, Irfan Ullah said:
Thank you for the response. Attached are the files for kernel-user spaces communication.
//when I remove this wait the code does not work msleep(3000);
If your code doesn't work, but sticking in random delays makes it start working, you almost certainly have a race condition or synchronization issue that should be fixed using proper locking.
void hello_exit(void) { //netlink_kernel_release(nl_sk);
Congratulations. You just leaked a socket here, which is going to make it difficult to use that socket until you either reboot or find a way to close it properly before trying to create it again.
(code generates some warnings, but it is not severe and could be ignored for the time being).
You should do the following: 1) Understand your code well enough so you understand *why* the compiler issued the warning. 2) Correct your code so the compiler doesn't complain. It almost certainly understands C better than you do.
gcc 9.2.1 emits one warning on the kernel module code at default warning levels. And it's one you *really* need to fix, because it indicates that you and the compiler are not on the same page about what types your variables are. Since it's going to go ahead and generate code based on what types *it* thinks your variables are, you will have nothing but pain and anguish debugging if you thought they were some other type....
In fact, you may want to compile the kernel module with 'make W=1' to get more warnings. If your system has sparse, you should use 'make W=1 C=1'.
And all the warnings this generates are things that shouldn't be seen in clean kernel code.
I didn't bother looking closely at your userspace. I gave up when I saw this:
14 int sock_fd; (...) 68 void user_space_receiver() 69 { (...) 96 user_space_receiver(sock_fd);
There's 2 basic ways to pass a variable to a function. You're trying to use both of them here. Pick one and use it properly.
Oh - and there's no possible way to reach the close(sock_fd); on line 77, because the rest of the function infinite loops without a break. At the very least, you should be checking the return code from recvmsg() and exiting the while(1) loop if there's an issue.
Bottom line: You need to get a *lot* more experience writing proper C code in userspace before you try to write kernel code.
-- *Best Regards,* *Mr. Irfan Ullah* PhD Candidate Data and Knowledge Engineering(DKE) Lab Department of Computer Science and Engineering Kyung Hee University, South Korea. +82-010-591-51651 <+82%2010-3877-8867> sahibzada.iu@gmail.com sahibzada_irfanullah
participants (3)
-
Greg KH -
Irfan Ullah (울라 이르판) -
Valdis Klētnieks