From owner-freebsd-current@freebsd.org Fri Jul 5 15:51:52 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61D8715CE675 for ; Fri, 5 Jul 2019 15:51:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C72A175A56; Fri, 5 Jul 2019 15:51:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 15:51:49 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.022; Fri, 5 Jul 2019 15:51:49 +0000 From: Rick Macklem To: Mark Johnston CC: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Thread-Topic: should a copy_file_range(2) syscall be interrupted via a signal Thread-Index: AQHVMsfe501Pgm1HEESW4i3o9xExQKa8GSKAgAAN6Zk= Date: Fri, 5 Jul 2019 15:51:49 +0000 Message-ID: References: , <20190705143845.GA50901@raichu> In-Reply-To: <20190705143845.GA50901@raichu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f75d3bb-5ab6-4ca0-5df7-08d70160b0f5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0285; x-ms-traffictypediagnostic: YTXPR01MB0285: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(39860400002)(346002)(396003)(51914003)(199004)(189003)(54906003)(71200400001)(786003)(74482002)(186003)(316002)(71190400001)(305945005)(102836004)(33656002)(76176011)(486006)(476003)(7696005)(446003)(11346002)(2906002)(99286004)(6506007)(68736007)(6436002)(4326008)(66946007)(66556008)(81166006)(450100002)(8676002)(81156014)(8936002)(66446008)(64756008)(76116006)(73956011)(46003)(229853002)(66476007)(14444005)(25786009)(5660300002)(9686003)(256004)(53936002)(478600001)(966005)(6916009)(74316002)(6306002)(52536014)(14454004)(86362001)(6246003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0285; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: auzJx0V4qKHZkbzkemaFvJ/2XrEZCUIgFt0zRquwC7SAa5Nh7wjId2OgcR/lwzsNLh7w8IGUsfNtDpsr/grba5OkiVMVyPQyf1XNNE2IzND5MafBCO/ec7532JTWyVETOdoM9rbAHYawJOfAtOwS/oZCU8J8f3b8GP1Nm2/0A62GGyPe45zvr1QXB1M1BrZzuKjNweMupofitmWRIhybiPzFN7hYADTtuR+RFn7Zm6P/h9Wyf2pNoh4lhS4BfWSg97neyUlm83GkTrQ+67WUH7CWnHmBZRw989O5JEgFdxfnw+xvzh9QdFzV+QsCroDHAWqBmfHGj1XFBYk9Ol0Ik9g0sMmuphUOIn0/vEVnFHrdYailSSmz4rtsqnIsXwUugSYBGwKIdEwCJyNuelaWDtZhsIHn7A4Lj/nPhn1dsKg= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 6f75d3bb-5ab6-4ca0-5df7-08d70160b0f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 15:51:49.2722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0285 X-Rspamd-Queue-Id: C72A175A56 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::619 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.88 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-0.96)[ipnet: 2a01:111:f000::/36(-2.58), asn: 8075(-2.19), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.61)[-0.606,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:51:52 -0000 Mark Johnston wrote: >On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: >> Hi, >> >> I have been working on a Linux compatible copy_file_range(2) syscall >> (the current code can be found at https://reviews.freebsd.org/D20584). >> >> One outstanding issue is how it should deal with signals. >> Right now, I have vn_start_write() without PCATCH, so that it won't be >> interrupted by a signal, but I notice that vn_write() {ie. write syscall= } does >> have PCATCH on vn_start_write() and so does vn_rdwr() when it is called >> without IO_NODELOCKED. >> >> I am thinking that copy_file_range(2) should do this also. >> However, if it returns an error, it is impossible for the caller to know= how much >> of the data range got copied. > >Couldn't copy_file_range() return the number of bytes copied in this >case? (The Linux man page notes that short writes are possible.) I >would expect to see the same error handling that we have in >dofilewrite(), where certain errnos are squashed. I think this would be a good approach for local file systems, since I belie= ve that the only place that EINTR can be generated is the vn_start_write() call, si= nce vn_rdwr(IO_NODELOCKED) never returns it and the call completes before returning. As such, the EINTR happens at a "well known" place in the copy and a return= of the bytes copied should be fine. Now, for NFS, it gets a little weird... - For NFSv3, many use the "intr" mount option, which means that a VOP_WRITE= () can return EINTR and the caller doesn't know if the write succeeded on th= e NFS server or not. --> Returning "bytes copied" instead of an error for this case doesn't se= em appropriate to me, since there is no way to know if the last write h= appened? However, "intr" is not recommended for NFSv4 and NFSv4.2 is the only case w= here there is an RPC to do this on the server. Maybe nfs_copy_file_range() shouldn't "hide" EINTR, although the local file systems do so. I think sounds like a good approach. What do others think? >> What do you think the copy_file_range(2) code should do? > >I'd find it surprising if copy_file_range() isn't interruptible. I'll admit I haven't tested on Linux, so I don't know what happens there. The Linux man page doesn't mention EINTR, but I don't know what happens for a Linux "intr" NFS mount. I do have a Linux system for testing, but it = is the same system I have been using to test this syscall on FreeBSD. Maybe I need= to boot/play around with it. I do think returning "bytes copied" instead of EINTR is a good idea, where = practical. Thanks for the comments, rick