Back porting the 3.3 change to current stable kernels was not a goodidea IMO and I probably should have NAKed the one that I actually saw,which was devoid of version btw.

The change came about because there was a complaint about me not wantingto fix this in the kernel, but wanting to continue using the user spaceworkaround. But it was insisted that it be fixed in the kernel, and soit was done.

Consequently people will encounter this gotcha sooner or later and willneed to apply a patch to resolve it. The back port to stable kernelsjust means it's sooner rather than later.

I have already told you that I will need to provide a (updated, sincethere is already a commit in git that covers 3.3) patch for autofs. Ihaven't done that yet because I've been a little ill.

> > Kernel has been shipping with this brokeness for quite> some time, namely, since introduction of autofs4, dated> Mon Mar 27 01:14:55 2006 -0800 (commit 5c0a32fc2cd0).> > This is 6 whole years by now.> > Main userspace user of this interface adopted long ago> too, and has been in wide use for years as well.> > This kernel change, even if right in theory, actually> breaks all existing userspace which was working fine> for years.> > It looks like this is very much against main linux> principle of not breaking stuff even if the change is> "obviously right".> > So it pretty much looks like this very fix has to be> reverted in mainline and in all stable kernels. At least> that's what I'd do if you ask me.> > > Now, back to "pure userspace" solution.> > The kernel sends data to userspace, and the unit of> exchange is pretty small - this structure of either> 300 or 304 bytes. Can the read from userspace EVER> be partial, so that a fullread() function is necessary?> I'm not sure, but to me it looks like this fullread()> loop isn't needed in the first place, and just single> read() (maybe repeating it in case of EINTR) should> do the job already. This way, we either handle the> data we've read, if we think the amount we read> is sufficient, and the packet looks sane, or just> error out. The filename is at the end of the struct,> so actually there's no need to send whole struct from> kernel, it is sufficient for the kernel to write up> to the trailing zero, and userspace _may_ be able to> understand (and no, this is not what userspace expects> currently, so changing kernel to do so will break things --> I'm just saying what can be done in _userspace_).> > Now, we know that this sizeof(v5_packet) is designed> wrongly. But it is actually trivial for the userspace> to expect EITHER 300 bytes OR 304 bytes from the kernel --> again, all in one go. For it to work, extend the struct> with a padding at the end so it will be real 304 bytes,> and request reading of these 304 bytes, but handle the> read of 300 bytes too as successful.> > This way, it will work for BOTH "bad" and "good" kernel.> > Ofcourse it all breaks again if, in case of several> requests going from the kernel, kernel will batch them> into single larger read, so we'll lose packet boundary.> If that's the case, my "solution" does not work obviously.> > Still, the userspace may adapt again, by doing a probe,> forcing the kernel to send us a request before making> the mountpoint visible in the final location, checking> the size of the data kernel sends, and setting that> pkt_len variable to this value. Ugly, but it will let> the application to work in either case.> > But again, to me the current situation with outright> BREAKING of existing userspace is much uglier since> it affects many users instead of a single userspace> component...> > Thanks,> > /mjt> > >> Should 3.3 work? As far as I can see, it includes the> >> same change (which has been backported!), so it may have> >> the same _issue_...>