[Bug libc/10353] Methods for deleting all file descriptors greater than given integer

public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
@ 2014-07-01  7:54 ` fweimer at redhat dot com
  2019-04-12 14:46 ` adhemerval.zanella at linaro dot org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 13+ messages in thread
From: fweimer at redhat dot com @ 2014-07-01  7:54 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
  2014-07-01  7:54 ` [Bug libc/10353] Methods for deleting all file descriptors greater than given integer fweimer at redhat dot com
@ 2019-04-12 14:46 ` adhemerval.zanella at linaro dot org
  2020-11-03  9:34 ` [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom) stsp at users dot sourceforge.net
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 13+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2019-04-12 14:46 UTC (permalink / raw)
  To: glibc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 48709 bytes --]

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #8 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
To expand Florian answer, the main issue is that closefrom call is inherent
racy when trying to implement on libc without kernel support. 

The straightforward way to accomplish, and what python does, is to iterate over
all open file descriptors (either by walking through /proc/<pid>/fds or
sysconf(_SC_OPEN_MAX)) and issue a close on the file descriptor.

The problem with this approach does not guarantee on multithread environments
that a file descriptor would not be created in the iteration phase.  One option
would be to serialize a file descriptor creation routine (such as open, openat)
with close; but besides the fact it adds a large complexity and scalability
issue, it does not solve the issue of file descriptors being created by
bypassing the libc (by issuing the syscall instruction directly).

Both OpenBSD and Solaris implements it with syscalls, former with closefrom and
later with fcntl(..., F_CLOSEFROM). Also, Solaris documents its MT-unsafe. 

In fact, IMHO a closefrom syscall won't help much for posix_spawn. Current
implementation for Linux uses a clone(CLONE_VM, CLONE_VFORK) which means that
only the calling thread will be suspended while the helper thread issues
execlpe or _exit.  It means that a file action to issue a closefrom will also
be susceptible to race conditions in multi-thread environments.

That's why posix_spawn_file_actions_addclosefrom_np does not make much sense
unless you implement posix_spawn with fork+exec (which has its own scalability
issues).  The possible solutions are:

 1. Ensure all file descriptors are opened with O_CLOEXEC.

 2. Use a helper process to actually set up the required file descriptor close
steps and issue the target binary. This is in fact what OpenJDK does (check
src/java.base/unix/native/jspawnhelper/jspawnhelper.c and
src/java.base/unix/native/libjava/childproc.c).

So IMHO closefrom would be just a performance optimization on Linux, where
kernel will know exactly which file descriptor to close.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45272-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Apr 12 21:35:36 2019
Return-Path: <glibc-bugs-return-45272-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 113083 invoked by alias); 12 Apr 2019 21:35:35 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 113042 invoked by uid 48); 12 Apr 2019 21:35:32 -0000
From: "dimpase at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
Date: Fri, 12 Apr 2019 21:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dimpase at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: WONTFIX
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-10353-131-3HnVLG7PaZ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-10353-131@http.sourceware.org/bugzilla/>
References: <bug-10353-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00143.txt.bz2
Content-length: 508

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

--- Comment #9 from Dima Pasechnik <dimpase at gmail dot com> ---
The cpython problem with its current implementation is bad performance on
systems with large sysconf(_SC_OPEN_MAX) value (e.g. it's much bigger on
FreeBSD than it's on Linux). We actually plan to do a cpython PR which would
replace the loop with a call to closefrom() -- for systems where it's
available.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45273-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Apr 12 22:10:57 2019
Return-Path: <glibc-bugs-return-45273-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 98529 invoked by alias); 12 Apr 2019 22:10:56 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 98486 invoked by uid 48); 12 Apr 2019 22:10:53 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
Date: Fri, 12 Apr 2019 22:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: WONTFIX
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-10353-131-uwXLdN28xH@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-10353-131@http.sourceware.org/bugzilla/>
References: <bug-10353-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00144.txt.bz2
Content-length: 683

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

--- Comment #10 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Dima Pasechnik from comment #9)
> The cpython problem with its current implementation is bad performance on
> systems with large sysconf(_SC_OPEN_MAX) value (e.g. it's much bigger on
> FreeBSD than it's on Linux). We actually plan to do a cpython PR which would
> replace the loop with a call to closefrom() -- for systems where it's
> available.

AFAIK unfortunately for this case, there is no much glibc can do without proper
kernel support.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45274-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 06:25:01 2019
Return-Path: <glibc-bugs-return-45274-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 70605 invoked by alias); 14 Apr 2019 06:24:58 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 70507 invoked by uid 48); 14 Apr 2019 06:24:53 -0000
From: "tamuki at linet dot gr.jp" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug time/24453] New: Producing alternative representation for year with alternative numeric symbols
Date: Sun, 14 Apr 2019 06:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: time
X-Bugzilla-Version: 2.29
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tamuki at linet dot gr.jp
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-24453-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00145.txt.bz2
Content-length: 2215

https://sourceware.org/bugzilla/show_bug.cgi?id=24453

            Bug ID: 24453
           Summary: Producing alternative representation for year with
                    alternative numeric symbols
           Product: glibc
           Version: 2.29
            Status: NEW
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: tamuki at linet dot gr.jp
  Target Milestone: ---

In Japanese locale, it is possible to produce Japanese calendar date
and time representation with Chinese numerals as follows:

$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%mæœˆ%dæ—¥"
04æœˆ14æ—¥
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%Hæ™‚%Måˆ†%Sç§’"
11æ™‚23åˆ†31ç§’

$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%Omæœˆ%Odæ—¥"
å››æœˆåå››æ—¥
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%OHæ™‚%OMåˆ†%OSç§’"
åä¸€æ™‚äºŒåä¸‰åˆ†ä¸‰åä¸€ç§’

These representation are very commonly used in Japan, especially in
vertical writing.

However, Japanese calendar year can currently not be produced using
Chinese numeric symbols, because both the 'E' and 'O' modifiers can
not be applied to "%y" or "%Y" simultaneously:

$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%yå¹´"
19å¹´
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%Yå¹´"
2019å¹´
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%EC%Eyå¹´"
å¹³æˆ31å¹´
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%EY"
å¹³æˆ31å¹´
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%Oyå¹´"
åä¹å¹´
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%EC%OEyå¹´"
å¹³æˆ%OEyå¹´
$ LANG=ja_JP.UTF-8 date -d "2019-04-14 11:23:31" +"%OEY"
%OEY

The last two should be represented as follows:

å¹³æˆä¸‰åä¸€å¹´

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45275-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 11:03:14 2019
Return-Path: <glibc-bugs-return-45275-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 74273 invoked by alias); 14 Apr 2019 11:03:14 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 74234 invoked by uid 48); 14 Apr 2019 11:03:11 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/20972] Running libc.so.6 as an executable triggers IFUNC relocation ordering issues
Date: Sun, 14 Apr 2019 11:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-20972-131-Qo3SRWH42E@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20972-131@http.sourceware.org/bugzilla/>
References: <bug-20972-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00146.txt.bz2
Content-length: 408

https://sourceware.org/bugzilla/show_bug.cgi?id=20972

Marat Radchenko <marat at slonopotamus dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marat at slonopotamus dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45276-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 11:07:07 2019
Return-Path: <glibc-bugs-return-45276-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 95692 invoked by alias); 14 Apr 2019 11:07:07 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 94009 invoked by uid 48); 14 Apr 2019 11:07:04 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/13579] do_lookup_x may access dangling memory
Date: Sun, 14 Apr 2019 11:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.15
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: carlos_odonell at mentor dot com
X-Bugzilla-Target-Milestone: 2.16
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-13579-131-3OC51qsKVo@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13579-131@http.sourceware.org/bugzilla/>
References: <bug-13579-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00147.txt.bz2
Content-length: 408

https://sourceware.org/bugzilla/show_bug.cgi?id=13579

Marat Radchenko <marat at slonopotamus dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marat at slonopotamus dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45277-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 11:10:37 2019
Return-Path: <glibc-bugs-return-45277-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 33777 invoked by alias); 14 Apr 2019 11:10:37 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 33733 invoked by uid 48); 14 Apr 2019 11:10:34 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/13882] Cycle detection in dynamic loader is broken
Date: Sun, 14 Apr 2019 11:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.15
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.16
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-13882-131-YTqRrLxphL@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13882-131@http.sourceware.org/bugzilla/>
References: <bug-13882-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00148.txt.bz2
Content-length: 408

https://sourceware.org/bugzilla/show_bug.cgi?id=13882

Marat Radchenko <marat at slonopotamus dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marat at slonopotamus dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45278-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 11:16:49 2019
Return-Path: <glibc-bugs-return-45278-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 38267 invoked by alias); 14 Apr 2019 11:16:49 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 38243 invoked by uid 48); 14 Apr 2019 11:16:46 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/15309] dl_open_worker doesn't fully initialize seen array during init sort
Date: Sun, 14 Apr 2019 11:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: carlos at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-15309-131-6lI24dVuCQ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15309-131@http.sourceware.org/bugzilla/>
References: <bug-15309-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00149.txt.bz2
Content-length: 408

https://sourceware.org/bugzilla/show_bug.cgi?id=15309

Marat Radchenko <marat at slonopotamus dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marat at slonopotamus dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45279-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 12:48:21 2019
Return-Path: <glibc-bugs-return-45279-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 72498 invoked by alias); 14 Apr 2019 12:48:18 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 72401 invoked by uid 48); 14 Apr 2019 12:48:14 -0000
From: "dimpase at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
Date: Sun, 14 Apr 2019 12:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dimpase at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: WONTFIX
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-10353-131-egjvbS6PVW@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-10353-131@http.sourceware.org/bugzilla/>
References: <bug-10353-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00150.txt.bz2
Content-length: 336

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

--- Comment #11 from Dima Pasechnik <dimpase at gmail dot com> ---
libbsd does provide closefrom on Linux-I have not looked at what it actually
does...

https://packages.debian.org/source/sid/libbsd

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45280-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 14:44:46 2019
Return-Path: <glibc-bugs-return-45280-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 19015 invoked by alias); 14 Apr 2019 14:44:46 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 18969 invoked by uid 48); 14 Apr 2019 14:44:43 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
Date: Sun, 14 Apr 2019 14:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: WONTFIX
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-10353-131-fUgLB4aKXD@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-10353-131@http.sourceware.org/bugzilla/>
References: <bug-10353-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00151.txt.bz2
Content-length: 571

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

--- Comment #12 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Dima Pasechnik from comment #11)
> libbsd does provide closefrom on Linux-I have not looked at what it actually
> does...
> 
> https://packages.debian.org/source/sid/

It does exactly what I described earlier: interact over /proc/self/fd or
getconf [1].

[1] https://gitlab.freedesktop.org/libbsd/libbsd/blob/master/src/closefrom.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45281-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 14:47:01 2019
Return-Path: <glibc-bugs-return-45281-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 21351 invoked by alias); 14 Apr 2019 14:47:00 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 21314 invoked by uid 48); 14 Apr 2019 14:46:57 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/15311] _dl_sort_fini static deps can be violated by dynamic ones
Date: Sun, 14 Apr 2019 14:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-15311-131-ZaeTj887co@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15311-131@http.sourceware.org/bugzilla/>
References: <bug-15311-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00152.txt.bz2
Content-length: 408

https://sourceware.org/bugzilla/show_bug.cgi?id=15311

Marat Radchenko <marat at slonopotamus dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marat at slonopotamus dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45282-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 18:17:00 2019
Return-Path: <glibc-bugs-return-45282-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 69756 invoked by alias); 14 Apr 2019 18:17:00 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 68018 invoked by uid 48); 14 Apr 2019 18:16:57 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/15329] _dl_sort_fini and _dl_sort_init don't keep SCCs contiguous
Date: Sun, 14 Apr 2019 18:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-15329-131-7tYxqwI6zj@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15329-131@http.sourceware.org/bugzilla/>
References: <bug-15329-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00153.txt.bz2
Content-length: 408

https://sourceware.org/bugzilla/show_bug.cgi?id=15329

Marat Radchenko <marat at slonopotamus dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marat at slonopotamus dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45283-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 21:23:19 2019
Return-Path: <glibc-bugs-return-45283-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 22236 invoked by alias); 14 Apr 2019 21:23:19 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 18788 invoked by uid 48); 14 Apr 2019 21:23:15 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/15310] _dl_sort_fini is O(n^3) causing slow exit when many dsos
Date: Sun, 14 Apr 2019 21:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-15310-131-0iLgJzMESR@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15310-131@http.sourceware.org/bugzilla/>
References: <bug-15310-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00154.txt.bz2
Content-length: 1384

https://sourceware.org/bugzilla/show_bug.cgi?id=15310

--- Comment #25 from Marat Radchenko <marat at slonopotamus dot org> ---
(In reply to Don Hatch from comment #3)
> I'll submit it here in a day or two.

Hello from 2019. We're still suffering from O(n^3). Don, unfortunately you
haven't published your code anywhere (even if it still lacks an exhaustive set
of tests).

For those brave enough out there who would like to try solve this, here's a PDF
named "A Space-Efficient Algorithm for Finding Strongly Connected Components"
with non-recursive Tarjan SCC implementation:
http://homepages.ecs.vuw.ac.nz/~djp/files/IPL15-preprint.pdf

"Proposed initial patch" that is attached here is no longer needed because it
only moves code around that was done in

commit c2c299fd24e87b83c63191ff979d41a86b37d714
Author: Andreas Schwab <schwab@suse.de>
Date:   Tue Nov 7 15:24:19 2017 +0100

    Consolidate link map sorting

    Combine the four places where link maps are sorted into a single function.
    This also moves the logic to skip the first map (representing the main
    binary) to the callers.

So, there's currently only a single sorting function in elf/dl-sort-maps.c

BTW, has anyone tried looking at how other libcs do this sorting? Maybe there's
no need to reinvent the wheel?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45284-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Apr 14 21:49:47 2019
Return-Path: <glibc-bugs-return-45284-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 120130 invoked by alias); 14 Apr 2019 21:49:47 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 120051 invoked by uid 48); 14 Apr 2019 21:49:42 -0000
From: "marat at slonopotamus dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/17645] RFE: Improve performance of dynamic loader for deeply nested DSO dependencies.
Date: Sun, 14 Apr 2019 21:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marat at slonopotamus dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-17645-131-na2JNGuvWr@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17645-131@http.sourceware.org/bugzilla/>
References: <bug-17645-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00155.txt.bz2
Content-length: 1257

https://sourceware.org/bugzilla/show_bug.cgi?id=17645

--- Comment #11 from Marat Radchenko <marat at slonopotamus dot org> ---
(In reply to Paulo Andrade from comment #8)
> My question is, is some documentation that says
> that dsos must be kept together in the ordering?
> I mean, there are 2 correct results:
> 
> main a4 a3 b2 b1 a2 a1
> 
> and
> 
> main a4 a3 b2 a2 a1 b1
> 
> but if there is some specification that says
> it should have "b2 b1" together, then the patch
> is invalid, because it only breaks cycles and
> does ordering, and if there are no dependencies,
> it keeps it in the order it received the list
> to sort.

I'm not aware of any such spefication, but current glibc implementation does
keep direct dependencies together and this looks like A Good Thing.

#15310 suggest using Tarjan SCC for toposort and it is expected to keep direct
deps together.

With regard to your patch - what big-O complexity does it have? If I read the
code correctly, you recalculate (num_maps - num_seen) weights whenever you mark
link_map as seen. This is just a better than O(n^2). But the problem we're
talking about (toposort) is believed to be linear.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45285-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Apr 15 08:27:32 2019
Return-Path: <glibc-bugs-return-45285-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 21012 invoked by alias); 15 Apr 2019 08:27:31 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 20944 invoked by uid 48); 15 Apr 2019 08:27:28 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/24252] resolv/tst-resolv-ai_idn test failure with libidn2 2.1.1a
Date: Mon, 15 Apr 2019 08:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: 2.30
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: MOVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-24252-131-wQHcfwTbq5@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-24252-131@http.sourceware.org/bugzilla/>
References: <bug-24252-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00156.txt.bz2
Content-length: 436

https://sourceware.org/bugzilla/show_bug.cgi?id=24252

--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
libidn2 upstream now has an API trace test, based on the glibc test suite:

https://gitlab.com/libidn/libidn2/commit/6b75895913990dd91ab5c373e4c9d1977761f899

Hopefully, this will avoid future regressions in the glibc test suite.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45286-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Apr 15 12:57:14 2019
Return-Path: <glibc-bugs-return-45286-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 130115 invoked by alias); 15 Apr 2019 12:57:13 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 127213 invoked by uid 48); 15 Apr 2019 12:57:09 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/11754] RFE: dlopen of ET_EXEC file
Date: Mon, 15 Apr 2019 12:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.12
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-11754-131-NO7SVW39St@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-11754-131@http.sourceware.org/bugzilla/>
References: <bug-11754-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00157.txt.bz2
Content-length: 1945

https://sourceware.org/bugzilla/show_bug.cgi?id=11754

--- Comment #15 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to John Reiser from comment #14)
> (In reply to Florian Weimer from comment #13)
> > We cannot support this because it is not possible to perform correct
> > relocations if another executable has already been loaded.  There is also no
> > way to correctly execute the ELF constructors of the second executable.
> 
> Please give specific examples or explanations why success (or a
> recognizable, specific, and informative error code) is not possible.

Here is an example.  The first program is mylocaltime-export:

#include <stdio.h>
#include <time.h>

void
mylocaltime (time_t t)
{
  struct tm *tm = localtime (&t);
  printf ("tm_isdst (from other program): %d\n", tm->tm_isdst);
  printf ("daylight (from other program): %d\n", daylight);
}

int
main (void)
{
  return 0;
}

The second is mylocaltime-use:

#include <dlfcn.h>
#include <err.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

static void
mylocaltime2 (time_t t)
{
  struct tm *tm = localtime (&t);
  printf ("tm_isdst (from main program): %d\n", tm->tm_isdst);
  printf ("daylight (from main program): %d\n", daylight);
}

int
main (void)
{
  setenv ("TZ", "Europe/Berlin", 1);
  void *handle = dlopen ("./mylocaltime-export", RTLD_NOW);
  if (handle == NULL)
    errx (1, "dlopen: %s", dlerror ());
  void *func = dlsym (handle, "mylocaltime");
  if (func == NULL)
    errx (1, "dlsym: %s", dlerror ());
  void (*fptr) (time_t) = func;
  mylocaltime2 (1555332781);
  fptr (1555332781);
}

Running the latter produces on x86-64:

tm_isdst (from main program): 1
daylight (from main program): 1
tm_isdst (from other program): 1
daylight (from other program): 0

Such issues will be extremely difficult to debug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45287-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Apr 15 12:58:12 2019
Return-Path: <glibc-bugs-return-45287-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 34384 invoked by alias); 15 Apr 2019 12:58:12 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 32453 invoked by uid 48); 15 Apr 2019 12:58:08 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/24323] dlopen should not be able open PIE objects
Date: Mon, 15 Apr 2019 12:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.30
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-24323-131-fepr3lMMrn@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-24323-131@http.sourceware.org/bugzilla/>
References: <bug-24323-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2019-04/txt/msg00158.txt.bz2
Content-length: 274

https://sourceware.org/bugzilla/show_bug.cgi?id=24323

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
See bug 11754 comment 15 for an example why this change is desirable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-45288-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Apr 15 14:47:26 2019
Return-Path: <glibc-bugs-return-45288-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 113843 invoked by alias); 15 Apr 2019 14:47:26 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 113833 invoked by uid 89); 15 Apr 2019 14:47:26 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=3.7 required=5.0 testsºYES_50,DOS_OUTLOOK_TO_MX,FILL_THIS_FORM,HTML_MESSAGE,SPF_PASS,T_FILL_THIS_FORM_LONG autolearn=no version=3.3.1 spammy=H*x:12.0, H*UA:12.0, contacts, H*x:Office
X-HELO: ans.enewswriter.com
Received: from ans.enewswriter.com (HELO ans.enewswriter.com) (206.189.15.249) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Apr 2019 14:47:25 +0000
From: "Tia Costa" <tia@enewswriter.com>
To: <glibc-bugs@sourceware.org>
Subject: Cisco Live! 2018 Attendee Info
Date: Mon, 15 Apr 2019 14:47:00 -0000
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAANoZW+yq4TxOrO45Pzxj5v/CgAAAEAAAAL2CGDM/R2FJrKdFL8AgziUBAAAAAA==@enewswriter.com>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-SW-Source: 2019-04/txt/msg00159.txt.bz2
Content-length: 533

Hi,



Would you be interested in Cisco Live! 2018 attendee list?



We can provide you with 18,500 attendee contacts.



Each contact comes with First Name, Middle Name, Last Name, Phone, Fax,
Email Address,

Business Name, Job Title, Web Address/URL, Country and Zip Code.



Please let me know if you are interested and I shall get back to you with
the Pricing.



Best Regards,

Tia Costa | Demand Generation| B2bprolist




If you don't wish to receive our newsletters, reply back with " UN-SUBSCRIBE
" in subject line.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom)
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
  2014-07-01  7:54 ` [Bug libc/10353] Methods for deleting all file descriptors greater than given integer fweimer at redhat dot com
  2019-04-12 14:46 ` adhemerval.zanella at linaro dot org
@ 2020-11-03  9:34 ` stsp at users dot sourceforge.net
  2020-11-03  9:45 ` fweimer at redhat dot com
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 13+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-03  9:34 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

Stas Sergeev <stsp at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stsp at users dot sourceforge.net

--- Comment #19 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Hi.

What do you think about this closefrom() to only set
FD_CLOEXEC rather than to do the actual close()?
Seems more consistent to me.
- compatible with popen(), posix_spawn(), system() and co
as you can just do it before fork()
- does exactly what we need, and in a less invasive way -
don't we need to close files only at exec()?
- clearly underlines the fact that O_CLOEXEC should have
been on by default since the creation of posix, but its not.
So it fixes exactly that rather than working around that by
doing explicit close().

Just an idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom)
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2020-11-03  9:34 ` [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom) stsp at users dot sourceforge.net
@ 2020-11-03  9:45 ` fweimer at redhat dot com
  2020-12-16 16:39 ` crrodriguez at opensuse dot org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 13+ messages in thread
