There was no problem if I just load and unload the module. But if I
write to the device using "ls > /dev/temp" and then unload the
module, I would get slab corruption.
you return different value as what has really been consumed:
if (*f_pos + count > MAX_DSIZE)
count1 = MAX_DSIZE - *f_pos;
if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
rv = -EFAULT;
goto wrap_up;
}
up (&temp_dev->sem);
*f_pos += count1;
return count;
may be it confuses the rest of kernel a bit?
I did this intentionally. Since my baby device buffer is fixed size,
I can't overflow the buffer. What I do is to cheat the application
(by pretending the bytes requested are copied to the device) so that
the application will be happy and do not hang on to send to the
device again and again. After all it is a test module for char device.
Nevertheless, I don't think this cheating has something to do with
the slab corruption.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]