From owner-freebsd-wireless@FreeBSD.ORG Sat Aug 18 03:42:53 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A587106566C for ; Sat, 18 Aug 2012 03:42:53 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm8-vm0.bullet.mail.sp2.yahoo.com (nm8-vm0.bullet.mail.sp2.yahoo.com [98.139.91.194]) by mx1.freebsd.org (Postfix) with SMTP id 47CFE8FC0C for ; Sat, 18 Aug 2012 03:42:53 +0000 (UTC) Received: from [98.139.91.70] by nm8.bullet.mail.sp2.yahoo.com with NNFMP; 18 Aug 2012 03:42:47 -0000 Received: from [208.71.42.195] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 18 Aug 2012 03:42:47 -0000 Received: from [127.0.0.1] by smtp206.mail.gq1.yahoo.com with NNFMP; 18 Aug 2012 03:42:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1345261367; bh=Zm1ksUc7SKeYGWgQXHKR0oDa9kOZLXGfVaXufKHP1KY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=1G6bMAzvsJFkRciQXemjkkw5hhOrWI3VzVbrJ+ueC1z/PCzg/myYS2eYIAZvWUbxBUXr2qjyEVeehbC/tsADqY5omix2QuN6rFcYKAZSCFid7PgBidmdUw+iWLmABJ86hoUFFC/s/s4nGrtYfhXaPB9pQp+1vnuaToIWt0fciZc= X-Yahoo-Newman-Id: 241668.93768.bm@smtp206.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4199rioVM1kcqbiwZJl4RHTuNrUN21ipplgRWG1rToP9gl8 4uCYAaqP0qEkanlOMP9a8tJ2frr5yVCMByiyMTmx4mtlt3FXty8hdOoupFu_ HdV_sb93dJHjiDfFmpLG5LO74PlmdgT6u7oukQzhE8RR6eYVcdHm18RQJeKw RtWHtahmpoyH6QpDERTtqcm8me_1W1Z_vft41H1uln0uTcNywRGFTAY_mYYW AdechL50rDBi.RKmIzLNUgVRWqNDf8X.P1e07s41ay_Qee1NS.8kQM14LSud i.V8D8W0i8LAq0LJAiw8Yxdb_xQkUhH4dr9gNXm0OBfJDg00_xO98BNZlDHT .HAX4a0dBX8lnDKllrfdUobAFr_oksIgjYUeuLr.k6t4t1qqZq_Wrb4kuh_. S6nq39oaRt4a4EaqZOMjOITxKZ4s1RA8aS05qEMp7NCFL0prApALGCaCSCc2 3yYQnUpAv X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vb0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp206.mail.gq1.yahoo.com with SMTP; 17 Aug 2012 20:42:47 -0700 PDT Received: by vbmv11 with SMTP id v11so5211089vbm.13 for ; Fri, 17 Aug 2012 20:42:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.75.36 with SMTP id z4mr3611626vdv.52.1345261366033; Fri, 17 Aug 2012 20:42:46 -0700 (PDT) Received: by 10.58.114.111 with HTTP; Fri, 17 Aug 2012 20:42:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Aug 2012 21:42:45 -0600 Message-ID: From: PseudoCylon To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, Kim Culhan Subject: Re: (ANother) stall fixed, please update to HEAD X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 03:42:53 -0000 On Fri, Aug 17, 2012 at 2:53 AM, Bernhard Schmidt wrote: > On Thu, Aug 9, 2012 at 11:32 AM, PseudoCylon wrote: >>> ------------------------------ >>> >>> Message: 5 >>> Date: Tue, 7 Aug 2012 12:34:52 -0400 >>> From: Kim Culhan >>> Subject: Re: (ANother) stall fixed, please update to HEAD >>> To: Adrian Chadd >>> Cc: freebsd-wireless@freebsd.org >>> Message-ID: >>> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> >>>> Yup. Would you be able to work with PseudoCylon and test his >>>> ieee80211_iterate_nodes() patch? I'd like verification that it fixes >>>> it for you before I tidy it up and commit it to -HEAD. >>> >>> iter.patch and iter2.patch cannot be applied in that order >>> soo.. PseudoCylon could you please generate a diff >>> against -HEAD from your present local source? >>> >> >> No it won't. Only one of them need to apply. I guess I didn't explain well. >> >> iter.path only print outs debug message when the array overflowed >> (most unlikely it will). At this moment, this is what we need. >> >> iter2.patch does iter.patch + revert changes + abort iterating just >> for piece of mind. Probably this is unnecessary. The code need to be >> patched in the way the array won't overflow if it ever happens. (I >> leave it to committers what to commit.) >> >> The attached patch can be applied over iter.patch >> >> Sorry for the confusion. > > Sorry for jumping in that late, but I've a bit of a bellyache with > that change especially the one which got committed. > > You've turned a totally safe function call into one which can fail, > and malloc will fail eventually, therefore all callers need to either > handle the error case or need to clearly state that it is not > necessary to do something. I have the feeling that you've introduced > some cases where due to lost calls the whole system might be hanging > (not as hard as a deadlock, but hard enough to require manual > intervention) by not doing a state change or something. > > Basically, all you've tried to achieve here is an additional unlock to > avoid a deadlock when the called function itself needs to acquire the > lock, performance aside, I'd really prefer if we're simply adding the > unlock and go back to the "restart" approach. At least until someone > either fixes the callers or can come up with a safe enough solution. That's true. Pointers to nodes are copied because we didn't want to unlock while traversing the linked list. Until some one comes up better solution, our options are ether dead lock or malloc. Maybe, driver can allocate the space matches drivers capability on attach. Nicer place to fail. AK