From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 0119D203BD for ; Fri, 28 Oct 2016 05:52:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750961AbcJ1FwB (ORCPT ); Fri, 28 Oct 2016 01:52:01 -0400 Received: from dcvr.yhbt.net ([64.71.152.64]:39376 "EHLO dcvr.yhbt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750807AbcJ1FwA (ORCPT ); Fri, 28 Oct 2016 01:52:00 -0400 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 513A820193; Fri, 28 Oct 2016 05:51:59 +0000 (UTC) Date: Fri, 28 Oct 2016 05:51:59 +0000 From: Eric Wong To: Junio C Hamano Cc: Linus Torvalds , Jeff King , Git Mailing List , Lars Schneider , Johannes Schindelin Subject: Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC Message-ID: <20161028055159.GA25950@starla> References: <20161027102419.dbzigj7wtr355ofh@sigill.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Junio C Hamano wrote: > Junio C Hamano writes: > > > Linus Torvalds writes: > > > >> On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote: > >>> > >>> Would the best endgame shape for this function be to open with > >>> O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2) > >>> but ignoring an error from it, I guess? That would be the closest > >>> to what we historically had, I would think. > >> > >> I think that's the best model. Actually, I would flip the order of flags. O_CLOEXEC is more important from a correctness standpoint. > > OK, so perhaps like this. > > Hmph. This may not fly well in practice, though. > > To Unix folks, CLOEXEC is not a huge correctness issue. A child > process may hold onto an open file descriptor a bit longer than the > lifetime of the parent but as long as the child eventually exits, I'm not too familiar with C internals of git; but I know we use threads in some places, and fork+execve in others. If our usage of threads and execve intersects, and we run untrusted code in an execve-ed child, then only having cloexec on open() will save us time when auditing for leaking FDs. fcntl(fd, F_SETFD, O_CLOEXEC) is racy in if there are other threads doing execve; so I wouldn't rely on it as a first choice. So I suppose something like this: static int noatime = 1; int fd = open(... | O_CLOEXEC); ...error checking and retrying... if (fd >= 0 && noatime && fcntl(fd, F_SETFL, O_NOATIME) != 0) noatime = 0; return fd;