Use a different value for DFS dwell time when performing a scheduled
scan. Previously we were using the same value as for normal passive
scans. This adds some flexibility between these two different types
of passive scan.
For now we use 150 TUs for DFS channel dwell time. This may need to
be fine-tuned in the future.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
DFS channels were never getting included in the scheduled scans,
because they always contain the passive flag as well and the call was
asking for DFS and active channels.
Fix this by ignoring the passive flag when collecting DFS channels.
Also, move the DFS channels in the channel list before the 5GHz active
channels (this was implemented in the FW differently than specified).
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We were comparing bitwise AND results with a boolean, so when the
boolean was set to true, it was not matching as it should.
Fix this by booleanizing the bitwise AND results with !!.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Before this patch, the command sequence number is being set before
lbs_queue_cmd() adds the command to the queue. However, lbs_queue_cmd()
sometimes forces commands to queue-jump (e.g. CMD_802_11_WAKEUP_CONFIRM).
It currently does this without considering that sequence numbers might need
adjusting to keep things running in order.
Fix this by setting the sequence number at a later stage, just before
we're actually submitting the command to the hardware. Also fixes a
possible race where seqnum was being modified outside of the driver
lock.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: Fix mwait_play_dead() faulting on mwait-incapable cpus
x86 idle: Fix mwait deprecation warning message
Evil merge to remove extra quote noticed by Joe Perches
Since those defined functions require additional semicolon
from the caller, they could cause potential syntax errors
when used in if-else statements.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: Put back -pg to tsc.o and add no GCOV to vread_tsc_64.o
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
autofs4: bogus dentry_unhash() added in ->unlink()
vfs: shrink_dcache_parent before rmdir, dir rename
The Apple custom PIC only exist in some earlier machine models,
anything with an MPIC will crash on suspend if we register those
syscore ops unconditionally.
This is a regression caused by commit f5a592f7d7 ("PM / PowerPC: Use
struct syscore_ops instead of sysdevs for PM")
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit cc3ce5176d (rcu: Start RCU kthreads in TASK_INTERRUPTIBLE
state) fudges a sleeping task' state, resulting in the scheduler seeing
a TASK_UNINTERRUPTIBLE task going to sleep, but a TASK_INTERRUPTIBLE
task waking up. The result is unbalanced load calculation.
The problem that patch tried to address is that the RCU threads could
stay in UNINTERRUPTIBLE state for quite a while and triggering the hung
task detector due to on-demand wake-ups.
Cure the problem differently by always giving the tasks at least one
wake-up once the CPU is fully up and running, this will kick them out of
the initial UNINTERRUPTIBLE state and into the regular INTERRUPTIBLE
wait state.
[ The alternative would be teaching kthread_create() to start threads as
INTERRUPTIBLE but that needs a tad more thought. ]
Reported-by: Damien Wyart <damien.wyart@free.fr>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Paul E. McKenney <paul.mckenney@linaro.org>
Link: http://lkml.kernel.org/r/1306755291.1200.2872.camel@twins
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This reverts commit 1b842e91fe.
There is a fundamental ordering race between the early and late probe
paths and the runtime PM tie-in that results in __pm_runtime_resume()
attempting to take a lock that hasn't been initialized yet (which by
proxy also suggests that pm_runtime_init() hasn't yet been run on the
device either, making the entire thing unsafe) -- resulting in instant
death on SMP or on UP with spinlock debugging enabled:
sh_tmu.0: used for clock events
sh_tmu.0: used for periodic clock events
BUG: spinlock trylock failure on UP on CPU#0, swapper/0
lock: 804db198, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
...
Revert it for now until the ordering issues can be resolved, or we can get
some more help from the runtime PM framework to make this possible.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
There was an ordering issue with regards to instruction_pointer() being
used in profile_pc() prior to the asm-generic/ptrace.h include, which
subsequently provided the instruction_pointer() definition. In the
interest of simplicity we simply open-code the regs->pc deref for the
profile_pc() definition instead.
The FP functions were also broken due to a lack of a common regs->fp,
so provide a common GET_FP() that is safe for both architectures in order
to fix up the frame pointer helpers too.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sh64 doesn't define a P1SEGADDR, resulting in a build failure. The proper
mapping can be attained for both sh32 and 64 via the CAC_ADDR macro, so
switch to that instead.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Commit 1e56a56410 introduced the mmu_gather
rework for sh, but missed a linux/swap.h include:
CC arch/sh/mm/tlb-urb.o
In file included from arch/sh/mm/tlb-urb.c:14:0:
arch/sh/include/asm/tlb.h: In function '__tlb_remove_page':
arch/sh/include/asm/tlb.h:92:2: error: implicit declaration of function 'free_page_and_swap_cache'
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
A logic error in mwait_play_dead() causes the kernel to use
mwait even on cpus which don't support it, such as KVM virtual
cpus.
Introduced by:
349c004e3d31: x86: A fast way to check capabilities of the current cpu
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=36222
Reported-by: Török Edwin <edwintorok@gmail.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/r/1306758237-9327-1-git-send-email-avi@redhat.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The dentry_unhash push-down series missed that shink_dcache_parent needs to
be called prior to rmdir or dir rename to clear DCACHE_REFERENCED and
allow efficient dentry reclaim.
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
It was not a good idea to start dereferencing disk->queue from
the fs sysfs strategy for displaying discard alignment. We ran
into first a NULL pointer deref, and after fixing that we sometimes
see unvalid disk->queue pointer values.
Since discard is the only one of the bunch actually looking into
the queue, just revert the change.
This reverts commit 23ceb5b771.
Conflicts:
fs/partitions/check.c
Ask for delayed callbacks on TX ring full, to give the
other side more of a chance to make progress.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add an API that tells the other side that callbacks
should be delayed until a lot of work has been done.
Implement using the new event_idx feature.
Note: it might seem advantageous to let the drivers
ask for a callback after a specific capacity has
been reached. However, as a single head can
free many entries in the descriptor table,
we don't really have a clue about capacity
until get_buf is called. The API is the simplest
to implement at the moment, we'll see what kind of
hints drivers can pass when there's more than one
user of the feature.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Support the new event index feature. When acked,
utilize it to reduce the # of interrupts sent to the guest.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Support for the new event idx feature:
1. When enabling interrupts, publish the current avail index
value to the host to get interrupts on the next update.
2. Use the new avail_event feature to reduce the number
of exits from the guest.
Simple test with the simulator:
[virtio]# time ./virtio_test
spurious wakeus: 0x7
real 0m0.169s
user 0m0.140s
sys 0m0.019s
[virtio]# time ./virtio_test --no-event-idx
spurious wakeus: 0x11
real 0m0.649s
user 0m0.295s
sys 0m0.335s
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
With the new used_event and avail_event and features, both
host and guest need similar logic to check whether events are
enabled, so it helps to put the common code in the header.
Note that Xen has similar logic for notification hold-off
in include/xen/interface/io/ring.h with req_event and req_prod
corresponding to event_idx + 1 and new_idx respectively.
+1 comes from the fact that req_event and req_prod in Xen start at 1,
while event index in virtio starts at 0.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Define a new feature bit for the guest and host to utilize
an event index (like Xen) instead if a flag bit to enable/disable
interrupts and kicks.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's unclear to me if it's important, but it's obviously causing my
technical colleages some headaches and I'd hate such imprecision to
slow virtio adoption.
I've emailed this to all non-trivial contributors for approval, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Ryan Harper <ryanh@us.ibm.com>
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
Acked-by: Eric Van Hensbergen <ericvh@gmail.com>
Acked-by: john cooper <john.cooper@redhat.com>
Acked-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
feature bit. Whenever the bit is set, the guest kernel must
always tell the host before we free pages back to the allocator.
Without this feature, we might free a page (and have another
user touch it) while the hypervisor is unprepared for it.
But, if the bit is _not_ set, we are under no obligation to
reverse the order; we're under no obligation to do _anything_.
As of now, qemu-kvm defines the bit, but doesn't set it.
This patch makes the "tell host first" logic the only case. This
should make everybody happy, and reduce the amount of untested or
untestable code in the kernel.
This _also_ means that we don't have to preserve a pfn list
after the pages are freed, which should let us get rid of some
temporary storage (vb->pfns) eventually.
Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
That's already been done by the virtio infrastructure before the probe
function is called.
Reported-by: alexey.kardashevskiy@au1.ibm.com
Acked-by: Amit Shah <amit.shah@redhat.com>
Tested-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It is easier to figure out the context by reading SCSI_SENSE_BUFFERSIZE
instead of plain '96'.
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Wire up the virtio_driver config_changed method to get notified about
config changes raised by the host. For now we just re-read the device
size to support online resizing of devices, but once we add more
attributes that might be changeable they could be added as well.
Note that the config_changed method is called from irq context, so
we'll have to use the workqueue infrastructure to provide us a proper
user context for our changes.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Without an IRQ chip set, we now get a WARN_ON and no timer interrupt. This
prevents booting.
Fortunately, the fix is a one-liner: set up the timer IRQ like everything
else.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org # .39.x
.. except there are various scripts that really know that there are
three numbers, so it calls itself "3.0.0-rc1".
Hopefully by the time the final 3.0 is out, we'll have that extra zero
all figured out.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We had a few drivers move from arch/arm into drivers/gpio, but they
don't actually compile without the ARM platform headers etc. As a
result they were messing up allyesconfig on x86.
Make them depend on ARM.
Reported-by: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now that ecryptfs_lookup_interpose() is no longer using
ecryptfs_header_cache_2 to read in metadata, the kmem_cache can be
removed and the ecryptfs_header_cache_1 kmem_cache can be renamed to
ecryptfs_header_cache.
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
ecryptfs_lookup_interpose() has turned into spaghetti code over the
years. This is an effort to clean it up.
- Shorten overly descriptive variable names such as ecryptfs_dentry
- Simplify gotos and error paths
- Create helper function for reading plaintext i_size from metadata
It also includes an optimization when reading i_size from the metadata.
A complete page-sized kmem_cache_alloc() was being done to read in 16
bytes of metadata. The buffer for that is now statically declared.
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Instead of having the calling functions translate the true/false return
code to either 0 or -EINVAL, have contains_ecryptfs_marker() return 0 or
-EINVAL so that the calling functions can just reuse the return code.
Also, rename the function to ecryptfs_validate_marker() to avoid callers
mistakenly thinking that it returns true/false codes.
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Only unlock and d_add() new inodes after the plaintext inode size has
been read from the lower filesystem. This fixes a race condition that
was sometimes seen during a multi-job kernel build in an eCryptfs mount.
https://bugzilla.kernel.org/show_bug.cgi?id=36002
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Reported-by: David <david@unsolicited.net>
Tested-by: David <david@unsolicited.net>
Luciano Coelho