From owner-freebsd-drivers@freebsd.org Tue Aug 18 06:34:45 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFB389BCBD8 for ; Tue, 18 Aug 2015 06:34:45 +0000 (UTC) (envelope-from sales@eccosense.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7B11275 for ; Tue, 18 Aug 2015 06:34:45 +0000 (UTC) (envelope-from sales@eccosense.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7AFA69BCBD7; Tue, 18 Aug 2015 06:34:45 +0000 (UTC) Delivered-To: drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6099A9BCBD6 for ; Tue, 18 Aug 2015 06:34:45 +0000 (UTC) (envelope-from sales@eccosense.com) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0098.outbound.protection.outlook.com [104.47.126.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D36DA1272 for ; Tue, 18 Aug 2015 06:34:43 +0000 (UTC) (envelope-from sales@eccosense.com) Received: from PS1PR01MB0777.apcprd01.prod.exchangelabs.com (10.165.32.147) by PS1PR01MB0778.apcprd01.prod.exchangelabs.com (10.165.32.148) with Microsoft SMTP Server (TLS) id 15.1.231.21; Tue, 18 Aug 2015 06:00:36 +0000 Received: from PS1PR01MB0777.apcprd01.prod.exchangelabs.com ([10.165.32.147]) by PS1PR01MB0777.apcprd01.prod.exchangelabs.com ([10.165.32.147]) with mapi id 15.01.0231.024; Tue, 18 Aug 2015 06:00:36 +0000 From: sales 1 To: "drivers@freebsd.org" Subject: Does Your Site Grab Attention? Thread-Topic: Does Your Site Grab Attention? Thread-Index: AdDZem9x9gSYIYxSSD6poMCefM2knw== Date: Tue, 18 Aug 2015 06:00:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sales@eccosense.com; x-originating-ip: [122.177.93.45] x-microsoft-exchange-diagnostics: 1; PS1PR01MB0778; 5:BpDW2yHQjtLun4d+DoggpL9LBVeAOPhfa5Ij5bLXLMxGb8NrRXbm/hxrJgXXHRZ+fIfl1mRnawHvKYe1YBC2P/dOjfCIHgNAui3D3WhJDkrGSWKFzulh3OMlM9d8BpRtjlBIOOzPAQwZJZo6eXRysA==; 24:lH4R2gG1uED8XLDEKzHMLOpbag/xHocia4/Pz7LugNFOy05/X+jYoAxktkNW8nmgW9S1kszuoYLj9WBWaqrxb9M2CWBmqr0fx0G6lhXkFyg=; 20:xBjrMrnUzg4cCKt0W8XgbvwrghgUrmZLkUDC147/3SpsAzlcoLzu0jxrpz+4edSAP1kuubXgWZMQODb+x6MYkA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:PS1PR01MB0778; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(8121516046)(3002001); SRVR:PS1PR01MB0778; BCL:0; PCL:0; RULEID:; SRVR:PS1PR01MB0778; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(2656002)(19300405004)(40100003)(2900100001)(106356001)(5002640100001)(77096005)(19625215002)(102836002)(5003600100002)(19580395003)(50986999)(92566002)(15975445007)(33656002)(86362001)(68736005)(54356999)(2501003)(46102003)(5001920100001)(101416001)(87936001)(64706001)(110136002)(105586002)(189998001)(2351001)(16236675004)(122556002)(5001960100002)(450100001)(97736004)(62966003)(66066001)(229853001)(74316001)(77156002)(10400500002)(81156007)(4001540100001)(5001830100001)(107886002)(5001860100001); DIR:OUT; SFP:1102; SCL:1; SRVR:PS1PR01MB0778; H:PS1PR01MB0777.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: eccosense.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: eccosense.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2015 06:00:17.9371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0f71a25b-07b9-489d-bc1e-d461badc97df X-MS-Exchange-Transport-CrossTenantHeadersStamped: PS1PR01MB0778 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 06:34:45 -0000 Hi, I am Pankaj , a Web Development Consultant in New Delhi (India) and I work = with 200+experienced IT professionals who are into: A) Web Site Re-Designing and Development. B) E-Commerce Solutions. C) Flash Design, Logo Design. D) Mobile iPhone, Android Apps Development. Experience and a Quick Turn! We are Professional, Trust worthy, and Reliabl= e and offer Quality Service Let me know if you're interested & looking forward to any of these above se= rvices. Share your requirements with us, I'll be happy to share the further= details with you. Your prompt response will be highly appreciated!! Thanks & Regards, Pankaj Upadhyay Web Development Consultant From owner-freebsd-drivers@freebsd.org Tue Aug 18 18:41:41 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51A939BDC9A for ; Tue, 18 Aug 2015 18:41:41 +0000 (UTC) (envelope-from leonardofogel@yahoo.com.br) Received: from nm6-vm4.bullet.mail.ne1.yahoo.com (nm6-vm4.bullet.mail.ne1.yahoo.com [98.138.91.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15F731697 for ; Tue, 18 Aug 2015 18:41:40 +0000 (UTC) (envelope-from leonardofogel@yahoo.com.br) Received: from [98.138.226.176] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2015 18:41:34 -0000 Received: from [98.138.226.162] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2015 18:41:34 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 18 Aug 2015 18:41:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 161212.80223.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 16368 invoked by uid 60001); 18 Aug 2015 18:41:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1439923294; bh=HhmMvwaWKOPF5gWlKe9pxRoEMCX7diLeEmynHmhqTiA=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yJg83U+soIhc2PbeTq4bkROFpm9jg3xYGBPjYEgo8xh/ZoXDiDGGX4++XIwLKa0D6DA7NlCx9vC9FMKYlK+8slbCcEfjAqNFMDgC9r11xL8TUb6W5PqXvgaZ3FcwfobepZG0Ff+S7/rSdaiSZ7YejteFfSZlqei7wl/I31OfQ6E= X-YMail-OSG: p5JB_VwVM1mSADIEO01NcHADnhfBE5z7mJG0N1ZSPuN7kET ESRO2txi6.2Swb_jdXTiUZFk1ceeioWxOLl.kICJQj7y4l.MB..GjS.SlgnQ eoTLIE5q3SVvbrjk_TT0c9ZgvxiQb3dOsI98wggRQGj6Sx_a0tvAr_oVHEEb 5Gz1r2nzNm9MQ6R_zouUZfUpW6hsH7Yq1kolm3J_O8zI6YXfiCPM5ODuNMT_ LeCYJ3DA8lP3p8bzTyQ7pVn5Dq7T1FCu2k1jt8bxaV8rYHNou5rtnA03wxjf c6PPcIiphlgOJLIyeIfrd5iCY6UYM6cZBy63UdD3JVXijvnmtMGLFwhrFw6C lXV8pirFfrM2JKC0ZhYCfW64KfqBjnXCWEzYozvX0CxjMO8vw_6CZziBlTKn .RBqZk9jRdvv1mSBot6sW1C_0lnJxmRtkVfjpckXpBGjVpue_ysJk4iJu5i1 IcUrwTJVH97Jiv09wG_2Kd58HKRy8Z79NiXDp8_xLTxlOO4IbFsf3HwSKWd_ Q8e2zQUSY1QzR1rGycvWnclgsMI1GcrcdKyLM3yxAYYZtryviZzizDPzFuXq TX2a6OvMxhQINXzBpohlFb9te5dc1 Received: from [186.228.53.250] by web120801.mail.ne1.yahoo.com via HTTP; Tue, 18 Aug 2015 11:41:34 PDT X-Rocket-MIMEInfo: 002.001, SGkuDQpUaGUgZm9sbG93aW5nIGNvZGUgaXMgYW4gZXhlcnB0IGZyb20gdGhlIEZyZWVCU0QgQXJjaGl0ZWN0dXJlIEhhbmRib29rLCBjaGFwdGVyIDExLjEuMS4gU2FtcGxlIERyaXZlciBTb3VyY2UuIEkndmUgaW5jbHVkZWQgbGFiZWxzIGkxLCBpMiwgaTMuDQoNCiAgIGludA0KICAgbXlwY2lfb3BlbihzdHJ1Y3QgY2RldiAqZGV2LCBpbnQgb2ZsYWdzLCBpbnQgZGV2dHlwZSwgc3RydWN0IHRocmVhZCAqdGQpDQogICB7DQogICAgICAgICAgIHN0cnVjdCBteXBjaV9zb2Z0YyAqc2M7DQoNCiAgICAgICAgICABMAEBAQE- X-Mailer: YahooMailBasic/610 YahooMailWebService/0.8.203.812 Message-ID: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> Date: Tue, 18 Aug 2015 11:41:34 -0700 From: Leonardo Fogel Subject: Race conditions To: freebsd-drivers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 18:41:41 -0000 Hi. The following code is an exerpt from the FreeBSD Architecture Handbook, cha= pter 11.1.1. Sample Driver Source. I've included labels i1, i2, i3. int mypci_open(struct cdev *dev, int oflags, int devtype, struct thread *td) { struct mypci_softc *sc; /* Look up our softc. */ i1: sc =3D dev->si_drv1; device_printf(sc->my_dev, "Opened successfully.\n"); return (0); } static int mypci_attach(device_t dev) { struct mypci_softc *sc; ... i2: sc->my_cdev =3D make_dev(&mypci_cdevsw, device_get_unit(dev), UID_ROOT, GID_WHEEL, 0600, "mypci%u", device_get_unit(dev)); i3: sc->my_cdev->si_drv1 =3D sc; printf("Mypci device loaded.\n"); return (0); } As I understand it, as soon as instruction at label i2 completes, there is = a rare possibility that another thread opens the device file and executes t= he instruction at i1, before the instruction at i3 is executed. Is it corre= ct? How could one fix it? Thank you for your time. Leonardo From owner-freebsd-drivers@freebsd.org Wed Aug 19 02:31:25 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C83BF9BD5CC for ; Wed, 19 Aug 2015 02:31:25 +0000 (UTC) (envelope-from john@araratriver.co) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4B4B123B; Wed, 19 Aug 2015 02:31:25 +0000 (UTC) (envelope-from john@araratriver.co) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E8474B91E; Tue, 18 Aug 2015 22:31:23 -0400 (EDT) From: John Baldwin To: freebsd-drivers@freebsd.org Cc: Leonardo Fogel , 'Konstantin Belousov' Subject: Re: Race conditions Date: Tue, 18 Aug 2015 19:30:48 -0700 Message-ID: <10064388.a9lbzVPoX7@ralph.baldwin.cx> Organization: Ararat River Consulting, LLC User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Aug 2015 22:31:24 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 02:31:25 -0000 On Tuesday, August 18, 2015 11:41:34 AM Leonardo Fogel wrote: > Hi. > The following code is an exerpt from the FreeBSD Architecture Handbook, chapter 11.1.1. Sample Driver Source. I've included labels i1, i2, i3. > > int > mypci_open(struct cdev *dev, int oflags, int devtype, struct thread *td) > { > struct mypci_softc *sc; > > /* Look up our softc. */ > i1: sc = dev->si_drv1; > device_printf(sc->my_dev, "Opened successfully.\n"); > return (0); > } > > static int > mypci_attach(device_t dev) > { > struct mypci_softc *sc; > ... > i2: sc->my_cdev = make_dev(&mypci_cdevsw, device_get_unit(dev), > UID_ROOT, GID_WHEEL, 0600, "mypci%u", device_get_unit(dev)); > i3: sc->my_cdev->si_drv1 = sc; > printf("Mypci device loaded.\n"); > return (0); > } > > > As I understand it, as soon as instruction at label i2 completes, there is a rare possibility that another thread opens the device file and executes the instruction at i1, before the instruction at i3 is executed. Is it correct? How could one fix it? It is a race, yes. I know there is a MAKEDEV_REF flag that can be passed to make_dev_p() and make_dev_credf() that can hold a reference on the returned cdev (so it can't be immediately deleted), but I don't know that that helps close the race you reference. I think I would probably prefer we add some sort of wrapper for make_dev that accepts the si_drv1 value (and possibly other values) as an argument to close this. I'm cc'ing kib@ to see if he has any suggestions or better ideas. -- John Baldwin From owner-freebsd-drivers@freebsd.org Wed Aug 19 08:48:43 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 945F39BD6B9 for ; Wed, 19 Aug 2015 08:48:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39226208; Wed, 19 Aug 2015 08:48:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t7J8mZXV060926 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Aug 2015 11:48:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t7J8mZXV060926 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t7J8mYrw060924; Wed, 19 Aug 2015 11:48:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Aug 2015 11:48:34 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-drivers@freebsd.org, Leonardo Fogel , "'Konstantin Belousov'" Subject: Re: Race conditions Message-ID: <20150819084834.GM2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <10064388.a9lbzVPoX7@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10064388.a9lbzVPoX7@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 08:48:43 -0000 On Tue, Aug 18, 2015 at 07:30:48PM -0700, John Baldwin wrote: > On Tuesday, August 18, 2015 11:41:34 AM Leonardo Fogel wrote: > > Hi. > > The following code is an exerpt from the FreeBSD Architecture Handbook, chapter 11.1.1. Sample Driver Source. I've included labels i1, i2, i3. > > > > int > > mypci_open(struct cdev *dev, int oflags, int devtype, struct thread *td) > > { > > struct mypci_softc *sc; > > > > /* Look up our softc. */ > > i1: sc = dev->si_drv1; if (sc == NULL) return (ENXIO); The new cdev was allocated with M_ZERO flag, so you can rely on the fact that uninitalized fields are zeroed. > > device_printf(sc->my_dev, "Opened successfully.\n"); > > return (0); > > } > > > > static int > > mypci_attach(device_t dev) > > { > > struct mypci_softc *sc; > > ... > > i2: sc->my_cdev = make_dev(&mypci_cdevsw, device_get_unit(dev), > > UID_ROOT, GID_WHEEL, 0600, "mypci%u", device_get_unit(dev)); > > i3: sc->my_cdev->si_drv1 = sc; > > printf("Mypci device loaded.\n"); > > return (0); > > } > > > > > > As I understand it, as soon as instruction at label i2 completes, there is a rare possibility that another thread opens the device file and executes the instruction at i1, before the instruction at i3 is executed. Is it correct? How could one fix it? > > It is a race, yes. I know there is a MAKEDEV_REF flag that can be passed to > make_dev_p() and make_dev_credf() that can hold a reference on the returned > cdev (so it can't be immediately deleted), but I don't know that that helps > close the race you reference. No, MAKEDEV_REF is about calling dev_ref() early enough so that the dev_clone handlers could safely access cdev that was just created (otherwise other thread might enter devfs_populate_loop() in parallel and unref :( ). MAKEDEV_REF has nothing to do with driver-managed fields initialization. > > I think I would probably prefer we add some sort of wrapper for make_dev > that accepts the si_drv1 value (and possibly other values) as an argument to > close this. I'm cc'ing kib@ to see if he has any suggestions or better ideas. Yes, this is a known issue in the cdev KPI, but of very low importance. I agree that a change to cdev KPI is due. One of the existing issues is that it is already bloated with make_dev_credf make_dev_cred make_dev_p make_dev all grown organically to plug this and that uglyness in the KPI. I wanted to combine all non-naming parameters to make_dev* into some structure, so that the final function to create cdev is like int make_dev_uber(struct cdev **res, struct make_dev_args *args, const char *fmt, ...); struct make_dev_args { struct cdevsw *csw; int flags; struct ucred *cred; ... int si_drv0; void *si_drv1, *si_drv2; <- eventually }; and a helper to do initialization of the structure. But as I said above, it is very low priority and I want to gather more outstanding issues with the KPI before making any decisions there. From owner-freebsd-drivers@freebsd.org Wed Aug 19 12:04:07 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1346A9BDD69 for ; Wed, 19 Aug 2015 12:04:07 +0000 (UTC) (envelope-from leonardofogel@yahoo.com.br) Received: from nm15-vm6.bullet.mail.ne1.yahoo.com (nm15-vm6.bullet.mail.ne1.yahoo.com [98.138.91.108]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8122210 for ; Wed, 19 Aug 2015 12:04:06 +0000 (UTC) (envelope-from leonardofogel@yahoo.com.br) Received: from [98.138.100.111] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2015 12:34:48 -0000 Received: from [98.138.87.11] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2015 12:02:21 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 19 Aug 2015 12:02:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 171594.50801.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 24912 invoked by uid 60001); 19 Aug 2015 12:02:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1439985741; bh=mEcmfTQ2IJpPnx3JBtY3Urg/3zWkVyk1siBuVUr4iLo=; h=Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qVrWaDjRKS6UDVH6Kd1/TPwjGyXX3HnPKillf4GXE6zAaxR60AFW4XR5oU8TNK4zCA0ofiZPBUflYEqhcfPUyMEyVJ4o8PJ8n+IkpX+Xj1ZrSMRzBLl96FIV2CZROWCvpHcKluCgxlf9Fu3tAj+YO1ZczQb5W3nNx73n8yjf3Ik= X-YMail-OSG: U5xDJyUVM1nfd3Z4C_wZHvJufhfWsGJPAmxM3M.E248a5y6 NXjNLIYZmQdocvxnIjVa5C.Os5WgqZiuo6WjGBqaEw0Alr95KuzdOFUOEGIO h6.dAYWrWiXSy5Y8FUWgrU2pOpuxu2tH7EnYKwo.bN0Jkunl.d5BOuQpVxde OH9Do5Ec9fO.UAbdTfSIq0LM7o3AIQIuFdWGdoN0tiCU7kSG68fOml08WsM_ LYVdsduB1gAkrrBhGf_QH72vY8hEoedyZ_AjvIe4l_zVmAJyNkFbk4eFwrKV GdGLuiEW_4xEHxTzS2ikcPa0qVhAIDf.1ObtY.MDL15Nyqfhvkg_SpLzxSVg SXUrDpjOBwjUwV0qNNh3bxsl45MxcsRLvzB7tz3TWLFwqHYRwAGoChatzRvX VfcEH5EIWgoPXvavTjhLxvX5CwP68NuY6EzRAGkRsn2bZctzAHKV3nPIhSnH 6NDnnG9vofezFie_qzcWigbGvEd5m63THsKURy6PEKKeMGV68IS4cxUIdSfl _1RySr1jSxYFUECqobfxROQOVA400RlmEglvHV5rwBl_DGlOLEfBRx3H82MM WjD1.0xxyynRnoLKikHVpf_UDFec- Received: from [186.228.53.250] by web120802.mail.ne1.yahoo.com via HTTP; Wed, 19 Aug 2015 05:02:21 PDT X-Rocket-MIMEInfo: 002.001, DQpPbiBXZWQsIDgvMTkvMTUsIEtvbnN0YW50aW4gQmVsb3Vzb3Ygd3JvdGU6DQoNCj4gICAgICBpZiAoc2MgPT0gTlVMTCkNCj4gICAgICAgICAgICAgcmV0dXJuIChFTlhJTyk7DQo.IFRoZSBuZXcgY2RldiB3YXMgYWxsb2NhdGVkDQo.IHdpdGggTV9aRVJPIGZsYWcsIHNvIHlvdSBjYW4gcmVseSBvbiB0aGUgZmFjdA0KPiB0aGF0IHVuaW5pdGFsaXplZCBmaWVsZHMgYXJlIHplcm9lZC4NCiANCkkgd2FzIG5vdCBhd2FyZSBvZiB0aGlzLiBJdCBsb29rcyBwcmV0dHkgZ29vZCB0byBtZS4NCg0KVGhhbmsgeW8BMAEBAQE- X-Mailer: YahooMailBasic/612 YahooMailWebService/0.8.203.812 Message-ID: <1439985741.59947.YahooMailBasic@web120802.mail.ne1.yahoo.com> Date: Wed, 19 Aug 2015 05:02:21 -0700 From: Leonardo Fogel Subject: Re: Race conditions To: John Baldwin , Konstantin Belousov Cc: freebsd-drivers@freebsd.org, 'Konstantin Belousov' In-Reply-To: <20150819084834.GM2072@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 12:04:07 -0000 On Wed, 8/19/15, Konstantin Belousov wrote: > if (sc =3D=3D NULL) > return (ENXIO); > The new cdev was allocated > with M_ZERO flag, so you can rely on the fact > that uninitalized fields are zeroed. =20 I was not aware of this. It looks pretty good to me. Thank you all for your attention. Leonardo From owner-freebsd-drivers@freebsd.org Wed Aug 19 14:30:25 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B79C09BEF3F for ; Wed, 19 Aug 2015 14:30:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 925791E58; Wed, 19 Aug 2015 14:30:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7AB69B98F; Wed, 19 Aug 2015 10:30:24 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-drivers@freebsd.org, Leonardo Fogel , 'Konstantin Belousov' Subject: Re: Race conditions Date: Wed, 19 Aug 2015 07:29:56 -0700 Message-ID: <6889344.0OebVsM7Q3@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150819084834.GM2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <10064388.a9lbzVPoX7@ralph.baldwin.cx> <20150819084834.GM2072@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Aug 2015 10:30:24 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 14:30:25 -0000 On Wednesday, August 19, 2015 11:48:34 AM Konstantin Belousov wrote: > On Tue, Aug 18, 2015 at 07:30:48PM -0700, John Baldwin wrote: > > On Tuesday, August 18, 2015 11:41:34 AM Leonardo Fogel wrote: > > > Hi. > > > The following code is an exerpt from the FreeBSD Architecture Handbook, chapter 11.1.1. Sample Driver Source. I've included labels i1, i2, i3. > > > > > > int > > > mypci_open(struct cdev *dev, int oflags, int devtype, struct thread *td) > > > { > > > struct mypci_softc *sc; > > > > > > /* Look up our softc. */ > > > i1: sc = dev->si_drv1; > if (sc == NULL) > return (ENXIO); > The new cdev was allocated with M_ZERO flag, so you can rely on the fact > that uninitalized fields are zeroed. > > > > device_printf(sc->my_dev, "Opened successfully.\n"); > > > return (0); > > > } > > > > > > static int > > > mypci_attach(device_t dev) > > > { > > > struct mypci_softc *sc; > > > ... > > > i2: sc->my_cdev = make_dev(&mypci_cdevsw, device_get_unit(dev), > > > UID_ROOT, GID_WHEEL, 0600, "mypci%u", device_get_unit(dev)); > > > i3: sc->my_cdev->si_drv1 = sc; > > > printf("Mypci device loaded.\n"); > > > return (0); > > > } > > > > > > > > > As I understand it, as soon as instruction at label i2 completes, there is a rare possibility that another thread opens the device file and executes the instruction at i1, before the instruction at i3 is executed. Is it correct? How could one fix it? > > > > > It is a race, yes. I know there is a MAKEDEV_REF flag that can be passed to > > make_dev_p() and make_dev_credf() that can hold a reference on the returned > > cdev (so it can't be immediately deleted), but I don't know that that helps > > close the race you reference. > No, MAKEDEV_REF is about calling dev_ref() early enough so that the > dev_clone handlers could safely access cdev that was just created > (otherwise other thread might enter devfs_populate_loop() in parallel > and unref :( ). MAKEDEV_REF has nothing to do with driver-managed > fields initialization. Well, it does allow a clone handler to safely set si_drv1 (which is typically what they do)? However, I didn't think it would help with Leonardo's question. A somewhat related race I ran into while trying to make cloning on /dev/tap more useful is that there isn't any way to "reserve" a cdev during clone such that only the current thread can try to open it (at least as far as I can tell), unless it is true that the cdev's d_open() method is guaranteed to be called once a cdev is returned from the clone handler (which it is not for the stat() case). It's a shame we can't pass down an 'ISOPEN' flag similar to that in namei to the clone handlers. (See https://reviews.freebsd.org/D2797 and related comments) > > I think I would probably prefer we add some sort of wrapper for make_dev > > that accepts the si_drv1 value (and possibly other values) as an argument to > > close this. I'm cc'ing kib@ to see if he has any suggestions or better ideas. > > Yes, this is a known issue in the cdev KPI, but of very low importance. > I agree that a change to cdev KPI is due. One of the existing issues is > that it is already bloated with > make_dev_credf > make_dev_cred > make_dev_p > make_dev > all grown organically to plug this and that uglyness in the KPI. I wanted > to combine all non-naming parameters to make_dev* into some structure, > so that the final function to create cdev is like > int make_dev_uber(struct cdev **res, struct make_dev_args *args, > const char *fmt, ...); > struct make_dev_args { > struct cdevsw *csw; > int flags; > struct ucred *cred; > ... > int si_drv0; > void *si_drv1, *si_drv2; <- eventually > }; > and a helper to do initialization of the structure. > > But as I said above, it is very low priority and I want to gather more > outstanding issues with the KPI before making any decisions there. This sounds like a good approach to me. You could version the args structure if you wanted (I think Glebius has done this for his ifnet work which uses a similar pattern) so you can extend it in the future. -- John Baldwin From owner-freebsd-drivers@freebsd.org Wed Aug 19 14:52:50 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0C179BC3C2 for ; Wed, 19 Aug 2015 14:52:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66CFAD66; Wed, 19 Aug 2015 14:52:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t7JEqdU6056200 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Aug 2015 17:52:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t7JEqdU6056200 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t7JEqdwq056094; Wed, 19 Aug 2015 17:52:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Aug 2015 17:52:39 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-drivers@freebsd.org, Leonardo Fogel , "'Konstantin Belousov'" Subject: Re: Race conditions Message-ID: <20150819145239.GS2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <10064388.a9lbzVPoX7@ralph.baldwin.cx> <20150819084834.GM2072@kib.kiev.ua> <6889344.0OebVsM7Q3@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6889344.0OebVsM7Q3@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 14:52:50 -0000 On Wed, Aug 19, 2015 at 07:29:56AM -0700, John Baldwin wrote: > On Wednesday, August 19, 2015 11:48:34 AM Konstantin Belousov wrote: > > On Tue, Aug 18, 2015 at 07:30:48PM -0700, John Baldwin wrote: > > > On Tuesday, August 18, 2015 11:41:34 AM Leonardo Fogel wrote: > > > > Hi. > > > > The following code is an exerpt from the FreeBSD Architecture Handbook, chapter 11.1.1. Sample Driver Source. I've included labels i1, i2, i3. > > > > > > > > int > > > > mypci_open(struct cdev *dev, int oflags, int devtype, struct thread *td) > > > > { > > > > struct mypci_softc *sc; > > > > > > > > /* Look up our softc. */ > > > > i1: sc = dev->si_drv1; > > if (sc == NULL) > > return (ENXIO); > > The new cdev was allocated with M_ZERO flag, so you can rely on the fact > > that uninitalized fields are zeroed. > > > > > > device_printf(sc->my_dev, "Opened successfully.\n"); > > > > return (0); > > > > } > > > > > > > > static int > > > > mypci_attach(device_t dev) > > > > { > > > > struct mypci_softc *sc; > > > > ... > > > > i2: sc->my_cdev = make_dev(&mypci_cdevsw, device_get_unit(dev), > > > > UID_ROOT, GID_WHEEL, 0600, "mypci%u", device_get_unit(dev)); > > > > i3: sc->my_cdev->si_drv1 = sc; > > > > printf("Mypci device loaded.\n"); > > > > return (0); > > > > } > > > > > > > > > > > > As I understand it, as soon as instruction at label i2 completes, there is a rare possibility that another thread opens the device file and executes the instruction at i1, before the instruction at i3 is executed. Is it correct? How could one fix it? > > > > > > > > It is a race, yes. I know there is a MAKEDEV_REF flag that can be passed to > > > make_dev_p() and make_dev_credf() that can hold a reference on the returned > > > cdev (so it can't be immediately deleted), but I don't know that that helps > > > close the race you reference. > > No, MAKEDEV_REF is about calling dev_ref() early enough so that the > > dev_clone handlers could safely access cdev that was just created > > (otherwise other thread might enter devfs_populate_loop() in parallel > > and unref :( ). MAKEDEV_REF has nothing to do with driver-managed > > fields initialization. > > Well, it does allow a clone handler to safely set si_drv1 (which is typically > what they do)? However, I didn't think it would help with Leonardo's > question. > > A somewhat related race I ran into while trying to make cloning on /dev/tap > more useful is that there isn't any way to "reserve" a cdev during clone such > that only the current thread can try to open it (at least as far as I can > tell), unless it is true that the cdev's d_open() method is guaranteed to be > called once a cdev is returned from the clone handler (which it is not for > the stat() case). It's a shame we can't pass down an 'ISOPEN' flag similar > to that in namei to the clone handlers. > > (See https://reviews.freebsd.org/D2797 and related comments) When the clone handler run, there is no even the cdev' associated vnode known in the thread called the dev_clone event handler. So regardless of whether you pass ISOPEN to the dev_clone, there is a possibility that a parallel open would happens before the current lookup consumer has a chance to proceed. > > > > I think I would probably prefer we add some sort of wrapper for make_dev > > > that accepts the si_drv1 value (and possibly other values) as an argument to > > > close this. I'm cc'ing kib@ to see if he has any suggestions or better ideas. > > > > Yes, this is a known issue in the cdev KPI, but of very low importance. > > I agree that a change to cdev KPI is due. One of the existing issues is > > that it is already bloated with > > make_dev_credf > > make_dev_cred > > make_dev_p > > make_dev > > all grown organically to plug this and that uglyness in the KPI. I wanted > > to combine all non-naming parameters to make_dev* into some structure, > > so that the final function to create cdev is like > > int make_dev_uber(struct cdev **res, struct make_dev_args *args, > > const char *fmt, ...); > > struct make_dev_args { > > struct cdevsw *csw; > > int flags; > > struct ucred *cred; > > ... > > int si_drv0; > > void *si_drv1, *si_drv2; <- eventually > > }; > > and a helper to do initialization of the structure. > > > > But as I said above, it is very low priority and I want to gather more > > outstanding issues with the KPI before making any decisions there. > > This sounds like a good approach to me. You could version the args structure > if you wanted (I think Glebius has done this for his ifnet work which uses a > similar pattern) so you can extend it in the future. I thought about the following use: struct make_dev_args args; struct cdev *cdev; make_dev_args_prep(&args); args.si_drv1 = softc; error = make_dev_uber(&cdev, &args, "exhauster"); So that the _prep() ensures that the _args structure extension is invisible to the KPI consumers. I have no intent of keeping KBI stable. Question is, do we need this now ? It is yet another churn in the make_dev(9) area, where we already have four interfaces, and we must keep them around for source compatibility. IMO si_drv1 issue does not justify yet another bloat. If there is any other reason to modify make_dev(9) group of functions, then I would agree with taking the _args step.