mwifiex: Avoid skipping WEP key deletion for AP - net-next.git - net-next plumbings

summary refs log tree commit diff

path: root/tools/build/feature/test-llvm-version.cpp

diff options

author	Ganapathi Bhat <gbhat@marvell.com>	2017-02-03 18:30:22 +0530
committer	Kalle Valo <kvalo@codeaurora.org>	2017-02-07 10:03:40 +0200
commit	a5b60de6972decc6b50a39abb376077c3c3621c8 (patch)
tree	bd96d73d49986b37233106653d84c7eeaca36438 /tools/build/feature/test-llvm-version.cpp
parent	6232c17438ed01f43665197db5a98a4a4f77ef47 (diff)

mwifiex: Avoid skipping WEP key deletion for AP

This patch fixes the issue specific to AP. AP is started with WEP security and external station is connected to it. Data path works in this case. Now if AP is restarted with WPA/WPA2 security, station is able to connect but ping fails. Driver skips the deletion of WEP keys if interface type is AP. Removing that redundant check resolves the issue. Fixes: e57f1734d87a ("mwifiex: add key material v2 support") Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Diffstat (limited to 'tools/build/feature/test-llvm-version.cpp')

0 files changed, 0 insertions, 0 deletions

8 32 1 : tunables 0 0 0 : slabdata 1336070 1336070 0 The huge numbers above come from insane number of async_work-s allocated and queued by btrfs_wq_run_delayed_node. The problem is caused by btrfs_wq_run_delayed_node() queuing more and more works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The worker func (btrfs_async_run_delayed_root) processes at least BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery works as expected while the list is almost empty. As soon as it is getting bigger, worker func starts to process more than one item at a time, it takes longer, and the chances to have async_works queued more than needed is getting higher. The problem above is worsened by another flaw of delayed-inode implementation: if async_work was queued in a throttling branch (number of items >= BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that the func occupies CPU infinitely (up to 30sec in my experiments): while the func is trying to drain the list, the user activity may add more and more items to the list. The patch fixes both problems in straightforward way: refuse queuing too many works in btrfs_wq_run_delayed_node and bail out of worker func if at least BTRFS_DELAYED_WRITEBACK items are processed. Changed in v2: remove support of thresh == NO_THRESHOLD. Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com> Signed-off-by: Chris Mason <clm@fb.com> Cc: stable@vger.kernel.org # v3.15+

Diffstat (limited to 'tools/perf/pmu-events')