Commit 78f1699 (ACPI: processor: call _PDC early) blindly walks
the namespace and calls _PDC on every processor object it finds.
This change may cause issues on platforms that declare dummy
values for SSDTs on non-present processors (disabled in MADT).
When we call _PDC and dynamically attempt to execute the AML
Load() op on these dummy SSDTs, there's no telling what might
happen.
Rather than finding every platform that has bogus SSDTs, restrict
early _PDC calls to platforms that are known to need early
evaluation of _PDC.
This is a minimal, temporary fix (given the context of the
current release cycle). A real solution of checking the MADT for
non-present processors will be written for the next merge window.
References:
http://bugzilla.kernel.org/show_bug.cgi?id=14710http://bugzilla.kernel.org/show_bug.cgi?id=14954
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The "full_alg_name" variable is used on a couple error paths, so we
shouldn't free it until the end.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
The variable lower_dentry is initialized twice to the same (side effect-free)
expression. Drop one initialization.
A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)
// <smpl>
@forall@
idexpression *x;
identifier f!=ERR_PTR;
@@
x = f(...)
... when != x
(
x = f(...,<+...x...+>,...)
|
* x = f(...)
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
ecryptfs_interpose checks if one of the flags passed is
ECRYPTFS_INTERPOSE_FLAG_D_ADD, defined as 0x00000001 in ecryptfs_kernel.h.
But the only user of ecryptfs_interpose to pass a non-zero flag to it, has
hard-coded the value as "1". This could spell trouble if any of these values
changes in the future.
Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Unnecessary because it would unhash perfectly valid dentries, causing them
to have to be re-looked up the next time they're needed, which presumably is
right after.
Signed-off-by: Aseem Rastogi <arastogi@cs.sunysb.edu>
Signed-off-by: Shrikar archak <shrikar84@gmail.com>
Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
Cc: Saumitra Bhanage <sbhanage@cs.sunysb.edu>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Ecryptfs_open dereferences a pointer to the private lower file (the one
stored in the ecryptfs inode), without checking if the pointer is NULL.
Right afterward, it initializes that pointer if it is NULL. Swap order of
statements to first initialize. Bug discovered by Duckjin Kang.
Signed-off-by: Duckjin Kang <fromdj2k@gmail.com>
Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: <stable@kernel.org>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Adrian reported that mkfontscale didn't work inside of eCryptfs mounts.
Strace revealed the following:
open("./", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
open("./fonts.scale", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
getdents(3, /* 80 entries */, 32768) = 2304
open("./.", O_RDONLY) = 5
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
fstat64(5, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
mmap2(NULL, 16384, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb7fcf000
close(5) = 0
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++
The mmap2() on a directory was successful, resulting in a SIGBUS
signal later. This patch removes mmap() from the list of possible
ecryptfs_dir_fops so that mmap() isn't possible on eCryptfs directory
files.
https://bugs.launchpad.net/ecryptfs/+bug/400443
Reported-by: Adrian C. <anrxc@sysphere.org>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
The i_blocks field of an eCryptfs inode cannot be trusted, but
generic_fillattr() uses it to instantiate the blocks field of a stat()
syscall when a filesystem doesn't implement its own getattr(). Users
have noticed that the output of du is incorrect on newly created files.
This patch creates ecryptfs_getattr() which calls into the lower
filesystem's getattr() so that eCryptfs can use its kstat.blocks value
after calling generic_fillattr(). It is important to note that the
block count includes the eCryptfs metadata stored in the beginning of
the lower file plus any padding used to fill an extent before
encryption.
https://bugs.launchpad.net/ecryptfs/+bug/390833
Reported-by: Dominic Sacré <dominic.sacre@gmx.de>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
When truncating inodes in the lower filesystem, eCryptfs directly
invoked vmtruncate(). As Christoph Hellwig pointed out, vmtruncate() is
a filesystem helper function, but filesystems may need to do more than
just a call to vmtruncate().
This patch moves the lower inode truncation out of ecryptfs_truncate()
and renames the function to truncate_upper(). truncate_upper() updates
an iattr for the lower inode to indicate if the lower inode needs to be
truncated upon return. ecryptfs_setattr() then calls notify_change(),
using the updated iattr for the lower inode, to complete the truncation.
For eCryptfs functions needing to truncate, ecryptfs_truncate() is
reintroduced as a simple way to truncate the upper inode to a specified
size and then truncate the lower inode accordingly.
https://bugs.launchpad.net/bugs/451368
Reported-by: Christoph Hellwig <hch@lst.de>
Acked-by: Dustin Kirkland <kirkland@canonical.com>
Cc: ecryptfs-devel@lists.launchpad.net
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
The comments in cacheflush.h should follow what's in
struct cpu_cache_fns. The comments for V6 and V7 are
unnecessary.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch addresses a number of minor (mostly cosmetic) issues relating
to the configuration of TIPC, including the following:
- Corrects range limits for maximum number of ports per node
- Adds missing range limits for size of log buffer
- Removes configuration setting relating to unsupported slave node capability
- Standardizes description and help text wording for configuration settings
- Removes unneeded blank spaces
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When cleaning up beacon buffers and slots, ath9k currently checks if
sc->ah->opmode is set to a beacon related mode before cleaning up
buffers.
An unfortunate ordering of interface up/down commands can lead to
sc->ah->opmode being set to monitor mode, while there are AP interfaces
present on the same wiphy.
Always cleaning up beacon buffers if present fixes this issue.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Users wishing to tweak tx power want it to happen immediately,
try to respect that. This was tested by Lorenzo by measuring the
received signal strength from an AP with ath9k and the patch.
Changing the tx power on the AP produced these results:
1) iwconfig wlan0 txpower 20 ---> Rx power -37dbm
2) iwconfig wlan0 txpower 15 ---> Rx power -41dbm
3) iwconfig wlan0 txpower 10 ---> Rx power -45dbm
4) iwconfig wlan0 txpower 5 ---> Rx power -51dbm
5) iwconfig wlan0 txpower 0 ---> Rx power -37dbm
The result with 0 is an anomoly and would need to be
addressed through a separate patch.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
nl80211_associate() was rejecting (re)association attempts with EBUSY
in some cases where we are currently associated with an AP that uses
different channel from the destination AP. Fix this by passing the
current wdev to rdev_fixed_channel() in the same way that was already
done for join-IBSS and connect commands. This allows the fixedchan
check to skipped for the current wdev and allows the reassociation to
proceed.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the v10 firmware running on 8688 HW, clearing WPA keys after setting the
WEP key prevents us from being able to associate with WEP APs.
Swapping the calling order for assoc_helper_wpa_keys() and
assoc_helper_wep_keys fixes that issue.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch moves the tx cleanup routines out of the critical
interrupt context and into the (previously known as rx) tasklet.
The main goal of this operation is to remove the extensive
usage of spin_lock_irqsaves in the generic p54common library.
The next step would be to modify p54usb to do the
rx processing inside a tasklet (just like usbnet).
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds error-paths to handle pci_dma_mapping errors.
Cc: <stable@kernel.org>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
First, both beacons and probe responses can be used for IBSS merge.
Next, sdata->u.ibss.bssid was always true (and thus IBSS merge was
disabled). We should use sdata->u.ibss.fixed_bssid instead.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee82011_sta_find_ibss() and ieee80211_sta_merge_ibss() are always
called with a defined state. So it's useless to check it or set it in
those function.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The Tx DMA descriptor has two kinds of flags that select RTS/CTS usage.
The first one (global for the frame) selects whether RTS/CTS or
CTS-to-self should be used, the second one enables RTS/CTS or
CTS-to-self usage for an individual multi-rate-retry entry.
Previously the code preparing the descriptor only enabled the global
flag, if the first MRR series selected the local one.
Fix this by enabling the global flag if any of the MRR entries need it.
With this patch, rate control can properly select the use of RTS/CTS
for all MRR entries except the first one, which is the default behavior.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Future code will need to look up rdev and wdev
within atomic sections, but currently we need
to lock a mutex for such lookups. Change the
list handling for both to be RCU-safe so that
we can look them up in rcu sections instead in
the future.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In an earlier commit,
mac80211: disable software retry for now
Pavel Roskin reported a problem that seems to be due to
software retry of already transmitted frames. It turns
out that we've never done that correctly, but due to
some recent changes it now crashes in the TX code. I've
added a comment in the patch that explains the problem
better and also points to possible solutions -- which
I can't implement right now.
I disabled software retry of failed/filtered frames
because it was broken. With the work of the previous
patches, it now becomes fairly easy to re-enable it
by adding a flag indicating that the frame shouldn't
be modified, but still running it through the transmit
handlers to populate the control information.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When mac80211 asks a driver to encrypt a frame, it
must assign the control.hw_key pointer for it to
know which key to use etc. Currently, mac80211 does
this whenever it would software-encrypt a frame.
Change the logic of this code to assign the hw_key
pointer when selecting the key, and later check it
when deciding whether to encrypt the frame or let
it be encrypted by the hardware. This allows us to
later simply skip the encryption function since it
no longer modifies the TX control.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no value in setting a flag that will
never be checked after this point, this seems
to be legacy code -- I think previously the
flag was used to check whether to encrypt the
frame or not. Now, however, the flag need not
be set, and setting it actually interferes if
the frame will be processed again later.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When an skb survived a round-trip through the driver
and needs to be re-used, its control information is
definitely not valid any more, the driver will have
overwritten it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This TX handler is used only for assigning the
station pointer in the control information, so
give it a better name. Also move it before rate
control.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Code directly scaling by HZ and rounding can be more efficiently
and clearly performed with msecs_to_jiffies.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When reading current ucode statistics information from debugfs, in
current implementation, it will always send a new "statistics request" to
uCode. In normal operation, uCode should report the statistics per beacon
interval. Remove this extra request to reduce the additional command exchanges
between driver and uCode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Flowhandler handle the communication between driver and uCode, when any
uCode error happen, we also like to know what is the status of the
flowhandler; it can help to debug flowhandler related problem.
Also adding debugfs file to dump current value of flowhandler registers.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is a w/a for a hardware bug. the h/w bug may cause the Rx bit
(bit 15 before shifting it to 31) to clear when using interrupt coalescing.
This does not mean frames are lost - their processing is just delayed until
next interrupt arrives.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For interrupt coalescing timer, the CSR_INT_COALESCING is an 8 bit
register in 32-usec unit, the range can go from 0x00 - 0xFF. set the
range and default timeout value for both calibration mode and operation mode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When dumping event log in debugfs, iwl_dump_nic_event_log()
should return the correct error code instead of let the calling
function makes it own assumption.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
