Re: upcalls from kernel code to user space daemons

[Oliver Neukum <oliver@neukum.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 15. Juni 2004 00:54 schrieb Steve French:
> On Mon, 2004-06-14 at 16:40, Oliver Neukum wrote:
> > > > 1) getHostByName:  when the kernel cifs code detects a server crashes
> > > > and fails reconnecting the socket and the kernel code wants to see if
> > > > the hostname now has a new ip address.
> > 
> > Is that possible at all? It looks like that might deadlock in the page
> > out code path.
> > 
> 
> Yes - since an upcall (indirectly) to a different process while in write
> could cause writepage to write out memory to a mount - which could hang
> if on an already dead tcp session, this (reconnection - failover to new
> ip address if the server ip address changes after failure) may be too
> risky to do in the context of writepage, but there may be a way to keep
> refusing to do writepage while in the midst of this harder form of mount
> reconnection - which isn't likely to be any worse than not
> reconnecting.  Fortunately, most tcp reconnection cases are much
> simpler.

Well, unless you want to mlock() all libraries connected with name
resolution or code dns in kernel, you'll have to either fail the io, which
is bad, or use a fallback that is local. I suggest that you write the block
in question to a local disk (swap space?) and fire of a user space helper
asynchronously. That helper then could reestablish the connection.

	Regards
		Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAzrwUbuJ1a+1Sn8oRAv2kAJ444nIrog/fnOPqlxTCAjAnaHtDUQCePe15
cGBjATSxNNRhCHGplhV703o=
=kjJe
-----END PGP SIGNATURE-----