From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93917 invoked by alias); 18 May 2017 20:00:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 93706 invoked by uid 89); 18 May 2017 20:00:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=relaxing, Hx-languages-length:1143 X-HELO: homiemail-a119.g.dreamhost.com Subject: Re: [PATCH] libio: Avoid dup already opened file descriptor [BZ#21393] To: Adhemerval Zanella , libc-alpha@sourceware.org Cc: Carlos O'Donell References: <1493996954-14556-1-git-send-email-adhemerval.zanella@linaro.org> From: Siddhesh Poyarekar Message-ID: <352a1abe-d4ba-322f-ed9d-158f7cd56e8e@gotplt.org> Date: Thu, 18 May 2017 20:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00567.txt.bz2 On Friday 19 May 2017 01:13 AM, Adhemerval Zanella wrote: > I think for BZ#21393 we won't get any sufficient conforming implementation > with proper kernel help or without relaxing the POSIX definition to also > allow this kind of errno. So I still think that checking for EBUSY and > returning it is still the correct approach. Specially because for the cases > where it fails then application might still seeing spurious issue due freopen > returning a valid return code but without dupping correctly the file > descriptor. OK, then this would require a NEWS item declaring that freopen behaviour is fixed and that its failure can now also set errno as EBUSY. Maybe the man page needs updating as well. > Also I think for proper underlying kernel support it would potentially > require dup3 to indefinitely block (which still be even more troublesome due > underlying FS like NFS that might timeout). I would require to extend dup3 > semantic, possible making it a cancelable entrypoint, and imho I think kernel > won't take this path lightly. They don't. Siddhesh