Bruce M Simpson wrote:
Or keep a generation count to detect pre-emption (the devstat code does this, amongst other things), and try again if you lost the race.
On further inspection, I'm pretty sure that sys/kern/subr_devstat.c is not correct.
In particular, sysctl_devstat writes out a node's data without holding the lock. (I believe this is the whole point of all the "generation count" machinery.) It seems possible for devstat_remove_entry to remove that entry, free the storage, and have that storage recycled just before it gets written out.
In this particular case, it means random kernel data gets written out from the kernel to userspace. (Which in some circles would be considered a security problem, though it's hard to see how anyone could possibly exploit it.)
Tim Kientzle
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
