Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753554AbbBSVei (ORCPT ); Thu, 19 Feb 2015 16:34:38 -0500 Received: from skprod3.natinst.com ([130.164.80.24]:36348 "EHLO ni.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752134AbbBSVeg (ORCPT ); Thu, 19 Feb 2015 16:34:36 -0500 Message-ID: <54E6561F.4050109@ni.com> Date: Thu, 19 Feb 2015 15:31:11 -0600 From: James Minor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Johannes Berg , Xander Huff CC: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, joseph.hershberger@ni.com, ben.shelton@ni.com, jaeden.amero@ni.com, joshc@ni.com, rich.tollerton@ni.com, brad.mouring@ni.com Subject: Re: [PATCH RFC] wext: Add event stream wrappers that return E2BIG when values don't fit References: <1422565452-19825-1-git-send-email-xander.huff@ni.com> <1422566529.6322.26.camel@sipsolutions.net> In-Reply-To: <1422566529.6322.26.camel@sipsolutions.net> X-MIMETrack: Itemize by SMTP Server on US-AUS-MGWOut1/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 02/19/2015 03:33:10 PM, Serialize by Router on US-AUS-MGWOut1/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 02/19/2015 03:33:10 PM, Serialize complete at 02/19/2015 03:33:10 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=utf-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-02-19_03:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1359 Lines: 32 On 01/29/2015 03:22 PM, Johannes Berg wrote: > > What you mean is "with the wext (compatibility) code in cfg80211". Comment fixed in the v2 of the patch (coming shortly). > > Either way, I *strongly* recommend against using this in the first > > place. There's an upper bound of 64k (I think) on the amount of memory > > that can be used, and people have been known to run into this limit - at > > which point you get absolutely no scan results back whatsoever. It's far > > safer to use nl80211's scan dump, and if you're looking at this code in > > particular then clearly you have it available. Agreed, and we will be switching to nl80211 as soon as we can. > > Regarding the patch itself, it seems to add a bit much code. Is there > > really no better way to express this? Perhaps by checking that the > > stream actually moved forward - which will *always* happen for any of > > these functions if they actually did anything? Even maybe if the new > > _check inlines were to do that it'd still make the code smaller. I've shuffled some things around and will submit the v2 momentarily. Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/