0

I've read that a lot can happen when mixing threads and forking and it should better be avoided. I'm finding myself in a situation where I don't have a choice and I receive a kernel-crash of my kernel-module.

My reduced test-case has 2 threads. One of it is doing ioctls to an open device-node in a loop. The other one is doing one fork, waits for the child to exit, which it does immediately. If I use pthread_atfork to synchronized my thread with the fork-call it is working.

Where can I look at to find out more on what happens during a fork on open file-descriptors which are currently executing an ioctl? What kind of corruption can happen?

EDIT: Andreas made me change my test case. Instead of having the child exiting immediatly I'm not waiting 10 seconds before exiting. I'm collecting all PID in the parent-process to later do a waitpid. I'm forking 100 times. If makes it crash after 2 or 3 forks.

Patrick B.
  • 11,773
  • 8
  • 58
  • 101

1 Answers1

1

There should be no problem caused by threading in that regard. There should especially be no kernel crashes.

From your description it sounds like you are writing your own kernel module that handles the file descriptor in question. Note that a forked process gets copies of all open file descriptors. When it exits it closes those.

It doesn't matter that it apparently does nothing but exit immediately, the close (and flush in file_operations) happens always. That is where you should be looking in your kernel code.

Andreas Bombe
  • 2,450
  • 13
  • 20
  • Thanks Andreas. I updated my test-case thanks to your idea of the close, but the problem persists. I'm unsure whether a close is done or not. I'm not receiving the `release`-syscall in my kernel-module when doing fork. – Patrick B. Apr 23 '14 at 08:17
  • @PatrickB. You will not get a release until the last close, i.e. not until there are no file descriptors left referring to that file. You should get a flush though. – Andreas Bombe Apr 23 '14 at 13:08