On Thu, Oct 2, 2014 at 11:13 AM, Pádraig Brady <P@xxxxxxxxxxxxxx> wrote: > On 10/02/2014 08:52 AM, Yann Droneaud wrote: >> In order to not potentially break applications which were >> requesting O_CLOEXEC on event file descriptors but which >> actually need it to be not effective as the kernel currently >> ignore the flag, so the file descriptor is inherited accross >> exec regardless of O_CLOEXEC (please forgive me for the >> wording), this patch introduces FAN_FD_CLOEXEC flag to >> fanotify_init() so that application can request O_CLOEXEC >> to be effective. >> Newer application would use FAN_FD_CLOEXEC flag along >> O_CLOEXEC to enable close on exec on newly created >> file descriptor: >> >> fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK|FAN_FD_CLOEXEC, >> O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME); > > Ugh really? > IMHO there should be widespread or at least known breakage with > O_CLOEXEC before adding messiness like this. > It seems surprising to me that apps that would depend on > O_CLOEXEC being ineffective. > > please reconsider this one. Agreed. The number of applications for which there are silent (not *yet* observed) breakages because O_CLOEXEC is not working as expected is likely rather larger than the set of applications that randomly specify O_CLOEXEC and then somehow get broken as a result. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