From: fweimer at redhat dot com @ 2020-11-03  9:45 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

--- Comment #20 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Stas Sergeev from comment #19)

> What do you think about this closefrom() to only set
> FD_CLOEXEC rather than to do the actual close()?
> Seems more consistent to me.
> - compatible with popen(), posix_spawn(), system() and co
> as you can just do it before fork()
> - does exactly what we need, and in a less invasive way -
> don't we need to close files only at exec()?

You can't set CLOEXEC safely before the fork, it would have to come after. 
There isn't much difference between closing and setting the flag directly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom)
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2020-11-03  9:45 ` fweimer at redhat dot com
@ 2020-12-16 16:39 ` crrodriguez at opensuse dot org
  2020-12-16 16:40 ` crrodriguez at opensuse dot org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 13+ messages in thread
From: crrodriguez at opensuse dot org @ 2020-12-16 16:39 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

Cristian Rodríguez <crrodriguez at opensuse dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crrodriguez at opensuse dot org

--- Comment #21 from Cristian Rodríguez <crrodriguez at opensuse dot org> ---
The linux kernel now has a close_range system call for this purpose. It would
be cool if glibc can provide both a syscall wrapper for close_range *AND*
closefrom implemented on top close_range in the linux target.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom)
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
                   ` (4 preceding siblings ...)
  2020-12-16 16:39 ` crrodriguez at opensuse dot org
@ 2020-12-16 16:40 ` crrodriguez at opensuse dot org
  2020-12-16 17:07 ` adhemerval.zanella at linaro dot org
  2021-07-08 17:21 ` adhemerval.zanella at linaro dot org
  7 siblings, 0 replies; 13+ messages in thread
From: crrodriguez at opensuse dot org @ 2020-12-16 16:40 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

--- Comment #22 from Cristian Rodríguez <crrodriguez at opensuse dot org> ---
(In reply to Stas Sergeev from comment #19)
> Hi.
> 
> What do you think about this closefrom() to only set
> FD_CLOEXEC rather than to do the actual close()?
> Seems more consistent to me.
> - compatible with popen(), posix_spawn(), system() and co
> as you can just do it before fork()
> - does exactly what we need, and in a less invasive way -
> don't we need to close files only at exec()?
> - clearly underlines the fact that O_CLOEXEC should have
> been on by default since the creation of posix, but its not.
> So it fixes exactly that rather than working around that by
> doing explicit close().
> 
> Just an idea.


What you request is now implemented with close_range(2) flag
CLOSE_RANGE_CLOEXEC

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom)
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
                   ` (5 preceding siblings ...)
  2020-12-16 16:40 ` crrodriguez at opensuse dot org
@ 2020-12-16 17:07 ` adhemerval.zanella at linaro dot org
  2021-07-08 17:21 ` adhemerval.zanella at linaro dot org
  7 siblings, 0 replies; 13+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2020-12-16 17:07 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #23 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Cristian Rodríguez from comment #21)
> The linux kernel now has a close_range system call for this purpose. It
> would be cool if glibc can provide both a syscall wrapper for close_range
> *AND* closefrom implemented on top close_range in the linux target.

The close_range seems a sensible addition to added as a syscall wrapper for
Linux, without any extra fallback, and returning ENOSYS on older kernel (as for
copy_file_range). From Florian message, he should be ok with a fallback to
/proc/self/fd if the syscall is not available; but this will make function not
fail-safe and add possible issues (as it was usual for multiple syscall
fallbacks we added previosuly).

I also agree that closefrom shouldbe added as a GNU extension, multiple system
have added it.

For posix_spawn extension, I think we can add a /proc/self/fd fallback that
sets FD_CLOEXEC for each; the spawn will fail if it can not be executed and it
is allowed by the interface.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom)
       [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
                   ` (6 preceding siblings ...)
  2020-12-16 17:07 ` adhemerval.zanella at linaro dot org
@ 2021-07-08 17:21 ` adhemerval.zanella at linaro dot org
  7 siblings, 0 replies; 13+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2021-07-08 17:21 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |2.34

--- Comment #24 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixed on 2.35 with the addition of close_range (Linux), closefrom, and
posix_spawn_file_actions_addclosefrom_np.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer
@ 2009-06-30 23:31 martinrb at google dot com
  2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
                   ` (4 more replies)
  0 siblings, 5 replies; 13+ messages in thread
From: martinrb at google dot com @ 2009-06-30 23:31 UTC (permalink / raw)
  To: glibc-bugs

Recent Solaris provides a way to delete all file descriptors
greater than a given integer, and provides a way to ask
posix_spawn to do so.  I believe glibc should implement these extensions.

Both of the big programs I have worked on, xemacs and openjdk,
have written their own way to do this.

extern int posix_spawn_file_actions_addclosefrom_np(
	posix_spawn_file_actions_t *file_actions,
	int lowfiledes);

extern void closefrom(int);

http://docs.sun.com/app/docs/doc/819-2243/posix-spawn-file-actions-addclosefrom-np-3c?l=ja&a=view

http://docs.sun.com/app/docs/doc/819-2243/closefrom-3c?l=ja&a=view

The functionality that has been added to glibc allowing FD_CLOSE_ON_EXEC
to be specified at time of creation of the fd does help (thank you)
but it is not sufficient for "open" programs like the JDK where 
arbitrary third party native code may be concurrently opening file 
descriptors while creating a subprocess.

-- 
           Summary: Methods for deleting all file descriptors greater than
                    given integer
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: martinrb at google dot com
                CC: glibc-bugs at sources dot redhat dot com

http://sourceware.org/bugzilla/show_bug.cgi?id=10353

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
  2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
@ 2009-06-30 23:52 ` roland at gnu dot org
  2009-07-01  5:58 ` drepper at redhat dot com
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 13+ messages in thread
From: roland at gnu dot org @ 2009-06-30 23:52 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From roland at gnu dot org  2009-06-30 23:52 -------
nscd.c does this by hand in a Linux-specific way, and it is trivial to implement
in libc on Hurd.  So this seems like a good addition.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10353

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
  2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
  2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
@ 2009-07-01  5:58 ` drepper at redhat dot com
  2009-07-01 22:22 ` martinrb at google dot com
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 13+ messages in thread
From: drepper at redhat dot com @ 2009-07-01  5:58 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From drepper at redhat dot com  2009-07-01 05:57 -------
No, it's a horrible idea.  The assumption that a program knows all the open file
descriptors is simply invalid.  The runtime (all kinds of libraries) can at any
point in time create additional file descriptors and indiscriminately calls for
trouble.  The correct way is to name the individual file descriptors the program
knows about and let the creator of the other file descriptors worry about the rest.

The reason nscd can do it the way it does it is simple: all the code used is
controlled by libc.  But that's a special case.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10353

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
  2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
  2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
  2009-07-01  5:58 ` drepper at redhat dot com
@ 2009-07-01 22:22 ` martinrb at google dot com
  2009-07-02  6:27 ` drepper at redhat dot com
  2009-07-02 16:15 ` martinrb at google dot com
  4 siblings, 0 replies; 13+ messages in thread
From: martinrb at google dot com @ 2009-07-01 22:22 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From martinrb at google dot com  2009-07-01 22:22 -------
Aside from the Solaris 10 precedent, other OSes have adopted
closefrom, apparently with the same behavior.

Here's OpenBSD:

http://www.openbsd.org/cgi-bin/man.cgi?query=closefrom&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

Here's NetBSD:

http://netbsd.gw.com/cgi-bin/man-cgi?closefrom++NetBSD-current

To provide more motivation, the idea is that you are in a
large multithreaded app that is swimming in a sea of unknown
file descriptors that may or may not have FD_CLOEXEC set,
you fork(), frob some file descriptors you care about,
and then need to close the rest.  You write your own buggy closefrom
or use the one provided by the system.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10353

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
  2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
                   ` (2 preceding siblings ...)
  2009-07-01 22:22 ` martinrb at google dot com
@ 2009-07-02  6:27 ` drepper at redhat dot com
  2009-07-02 16:15 ` martinrb at google dot com
  4 siblings, 0 replies; 13+ messages in thread
From: drepper at redhat dot com @ 2009-07-02  6:27 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From drepper at redhat dot com  2009-07-02 06:27 -------
(In reply to comment #3)
> Here's OpenBSD:
> [...]
> Here's NetBSD:
> [...]

This is *anything* but an argument in favor.


> To provide more motivation, the idea is that you are in a
> large multithreaded app that is swimming in a sea of unknown
> file descriptors that may or may not have FD_CLOEXEC set,

So, fix the code.  We have O_CLOEXEC support as well.  There is no reason to
work around buggy code and this interface *actively* prevents innovations by
usurping file descriptors.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=10353

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
  2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
                   ` (3 preceding siblings ...)
  2009-07-02  6:27 ` drepper at redhat dot com
@ 2009-07-02 16:15 ` martinrb at google dot com
  4 siblings, 0 replies; 13+ messages in thread
From: martinrb at google dot com @ 2009-07-02 16:15 UTC (permalink / raw)
  To: glibc-bugs

------- Additional Comments From martinrb at google dot com  2009-07-02 16:14 -------

>> To provide more motivation, the idea is that you are in a
>> large multithreaded app that is swimming in a sea of unknown
>> file descriptors that may or may not have FD_CLOEXEC set,

>So, fix the code.  We have O_CLOEXEC support as well.  There is no reason to
>work around buggy code and this interface *actively* prevents innovations by
>usurping file descriptors.

For many applications, there is no way in practice to control all the 
code running in the same address space.  This is especially true for
"platforms" like java, where arbitrary user-created shared libraries
are loaded and executed at runtime.

The idea of permitting innovations that use file descriptors is
an interesting one, but one that in my opinion cannot succeed.
Too many people (like myself) are maintaining library code
that starts new subprocesses, and they will continue to
indiscriminately close unknown file descriptors, 
with or without help from their libc.

While my library closes file descriptors unconditionally,
The python subprocess API makes closing fds an option.

"""If close_fds is true, all file descriptors except 0, 1 and 2 will be
closed before the child process is executed."""

Interestingly, python provides a related function

.. function:: closerange(fd_low, fd_high)

   Close all file descriptors from *fd_low* (inclusive) to *fd_high* (exclusive),
   ignoring errors. Availability: Unix, Windows. Equivalent to::

      for fd in xrange(fd_low, fd_high):
          try:
              os.close(fd)
          except OSError:
              pass

which doesn't seem to support "infinity" for the second argument.

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=10353

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-07-08 17:21 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-10353-131@http.sourceware.org/bugzilla/>
2014-07-01  7:54 ` [Bug libc/10353] Methods for deleting all file descriptors greater than given integer fweimer at redhat dot com
2019-04-12 14:46 ` adhemerval.zanella at linaro dot org
2020-11-03  9:34 ` [Bug libc/10353] Methods for deleting all file descriptors greater than given integer (closefrom) stsp at users dot sourceforge.net
2020-11-03  9:45 ` fweimer at redhat dot com
2020-12-16 16:39 ` crrodriguez at opensuse dot org
2020-12-16 16:40 ` crrodriguez at opensuse dot org
2020-12-16 17:07 ` adhemerval.zanella at linaro dot org
2021-07-08 17:21 ` adhemerval.zanella at linaro dot org
2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
2009-07-01  5:58 ` drepper at redhat dot com
2009-07-01 22:22 ` martinrb at google dot com
2009-07-02  6:27 ` drepper at redhat dot com
2009-07-02 16:15 ` martinrb at google dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).