I'm also seeing this (didn't report; tainted kernel, though I now have another box set up with an untainted kernel to play with)
I grabbed the SRPM and built myself a kernel-3.3.2-3.fc17.x86_64.rpm
Alas, I can't try my 100% reliable reproducer of "hit the New Message button in kmail" because this kernel gives me my NFS home directory owned by an unfeasibly large UID :-)
Under 3.3.0-8.fc17.x86_64 the files are owned by 'tim' but under kernel-3.3.2-3.fc17.x86_64 it's someone called 4294967294 with GID 4294967294. Which would be a 32-bit -2 which since uid_t is unsigned 32-bit, could be a signed return code cast where it oughtn't.
I know about getting /etc/idmapd.conf correct. I can flip back and forth between the states by rebooting and selecting the different kernels with no other change.
I'm also seeing this (didn't report; tainted kernel, though I now have another box set up with an untainted kernel to play with)
I grabbed the SRPM and built myself a kernel- 3.3.2-3. fc17.x86_ 64.rpm
Alas, I can't try my 100% reliable reproducer of "hit the New Message button in kmail" because this kernel gives me my NFS home directory owned by an unfeasibly large UID :-)
Under 3.3.0-8.fc17.x86_64 the files are owned by 'tim' but under kernel- 3.3.2-3. fc17.x86_ 64 it's someone called 4294967294 with GID 4294967294. Which would be a 32-bit -2 which since uid_t is unsigned 32-bit, could be a signed return code cast where it oughtn't.
I know about getting /etc/idmapd.conf correct. I can flip back and forth between the states by rebooting and selecting the different kernels with no other change.