Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752362AbaJBL4Q (ORCPT ); Thu, 2 Oct 2014 07:56:16 -0400 Received: from mail-qc0-f179.google.com ([209.85.216.179]:51242 "EHLO mail-qc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751176AbaJBL4O convert rfc822-to-8bit (ORCPT ); Thu, 2 Oct 2014 07:56:14 -0400 MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <542D1726.3040801@draigBrady.com> References: <9d050a2db4f9cf68cd6cb038f16cccb0f73c6e66.1411562410.git.ydroneaud@opteya.com> <542481B3.8070300@gmx.de> <1411721898.7778.18.camel@localhost.localdomain> <542666B2.9080700@gmx.de> <1411980555-10818-1-git-send-email-ydroneaud@opteya.com> <20141001153621.65e9258e65a6167bf2e4cb50@linux-foundation.org> <1412230855.28184.5.camel@localhost.localdomain> <1412236349-30035-1-git-send-email-ydroneaud@opteya.com> <542D1726.3040801@draigBrady.com> From: "Michael Kerrisk (man-pages)" Date: Thu, 2 Oct 2014 13:55:53 +0200 Message-ID: Subject: Re: [PATCH] fanotify: add a flag to allow setting O_CLOEXEC on event fd To: =?UTF-8?Q?P=C3=A1draig_Brady?= Cc: Yann Droneaud , Andrew Morton , Heinrich Schuchardt , Eric Paris , Richard Guy Briggs , Al Viro , lkml , "linux-fsdevel@vger.kernel.org" , stable@vger.kernel.org, Linux API , Jan Kara , Lino Sanfilippo , Valdis Kletnieks Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 2, 2014 at 11:13 AM, Pádraig Brady 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/