From owner-freebsd-current@freebsd.org Sun Aug 11 22:20:02 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 786F7C4260 for ; Sun, 11 Aug 2019 22:20:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660058.outbound.protection.outlook.com [40.107.66.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-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 466D1Y46mDz4Sq4; Sun, 11 Aug 2019 22:20:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OE41v+3IAqH3PHKQ4TEA88VomD1B83Zh5dcDkeOYs8RlYjLLA9xWKBa9NAgmkCF9WidzcB/z8QjMb9q9YSpvL93k0CPmzpFyoV1BY7aP9zJhiwDolqVYZmWyN4hO8DXzUh+n6IVGY1eD2TxKrr9/MraUKfd8wuVyDJBgI+oEZ1panu2nUdSdse9VYh9EEK0TLECJPouUsluX+74Rcp4KoQksWZPhmoGyHJ64Ea4Qatboh7xwBbhd3rkryu9JaBiBHPyGxy9xoJC0qPIl3pq2zzTK7Oq5ykbWSIlKZnMvN6zCaMu0pci2fSGG5NWdq92GLfOXdtbrieoMbKXnENoqRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XPBRfLnmf29p1Kblv4SEcx8GwIhaVC1iUV4mDTZjt/o=; b=Vqprb/Ec0AUWt6j2BS6GLX73NkIvjODIgQsNZcg3mZdyjjmYqlgMF1QXEHonAFYDMPXfT6PRO/Xwfg9ccNy+ByJ2Cw8XmKHflilXVuS4Kk2P97dk7gijU76Zz11mZAEMZ8JogkwF2JZkyGdwO/mMJlGXRbekbldY4Fx+2PKKtEu2AqWEOGEPLfr7nqLfyn1tk2ljKp3i9KXud1MpCnSJYJmZF8nFpFOmuJxdzQFnDbjKMFLyCfkPYaH7BQugQMRNvoeQEV10lPADVqyq5IDNc7E9CVpDTVYxKgh/FQwnKqbuy2td5kDNB4poMzgO0DgIJGzeYWnoOQ8HDd0OGrYvhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3616.CANPRD01.PROD.OUTLOOK.COM (10.255.12.82) by YTBPR01MB3263.CANPRD01.PROD.OUTLOOK.COM (10.255.13.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.18; Sun, 11 Aug 2019 22:19:58 +0000 Received: from YTBPR01MB3616.CANPRD01.PROD.OUTLOOK.COM ([fe80::fc05:2310:90ce:16e]) by YTBPR01MB3616.CANPRD01.PROD.OUTLOOK.COM ([fe80::fc05:2310:90ce:16e%6]) with mapi id 15.20.2157.022; Sun, 11 Aug 2019 22:19:58 +0000 From: Rick Macklem To: Ian Lepore , Alan Somers CC: "gljennjohn@gmail.com" , "freebsd-current@FreeBSD.org" Subject: Re: RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY? Thread-Topic: RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY? Thread-Index: AQHVT+jQ5wsNrJT2jUSYLr8e3O7szab1hhuAgACEJgCAAARxAIAAHhmAgABUNyQ= Date: Sun, 11 Aug 2019 22:19:57 +0000 Message-ID: References: <20190811090405.50cc49b1@ernst.home> , In-Reply-To: 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: df5090a6-66d9-4525-78b8-08d71eaa0b6b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTBPR01MB3263; x-ms-traffictypediagnostic: YTBPR01MB3263: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(346002)(39850400004)(136003)(199004)(51914003)(189003)(316002)(25786009)(476003)(76176011)(786003)(229853002)(486006)(99286004)(55016002)(8936002)(186003)(102836004)(9686003)(54906003)(5660300002)(7696005)(6506007)(53546011)(110136005)(52536014)(11346002)(446003)(6436002)(46003)(8676002)(66446008)(14454004)(76116006)(81156014)(53936002)(81166006)(66556008)(66476007)(305945005)(86362001)(6246003)(64756008)(478600001)(33656002)(71200400001)(71190400001)(4326008)(74316002)(256004)(2906002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3263; H:YTBPR01MB3616.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: vUIudxbLu37J8dm9XwNVuzcaRuEHZ6VVCoprISQQ2S61v7gDApLdK6LFLxD3zRodI9qCBW9Avz7FqvEVrlqnTrWllXsvg2u4UZYAmwetdjWwukcxjhTqUm+RgseZxW48vN7MIwku5uwvfEB2Hikap25i84vxE01UH3cXwFoPpnxwvwAGaFGakWriBRjOIdF431oWTa9b9LOiEELplgOaRNYMegaioK37y5Z17xWcW8OTTEUIvn+QMctDDKk5SA0tKQyanAKTUL7V90FwI0aR1cTvTA7R1w8yaUId2tJkEwdEnBS6LqBC3WBfBvbS0gKmt7PI/uGkrGWPBxf5a3sLIBtvFh4HTE+B002Fmtu5swjfNbwSf2ujbaER/LcsjqvFYobzw5sfgbayR7AunFddoFCfw6mgpO5Dfy6R1bNINzk= x-ms-exchange-transport-forked: True 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: df5090a6-66d9-4525-78b8-08d71eaa0b6b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2019 22:19:57.9891 (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: 1jvBc/nPjAKtDJurlcWBGeaCgfPauLi9Pup0CDaPy/+IfPVHs5k7sPVpOZrjgJ2oErstB8tmiO41xU2ZOivdrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3263 X-Rspamd-Queue-Id: 466D1Y46mDz4Sq4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.58 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.38 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; ARC_ALLOW(-1.00)[i=1]; 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]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; RCVD_IN_DNSWL_NONE(0.00)[58.66.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.14)[ipnet: 40.64.0.0/10(-3.34), asn: 8075(-2.28), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_CC(0.00)[gmail.com] 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: Sun, 11 Aug 2019 22:20:02 -0000 Ian Lepore wrote: >On Sun, 2019-08-11 at 09:12 -0600, Alan Somers wrote: >> On Sun, Aug 11, 2019 at 8:57 AM Ian Lepore wrote: >> > >> > On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote: >> > > On Sun, 11 Aug 2019 02:03:10 +0000 >> > > Rick Macklem wrote: >> > > >> > > > Hi, >> > > > >> > > > I've noticed that, if you do a lseek(SEEK_DATA/SEEK_HOLE) on a >> > > > file >> > > > that >> > > > resides in a file system that does not support holes, ENOTTY is >> > > > returned. >> > > > >> > > > This error isn't listed for lseek() and seems a liitle weird. >> > > > >> > > >> > > ENOTTY is the standard error return for an unimplemented >> > > ioctl(2), >> > > and SEEK_HOLE ultimately becomes a call to fo_ioctl(). That's true and explains why it returns ENOTTY. However, lseek(2) is not io= ctl(2) and it doesn't list ENOTTY as an error. (Just to make things confusing, lseek(2) using SEEK_DATA/SEEK_HOLE appears = to be only a POSIX draft at this point, so POSIX doesn't really help w.r.t. w= hat errors should be returned for this case.) >> > > >> > > > I can see a couple of alternatives to this: >> > > > 1 - Return a different error. Maybe ENXIO? >> > > > or >> > > > 2 - Have lseek() do the trivial implementation when the >> > > > VOP_IOCTL() >> > > > fails. >> > > > - For SEEK_DATA, just return the offset given as argument >> > > > and >> > > > for SEEK_HOLE >> > > > return the file's size as the offset. >> > > > >> > > > What do others think? rick >> > > > ps: The man page should be updated, whatever is done w.r.t. >> > > > this. >> > > > >> > > >> > > I also vote for option 2 >> > > >> > >> > If SEEK_DATA and SEEK_HOLE don't return the standard "ioctl not >> > supported" error code and return a fake result, how are you >> > supposed to >> > determine at runtime whether SEEK_HOLE is supported or not? >> > >> > -- Ian >> >> pathconf(2) will tell you. >> > >Ahh, I wasn't aware of that. > >For option 2, lseek() has to not just return the info, but must also >actually set the file position accordingly, and has to treat offset >=3D >filesize as an error. Yes, this check is done below the VOP_IOCTL() layer for the file system (using vn_bmap_seekhole() or custom code). I think the easiest way to implement #2 is create a vop_stdioctl() and put = it into sys/kern/vfs_default.c. It would need to do this check. Interestingly, I had assumed the discussion would have been between leaving the errno alone vs changing the errno. I only threw in #2 for completeness sake. --> Now, it appears that #2 is the favourite. I'll wait for more responses before I propose a patch. Thanks for the comments, rick