All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arend Van Spriel <arend.vanspriel@broadcom.com>
To: Johannes Berg <johannes@sipsolutions.net>, arend@broadcom.com
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH V7 1/2] nl80211: add feature for BSS selection support
Date: Wed, 24 Feb 2016 11:04:41 +0100	[thread overview]
Message-ID: <56CD8039.9060407@broadcom.com> (raw)
In-Reply-To: <1456260764.9910.31.camel@sipsolutions.net>



On 23-2-2016 21:52, Johannes Berg wrote:
> On Tue, 2016-02-23 at 21:46 +0100, Arend Van Spriel wrote:
>>  
>>> Maybe we should be less specific here regarding the NLA_FLAG and
>>> say
>>> that it will contain attributes for each, indicating which
>>> behaviours
>>> are supported, and say there's behaviour-dependent data inside each
>>> of
>>> those attributes?
>>
>> For the GET_WIPHY case there will be not behaviour dependent data.
>>
>>> It seems entirely plausible that future behaviours would require
>>> their
>>> own sub-capabilities; perhaps that's even the case today for having
>>> an
>>> adjustment range for example, not that I think it's really
>>> necessary
>>> now.
>>
>> At least it does not harm to take that into account.
> 
> Right; there isn't today, but there might be later, so for the
> GET_WIPHY case it might be worth just specifying that there will be an
> attribute, not that it's NLA_FLAG?

Will try and be vague :-)

> Not that it'll matter much - only when we actually add such could
> applications possibly want to parse them :)

That goes without saying :-p

>>>> +	/* only process one nested attribute */
>>>> +	nest = nla_data(nla);
>>>> +	if (!nla_ok(nest, nla_len(nest)))
>>>> +		return -EBADF;
>>>
>>> This isn't quite clear to me. Shouldn't you do this by declaring it
>>> NLA_TESTED in the nl80211_policy?
>>
>> Guess you mean NLA_NESTED.
> 
> Heh, yeah.
> 
>>> Actually, not really? you use nla_ok() on the inner (without having
>>> checked at all that it's even long enough btw, since you didn't do
>>> the
>>> policy change), but that would already be done by nla_parse()
>>> below?
>>
>> Because ATTR_BSS_SELECT is used in CMD_GET_WIPHY and CMD_CONNECT the
>> length of the attribute is not a constant. Or do I only need to put
>> length in nl80211_policy for userspace-2-kernel direction, ie. for
>> ATTR_BSS_SELECT in CMD_CONNECT.
> 
> Ah. kernel->userspace messages don't use the policy in any way, it's
> just for the userspace->kernel message validation, so you can put there
> what's needed for CMD_CONNECT and ignore GET_WIPHY.

I actually do not see any NLA_NESTED attributes with an explicit length.
As you mentioned the nla_parse() of the nested attribute will validate
the length of the stream so no need to put that in the policy.

Regards,
Arend

  reply	other threads:[~2016-02-24 10:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17 10:47 [PATCH V7 1/2] nl80211: add feature for BSS selection support Arend van Spriel
2016-02-17 10:47 ` [PATCH V7 2/2] brcmfmac: add support for nl80211 BSS_SELECT feature Arend van Spriel
2016-02-23 14:20 ` [PATCH V7 1/2] nl80211: add feature for BSS selection support Johannes Berg
2016-02-23 20:46   ` Arend Van Spriel
2016-02-23 20:52     ` Johannes Berg
2016-02-24 10:04       ` Arend Van Spriel [this message]
2016-02-24 10:37         ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56CD8039.9060407@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=arend@broadcom.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.