From owner-freebsd-net@FreeBSD.ORG Fri Feb 13 02:11:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6804B2C5; Fri, 13 Feb 2015 02:11:51 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (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 817E089; Fri, 13 Feb 2015 02:11:49 +0000 (UTC) Received: from CO2PR05MB761.namprd05.prod.outlook.com (10.141.227.13) by CO2PR05MB764.namprd05.prod.outlook.com (10.141.227.19) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 12 Feb 2015 21:36:40 +0000 Received: from CO2PR05MB761.namprd05.prod.outlook.com ([10.141.227.13]) by CO2PR05MB761.namprd05.prod.outlook.com ([10.141.227.13]) with mapi id 15.01.0081.018; Thu, 12 Feb 2015 21:36:40 +0000 From: Sreekanth Rupavatharam To: Jack Vogel Subject: Re: Double cleanup in igb_attach Thread-Topic: Double cleanup in igb_attach Thread-Index: AQHQOcQ8M6DG1/D37kKlfeofCj44QJzUW0EA//+AdgCAAIzTgIAAAX8YgAAA4YCAAAQUE4AAAPkAgBiB44CAAJeiAP//lQSA Date: Thu, 12 Feb 2015 21:36:39 +0000 Message-ID: References: <20150127192814.GA63990@strugglingcoder.info> <26266AD2-4743-4A7B-A87D-F68E2E2425A0@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [66.129.239.14] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB764; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB764; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(279900001)(377454003)(479174004)(164054003)(35774003)(24454002)(1411001)(92566002)(66066001)(40100003)(122556002)(102836002)(16236675004)(77096005)(86362001)(19625305001)(54356999)(46102003)(50986999)(19580395003)(87936001)(2656002)(62966003)(106116001)(77156002)(2950100001)(83506001)(15975445007)(19617315012)(76176999)(110136001)(93886004)(19580405001)(2900100001)(36756003)(99286002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB764; H:CO2PR05MB761.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2015 21:36:39.6138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB764 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "jfv@freebsd.org" , "freebsd-net@freebsd.org" , hiren panchasara X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 02:11:51 -0000 Looking at the em driver, the em_detach is missing from the same place. return (0); 759 760err_late: 761 em_free_transmit_structures(adapter); 762 em_free_receive_structures(adapter); 763 em_release_hw_control(adapter); 764 if (adapter->ifp !=3D NULL) 765 if_free(adapter-= >ifp); 766err_pci: -- Thanks, Sreekanth From: Jack Vogel > Date: Thursday, February 12, 2015 at 12:00 PM To: Sreekanth Rupavatharam > Cc: hiren panchasara >, "freebsd-net@freebsd.org" >, "jfv@freebsd.org" > Subject: Re: Double cleanup in igb_attach I do not recall if I put that call in myself and, yes, it seems odd. It was= probably trying to clean up some bad state a failed attach left things in. If it is removed it should be thoroughly regression tested. Jack On Thu, Feb 12, 2015 at 10:56 AM, Sreekanth Rupavatharam > wrote: Hi Jack, Actually, looking at the code again, it seems to me that igb_detach is not = supposed to be called from igb_attach at all. It causes more problems than = previously mentioned. E.g., in case of branching to err_late *before* igb_= setup_interface(where the ifp is initialized), calling igb_detach there cau= ses a NULL pointer access. The best way to deal with it is to take out the = igb_detach call from the err_late: label. Thoughts? Comments? -- Thanks, Sreekanth From: Jack Vogel > Date: Tuesday, January 27, 2015 at 12:42 PM To: Sreekanth Rupavatharam > Cc: hiren panchasara >, "freebsd-net@freebsd.org" >, "jfv@freebsd.org" > Subject: Re: Double cleanup in igb_attach Yes, I will look them over. Jack On Tue, Jan 27, 2015 at 12:38 PM, Sreekanth Rupavatharam > wrote: Thanks jack, Now, can you please review these changes? And commit if you deem it fi= t? Thanks, -Sreekanth On Jan 27, 2015, at 12:24 PM, "Jack Vogel" > wrote: Errrr, I am one of those people :) (jack.vogel@intel.com) Jack On Tue, Jan 27, 2015 at 12:21 PM, Sreekanth Rupavatharam > wrote: Definitely, but I didn't have the contact info of those people. Thanks, -Sreekanth On Jan 27, 2015, at 12:15 PM, "Jack Vogel" > wrote: If you want something committed to an Intel driver, asking Intel might be t= he courteous thing to do, don't you think? Jack On Tue, Jan 27, 2015 at 11:51 AM, Sreekanth Rupavatharam > wrote: Hiren, Can you help commit this? Index: if_igb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_igb.c(revision 298053) +++ if_igb.c(working copy) @@ -723,7 +723,8 @@ igb_attach(device_t dev) return (0); err_late: -igb_detach(dev); +if(igb_detach(dev) =3D=3D 0) /* igb_detach did the cleanup */ +return(error); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); igb_release_hw_control(adapter); -- Thanks, Sreekanth On 1/27/15, 11:28 AM, "hiren panchasara" > wrote: + Jack On Tue, Jan 27, 2015 at 12:00:19AM +0000, Sreekanth Rupavatharam wrote: Apologies if this is not the right forum. In igb_attach function, we have t= his code. err_late: igb_detach(dev); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); igb_release_hw_control(adapter); err_pci: igb_free_pci_resources(adapter); if (adapter->ifp !=3D NULL) if_free(adapter->ifp); free(adapter->mta, M_DEVBUF); IGB_CORE_LOCK_DESTROY(adapter); The problem is that igb_detach also does the same cleanup in it?s body. Onl= y exception is this case where it just returns EBUSY /* Make sure VLANS are not using driver */ if (if_vlantrunkinuse(ifp)) { device_printf(dev,"Vlan in use, detach first\n"); return (EBUSY); } I think the code in igb_attach should be changed to free up resources only = if the igb_detach returns an error. Here?s the patch for it. Index: if_igb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_igb.c (revision 298025) +++ if_igb.c (working copy) @@ -723,7 +723,8 @@ igb_attach(device_t dev) return (0); err_late: - igb_detach(dev); + if(igb_detach(dev) =3D=3D 0) /* igb_detach did the cleanup */ + return; igb_free_transmit_structures(adapter); Can anyone comment on it and tell me if my understanding is incorrect? Seems reasonable to me at the first glance. We need to call IGB_CORE_LOCK_DESTROY(adapter) before returning though. cheers, Hiren