[PATCH] Unix datagram socket messaging
Volker Lendecke
Volker.Lendecke at SerNet.DE
Wed Apr 16 04:43:57 MDT 2014
On Wed, Apr 16, 2014 at 12:00:04PM +0200, Stefan (metze) Metzmacher wrote:
> Hi Volker,
>
> > https://git.samba.org/?p=vl/samba.git/.git;a=shortlog;h=refs/heads/unix-msg
> >
> > contains the result of Jeremy's preliminary review of the
> > unix datagram based messaging code for source3.
> >
> > This is the request for formal review and push to master.
>
> The notify patches seem to be independent, can you move them to be the
> first patches?
They are not entirely independent. They are not necessary
with the current messaging, because we handle messages
always before the client requests. I do not want to put in
additional complexity to the notify code before it is clear
that the rest of the patches can go in at all.
> The same applies to "printing_cups: Call the msg_ctx destructor on exit"
> and "smbd: Call the msg_ctx destructor for background jobs".
Same here. They are not necessary without the rest of the
patches and just add complexity.
> iov_buf* can also be added first and then used in the unix_msg code
> instead of the static copy.
I want to avoid making unix_msg depend on the rest of Samba,
just as I want to make for example pthreadpool independent.
If you think this is overkill, I can rewrite this code to
make use of the tevent_req infrastructure and the rest of
Samba. Do you want me to do this?
> They all have "Reviewed-by: Stefan Metzmacher <metze at samba.org>"
>
> I haven't fully reviewed the real changes yet, but have some initial
> comments:
>
> Can we pass tevent_context to poll_funcs_init_tevent() instead of
> using: func.private_data = ev; in the caller?
Yes, I will do that.
> Are we sure we don't get problems when having all messaging sockets in
> just one subdirectory?
My assumption is that by now all sane file systems have
hashed directories and thus direct access should be fast.
Also, we should not have more than a few thousand sockets
per node. Is this a problem for modern file systems? If so,
I can certainly convert this to a hashing scheme with
256/256 subdirectories.
> There're environments with just winbindd running, so we might need a
> periodic
> cleanup run not only in smbd.
Ok, I will add that.
>
> In
> https://git.samba.org/?p=vl/samba.git/.git;a=commitdiff;h=777954434bb7404659fbb7f519a4069b1100c400
> we have
>
> + struct sockaddr_un addr = { 0, };
>
> ...
>
> + ret = bind(ctx->sock, (struct sockaddr *)&addr,
> sizeof(addr));
>
> I think we should cast with (struct sockaddr *)(void *)&addr, in order
> to avoid
> strict aliasing warnings on some systems.
The correct way to avoid this is to do a memcpy. I will
convert to that.
> After socket() we should set FD_CLOEXEC and O_NONBLOCK similar to
> tsocket_bsd_common_prepare_fd() or set_blocking() and
> smb_set_close_on_exec().
> MSG_DONTWAIT might not be available everywhere.
Ok, I will change that to not use MSG_DONTWAIT.
> + if (errno != EWOULDBLOCK) {
>
> may need some more magic and also check for EAGAIN,
> see tsocket_bsd_error_from_errno() or commit
> f5a3d74264abb25009e73b1b35d62db34fa62343.
> ... ok, I just found that it's fixed in
> https://git.samba.org/?p=vl/samba.git/.git;a=commitdiff;h=325e62cbb116abdec7cf1466862bd12ecd42224e
> I think we should squash that and also this one
> https://git.samba.org/?p=vl/samba.git/.git;a=commitdiff;h=d44c82a1edddb0d838702e15e00538faae9386bc
>
> + unlink(ctx->path);
>
> We may need to check that ctx->path is not an empty string?
Ok, thanks, will do those changes.
Volker
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de
More information about the samba-technical
mailing list