Eric Lee / smarc-fsl-linux-kernel

30 Mar, 2018

2 commits

  • 10256debb   net: Don't take rtnl_lock() in wireless_nlevent_flush() ... Browse Code »

    This function iterates over net_namespace_list and flushes
    the queue for every of them. What does this rtnl_lock()
    protects?! Since we may add skbs to net::wext_nlevents
    without rtnl_lock(), it does not protects us about queuers.

    It guarantees, two threads can't flush the queue in parallel,
    that can change the order, but since skb can be queued
    in any order, it doesn't matter, how many threads do this
    in parallel. In case of several threads, this will be even
    faster.

    So, we can remove rtnl_lock() here, as it was used for
    iteration over net_namespace_list only.

    Signed-off-by: Kirill Tkhai
    Signed-off-by: David S. Miller

    Kirill Tkhai
     
  • f0b07bb15   net: Introduce net_rwsem to protect net_namespace_list ... Browse Code »

    rtnl_lock() is used everywhere, and contention is very high.
    When someone wants to iterate over alive net namespaces,
    he/she has no a possibility to do that without exclusive lock.
    But the exclusive rtnl_lock() in such places is overkill,
    and it just increases the contention. Yes, there is already
    for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
    and this can't be sleepable. Also, sometimes it may be need
    really prevent net_namespace_list growth, so for_each_net_rcu()
    is not fit there.

    This patch introduces new rw_semaphore, which will be used
    instead of rtnl_mutex to protect net_namespace_list. It is
    sleepable and allows not-exclusive iterations over net
    namespaces list. It allows to stop using rtnl_lock()
    in several places (what is made in next patches) and makes
    less the time, we keep rtnl_mutex. Here we just add new lock,
    while the explanation of we can remove rtnl_lock() there are
    in next patches.

    Fine grained locks generally are better, then one big lock,
    so let's do that with net_namespace_list, while the situation
    allows that.

    Signed-off-by: Kirill Tkhai
    Signed-off-by: David S. Miller

    Kirill Tkhai
     

28 Mar, 2018

1 commit

13 Feb, 2018

1 commit

  • 6c0075d0f   net: Convert wext_pernet_ops ... Browse Code »

    These pernet_operations initialize and purge net::wext_nlevents
    queue, and are not touched by foreign pernet_operations.

    Mark them async.

    Signed-off-by: Kirill Tkhai
    Acked-by: Andrei Vagin
    Signed-off-by: David S. Miller

    Kirill Tkhai
     

25 Jan, 2018

1 commit

14 Jun, 2017

