Re: [PATCH v2] Introduce a version6 of autofs interface, to fix design error.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Fri, Apr 27, 2012 at 12:24 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: > > If you can pull that off, it would certainly work and be the best > solution. > > BTW, this has happened before, we had this same problem passing data > over netlink sockets. And since it's packetized already we had a > slightly easier time dealing with it. Ok, so here's a fairly quick hack. NOTE! I haven't actually tested this, because I don't use autofs (well, not knowingly - maybe I have a machine that actually does). What it does is add a new "packetized" flag to pipes, which does two simple things: - do not merge write data in pipe buffers when writing - when reading, consider a pipe buffer to be "spent" when any of the data has been read Of course, if you write more than PIPE_BUFFER bytes, the packetization doesn't work, but hey, if you do that, it's your own damn problem. Then, this just makes (for debugging!) autofs always write eight extra bytes of garbage (NOTE NOTE NOTE! This will write uninitialized data, so this is literally just for debugging this particular issue), so that if the whole "kernel writes a few bytes extra" approach with pipe packetization doesn't work, you would see it even on native 32-bit or 64-bit mode, without having to even test the special case of "32-bit automount binary on a 64-bit kernel". So *anybody* who uses autofs can test this patch and see if autofs still works for them despite the extra padding on the write. So note the "+8" in autofs_v5_packet_size(). It's there on purpose, but it needs to be removed for actual final results if this works for testing. Comments? The patch looks fairly simple. The "packetized pipe" might even be useful for other users and maybe we might want to expose it as an actual pipe fcntl, but right now the only thing that sets that flag is autofs. Does this even work? I might well have missed some obvious thing, this was put together pretty quickly, but I think the *concept* may be the right approach to this whole mess. (And yes, we could probably just pack the "struct pipe_inode_info" better. We don't really need 32 bits for the pipe writer count etc. But to make the patch simple, I just added a whole new bitfield, which will just grow that silly structure). Linus
Description: Binary data