Several race conditions in chardev.c? about lkmpg HOT 6 CLOSED

@jserv respectfully, the problem with:

static char msg[BUF_LEN];

... in chardev.c still exists. As I understand, device_* can be called concurrently which will cause concurrent access to msg and memory corruption as result. Unless there is something I don't know about how Linux kernel modules work. In the latest case I believe it should be clarified in the text and in the comments to the code.

from lkmpg.

Reopen as per @afiskon requested. Under investigation.

from lkmpg.

I am testing the chardev.c on my machine and I think there is still some bug need to be fixed.

In my testing:
`[0] read 0 bytes.
[1] read 0 bytes.
[3] read 40 bytes. I already told you 1 times Hello world!

[2] read 40 bytes. I already told you 1 times Hello world!

[4] read 0 bytes.
[3] read 40 bytes. I already told you 1 times Hello world!

[0] read 0 bytes.
[1] read 40 bytes. I already told you 1 times Hello world!

[2] read 0 bytes.
[4] read 40 bytes. I already told you 1 times Hello world!
`
Sometime, the read function from user space will fail (can't get the message) because the "Offset" in the open file table is not correct.
They all use the same open file table entry so there will also have race condition if we update the offset before device_read() return the bytes_read.

from lkmpg.

I am testing the chardev.c on my machine and I think there is still some bug need to be fixed.

@YLowy, you should discussion in the thread of pull request #108 if you were referring to the offset specific changes.

from lkmpg.

Due to the offset which is hard to be managed, I think it is a good way to create a list for each reading tasks. The element of the list includes the task's PID and it's offset. So that the race condition in the open file table will not occur. Nevertheless, we still need to consider the list behavior when task close or lseek the device.

from lkmpg.

Close via #108

from lkmpg.