From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12163 Path: news.gmane.org!.POSTED!not-for-mail From: Nicholas Wilson Newsgroups: gmane.linux.lib.musl.general Subject: Re: Should calls to mmap/brk handle EINTR? Date: Tue, 28 Nov 2017 14:44:00 +0000 Message-ID: References: ,<4c6e2a7a-7618-db76-1e11-1ad9c58df12a@redhat.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1511880264 2109 195.159.176.226 (28 Nov 2017 14:44:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Nov 2017 14:44:24 +0000 (UTC) Cc: "musl@lists.openwall.com" To: Florian Weimer Original-X-From: musl-return-12179-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 28 15:44:16 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eJh7K-00086n-T1 for gllmg-musl@m.gmane.org; Tue, 28 Nov 2017 15:44:11 +0100 Original-Received: (qmail 21643 invoked by uid 550); 28 Nov 2017 14:44:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21621 invoked from network); 28 Nov 2017 14:44:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realvnc.onmicrosoft.com; s=selector1-realvnc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JcEpa/jLi8CVL13uYCVmM25GjNo3EQH3Vgi24azzjC4=; b=A6TF2k4sMa3EDIR1iqN4rNZkKnr8+J2wO6Of39eWsFlROl0W3y6Ln31SnCAMT3CpWGphuUxD0elMblt9vjWgTUEZ7CKbG1zUsXVio6yUOLlvJstMTyP3wjCeZchvnri2POTUuSvDCOFQPvpBwOQAZIDJuqn1xJupcf96peabSMk= Thread-Topic: [musl] Should calls to mmap/brk handle EINTR? Thread-Index: AQHTaEauLZw5Z+SrDUGmVXRaCJi+bKMp2ekAgAAEKGM= In-Reply-To: <4c6e2a7a-7618-db76-1e11-1ad9c58df12a@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nicholas.wilson@realvnc.com; x-originating-ip: [2a02:390:a001:192:d6be:d9ff:fe9c:1892] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;VI1PR0502MB3885;6:ZQm08+z6k9jLZgCVzJPpb/9eVFsO2Pp1GD7MqWSjy/txzk3Z6a2H2ru2HTPBjbhISxidRYVuzM5xOMYbcrmODHOL1WNPAQX6CzQbaPpBJLvqVi81YaXeLOHOvciiZA1UG2aSrj9KGJ2L3E5jOxZL0sFpj76K6ZeGjE6P1WbJ66yOVPJHW68bZslwXuJNWkToFh+A26J5j83+tF0i0IwprAEdZDsEIGwYtO4EVNlUdqU5TE0Dzp4Lp9na8zfDiE90LCMz/1NzfTuU4HzPvoSIhkSTmp4fIs0tkYbXhGnnlZc/z5eiNwnB+yZsjufUoDD72eG/lpMRnOxwabttWxgn+Ov1C2XWIRejE8ZZHvMRU+I=;5:LzBac6gP6s5OAZhEckgIktFo+dIimCS1Z/mE4O8TIfzxUcuOXncIbXedEn0M6DUYjxmZFEGCh/YJyPak1fAvKs3nQKHsqKyWLfM/AIb/pXkXt3Mu7TiM49J/T4JFCffNB3hvmNpjkwCSPYuH9ZEH00rHwh8krQYuqP7io9SamXg=;24:tX3Plyw9Pq2FZnmT/uxS2fvlOZ0Zy4YBW2kN9zU8furo06qtCo5sSePonzWkFJciE1r7uuzgm3BFszDq02za9jSHFS9X42OE3ihAIT1LvVM=;7:BAqa3ChLCdp2RtYfR0txf1N+VELmQAxPKUnVAD9NjiDxFgnTYBUXtM9I+CuCJSy/Kb2OXguDRrsk+8Kpkp5jT1OmP0Wi med55qDwv75qGXQ1evk1rzjuRKmhLAWHqVoTZNIFOhQDPuuLTH/nkYXo/DL6mUx8OsZNIMsW8YZ5n+aIxxAf5vjJMk14UvzBId x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7c0beb09-0eb5-4ae6-dbf0-08d5366e767c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603258);SRVR:VI1PR0502MB3885; x-ms-traffictypediagnostic: VI1PR0502MB3885: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231022)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(2016111802025)(20161123564025)(20161123555025)(6072148)(6043046)(201708071742011);SRVR:VI1PR0502MB3885;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:VI1PR0502MB3885; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(366004)(346002)(376002)(24454002)(199003)(189002)(3280700002)(7736002)(3660700001)(102836003)(305945005)(14454004)(81166006)(316002)(7696005)(478600001)(6436002)(5250100002)(575784001)(97736004)(6116002)(74316002)(2950100002)(189998001)(8676002)(8936002)(6916009)(2900100001)(86362001)(53936002)(9686003)(106356001)(76176999)(105586002)(55016002)(6246003)(99286004)(50986999)(101416001)(54356999)(25786009)(4326008)(229853002)(53546010)(5660300001)(2906002)(81156014)(68736007)(33656002)(6506006);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0502MB3885;H:VI1PR0502MB3885.eurprd05.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: realvnc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-MS-Exchange-CrossTenant-Network-Message-Id: 7c0beb09-0eb5-4ae6-dbf0-08d5366e767c X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 14:44:00.3583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9ad766d3-c6a5-4458-8c58-244e7c118728 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0502MB3885 X-OriginatorOrg: realvnc.com Xref: news.gmane.org gmane.linux.lib.musl.general:12163 Archived-At: Ah, thanks very much! I hadn't dug that deep, I just jumped to a conclusion when I saw "return -E= INTR", without realising that was just a dummy return value. Thanks for checking that, I haven't managed to reproduce it, I just guessed= from seeing the code that it was possible. Nick ________________________________________ From: Florian Weimer Sent: 28 November 2017 14:29:00 To: Nicholas Wilson Cc: musl@lists.openwall.com Subject: Re: [musl] Should calls to mmap/brk handle EINTR? On 11/28/2017 01:51 PM, Nicholas Wilson wrote: > I've noticed that in Linux 4.7, there's a change compared to the Linux 4.= 6 code. The mmap and brk syscalls are protected by semaphores, and previous= ly, those syscalls did an uninterruptible wait on the semaphore. Since Linu= x 4.7, those syscalls can now return EINTR if the semaphore is under conten= tion, and a signal is received while waiting on it. Is this really true? How is this not a kernel bug? Commit dc0ef0df7b6a90892ec41933212ac701152a254c says this: =93 =85 Most of the patches are really trivial because the lock is help from a shallow syscall paths where we can return EINTR trivially and allow the current task to die (note that EINTR will never get to the userspace as the task has fatal signal pending). =85 =94 Those EINTRs really have to be invisible from userspace. If you can reproduce EINTR returns to userspace, then something is very wrong. Thanks, Florian