| |||||||||||||
Magic numbersMagic numbersPosted Apr 30, 2012 21:16 UTC (Mon) by man_ls (subscriber, #15091)In reply to: Fixing broken userspace is NOT the kernel's job by drag Parent article: Fixing the unfixable autofs ABI But why check only for exactly 300 bytes? It would be understandable if systemd would check that the size of the data is >=300. That way there would be room to add padding or even new fields at the end, if needed.
(Log in to post comments)
Magic numbers Posted Apr 30, 2012 21:19 UTC (Mon) by felixfix (subscriber, #242) [Link]
Might be just general paranoia, to catch changes it doesn't know about. It won't catch all since there's no check for the layout of the data, but if someone adds or removes a member, or changes the size of some, it has a chance of noticing.
Magic numbers Posted May 1, 2012 8:03 UTC (Tue) by mjt (guest, #1515) [Link]
It is not a magic number, it is sizeof(kernel packet), which turned out to be different on 32bit and 64bit. It is the unit of data kernel exchanges data with usespace, it is the protocol definition. The protocol itself wasn't designed properly, that's the whole issue.
Now, reading just 300 bytes (size of that packet on 32bit userspace) instead of 304 bytes which a 64bit kernel sent to userspace does the trick, but the pipe buffer now holds 4 bytes, which will be read by userspace as a NEW packet. Even if new packet actually arrives, for the userspace the result will be complete garbage, since the packet boundary got lost.
At any rate, no userspace trick will fix already released versions of userspace applications, which is the whole point. Yes it could be made differently, but what's done is done and we don't want to break it.
Magic numbers Posted May 1, 2012 18:34 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
with the new packetized interface if you read 300 bytes, the other 4 bytes are forever lost, so the next read will get the correct packet boundary.
|
|||||||||||||