From owner-freebsd-wireless@FreeBSD.ORG Mon Jul 30 09:16:59 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3ADA7106566C for ; Mon, 30 Jul 2012 09:16:59 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm19.bullet.mail.sp2.yahoo.com (nm19.bullet.mail.sp2.yahoo.com [98.139.91.89]) by mx1.freebsd.org (Postfix) with SMTP id 0D32F8FC12 for ; Mon, 30 Jul 2012 09:16:59 +0000 (UTC) Received: from [98.139.91.65] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 30 Jul 2012 09:16:53 -0000 Received: from [208.71.42.195] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 30 Jul 2012 09:16:53 -0000 Received: from [127.0.0.1] by smtp206.mail.gq1.yahoo.com with NNFMP; 30 Jul 2012 09:16:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1343639813; bh=0l8jISC7Qzt4FrczTlU/rZ7rMgV7B0tFoDBd8foDbnQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=6cCZ9NEuPISUN+JXebxMnvo2CZ041CCWapbnAV2NV7tEgop4Gpy8r1QzOMKyn7KNJt6SdBiJRhb5DHLErwjaCEN0ME4OZdS7gndirVokHbp5dcXlbwuuoxFlB/9w580ySUh6OCN4qpM7DY9h/xFvuSe4WeVaGahdjMANHh6MAgg= X-Yahoo-Newman-Id: 195197.18797.bm@smtp206.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cA.5VT8VM1kuzxgWUHN58kMB8hS4o.ngL9AoQEHM9kyZbeF 2iGiYn_KZysf7G_tlkkB_ImryFSX5EhspHMq6Qux6DQzh8yPNfYafoPqloaf s.evSn9Y2RTsksIXTM1WSbQDX6XBz32tyifbJ.o0aHKje6bTBSrcq_og330f sXFfnltx2_FqeCKGqXi8k5jAjc1va.cZOZihYgGZql8v5Q.SICBWWJAIBWIw 5oyGsfrUimE6GSEhmirqUmyOxZyYMX_sTLNJ8J6duIsDoIkJciaJu_HqyL3P LjCezFLv6fKz8ctFKtxH6XpzH_OaJlN1OGU70U6URgGMWxCy0Ta0JN8V0gBD 61ie9gpQO03kBqEOL1gG0dcfyKYedEibcCWJf3zAEQxfYAjmV5Yw8JbJdGhu 6ZZ6_7kV4QvmXosVlXGWNVfYzZpEuDN271H9mKt7ZPeTLjQsizbD8wE97Kyy NF5_2qJrTQWgOX8m36aMNS8crPJ82ii5ls53SGruIgHO_P3E0TyZa6jjK2BL 7BvwJ0TpqNcxyEUp2P6eK_JgZ1ve_kAad3IiCcfpXOLWQ8UsTM9s- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vc0-f182.google.com (moonlightakkiy@209.85.220.182 with plain) by smtp206.mail.gq1.yahoo.com with SMTP; 30 Jul 2012 02:16:53 -0700 PDT Received: by vcbgb22 with SMTP id gb22so5312672vcb.13 for ; Mon, 30 Jul 2012 02:16:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.148.210 with SMTP id q18mr10332095vcv.6.1343639812248; Mon, 30 Jul 2012 02:16:52 -0700 (PDT) Received: by 10.59.10.194 with HTTP; Mon, 30 Jul 2012 02:16:52 -0700 (PDT) Date: Mon, 30 Jul 2012 03:16:52 -0600 Message-ID: From: PseudoCylon To: Adrian Chadd , Kim Culhan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: ath lor 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: Mon, 30 Jul 2012 09:16:59 -0000 > ------------------------------ > > Message: 3 > Date: Sat, 28 Jul 2012 19:36:38 -0700 > From: Adrian Chadd > Subject: Re: ath lor > To: Kim Culhan > Cc: freebsd-wireless@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hm, if someone's up for a bit of coding, here's my suggestIon: > > * create an iterator struct which just contains an array of > ieee80211_node entries; > * write an iterator function that _just_ populates that iterator > struct with ieee80211 node entries, but after having locked them; > * then, once the call to ieee80211_iterate_node() is done, the > iterator struct will have a list of nodes to iterate over; > * then just call the original callback over each member of that > iterator struct node array, derefing nodes as you go along. > Do you want to change the above to C code? I can do that if no one does it. Do you want an iterator struct node *array* or a linked list? The standard allows 2007 stations to associate an AP, so the array will be that big. Or, use even dirtier trick to make the array size variable? > That avoids calling any callbacks with the iterator node table lock held. > > It's dirty and I would prefer the use of something more modern, like > transactional memory or generation counts, but I'd really like this > bug squished so kim and others can continue hacking/testing this > stuff. It'd also eliminate a rather annoying LOR from the TODO list. > We still need to look after comlock LOR. LOR between scanlock and comlock is the original problem of this thread. And, comlock is causing dead locks all over run(4). I've been working on it, but kinda stuck. Hence no solution, yet. Also, for USB devices, because usbd_do_request_flags() may sleep, hopefully ieee80211 stack understands the driver has to unlock or call taskqueue, even though comlock (or other locks) need to be held during driver functions being executed. http://fxr.watson.org/fxr/source/dev/usb/usb_request.c#L346 AK