[systemd-devel] [PATCH] Circumvent autofs_v5_packet_union size bug
raven at themaw.net
Mon Sep 19 20:36:56 PDT 2011
On Mon, 2011-09-19 at 22:47 +0200, Lennart Poettering wrote:
> On Fri, 16.09.11 14:09, Thomas Meyer (thomas at m3y3r.de) wrote:
> > the size of autofs_v5_packet_union is 300 bytes on x86 and 304 bytes on x86_64 kernels.
> > when running systemd (x86) on an x86_64 kernel this leads to a hang in automount_fd_event->loop_read
> > as a second fd_event is trigged for the remaining 4 bytes. but the loop_read tries to read
> > 300 bytes again. adapt the packet size dynamically to architecture we are running on.
> Humm. Just reading more is not really sufficient, if the fields might be
The problem isn't internal structure alignment it's the total structure
size requiring 8 byte alignment due to the presence of a 64 bit field in
I did try to get this right in the first place but miscalculated and
didn't notice it until it had been in operation for sufficient time to
make it a bad idea to change.
> This is a bug in the kernel, and it should be fixed in the kernel (which
> would mean the kernel folks have to define a new version of this
> struct/ioctl which fixes this). If that's defined we can then add
> support for this into systemd. Could you file a bug about this please on
> the kernel bugzilla? (please cc me, or post the url here!)
Yes, it is a mistake that I made but it is a bad idea to change
something that will cause widespread failure of existing binaries and
that's why the discrepancy persists and will continue to do so.
I chose to compensate for it in user space and to advise anyone that
encountered the problem on how to handle it and I have had no reports of
problems in autofs since I added the size calculation (which was a long
time ago now).
> How does the autofs client package deal with this problem?
The function in this patch is what I use in autofs.
> I am sorry but I am pretty sure I want to keep the compat kludges for
> broken things in systemd at a minimum, adding such a work around looks
> like the wrong way to me. We generally try to fix problems where they
> are these days, not where we notice them.
Sure, it is unfortunate but, as far as the autofs kernel module is
concerned the decision about this was made a long time ago and, yes it
isn't what we want but the breakage it would have caused then and the
breakage it would cause now is too great.
Lets not forget what the actual problem is.
The mismatch only occurs where the compiled binary arch is different
from the installed system arch. For example one needs to be using an
i386 (or i686 or similar) binary on an x86_64 installed system or
similar mismatch which isn't the common case either.
More information about the systemd-devel