From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12154 Path: news.gmane.org!.POSTED!not-for-mail From: Nicholas Wilson Newsgroups: gmane.linux.lib.musl.general Subject: Should calls to mmap/brk handle EINTR? Date: Tue, 28 Nov 2017 12:51:07 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1511873485 12617 195.159.176.226 (28 Nov 2017 12:51:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Nov 2017 12:51:25 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-12170-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 28 13:51:17 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 1eJfM4-0002dz-AQ for gllmg-musl@m.gmane.org; Tue, 28 Nov 2017 13:51:16 +0100 Original-Received: (qmail 4008 invoked by uid 550); 28 Nov 2017 12:51:21 -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 3974 invoked from network); 28 Nov 2017 12:51:20 -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=q27YSjcX1a/atytAca3mGYcywAsxFTHlfxStt1qwoWw=; b=ZvF59CLAzBenMEXg1paMku3/cIDN1JHGeTQMw7QlNLQngFbQ6P9zz+wiOitfjniVDl4xhvWslJikPEDTeCQyMkmy98PXQCVM77j0SMk3K7pUrwEmjieUtEGWSnems4uzht3DeBBMF/4mSKi3RXiSpOzn3/NzGmDApHs7dFf5q6g= Thread-Topic: Should calls to mmap/brk handle EINTR? Thread-Index: AQHTaEauLZw5Z+SrDUGmVXRaCJi+bA== 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:oGn0Cwu1s7YVOJJWz89K7cQ2FXrfADyijsn8c0kR/znTZFBb6DtYGNKKlmqV/t0lMwbogCNp/rrkL9ni2f2sJ4wFBwEGBHVqy5HzGlxpkQTQxXPgUvQNBOlFjbONqPhfYh9FePzS25LD/isLj/JQvmInPB8uuTJVadJfSrVpAG0vifkG3ILq04YVjPAPlzwHdPk7eC2KNipNrc3rq1ND4eBOKoxr+ikN2vYShcn83jM+t6mOakPMKT8Knnav0ctHnk2OWJx4LAv6aLsmil4IpOAc9zmkL4qotGOnSc0o5OhbXkOpFOK2uHQDSaQ2XyGvqi2PiNW6ZdGuu40bGbefFG8DDwgtPhqJPoyRbBouXSA=;5:j6FJWkt84t0wDFbZlbKeX7II9HDKRi4sjFthZFkNdVFSx57gq1nvoKuacBYPqfqQsQn7B7PTiVT9SAFQRIH5KTpmruV7+I7TvtaWxVmkI+nmYr01S6PlRCXZuvRL81U4a5eG2HsZagg/1vMDCdzC2fOQJo3b0aBFLSb+FXmkrK8=;24:z4rzwyfRrevDIkbnWlLC7tf2vTkvgNSBQFAWJjd0Eobd4qjU/SXsfcLL2aZPqQawazPutTNsW9nTuzSik1UR8znu4uxcYLzbzdIT5263bT8=;7:pQtFo17nJGUAFQV3cqCsmx1jmnTBZtSYNvgdFKPPh3+a8cGGyAcmwZyQcs4b7duOMyHRTZhLidlf7a+0jDXt84zGImx+ vmjSV/QQ362E+OiNMPArZU6xmZbYdKv8tDJZEa0lGOjbehVPoAi3Xon2e4nteMr0UMctHQJd6b03Bck8M9PNZbsVAQINWklnZE x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1130edc1-cdaf-43e4-fe46-08d5365eb1ca 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)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(2016111802025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6043046)(6072148)(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)(199003)(189002)(3280700002)(74316002)(305945005)(3660700001)(7736002)(102836003)(14454004)(81166006)(316002)(7696005)(478600001)(5250100002)(97736004)(6116002)(189998001)(6436002)(8676002)(5640700003)(8936002)(6916009)(86362001)(2900100001)(53936002)(106356001)(9686003)(105586002)(99286004)(55016002)(101416001)(50986999)(54356999)(25786009)(2351001)(1730700003)(5660300001)(2906002)(81156014)(68736007)(2501003)(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: 1130edc1-cdaf-43e4-fe46-08d5365eb1ca X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 12:51:07.9708 (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:12154 Archived-At: Hi, 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 previously= , those syscalls did an uninterruptible wait on the semaphore. Since Linux = 4.7, those syscalls can now return EINTR if the semaphore is under contenti= on, and a signal is received while waiting on it. I've checked glibc, and they don't seem to have any handling for EINTR eith= er on these calls. I know it's very unlikely, but should the calls to mmap be changed to do a = retry loop? If malloc fails, it can cause very unpleasant behaviour in an a= pplication - and yet memory isn't exhausted, it's simply caused by contenti= on. If lots of threads are concurrently doing malloc/free on large regions,= it *might* be possible for the malloc to fail spuriously? I just wondered if it had been noticed/considered. Maybe ask the glibc peop= le if they've noticed the change? All the best, Nick=