From owner-freebsd-current@freebsd.org Fri Jul 5 15:59:45 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 5B26515CEBD4 for ; Fri, 5 Jul 2019 15:59:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670078.outbound.protection.outlook.com [40.107.67.78]) (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 539FC75E9D; Fri, 5 Jul 2019 15:59:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0286.CANPRD01.PROD.OUTLOOK.COM (10.165.219.8) 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:59:41 +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:59:41 +0000 From: Rick Macklem To: Hans Petter Selasky , "freebsd-current@FreeBSD.org" CC: "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: AQHVMsfe501Pgm1HEESW4i3o9xExQKa8DfWAgAAgBaE= Date: Fri, 5 Jul 2019 15:59:41 +0000 Message-ID: References: , <8c7707d7-f315-d613-705f-40b1619a7553@selasky.org> In-Reply-To: <8c7707d7-f315-d613-705f-40b1619a7553@selasky.org> 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: f922b864-eb62-4eb6-5e23-08d70161ca93 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0286; x-ms-traffictypediagnostic: YTXPR01MB0286: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(346002)(376002)(199004)(189003)(25786009)(66476007)(64756008)(7696005)(76176011)(66946007)(66446008)(46003)(66556008)(76116006)(52536014)(86362001)(73956011)(478600001)(4326008)(54906003)(186003)(81156014)(2906002)(476003)(486006)(256004)(55016002)(102836004)(316002)(6246003)(786003)(68736007)(110136005)(81166006)(74482002)(8676002)(99286004)(305945005)(229853002)(8936002)(14444005)(446003)(2501003)(11346002)(53936002)(74316002)(6506007)(4744005)(33656002)(14454004)(5660300002)(9686003)(71200400001)(71190400001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0286; 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: csqqY+mOhG04wfyL8QsG5RO9iXT2bDum1OnYgt4bKi3gFMBFjV9U3H56GBK8FdaNd7FB06Kyl9cQ4Shwh6dxc+zRe6UXym0D8a6usRS/2Wjl84bTDuutouDRVt03t85Y5ualILR0prplckVBDHjDg4RXWmXWLhIwiAox3FZkfRrD/SCxM9tU8Ah5sX39RxXJmEfwDjQrZANweP0zV6M577vRQ7pimTzAJkKLxd4YvWQP+FZI6PcJR+w2XuuYvm9V8wkoHA5ivz8UwR9OWVvYUHeVGyRfls3D2rqSoTF5spVIpvDcJo8LY4GoBXv+7H2DiIl4HL6s39ingBF8OJ817atABbgkF2Iu/IwO8bNbqsiYUdM+2zjq38mGmaXPFpatMlNIilk/w4WdQ1jIm5AR6ezc0JjWGFAeOU4cMiXxp0s= 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: f922b864-eb62-4eb6-5e23-08d70161ca93 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 15:59:41.7945 (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: YTXPR01MB0286 X-Rspamd-Queue-Id: 539FC75E9D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.78 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.74 / 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)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.40)[-0.403,0]; RCVD_IN_DNSWL_NONE(0.00)[78.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.03)[ipnet: 40.64.0.0/10(-2.89), asn: 8075(-2.19), country: US(-0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, 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:59:45 -0000 Hans Petter Selasky wrote: >On 2019-07-05 02:28, Rick Macklem wrote: >> 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. > >How can you kill a program stuck on copy_file_range(2) w/o catching signal= s? Well, if "stuck" means sleeping somewhere inside the VOP_WRITE() call for the file system, I think it is "stuck" forever, just like write(2), isn't i= t? For NFS, the "intr" option might allow write(2) to return EINTR, but it oft= en takes a forced dismount (actually "umount -N") to get it "unstuck". However, I think for the case where the signal is detected outside of VOP_READ()/VOP_WRITE() in the copy loop, it does make sense to terminate it and I think the suggestion of returning "bytes copied" instead of EINTR = is a good one. rick