3 commits

  • 68dd02d19   dev_ioctl: copy only the smaller struct iwreq for wext ... Browse Code »

    Unfortunately, struct iwreq isn't a proper subset of struct ifreq,
    but is still handled by the same code path. Robert reported that
    then applications may (randomly) fault if the struct iwreq they
    pass happens to land within 8 bytes of the end of a mapping (the
    struct is only 32 bytes, vs. struct ifreq's 40 bytes).

    To fix this, pull out the code handling wireless extension ioctls
    and copy only the smaller structure in this case.

    This bug goes back a long time, I tracked that it was introduced
    into mainline in 2.1.15, over 20 years ago!

    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=195869

    Reported-by: Robert O'Callahan
    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • 4f39a1f58   wireless: wext: use struct iwreq earlier in the call chain ... Browse Code »

    To make it clear that we never use struct ifreq, cast from it
    directly in the wext entrypoint and use struct iwreq from there
    on. The next patch will remove the cast again and pass the
    correct struct from the beginning.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • 8bfb36766   wireless: wext: remove ndo_do_ioctl fallback ... Browse Code »

    There are no longer any drivers (in the tree proper, I didn't
    check all the staging drivers) that take WEXT ioctls through
    this API, the only remaining ones that even have ndo_do_ioctl
    are using it only for private ioctls.

    Therefore, we can remove this call.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

13 Jan, 2017

1 commit

  • 10b2eb694   wext: uninline stream addition functions ... Browse Code »

    With 78, 111 and 85 bytes respectively (on x86-64), the
    functions iwe_stream_add_event(), iwe_stream_add_point()
    and iwe_stream_add_value() really shouldn't be inlines.

    It appears that at least my compiler already decided
    the same, and created a single instance of each one
    of them for each file using it, but that's still a
    number of instances in the system overall, which this
    reduces.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

08 Aug, 2016

1 commit

  • 4d0bd46a4   Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel" ... Browse Code »

    This reverts commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724.

    Ben Hutchings pointed out that the commit isn't safe since it assumes
    that the structure used by the driver is iw_point, when in fact there's
    no way to know about that.

    Fortunately, the only driver in the tree that ever runs this code path
    is the wilc1000 staging driver, so it doesn't really matter.

    Clearly I should have investigated this better before applying, sorry.

    Reported-by: Ben Hutchings
    Cc: stable@vger.kernel.org [though I guess it doesn't matter much]
    Fixes: 3d5fdff46c4b ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel")
    Signed-off-by: Johannes Berg

    Johannes Berg
     

09 Jun, 2016

1 commit

  • 3d5fdff46   wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel ... Browse Code »

    iwpriv app uses iw_point structure to send data to Kernel. The iw_point
    structure holds a pointer. For compatibility Kernel converts the pointer
    as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
    may use iw_handler_def.private_args to populate iwpriv commands instead
    of iw_handler_def.private. For those case, the IOCTLs from
    SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl().
    Accordingly when the filled up iw_point structure comes from 32 bit
    iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends
    it to driver. So, the driver may get the invalid data.

    The pointer conversion for the IOCTLs (SIOCIWFIRSTPRIV to
    SIOCIWLASTPRIV), which follow the path ndo_do_ioctl(), is mandatory.
    This patch adds pointer conversion from 32 bit to 64 bit and vice versa,
    if the ioctl comes from 32 bit iwpriv to 64 bit Kernel.

    Cc: stable@vger.kernel.org
    Signed-off-by: Prasun Maiti
    Signed-off-by: Ujjal Roy
    Tested-by: Dibyajyoti Ghosh
    Signed-off-by: Johannes Berg

    Prasun Maiti
     

05 Apr, 2016

1 commit

30 Jan, 2016

2 commits

  • cb150b9d2   cfg80211/wext: fix message ordering ... Browse Code »

    Since cfg80211 frequently takes actions from its netdev notifier
    call, wireless extensions messages could still be ordered badly
    since the wext netdev notifier, since wext is built into the
    kernel, runs before the cfg80211 netdev notifier. For example,
    the following can happen:

    5: wlan1: mtu 1500 qdisc mq state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
    5: wlan1:
    link/ether

    when setting the interface down causes the wext message.

    To also fix this, export the wireless_nlevent_flush() function
    and also call it from the cfg80211 notifier.

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

    Johannes Berg
     
  • 8bf862739   wext: fix message delay/ordering ... Browse Code »

    Beniamino reported that he was getting an RTM_NEWLINK message for a
    given interface, after the RTM_DELLINK for it. It turns out that the
    message is a wireless extensions message, which was sent because the
    interface had been connected and disconnection while it was deleted
    caused a wext message.

    For its netlink messages, wext uses RTM_NEWLINK, but the message is
    without all the regular rtnetlink attributes, so "ip monitor link"
    prints just rudimentary information:

    5: wlan1: mtu 1500 qdisc mq state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
    Deleted 5: wlan1: mtu 1500 qdisc noop state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
    5: wlan1:
    link/ether
    (from my hwsim reproduction)

    This can cause userspace to get confused since it doesn't expect an
    RTM_NEWLINK message after RTM_DELLINK.

    The reason for this is that wext schedules a worker to send out the
    messages, and the scheduling delay can cause the messages to get out
    to userspace in different order.

    To fix this, have wext register a netdevice notifier and flush out
    any pending messages when netdevice state changes. This fixes any
    ordering whenever the original message wasn't sent by a notifier
    itself.

    Cc: stable@vger.kernel.org
    Reported-by: Beniamino Galvani
    Signed-off-by: Johannes Berg

    Johannes Berg
     

05 Sep, 2012

1 commit

16 Apr, 2012

1 commit

13 Apr, 2012

1 commit

10 Apr, 2012

1 commit

02 Apr, 2012

1 commit

01 Nov, 2011

1 commit

25 Nov, 2010

1 commit

10 Sep, 2010

1 commit

01 Sep, 2010

1 commit

  • 365391071   net/wireless: Remove double test ... Browse Code »

    The same expression is tested twice and the result is the same each time.

    The sematic match that finds this problem is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @expression@
    expression E;
    @@

    (
    * E
    || ... || E
    |
    * E
    && ... && E
    )
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: John W. Linville

    Julia Lawall
     

31 Aug, 2010

1 commit

  • 42da2f948   wireless extensions: fix kernel heap content leak ... Browse Code »

    Wireless extensions have an unfortunate, undocumented
    requirement which requires drivers to always fill
    iwp->length when returning a successful status. When
    a driver doesn't do this, it leads to a kernel heap
    content leak when userspace offers a larger buffer
    than would have been necessary.

    Arguably, this is a driver bug, as it should, if it
    returns 0, fill iwp->length, even if it separately
    indicated that the buffer contents was not valid.

    However, we can also at least avoid the memory content
    leak if the driver doesn't do this by setting the iwp
    length to max_tokens, which then reflects how big the
    buffer is that the driver may fill, regardless of how
    big the userspace buffer is.

    To illustrate the point, this patch also fixes a
    corresponding cfg80211 bug (since this requirement
    isn't documented nor was ever pointed out by anyone
    during code review, I don't trust all drivers nor
    all cfg80211 handlers to implement it correctly).

    Cc: stable@kernel.org [all the way back]
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

12 Apr, 2010

1 commit

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

24 Mar, 2010

2 commits

05 Dec, 2009

2 commits

30 Nov, 2009

1 commit

08 Oct, 2009

1 commit

  • 3d23e349d   wext: refactor ... Browse Code »

    Refactor wext to
    * split out iwpriv handling
    * split out iwspy handling
    * split out procfs support
    * allow cfg80211 to have wireless extensions compat code
    w/o CONFIG_WIRELESS_EXT

    After this, drivers need to
    - select WIRELESS_EXT - for wext support
    - select WEXT_PRIV - for iwpriv support
    - select WEXT_SPY - for iwspy support

    except cfg80211 -- which gets new hooks in wext-core.c
    and can then get wext handlers without CONFIG_WIRELESS_EXT.

    Wireless extensions procfs support is auto-selected
    based on PROC_FS and anything that requires the wext core
    (i.e. WIRELESS_EXT or CFG80211_WEXT).

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg