From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 0CC593858C50 for ; Mon, 17 Apr 2023 22:59:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0CC593858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x229.google.com with SMTP id by8so28054521ljb.13 for ; Mon, 17 Apr 2023 15:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681772345; x=1684364345; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=GderjW9SjMEBG4gAuWVjaZ3PZ/6zmctS+geLT5s2WOg=; b=XQujDZ28gNaHu/qe8trHUdHVWqrAb3YWMzz9L4cplh0Ur3CAPML2OFWEnRFe1mSz/3 Igwj7z06vMqGHPgYAmsRscaqUIXgh4sH7NzohTcZDlXZnhPxrMEoR3dOoApBazIP+Kem OW2oNhE8VjTCoNnvU+DHIzsCRuKK21cBUqSiXiFUZNQ2xK2+ceiJAWI5CTpwGyTzbgFH c2MCz6TDjIHOYN/WrBbbHpD5iil1GZd/RpZ1EjQnnR9ycPomEFhtOz5vU76TbXjZI8r4 wroomCQ6gf9pu5zSEdiL6pfwtTDzf+0YQqAiBhfL9qCY9NgisgjFvM6KS9c7Ubn35pTl vzxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681772345; x=1684364345; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GderjW9SjMEBG4gAuWVjaZ3PZ/6zmctS+geLT5s2WOg=; b=hHtugpMTJnRbEvg/YPTJGRwKCBU9b3c56KwPbJy/YhzXzLEioELlg0b8KI4/VQMMXk kCn42CjKImSJmGS/vpbG70I97xU9KmrjgnG30FSDRbsYefZU6udbAt/qo3GZAaZ7CiKa ZFvAEVOdl976nTdM2PxKlTOkH8f9p65WoVcnt8xvN16cfo41BORjVoKLdIF0e0LMS7Dn eivrnROeXR0QMsShdi7yv34flx8Q/TiMGY75QZvlxmWrcN2rxSiGibCb9UoNE+D3EjJq /imHe35NcvXDdGcJpOszqICNMfPQ+Hdk+TRcmFOq91GfcbcPcauUTGCH8XdtoUZXGquO WXtw== X-Gm-Message-State: AAQBX9exgI+/2b7DtK5VptkkA0t7XIJeWbjRvdC/LC5RqGm9A4FCOwP1 29OWFS0CDwXU6y4byT6KKnqUZqA/wwyIuQ== X-Google-Smtp-Source: AKy350YwdgCmu6qc9yiqX++nkph9rLE0p6cqTJdbnU6P/U31+7DDlI1bYyryvTV2nAybjYgZAosE7A== X-Received: by 2002:a2e:7407:0:b0:2a7:79e6:1630 with SMTP id p7-20020a2e7407000000b002a779e61630mr127729ljc.25.1681772345000; Mon, 17 Apr 2023 15:59:05 -0700 (PDT) Received: from surface-pro-6.. ([2a00:1370:818c:4a57:d907:80f6:db70:646a]) by smtp.gmail.com with ESMTPSA id f7-20020a2ea0c7000000b002a8b5310642sm1463539ljm.5.2023.04.17.15.59.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Apr 2023 15:59:04 -0700 (PDT) From: Sergey Bugaev To: libc-alpha@sourceware.org, bug-hurd@gnu.org Cc: Samuel Thibault , Sergey Bugaev Subject: [RFC PATCH 0/5] O_IGNORE_CTTY everywhere Date: Tue, 18 Apr 2023 01:58:52 +0300 Message-Id: <20230417225857.2006561-1-bugaevc@gmail.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello! This is an attempt to use O_IGNORE_CTTY in a lot of places throughout glibc. But first, what is O_IGNORE_CTTY, how is it different from O_NOCTTY, and why would we want to use it? O_IGNORE_CTTY is an open () flag in the Hurd port that makes glibc access the newly opened file as if it's not the controlling terminal of the process, even if it actually really is. In particular, reads from the file while in the background won't generate SIGTTIN, writes won't generate SIGTTOU. (Doesn't sound very useful yet, does it?) O_NOCTTY, in contrast, controls whether or not the newly opened file, if it is a terminal, automatically becomes the ctty of the process. On the Hurd this is never the case, and O_NOCTTY is defined to 0. So, why would one want to use O_IGNORE_CTTY when opening random files that have nothing to do with terminals, let alone cttys? Well, it turns out you *especially* want to use O_IGNORE_CTTY precisely in case you know that what you're opening surely is not the current ctty of the process! This is because unless O_IGNORE_CTTY is set, glibc has to do an extra RPC (or even two) to check whether the file is our ctty. Passing O_IGNORE_CTTY is a hint/promise to glibc that the file is not our ctty, so theres' no need to make the expensive check. So, O_IGNORE_CTTY is most useful not to alter the user-visible behavior (treat ctty as if it's not that), but rather to speed up open () calls *without* altering user-visible behavior. ======================================= With that in mind, I went through the codebase and added O_IGNORE_CTTY to __open flags just about everywhere. You only want to *not* pass O_IGNORE_CTTY when you're not sure what you're opening, such as when implementing fopen () or a similar wrapper for open (). But when you're opening, say, a shared library, or a /dev/shm/ file, or a locale archive -- you know you're not dealing with ttys, and so using O_IGNORE_CTTY is appropriate and beneficial. In order to not add tons of ifdefs, I've added a single #ifndef O_IGNORE_CTTY # define O_IGNORE_CTTY 0 #endif to include/fcntl.h (following Samuel's advice). This of course makes O_IGNORE_CTTY usable (and no-op) on Linux (and other ports) without exposing it in the installed headers. ======================================= While looking through __open calls, I've noticed a few that (suprisingly!) did not use O_CLOEXEC. I've tried to fix them all. Even if the rest of this patchset is rejected, please evaluate that one commit separately. I had to convert misc/daemon.c to a more GNU-ish style, since my changes wouldn't easily fit on 79/80 columns otherwise. I've split off the actual conversion into a separate patch to make review easier; but that patch is still going to unreadable; nothing I can do about that, sorry. I have built glibc on x86_64-linux and run the testsuite; there are no new test failures. I can't run the full testsuite on i686-gnu, but some manual testing confirms that the many superfluous term_getctty () RPC calls are gone, but the ctty functionality is still there, e.g. I can fopen ("/dev/tty") and write to it and get the expected behavior. This is different from my usual patches in that it mostly touches non- Hurd-specific code. Sergey Sergey Bugaev (5): misc: Convert daemon () to GNU coding style Use O_CLOEXEC in more places hurd: Make dl-sysdep's open () cope with O_IGNORE_CTTY include/fcntl.h: Define O_IGNORE_CTTY Use O_IGNORE_CTTY where appropriate catgets/open_catalog.c | 4 +- csu/check_fds.c | 6 +-- elf/dl-load.c | 2 +- elf/dl-misc.c | 2 +- elf/dl-profile.c | 3 +- gmon/gmon.c | 7 +-- iconv/gconv_cache.c | 3 +- include/fcntl.h | 16 +++++++ locale/loadarchive.c | 7 +-- locale/loadlocale.c | 4 +- login/openpty.c | 2 +- login/utmp_file.c | 7 +-- misc/daemon.c | 88 +++++++++++++++++++---------------- nss/nss_db/db-open.c | 3 +- rt/shm_open.c | 2 +- shadow/lckpwdf.c | 2 +- sysdeps/mach/hurd/dl-sysdep.c | 4 +- sysdeps/mach/hurd/opendir.c | 2 +- sysdeps/pthread/sem_open.c | 9 ++-- sysdeps/unix/bsd/getpt.c | 4 +- 20 files changed, 106 insertions(+), 71 deletions(-) -- 2.39.2