Re: setsockopt - SO_REUSEADDR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26/07/06, Chinmaya Mishra <chinmaya4@xxxxxxxxx> wrote:

 Hi all,

 I am creating a socket in kernel.

Why?

Just as opening files from kernel space is a bad idea, opening network
sockets from kernel space is also a bad idea - there's no fixed
process context for the socket...
Why do you need this and why can't you do it in user space?

It is able to bind. But after abnormal
 termination of the module, I am not able to bind the socket once again.

"Abnormal termination of the module"? you mean "rmmod -f" ?  If you
forcefully remove a module from the kernel then all bets are off -
there may be issues with memory your module allocated that it didn't
get a chance to free, you can have all sorts of fun with locks, global
variables/structures you have changed partially may lead to problems
etc etc etc...


Here i use

[snip]

 It throwing the following error
     Error in set socket opt for SO_REUSEADDR
     Could not bind to socket, error = 98


 Can you tell me what i am missing. Just I want to reuse the bind same
address once again in the
 same port.

If you forcibly removed the module, how on earth is the kernel
supposed to know the socket is no longer in use? Your module didn't
get a chance to clean up properly... In userspace the kernel will take
care of releasing resources used by an application when it dies. That
is *NOT* the case for kernel code.

Why, again, was it that this had to be done in kernel space ?

--
Jesper Juhl <jesper.juhl@xxxxxxxxx>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux