08 Aug, 2020

1 commit

  • As said by Linus:

    A symmetric naming is only helpful if it implies symmetries in use.
    Otherwise it's actively misleading.

    In "kzalloc()", the z is meaningful and an important part of what the
    caller wants.

    In "kzfree()", the z is actively detrimental, because maybe in the
    future we really _might_ want to use that "memfill(0xdeadbeef)" or
    something. The "zero" part of the interface isn't even _relevant_.

    The main reason that kzfree() exists is to clear sensitive information
    that should not be leaked to other future users of the same memory
    objects.

    Rename kzfree() to kfree_sensitive() to follow the example of the recently
    added kvfree_sensitive() and make the intention of the API more explicit.
    In addition, memzero_explicit() is used to clear the memory to make sure
    that it won't get optimized away by the compiler.

    The renaming is done by using the command sequence:

    git grep -w --name-only kzfree |\
    xargs sed -i 's/kzfree/kfree_sensitive/'

    followed by some editing of the kfree_sensitive() kerneldoc and adding
    a kzfree backward compatibility macro in slab.h.

    [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
    [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

    Suggested-by: Joe Perches
    Signed-off-by: Waiman Long
    Signed-off-by: Andrew Morton
    Acked-by: David Howells
    Acked-by: Michal Hocko
    Acked-by: Johannes Weiner
    Cc: Jarkko Sakkinen
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: Joe Perches
    Cc: Matthew Wilcox
    Cc: David Rientjes
    Cc: Dan Carpenter
    Cc: "Jason A . Donenfeld"
    Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
    Signed-off-by: Linus Torvalds

    Waiman Long
     

21 Aug, 2019

1 commit


29 Mar, 2018

1 commit


11 Dec, 2017

1 commit


02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

06 Mar, 2017

1 commit

  • DFS requirement for ETSI domain (section 4.7.1.4 in
    ETSI EN 301 893 V1.8.1) is the only one which explicitly
    states that once DFS channel is marked as available afer
    the CAC, this channel will remain in available state even
    moving to a different operating channel. But the same is
    not explicitly stated in FCC DFS requirement. Also, Pre-CAC
    requriements are not explicitly mentioned in FCC requirement.
    Current implementation in keeping DFS channel in available
    state is same as described in ETSI domain.

    For non-ETSI DFS domain, this patch gives a grace period of 2 seconds
    since the completion of successful CAC before moving the channel's
    DFS state to 'usable' from 'available' state. The same grace period
    is checked against the channel's dfs_state_entered timestamp while
    deciding if a DFS channel is available for operation. There is a new
    radar event, NL80211_RADAR_PRE_CAC_EXPIRED, reported when DFS channel
    is moved from available to usable state after the grace period. Also
    make sure the DFS channel state is reset to usable once the beaconing
    operation on that channel is brought down (like stop_ap, leave_ibss
    and leave_mesh) in non-ETSI domain.

    Signed-off-by: Vasanthakumar Thiagarajan
    Signed-off-by: Johannes Berg

    Vasanthakumar Thiagarajan
     

30 Sep, 2016

1 commit


15 Sep, 2016

1 commit

  • There's no point in allowing connect keys when one of them
    isn't also configured as the TX key, it would just confuse
    drivers and probably cause them to pick something for TX.
    Disallow this confusing and erroneous configuration.

    As wpa_supplicant will always send NL80211_ATTR_KEYS, even
    when there are no keys inside, allow that and treat it as
    though the attribute isn't present at all.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

14 Sep, 2016

1 commit


12 Apr, 2016

1 commit

  • This enum is already perfectly aliased to enum nl80211_band, and
    the only reason for it is that we get IEEE80211_NUM_BANDS out of
    it. There's no really good reason to not declare the number of
    bands in nl80211 though, so do that and remove the cfg80211 one.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

01 Apr, 2015

1 commit

  • …inux/kernel/git/jberg/mac80211-next

    Johannes Berg says:

    ====================
    Lots of updates for net-next; along with the usual flurry
    of small fixes, cleanups and internal features we have:
    * VHT support for TDLS and IBSS (conditional on drivers though)
    * first TX performance improvements (the biggest will come later)
    * many suspend/resume (race) fixes
    * name_assign_type support from Tom Gundersen
    ====================

    Signed-off-by: David S. Miller <davem@davemloft.net>

    David S. Miller
     

04 Mar, 2015

1 commit


03 Mar, 2015

1 commit

  • 802.11ad adds new a network type (PBSS) and changes the capability
    field interpretation for the DMG (60G) band.
    The same 2 bits that were interpreted as "ESS" and "IBSS" before are
    re-used as a 2-bit field with 3 valid values (and 1 reserved). Valid
    values are: "IBSS", "PBSS" (new) and "AP".

    In order to get the BSS struct for the new PBSS networks, change the
    cfg80211_get_bss() function to take a new enum ieee80211_bss_type
    argument with the valid network types, as "capa_mask" and "capa_val"
    no longer work correctly (the search must be band-aware now.)

    The remaining bits in "capa_mask" and "capa_val" are used only for
    privacy matching so replace those two with a privacy enum as well.

    Signed-off-by: Dedy Lansky
    [rewrite commit log, tiny fixes]
    Signed-off-by: Johannes Berg

    Dedy Lansky
     

11 Sep, 2014

1 commit


19 May, 2014

1 commit


25 Apr, 2014

1 commit


10 Apr, 2014

2 commits


09 Apr, 2014

2 commits


20 Mar, 2014

1 commit


21 Feb, 2014

1 commit


05 Feb, 2014

2 commits

  • It was possible to break interface combinations in
    the following way:

    combo 1: iftype = AP, num_ifaces = 2, num_chans = 2,
    combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20

    With the above interface combinations it was
    possible to:

    step 1. start AP on DFS channel by matching combo 2
    step 2. start AP on non-DFS channel by matching combo 1

    This was possible beacuse (step 2) did not consider
    if other interfaces require radar detection.

    The patch changes how cfg80211 tracks channels -
    instead of channel itself now a complete chandef
    is stored.

    Signed-off-by: Michal Kazior
    Signed-off-by: Johannes Berg

    Michal Kazior
     
  • When receiving an IBSS_JOINED event select the BSS object
    based on the {bssid, channel} couple rather than the bssid
    only.
    With the current approach if another cell having the same
    BSSID (but using a different channel) exists then cfg80211
    picks up the wrong BSS object.
    The result is a mismatching channel configuration between
    cfg80211 and the driver, that can lead to any sort of
    problem.

    The issue can be triggered by having an IBSS sitting on
    given channel and then asking the driver to create a new
    cell using the same BSSID but with a different frequency.
    By passing the channel to cfg80211_get_bss() we can solve
    this ambiguity and retrieve/create the correct BSS object.
    All the users of cfg80211_ibss_joined() have been changed
    accordingly.

    Moreover WARN when cfg80211_ibss_joined() gets a NULL
    channel as argument and remove a bogus call of the same
    function in ath6kl (it does not make sense to call
    cfg80211_ibss_joined() with a zero BSSID on ibss-leave).

    Cc: Kalle Valo
    Cc: Arend van Spriel
    Cc: Bing Zhao
    Cc: Jussi Kivilinna
    Cc: libertas-dev@lists.infradead.org
    Acked-by: Kalle Valo
    Signed-off-by: Antonio Quartulli
    [minor code cleanup in ath6kl]
    Signed-off-by: Johannes Berg

    Antonio Quartulli
     

19 Dec, 2013

1 commit

  • This allows QoS mapping from external networks to be implemented as
    defined in IEEE Std 802.11-2012, 10.24.9. APs can use this to advertise
    DSCP ranges and exceptions for mapping frames to a specific UP over
    Wi-Fi.

    The payload of the QoS Map Set element (IEEE Std 802.11-2012, 8.4.2.97)
    is sent to the driver through the new NL80211_ATTR_QOS_MAP attribute to
    configure the local behavior either on the AP (based on local
    configuration) or on a station (based on information received from the
    AP).

    Signed-off-by: Kyeyoon Park
    Signed-off-by: Jouni Malinen
    Signed-off-by: Johannes Berg

    Kyeyoon Park
     

06 Dec, 2013

1 commit


26 Nov, 2013

1 commit

  • These two flags are used for the same purpose, just
    combine them into a no-ir flag to annotate no initiating
    radiation is allowed.

    Old userspace sending either flag will have it treated as
    the no-ir flag. To be considerate to older userspace we
    also send both the no-ir flag and the old no-ibss flags.
    Newer userspace will have to be aware of older kernels.

    Update all places in the tree using these flags with the
    following semantic patch:

    @@
    @@
    -NL80211_RRF_PASSIVE_SCAN
    +NL80211_RRF_NO_IR
    @@
    @@
    -NL80211_RRF_NO_IBSS
    +NL80211_RRF_NO_IR
    @@
    @@
    -IEEE80211_CHAN_PASSIVE_SCAN
    +IEEE80211_CHAN_NO_IR
    @@
    @@
    -IEEE80211_CHAN_NO_IBSS
    +IEEE80211_CHAN_NO_IR
    @@
    @@
    -NL80211_RRF_NO_IR | NL80211_RRF_NO_IR
    +NL80211_RRF_NO_IR
    @@
    @@
    -IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_NO_IR
    +IEEE80211_CHAN_NO_IR
    @@
    @@
    -(NL80211_RRF_NO_IR)
    +NL80211_RRF_NO_IR
    @@
    @@
    -(IEEE80211_CHAN_NO_IR)
    +IEEE80211_CHAN_NO_IR

    Along with some hand-optimisations in documentation, to
    remove duplicates and to fix some indentation.

    Signed-off-by: Luis R. Rodriguez
    [do all the driver updates in one go]
    Signed-off-by: Johannes Berg

    Luis R. Rodriguez
     

25 Nov, 2013

1 commit


06 Nov, 2013

1 commit


28 Oct, 2013

1 commit

  • To use DFS in IBSS mode, userspace is required to react to radar events.
    It can inform nl80211 that it is capable of doing so by adding a
    NL80211_ATTR_HANDLE_DFS attribute when joining the IBSS.

    This attribute is supplied to let the kernelspace know that the
    userspace application can and will handle radar events, e.g. by
    intiating channel switches to a valid channel. DFS channels may
    only be used if this attribute is supplied and the driver supports
    it. Driver support will be checked even if a channel without DFS
    will be initially joined, as a DFS channel may be chosen later.

    Signed-off-by: Simon Wunderlich
    Signed-off-by: Mathias Kretschmer
    [fix attribute name in commit message]
    Signed-off-by: Johannes Berg

    Simon Wunderlich
     

27 Sep, 2013

1 commit

  • Fix kernel warning when using WEXT for configuring ad-hoc mode,
    e.g. "iwconfig wlan0 essid test channel 1"

    WARNING: at net/wireless/chan.c:373 cfg80211_chandef_usable+0x50/0x21c [cfg80211]()

    The warning is caused by an uninitialized variable center_freq1.

    Cc: stable@vger.kernel.org
    Signed-off-by: Bruno Randolf
    Signed-off-by: Johannes Berg

    Bruno Randolf
     

04 Jun, 2013

1 commit

  • The current internal SME implementation in cfg80211 is
    very mixed up with the MLME handling, which has been
    causing issues for a long time. There are three things
    that the implementation has to provide:
    * a basic SME implementation for nl80211's connect()
    call (for drivers implementing auth/assoc, which is
    really just mac80211) and wireless extensions
    * MLME events for the userspace SME
    * SME events (connected, disconnected etc.) for all
    different SME implementation possibilities (driver,
    cfg80211 and userspace)

    To achieve these goals it isn't necessary to track the
    software SME's connection status outside of it's state
    (which is the part that caused many issues.) Instead,
    track it only in the SME data (wdev->conn) and in the
    general case only track whether the wdev is connected
    or not (via wdev->current_bss.)

    Also separate the internal implementation to not have
    callbacks from the SME events, but rather call it from
    the API functions that the driver (or rather mac80211)
    calls. This separates the code better.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

25 May, 2013

1 commit

  • Virtually all code paths in cfg80211 already (need to) hold
    the RTNL. As such, there's little point in having another
    four mutexes for various parts of the code, they just cause
    lock ordering issues (and much of the time, the RTNL and a
    few of the others need thus be held.)

    Simplify all this by getting rid of the extra four mutexes
    and just use the RTNL throughout. Only a few code changes
    were needed to do this and we can get rid of a work struct
    for bonus points.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

12 Feb, 2013

1 commit


26 Nov, 2012

2 commits

  • Change nl80211 to support specifying a VHT (or HT)
    using the control channel frequency (as before) and
    new attributes for the channel width and first and
    second center frequency. The old channel type is of
    course still supported for HT.

    Also change the cfg80211 channel definition struct
    to support these by adding the relevant fields to
    it (and removing the _type field.)

    This also adds new helper functions:
    - cfg80211_chandef_create to create a channel def
    struct given the control channel and channel type,
    - cfg80211_chandef_identical to check if two channel
    definitions are identical
    - cfg80211_chandef_compatible to check if the given
    channel definitions are compatible, and return the
    wider of the two

    This isn't entirely complete, but that doesn't matter
    until we have a driver using it. In particular, it's
    missing
    - regulatory checks on the usable bandwidth (if that
    even makes sense)
    - regulatory TX power (database can't deal with it)
    - a proper channel compatibility calculation for the
    new channel types

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • Instead of passing a channel pointer and channel type
    to all functions and driver methods, pass a new channel
    definition struct. Right now, this struct contains just
    the control channel and channel type, but for VHT this
    will change.

    Also, add a small inline cfg80211_get_chandef_type() so
    that drivers don't need to use the _type field of the
    new structure all the time, which will change.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

18 Oct, 2012

2 commits


29 Jun, 2012

2 commits