From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12493 Path: news.gmane.org!.POSTED!not-for-mail From: Nicholas Wilson Newsgroups: gmane.linux.lib.musl.general Subject: [PATCH] Possible patch for __syscall_cp Date: Tue, 13 Feb 2018 14:28:32 +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 1518532028 23224 195.159.176.226 (13 Feb 2018 14:27:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Feb 2018 14:27:08 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-12509-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 13 15:27:04 2018 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 1elbXi-0004iy-Rm for gllmg-musl@m.gmane.org; Tue, 13 Feb 2018 15:26:46 +0100 Original-Received: (qmail 3995 invoked by uid 550); 13 Feb 2018 14:28:49 -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 3955 invoked from network); 13 Feb 2018 14:28:49 -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=Zr9QWaBiFBTkSOstT8t/Lv6T5NnJXtXNSe1/WVVmfg8=; b=P6GmjepvKwhz03xrsO8OVGFi/KQaToBx+rixxysAiEVfTATDoR5WHz1lZZip+wobo4huTMNRMg97GEda0urkICARMaU4dbxQt3fVQKo3sI0qxpHCMOnN6oqY6Pm3tUzjyLrl0SalsiG+FsQXpyLbVdsRZS+GUczBYqWguFETg+U= Thread-Topic: [PATCH] Possible patch for __syscall_cp Thread-Index: AQHTpNXbVh8lNvkSFEaYm+ClO4dw9w== 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;DB6PR0502MB2919;6:a7ZsBYzikOmsLg0fVAlGIuNsAXRW4vYp90EesGH6phVU3NC3caB7FfWvY2PwNpTjFAjdMLsmjv0IMwjb7EPxO0X48RzBpPkDwxJnXf52UR56dmlngrcIbyrh6sVpyod6FYhqXD+ECSugSQGidr/29DSOr970uH8ZWjfs227HI695FQ+idPVQV4IWbdlCug+/N7/NGi9X2BVW88zYDwouwD9dnsds+i1ajnAla4mlwv5UJOi01/ALs6H/yPwk7saqSCd8K16rmLy/1EGLm4oyMHMbgiTM0tUg6Ok7eFJO5WSdCnzGKxecESsh0DrL9URyIZR289GLpdE0tJz28xEoka314kE8raHu+T3/SK5Alliqw/CKHw+yg4Aj6OKZQFCm;5:ivfEvp5giP0R5nV3WsU0yUzhO0nI3ooPIhBS3b2OHOPbYv++HxQSQ+ryn74UfZh1pCgXLLO9MqtkSAbl3WLAqOjJmpKqBu8esCpdZCDcFoT0/aS7wwVqSKDHSQFSnf2/Z8w94D20cCHJoOSpesxhu6MLybRsR4GsjEsrNn3vd0A=;24:QDHO9ecglmxSSMk3STCA49i+BuxBhSu/o23bSvv7eYwGu2sRPVlo6PTcZmx3JftPkcVxQx+hBkf13iRQ0VDo/Bya2A5sW1LIUmmMk9zfEYU=;7:PbUSDlunfxxG5UtwzhlO+C1x8+c6NQom/ulsmG+TB5Qcx1f114YomA/hY3U1vKc2NI2919b6 BhOo4D9ygu0Mz40gPKxc8UNv2PB6wGu/mKVDcdFHZghIdwVJvJeVqpng/GuYnHxfrSFMlWa0HaBFine7HEvO+1eciFwDthlbrC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 49a7d4b0-93fb-4a29-d72c-08d572ee0f18 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020);SRVR:DB6PR0502MB2919; x-ms-traffictypediagnostic: DB6PR0502MB2919: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(2400082)(944501161)(3002001)(93006095)(93001095)(6041288)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(2016111802025)(6072148)(6043046)(201708071742011);SRVR:DB6PR0502MB2919;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0502MB2919; x-forefront-prvs: 0582641F53 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(376002)(346002)(39840400004)(39380400002)(396003)(189003)(199004)(2351001)(6116002)(186003)(53936002)(7736002)(97736004)(105586002)(9686003)(305945005)(316002)(33656002)(6506007)(74316002)(59450400001)(99286004)(102836004)(68736007)(14454004)(7696005)(478600001)(25786009)(2906002)(6916009)(5250100002)(81156014)(81166006)(106356001)(2501003)(8936002)(1730700003)(5660300001)(2900100001)(1857600001)(3660700001)(5640700003)(6436002)(86362001)(55016002)(8676002)(3280700002);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0502MB2919;H:DB6PR0502MB3016.eurprd05.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: realvnc.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: WZMHFBOMsg8kL7EbdMPmx3WRjDKzvOyn4PrwzrNipusS8vu9oNY+opwzp2BSwFJ8yxZwPnWh6JXnRfHJyfT+sw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-MS-Exchange-CrossTenant-Network-Message-Id: 49a7d4b0-93fb-4a29-d72c-08d572ee0f18 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2018 14:28:32.2299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9ad766d3-c6a5-4458-8c58-244e7c118728 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0502MB2919 X-OriginatorOrg: realvnc.com Xref: news.gmane.org gmane.linux.lib.musl.general:12493 Archived-At: Hi, I have here a patch, which may or not be correct - I'm not confident. In __syscall_cp.c, there's a call to __syscall which deliberately *disables= * macro expansion, forcing the call to go via the __syscall function. On Wa= sm, I don't currently provide this function, instead I'm using the macros f= or __syscall to redirect via the __syscall functions. This call in __syscall_cp looks to be practically the only place in the who= le of Musl where macro expansion is prevented for __syscall (other than in = src/internal/syscall.h itself, and arch/mips/syscall_arch.h). So on those g= rounds it's a bit suspicious, given that every other caller of __syscall us= es the macros from internal/syscall.h. If there is a rationale, I could just define __syscall() in arch/wasm/sysca= ll_arch.h - but I'd rather not if it's not meant to be called. Would it be = possible instead to apply the patch below, and allow macro expansion? I can't see a risk, although I don't understand the cancellation-point impl= ementation very well. There's no recursion possible, since plain __syscall(= ) never redirects to any of the __syscall_cp machinery, so expansion oughtn= 't to cause problems on any archs? Thanks, Nick diff --git a/src/thread/__syscall_cp.c b/src/thread/__syscall_cp.c index 09a2be84..7b870faa 100644 --- a/src/thread/__syscall_cp.c +++ b/src/thread/__syscall_cp.c @@ -8,7 +8,7 @@ static long sccp(syscall_arg_t nr, syscall_arg_t u, syscall_arg_t v, syscall_arg_t w, syscall_arg_t x, syscall_arg_t y, syscall_arg_t z) { - return (__syscall)(nr, u, v, w, x, y, z); + return __syscall(nr, u, v, w, x, y, z); } =20 weak_alias(sccp, __syscall_cp_c);=