Em qua., 16 de dez. de 2020 às 10:14, Vladimir Homutov <v...@nginx.com> escreveu:
> 16.12.2020 09:41, 张翔 пишет: > > # HG changeset patch > > # User Zhang Xiang <hawkxiang....@gmail.com > > <mailto:hawkxiang....@gmail.com>> > > # Date 1608099124 -28800 > > # Wed Dec 16 14:12:04 2020 +0800 > > # Node ID a685d9c04acdb4ec71fd9f176415917c217af630 > > # Parent 82228f955153527fba12211f52bf102c90f38dfb > > Mail: accept4() support SOCK_CLOEXEC flag > > > > The close-on-exec flag on the new FD can be set via SOCK_CLOEXEC > > > > diff -r 82228f955153 -r a685d9c04acd auto/unix > > --- a/auto/unix Tue Dec 15 17:41:39 2020 +0300 > > +++ b/auto/unix Wed Dec 16 14:12:04 2020 +0800 > > @@ -510,7 +510,7 @@ > > ngx_feature_incs="#include <sys/socket.h>" > > ngx_feature_path= > > ngx_feature_libs= > > -ngx_feature_test="accept4(0, NULL, NULL, SOCK_NONBLOCK)" > > +ngx_feature_test="accept4(0, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC)" > > . auto/feature > > > > if [ $NGX_FILE_AIO = YES ]; then > > diff -r 82228f955153 -r a685d9c04acd src/event/ngx_event_accept.c > > --- a/src/event/ngx_event_accept.c Tue Dec 15 17:41:39 2020 +0300 > > +++ b/src/event/ngx_event_accept.c Wed Dec 16 14:12:04 2020 +0800 > > @@ -57,7 +57,7 @@ > > > > #if (NGX_HAVE_ACCEPT4) > > if (use_accept4) { > > - s = accept4(lc->fd, &sa.sockaddr, &socklen, SOCK_NONBLOCK); > > + s = accept4(lc->fd, &sa.sockaddr, &socklen, SOCK_NONBLOCK | > > SOCK_CLOEXEC); > > } else { > > s = accept(lc->fd, &sa.sockaddr, &socklen); > > } > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > just realized you are talking about accepted sockets. > Why do you think it is useful? Normally we don't fork workers and don't > exec anything. > Sorry for meddling. While we wait for a response, I would like to include just for help. *O_CLOEXEC *(since Linux 2.6.23) Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) <https://man7.org/linux/man-pages/man2/fcntl.2.html> *F_SETFD *operations to set the *FD_CLOEXEC *flag. Note that the use of this flag is essential in some multithreaded programs, because using a separate fcntl(2) <https://man7.org/linux/man-pages/man2/fcntl.2.html> *F_SETFD *operation to set the *FD_CLOEXEC *flag does not suffice to avoid race conditions where one thread opens a file descriptor and attempts to set its close-on-exec flag using fcntl(2) <https://man7.org/linux/man-pages/man2/fcntl.2.html> at the same time as another thread does a fork(2) <https://man7.org/linux/man-pages/man2/fork.2.html> plus execve(2) <https://man7.org/linux/man-pages/man2/execve.2.html>. Depending on the order of execution, the race may lead to the file descriptor returned by *open*() being unintentionally leaked to the program executed by the child process created by fork(2) <https://man7.org/linux/man-pages/man2/fork.2.html>. (This kind of race is in principle possible for any system call that creates a file descriptor whose close-on-exec flag should be set, and various other Linux system calls provide an equivalent of the *O_CLOEXEC *flag to deal with this problem.) Ranier Vilela
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
