The headers under
/usr/include/linux and under
/usr/include/asm* are distributed with the Linux kernel. The other headers (
/usr/include/bits/*.h, and many more) are distributed with the C library (the GNU C library, also known as glibc, on all non-embedded Linux systems). There's a little explanation in the glibc manual.
/usr/include/asm should contain the headers that were used when compiling the C library, not the headers from the running kernel. Otherwise, if some constants or data structures changed, there will be an inconsistency between the compiled program and the C library, which is likely to result in a crash or worse. (If the headers match the C library but the C library doesn't match the kernel, what actually happens is that the kernel is designed to keep a stable ABI and must detect that it's called under a different ABI and interpret syscall arguments accordingly. The kernel must do this for statically compiled programs anyway.)
I remember a heated debate between Debian and Red Hat a while (a decade?) ago on the
/usr/include/linux issue; apparently each side is sticking to its position. (As far as I understand it, Debian is right, as explained above.) Debian currently distributes
/usr/include/linux and friends in the
linux-libc-dev package, which is compiled from kernel sources but not upgraded with the kernel. Kernel headers are in version-specific packages providing the
linux-headers-2.6 metapackage; this is what you need to compile a module for a particular kernel version.
The package you're looking for is the C library headers. I don't know what it's called, but you can find out with
yum provides /usr/include/sys/types.h.