[patch] Re: smbmount problem

[Michael H. Warfield]

Paul enscribed thusly:
> I have put together a patch that should correct both the autofs race and

	Warning!  If you use this patch and you do not implement the
fix for the deadly embrace, you will cause smbmount processes to hang
in a deadly embrace.  You have to reboot in order to clear the mount
points.

> the problem with the kernel getting the wrong pid. This has nothing to do
> with glibc's uid_t being 32 bits and the kernel's being 16.

	True...  That was only an smbumount problem.  I already have a
request into the kernel list to fix the error in smb_fs.h that is causing
this.

> This patch changes smbmount's behavior so that it first daemonizes, then
> the child attempts the final ioctl to the kernel to complete the mount.
> The parent does a "waitpid" on the child, and catches SIGTERM. If the
> child finishes the mount without a problem then the parent is killed with
> "SIGTERM" and exits with a return value of 0. If the child has a problem
> with the final ioctl, then it exits, the parent catches this, and returns
> with a return value of 1, signaling an error (consistant with the rest of
> smbmount).

> Result: It works with autofs (tested - no more race), and the kernel gets
> the proper PID of the process handling it. Yay.

	If you didn't fix the setsid problem you could not have properly
tested it against autofs.  I've already compared notes with HPA (author
of autofs) and determined the problem.  There is a determinant deadly
embrace.  It doesn't work with autofs unless you fix this problem!  If
you don't fix this problem, a hung smbmnt process will lock up the mount
point until you reboot.

> Paul Laufer

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!