From owner-freebsd-hackers@freebsd.org Sun Sep 27 00:14:02 2020 Return-Path: Delivered-To: freebsd-hackers@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 70EF53E53F3; Sun, 27 Sep 2020 00:14:02 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2073.outbound.protection.outlook.com [40.107.91.73]) (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 4BzR2w5YYSz4H5D; Sun, 27 Sep 2020 00:14:00 +0000 (UTC) (envelope-from stephen.wall@redcom.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B5VGSZrUW+vwhnrB1if2TgRfpZwYRvdIFmcuG2XmZP/9Na0Or9HLr8cBgj5QiXZhktq1bhG/OGGwowdF+dhEwcp7bY/5iQh4xb1ZbkwM0OKFwHalpB35r6ZvlN0Z/tWn4G7tO7IzESz9bmigDoxZHfQt3n/yPzrrIgL2wGZTfwxSGKltb5tUlAXGdeHvrb9ShvsIPgAt0OLl8I1gBpSjl52hxwvT9RkqU//OMgZz5QnCbQHPuxlIiBlCF5Z8DtQRVdRvh8Ktj6NDSFJblqafSIupglrGtcTYVsSFxSHi6rXo4Cg6jH0Os75EQxUA3NJ/N+GnfGWMTbrv/I2mv48sTg== 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=i3M/HFga5ujR2DlzX9hdr0BviU9cNSOPJHaAa/yosRk=; b=IecGdx9ppRwLJ8ppfveSbh8Mj4AlYQzQ/yLqXZXzTZ8WRvwsSuvld3yOvmd3ULkB+j8ymB/12kNfzz5azpwu3XWnNu8ldksr2TLC4sW4ZLc3aT3oFnGylrW+K5IAxhjGTcwRY6wjRs1tVuDWk1ObMmIHAtQovdSP9caUPeBs2y+t8/6wXF3hC4KumpBJzPlT9KqG6sB22qAJ5bUW+psLchUkE22X505Lb9XjxN1T329cBziQo/fsBNn2XKxkG12PbUzdGg1uJhUoBJD+VGZMcRRuuquEvN8FwvHTVglYBLLVNcfsCJxMDv5bfDZ2wy+KBn+OSI4IE3WjEtl7VhLKEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com; dkim=pass header.d=redcom.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redcomlaboratories.onmicrosoft.com; s=selector1-redcomlaboratories-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i3M/HFga5ujR2DlzX9hdr0BviU9cNSOPJHaAa/yosRk=; b=c/Opp/kxTbQ8BERuLC7zeNa4joagCrsQ8hNYcanKu3vJ298VCAwdjQ7iPx1a952hhbEUjeJc1KY1xfOoEoYZLwzoSBw582qxSMN+/rTayzMFIQSo4OsWiExFdwy4IbL4rfNqQtgsqOBFGByKHDLndtMdhD0zDr59H6ZM0o2LSJoqwHXcttrHOD4FWQxRvAqNa0RPrVsILQsomOsmcZJjtslJpTAX83WAqIcwNtcAfC2jj2eZU8zv/vIJtsTInUDf2CHdXoHxlbBlKM3+5/Vzd36vjm6HJUPIa2rES90kzMBe/ywgO+yhe/FXBwPSUb46VZV8rEMjqxjObMHthOtKKA== Received: from MN2PR09MB4876.namprd09.prod.outlook.com (2603:10b6:208:223::18) by BLAPR09MB6402.namprd09.prod.outlook.com (2603:10b6:208:289::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Sun, 27 Sep 2020 00:13:57 +0000 Received: from MN2PR09MB4876.namprd09.prod.outlook.com ([fe80::4039:3c3b:81b5:cfd8]) by MN2PR09MB4876.namprd09.prod.outlook.com ([fe80::4039:3c3b:81b5:cfd8%6]) with mapi id 15.20.3412.028; Sun, 27 Sep 2020 00:13:57 +0000 From: "Wall, Stephen" To: FreeBSD Hackers , "freebsd-current@freebsd.org" , Rick Macklem Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFK6l7nDvm Date: Sun, 27 Sep 2020 00:13:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.224.143.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62654a3a-be3e-4b23-1003-08d8627a3a3e x-ms-traffictypediagnostic: BLAPR09MB6402: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NPGxXsWm27tKs/LvvO6VnT/QzVsL1PJuOvXHOvn4Nxci0UWvMX6u0fx8TQztl2Ek2kKxSToqoYYifMCD+X3NfH0F8+BxPbtVaMch/ALYaiELHB8LjEtO+t5Kg2Km3EIAEYEDekiIOIq2810GQzmZ9Kd1WCldjAq93QV664QkW213YVVNmkWGOnei9mXjQpJ1ufjl9AVZBklGe0uOyHRf1YI16bwH5UkYSd7oRZqPcNWC79QxqXaHbejGgfFGW2Cjals+wM1PQVsd0/ab6yYhXlvxiShvy7efej0fQneJuYNtqT60UD5SjO2xhg2SU4tccpm+y0VlrWaHgCb8YFpbuks5Ocxt755wSDK/zqxdCVmqjEUXRDYxtRY2epyI+vzO x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB4876.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(376002)(39830400003)(396003)(316002)(186003)(110136005)(8936002)(6506007)(52536014)(478600001)(7696005)(66946007)(5660300002)(76116006)(26005)(55016002)(9686003)(8676002)(33656002)(2906002)(558084003)(71200400001)(86362001)(66476007)(66556008)(64756008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6AGiSV/JGD3Hlh2LopCpLbtJA+pc7KrMLWB6T5pw9jJJimLq3+MFqweNyGtQ/XMTHWMM2orjTdH59mGXiFobAZb4nN4Qf4qGjTEHzeLU5sRSVXwvxgwc52BEd/Q3fN527igDN1b00PdjtbLgopWpuB9YPmpJsHp2XDe6uV4LfSTr44977l5irHvZz1pmHuD98kPzfctHP4i2E2R0zhWvoT2xIFSSC7PbkxhXPUG7CVfOt2QkAU1BCkT94gaPdV3+jllpSVwTM19WaBN0UfYQQGWHCkKHWd0J2PVufQO0x3O5hcCPhrTUrG+zKiqVJ91q6hvaZ9nmuJQXmEFWEN2+XINmh9fHzfKtmaTBS3NyL+zdyE3WFzsDA8Fp0xQFvMFtqXjSidbJgX3IYDzh0q0G9Ov+qr+Fgnbq/USWfaq/mQIAED2NtXvO1Vmmy1OrYaq9EGUv7z8vs7i0PBKnvmFUK2jFhUqVKkuhzoHXXK8550+I+NXYgsdgUr/m+mysM4eCOZDvG7FCcWuIZgef3DQZqoe9Ujg3UyCx0VC+zmfRC50ZED8C81LAYVPbXWJLBYfM5SSKmjMzT6YWDvFUg5fvS1I57iHFuCc/UckuXipm23Na8YhaXKKrZ28qid0mP8HZ+kmBB4Yvmjnp0CWVtZBmfQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: redcom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4876.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62654a3a-be3e-4b23-1003-08d8627a3a3e X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2020 00:13:57.4597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FE65y4bXEevKPbFIXBDlAk3wm7w/5ILfiBZnPKHdPwPOVL4Hu5fZERiuaoot77LwWE/mZgDCm9TpDxHeBG1wkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6402 X-Rspamd-Queue-Id: 4BzR2w5YYSz4H5D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=c/Opp/kx; dmarc=none; spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.91.73 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com X-Spamd-Result: default: False [-3.66 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[redcom.com]; NEURAL_HAM_LONG(-1.02)[-1.024]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+]; NEURAL_HAM_SHORT(-1.05)[-1.047]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.91.73:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.91.73:from] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 00:14:02 -0000 Could the as yet unused options param have a bit assigned to trigger the ne= w behavior? Inform the linux community of the addition and let them decide= if they would like to adopt it as well. From owner-freebsd-hackers@freebsd.org Sun Sep 27 02:52:43 2020 Return-Path: Delivered-To: freebsd-hackers@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 87F593E950A; Sun, 27 Sep 2020 02:52:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on060e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::60e]) (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 4BzVZ22sGgz4P45; Sun, 27 Sep 2020 02:52:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=idMrZ7BhPcxqBzhupRWkRUSzXVLP/7V6tg5z52J0ZTvk1WZORdylEQ0cTGkg5dgoqyrxZqQycVyPs4AdmhQFIY8PK46fgz3M1XE1sHm90v70CKhexC3IQJIlX6/oW83m1qNkeCDRAtO7bZwt0neA0WJTWusxSuYIJ22cnnaJ+AunsnebJQJSWZJZg6vayg42ky2wDt7XgJXiQOKtfrWKTF248KbudVdfsOwSAuOoGad3ZMuiJl5SVVBnQsDfGwWXg2GaB6JmYWossQb3IZN3fORWyYKWClZi9PDaV0glu2Cv/7jWHcidfZLNy0fYgHsEmnGUiQhleMLRjxqVvumFQA== 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=uLKZ5VntpkUNMq5oLZ4rXndQpmPBCnBSfZBkvH+HxxY=; b=DyGO6Shfi4ujsIA+0l65HvVz0rm2AnXV0Na79Fp2a7/hvlMPBMLE0IgQdd6ZdEmI1EJWc9KdgC0DwcUxQ7EtYCtt6mm2foVMZGPV4nzdUVPlyrVTNoOActEed8NLoESXgui2WPXM3tvKhInnx+lgGmPjstIwCtf06BF2VleQ6dQ/EeYDKmdGRCSo98Et2v0D9jz6qvTmEjrry+j0yaNAwAl1qTJf4yHJk8gMBdFNfGPdG1e5kltYOZ5f9qaarGw58nR5+Yxf8TO7oMHKNkZ1x//velF1aGyDWAHq6yhLU3/ZuhaNBk6RjbLMZDKnMV1FKlMD5AdnNOt4ChJeAQyehA== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uLKZ5VntpkUNMq5oLZ4rXndQpmPBCnBSfZBkvH+HxxY=; b=BW0aOJbdSo3tTqA7cA0v98C0CmQqPYlDIOGh422P9P5PXUqbMymnhEeWhorH4IU+y+cFRWCfytJG61ctGcto07jCxOX3s0cbx15D+LdUfnWb7vcyx5X2OazD/ib3nDIREYWkCXIBk+VM+F6gD/JY+MbFDxVAIFS4X0NwXmWHZST73xWLON0NlFanRVk4ZYDQ0+Nde97+3CLJyXDAcCn5ywr+DjKyhilCkC0MU8xG1C/LrnHNZYQMpAoZJA11X52w72Wv3bt6Gwsj/CvTGMxDvNQcKy7l7OY6aw6js39sudq6HsSsAYvuah5kgzT/609QQfIG98n/heSB36ujplFF8g== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB3530.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.25; Sun, 27 Sep 2020 02:52:40 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3412.028; Sun, 27 Sep 2020 02:52:40 +0000 From: Rick Macklem To: "Wall, Stephen" , FreeBSD Hackers , "freebsd-current@freebsd.org" Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFK6l7nDvmgAAr7eA= Date: Sun, 27 Sep 2020 02:52:40 +0000 Message-ID: References: , 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: e5caed86-9789-40df-4ff6-08d862906656 x-ms-traffictypediagnostic: YT1PR01MB3530: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: klj14eU0iQnxb3lAXDgyjvHaghbH67ObAGC0JrZFju2/MeADtMyJUWU7fLP59hmp4x7i/WvXz5WyNbRCHP8yoyzwd0WiS0AmzoRANNio+QxJ4LlVKg9srEkoKs6tIFFMUYflnCMDc3wwSUBba/e3wBc7cEbMBEV7kBKKKJeb5ynwM/+ErB4WxL1R0EqCXECweYfGeuPlrYq4ptYSquXWZFMI2C5teFGrxttCuArGm7HicMLv9uImjTVJQqMBXIA++VipmKwOPUVp6RJw/71q5kT0hUaRE+MuX0wcTABcRlsYz6H4Kd2tQ1UJa3zFeJqW3b8HRUoMrCtqJmBlPSca6gPbOtx38qvONeUeZgXFJ1dNn6S9JXDW4mECyVdcgp+q x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(396003)(39850400004)(136003)(71200400001)(4744005)(52536014)(86362001)(66946007)(66446008)(64756008)(66556008)(2906002)(66476007)(76116006)(91956017)(5660300002)(33656002)(6506007)(186003)(55016002)(9686003)(478600001)(8936002)(7696005)(786003)(316002)(110136005)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: hz1zncn/bp4QKb7dFsP2EuWxPnm7MD6g95mxL5L7PhR+/5ebEkTduOFjalAulR/QkCI8YOv/p2dswoKCijuaC2cP3/4X6z1X2mOgWLIaGDuxerRYNHxhoPx5Ac+TGBoW+c6qqBVwwuoJ83Q2p88SwDA3E6BDPSuEqszrklQUOZOiZ1E/c5+Bz6ybkge9JfzXUDRCEQU529eIh/nSOPVmn944Rp2foIxnbQywAcYvHGWIOEmPxufb2ia/nrIVFO5pEvO022Cug/d0wYDm5NU0d1L03IV0x4+ZcnEpadGVl5vqa/fpuj9RzpiAXfISU+cvzR3XONjmG0QwwnNE/m827es0siSxHpGr/0ZEiNupo0yLZ08zQzwzjeX9LMRXEA3F+gXUpLkb//2C4T+pTE+selKI1Tg5RcQKhBQ3xinuiKPxnfFHW3sVsybAYNWvJ9Zb9XtrDo+q5SA6wBCuSCGCYcOYWeytjYxJ8/cNqucoc6lO0bBppB4Q8V89FbXHM3KJ+y0mLz4H+6rdIgMiGvsEU48vQ34bDV1iOqFaEqVaae5uRK2moVfbXRNv2Ci+XbQNxgenYSbwWAfzQIYffcqXLX2CRU5vD7pENeHpM2qgULdoS4L08jGuxib0RgHV6NW5pWx10v6QbHGcdBJvpsumb3by24/VWaSGDInCIsQSltty3ieAK7oU3oSPCf/CxlFL6mEb+CWE3NlLDei9JWHYbg== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e5caed86-9789-40df-4ff6-08d862906656 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2020 02:52:40.3920 (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: xSnZah9QMMRD44amruuxIGbhalRdpdLxINYmv4hL7bmZvbnMtprFBCktJgwPHkdOWtyAM5hZX317GOfPlB+04w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB3530 X-Rspamd-Queue-Id: 4BzVZ22sGgz4P45 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=BW0aOJbd; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::60e as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.16 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.012]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.15)[-1.153]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 02:52:43 -0000 Wall, Stephen wrote:=0A= > Could the as yet unused options param have a bit assigned to trigger the = new =0A= > behavior? Inform the linux community of the addition and let them decide= if they=0A= > would like to adopt it as well.=0A= I'll assume you are referring to the "flags" argument when you say "param" = above.=0A= =0A= You could. However, since the Linux man page says it will return EINVAL if= =0A= the "flags" argument is non-zero, you've still introduced an incompatibilit= y=0A= w.r.t. the Linux behaviour.=0A= It does make it clear that copy_file_range(2) will have the non-Linux behav= iour=0A= when the flag is specified, which I think is a good idea.=0A= =0A= rick=0A= =0A= =0A= From owner-freebsd-hackers@freebsd.org Sun Sep 27 02:55:55 2020 Return-Path: Delivered-To: freebsd-hackers@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 284323E9D7D; Sun, 27 Sep 2020 02:55:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzVdk16Rfz4Pv2; Sun, 27 Sep 2020 02:55:53 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f178.google.com with SMTP id t76so7449027oif.7; Sat, 26 Sep 2020 19:55:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MSNJCzZoy1fgm/a8nqe243dFVDzmnq/D3cnvhiAAhcQ=; b=VTqrTZ6mSFwtxdHuHhYIs6AH+QdFmPnqoLSAgUNqHgqcbAERP5OcDxDTMPiGFWv1+U Hn5xffL3eqlIEPaHckXBTrXxuJEmnnub8Reo5UIuNi9gzLj8to7bBBQzS2bQKpXTAKW2 1xDWWkgZyDxbYt4UTbrniFaLZ2w8k7gsTqc0rI+Iv72691azNeS/B5+CwO9lCJ28vdv4 0nZF9Rlv5WbGvTV3EUZvdZN1w0iHxQJvuKnnHPkrW/cWWadU/7X3CF8nQh31+3Da3kSt 7VLPypcnJhwVUlHbTLaaHyp0v/8Z4N6OKQ45huw7pkeN6T5BtgtLdOzrRHedbPtoh2Aa zckQ== X-Gm-Message-State: AOAM533LWv/JCzR9icGF/2MVeZgUElk3oO5Ds5typCIprkrISbpcuEY5 aLBmqXXMdAkCctIt6WjzBOQGV7LABh7TTsCO2WE= X-Google-Smtp-Source: ABdhPJwh6GoKfjO40kUJVFVk09DjoR9YkDVAsrtRLaxcz/Z1dIqIL5M2dEqy94gZ1/26/+vdRUBtMqJ2lBmPI8qImqI= X-Received: by 2002:a05:6808:555:: with SMTP id i21mr2491746oig.55.1601175352478; Sat, 26 Sep 2020 19:55:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 26 Sep 2020 20:55:41 -0600 Message-ID: Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? To: Rick Macklem Cc: "Wall, Stephen" , FreeBSD Hackers , "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4BzVdk16Rfz4Pv2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.178 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.69 / 15.00]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; ARC_NA(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.013]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.70)[-0.698]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.178:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.178:from]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 02:55:55 -0000 On Sat, Sep 26, 2020 at 8:52 PM Rick Macklem wrote: > Wall, Stephen wrote: > > Could the as yet unused options param have a bit assigned to trigger the > new > > behavior? Inform the linux community of the addition and let them > decide if they > > would like to adopt it as well. > I'll assume you are referring to the "flags" argument when you say "param" > above. > > You could. However, since the Linux man page says it will return EINVAL if > the "flags" argument is non-zero, you've still introduced an > incompatibility > w.r.t. the Linux behaviour. > It does make it clear that copy_file_range(2) will have the non-Linux > behaviour > when the flag is specified, which I think is a good idea. > I think it's just syntactic salt. Why require extra work for so little purpose? My opinion is that if we can make it work for character devices, we should. From owner-freebsd-hackers@freebsd.org Sun Sep 27 06:21:58 2020 Return-Path: Delivered-To: freebsd-hackers@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 0A63F3F1137 for ; Sun, 27 Sep 2020 06:21:58 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzbCT1NfNz4bGx for ; Sun, 27 Sep 2020 06:21:56 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9F7585C0103 for ; Sun, 27 Sep 2020 02:21:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 27 Sep 2020 02:21:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm3; bh=jeauM2YtiEXMSOtDF+gxjAVdfXkxGtoAOltQjtmm8Y4=; b=JrW0MlLI z4SatvBujZ9xPZ6Zw2vi5L1fmNBD9Y7K23TMyAEPzDAVUZ6EODuKSXCU9TRGPrlz H6TbDbliXIbz9/v710Ton92HZqileQyYJMGDxGNOB33jqbWS7OApbZAnDoLne+OB JNtqM+8m7AtZ1s2vxfVUYI3rOkz30GG0hwEQmLckPfwHgliYuVINOQtc4nM3VErs qiK2XejdSmjBdFAwBlVOjRGy2Eee7ELkBUDZYP1fUipMjEEh3y99+a6+JiZhjclR xnFsPIeRedIvCoTPNKlLiKqQ+B/iGUyoWaq0BcjS8MYyQ/2O7hAlKib6Xfge+Wkt UZWDyHo6QTpRbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=jeauM2YtiEXMSOtDF+gxjAVdfXkxG toAOltQjtmm8Y4=; b=Y2tU07WmUo25t/RjG0PVV4TecJgnxGphIMR2ngDqrjA96 syM+f0ubQhQG6QiQDmnQIkmC9n9iqnvEadR2j764suCL6hKFanUxKpolUlX7ZDvh aIPuY3Hy2RrqlZCSdJ44H7t7pEwWbw0q6jlCawaBGvcUxK5yIZS32hhktIRlZDMq WCGGW/uBEb+turDn+oQO+uRgjRQc7OESr6WLpVV/WPYO0eR3YGfL1fQZmzTRu11c iuNG/zQI3DBq/PeoZf6QJ1N9rhtF0bz3Vi+H0+HQm8hKEC9Jyt2+qmzOedMYRsf+ msv0e9J5ZPPZ2ht3IxGnCktyyQIIzYLjqh+wKidQA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefgdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehgtderredttd dvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiihgihs thdrnhgvtheqnecuggftrfgrthhtvghrnhepkeelheefgfdvtefgfeelgfdvkeeuveevke fgtdegveehuefgkeevieejlefggeegnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhg necukfhppeekvddrjedtrdeluddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: from bastion.zyxst.net (bastion.zyxst.net [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 11395306467D for ; Sun, 27 Sep 2020 02:21:55 -0400 (EDT) Date: Sun, 27 Sep 2020 07:21:26 +0100 From: tech-lists To: freebsd-hackers@freebsd.org Subject: private freebsd-update server - possible with -current? Message-ID: <20200927062126.GE54660@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UnaWdueM1EBWVRzC" Content-Disposition: inline X-Rspamd-Queue-Id: 4BzbCT1NfNz4bGx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=JrW0MlLI; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=Y2tU07Wm; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.28 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.55 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.01)[-1.007]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.85)[-0.853]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 06:21:58 -0000 --UnaWdueM1EBWVRzC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm not altogether sure which list this question should go to, so please accept my apologies in advance if this is the wrong place to ask and direct= me elsewhere.=20 What I'd like to do is to run a freebsd-update server for some low-power boards that are tier2 or tier3 arches *and* for various attached hardware reasons need to run -current (nodebug). I'd like to have the=20 freebsd-update functionality missing from -current as it stands, so that a full rebuild of the image isn't needed. I read with interest https://www.freebsd.org/doc/en/articles/freebsd-update-server the article is old but the start of it says it was last updated recently (2020-06-28), so still valid? so I'd like to ask the experts here: 1. would this be expected to work with -current? Looking through the page it there's lots of use of patches that pertain to following releng. My use case doesn't require that. [1] 2. will the server build/run under other arches? I'm interested in arm64 for this. [1] 3. can it be made to cross-compile with native-xtools? [1] ultimately what i'd like to have is a freebsd-update server on rpi4/arm64= =20 building for arm[6,7] arm64 and mips64. On the low power board, run freebsd-update as usual, apply updates, reboot. [1] right now I'm only asking if it's possible or if my idea is flawed, or = if theres a better idea. thanks, --=20 J. --UnaWdueM1EBWVRzC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl9wL3kACgkQs8o7QhFz NAXrRg//fADpCMQKIvOHKPMgK0eCpUJ3bw+CUfnMNvOrpk9RTV6OySZiF3R7PtYD c6MuqpDyl8QeIZQVa31N5lvSYeUA8Gd+THtnBu2ymL8r/6+o6NIUHMzcqhMorVTx fMiqKgzks+A1UO7ju9VU7nqg5x/JPDfA2fvZIrk7M/+fuLNAbB7UMyFJ4toyHuls /Vr+wZO1sui2eRHH9AEa2VgO9g8s5MsL7W5j8nVdAmiDI2EEoe5J9sQbbpYAThX5 MBf3Up+mO5xY3uwCObm+/6OPN3sR+MvFNKkQhvpSpITRrO/3cKQw0V788pa/T++/ VMZ5flHGF8zESG25hzEUDIsA4t7fQV/7JBZkn2sWleb0UEdMDnPq9veJlFhQ+F8d xoZQ6lA//I2WEQBMSVIJzAC0ytsXvLo3VT6SBKAezlo/JHucz/qspTZheFGaOG8B 0lvEFQF3L0KuGgTq41SI/sjzRtBNCYf802qxYQNvxEyAGSZpgoy5PVsymmW4ukWx D0recGiOgofvJJPWAiSmWKlG68glOxY0oF378Gzd8WIFazwzh198wj6hcfD2Jfol fOr/iQw5ojp3raJIwyypGxU7ue0qr0NN7NN+1AFRARrjRW2JFKhbJrSxe26gvn1K 0WYmP2KWvQGA52XGB4wm8ndtXQtd7Bkq+c6V7P8H06otJ/k1hn4= =l5JI -----END PGP SIGNATURE----- --UnaWdueM1EBWVRzC-- From owner-freebsd-hackers@freebsd.org Sun Sep 27 08:56:33 2020 Return-Path: Delivered-To: freebsd-hackers@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 18A313F3873 for ; Sun, 27 Sep 2020 08:56:33 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bzfdr6pzcz4k0H for ; Sun, 27 Sep 2020 08:56:32 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 4Bzfdq4N8xz3nDX; Sun, 27 Sep 2020 08:56:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id 7cDYQIQ21kDn; Sun, 27 Sep 2020 08:56:31 +0000 (UTC) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1200::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 4Bzfdn6WY7z3mQw; Sun, 27 Sep 2020 08:56:29 +0000 (UTC) Subject: Re: Informative dmesg logging? To: Steve Kargl , freebsd-hackers@freebsd.org References: <20200926193357.GA77746@troutmask.apl.washington.edu> From: Niclas Zeising Message-ID: <2df28f9f-39be-1d23-be57-738c758404a8@freebsd.org> Date: Sun, 27 Sep 2020 10:56:29 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200926193357.GA77746@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Bzfdr6pzcz4k0H X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:36236, ipnet:176.58.89.0/24, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 08:56:33 -0000 On 2020-09-26 21:33, Steve Kargl wrote: > Just updated to head including replacing drm-legacy-kmod > with drm-current-kmod. During boot, I see these mesages: > > % dmesg | grep "local kernel" > __pm_runtime_resume not implemented -- see your local kernel hacker > pm_runtime_mark_last_busy not implemented -- see your local kernel hacker > __pm_runtime_suspend not implemented -- see your local kernel hacker > pm_runtime_get_if_in_use not implemented -- see your local kernel hacker > __pm_runtime_resume not implemented -- see your local kernel hacker > kmem_cache_shrink not implemented -- see your local kernel hacker > register_oom_notifier not implemented -- see your local kernel hacker > kmem_cache_shrink not implemented -- see your local kernel hacker > kmem_cache_shrink not implemented -- see your local kernel hacker > kmem_cache_shrink not implemented -- see your local kernel hacker > kmem_cache_shrink not implemented -- see your local kernel hacker > kmem_cache_shrink not implemented -- see your local kernel hacker > kmem_cache_shrink not implemented -- see your local kernel hacker > register_acpi_notifier not implemented -- see your local kernel hacker > async_schedule is dodgy -- see your local kernel hacker > pm_runtime_set_autosuspend_delay not implemented -- see your local kernel hacker > __pm_runtime_use_autosuspend not implemented -- see your local kernel hacker > async_synchronize_cookie not implemented -- see your local kernel hacker > check_move_unevictable_pages not implemented -- see your local kernel hacker > > Other than filling dmesg output, is anyone interested in this info? > It's debug prints from drm-kmod about things that aren't implemented, but not needed working drivers. We are aware of them already. Thanks! Regards -- Niclas Zeising From owner-freebsd-hackers@freebsd.org Sun Sep 27 13:30:50 2020 Return-Path: Delivered-To: freebsd-hackers@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 EA4F93FBE4A for ; Sun, 27 Sep 2020 13:30:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzmkL03XLz3WJL for ; Sun, 27 Sep 2020 13:30:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f52.google.com with SMTP id h17so6998459otr.1 for ; Sun, 27 Sep 2020 06:30:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ys7I3Cx6DhiILAspgi43IHMXW+3o6pW614PXNLkELow=; b=B1TlBQHK0RTSFwG61WKGzvUGMzFfNTZqeoy2up49oWKy3hw8HGfQZNaK8znwozvI5s 0p9myXtbjGEi6OR5Fw/PJey0peO4M8yZE2Xu259a6gbePRSnVwsZ9yJ4AtsXt+Q1WZYR LSu0gOVxEaxEnNoMbRlf+MW06ePy+Qroe0ZJ5PQjevhvGMdAPRsZQvdTxhr/CaeXvweg 6tsb9WYpbGEeipho1NMCErCQjFeJG10tVusJVewUWKYSWUlXYGSUzqXI9bOz6FevhcRv AGlyZRhRQaZP88Lsg4uQU+so4vD0QSQj48amjFTBKviJGqrF7BEAWEu359oCGyHCuoMe CHsg== X-Gm-Message-State: AOAM531iutKW9jLROEYHsnbt0CUndYWDCmbylocbD4ygFaw7cz/GkVXm zbJ+aEcM2K1H9JVrRTmChDEt4CcEX3fS2heuM2H3oXRg X-Google-Smtp-Source: ABdhPJzmSckVUiByI+mqcROYDeZrv7ei+VrhvQFQzlpeF0P8fXwILfBbdPF0xm7ORv0pgYRG2z/VvtFauGkQ/WraOq0= X-Received: by 2002:a05:6830:1e30:: with SMTP id t16mr6233441otr.18.1601213448671; Sun, 27 Sep 2020 06:30:48 -0700 (PDT) MIME-Version: 1.0 References: <20200927062126.GE54660@bastion.zyxst.net> In-Reply-To: <20200927062126.GE54660@bastion.zyxst.net> From: Alan Somers Date: Sun, 27 Sep 2020 07:30:37 -0600 Message-ID: Subject: Re: private freebsd-update server - possible with -current? To: tech-lists Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 4BzmkL03XLz3WJL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.92 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.52:from]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; NEURAL_HAM_LONG(-1.01)[-1.013]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.07)[0.075]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.52:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 13:30:51 -0000 On Sun, Sep 27, 2020 at 12:22 AM tech-lists wrote: > Hi, > > I'm not altogether sure which list this question should go to, so please > accept my apologies in advance if this is the wrong place to ask and > direct me > elsewhere. > > What I'd like to do is to run a freebsd-update server for some low-power > boards that are tier2 or tier3 arches *and* for various attached hardware > reasons need to run -current (nodebug). I'd like to have the > freebsd-update functionality missing from -current as it stands, so that a > full rebuild of the image isn't needed. > > I read with interest > https://www.freebsd.org/doc/en/articles/freebsd-update-server > the article is old but the start of it says it was last updated recently > (2020-06-28), so still valid? so I'd like to ask the experts here: > > 1. would this be expected to work with -current? Looking through the page > it > there's lots of use of patches that pertain to following releng. My use > case > doesn't require that. [1] > > 2. will the server build/run under other arches? I'm interested in arm64 > for > this. [1] > > 3. can it be made to cross-compile with native-xtools? [1] > > ultimately what i'd like to have is a freebsd-update server on rpi4/arm64 > building for arm[6,7] arm64 and mips64. On the low power board, run > freebsd-update as usual, apply updates, reboot. > > [1] right now I'm only asking if it's possible or if my idea is flawed, or > if > theres a better idea. > > thanks, > -- > J. > I don't see why it shouldn't. I'm currently a private freebsd-update server on 12-STABLE. The catch is that freebsd-update refuses to run on anything it thinks isn't an official release. So I have to make my own releases. To distinguish them from official ones, I name them something like "12.1-MYNAME1", and then I have to modify the freebsd-update script to thing that "MYNAME1" indicates an official release. -Alan From owner-freebsd-hackers@freebsd.org Sun Sep 27 13:49:23 2020 Return-Path: Delivered-To: freebsd-hackers@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 3ADE33FC54F; Sun, 27 Sep 2020 13:49:23 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on20605.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::605]) (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 4Bzn7k2z1jz3XSk; Sun, 27 Sep 2020 13:49:22 +0000 (UTC) (envelope-from stephen.wall@redcom.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QVcVIAhFo+qBM2N57FPgxK8m5Y2bko3emTEeS37Cq633yyXHk56GzI/7gw6DdjyB5Ske3H4+1CMmK2e5mX3xxCAMtdC9dVWf5GZwp1OhnAjWBqU/Hb1QUuL9Yp7ZRA2q1ZbNfx4/VTHaqttnlkJSiXQqjGAbtTj6+g/pch+hW7M/xlqVMu5lSoSzFHnK8rK2rbcIlpCTlmaqGgQQMa1LiXtVFXpXYn/alViowh/LO7gtw6YOWy7jsaqe8ODc8Pzl+zPw0/u2ra6uZEVVM61HrFNvpmarcTqTDYEauD12KwssKOazvKB9SRNzSvSvc0WboeVYoCvZLbsZNNbgsKGcNg== 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=xpR5dSngRQsQdGc8U7L51PpT5ESKqao+XUOk8zpzCsY=; b=i8vlHJdkAL2KCMR+fwabKkieA4FthiY09fNwPxN/Y9qJ3a5bv8f3mcLL3SEGHCIv/N7Gxoh6Lv0vx8OrvwCwp4ha2u/KPXE5HHCqDlPZiAK29Q7cNYLLo7ujJX1QtcoSdxk05PtYj3cVqMwNMnUDYYoTknR+V16q3Q/HwHFXmXIWnWrc89/zkymPIj5Q8B5LjO4BDSIaUQVH7oofCtIqafu7RuFAEyR9WyN0WqCbYigR53Gb4C8lYJaV9viJYtoXDjx0Jbb8ug0082FYuQUz5TDUm8SU9rQ+JE3TjZTYQ4R+cuMoLBledVjjM/2tPBUTiTNbRPSq0i1PyyspA+FluQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com; dkim=pass header.d=redcom.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redcomlaboratories.onmicrosoft.com; s=selector1-redcomlaboratories-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xpR5dSngRQsQdGc8U7L51PpT5ESKqao+XUOk8zpzCsY=; b=RsdkVKHpPQnr0Xyu3ASokoH9o91wvvzFNNlwhnL/CT346ZKMo/OODw1kBnNEISxaEaOrgl+mua/jIKUPvdRie9ooC4ytHy+9fXITllvdV+BSLpqbNCbrFZvLywBxwm6prlAAbIJSDGIrvAZC36+L4aRlQI+FN1B1kVu4VjJzwdfwN+4QPr0URpeCoA4DM7kdxyobZGpoZGsl4EE/Th9IT/j8/wI8lelqUCTM9rem03v00aSWbusOdy6LslIJTNUObAHsy4b56tpDTf8Ny0fyXRc/ARQONFmBTvg7gdzF3XGWJedelTy25YbWxz+QiZkA59ZK883iP18N2YXSqLjM1g== Received: from MN2PR09MB4876.namprd09.prod.outlook.com (2603:10b6:208:223::18) by BLAPR09MB6785.namprd09.prod.outlook.com (2603:10b6:208:2a7::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Sun, 27 Sep 2020 13:49:20 +0000 Received: from MN2PR09MB4876.namprd09.prod.outlook.com ([fe80::4039:3c3b:81b5:cfd8]) by MN2PR09MB4876.namprd09.prod.outlook.com ([fe80::4039:3c3b:81b5:cfd8%6]) with mapi id 15.20.3412.028; Sun, 27 Sep 2020 13:49:19 +0000 From: "Wall, Stephen" To: Rick Macklem , FreeBSD Hackers , "freebsd-current@freebsd.org" Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFK6l7nDvmgAAr7eCAALVoTg== Date: Sun, 27 Sep 2020 13:49:19 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.48.135.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10c88a65-27da-4dee-29a6-08d862ec2247 x-ms-traffictypediagnostic: BLAPR09MB6785: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nvEPrIu/eQ79xC28pJTS5Swt/mjvJRnhZpchRfcagRi6MSo7zNJVj55meW0oznC8uOsq4s19DLjR4Lv/oyEU/chs5p2BNlyO7GiQ6IVVQqIiQ8vNH9bdFwiB3B8zy6G2jtw0cXNvtuaGPh1gcVi91nGQbD5PBblE4ifDP7MvAY+OhXdzYZGVg0ftT6a+2nFcmyyZTif+SXUVP982EiBY5Xbhu3zMwOdDkkxvbqxsURAOMUDQWrMMFS7+02O02BchjD/DOYrZ32nWr9evoBWk8PUjNp1KgBSB9EKFcEHaw0OOrx/OZIcYGfdypg8hNSqgeO5VWcgtfNfF9aFmwj6b+Hp4rdgLI1b0sqE3ncpZKUdj0l1EmBp0Yd+8nFVGc6Q5 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB4876.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(39830400003)(136003)(396003)(346002)(66446008)(66476007)(52536014)(91956017)(66556008)(7696005)(8676002)(33656002)(5660300002)(2906002)(8936002)(9686003)(478600001)(86362001)(26005)(71200400001)(55016002)(64756008)(186003)(66946007)(76116006)(296002)(110136005)(316002)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qFX/SimvfzZg43LBda/rtYZenhnAa77a/RZ4Wjop5e0US1bfFL5NsnXSvHFwdMEhNUuey94rhg88jUeoxF5cezJWSwGYlBMmE88+KAyUMt1kugQJsCftBAvLvStFBVhEJ8ZOUZltjTwmq2O44VE+SEJJx05MZIBOzd2g6FkUNw2hM6RYhXNHBYLMoksmESBei/fr+E3sBwTs/HDiVLcucHN/C2c2K7EgvgopYIUb7hJ5HwGE87bVJYo7agAWKN5szOZtzj4eyhqpYplBOoR7RcaqVOALVLc6tD0sYr+cyhqaR//32ZdC5wskD+7oa1uPdzbOJl+itBcmdnzP1OyBpeqCJypdfxFFzSBAfblTuuB4uLXDuAwaHtKoLIT70g3XNliz8OxNY31zC0wHqH5HDAjE6j1XSz9OFA1ZfYIq8y+NGGW2C1rB645zbTgb4r0J2IaTSsxgClfnAUWW6N06xhGfc+lhnXzCNBAhsl7VoWP+Z8htcUE9SoucXRfU5YAVFWSV1kVdjTuNjg2sc9yb/Ex51DkhiqXdo7pBccpdBKn/JvVVHrL3RqcOPD3whghlYy8RKtzOrZGWM8NQxxJvUgIIvOakDz04OsFdphzjIjFSl2fqhIJ/EIpE50jk63QAiwzrRUFNYYxTA3rOr3S2Ng== 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: redcom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4876.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10c88a65-27da-4dee-29a6-08d862ec2247 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2020 13:49:19.7358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VLzYLQGQn9D+Nl4FTdhNlbDNWsnYAr3ROakF69Mer8CHTFgQgB0TC+9CkkqxOvCfVdFarSN5hdmmJ3GzLW6pEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6785 X-Rspamd-Queue-Id: 4Bzn7k2z1jz3XSk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=RsdkVKHp; dmarc=none; spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 2a01:111:f400:7d05::605 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com X-Spamd-Result: default: False [-3.15 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[redcom.com]; NEURAL_HAM_LONG(-1.02)[-1.021]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+]; NEURAL_HAM_SHORT(-0.63)[-0.632]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 13:49:23 -0000 =0A= > I'll assume you are referring to the "flags" argument when you say "param= " above.=0A= =0A= Correct, I was misremembering the man page.=0A= =0A= > However, since the Linux man page says it will return EINVAL if=0A= > the "flags" argument is non-zero, you've still introduced an incompatibil= ity=0A= > w.r.t. the Linux behaviour.=0A= =0A= This would be a one-way incompatibility, i.e. code written on linux will ru= n unaltered on FreeBSD.=0A= If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever, im= portant part is `FREEBSD`) it will be quite obvious that this code needs to= be adapted to other platforms:=0A= ```=0A= #ifndef FREEBSD_COPY_DEVICES=0A= #define FREEBSD_COPY_DEVICES 0=0A= #endif=0A= ```=0A= =0A= > Why require extra work for so little purpose?=0A= =0A= I'm sorry, I'm not sure what extra work you are referring to.=A0 Specifying= a flag on copy_file_range(2)?=A0 That's trivial.=0A= =0A= > My opinion is that if we can make it work for character devices, we shoul= d. =0A= =0A= Well, collecting opinions was the point, no? :)=0A= =0A= What's going to use this function besides system commands?=A0 I think I saw= `cp` and `dd` mentioned - I think it unlikely you need to be concerned abo= ut their portability.=0A= =0A= -spw=0A= =0A= From owner-freebsd-hackers@freebsd.org Sun Sep 27 14:20:50 2020 Return-Path: Delivered-To: freebsd-hackers@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 B7F443FCC48; Sun, 27 Sep 2020 14:20:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bznr15ZM2z3Z1L; Sun, 27 Sep 2020 14:20:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id o8so7056007otl.4; Sun, 27 Sep 2020 07:20:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HSgDPQJ/DVFSle5/qEn+0pp2/+CBLxzl8FleFedPxuE=; b=JNcktGBxpQD0iKsj/FZOcSBLawxn57cet2Y6HC3vnmN7LCqp8/e57QTLyh+3o5r8+w VPEeSDZx6srqAhJ9cU14We8LrM13z5Rwdj4WCSed5uN39p1VUbN7iKQRC6cKfcF8UBU+ dRUz7kISGbo8t2DEioC6P3/0VVLkIzE+FK7nEIKxbZM6gc+V3kN5U6vyJoQfA3D5C0Gd pKW4dI8JNqWgjbdljCENemDzzD0HughhmvsYYOoskXoN+HHJo2iROfTzG1ybki0yM2Kr dzK5M5AJmXBCegBOeG6IZr5wrvAXSc9NCzAzA/WQ+4ljmtZAR1XqlGv52xPq2EJ5ltom R2iw== X-Gm-Message-State: AOAM533QnM9+CYJoU+iEHV6eCRpVZgsJ5vl9jiQO4IbOijGT9TnaH+65 x0awEeVU/kJi/9acryZrFHF7TWFt9V2Edldy34c= X-Google-Smtp-Source: ABdhPJwTgQPY2NBamRDshrvXK6WiPpC1LeceDUAH/1vEOPzZn8j2NaZYaWhFXItDPkvpem9mRIFkTxNU4znxI2Y1sjg= X-Received: by 2002:a05:6830:1286:: with SMTP id z6mr5893487otp.291.1601216448720; Sun, 27 Sep 2020 07:20:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sun, 27 Sep 2020 08:20:37 -0600 Message-ID: Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? To: "Wall, Stephen" Cc: Rick Macklem , FreeBSD Hackers , "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4Bznr15ZM2z3Z1L X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.41 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.37 / 15.00]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.41:from]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.014]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.38)[-0.379]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.41:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 14:20:50 -0000 On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen wrote: > > > I'll assume you are referring to the "flags" argument when you say > "param" above. > > Correct, I was misremembering the man page. > > > However, since the Linux man page says it will return EINVAL if > > the "flags" argument is non-zero, you've still introduced an > incompatibility > > w.r.t. the Linux behaviour. > > This would be a one-way incompatibility, i.e. code written on linux will > run unaltered on FreeBSD. > If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever, > important part is `FREEBSD`) it will be quite obvious that this code needs > to be adapted to other platforms: > ``` > #ifndef FREEBSD_COPY_DEVICES > #define FREEBSD_COPY_DEVICES 0 > #endif > ``` > > > Why require extra work for so little purpose? > > I'm sorry, I'm not sure what extra work you are referring to. Specifying > a flag on copy_file_range(2)? That's trivial. > It's easy to leave out, which could cause a lot of pain for users who don't understand why their application isn't working. > > > My opinion is that if we can make it work for character devices, we > should. > > Well, collecting opinions was the point, no? :) > > What's going to use this function besides system commands? I think I saw > `cp` and `dd` mentioned - I think it unlikely you need to be concerned > about their portability. > Userspace RAID-like applications could use it for rebuilds, and they'll need it to work on device nodes. Userspace NFS servers and iSCSI servers could obviously use it. And since the FUSE protocol includes a COPY_FILE_RANGE operation, many FUSE daemons could implement that with copy_file_range(2). -Alan From owner-freebsd-hackers@freebsd.org Sun Sep 27 14:34:00 2020 Return-Path: Delivered-To: freebsd-hackers@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 583113FD26D; Sun, 27 Sep 2020 14:34:00 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2040.outbound.protection.outlook.com [40.107.91.40]) (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 4Bzp7C17b6z3Zlw; Sun, 27 Sep 2020 14:33:58 +0000 (UTC) (envelope-from stephen.wall@redcom.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UuU/4QaqN+LlMUB4Da54cgCcrO/umMlWnDEzsFhC4yyplsTlLI9MPR0eL57t3x3x9X6attHypS7VGFpCMOG2Z26zDJlyjRhhk+Fv37+IrrZksQbiSZyLHkWvadR2Y3UZu/+SlVaY8S6e51/pU2tpgzOTlmp/fn81I/GD+X7pLL6hOC17wKF5IRf2uUZuFvkF2yU5qHBxQOUuVnXYP/gteuj6G0Rb0/z5x6e3wj4laoyfm/+V2SHh1Yije88WgrskWow9OxIkE1nxIhcoWbc2dcOunl3R4UTnAHkg09H007Hsd0E0JS6oUpPu0OmUEilq0zFg+XZe7dChp/5c/rqaBA== 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=TwQuDplX6r6G2dD9NMwCMFm8cXrjB5s9zhB/CZyC4s4=; b=JKgjAQb+gG9BC2LUcg//76UkxfC07vuA1fdJPY4QNBfbijjEugrJXsqHMN6FRtQtYMmNRgf4sEY76K8VUEtcYSC3x3n8M4QVb3op22EIElEDeGA2ob4EL6BCwr0gm0TOtd7v1MGuEtNAQ+B5FfYvQQsaEvC6L0ra54souNbU7zVn1yNuyIHyVqJvnCom6BrEIsUC61asUB9yfQmGNqz0nZOhQxEv0BqhF43YmVQurlocFix+Mrj0P6eJqJd8E02otZaZUvDH9PiOvDgpuwMwaFBgmvUdk9qxNQy273Z9dmqq3EPfgRSWt7oCZm6HFFouDRTSSbG5rW0Dgy3uPfK0UA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com; dkim=pass header.d=redcom.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redcomlaboratories.onmicrosoft.com; s=selector1-redcomlaboratories-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TwQuDplX6r6G2dD9NMwCMFm8cXrjB5s9zhB/CZyC4s4=; b=MbO2R5rNtxG7vIXNCW2dRDinzb7Qxmarlm/u4H7jnxYB8xOALyKC8OsyOmVrZ6NxaDOQDbJQpcKBg9pCoNlzjlvdmBmbqHZ+w/qauJLTBS7s9hm0HAAFOTnxfKhTPXt9/++XkGvNoeqTWfxdMrxrYUxUYxktXr6ZsICGwexM+yMBhWo9VdN2ndtOHuSUIjLrsZRry/yY/KXM0FiE+o/JvYBVqCm1LObvaHq1PmTNG8OdlwlPcgfQCm3cUTkN2JM+CsB9vhsbWpcs4ox6d862L9aWJBh6pBFjv9RwWdlLYHS3l3OTnSZgaF01PXYHIk8rvJVYE1EuAzhUEwf9W0lGpg== Received: from MN2PR09MB4876.namprd09.prod.outlook.com (2603:10b6:208:223::18) by BLAPR09MB6241.namprd09.prod.outlook.com (2603:10b6:208:2af::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.28; Sun, 27 Sep 2020 14:33:57 +0000 Received: from MN2PR09MB4876.namprd09.prod.outlook.com ([fe80::4039:3c3b:81b5:cfd8]) by MN2PR09MB4876.namprd09.prod.outlook.com ([fe80::4039:3c3b:81b5:cfd8%6]) with mapi id 15.20.3412.028; Sun, 27 Sep 2020 14:33:57 +0000 From: "Wall, Stephen" To: Alan Somers CC: Rick Macklem , FreeBSD Hackers , "freebsd-current@freebsd.org" Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFK6l7nDvmgAAr7eCAALVoToAADHSAgAABHxE= Date: Sun, 27 Sep 2020 14:33:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.48.135.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6dcbafc3-ad79-4acb-522d-08d862f25e05 x-ms-traffictypediagnostic: BLAPR09MB6241: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y+miXfQPxb5Kw9BOYeqkxixR8ma88z79DyibkczZBLqoiUV7uLSBtFq3wOpFaAIATbkvmtZpRcfXcsLphG0wPwKHkb/6R2NNE7B40DrAd1zadJC1Q+cNRPPjiQslWpTDPgasdL4RL2hKy6TOoVQ/NH+Fl7qd2+wRsyyRKfhxO1aQJxnWkVwQvfvSrQq4rVxUmUdOF5+TbhEpqElBgDQIU5OfpCi4ILSERYxuOgJHTqyyL07ul40eVWoFanG8bOQlXFl0LMkOI/FK/iR/gWWv87TgD1J5R7y9CBuamsOhZpcXpYPyuMq9U365r09Oo38xXtk8e6NlteYWPk2oSwilgsc2F0mt7zBdNvEiSuY1q4k9WeQ1T6mDU58wLRX/qA68 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB4876.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(396003)(39830400003)(346002)(136003)(2906002)(66946007)(91956017)(76116006)(5660300002)(9686003)(55016002)(19627405001)(4326008)(8936002)(8676002)(64756008)(66556008)(66476007)(66446008)(316002)(478600001)(6916009)(52536014)(6506007)(7696005)(71200400001)(186003)(26005)(54906003)(86362001)(4744005)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VTC2bRBQ2Xj1D45RSSfbyMPM4U2pciTd06zFXZuwLOSllwP0cl0tRYgpaH1pbvbKVhXvFIFImDjOOIy6OcCgSI79u9nm64MJ7/ZhEPJKIpLVeDG6GRLwYt5UOdbPmPPkAoa7zYjFYIyX44YKExETvFDJVmisxGbhEjThHFFRuobc2DIYpT2BuH8JkF+9nMWVAYFV3ou9aztbQOOXXmc9vPJTCsKIPXHrfjF0y0x2zOQB2/wVmqLsPOWsVEP9fBUID1x7+1EvYBkAenVehDXZ87HkqmUUtm8o1/3Mf6t3ZR8gFF5zu8BHj+WA6etl/FA0W//2+pKQyXsRjWBM5b5T+qNEMFWtwIQ7llq8ckdJlIVsfZPQ7283PDSlVnv7qEy4x0bGZrj2wOrA+y98I5/ZcVs3vqQCOljqBHvFMz1ZZApRAeRi5FyJXboU/atDxVEauOlxRtcYcGduGm8G54fhxhK9/RR6j4QGXGWibpFQxdM9nsl7gavHhjpNxJ+6bf8XilgYbdQzkM1RyAkFDH2o6/o5sIdfov73xngThyCOfWcXEbKZCOJ8tRPkFUw+wYF9kHe6Gtf/sR9f6nHEg17bxcX8E9uAcgqX91zyfRuUsz14f0v8HGFytQkZKx8gxwpF/OOm0VEnotuwn4ojTdgz2Q== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: redcom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4876.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6dcbafc3-ad79-4acb-522d-08d862f25e05 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2020 14:33:57.1003 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pVcHB4R5YhxVbh43t01fhhZals1rNufhVaJqREIg9nR8/b9+NmuTs6MElJJgyqiL/iykJ6WzG3LHHrkRzkv69g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6241 X-Rspamd-Queue-Id: 4Bzp7C17b6z3Zlw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=MbO2R5rN; dmarc=none; spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.91.40 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com X-Spamd-Result: default: False [-3.59 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[redcom.com]; NEURAL_HAM_LONG(-1.02)[-1.018]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+]; NEURAL_HAM_SHORT(-1.09)[-1.086]; RCVD_IN_DNSWL_NONE(0.00)[40.107.91.40:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.91.40:from] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 14:34:00 -0000 > Userspace RAID-like applications could use it for rebuilds, and they'll > need it to work on device nodes. Userspace NFS servers and iSCSI servers > could obviously use it. And since the FUSE protocol includes a > COPY_FILE_RANGE operation, many FUSE daemons could implement that with > copy_file_range(2). These will need to have conditional code for Linux and FreeBSD anyways, if = copy_file_range() behaves differently, and the developer wants a portable a= pplication. It seems to me that unless you get the linux community onboard = with making a compatible change on their platform, you'd be better off nami= ng the FreeBSD function something different to avoid confusion for cross pl= atform developers. Though, unless they are well versed in FreeBSD, they wo= n't use it anyways since they are writing code to work on Linux, and that c= ode will also work on FreeBSD, given copy_file_range() compatibility. Just my opinion, don't feel bad about ignoring it. -spw From owner-freebsd-hackers@freebsd.org Sun Sep 27 15:16:50 2020 Return-Path: Delivered-To: freebsd-hackers@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 8F17D3FE0A2; Sun, 27 Sep 2020 15:16:50 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bzq4d3nmWz3cFP; Sun, 27 Sep 2020 15:16:49 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x441.google.com with SMTP id k15so8944103wrn.10; Sun, 27 Sep 2020 08:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nYAWEbKSLZu/2ZxBG1Do56H/lS5xBsAeuocCuW1wpc4=; b=NarcUtEjCbq4sUStx3Rj+9uBuumt93ZOjJuuuYiZMEDRJsaq9q5lTrO0ZL0zEpVrqa Z1w5XUHVOyDC9Wq65Kr1kPrgQ80tOdtvqqs8yQMK8XsHaWwRSDwH3NwoG5f/D9srkF28 AGjVNOvemKY2bPdj7OQvR/jXmkVssw7zCv6m3zzTspqEgw6oE4gsVR5AwZqPXoeQTNpX L6JZZD0zHUHwS+3MG8XWzicVVsmdnVa0QSAKYlgmYAszLneflcDBDNqCU5UrqXk/bn+8 861WD96LNQo8joLFDYt1CDiIGAVWtaIu+YmJRYY9NGgYvUfINee6R9FgJHAtWkAjBt7M kNYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nYAWEbKSLZu/2ZxBG1Do56H/lS5xBsAeuocCuW1wpc4=; b=kRarqAcd7w/4ZppqxzJUXX4u0umjuOc/RSXxyF20E/nUT2kmCvajOkoNJzou3sMfC8 9XXvdPR4Z8N0ZYBY/XZqKW/SN0QvDGvpyCAmXrs77hPz6W1f6FCqykD8/O0PWabTE0UP eQUmKSzkQbs9j1ImfQUWZxHO91GQ97wEttcQhlO10MaiAJWQTeD4FouKS8agyuqnI1mi eUZBv9E9KI7Dxjua5hqgakGyy6DhwmIDR2sytXWwJBXFm4wcV170NJ/Y9+eDvojPAQiu 78+wFQ3ZI4oZ7kLX3KbVEA3SgYSfospONFZ6q4IrzaNpKxSx/6RJFFQ+GRuNB4X/jICH 0mpA== X-Gm-Message-State: AOAM530I16Q5ABs3Z+lih0KtK7IhqPR14UotWXpEaJQBqkImb7UQp3S/ mZcpkpxgAHgTVW/O6gSKlFZKKlrt5exNjnU0qFp0lf3zNOw= X-Google-Smtp-Source: ABdhPJxqID61zylEJYpBYeaQ3JHLbpBDsDgNQgK+wHcKtt22kvnTZVIMVbzAksfgpIVfpVdSFuVHmrznruJyusFuiZg= X-Received: by 2002:adf:e84a:: with SMTP id d10mr15369002wrn.66.1601219807770; Sun, 27 Sep 2020 08:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6000:187:0:0:0:0 with HTTP; Sun, 27 Sep 2020 08:16:46 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Sun, 27 Sep 2020 17:16:46 +0200 Message-ID: Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? To: Alan Somers Cc: "Wall, Stephen" , Rick Macklem , FreeBSD Hackers , "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Bzq4d3nmWz3cFP X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=NarcUtEj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::441 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.57 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.02)[-1.019]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::441:from]; NEURAL_HAM_SHORT(-0.56)[-0.560]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 15:16:50 -0000 On 9/27/20, Alan Somers wrote: > On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen > wrote: > >> >> > I'll assume you are referring to the "flags" argument when you say >> "param" above. >> >> Correct, I was misremembering the man page. >> >> > However, since the Linux man page says it will return EINVAL if >> > the "flags" argument is non-zero, you've still introduced an >> incompatibility >> > w.r.t. the Linux behaviour. >> >> This would be a one-way incompatibility, i.e. code written on linux will >> run unaltered on FreeBSD. >> If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever, >> important part is `FREEBSD`) it will be quite obvious that this code >> needs >> to be adapted to other platforms: >> ``` >> #ifndef FREEBSD_COPY_DEVICES >> #define FREEBSD_COPY_DEVICES 0 >> #endif >> ``` >> >> > Why require extra work for so little purpose? >> >> I'm sorry, I'm not sure what extra work you are referring to. Specifying >> a flag on copy_file_range(2)? That's trivial. >> > > It's easy to leave out, which could cause a lot of pain for users who don't > understand why their application isn't working. > A FreeBSD-specific flag to a Linux-alike syscall is bound to run into a conflict at some point, making it a non-starter. > >> >> > My opinion is that if we can make it work for character devices, we >> should. >> >> Well, collecting opinions was the point, no? :) >> >> What's going to use this function besides system commands? I think I saw >> `cp` and `dd` mentioned - I think it unlikely you need to be concerned >> about their portability. >> > > Userspace RAID-like applications could use it for rebuilds, and they'll > need it to work on device nodes. Userspace NFS servers and iSCSI servers > could obviously use it. And since the FUSE protocol includes a > COPY_FILE_RANGE operation, many FUSE daemons could implement that with > copy_file_range(2). I think the first thing to do is check what Linux is doing here, most notably they may have other primitives to take care of it and in that case would be best to implement equivalents. I don't have a strong opinion on VCHR support. I will note there may be Linux code expecting to fail with such argument. If Linux-compatible approach mentioned above is not going to work out, I think the best thing to do is to add another syscall (copy_file_range_np?) which can be tweaked however we see fit. -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Sun Sep 27 18:29:59 2020 Return-Path: Delivered-To: freebsd-hackers@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 7652E423D1B for ; Sun, 27 Sep 2020 18:29:59 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4BzvMV2cnKz44l5 for ; Sun, 27 Sep 2020 18:29:54 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 08RITleV012907 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 27 Sep 2020 11:29:48 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: Is it possible to exit the chroot(2) environment? Message-ID: Date: Sun, 27 Sep 2020 11:29:46 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Language: en-US X-Rspamd-Queue-Id: 4BzvMV2cnKz44l5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@rawbw.com designates 198.144.192.42 as permitted sender) smtp.mailfrom=yuri@rawbw.com X-Spamd-Result: default: False [-1.39 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.966]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.24)[-0.235]; DMARC_NA(0.00)[rawbw.com]; R_SPF_ALLOW(-0.20)[+ip4:198.144.192.32/27]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[73.189.35.76:received] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 18:29:59 -0000 This line https://github.com/rpm-software-management/rpm/blob/master/lib/rpmchroot.c#L155 calls chroot(".") in order to exit from the chroot environment. It apparently succeeds on Linux (this is rpm), but it fails on FreeBSD with "Operation not permitted", while executed under sudo. The chroot(2) man page doesn't mention anything about exiting the chroot environment. Does chroot(2) behave differently on Linux and FreeBSD, and chroot(".") is a valid way to exit on Linux and not on FreeBSD? Or what is going on here? I wish somebody familiar with chroot add this information into the chroot(2) man page. Thank you, Yuri From owner-freebsd-hackers@freebsd.org Sun Sep 27 19:03:08 2020 Return-Path: Delivered-To: freebsd-hackers@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 3CD89424A85 for ; Sun, 27 Sep 2020 19:03:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bzw5k2LFyz46mh for ; Sun, 27 Sep 2020 19:03:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2c.google.com with SMTP id f11so4329286qvw.3 for ; Sun, 27 Sep 2020 12:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u06zlxQeZdodnk2k8p4pcjm3iBdYRqUpSXbfa0NnLeg=; b=12x2qkRTa7d9zzojunTMOwkoPTtPjCapTuLonJ6YEVNEYcP3p7ZAsWv3tQbIBNtNfK PmOPiww0VU35R1A9/OunpBJdW8G8SXeT7f/Z1woLcSn7F37jSQiOFDTOEMi2Zl5816xX lf8cK0ZWRPIA4PyvPQMkwDQhXCrwpUGvj8OGezNJy4c2c4KTjMbeQpiMmw+eBePG2Yfy z2HlvuheQgr1fIx1Mqr/dS2npXTJC/ZlIHhdM5b3NJAE9yLXgTUdWJMEXa8WPGLyQ00S vR0D2J5B9IemCGbEsuq/WTk6xJnTUmsfVFGdO3/HeKmWfNRb0cgulrhPtLckACs7SYpr Nnbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u06zlxQeZdodnk2k8p4pcjm3iBdYRqUpSXbfa0NnLeg=; b=MszYr5w5bphmH+2VCiCO93viCXZc+jj1nuT+yn1UIGbwYptBhhWzkCnD5y7MlY9diD t2+AuxGFfAU80MvDG2J25VEmYsTA0VLl90jNcrYpIQt0zCVn/I9/ulwMtjWxGX5BlXLk w8L65xgPk/9e2fU7+Na0jAITNyutRhmx40C6HNPNXLCD+v+57lxC8UZpwblk+zBykB8C PPBu2NbEoxiVfXbYE1Ad8Y06qdas56q2n4wwp6CfYA7A+GRJP3ceY372CUrZ167HdcXg rFzpfDBOIAC6yEbr5IdgLs+Qk+TzguXGdh8kBQ/KPNSvDKpCzlaZIje1jlfY8nSVljM5 1RVw== X-Gm-Message-State: AOAM532RPufn6UFQYFRyOMGZgZgF8y59vPkzUMVuFDCmxNCtkologKfX ALrTWKQKJjmtQ2kZbUkzYaYpnqPHnjavKMzpEdjKexzZWAnQpg== X-Google-Smtp-Source: ABdhPJwEYBrJ/BMuPGBXjpXh/IOYFbOuWNuc6CRbP3HgmMMQvbzhz9Y31dPU5W4ZcgAGs4xQjilsGC7KhOok1cC0ufw= X-Received: by 2002:ad4:47cc:: with SMTP id p12mr8564423qvw.26.1601233385246; Sun, 27 Sep 2020 12:03:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 27 Sep 2020 13:02:54 -0600 Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Yuri Cc: Freebsd hackers list X-Rspamd-Queue-Id: 4Bzw5k2LFyz46mh X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=12x2qkRT; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.27)[0.270]; NEURAL_HAM_LONG(-0.98)[-0.980]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2c:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:03:08 -0000 On Sun, Sep 27, 2020 at 12:30 PM Yuri wrote: > This line > > https://github.com/rpm-software-management/rpm/blob/master/lib/rpmchroot.c#L155 > calls chroot(".") in order to exit from the chroot environment. > Interesting. FreeBSD doesn't allow that. > It apparently succeeds on Linux (this is rpm), but it fails on FreeBSD > with "Operation not permitted", while executed under sudo. > > The chroot(2) man page doesn't mention anything about exiting the chroot > environment. > True. Such behavior is undefined. There's no defined notion of exiting a chroot. It doesn't seem to be documented in the few examples of the chroot(2) call linux man pages I've found. Do you have documentation on what, exactly, it's supposed to do? Does chroot(2) behave differently on Linux and FreeBSD, and chroot(".") > is a valid way to exit on Linux and not on FreeBSD? Or what is going on > here? > Generally, one is not supposed to exit a chroot. :) Though jail(2) exists because it's trivially possible in most cases. I wish somebody familiar with chroot add this information into the > chroot(2) man page. > POSIX never defined the behavior (and it's been removed in newer versions of POSIX). Warner From owner-freebsd-hackers@freebsd.org Sun Sep 27 19:06:28 2020 Return-Path: Delivered-To: freebsd-hackers@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 92A83424A47 for ; Sun, 27 Sep 2020 19:06:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bzw9b4QKHz46XH for ; Sun, 27 Sep 2020 19:06:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x732.google.com with SMTP id w16so8169534qkj.7 for ; Sun, 27 Sep 2020 12:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b92q8Bztoen0P9eGRbfitOhnmzEvdm6yuKgWNEn427c=; b=hrjDP2JGltIs1YNjLoYPfj8aX/NIDLvixbV6W8Jlt7ZKrMuDUrebpZHBrRMBShX7aV mVmOT+Hv7bhS7nHZm/elgyAXxNxIQnXj9brDq2PkYujrxB24+fRJ3dRH9jXwB3RU9B85 bxgOYN7hBVenpn9ddLBlOvnNscqxNnhL3wBXw/h9i7Y6Noy3+VfAOX7xwcTxjbpXye2b 2Jx0vaKKI82IjaN7RxwBHvBIDUIT/aYK9+JnHNPSoZoL/qy7ofS0mhKXgeMFXxb78px1 Jw0apeY27AgEAGGgVxPsqQ2efzkzx1n8i5TsZ1T2FQvLLLpsbRKJyndD5HUu9Too8R8E a8Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b92q8Bztoen0P9eGRbfitOhnmzEvdm6yuKgWNEn427c=; b=QhfOvwiFgqqB22hjB3XSmaE3/W81uTCG3JG9s7eG1iPCkYSzxiaBAYSxdYXHUDiFL/ y5CNzb2x8a5XJzoCePoLw2vxGkDtPLlmadNw0bbgyBU2XqgmM4UErt5WI5C91AYqJ5aM 7cIZjzWGkdvQVOCV64eWkvEpovhAYd9EXOp5tFWYz6QO58dDxcdtg6mv1A4rbFbHlTUt lYhOM4JGnDQCNQpyfHLiSmrXLrZlwhD6c5iLPstBG28QK/U5o80vJW6Pf2u6tpOG+GUK p5VBM0QwT/q8NQn+Ar1t0B48hRQ5RPi5+dvm8dWa4mr0o9cCGGf6nebLwDxIyblNfTx4 3wFA== X-Gm-Message-State: AOAM533ZaY940wQ7mhcG+/96F05aA3l39b5McBG62tWfHy3z7TbDA5lT /6MdQlBYEUFn4efpM08X+m7/3y8Af5tSGzBNp1pQfcr5fIYvI1TI X-Google-Smtp-Source: ABdhPJzkOnuRIvYE0TJlYSwqecPx+p7n6v5hW4Ve7LSzqyZE5jpKbYgGZei0uZZHr52yPnCvqPYQTvVFHLVkUwipAN8= X-Received: by 2002:ae9:ee06:: with SMTP id i6mr8988456qkg.380.1601233586072; Sun, 27 Sep 2020 12:06:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 27 Sep 2020 13:06:15 -0600 Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Yuri Cc: Freebsd hackers list X-Rspamd-Queue-Id: 4Bzw9b4QKHz46XH X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=hrjDP2JG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::732) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.27)[0.267]; NEURAL_HAM_LONG(-0.98)[-0.979]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::732:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:06:28 -0000 On Sun, Sep 27, 2020 at 1:02 PM Warner Losh wrote: > > > On Sun, Sep 27, 2020 at 12:30 PM Yuri wrote: > >> This line >> >> https://github.com/rpm-software-management/rpm/blob/master/lib/rpmchroot.c#L155 >> calls chroot(".") in order to exit from the chroot environment. >> > > Interesting. FreeBSD doesn't allow that. > > >> It apparently succeeds on Linux (this is rpm), but it fails on FreeBSD >> with "Operation not permitted", while executed under sudo. >> >> The chroot(2) man page doesn't mention anything about exiting the chroot >> environment. >> > > True. Such behavior is undefined. There's no defined notion of exiting a > chroot. It doesn't seem to be documented in the few examples of the > chroot(2) call linux man pages I've found. Do you have documentation on > what, exactly, it's supposed to do? > > Does chroot(2) behave differently on Linux and FreeBSD, and chroot(".") >> is a valid way to exit on Linux and not on FreeBSD? Or what is going on >> here? >> > > Generally, one is not supposed to exit a chroot. :) Though jail(2) exists > because it's trivially possible in most cases. > > I wish somebody familiar with chroot add this information into the >> chroot(2) man page. >> > > POSIX never defined the behavior (and it's been removed in newer versions > of POSIX). > Also, what happens when you set kern.chroot_allow_open_directories=2 ? Warner From owner-freebsd-hackers@freebsd.org Sun Sep 27 19:07:45 2020 Return-Path: Delivered-To: freebsd-hackers@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 8A6C4424DA3 for ; Sun, 27 Sep 2020 19:07:45 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzwC536N5z46qZ for ; Sun, 27 Sep 2020 19:07:45 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4300013E6A for ; Sun, 27 Sep 2020 19:07:45 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f170.google.com with SMTP id o5so8118738qke.12 for ; Sun, 27 Sep 2020 12:07:45 -0700 (PDT) X-Gm-Message-State: AOAM532ETZOAXt8YRUfQAur61Z0kQqbOAHbwTBKmtJJZbxoVNA7vO7xF AjhST7TX+Ksj8u+IKYzfhMzdac8efVTMB8hAq4w= X-Google-Smtp-Source: ABdhPJzd9aFbZAIjqIg5bsih9DgX9OnqCogpxs9r+wzNn62jKd1icBC9Gv5AclMpxtnNMpYIx7LTtt7CT0siQ58rp5I= X-Received: by 2002:a05:620a:ce3:: with SMTP id c3mr9170513qkj.103.1601233664818; Sun, 27 Sep 2020 12:07:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Sun, 27 Sep 2020 14:07:33 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Warner Losh Cc: Yuri , Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:07:45 -0000 On Sun, Sep 27, 2020 at 2:03 PM Warner Losh wrote: > > On Sun, Sep 27, 2020 at 12:30 PM Yuri wrote: > > > This line > > > > https://github.com/rpm-software-management/rpm/blob/master/lib/rpmchroot.c#L155 > > calls chroot(".") in order to exit from the chroot environment. > > > > Interesting. FreeBSD doesn't allow that. > > > > It apparently succeeds on Linux (this is rpm), but it fails on FreeBSD > > with "Operation not permitted", while executed under sudo. > > > > The chroot(2) man page doesn't mention anything about exiting the chroot > > environment. > > > > True. Such behavior is undefined. There's no defined notion of exiting a > chroot. It doesn't seem to be documented in the few examples of the > chroot(2) call linux man pages I've found. Do you have documentation on > what, exactly, it's supposed to do? > I'm almost certain they just aren't restricting you from chrooting to a directory out of the chroot if you have a reference to it, so it probably does something like: chdir("/"); chroot("/some/root"); /* Do stuff, but never chdir */ chroot("."); /* Working directory is still the real root. */ Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Sun Sep 27 19:12:16 2020 Return-Path: Delivered-To: freebsd-hackers@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 C9F40424EB2 for ; Sun, 27 Sep 2020 19:12:16 +0000 (UTC) (envelope-from xtouqh@hotmail.com) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04olkn0804.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::804]) (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 4BzwJH1sVRz475W; Sun, 27 Sep 2020 19:12:14 +0000 (UTC) (envelope-from xtouqh@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TIu8jonsYOrSp2tPTvEAut/Ym3avlQdFUXknPRoZbP/sSchKHdDjV5O4Se3dyq4P23bkzYreJDMZxqUXoW2bjjUDrRe5Fqj2/wuIFAq1ItLluZAnbhhS/hHXjWgjkBWpyqJOL98NxG2o8e8WhoC/2plzn0NRL7DyFBBo6P0HZxvpW6IhIlVMZmhvzT6+abSq/CdfD7ObibjA/ivMTq7COXZkYuoCfD13IO9fmjpIZ5iMIV5UDGQBrzGlHqcGNiTW3WKhU9EE5UWQxioWoa4yYAP6kQKRM78U6pzj9ug04/2FNabtU/h4eoYx1UzRpxxnjcIlBCyby1f1qrDExAJjlg== 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=iTzvAfTxgvV1MvxAZjPpAU0YV9D+RP1z5aIuE/204+g=; b=LTtAftBoO5KH0SWQOJGZyFwYNyq/ldX/ekTWnTiHHrRMAFne2biGLKV+Wx9/CZ+64QoRCXz/rYavUTE32uC4BqgZCUTX8Axw1AabLp9oPOUB9Txc2wrsTMMyTqqDcvE+3tXxOww1LuopahcEGv29wjdQMXL3JVdKGpu675GiUo5RJaAGOftuS6B3RH/xafKUvPOAtHyzX5bSKzy6iBX2WzWG+Oke0ClJ+BmadfORE0TQ8SZBFK54O1it6k5Jkz/uKe0kM1S2L6TpR0Rrtcps1asseNIuTzc9yedVrkTAwx/flMPf672QwH///mjuBUe6k17DtR1sdE5qY+oJlm7ajg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iTzvAfTxgvV1MvxAZjPpAU0YV9D+RP1z5aIuE/204+g=; b=sFpecfCRCF8eWmF74s3FGU/D3CFH1LdvwBVrgDKltGmZQSNbgZPzKWSOP4Or7H0QtVB1srGxGlaslD6W08P0Ms3BYRXMwM6t2hwA8+T24QB8R0V0gdg+ykhOd9zsKCA2HT+Pc68aev9NR6GneEEEttaF7xulFSMwx38ZT12d79W/3vpwSQa06J1Y5BqyhOTxWYAwbZiG42MtVbjJ1wQxg5Gqjb9yVkCJgjt2jkn+8Q3ET7U0e/5i3I4uFviMQCc4wA28R4BTTCf80gCzk+ahiaWqJ1h4kDYUkCsKLwG6U/B/Ji6eqMVf51gNPY7hv3uBeKoLNvGgJ6JhzMGn7FYIfA== Received: from DB3EUR04FT037.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::53) by DB3EUR04HT112.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::351) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Sun, 27 Sep 2020 19:12:12 +0000 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com (2a01:111:e400:7e0c::43) by DB3EUR04FT037.mail.protection.outlook.com (2a01:111:e400:7e0c::286) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Sun, 27 Sep 2020 19:12:12 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:91896EEAF81C198626892C0E6A81164B14B93EAA3CF1946865639E42A3543A18; UpperCasedChecksum:E6D67658EE69C49692D5874565D9A483FB9827877AA1299796F26DB40B00C6F4; SizeAsReceived:8954; Count:49 Received: from AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::759a:af46:6f2:8fb8]) by AM0PR06MB3986.eurprd06.prod.outlook.com ([fe80::759a:af46:6f2:8fb8%7]) with mapi id 15.20.3412.028; Sun, 27 Sep 2020 19:12:12 +0000 Subject: Re: Is it possible to exit the chroot(2) environment? To: Kyle Evans , Warner Losh Cc: Yuri , Freebsd hackers list References: From: xtouqh@hotmail.com Message-ID: Date: Sun, 27 Sep 2020 22:12:11 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM4P190CA0008.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:56::18) To AM0PR06MB3986.eurprd06.prod.outlook.com (2603:10a6:208:b6::28) X-Microsoft-Original-Message-ID: <2c249ba2-4b14-20e7-e509-9b0eb8cf2f82@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (91.240.124.157) by AM4P190CA0008.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:56::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22 via Frontend Transport; Sun, 27 Sep 2020 19:12:11 +0000 X-Microsoft-Original-Message-ID: <2c249ba2-4b14-20e7-e509-9b0eb8cf2f82@hotmail.com> X-TMN: [lnTc1uhrV6wHuyzDaSGnjDg+O3FI7urH] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: cc8efe66-9993-4589-6242-08d863193cd9 X-MS-TrafficTypeDiagnostic: DB3EUR04HT112: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: l4p49fpud50Nuvq361Wew9d5m68WOpsTw5mJq/qZaACc16tbnZ4rUlITE16B5cAaeHvEweORkju4aKMz8U1dK6Q6Qrnl0IQMNvA3qzeXX7Q5X/ULWrA4Fmmm+L7bWltU3Ask4Lju3Vz2v5FNT700a28SkHBUQpPr9DjyrUfwPjnoF9sE+tTsrzyR9XqwLm1JV0I6eDH0c8cyQXjEieCNj2wAMlg4xsaVuHigre2G6xRTlVf/yceHl8A7W7eipIDy X-MS-Exchange-AntiSpam-MessageData: 2gr4hGkWSFhQYvbLCGTMuGD4G185nnwyofnBwen3EXgH1q+/Fr+7kK0/v7Ob81TlmSZB1YIuENWVKMYK7akL8TJjwaOyQQK3XmsI1dlC9EyvSSfM8K1Lp2U59fz/LuxPUV2xAHp/pSjqmwpgymK3eg== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: cc8efe66-9993-4589-6242-08d863193cd9 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2020 19:12:12.6862 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DB3EUR04FT037.eop-eur04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3EUR04HT112 X-Rspamd-Queue-Id: 4BzwJH1sVRz475W X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=sFpecfCR; dmarc=pass (policy=none) header.from=hotmail.com; spf=pass (mx1.freebsd.org: domain of xtouqh@hotmail.com designates 2a01:111:f400:fe0e::804 as permitted sender) smtp.mailfrom=xtouqh@hotmail.com X-Spamd-Result: default: False [-1.06 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; RCVD_COUNT_FIVE(0.00)[5]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[hotmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.027]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hotmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.553]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:12:16 -0000 Kyle Evans wrote: > On Sun, Sep 27, 2020 at 2:03 PM Warner Losh wrote: >> >> On Sun, Sep 27, 2020 at 12:30 PM Yuri wrote: >> >>> This line >>> >>> https://github.com/rpm-software-management/rpm/blob/master/lib/rpmchroot.c#L155 >>> calls chroot(".") in order to exit from the chroot environment. >>> >> >> Interesting. FreeBSD doesn't allow that. >> >> >>> It apparently succeeds on Linux (this is rpm), but it fails on FreeBSD >>> with "Operation not permitted", while executed under sudo. >>> >>> The chroot(2) man page doesn't mention anything about exiting the chroot >>> environment. >>> >> >> True. Such behavior is undefined. There's no defined notion of exiting a >> chroot. It doesn't seem to be documented in the few examples of the >> chroot(2) call linux man pages I've found. Do you have documentation on >> what, exactly, it's supposed to do? >> > > I'm almost certain they just aren't restricting you from chrooting to > a directory out of the chroot if you have a reference to it, so it > probably does something like: > > chdir("/"); > chroot("/some/root"); > /* Do stuff, but never chdir */ > chroot("."); /* Working directory is still the real root. */ Reading the illumos chroot(2) suggests something similar: The ".." entry in the root directory is interpreted to mean the root directory itself. Therefore, ".." cannot be used to access files outside the subtree rooted at the root directory. Instead, fchroot() can be used to reset the root to a directory that was opened before the root directory was changed. From owner-freebsd-hackers@freebsd.org Sun Sep 27 19:42:44 2020 Return-Path: Delivered-To: freebsd-hackers@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 65D2C4260BC for ; Sun, 27 Sep 2020 19:42:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzwzS1z22z4Fjg for ; Sun, 27 Sep 2020 19:42:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 21A7F140C3 for ; Sun, 27 Sep 2020 19:42:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id e7so6589992qtj.11 for ; Sun, 27 Sep 2020 12:42:44 -0700 (PDT) X-Gm-Message-State: AOAM531w9VEIqOKU8+FhFCez7RSGSATSttM4ixUs4oQViMdG0RxilxmR 7YjgYMgNym5uWgP7ktO/QbzCPMRr+VMQlzOtGlQ= X-Received: by 2002:ac8:3f3d:: with SMTP id c58mt9615707qtk.53.1601235763673; Sun, 27 Sep 2020 12:42:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Sun, 27 Sep 2020 14:42:32 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? Cc: Warner Losh , Yuri , Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:42:44 -0000 On Sun, Sep 27, 2020 at 2:07 PM Kyle Evans wrote: > > On Sun, Sep 27, 2020 at 2:03 PM Warner Losh wrote: > > > > On Sun, Sep 27, 2020 at 12:30 PM Yuri wrote: > > > > > This line > > > > > > https://github.com/rpm-software-management/rpm/blob/master/lib/rpmchroot.c#L155 > > > calls chroot(".") in order to exit from the chroot environment. > > > > > > > Interesting. FreeBSD doesn't allow that. > > > > > > > It apparently succeeds on Linux (this is rpm), but it fails on FreeBSD > > > with "Operation not permitted", while executed under sudo. > > > > > > The chroot(2) man page doesn't mention anything about exiting the chroot > > > environment. > > > > > > > True. Such behavior is undefined. There's no defined notion of exiting a > > chroot. It doesn't seem to be documented in the few examples of the > > chroot(2) call linux man pages I've found. Do you have documentation on > > what, exactly, it's supposed to do? > > > > I'm almost certain they just aren't restricting you from chrooting to > a directory out of the chroot if you have a reference to it, so it > probably does something like: > > chdir("/"); > chroot("/some/root"); > /* Do stuff, but never chdir */ > chroot("."); /* Working directory is still the real root. */ > I think the original report needs a ktrace to narrow down what's really going on... kevans@shiva:~/grep$ cat chr.c #include #include int main(int argc, char *argv[]) { printf("chdir %d\n", chdir("/")); printf("chroot %d\n", chroot("/tmp")); printf("chroot %d\n", chroot(".")); return (0); } kevans@shiva:~/grep$ sudo ./a.out chdir 0 chroot 0 chroot 0 Sprinkling some stat() calls in between reveals that chroot(2) is working in both cases and properly entering/exiting the chroot. From owner-freebsd-hackers@freebsd.org Sun Sep 27 19:47:46 2020 Return-Path: Delivered-To: freebsd-hackers@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 393AA42658E for ; Sun, 27 Sep 2020 19:47:46 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4Bzx5G0HRSz4G33; Sun, 27 Sep 2020 19:47:45 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 08RJlh0h024116 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 27 Sep 2020 12:47:44 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be yv.noip.me Subject: Re: Is it possible to exit the chroot(2) environment? To: Kyle Evans Cc: Freebsd hackers list References: From: Yuri Message-ID: Date: Sun, 27 Sep 2020 12:47:42 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4Bzx5G0HRSz4G33 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:47:46 -0000 On 2020-09-27 12:42, Kyle Evans wrote: > I think the original report needs a ktrace to narrow down what's > really going on... https://people.freebsd.org/~yuri/rpm-ktrace-dump-chroot-fails.txt Yuri From owner-freebsd-hackers@freebsd.org Sun Sep 27 19:56:28 2020 Return-Path: Delivered-To: freebsd-hackers@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 C3445426561 for ; Sun, 27 Sep 2020 19:56:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzxHJ4qqTz4GGR for ; Sun, 27 Sep 2020 19:56:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8424B14912 for ; Sun, 27 Sep 2020 19:56:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f182.google.com with SMTP id q63so8247020qkf.3 for ; Sun, 27 Sep 2020 12:56:28 -0700 (PDT) X-Gm-Message-State: AOAM5326irrFGGKf8fVGuRf7HkNbi0mS030CY4oLmkY2DONoqAa9JVQ1 W/2WHUBWF83Uiqu8Vk3e/OwJHcZ2CqPM2zfi1rw= X-Google-Smtp-Source: ABdhPJzPt7mQJ2gN8XqinAgX7QgzO/LR5Ej529dX1QRUBHZnb430Xmomw+/Tan3csSOLV3PbVQIwZ/be3mD2YSjaXkA= X-Received: by 2002:a37:a189:: with SMTP id k131mr8829971qke.34.1601236588142; Sun, 27 Sep 2020 12:56:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Sun, 27 Sep 2020 14:56:16 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Yuri Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:56:28 -0000 On Sun, Sep 27, 2020 at 2:47 PM Yuri wrote: > > On 2020-09-27 12:42, Kyle Evans wrote: > > I think the original report needs a ktrace to narrow down what's > > really going on... > > > https://people.freebsd.org/~yuri/rpm-ktrace-dump-chroot-fails.txt > Yup, that's pretty definitive: 69691 python3.7 CALL chroot(0x8026e6ad2) 69691 python3.7 NAMI "." 69691 python3.7 RET chroot -1 errno 1 Operation not permitted Note the explanation of EPERM: [EPERM] The effective user ID is not the super-user, or one or more filedescriptors are open directories. For the former half, a chroot in the very same python3.7 exec succeeded, so it must not be that. Try setting kern.chroot_allow_open_directories to some value that isn't 0 or 1. From owner-freebsd-hackers@freebsd.org Sun Sep 27 20:04:12 2020 Return-Path: Delivered-To: freebsd-hackers@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 07028426BBD for ; Sun, 27 Sep 2020 20:04:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4BzxSC5qrxz4GlL; Sun, 27 Sep 2020 20:04:11 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 08RK4ATt025610 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 27 Sep 2020 13:04:10 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be yv.noip.me Subject: Re: Is it possible to exit the chroot(2) environment? To: Kyle Evans Cc: Freebsd hackers list References: From: Yuri Message-ID: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> Date: Sun, 27 Sep 2020 13:04:09 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4BzxSC5qrxz4GlL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 20:04:12 -0000 On 2020-09-27 12:56, Kyle Evans wrote: > kern.chroot_allow_open_directories to some value that isn't 0 or 1. It succeeds with kern.chroot_allow_open_directories=2. Yuri From owner-freebsd-hackers@freebsd.org Sun Sep 27 20:09:40 2020 Return-Path: Delivered-To: freebsd-hackers@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 641A1426A71 for ; Sun, 27 Sep 2020 20:09:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzxZX26FNz4H9N for ; Sun, 27 Sep 2020 20:09:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 26E0414C0C for ; Sun, 27 Sep 2020 20:09:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f174.google.com with SMTP id q63so8264918qkf.3 for ; Sun, 27 Sep 2020 13:09:40 -0700 (PDT) X-Gm-Message-State: AOAM533nO0owWuxlcU1wfOLBeSgR1w1F1Iwkz9FHVWrM9iv6Vu/SKFpB 2unrNVygM/QIDJnfEaWqm9hQWKu3Z4/sHcFHq5k= X-Google-Smtp-Source: ABdhPJw5KGliFJ3ShSoQ+iafsTE7tHLAVSU4NtrnPjU3zX6KD2SCT8EVtxpLW0wn2PbAc7lmUUEu8PMUzy96/vvdA04= X-Received: by 2002:a05:620a:136e:: with SMTP id d14mr9271903qkl.430.1601237379793; Sun, 27 Sep 2020 13:09:39 -0700 (PDT) MIME-Version: 1.0 References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> In-Reply-To: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> From: Kyle Evans Date: Sun, 27 Sep 2020 15:09:28 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Yuri Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 20:09:40 -0000 On Sun, Sep 27, 2020 at 3:04 PM Yuri wrote: > > On 2020-09-27 12:56, Kyle Evans wrote: > > kern.chroot_allow_open_directories to some value that isn't 0 or 1. > > > It succeeds with kern.chroot_allow_open_directories=2. > > Ok, so Warner's proposal was correct and we've verified the semantics work out the same, this is simply a behavioral difference in that we're a little more strict -- presumably to make it less trivial to break out of a chroot. I suspect a default change for the sysctl/behavior is unlikely, your best bet to move forward is probably to work out if they really need to have dangling directories open and correct that if at all possible. From owner-freebsd-hackers@freebsd.org Sun Sep 27 20:10:47 2020 Return-Path: Delivered-To: freebsd-hackers@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 03AE6426E77 for ; Sun, 27 Sep 2020 20:10:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bzxbp1Vszz4HLk for ; Sun, 27 Sep 2020 20:10:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id 16so8257801qkf.4 for ; Sun, 27 Sep 2020 13:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uVkrSJbF/4LOkIZJNcZp7dRh3DacE5B4tsnxe8XwGxI=; b=ghkE5ytfe4Hbf7GyTzfxhgtR8hFetQalXnpt1VALKS8MGnwi+4VBGpYnY6GrcnqNh8 Ofu05bH4bBZIh5HnmCRc9K6eZfARkunPI34WWDPBzg9x8p3M7K9j9hXzUC/SLkiVOX0a DC46coVy0FyJAbse9FhYPKWWRDoeLo8mt5/44iE4/kQaPWfbkgdNR0WpZF4L9pVAymSX lrIZU/7UsItIyiOs1PUYCBOpddvr4K8eOLUT8zbBR8FUGMPQbM2oCQt+q9sa5dZ9YiyS Ry0NVH5Z1IhfzNlPfY5X4rJQoGyJxTPk8lLjgmdJJSYVb4JLmwLmLLeiP1muTGyB+7AS EQZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uVkrSJbF/4LOkIZJNcZp7dRh3DacE5B4tsnxe8XwGxI=; b=WCMe1mv9q0b4sreEV+HfBSgI7RYT1gzKHVODDBhTvVKBYT0Y7X4ksWHGGIF8Ais9q+ fNisrLPedlrQBfXLkzozbv7y7Hlk7ivC++Dxb+2/Dj4JeICulxiUmG0QnK11FTU2ZB7t w00UuBDAlSBMINeYEI6ekTh7+9I1kENv61v3AKcbPgAa8Nho92QPOIA4sPW1i+iTG+Yb B9QNSarHKrlgvaPUKfNv61vAOvSokikuy84xrIzxlKui+OKnv0oq4gSF25fdKBT+GrYr 6+UMR0Lb489Z+tuCinw2GNta/uWZi/8fJsJXArmTjfRIIYFwyrflt8j3caQwkWSsRRXh La7g== X-Gm-Message-State: AOAM531pY2CEquITczhU7TsqLi66OClszupKWrG7vkgKMpiQPbdRWW65 Jh53/pPua2tRXcj/BQkS9IiCIcgK+pHS5/JHyghQlQ== X-Google-Smtp-Source: ABdhPJzmsfFBaTDhQ0ilRTnAuJyXZ9ubYWIb2+ZLSZyJoSsVDcHZHBH6eL+2IxvvFUlbym7G15SxN7La2AVam+nFlek= X-Received: by 2002:a05:620a:1583:: with SMTP id d3mr8956700qkk.495.1601237445239; Sun, 27 Sep 2020 13:10:45 -0700 (PDT) MIME-Version: 1.0 References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> In-Reply-To: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> From: Warner Losh Date: Sun, 27 Sep 2020 14:10:33 -0600 Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Yuri Cc: Kyle Evans , Freebsd hackers list X-Rspamd-Queue-Id: 4Bzxbp1Vszz4HLk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ghkE5ytf; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::730) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.26 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.27)[-0.274]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 20:10:47 -0000 On Sun, Sep 27, 2020, 2:04 PM Yuri wrote: > On 2020-09-27 12:56, Kyle Evans wrote: > > kern.chroot_allow_open_directories to some value that isn't 0 or 1. > > > It succeeds with kern.chroot_allow_open_directories=2. > Yea. This is documented in chroot(2). Yuri > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sun Sep 27 20:15:52 2020 Return-Path: Delivered-To: freebsd-hackers@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 8D18F427319 for ; Sun, 27 Sep 2020 20:15:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bzxjg5ZR1z4J3v for ; Sun, 27 Sep 2020 20:15:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x832.google.com with SMTP id b2so6625291qtp.8 for ; Sun, 27 Sep 2020 13:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CQhPcY9DlHbMOMnrsAA6ABkzNETJI78eieaQDW96fTM=; b=b3ZP/uXGsgRGdo3yPpyxz8II7cHvagrgb6iz18nymK6gOtF0HnFsrua3m0eurbB1Jw FK9Qqxcdzq5GRn/D5CoGI3jvLXFWRhy6hh+ZeHngXf8JjnsX+g1ZeF8SvHhXXzQY/A7u +cnYpzVIru8+agvmAWoDx6czyCZpKj2B2dprevL2lEnVM7L3UozftAEUz0oxKxDbulmi C0zcYKUdn005hqUY3gpyUyqcr9Ocyx5Zb1F0yGHZYZNQhN7ocmGVkrRTajTI2pQugx/4 +hM1/Wt0nb8z+cKZb+y2dukpvwuB4ZGUWt3A0RcfZ5nF3z6QVUxf4f6uVGIZW+8pjVB1 kvuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CQhPcY9DlHbMOMnrsAA6ABkzNETJI78eieaQDW96fTM=; b=SZdBbnrAqcdqJMfkl/C+XDwOqPw2uIeaLh0RCTNHiIy/imSvs21XGX9z6Y6ZjD/lHB mt3GNBvFUzCdacqD/gYWkkMl2ovf04OxsCuRK5Zbod2bRHRrPxnoh0gSeFLX/1qvqAHa 8FXFAagKLJLaNH5uHQRMFAxYU0+egpisDPu/Q84yMj5RGbRPma3C+DrBD7YP7HDsIeFK vbr4uZPiy7AOPtHPSiWKPuSSPnDMsHxTVxwJ8+9lODXe6dBeC8aNBZj7DsaoyK5ZuCwt 6VQHgHgKlN8rmOx1rRDcF0kmyBH5VnqcbVgdmm5RBtQzdx/77Goj2iXNSnEKqlZwZjGq Rb1A== X-Gm-Message-State: AOAM530H/fu3rF78ie/qudQuHY5GtEyMmyIS1uYBIiBBWgbbpm4nN/wF 28rb9YPwsjBB8IhSxkPoJLhWHH4lWcNfbi5UTJcJZA== X-Google-Smtp-Source: ABdhPJxTX0OpmTBbuUdjpH/tCJ7WRjoCPsaWjV/avjSqCB3UkjIKyqzLGDfiPgq/H5xnu3FQdbfM9os+fV7EcbYcogs= X-Received: by 2002:ac8:7388:: with SMTP id t8mr9579776qtp.187.1601237750714; Sun, 27 Sep 2020 13:15:50 -0700 (PDT) MIME-Version: 1.0 References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> In-Reply-To: From: Warner Losh Date: Sun, 27 Sep 2020 14:15:38 -0600 Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Kyle Evans Cc: Yuri , Freebsd hackers list X-Rspamd-Queue-Id: 4Bzxjg5ZR1z4J3v X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=b3ZP/uXG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::832) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.26 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.27)[-0.274]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::832:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 20:15:52 -0000 On Sun, Sep 27, 2020, 2:09 PM Kyle Evans wrote: > On Sun, Sep 27, 2020 at 3:04 PM Yuri wrote: > > > > On 2020-09-27 12:56, Kyle Evans wrote: > > > kern.chroot_allow_open_directories to some value that isn't 0 or 1. > > > > > > It succeeds with kern.chroot_allow_open_directories=2. > > > > > > Ok, so Warner's proposal was correct and we've verified the semantics > work out the same, this is simply a behavioral difference in that > we're a little more strict -- presumably to make it less trivial to > break out of a chroot. > > I suspect a default change for the sysctl/behavior is unlikely, your > best bet to move forward is probably to work out if they really need > to have dangling directories open and correct that if at all possible. > To be fair, we are more strict than Linux... but it is documented. Though if there were some way to highlight that better, I'd be open to working that in. Maybe a sentence on 'any other value' paragraph talking about traditional behavior... Warner _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sun Sep 27 20:25:48 2020 Return-Path: Delivered-To: freebsd-hackers@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 063214277B3 for ; Sun, 27 Sep 2020 20:25:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bzxx76QsQz4JdQ for ; Sun, 27 Sep 2020 20:25:47 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id BAF3C140D9 for ; Sun, 27 Sep 2020 20:25:47 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f182.google.com with SMTP id o5so8223199qke.12 for ; Sun, 27 Sep 2020 13:25:47 -0700 (PDT) X-Gm-Message-State: AOAM532r4d6MxTuo4+JUeJlswmqJhGZyKTqEwOfHuYCnFJoRimHnih7z 8JkjU3h/aIxOUo1ZQlfn2/JaL9hziIquucEBfU0= X-Google-Smtp-Source: ABdhPJwC6bc0OrA5GTs3JOYm73e3HXHBqJZF5KNknyFXylPKt4R/7+vtsDyoWnvtrI8AbchygTVah35LZpZJRBQV4sc= X-Received: by 2002:a05:620a:136e:: with SMTP id d14mr9313531qkl.430.1601238347369; Sun, 27 Sep 2020 13:25:47 -0700 (PDT) MIME-Version: 1.0 References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> In-Reply-To: From: Kyle Evans Date: Sun, 27 Sep 2020 15:25:36 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Warner Losh Cc: Yuri , Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 20:25:48 -0000 On Sun, Sep 27, 2020 at 3:15 PM Warner Losh wrote: > > > > On Sun, Sep 27, 2020, 2:09 PM Kyle Evans wrote: >> >> On Sun, Sep 27, 2020 at 3:04 PM Yuri wrote: >> > >> > On 2020-09-27 12:56, Kyle Evans wrote: >> > > kern.chroot_allow_open_directories to some value that isn't 0 or 1. >> > >> > >> > It succeeds with kern.chroot_allow_open_directories=2. >> > >> > >> >> Ok, so Warner's proposal was correct and we've verified the semantics >> work out the same, this is simply a behavioral difference in that >> we're a little more strict -- presumably to make it less trivial to >> break out of a chroot. >> >> I suspect a default change for the sysctl/behavior is unlikely, your >> best bet to move forward is probably to work out if they really need >> to have dangling directories open and correct that if at all possible. > > > To be fair, we are more strict than Linux... but it is documented. Though if there were some way to highlight that better, I'd be open to working that in. Maybe a sentence on 'any other value' paragraph talking about traditional behavior... > +1. I think an additional sentence pointing out that that's the traditional behavior would outline that this is perhaps what's needed, maybe with a specific EPERM reference. It's tempting to also propose switching it to the even-more-strict 0 at some point, perhaps considering a procctl(2) if we really find some scenarios where it's absolutely necessary... we'll leave that battle to a different day, though. From owner-freebsd-hackers@freebsd.org Sun Sep 27 21:37:44 2020 Return-Path: Delivered-To: freebsd-hackers@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 EFE36372477 for ; Sun, 27 Sep 2020 21:37:44 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4BzzX8410qz4Rjl; Sun, 27 Sep 2020 21:37:43 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 08RLbfcA034066 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 27 Sep 2020 14:37:42 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be yv.noip.me Subject: Re: Is it possible to exit the chroot(2) environment? To: Kyle Evans , Warner Losh Cc: Freebsd hackers list References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> From: Yuri Message-ID: <3d17ea59-0e85-4e33-f426-deec99f07b83@rawbw.com> Date: Sun, 27 Sep 2020 14:37:40 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4BzzX8410qz4Rjl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 21:37:45 -0000 On 2020-09-27 13:25, Kyle Evans wrote: > +1. I think an additional sentence pointing out that that's the > traditional behavior would outline that this is perhaps what's needed, > maybe with a specific EPERM reference. The fact that chroot(".") undoes the previous chroot(...) call should also be documented, IMO. The current chroot(2) man page doesn't mention this. Also chroot apparently preserves the current working directory for the purpose of chroot("."), but not for other purposes. What if chdir(2) with the same string $OLD_WD is called in the chroot environment with root in $ROOT_DIR, i.e. chroot($OLD_WD), and it succeeds because there happens to be a directory with the same path $OLD_WD in the chroot environment too, i.e. $CHROOT_DIR$OLD_WD is a valid directory. Would chroot(".") then change root back to the original directory $OLD_WD, or it would change it deeper into the root environment directory: $CHROOT_DIR$OLD_WD ? All this makes for a complex and potentially confusing behavior, which should be documented, IMO. Yuri From owner-freebsd-hackers@freebsd.org Sun Sep 27 22:20:52 2020 Return-Path: Delivered-To: freebsd-hackers@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 D8277373E4A for ; Sun, 27 Sep 2020 22:20:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C00Tw5T2Qz4V13 for ; Sun, 27 Sep 2020 22:20:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 9A28D14FCF for ; Sun, 27 Sep 2020 22:20:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f179.google.com with SMTP id b2so6767694qtp.8 for ; Sun, 27 Sep 2020 15:20:52 -0700 (PDT) X-Gm-Message-State: AOAM5312IIh/13MD+MmLKeiap+DHxRkhhcwPqqeqdDOOKhlDDFgPJbKT 30XegXrWyhh5n5uJDUBQxRloZfbTkyf1R64Uq3s= X-Google-Smtp-Source: ABdhPJz1BztHlVGt3ebpjvByB5g+HiE4djXALU4Ugmu16NkwJbfY+TloYqIJUsPOzUmGDERQbq8UJu0dCidU776J/Lw= X-Received: by 2002:ac8:192b:: with SMTP id t40mr9993348qtj.60.1601245252204; Sun, 27 Sep 2020 15:20:52 -0700 (PDT) MIME-Version: 1.0 References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> <3d17ea59-0e85-4e33-f426-deec99f07b83@rawbw.com> In-Reply-To: <3d17ea59-0e85-4e33-f426-deec99f07b83@rawbw.com> From: Kyle Evans Date: Sun, 27 Sep 2020 17:20:41 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to exit the chroot(2) environment? To: Yuri Cc: Warner Losh , Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 22:20:52 -0000 On Sun, Sep 27, 2020 at 4:37 PM Yuri wrote: > > On 2020-09-27 13:25, Kyle Evans wrote: > > +1. I think an additional sentence pointing out that that's the > > traditional behavior would outline that this is perhaps what's needed, > > maybe with a specific EPERM reference. > > > The fact that chroot(".") undoes the previous chroot(...) call should > also be documented, IMO. The current chroot(2) man page doesn't mention > this. > The problem is that chroot(".") is not a sure-fire way to escape the chroot. It's not that simple- it only works because your working directory is still outside. > Also chroot apparently preserves the current working directory for the > purpose of chroot("."), but not for other purposes. > chroot never changes the working directory for any purpose, this is one of the well-understood flaws of the syscall. It's not preserving anything specifically for chroot("."), and in-fact you'll find that "." in other syscalls (e.g. stat) is consistent with what you're seeing here. > What if chdir(2) with the same string $OLD_WD is called in the chroot > environment with root in $ROOT_DIR, i.e. chroot($OLD_WD), and it > succeeds because there happens to be a directory with the same path > $OLD_WD in the chroot environment too, i.e. $CHROOT_DIR$OLD_WD is a > valid directory. Would chroot(".") then change root back to the original > directory $OLD_WD, or it would change it deeper into the root > environment directory: $CHROOT_DIR$OLD_WD ? > > All this makes for a complex and potentially confusing behavior, which > should be documented, IMO. > chroot would demonstrate the same consistency here. chroot does not change your working directory, so it doesn't matter how many times you chroot as long as you don't chdir to some name that resolves within the chroot. From owner-freebsd-hackers@freebsd.org Sun Sep 27 22:24:07 2020 Return-Path: Delivered-To: freebsd-hackers@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 B1E8F373E70 for ; Sun, 27 Sep 2020 22:24:07 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C00Yg4FX5z4V2N; Sun, 27 Sep 2020 22:24:07 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from ice.alameda.xse.com (unknown [IPv6:2600:1700:a570:11f0:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 1E8F415B0A; Sun, 27 Sep 2020 22:24:07 +0000 (UTC) (envelope-from leres@freebsd.org) Subject: Re: Is it possible to exit the chroot(2) environment? To: Kyle Evans , Yuri References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> <3d17ea59-0e85-4e33-f426-deec99f07b83@rawbw.com> Cc: Freebsd hackers list From: Craig Leres Message-ID: <4702ab92-0cee-133d-62c9-1cfa787379e6@freebsd.org> Date: Sun, 27 Sep 2020 15:24:05 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 22:24:07 -0000 Don't forget about fchdir(), I've used it (in non-chroot()) programs to implement pushd/popd functionality in a recursive function. Craig From owner-freebsd-hackers@freebsd.org Mon Sep 28 01:16:16 2020 Return-Path: Delivered-To: freebsd-hackers@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 1FE823F0C1E for ; Mon, 28 Sep 2020 01:16:16 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C04NH1T34z4dqP for ; Mon, 28 Sep 2020 01:16:14 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A46125C0195 for ; Sun, 27 Sep 2020 21:16:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 27 Sep 2020 21:16:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=oZCGjAzqdgRAIn6KCckOqufYzZ2 kR+HV3CyBH1ETVVs=; b=i8ZyeUnmwe+yBWlmmrpRLe0vdpN7urkj3zP9QtLkJnF itMPqOy57D3x4DnbcPtVzY57V9ve9IsMyn7AmRRxToU1Wlr84/vZ6Vk0W14xVIqJ 9yYP3PmGNk+oOV6ttlSmP7+Q12gQ1Tzuad3A7vnvsWv26KEUNq1AtXKKL6ur0a32 lZ24ZjRYF9iNolofdI38WHgS+aihrbCOg3FpDUjPtTwNNTZQITKHaHBgdpRO41r7 tqNPgx2kPV1u46z2dsfzG0QQhQnR/WAeJTPwEfP+X/l13bGSFP/wTm9xNntBfaA3 E1LCzwnfM0zoVWPaHuw048AR9Z2d3bzhA4qFTxe6x6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=oZCGjA zqdgRAIn6KCckOqufYzZ2kR+HV3CyBH1ETVVs=; b=SlcONgdSrMYcosIiybK4is 4QZWvTv65b0gczLwvuokxUy3hy6H7K+kPvHU/RmqGM462ngGk1NBL7dc7pt1SMZu cHRFiJg3REuvuO6wUDbbzBl6QBnDATf4p2BDG7p1C0RxCPfb81oq2qhXDSV5r/GH SyE3uHryw5j4qAppjB4LATjhGHL3xs+1Z0rn+4doJ5WpLsLNoF1wTBl90DNC/3Ls nITg0DMExtWoNGBxR649otlCRL8wQwVpIJVYlnlBNZnXFeiWpnIIRqtV5oW0XD5V E0Dp2chCfv+YcMAXVlSQdTEToJLi9lZLgW3N33HYkG6ULqQghWluqaxiRavU2Gdw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecukfhppeekvddrjedtrdeluddrleelnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthgvtghhqd hlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: from bastion.zyxst.net (bastion.zyxst.net [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 9FE993064674 for ; Sun, 27 Sep 2020 21:16:13 -0400 (EDT) Date: Mon, 28 Sep 2020 02:15:44 +0100 From: tech-lists To: freebsd-hackers@freebsd.org Subject: Re: private freebsd-update server - possible with -current? Message-ID: <20200928011544.GF54660@bastion.zyxst.net> References: <20200927062126.GE54660@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4f28nU6agdXSinmL" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4C04NH1T34z4dqP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=i8ZyeUnm; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=SlcONgdS; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.29:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.01)[-1.009]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.73)[-0.727]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 01:16:16 -0000 --4f28nU6agdXSinmL Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 27, 2020 at 07:30:10AM -0600, Alan Somers wrote: >I don't see why it shouldn't. I'm currently a private freebsd-update >server on 12-STABLE. The catch is that freebsd-update refuses to run on >anything it thinks isn't an official release. So I have to make my own >releases. To distinguish them from official ones, I name them something >like "12.1-MYNAME1", and then I have to modify the freebsd-update script to >thing that "MYNAME1" indicates an official release. Thanks, that sounds hopeful, at least for freebsd-update (arm64) because I have a bare-metal arm64 machine. I'll need to work out how to make a release on arm64 for mips64, hopefully that'll work. --=20 J. --4f28nU6agdXSinmL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl9xOVMACgkQs8o7QhFz NAX/uRAAhq2pWqb2mDT4XnYk3twZfL1l9dBBBM+r/BhYGVySVKxnMafWVcmjoqDU yAl3a1E052PN8QmAU19eCZMzIkR59gT8zODCZDiTGCO6Aw0yDeozb6bzeqoFnrah /Px3tO0GCxf4DwgSIxzQLc6G/MjeCcBOigTJqrXNsJxN1H1e7O56MVQDdUEYOd8E vfz+hq6kwkQ6XZFZoqUIXW+VUPb3UsrtnT62AbpbFlzo2WxuZW4c532B3GcA/uK7 Li1kCBy4RKsVbs9rZd1iFDP/RbpV16cYQJxKdM0Z5TR5Jy3SuqezK7bKefhFo/Vf dAeVr/xtYjlZ5XEuAt+N98/ZO6oPy2DbQZxerVqR67kEmlKoJp0oqy9+/Eu3kH4L 2Lhy+0eBBnoRwW5TcApeNohiEMTH1lTZnt5yEmh6VzTzItlRK4ag3bS7yzYuuNBS deXQLGVl8hZPuBiDdCMUna5rMOPpmNCz2VYG9X43MmGEMUzIhiUNKLiaPc/lpR/a v9iJ1FlhN6K8rhnalwGqTlPBlxlnPGW+SU2kxWwG2ruuwusMlQazNPyZ1lTxiGp1 Ugr+Qk/rh+udM5FEIUuiCOa+TNRuI8IGU1Y2NwS63IE8XMB0I8WMVWDoY+X35b9S Xf3sm9M7mwqSU1hsM4pSf9i+R/OeX7cn4lM/kd4GMAsLeMU3XnA= =TPC2 -----END PGP SIGNATURE----- --4f28nU6agdXSinmL-- From owner-freebsd-hackers@freebsd.org Mon Sep 28 01:43:22 2020 Return-Path: Delivered-To: freebsd-hackers@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 6F21A3F13E5 for ; Mon, 28 Sep 2020 01:43:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660057.outbound.protection.outlook.com [40.107.66.57]) (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 4C04zY3T4pz4g0Q; Mon, 28 Sep 2020 01:43:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DVZMx6Xa7yn5Oa8VG7LJHXW9VZe125182x0KakIv4GlG6d6CbbmSEaESSTF9ZAPAL1l/i00yoEZnOnGdP4ZDsWzd5UVUkz54PIzL2urEQw1kB5LE98LU1dJtYn8AtpWTqSc3U8/0q+FBvDB/9omGKoW8a/LJAq+lOnHerm1skW5jeM69O9qz/td10OIj8NSO6HJjcHT8PhqNXAo+sSu84Sr8mXD/zaAaECqTwx1VuvyjxMSEVRfvaIfT2REt4BA3uDjUMhIUarS5ZXs7DOlF3YcLCqKq0WEO2EORMHWbefSH+WmnxvSU82UEh41Z0JPuTrxs5cF+cG3+ibmovJX64Q== 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=MbP+EQhLElQ9xpd5K6nJazuUdjNMQuEvpzR0LbPeO78=; b=bcClhyNPc1qv0VVSiyIlbhmMtI8GjuhxMMd5FD04zna95uTQPMDIoMBVhqKkuS0syOcSIu/+vmK0JxeS/RnV3yevi7PMcVFzp3+VBiLLSS3kZw8tWjmJqnjIUxLO4T81BVnz1VemV97j7er97SbLAiwi0S2gzqzk6XrXYOPmP5SDk6q9rI2s9Pied3ZtX64XVO24lEnH9TPkibkmAnNiSzsv54pdAPLC+PFfm62cPhJZzW7/6OYt7Q7lHik5RCTT+mmK/X+LHZf1TtWalJVxQ3MAnYFDY2hBlLbDzDT0GGCDFqGMybhv0jnVLP1a39KjWI2oQ/oi3tnu32Ku21XZYw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MbP+EQhLElQ9xpd5K6nJazuUdjNMQuEvpzR0LbPeO78=; b=DIVSG4ZW8K8fVL9GYdaWZO5PZlevwN8wnn8kWuwNyJJ/atmKBHN6WVTo9aW035IxGdYZiLEhrejY6Tg3C6zXh6wNRaUDZtrte4vvrYK4Aux6rrXumb4Qb760dgWSfpQZJH051aQ55aI8cHD8CheoRLEBasMJ34Gl5WrXDiXHLX2DAZXFe8DJtn/n3D2rKwCG6V1Uvlk8az+/7vSse2Mk9ZmijqLX7HE3eJjaoC8bDe1CioAC9fJJPCb/3YCAMZhzatHxe067MDsTXBO4JObb1cRfaxHf6PM6F6yWifI4BJZfyOQhroBrG+6zF/2vhUZjqdgms0BdMvS4vkQ5cdFMGw== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:16::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Mon, 28 Sep 2020 01:43:19 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3412.029; Mon, 28 Sep 2020 01:43:19 +0000 From: Rick Macklem To: Chris Stephan , Alan Somers CC: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAApba+ACJ95gIAAfXJMgAG51Xw= Date: Mon, 28 Sep 2020 01:43:18 +0000 Message-ID: References: , , , , 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: 8050a907-92ba-4736-3ba9-08d8634fe05c x-ms-traffictypediagnostic: YTOPR0101MB1820: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jdErE2PkwvnWWiptORpl4DNFfyddVwTfMQAWExNoIv9VrOWzTLMKdJ4Lv12E1cxO35KuatjjpqCsonGVnafoJ9UCFEiMGKhmfFEOj+SNsUorplqA9szbsjBdIPpIeFErcnocxMW+HHm731QBxY1bVxNiywc8Ac1doMJkmS0WWfXCj64BsPwpSoqjzTr+4D8J8uVJUgrEn0AZZnrvDpfV5au27QGWL5hQjSBmD2ASL1sil/LIEY+bOdXFE8Um6WCuWw6ye8nDoXpT0cWKmE30yhDjYOcQTlYF1/pniffMVtjK6n3uCveL5KoIlfruos5lHyx1UpN/KbpThBQA79M0cLj6mmxJJGpjaQgrnRZcVyhNJ/AVw2wcUwnitHLVQh4hJlhbXHT+ug8NDJBZU26IDxB9v1TIoJ5UEbtNA+wMZNtEBNkvUhWoaDTIMsbeo6e4CgGpcNil+Jpa6xQKfnx/dA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(346002)(366004)(376002)(396003)(39850400004)(66946007)(66476007)(66556008)(64756008)(66446008)(30864003)(4326008)(91956017)(966005)(2906002)(86362001)(316002)(786003)(110136005)(45080400002)(8936002)(478600001)(33656002)(8676002)(76116006)(5660300002)(6506007)(52536014)(186003)(53546011)(7696005)(83380400001)(55016002)(9686003)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /QG6UyWYu/BjSOtEbeFrl1ynPwaMV6V+maOlLB3J1Dq6Qu7zfpeJSuaLuCT+YDi275ov+MEwc1EiZWC1NLSrwDHG9MOEABJnGL/gqtCh39eOrdPdsegybD/0CIlLLTZmxbkFvh06Vno2qj4l1dacpPRpwdNMxdyNIyJpKFocv8dFl6uny7LXDSSzktsEMq+QhYDjTvzHU75sM62IGnmzuoL6KHddF/XiP9e3XGlV9HGNnWI2GLAADq05TMAyumU+amRVLLxP43KtjmaolQn9+dSo+XuOfRo7Sv0gu2zWpayvn/sUxma8r+CHvEgYPYdituHE4LCZjRUCtBb/0Fm0LbwF0jTxgon9/g9rXeeEz+4IJ8KZ1OsVcKPqHZE+abb/sJzrLnDRr//eRE23vfruScF4FIIgfa9eU+Ur2duJibnpW+uN/SQFi0UpeYhuCr8LvIpunNnIbEXiHlXQumzxOqR4+HQsNttcENDljjsXfpl8dEdHZK1iGBvQbXVOOhC4fJxQdVYWM5EceweX+YsLv9iV/cEx2zdmWNacoc9T5vlwePWJ4epQlFLqAV6VswC3TP7muCDbrbRBsbOz5oc/L6u1eJVX9ODJYlI1jefSHzkX4VVV5O2MaIbiCbbwFGhlumwDkLyFxvvCcZakUalD0aILzewfiQCep4CJiuC/Yw5jBBUxpipstbAJdnX2a1QMgCAcgTL62Rmhj6toLHhGaA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 8050a907-92ba-4736-3ba9-08d8634fe05c X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2020 01:43:18.9782 (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: lSUUyauNRUodPQTUfxkTf1EJzVrzz9M6VFPu3DJRWheHBWEiAfdnF6B07I5ueMju+g4cCu1L698pKUXncnZ3mg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1820 X-Rspamd-Queue-Id: 4C04zY3T4pz4g0Q X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=DIVSG4ZW; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.57 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.13 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.57:from]; NEURAL_HAM_SHORT(-1.16)[-1.158]; FREEMAIL_TO(0.00)[live.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.57:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 01:43:22 -0000 I have implemented the 1second timeout and put it up on phabricator as D26571. If anyone wishes to review, please do so. There are also D26569 and D26570, which are a couple of fixes I came up with during testing. These patches do not address the "should it be Linux compatible", which is being discussed on another thread. Thanks for the suggestion w.r.t using a time limit, rick ________________________________________ From: owner-freebsd-hackers@freebsd.org = on behalf of Rick Macklem Sent: Saturday, September 26, 2020 7:22 PM To: Chris Stephan; Alan Somers Cc: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Chris Stephan wrote: > New to the list and Late to the discussion. I am thinking increasing the = Len could > cause possible degradation of performance when used on slower or legacy > systems. On the other hand just picking a len and cutting it off at a har= d max > seems crude even with a tunable. Admittedly my naive opinion in this matt= er > ponders, could there be a sysctl tunable that just sets an estimate on ti= meframe > instead of size. As you said 100M is roughly a sec on modem hardware. IOP= S are > already tracked. The inverse of the avg IOPS for the filesystem in questi= on could > be used against this tunable to derive the estimated size limit of the ne= xt > read/write. This would allow the max len within the syscall to both honor= a > timeframe before a signal would be handled and maximize efficiency across= a > large breadth of systems varying in performance. I=92m sure it is more co= mplicated > than I suggest... just tossing my 2c in. Yes. Using time will work for the generic copy case and I think that's a go= od idea. Then we can leave the file system specific cases up to the implementors. (For NFSv4.2, once you send the RPC to the server, the client has no contro= l over how long it takes to reply. The current sysctl that sets a size is still a= bout all the NFSv4.2 code can do.) Thanks for the suggestion, rick Chris Sent from FreeBSD ________________________________ From: owner-freebsd-hackers@freebsd.org = on behalf of Rick Macklem Sent: Sunday, September 20, 2020 11:28:21 PM To: Alan Somers Cc: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) [I have only indented your most recent comments] Alan Somers wrote: On Sun, Sep 20, 2020 at 5:14 PM Rick Macklem > wrote: Alan Somers wrote: >On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem >> wrote: >>Alan Somers wrote: >>>copy_file_range(2) is nifty, but it has a few sharp edges: >>>1) Certain file systems don't support it, necessitating a write/read bas= ed >>>fallback >>>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA >>>3) It's slightly tricky to both efficiently deal with holes and also >>>promptly respond to signals >>> >>>These problems aren't terribly hard, but it seems to me like most >>>applications that use copy_file_range would share the exact same >>>solutions. In particular, I'm thinking about cp(1), dd(1), and >>>install(8). Those three could benefit from sharing a userland wrapper t= hat >>>handles the above problems. >>> >>>Should we add such a wrapper to libc? If so, what should it be called, = and >>>should it be public or just private to /usr/src ? >>There has been a discussion on src-committers which I suggested should >>be taken to a public mailing list. >> >>The basic question is... >>Whether or not the copy_file_range(2) syscall should be compatible with >>the Linux one. >>When I did the syscall, I tried to make it Linux-compatible, arguing that >>Linux is now a de-facto standard. >>The Linux syscall only works on regular files, which is why Alan's patch = for >>cp required a "fallback to the old way" for VCHR files like /dev/null. >> >>He is considering a wrapper in libc to provide FreeBSD specific semantics= , >>which I have no problem with, so long as the naming and man page make >>it clear that it is not compatible with the Linux syscall. >>(Personally, I'd prefer a wrapper in libc to making the actual syscall no= n-Linux >> compatible, but that is just mho.) >> >>Hopefully this helps clarify what Alan is asking, rick >> >>I don't think the two questions are equivalent. I think that copy_file_r= ange(2) >>ought to work on character devices. Separately, even it does, I = think a userland >>wrapper would still be useful. It would still be able t= o handle sparse files more >>efficiently than the kernel-based vn_generic_c= opy_file_range. I saw this also stated in your #2 above, but wonder why you think a wrapper would handle holes more efficiently. vn_generic_copy_file_range() does look for holes via SEEK_DATA/SEEK_HOLE just like a wrapper would and retains them as far as possible. It also look= s for blocks of all zero bytes for file systems that do not support SEEK_DATA= / SEEK_HOLE (like NFS versions prior to 4.2) and creates holes for these in the output file. --> The only cases that I am aware of where the holes are not retained are: - When the min holesize for the output file is larger than that of the input file. - When the hole straddles the byte range specified for the syscall. (Or when the hole straddles two copy_file_range(2) syscalls, if you prefer.) If you are copying the entire file and do not care how long the syscall takes (which also implies how long it will take for a termination signal like C to be handled), the most efficient usage is to specify a "len" argument equal to UINT64_MAX. --> This will usually copy the whole file in one gulp, although it is not guaranteed to copy everything, given the Linux semantics definition of it (an NFSv4.2 server can simply choose to copy less, for example= ). --> This allows the kernel to use whatever block size works efficien= tly and does not require an allocation of a large userspace buffer= for the date, nor that the data be copied to/from userspace. The problem with doing the whole file in one gulp are: - A large file can take quite a while and any signal won't be processed unt= il the gulp is done. --> If you wrote a program that allocated a 100Gbyte buffer and then copied a file using read(2)/write(2) with a size of 100Gbytes in a = loop, you'd end up with the same result. - As kib@ noted, if the input file never reports EOF (as /dev/zero does), then the "one gulp" wouldn't end until storage is exhausted on the output file(s) device and C wouldn't stop it (since it is one b= ig syscall). --> As such, I suggested that, if the syscall is extended to allow VCH= R, that the "len" argument be clipped at "K Mbytes" for that case t= o avoid filling the storage device before being able to C ou= t of it, for this case. I suppose the answer for #3 is... - smaller "len" allows for quicker response to signals but - smaller "len" results in less efficient use of the syscall. Your patch for "cp" seemed fine, but used a small "len" and, as such, made the use of copy_file_range(2) less efficient. All I see the wrapper dong is handling the VCHR case (if the syscall remain= s as it is now and returns EINVAL to be compatible with Linux) and making some rather arbitrary choice w.r.t. how big "len" should be. --> Choosing an appropriate "len" might better be left to the specific use case, I think? In summary, it's mostly whether VCHR gets handled by the syscall or a wrapper? > 1) In order to quickly respond to a signal, a program must use a modest l= en with > copy_file_range Does this matter? Or put another way, is a 1-2sec delay in response to C an issue for "cp". When kib@ reviewed the syscall, he did not see the delay in signal handling a significant problem, noting that it is no different than a large process = core dumping. > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to > truncate the output file to the middle of the hole. Then, in the next in= vocation, > truncate it again to a larger size. > 3) The result is a file that is not as sparse as the original. > > For example, on UFS: > $ truncate -s 1g sparsefile > $ cp sparsefile sparsefile2 > $ du -sh sparsefile* > 96K sparsefile > 32M sparsefile2 If you care about maintaining sparseness, a "len" of 100Mbytes or more woul= d be a reasonable choice. Since "cp" has never maintained sparseness, I didn'= t suggest such a size when I reviewed your patch for "cp". --> I/O subsystem performance varies widely, but I think 100Mbytes will lim= it the delay in signal handling to about 1sec. Isn't that quick enough? > My idea for a userland wrapper would solve this problem by using > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for > everything else with a modest len. Alternatively, we could eliminate the= need for > the wrapper by enabling copy_file_range for every file system, and making > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with > large len without penalizing signal handling performance. The problem with doing this is it largely defeats the purpose of copy_file_= range(). 1 - What about file systems that do not support SEEK_DATA/SEEK_HOLE. (All NFS mounts except NFSv4.2 ones against servers that support the NFSv4.2 Seek operation are in this category.) 2 - For NFSv4.2 with servers that support Seek, the copy of an entire file can be done via a few (or only one) RPC if you make "len" large and don't use Seek. If you combine using Seek with len =3D=3D2Mbytes, then you do a lot mo= re RPCs with associated overheads and RPC RTT delays. You still avoid moving a= ll the data across the wire, but you do lose a lot of the performance adv= antage. I could have made copy_file_range(2) a lot simpler if the generic code didn= 't try and maintain holes, but I wanted it to work well for file systems that = did not support SEEK_DATA/SEEK_HOLE. I'd suggest you try patching "cp" to use a 100Mbyte "len" for copy_file_ran= ge() and test that. You should fine the sparseness is mostly maintained and that you can = C out of a large file copy without undue delay. Then try it over NFS mounts (both v4.2 and v3) for the same large sparse fi= le. You can also code up a patched "cp" using SEEK_DATA/SEEK_HOLE and see how they compare. rick -Alan _______________________________________________ freebsd-hackers@freebsd.org mailing list https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.f= reebsd.org%2Fmailman%2Flistinfo%2Ffreebsd-hackers&data=3D02%7C01%7C%7C2= 7ea5166cf99415d3bba08d85de6d259%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%= 7C637362593231297450&sdata=3DSfm9MxjQ6MVHgG%2Fw3sghn0hebSFjZo%2FSaUyZ9H= Pyws8%3D&reserved=3D0 To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Sep 28 09:50:17 2020 Return-Path: Delivered-To: freebsd-hackers@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 524643FD21C for ; Mon, 28 Sep 2020 09:50:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C0HnP1QHyz48BQ for ; Mon, 28 Sep 2020 09:50:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1601286617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JdO1VJ+6jJ5mfArGbPc0Ipfo0EhYHF7ZqHexhxysBxk=; b=tJ3CA3y5v6eTxz7EQz82wIyWJD7xNurAUF5OGpBSMy9BNwEgQpv2jVLLFVdKhhhRwnhnEH tE9lDXrMu75XRWFp+ssyfVDBBurrpIcBKFxWRlk7SZ9x8mn8iS9q9ApIHWNt85SKxxRimn g4hhbGXT+JHtAjl6pRcehwEKF3u9cFOxniyiSXHw/6psg3v5SQH0sbDXfYFS6J/ws248xo hid/oa+BeGAExI640pURcKusKS1TfB2u32t8FopTfz4uNLYOOLfI/T8f5whx1xdJnM9uad vWotAiSbZfVx/bFpAcsb5SwBOH08x5DZgDQ0N4AL+Is1X+BYwJuVSjdqhXIzAg== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 20B40DBB3; Mon, 28 Sep 2020 09:50:17 +0000 (UTC) Date: Mon, 28 Sep 2020 11:50:14 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: Is it possible to exit the chroot(2) environment? Message-ID: <20200928095014.ohhug4amcao4747x@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> <3d17ea59-0e85-4e33-f426-deec99f07b83@rawbw.com> <4702ab92-0cee-133d-62c9-1cfa787379e6@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pawcz25trzurace3" Content-Disposition: inline In-Reply-To: <4702ab92-0cee-133d-62c9-1cfa787379e6@freebsd.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1601286617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JdO1VJ+6jJ5mfArGbPc0Ipfo0EhYHF7ZqHexhxysBxk=; b=RSCj9z9Z12+KbBzcBqJKSKc3gsKVEobkYmhA+aFB2r/1/kCmJCrh8x5uKCcqUEkSdui/jG ZYS8sq3LyLrOt8XrHwJyqtIom7N/ryNMhaOQFlByJWRz97u9lVK55L011LyhTpkOa0tBYJ wkAiNCFkxvQkk+kdel9PqWf/ax+51FJ6n9ik2UQV3QzDdSPkDjKu7pVtd7ZXSye7GK1ynw Vce4fj/OCgmZMEYon6uHQJypxoR98pKmRUZ5py0wBlE+JESrd5c0EhFHvXFC3F5DzyQ9uP 5v5Tcknm7NlDlud6OLYzDT9xOLeGPZluKqB2LHuqfmSynmDzQTGm1Wmsk8b8hw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1601286617; a=rsa-sha256; cv=none; b=oZgeJdO5+NA0Mi/8nOHlKX3XIDPX6zALRjI7PNczfderpTQUTkCCwivZK4giG1OqWFhTpZ uW3xJbLYhIOt/C2NsVXB86xbcdxcVRi12YAsyuCrB3yP5NGXyVkMb8QhJEMtB46j9qv5pa n8ACpJ4DxjpHrri0f077LdQyznJaGLkB+mNpl2It6y89NAgmDIUL430btRmbs8lNEKfXme h3PpHXrS5RnT2nS7gwIrhi2niVojlc7w4YVTf3mfVcH39KHjatrWRQe5GovovYKLmblQLt Wvdm4KVpf30/O2V93oaVX81kstdcYl/xkh8LrsyYb2O6ArgRiMwGr/5FR3JUUg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 09:50:17 -0000 --pawcz25trzurace3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 27, 2020 at 03:24:05PM -0700, Craig Leres wrote: >Don't forget about fchdir(), I've used it (in non-chroot()) programs=20 >to implement pushd/popd functionality in a recursive function. > > Craig >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Hi folks, In reading this thread, I was reminded that the jail paper from SANE 2000 [= 1] documents both ".." and fchdir() as well-known methods for escaping, with t= he=20 former being used to escape anonymous ftp access in the ftp daemon. Similar= ily,=20 I also have vague memories of cd / being used to escape chroot. The section also mentions that new code was added to detect and thwart thes= e=20 escapes, so perhaps there is a commit log that would be interesting to look= at? Going back in history a bit, from the 'Special handling for ".."' block in= =20 ufs_nami.c in 4.1cBSD [2], it does seem like chroot wasn't even meant to pr= event=20 escaping in V7, and was noticed as a result of redoing namei() for FFS, and= =20 subsequently fixed - so it may be that other Unix-likes inherited different= =20 logic than the BSDs? [1]: http://www.sane.nl/events/sane2000/papers/kamp.pdf [2]: https://minnie.tuhs.org/cgi-bin/utree.pl?file=3D4.1cBSD/a/sys/sys/ufs_= nami.c --pawcz25trzurace3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl9xsdZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87r22gf7Bo43VC6Lt+lpwZgLniW5VHn2/WaBVZfmmNy38BXxA+qwKTnLz1RxjRNb vQh4Qga6t941MpIZV4+SbjdLkSa2xixcX0BerQJGX0AsSM6LnDM5WLDf1gHui+GF sVDF8yo/6Mmy4Lh9jJ+xWci49HF+eZ5uMsWzGp0sK0WcJJgC0qHGPt6QP/P980on VmuXasI3ZXdfHlMSCGWiB/kyOB5NF2h9AzUXG7NZ5FL3MLgIkQ5uNna0r6WzOHV8 rdKJKaBh+25g0QVKnhI9u8hTImgEJDNDybX0cTwFPNB/HOrmKz6osN+DkW8/7cvx 5R/yxBNHnUk02A1u93fijKfc+fJzVw== =XFBY -----END PGP SIGNATURE----- --pawcz25trzurace3-- From owner-freebsd-hackers@freebsd.org Tue Sep 29 17:09:45 2020 Return-Path: Delivered-To: freebsd-hackers@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 8ECD342A2DF for ; Tue, 29 Sep 2020 17:09:45 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C15V05hgVz3cKk for ; Tue, 29 Sep 2020 17:09:44 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-vk1-xa29.google.com with SMTP id a16so2616950vke.3 for ; Tue, 29 Sep 2020 10:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sAbhMu4Q+A5+L03Yyd/wSYvwjfsA9twO14Y0qNq7JQw=; b=Y55MRamLWzDcwZ7PwvhMvoGcDAxWu2H9EF4NGsSNevWZiMFnC2RERWmc3bbsH7Nw7v tfl+V9uhI9JAIZd1A/lSg9K/beViZSDdcis+RGQXGarnWuNTsmbFIv8hMqs23PRt6OPn O50BcZIANclxpZoEZ9GPuG2CHiOSmpi/YmfdYc9LLkqY96oaldBu3PlG/KzGK+ZVjE+z eNHBIcXABX4Z5bUVshIEKgxZH1cv3MS7s01VqX20tZVCF5VD1KbZIBft2fqIcEUgJC5v 4IZeKAId1o5ARevn7/HFb2NkxfYDXqGtpSjSPvi7SqVM6RcJKJzBILJbqIxCDcRBqybh p+DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sAbhMu4Q+A5+L03Yyd/wSYvwjfsA9twO14Y0qNq7JQw=; b=jsoz5xrukwZZlPycoJ68If3mKWGUDBsLbMOuYi+NupDWPWOJObzYaOUALft4pqDHHw Dfo9PuZ/ADLzUrdYFS+zeSBTwAeBSvGzbxD+nuhfSXYlX3mROhZu6PKGwufRGH/tMo0f y5Z5l/F3nbmQHW0GwNXDYc9FHUtUJQs1kX8r0zJyegyyzMMuRDhkEERMgz1g7RULef6f c01EbBKVUUIYrEdXTjGrJgdB8GyDEUppYyDEUGIYLJtjQpn23GJx/GDOqpbscMpcAysZ Ksg4mtl3cmk1eLN8XkUwucgm4zZV9Oa7OJNIYS1M8XEh5q+j3AGuknLAw64iEmCkCOqN gMPw== X-Gm-Message-State: AOAM533MgyNxjKA0Y34lJXJtxqOJ5Lle49SGmUt7PicaNCNxEemQ4e1t 6CojFkyuvMPmGvAG/HBZ+cxfp4S+sp9df3v/qaYDqap7EN99MQ== X-Google-Smtp-Source: ABdhPJzpjeBd5YjZxKtJtZFaUC2MMgSWCKvWfoHLofQ2QyT5vuGmybgQ/OHeVeRahfKYW61f9XeKw3zuzdGDd3cMe/s= X-Received: by 2002:a1f:1e4b:: with SMTP id e72mr3631411vke.17.1601399383500; Tue, 29 Sep 2020 10:09:43 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Tue, 29 Sep 2020 20:08:05 +0200 Message-ID: Subject: D26158 looking for reviewers To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C15V05hgVz3cKk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Y55MRamL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of fernandoapesteguia@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=fernandoapesteguia@gmail.com X-Spamd-Result: default: False [-2.71 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.57)[-0.572]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.83)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.952]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a29:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 17:09:45 -0000 Hi there, Could anybody have a quick look at this contrib/nvi related fix? https://reviews.freebsd.org/D26158 Thanks! From owner-freebsd-hackers@freebsd.org Wed Sep 30 07:13:59 2020 Return-Path: Delivered-To: freebsd-hackers@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 D72E63FE27E for ; Wed, 30 Sep 2020 07:13:59 +0000 (UTC) (envelope-from shamanthkrishna23@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C1SD65S1Dz3ZHL for ; Wed, 30 Sep 2020 07:13:58 +0000 (UTC) (envelope-from shamanthkrishna23@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id z4so524870wrr.4 for ; Wed, 30 Sep 2020 00:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Vv/R7FQD9RKvTGTiRizjM+seAxV3G8eeRcfHtHvt0pY=; b=GukKM4ARQCkM6gcCWkfQ2/WHHKo3BhfmdwmZU9EMOQuihrJpZC4k1J8w9+iUrgCkjk rSIEQ29FE8R6UXpnOP2Q5zthK9us6W9jDQZ4oyHVcqwWmGp6q2qYIkQygPjhiNoV07SQ nDarme4z3Qp9Ye2aK18uorplRJTwf+KKVw6I7+2ecTFsmlw/9EHtFqzNAdDVomfeD2L/ sJPuxlPJG1fCXQMLK59OvHkE7PSHLgO/cc4eSWnZTi+9DzqMqqkMQXg5UVW9nSB4Ki6S Pg28WS5vEq2mFk0cBib8vaLnY1vyLOtDSy8kTf9FSIDQGO8cvutjbKbQyOdbo1RfRu43 Av/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Vv/R7FQD9RKvTGTiRizjM+seAxV3G8eeRcfHtHvt0pY=; b=p1tHGiHGfHHXU39doNah3TUuzB/g3pAtyZWHbqniicC5NM38NmXxCpVv2UjZuqatMk Y1yrKQbkFYCZ5bMiGqXrAzEwvoLh5ArYZ50YI1MEoD1YpN4M2iWkxd8o9QLicDyQGlw0 BbNAoyRxxXx29U1mq2h9lvC9C353/Na0lOPaOe/9Q/EXMJ52Za7AqlTqnF1p59PkpkBF J1OKavAZwBvHQwdIveuxV/3ex6QZg1ZlHxzpY0/hGkwp5vrUVjnJA1EJ2rm0C4Oa9Zi1 H8Ray9YJaZjETcW1fTv2S0RKTruJoElhbHXYkLrdVi53ZFznxTUnEy7fqV7U303P9fFo z7eg== X-Gm-Message-State: AOAM530QvTUZg2X22xwhK3PbulasR0sC2yxx/ELKD0s/kW2S1tg9d4KO MFXvZ9V2n1sTu8Ot781vwFuV6ML2RzIDwhdQrobOochvpYT3ew== X-Google-Smtp-Source: ABdhPJxOQW0/bWVR8IMsh/kDx4kNHRGtdGOYtixSd+B1TeiatAqeo5ksV/zH1NXHKekHHX2EgStaFNG+mKPmZc4SSb0= X-Received: by 2002:adf:df81:: with SMTP id z1mr1498451wrl.9.1601450036641; Wed, 30 Sep 2020 00:13:56 -0700 (PDT) MIME-Version: 1.0 From: SHAMANTHA KRISHNA K G Date: Wed, 30 Sep 2020 12:43:45 +0530 Message-ID: Subject: vm objects . To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 4C1SD65S1Dz3ZHL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=GukKM4AR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of shamanthkrishna23@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=shamanthkrishna23@gmail.com X-Spamd-Result: default: False [-2.43 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.02)[-1.022]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[1]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; NEURAL_HAM_SHORT(-0.47)[-0.465]; NEURAL_HAM_LONG(-0.94)[-0.943]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 07:13:59 -0000 Hello all, What exactly does each of these vm objects means with respect to* /proc//map* vnode default device swap physical And given that below are the fields corresponding to each entry in */proc//map* ,what exactly does *flags* mean, i,e *the field after reference count and before COW* *start ,end ,RES ,PRES ,offset ,protection_flags ,shadow_count > ,reference_count ,flags ,COW ,access ,type ,charged, charged uid* Here is the code to the /proc//map filler --> https://github.com/freebsd/freebsd/blob/9561dc969d120d90918ddce5b82604ca349d592c/sys/fs/procfs/procfs_map.c#L219 Thank you, -Shamantha. From owner-freebsd-hackers@freebsd.org Fri Oct 2 02:10:39 2020 Return-Path: Delivered-To: freebsd-hackers@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 6887F3F211A for ; Fri, 2 Oct 2020 02:10:39 +0000 (UTC) (envelope-from jmaharaj2013@gmail.com) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C2YPB52w5z40tr for ; Fri, 2 Oct 2020 02:10:38 +0000 (UTC) (envelope-from jmaharaj2013@gmail.com) Received: by mail-ed1-x542.google.com with SMTP id c8so123869edv.5 for ; Thu, 01 Oct 2020 19:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:mime-version; bh=7oeyIsVWHH2p2bzEUFmPAdfOFxbmlIzH/6sIXNpgBCQ=; b=cKo6SixyP5sG9PqfWGd66PPu4mNFrMD4Bq2i6OopN/NyW7r5UXWr0ntd0e4lsyY7Xz L2xN47jysnLDY+Lp4NWoXSQEJqFWyuIpiy13b/77+OGS1gfpg9e3OqaIp+RpoktIjBQj mPh0tOR6RPVda1s198PcLjF+PDJdXlEKGL6SZ2WHDwqQtweigIrwamYwAFYc3K/l2/Oj qpsJCHQXWc2vbJeIx2cqT6IjnKqioo/10mgO5oLQI2wyhewyOLxnqS494SqbbCPhw+7P 8vvm6b+CrNVrQpuhf6i8Kb2OTBPqguLOeb18GL1mKjYtFSN9WyIAqLY6v2GeqpDSIG9o 0XtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:mime-version; bh=7oeyIsVWHH2p2bzEUFmPAdfOFxbmlIzH/6sIXNpgBCQ=; b=mmwR+76uIv6l4xgPkOQfmsinSf8dMuv5ltTLgCD6X2KypUD2m1Yc3ojiNO+sSxnkMB NTonPi439U0rSgISqZgPe02a+z2PuKSfejs4MajsXhEJMhKcuDZR+JOLlv43cabon+Vz hgkprue2THRC0ol2gt8HjEG7SOv67FKxukCh95kSeoTPourVYh5lqhKBHbQNo36FyCCD vOU410oarsn3xHr1se78cAyTUk3kQfPfaw6jW0Wg7qcazb565+BXeac6dM1veOPUUfRj 5bRXMgZUiCxtTVy7+5ZFeMzupeNAW5iFDecncfoKnRzM5MgGz7102gFUgMaGWaL1ORaO oewg== X-Gm-Message-State: AOAM530m7E2ZK6fL14yCiYCtPp/RCeMsCvfWj1qrU7yZlf2Y90QWQDW1 0T9pxAvRk//wU+vZswCViQ2T7j8kK1M= X-Google-Smtp-Source: ABdhPJzN2czSlG2azMlT/lvX2YOE8qqPlxJlOUSa81dIul/2rgeRxAlokjcbxleaaSTK6SejgZ9mYg== X-Received: by 2002:aa7:c70a:: with SMTP id i10mr11448462edq.218.1601604635735; Thu, 01 Oct 2020 19:10:35 -0700 (PDT) Received: from BYAPR05MB6311.namprd05.prod.outlook.com ([2603:1036:307:28c7::5]) by smtp.gmail.com with ESMTPSA id x12sm79308edq.77.2020.10.01.19.10.34 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2020 19:10:35 -0700 (PDT) From: Raj J Putari To: "freebsd-hackers@freebsd.org" Subject: Idea: Signing software with stuff like ssl certs Thread-Topic: Idea: Signing software with stuff like ssl certs Thread-Index: AQHWmGE1Nuel7zIVI02UZP8EK96NSQ== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 2 Oct 2020 02:10:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4C2YPB52w5z40tr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=cKo6Sixy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jmaharaj2013@gmail.com designates 2a00:1450:4864:20::542 as permitted sender) smtp.mailfrom=jmaharaj2013@gmail.com X-Spamd-Result: default: False [-3.45 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.97)[-0.968]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.003]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::542:from]; NEURAL_HAM_SHORT(-0.48)[-0.481]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 02:10:39 -0000 No code yet, I don=92t want to use qemu because I heard its fast, but reall= y hacky, but I=92m working on buying parallels on the third with my SSI mon= ey because my dad bought me a mac pro 2013 off amazon (which is amazing by = the way) For ports and packages, a package distributor signs the software with an en= crypted key, and in the kernel we check it and decrypt it on the fly, or st= ore information in the swap (which can be encrypted as well), or in a direc= tory, I suggest in the /var or possible /usr directory, but I don=92t reall= y want to break heirachy for systematic reasons In the kernel, probably in some directory, we have a source file that loads= , checks, and does various checks on the cert and checks it, and if it pass= es the tests, it loads it into memory and executes it, using conventional p= rogramming Failing that, and I can work on this later, but I prefer if someone else di= d, we can just have a userland application that generates a key and signs i= t (not sure how, I haven=92t really googled or checked on it) Also we need some kind of web site and possible a protocol (welcome back 90= s) that deals with issuing certificates for software such as applications, = software, and device drivers, kind of like letsencrypt My logic is that if you cannot access a resource due to encryption, you can= not hack it I honestly suggest. Fork, since if you encrypt the entire kernel, theres go= ing to be problems, so I strongly suggest everyone team up with their assoc= iates and make a fork, or possibly implement it in openbsd What does everyone think? When I get my check, im going to cludge around in= FBSD13-CURRENT From owner-freebsd-hackers@freebsd.org Fri Oct 2 03:50:32 2020 Return-Path: Delivered-To: freebsd-hackers@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 ED31D3F4C84 for ; Fri, 2 Oct 2020 03:50:32 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C2bcR6sn7z45Zr for ; Fri, 2 Oct 2020 03:50:31 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lj1-f179.google.com with SMTP id w3so81041ljo.5 for ; Thu, 01 Oct 2020 20:50:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kJp7jqGo3vvucYFSyFT7CkjU/HVRu5bLX2RfA/hTQaM=; b=rGCUY/VeUrHUyDywImHuRAtG37tzQdyQ1HrQmRR1Fe0ZmvvgR+Yd+ow0lTr4veJEhB 7kWZAR9aTrxCodhbePk1d9MsgUaZFdkaQhKo2AeeNot10bbmh3tMf80rQ40zcppokFXN ErjvzHu1I9+NO8OxvCCvt9DYm1GbstCNkWubcS962fSYPVp10uFBKJ/+MCW6RRMaep2h /uxjFLzElJ6LTNHR5Tknis+2fkSQqHZsl/sJ2M0ZyzmgO/7gA2YZQkGQ45vRawzaxREk dMFT28/2Z24OtE7cxTMJfIsZqTks/f4EFKY9ArXm4ekMCLiS6jMdeiSL2hsagvHNlZ3J k9RQ== X-Gm-Message-State: AOAM5312AYlWpvq/+m7JDXCf0fzUK9DA4ySrHZZ4TzK2XwyGXvyXwv8Q M9uqiHCOAQAWaEN6/YbPo+3PTxod2hmLgA== X-Google-Smtp-Source: ABdhPJzyvlaOuXoeKyfzx+lA7asePYEZy0SyKi60jq8gCCNrsvPxRy3/t69K58FR3+nDL9IG6laguA== X-Received: by 2002:a2e:b52c:: with SMTP id z12mr102482ljm.437.1601610629265; Thu, 01 Oct 2020 20:50:29 -0700 (PDT) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id b22sm48085lff.183.2020.10.01.20.50.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 20:50:29 -0700 (PDT) Received: by mail-lj1-f178.google.com with SMTP id y4so73806ljk.8 for ; Thu, 01 Oct 2020 20:50:28 -0700 (PDT) X-Received: by 2002:a05:651c:505:: with SMTP id o5mr120784ljp.177.1601610628800; Thu, 01 Oct 2020 20:50:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gleb Popov Date: Fri, 2 Oct 2020 07:50:21 +0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Idea: Signing software with stuff like ssl certs To: Raj J Putari Cc: freebsd-hackers X-Rspamd-Queue-Id: 4C2bcR6sn7z45Zr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-2.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.96)[-0.957]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.64)[-0.638]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.179:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.001]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.179:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 03:50:33 -0000 On Fri, Oct 2, 2020, 06:10 Raj J Putari wrote: > No code yet, I don=E2=80=99t want to use qemu because I heard its fast, b= ut really > hacky, but I=E2=80=99m working on buying parallels on the third with my S= SI money > because my dad bought me a mac pro 2013 off amazon (which is amazing by t= he > way) > > For ports and packages, a package distributor signs the software with an > encrypted key, and in the kernel we check it and decrypt it on the fly, o= r > store information in the swap (which can be encrypted as well), or in a > directory, I suggest in the /var or possible /usr directory, but I don=E2= =80=99t > really want to break heirachy for systematic reasons > > In the kernel, probably in some directory, we have a source file that > loads, checks, and does various checks on the cert and checks it, and if = it > passes the tests, it loads it into memory and executes it, using > conventional programming > > Failing that, and I can work on this later, but I prefer if someone else > did, we can just have a userland application that generates a key and sig= ns > it (not sure how, I haven=E2=80=99t really googled or checked on it) > > Also we need some kind of web site and possible a protocol (welcome back > 90s) that deals with issuing certificates for software such as > applications, software, and device drivers, kind of like letsencrypt > > My logic is that if you cannot access a resource due to encryption, you > cannot hack it > > I honestly suggest. Fork, since if you encrypt the entire kernel, theres > going to be problems, so I strongly suggest everyone team up with their > associates and make a fork, or possibly implement it in openbsd > > What does everyone think? When I get my check, im going to cludge around > in FBSD13-CURRENT > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > No offense, but the message looks like it was autogenerated using some neural network algorithm. Sorry if I'm mistaken. > From owner-freebsd-hackers@freebsd.org Fri Oct 2 04:25:15 2020 Return-Path: Delivered-To: freebsd-hackers@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 973743F54F1; Fri, 2 Oct 2020 04:25:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::616]) (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 4C2cNV2cwTz46lM; Fri, 2 Oct 2020 04:25:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l07uyznkvUjREQ7PYIne+S16X2pQnG0HK/4WyRyTQhVEXBMWmdeUyTe/jjHSWkh335g6DvEurKCEqo4LKH5Ey5zyfUgNUgL4zuM7eZioynUS0nQb8pXZ4vsB5zuwLo9K6rdn6NzldCBDFuxMAKn/GXXSef2eB5t/VZkjZWdTLnT8P+4E5N6eep6AYifjNdcBhLkUCbd3czZSoIjEVUlFwLAqCuYHYYhlNQBkfaPSJ+TbmvvqxmexWb2Jo/kuDiSiA+0AnHBMqsZXZ4SRado38bbehpwK6gluo1RUQ4H/NlDfhSuzSJqU4XEaqRuh8aKCh98RDBcSkorrUyvlgs43hw== 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=jg4YNQMy554FWRZJQma1s496zGXbeUsGCi5dTZyESFM=; b=gATcj4ldM1WNcH5vh2VfWLy2MnQdDWJKbPUeiExV3+nmcCjYDvtLq2ldhpCvd2BxJFEiWJALHXWckGcyFfIoTginDt+yadWlJIBVyORu2neNniM9J9EciMRgMP7ITCvahexD5YkDYHEtZT2OAArkDbqMEFyCQTNuVg6vIK4uM18YggwbLBCObvR2cNJ41oRE02TCiboqglAxd4B/f4ZA+CpI+anzey4F8KFVV15h415f2neOqKZi8ouQlHswk9gYUBl1ZO+hs1/UzWuz7pCwLnw0qF9FUemfTQX8hxfjEvLHathLVTLPkHHZasyAF93gQ0eFXnngPIRHQXRfaI410g== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jg4YNQMy554FWRZJQma1s496zGXbeUsGCi5dTZyESFM=; b=i4wDLtSpGUVRaPrMDI43swUB4Uihygcy19YDXCthHWHOPnGaUMIDnt4gmMjcjRaanBZ8yy5JOQixXxFkj7DA/+IrcwUeSshYdJwKxG6wgQt8Qjyqn8b6I/ZqCofHoMPvRZptxApo4OWJ/sfapxUnlYEJBgyLKaIdQ9Hr4AHaH+bl4t8xuvgurHJ4Rdrzcn8h5//LoJAr1dzUFBGViVh5g1QjX1Kapw4xKLq7+vKmuqhl9r2eFDhjuEkz3Veb2gBEULvyB2LeUwkcRz35wLGg9O3MVMyVYUiUUiL81Xu9YdEecwRzVzh4NbVsaCwXXmb15tszZ0DEeTDQoNzNR5qHBA== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2426.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Fri, 2 Oct 2020 04:25:10 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3433.034; Fri, 2 Oct 2020 04:25:10 +0000 From: Rick Macklem To: Mateusz Guzik , Alan Somers CC: "Wall, Stephen" , FreeBSD Hackers , "freebsd-current@freebsd.org" Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFK6l7nDvmgAAr7eCAALVoToAADHSAgAAPsQCAByNZ/w== Date: Fri, 2 Oct 2020 04:25:10 +0000 Message-ID: References: , 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: 6f8cfe24-4071-4626-6b0f-08d8668b26a6 x-ms-traffictypediagnostic: YT1PR01MB2426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wnEijiPQNmKWL/w6bf6UwXF9jO/LEF8pHl9ASoio1k14KrrI7Q5VN63myyqrOFs9S4qtNgpqGet+QBuhncWtMdTLh/U4+oHQU9ieyFTrhIKPe4JyW1VIgYKxfkNTtU/g8IQC6ycmEICqgd/EIGBJCnZ24PWBPmuR+NY2A5sC1tCUdFUWpjJgO2HVACQKAmyZWntwfZ2D4JwxB++j4HKQf8P2zDOtRTSjPczGKe8rxsUEDLWZRjoUadTWgc2xpdMfM9sb8v20gG/OB11H10+3bR98mOCQvSV5UpXDsDyIxkxt42jXqJQ1iyUjE4xGoWEI1w+CBHaUKzHyHL/shy1ajg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(396003)(39860400002)(366004)(8676002)(316002)(478600001)(786003)(8936002)(71200400001)(86362001)(55016002)(9686003)(33656002)(4326008)(66476007)(64756008)(186003)(53546011)(5660300002)(52536014)(6506007)(91956017)(66556008)(66446008)(7696005)(76116006)(66946007)(110136005)(54906003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: o8B8LqTu5O7Fh5witrF10soGGLt6jY1mpbviW5AhuB7KZLjlfReq+tDCXgkhIwWdIMJwPlqqU5uuFSVq/jJxeqMKujpzLcHuF50lVqOULdshFVf/W18OrAKTmGUIizgHgQb2GsclXLeHBJg+0KGZr6CmNEcKTMcTkj8/M4ClR3TrP1m+IBkN7OLkPQuWKFUsZTOGymknBYURcyMgnuC0SGLq4xlyAjyYsm9f9ElGjGdyXIt0Kcq5vspt6WWjfpiUjp9zkeOqGauC6ExzxBDaJB2Zpb9tsLiAfHRFkg0jVN0iPS6swFm5TlR0FIAQjp9u6FYJlr97CcxnGZH1T5Xu6rUYl1k+uIT9lMCUiXtzPQ3G1HvCOsgodExagVvHq8uZaSy1cSGNmANHDEkd1o+T6dzzRJai9apLMRzHnq2iWjJYZqhBq9ILpjora03TJhmGd7LTn8DOJ1VzEaCaaqgO46Lw11edh8egfKoPwUZKrW9qFNFViRtBAKjYyIw86gKl9Rvl247moacvc60SpJ2aDZOrITlvJx8wsPotK6OtDjW6GimQbevWHohqqOsYLiWDXwpNXGDKb8IITgnKnh1FkaLovkq38mOVzTii9rBhJohLQBwyBR5mRAcaeJSdUnGlRbogpEkrqjxrSL5DgVk3yl51rucopFiU/OzCQnoWjwgVhOdH3W52OjVvllm2NJZsxKoGivKlyuhIVDYZKzzW5w== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6f8cfe24-4071-4626-6b0f-08d8668b26a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 04:25:10.7243 (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: MOijainVIaVzHok/RiYQxAqsrmFx4U7uripkRG0JSLWqbfG2PkDUMO6Nby0ESp2RQW+io/GxqZfMO0CGg07evQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2426 X-Rspamd-Queue-Id: 4C2cNV2cwTz46lM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=i4wDLtSp; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::616 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.07 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.026]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-0.94)[-0.937]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.10)[-1.103]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 04:25:15 -0000 Mateusz Guzik wrote:=0A= >On 9/27/20, Alan Somers wrote:=0A= >> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen = =0A= >> wrote:=0A= >>=0A= >>>=0A= >>> > I'll assume you are referring to the "flags" argument when you say=0A= >>> "param" above.=0A= >>>=0A= >>> Correct, I was misremembering the man page.=0A= >>>=0A= >>> > However, since the Linux man page says it will return EINVAL if=0A= >>> > the "flags" argument is non-zero, you've still introduced an=0A= >>> incompatibility=0A= >>> > w.r.t. the Linux behaviour.=0A= >>>=0A= >>> This would be a one-way incompatibility, i.e. code written on linux wil= l=0A= >>> run unaltered on FreeBSD.=0A= >>> If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever= ,=0A= >>> important part is `FREEBSD`) it will be quite obvious that this code=0A= >>> needs=0A= >>> to be adapted to other platforms:=0A= >>> ```=0A= >>> #ifndef FREEBSD_COPY_DEVICES=0A= >>> #define FREEBSD_COPY_DEVICES 0=0A= >>> #endif=0A= >>> ```=0A= >>>=0A= >>> > Why require extra work for so little purpose?=0A= >>>=0A= >>> I'm sorry, I'm not sure what extra work you are referring to. Specifyi= ng=0A= >>> a flag on copy_file_range(2)? That's trivial.=0A= >>>=0A= >>=0A= >> It's easy to leave out, which could cause a lot of pain for users who do= n't=0A= >> understand why their application isn't working.=0A= >>=0A= >=0A= >A FreeBSD-specific flag to a Linux-alike syscall is bound to run into=0A= >a conflict at some point, making it a non-starter.=0A= >=0A= >>=0A= >>>=0A= >>> > My opinion is that if we can make it work for character devices, we= =0A= >>> should.=0A= This turns out to be a lot messier than I thought it would be.=0A= For example: /dev/zero cannot be read via VOP_READ() on the vnode.=0A= To read it, you must us dofileread() on the file descriptor.=0A= --> This implies a separate copy loop from the one implemented by=0A= vn_generic_copy_file_range(), which works on vnodes. (And that needs to= =0A= remain, because the NFS server only has vnodes and no open file descrip= tors.=0A= =0A= At least that appears to be the case when I tried it and then looked in=0A= sys/fs/devfs and sys/dev/null when it didn't work.=0A= =0A= rick=0A= =0A= >>=0A= >> Well, collecting opinions was the point, no? :)=0A= >>=0A= >> What's going to use this function besides system commands? I think I sa= w=0A= >> `cp` and `dd` mentioned - I think it unlikely you need to be concerned= =0A= >> about their portability.=0A= >>=0A= >=0A= > Userspace RAID-like applications could use it for rebuilds, and they'll= =0A= > need it to work on device nodes. Userspace NFS servers and iSCSI servers= =0A= > could obviously use it. And since the FUSE protocol includes a=0A= > COPY_FILE_RANGE operation, many FUSE daemons could implement that with=0A= > copy_file_range(2).=0A= =0A= I think the first thing to do is check what Linux is doing here, most=0A= notably they may have other primitives to take care of it and in that=0A= case would be best to implement equivalents.=0A= =0A= I don't have a strong opinion on VCHR support. I will note there may=0A= be Linux code expecting to fail with such argument.=0A= =0A= If Linux-compatible approach mentioned above is not going to work out,=0A= I think the best thing to do is to add another syscall=0A= (copy_file_range_np?) which can be tweaked however we see fit.=0A= =0A= --=0A= Mateusz Guzik =0A= From owner-freebsd-hackers@freebsd.org Fri Oct 2 15:47:39 2020 Return-Path: Delivered-To: freebsd-hackers@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 DF1A443070D for ; Fri, 2 Oct 2020 15:47:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670063.outbound.protection.outlook.com [40.107.67.63]) (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 4C2vWt74lkz4Ljf; Fri, 2 Oct 2020 15:47:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iYSO+IArlT68K3Cpg9Enj11qo3aCCvBMB+KcB8l2sREwHjHZWQihWAfZwkMh57P9iQMw8tfrVMC9242bNtVFbm0xTNTys2ziRrCYvpbfoI8bnMTri/UsXmlh/5XBBQ2n9hYySPMS6/TPSznaRkN6qqhwTyHXevMAfccX0zeTKuipb8NS1uBTLKDCq7e2zg4xJ2IYrE9Dhu3X/YCU2poNF/m1XCiepm0peuIMYyRGfCe4dz5VfK9i7iv/EFOTZuyv7Hq7dC+NYqQ0FtRLFm/Pgm26h7glrrnmmnr0XAPfhY5HNlf5WsuVqWjFs8oM8EGT7rGxEpwTmjRjeNB7F1LyNw== 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=I72CMT3rdqblECxvIlmi3awhJJJb7DCiXuW4ce1iaRw=; b=HuUmhKbtcbTWvgOnN/RJ5rwp4XJRU0hrvcoPicX1piBQ7wNMKp1zGAqMSUofyAU+OgINPTJFIGX8DhW0Gh2bRRd0RtU7ZgWUM+RS7e6Roe5nUh2mwQgEgseuULiBbhZIdlaW16VyMWMnPdkssNab9O3UxpmXCvMkykN5PaGOv3lu1ZSo8AiqCAhJBg05a075cK2uB5/h7Sa2gV7GyH9m8IsEHyOWYPYjo1mZzFrPPjg5o6nALYPZYHdBu0aEWkVfXiJhWdgpDSfpgAexkJ+54mY3vsvxBYM0qXeF11wv0K/ABaqavElmko/nRfFJ+Ywv/+5HzggAXygZPFbPMcNjtw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I72CMT3rdqblECxvIlmi3awhJJJb7DCiXuW4ce1iaRw=; b=mBc76zjRadVKPos75S7U+HzhI8oTPPoHXaZVdsDISKvh+zGkElvumgrAFGpAtKZgQnfE7ZxOLIHXk4mRzRjN5wlVkPlJ0AJV1F4lFL+DBt9rBcEMAz6DdHJcHpJirE1YMapXd8uaQVEli+GItLFE3fSVg/3KyzXFYkWlfiGeGOP1oSpfbjbhZ+1+QB5/mOT41ko7UNt+yP74N1paD0ed6IylNtkcaR29p/oV7+SCe4KhoRNfi4X0pjWfpO+j5TQpt0aQWIT85lvdb4DtixdihQcRmbvo2ppb2KyxeKeAUCbtHW9IXDut52+RrycxX2QcN0DbDBha6T2W6dRq8ULWXg== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2426.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Fri, 2 Oct 2020 15:47:37 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3433.039; Fri, 2 Oct 2020 15:47:37 +0000 From: Rick Macklem To: Chris Stephan , Alan Somers CC: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAApba+ACJ95gIAAfXJMgAG51XyABzQMEA== Date: Fri, 2 Oct 2020 15:47:37 +0000 Message-ID: References: , , , , , 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: 3c4a12f2-caf6-4995-bb49-08d866ea7c8e x-ms-traffictypediagnostic: YT1PR01MB2426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2958; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pIAajzTJsRuLSbE+5/0Ley6sPje6HdVaybGT3dTH1Xd7eeQBxJWNvca5JoJp+yg2KP4gmJrzrdaMPg/iQzDqeSZ6y5XD0BwPPSD9ap8BzYX9s0nAyrVKNZs7YT+rimexOvqgiSUHr8kEonFO2em64m2g9mMekjSvo9j7BCnESNAjeVW7Jk1M9ZeWyULink3UdSb+NyrOi1hWM34ZaaiJf97buE5n5V4X3PEoX5AL8WkAMlnnlsdSP3BeOwXf5U9lDlo2kN9XCtO4ANEiyzLTPSzk/6XgWz8TVmgDUlNHZwH6+1PewuW4spCytEOJBgsB9t71wyQv8vkyeEmJwswmObmpf415MclkjJTOoGGTvAc9laxVoY/M8XLcELlOLaHwdSLUjYImJyx6lZ+1vrVFwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39860400002)(376002)(366004)(136003)(346002)(91956017)(66556008)(83380400001)(7696005)(66446008)(76116006)(66946007)(5660300002)(52536014)(30864003)(53546011)(6506007)(83080400001)(966005)(110136005)(2906002)(55016002)(9686003)(66476007)(71200400001)(45080400002)(786003)(478600001)(8676002)(8936002)(64756008)(186003)(33656002)(4326008)(86362001)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: z6Vzo15TQEz16jwpIYCBKvsmyne/buLNKqWgTC2xZeBq4Cl3CYcjn8SNMf2+rITO0hw22vLYP3HSx7ROb3DrjKvM6gqHGkqwErOFyJKzOgwCLkFvfYNZWuHjiKDF6vY8lRT7bF3zXdq2v/cl4ze+4g01AzU5h1lZNrRRebHmsmuUGf8kB+xeGFBIZa/eLT/orSrzA+u3fX5ubqpQzZhreelD/zEX22YGgLQeIvVvh8FW4wXe3HamxsqSpalEZuuZ1GuLC7vxxiNFJnJWSbVBKfPVIjySsZKRwArorEncghSNuRDP7SVAQ/nFhW8BW9MYYdwwn9o/wb6ikZMmLDMafSAj30Y7dfPydIw8AwtFH0QKg1wjC7wHngSusNiiTfRHYrn82BdKNby1Th1XghYAU31begkFDADfWl2cXLiswgB8xgg1eSnGg+R/6N8PaELZKNl3Uj8t/MjdAJHI/VQ+txAel6o7zjQf2xgxEHXDeGAc+vE0+YXVpBxdITJCqS1wvc2d08q80HkxPVgi/4P/Co5OVEGq7FQIV+HtdYivVaN7/p6JsMY9deUlx4CGClOFk4RwkqUF9mdD5uwdwranOCo1esNabOaSq4z1NrK85XVuCKNbkM7PcvvL2XcstHLu1HlTP755DGki7PK+w1oaRw6leHRFmEqTYJ0ocDLQuNsEJC71ySYv7hM5lmGS007M/UlS9m+JWNPUW3i1I47B6Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3c4a12f2-caf6-4995-bb49-08d866ea7c8e X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 15:47:37.0494 (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: DsZZAXqb2pxT9b9Jqiq6roLD5djkgpyyCdS0qsTNa42/cSurwxSLkm7D6hdczRUFv4uuoz0bKlmb8jOp/X0Rnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2426 X-Rspamd-Queue-Id: 4C2vWt74lkz4Ljf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=mBc76zjR; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.63 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.02)[-1.018]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-0.98)[-0.982]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-0.87)[-0.870]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.63:from]; FREEMAIL_TO(0.00)[live.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.67.63:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 15:47:39 -0000 [stuff snipped]=0A= Rick Macklem wrote:=0A= >Chris Stephan wrote:=0A= >> New to the list and Late to the discussion. I am thinking increasing the= Len could=0A= >> cause possible degradation of performance when used on slower or legacy= =0A= >> systems. On the other hand just picking a len and cutting it off at a ha= rd max=0A= >> seems crude even with a tunable. Admittedly my naive opinion in this mat= ter=0A= >> ponders, could there be a sysctl tunable that just sets an estimate on t= imeframe=0A= >> instead of size. As you said 100M is roughly a sec on modem hardware. IO= PS are=0A= >> already tracked. The inverse of the avg IOPS for the filesystem in quest= ion could=0A= >> be used against this tunable to derive the estimated size limit of the n= ext=0A= >> read/write. This would allow the max len within the syscall to both hono= r a=0A= >> timeframe before a signal would be handled and maximize efficiency acros= s a=0A= >> large breadth of systems varying in performance. I=92m sure it is more c= omplicated=0A= >> than I suggest... just tossing my 2c in.=0A= >Yes. Using time will work for the generic copy case and I think that's a g= ood idea.=0A= >Then we can leave the file system specific cases up to the implementors.= =0A= >(For NFSv4.2, once you send the RPC to the server, the client has no contr= ol over=0A= > how long it takes to reply. The current sysctl that sets a size is still = about all the=0A= > NFSv4.2 code can do.)=0A= When I looked at a wireshark packet trace, it turned out that the Copy RPC= =0A= happened quickly and it was the subsequent Commit RPC that could take=0A= 1sec or more.=0A= As such, setting a time limit on Copy was not useful.=0A= Testing shows that 16Mbytes/Copy is small enough to keep the Commit RPC=0A= well below 1sec even on really slow server hardware (Pentium 4 with IDE dis= k).=0A= There was also no appreciable performance improvement for Copy sizes=0A= greater than 16Mbytes for the testing I did.=0A= As such, I think the vfs.nfs.maxcopyrange sysctl with a default of 16Mbytes= =0A= is all that can be done for NFSv4.2.=0A= =0A= For local file systems, a patch that detects pending signals is in progress= .=0A= =0A= rick=0A= =0A= Thanks for the suggestion, rick=0A= =0A= Chris=0A= =0A= Sent from FreeBSD=0A= ________________________________=0A= From: owner-freebsd-hackers@freebsd.org = on behalf of Rick Macklem =0A= Sent: Sunday, September 20, 2020 11:28:21 PM=0A= To: Alan Somers =0A= Cc: FreeBSD Hackers =0A= Subject: Re: RFC: copy_file_range(3)=0A= =0A= [I have only indented your most recent comments]=0A= Alan Somers wrote:=0A= On Sun, Sep 20, 2020 at 5:14 PM Rick Macklem > wrote:=0A= Alan Somers wrote:=0A= >On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem >> wrote:=0A= >>Alan Somers wrote:=0A= >>>copy_file_range(2) is nifty, but it has a few sharp edges:=0A= >>>1) Certain file systems don't support it, necessitating a write/read bas= ed=0A= >>>fallback=0A= >>>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA=0A= >>>3) It's slightly tricky to both efficiently deal with holes and also=0A= >>>promptly respond to signals=0A= >>>=0A= >>>These problems aren't terribly hard, but it seems to me like most=0A= >>>applications that use copy_file_range would share the exact same=0A= >>>solutions. In particular, I'm thinking about cp(1), dd(1), and=0A= >>>install(8). Those three could benefit from sharing a userland wrapper t= hat=0A= >>>handles the above problems.=0A= >>>=0A= >>>Should we add such a wrapper to libc? If so, what should it be called, = and=0A= >>>should it be public or just private to /usr/src ?=0A= >>There has been a discussion on src-committers which I suggested should=0A= >>be taken to a public mailing list.=0A= >>=0A= >>The basic question is...=0A= >>Whether or not the copy_file_range(2) syscall should be compatible with= =0A= >>the Linux one.=0A= >>When I did the syscall, I tried to make it Linux-compatible, arguing that= =0A= >>Linux is now a de-facto standard.=0A= >>The Linux syscall only works on regular files, which is why Alan's patch = for=0A= >>cp required a "fallback to the old way" for VCHR files like /dev/null.=0A= >>=0A= >>He is considering a wrapper in libc to provide FreeBSD specific semantics= ,=0A= >>which I have no problem with, so long as the naming and man page make=0A= >>it clear that it is not compatible with the Linux syscall.=0A= >>(Personally, I'd prefer a wrapper in libc to making the actual syscall no= n-Linux=0A= >> compatible, but that is just mho.)=0A= >>=0A= >>Hopefully this helps clarify what Alan is asking, rick=0A= >>=0A= >>I don't think the two questions are equivalent. I think that copy_file_r= ange(2) >>ought to work on character devices. Separately, even it does, I = think a userland >>wrapper would still be useful. It would still be able t= o handle sparse files more >>efficiently than the kernel-based vn_generic_c= opy_file_range.=0A= I saw this also stated in your #2 above, but wonder why you think a wrapper= =0A= would handle holes more efficiently.=0A= vn_generic_copy_file_range() does look for holes via SEEK_DATA/SEEK_HOLE=0A= just like a wrapper would and retains them as far as possible. It also look= s=0A= for blocks of all zero bytes for file systems that do not support SEEK_DATA= /=0A= SEEK_HOLE (like NFS versions prior to 4.2) and creates holes for these in= =0A= the output file.=0A= --> The only cases that I am aware of where the holes are not retained are:= =0A= - When the min holesize for the output file is larger than that of the= =0A= input file.=0A= - When the hole straddles the byte range specified for the syscall.=0A= (Or when the hole straddles two copy_file_range(2) syscalls, if you= =0A= prefer.)=0A= =0A= If you are copying the entire file and do not care how long the syscall=0A= takes (which also implies how long it will take for a termination signal=0A= like C to be handled), the most efficient usage is to specify=0A= a "len" argument equal to UINT64_MAX.=0A= --> This will usually copy the whole file in one gulp, although it is not= =0A= guaranteed to copy everything, given the Linux semantics definition= =0A= of it (an NFSv4.2 server can simply choose to copy less, for example= ).=0A= --> This allows the kernel to use whatever block size works efficien= tly=0A= and does not require an allocation of a large userspace buffer= for=0A= the date, nor that the data be copied to/from userspace.=0A= =0A= The problem with doing the whole file in one gulp are:=0A= - A large file can take quite a while and any signal won't be processed unt= il=0A= the gulp is done.=0A= --> If you wrote a program that allocated a 100Gbyte buffer and then=0A= copied a file using read(2)/write(2) with a size of 100Gbytes in a = loop,=0A= you'd end up with the same result.=0A= - As kib@ noted, if the input file never reports EOF (as /dev/zero does),= =0A= then the "one gulp" wouldn't end until storage is exhausted on the=0A= output file(s) device and C wouldn't stop it (since it is one b= ig=0A= syscall).=0A= --> As such, I suggested that, if the syscall is extended to allow VCH= R,=0A= that the "len" argument be clipped at "K Mbytes" for that case t= o=0A= avoid filling the storage device before being able to C ou= t=0A= of it, for this case.=0A= I suppose the answer for #3 is...=0A= - smaller "len" allows for quicker response to signals=0A= but=0A= - smaller "len" results in less efficient use of the syscall.=0A= =0A= Your patch for "cp" seemed fine, but used a small "len" and, as such,=0A= made the use of copy_file_range(2) less efficient.=0A= =0A= All I see the wrapper dong is handling the VCHR case (if the syscall remain= s=0A= as it is now and returns EINVAL to be compatible with Linux) and making=0A= some rather arbitrary choice w.r.t. how big "len" should be.=0A= --> Choosing an appropriate "len" might better be left to the specific use= =0A= case, I think?=0A= =0A= In summary, it's mostly whether VCHR gets handled by the syscall or a=0A= wrapper?=0A= =0A= > 1) In order to quickly respond to a signal, a program must use a modest l= en with > copy_file_range=0A= Does this matter? Or put another way, is a 1-2sec delay in response to C=0A= an issue for "cp".=0A= When kib@ reviewed the syscall, he did not see the delay in signal handling= =0A= a significant problem, noting that it is no different than a large process = core=0A= dumping.=0A= =0A= > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to=0A= > truncate the output file to the middle of the hole. Then, in the next in= vocation,=0A= > truncate it again to a larger size.=0A= > 3) The result is a file that is not as sparse as the original.=0A= >=0A= > For example, on UFS:=0A= > $ truncate -s 1g sparsefile=0A= > $ cp sparsefile sparsefile2=0A= > $ du -sh sparsefile*=0A= > 96K sparsefile=0A= > 32M sparsefile2=0A= If you care about maintaining sparseness, a "len" of 100Mbytes or more woul= d=0A= be a reasonable choice. Since "cp" has never maintained sparseness, I didn'= t=0A= suggest such a size when I reviewed your patch for "cp".=0A= --> I/O subsystem performance varies widely, but I think 100Mbytes will lim= it=0A= the delay in signal handling to about 1sec. Isn't that quick enough?= =0A= =0A= > My idea for a userland wrapper would solve this problem by using=0A= > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for=0A= > everything else with a modest len. Alternatively, we could eliminate the= need for=0A= > the wrapper by enabling copy_file_range for every file system, and making= =0A= > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with=0A= > large len without penalizing signal handling performance.=0A= The problem with doing this is it largely defeats the purpose of copy_file_= range().=0A= 1 - What about file systems that do not support SEEK_DATA/SEEK_HOLE.=0A= (All NFS mounts except NFSv4.2 ones against servers that support the= =0A= NFSv4.2 Seek operation are in this category.)=0A= 2 - For NFSv4.2 with servers that support Seek, the copy of an entire file= =0A= can be done via a few (or only one) RPC if you make "len" large and=0A= don't use Seek.=0A= If you combine using Seek with len =3D=3D2Mbytes, then you do a lot mo= re RPCs=0A= with associated overheads and RPC RTT delays. You still avoid moving a= ll=0A= the data across the wire, but you do lose a lot of the performance adv= antage.=0A= =0A= I could have made copy_file_range(2) a lot simpler if the generic code didn= 't=0A= try and maintain holes, but I wanted it to work well for file systems that = did=0A= not support SEEK_DATA/SEEK_HOLE.=0A= =0A= I'd suggest you try patching "cp" to use a 100Mbyte "len" for copy_file_ran= ge()=0A= and test that.=0A= You should fine the sparseness is mostly maintained and that you can = C=0A= out of a large file copy without undue delay.=0A= Then try it over NFS mounts (both v4.2 and v3) for the same large sparse fi= le.=0A= =0A= You can also code up a patched "cp" using SEEK_DATA/SEEK_HOLE and see=0A= how they compare.=0A= =0A= rick=0A= =0A= =0A= -Alan=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.f= reebsd.org%2Fmailman%2Flistinfo%2Ffreebsd-hackers&data=3D02%7C01%7C%7C2= 7ea5166cf99415d3bba08d85de6d259%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%= 7C637362593231297450&sdata=3DSfm9MxjQ6MVHgG%2Fw3sghn0hebSFjZo%2FSaUyZ9H= Pyws8%3D&reserved=3D0=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= From owner-freebsd-hackers@freebsd.org Sat Oct 3 22:19:31 2020 Return-Path: Delivered-To: freebsd-hackers@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 7CFDE3F18E0 for ; Sat, 3 Oct 2020 22:19:31 +0000 (UTC) (envelope-from jmaharaj2013@gmail.com) Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C3h9Z1rsqz3dFF for ; Sat, 3 Oct 2020 22:19:30 +0000 (UTC) (envelope-from jmaharaj2013@gmail.com) Received: by mail-oo1-xc29.google.com with SMTP id h8so1308903ooc.12 for ; Sat, 03 Oct 2020 15:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:mime-version; bh=NFvKQd8U4Bmqd+LzlDd4BlLADt5eHKVG7HObk9errAo=; b=nMBhWcApbUgjjWH+HqChyV8Vf58BSiDBH3HaGlClFPsX9lyttr7Wo/9hjNn47z4vkD OO/l9R6FCmvDE0vIlUf8mAEwX1TSiqsH94Dm0PA4xzNfvEqLIaYq/YWUdHJv+OMjx173 bb2MB3tQHcHmO1WsfXu+yqkyXeNyLqdEao1bSF/Z0jsKxzwXF12CcxHY7zo15WDThdxY LKAxr1362GZSyMMB+koprzDWgSN7pIvJaH3Jez7vCo7EnHPJuAbVl62xyVNEjbEZ8imo 3V2NSX7c6nbv5AOq8yFjC1rKhLlU0fOpDiHqpfG2E1KXgIQ9FZkKvU17NqOZFJw8b6gb sLUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:mime-version; bh=NFvKQd8U4Bmqd+LzlDd4BlLADt5eHKVG7HObk9errAo=; b=jfSXlNvY9qfOitOwjA8hXDPEk3bEkgBZxfPzwAmg9JtOKRBxOmJzXvYd9/CBz1aqAb IjAnwSHgv/+b4nrVK/2tAZaB1fgSoi3b9rExLWlUtfRNJWgRFMXaEnuxiQVVdkQhGRjt YnS43UlimxiXL1zSbiTOpnCktYEhxS8fgYGPQYwPvgbaW0dasE+8ii2MSt6Q4cp5xxpn bl3EWtZgOnHi7RbMYHw1/qoSzt1SEfKZ9hdpvkE7WVyOkbOZ1BFd56a5IYgMZjztLc3t DSTWKeq5IXsOyHTk4wUnY41cfIESkjXMPgpD95/IkQkAmIiFrfS3H2FJCFIQ1gBzY/hh fHgA== X-Gm-Message-State: AOAM531cmHVUN8nSgTzYHW9kBSt/P8Qy0FKTRZ6ztdRTF6C59brTdgSg 7ayahtu6PNAXH6SG+EECbuKJJ08ZfyU= X-Google-Smtp-Source: ABdhPJzEKnps0gPcIEo9xjdvF1PpyS0shyXs7AO9IqwMYR6LWg98sTrOyO9XC6VPpNA6wLvvIC522Q== X-Received: by 2002:a4a:751a:: with SMTP id j26mr6984860ooc.14.1601763567645; Sat, 03 Oct 2020 15:19:27 -0700 (PDT) Received: from SN6PR05MB6318.namprd05.prod.outlook.com ([2603:1036:805:f6::5]) by smtp.gmail.com with ESMTPSA id x189sm1218282oia.4.2020.10.03.15.19.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Oct 2020 15:19:26 -0700 (PDT) From: Raj J Putari To: "freebsd-hackers@freebsd.org" Subject: Hi, I wrote a FOSS D&D dice rolling program Thread-Topic: Hi, I wrote a FOSS D&D dice rolling program Thread-Index: AQHWmdNAFG4882kn3EGZSgGbKaaxmw== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sat, 3 Oct 2020 22:19:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/mixed; boundary="_004_SN6PR05MB6318AD237BF47BF8E2CB06DAFA0E0SN6PR05MB6318namp_" MIME-Version: 1.0 X-Rspamd-Queue-Id: 4C3h9Z1rsqz3dFF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=nMBhWcAp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jmaharaj2013@gmail.com designates 2607:f8b0:4864:20::c29 as permitted sender) smtp.mailfrom=jmaharaj2013@gmail.com X-Spamd-Result: default: False [-1.63 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.22)[-0.215]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.043]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; MIME_BAD_ATTACHMENT(1.60)[c]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c29:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 22:19:31 -0000 --_004_SN6PR05MB6318AD237BF47BF8E2CB06DAFA0E0SN6PR05MB6318namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hopefully I don=92t get flamed, I=92d post it to USENET but I don=92t have = EasyNews posting access You can do whatever you want with it, but I strongly suggest contacting you= r DM (Attached is the source, I=92ll paste it for the security conscience) // START // // main.c // DUNGEONS_AND_DRAGONS_DICE // // Created by unidef on 10/3/20. // #include #include #include #include #include #define NUMBER_OF_ROLLS 1 #define NUMBER_OF_SIDES 12; short PauseTime =3D 3; // seconds typedef double long int64; struct Dice { int Sides; char description[700]; short Dungeon_Code; /* dungeon code 0 for monster 1 for player 2 for dungeon master */ }; struct Dice Roll(int Dice_Sides){ struct Dice Roll; int rRandSeed; time_t CurrentTime; Roll.Sides =3D Dice_Sides; time(&CurrentTime); rRandSeed =3D (int)rand() % Roll.Sides; strcat(Roll.description, "Rolled at "); strcat(Roll.description, ctime(&CurrentTime)); printf("Rolled %d at %s", rRandSeed, ctime(&CurrentTime)); sleep(PauseTime); return(Roll); } void Mean_System(){ // Mean system denotes estimation based on Dungeon_Code // TODO }; int main(int argc, const char * argv[]) { struct Dice Holder; int Counter =3D 0; int NumberOfRolls =3D NUMBER_OF_ROLLS; int DiceSides =3D NUMBER_OF_SIDES; while (Counter < NumberOfRolls){ Holder =3D Roll(DiceSides); Counter++; } printf("Done! Please consult Dungeon Master\n"); return 0; } // END --_004_SN6PR05MB6318AD237BF47BF8E2CB06DAFA0E0SN6PR05MB6318namp_ Content-Type: application/octet-stream; name="main.c" Content-Description: main.c Content-Disposition: attachment; filename="main.c"; size=1546; creation-date="Sat, 03 Oct 2020 22:19:26 GMT"; modification-date="Sat, 03 Oct 2020 22:19:26 GMT" Content-Transfer-Encoding: base64 Ly8KLy8gIG1haW4uYwovLyAgRFVOR0VPTlNfQU5EX0RSQUdPTlNfRElDRQovLwovLyAgQ3JlYXRl ZCBieSB1bmlkZWYgb24gMTAvMy8yMC4KLy8KCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8 c3RkbGliLmg+CiNpbmNsdWRlIDx0aW1lLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUg PHVuaXN0ZC5oPgoKI2RlZmluZSBOVU1CRVJfT0ZfUk9MTFMgMQojZGVmaW5lIE5VTUJFUl9PRl9T SURFUyAxMjsKCnNob3J0IFBhdXNlVGltZSA9IDM7IC8vIHNlY29uZHMKdHlwZWRlZiBkb3VibGUg bG9uZyBpbnQ2NDsKCgpzdHJ1Y3QgRGljZSB7CiAgICBpbnQgU2lkZXM7CiAgICBjaGFyIGRlc2Ny aXB0aW9uWzcwMF07CiAgICBzaG9ydCBEdW5nZW9uX0NvZGU7CiAgICAKICAgIC8qIGR1bmdlb24g Y29kZQogICAgIDAgZm9yIG1vbnN0ZXIKICAgICAxIGZvciBwbGF5ZXIKICAgICAyIGZvciBkdW5n ZW9uIG1hc3RlcgogICAgICovCn07CgpzdHJ1Y3QgRGljZSBSb2xsKGludCBEaWNlX1NpZGVzKXsK CiAgICBzdHJ1Y3QgRGljZSBSb2xsOwogICAgaW50IHJSYW5kU2VlZDsKICAgIHRpbWVfdCBDdXJy ZW50VGltZTsKICAgIAogICAgUm9sbC5TaWRlcyA9IERpY2VfU2lkZXM7CiAgICB0aW1lKCZDdXJy ZW50VGltZSk7CiAgICByUmFuZFNlZWQgPSAoaW50KXJhbmQoKSAlIFJvbGwuU2lkZXM7CiAgICBz dHJjYXQoUm9sbC5kZXNjcmlwdGlvbiwgIlJvbGxlZCBhdCAiKTsKICAgIHN0cmNhdChSb2xsLmRl c2NyaXB0aW9uLCBjdGltZSgmQ3VycmVudFRpbWUpKTsKICAgIHByaW50ZigiUm9sbGVkICVkIGF0 ICVzIiwgclJhbmRTZWVkLCBjdGltZSgmQ3VycmVudFRpbWUpKTsKICAgIHNsZWVwKFBhdXNlVGlt ZSk7CiAgICByZXR1cm4oUm9sbCk7Cn0KCnZvaWQgTWVhbl9TeXN0ZW0oKXsKICAgIC8vIE1lYW4g c3lzdGVtIGRlbm90ZXMgZXN0aW1hdGlvbiBiYXNlZCBvbiBEdW5nZW9uX0NvZGUKICAgIC8vIFRP RE8KfTsKCgoKaW50IG1haW4oaW50IGFyZ2MsIGNvbnN0IGNoYXIgKiBhcmd2W10pIHsKICAgIHN0 cnVjdCBEaWNlIEhvbGRlcjsKICAgIAogICAgaW50IENvdW50ZXIgPSAwOwogICAgaW50IE51bWJl ck9mUm9sbHMgPSBOVU1CRVJfT0ZfUk9MTFM7CiAgICBpbnQgRGljZVNpZGVzID0gTlVNQkVSX09G X1NJREVTOwogICAgCiAgICB3aGlsZSAoQ291bnRlciA8IE51bWJlck9mUm9sbHMpewogICAgICAg IEhvbGRlciA9IFJvbGwoRGljZVNpZGVzKTsKICAgICAgICBDb3VudGVyKys7CiAgICB9CiAgICAK ICAgIHByaW50ZigiRG9uZSEgUGxlYXNlIGNvbnN1bHQgRHVuZ2VvbiBNYXN0ZXJcbiIpOwogICAg CiAgICByZXR1cm4gMDsKfQo= --_004_SN6PR05MB6318AD237BF47BF8E2CB06DAFA0E0SN6PR05MB6318namp_--