Netlink socket returns NULL in vmx.c kernel file

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191105/a6e3a96c/attachment-0001.sig>