Andrew Morton [Thu, 30 Sep 2010 22:15:29 +0000 (15:15 -0700)]
arch/m68k/mac/macboing.c: use unsigned long for irqflags
Fix the warnings
arch/m68k/mac/macboing.c: In function 'mac_mksound':
arch/m68k/mac/macboing.c:189: warning: comparison of distinct pointer types lacks a cast
arch/m68k/mac/macboing.c:211: warning: comparison of distinct pointer types lacks a cast
arch/m68k/mac/macboing.c: In function 'mac_quadra_start_bell':
arch/m68k/mac/macboing.c:241: warning: comparison of distinct pointer types lacks a cast
arch/m68k/mac/macboing.c:263: warning: comparison of distinct pointer types lacks a cast
arch/m68k/mac/macboing.c: In function 'mac_quadra_ring_bell':
arch/m68k/mac/macboing.c:283: warning: comparison of distinct pointer types lacks a cast
Andrew Morton [Thu, 30 Sep 2010 22:15:28 +0000 (15:15 -0700)]
drivers/serial/mfd.c needs slab.h
alpha allmodconfig:
drivers/serial/mfd.c:144: error: implicit declaration of function 'kzalloc'
drivers/serial/mfd.c:144: warning: assignment makes pointer from integer without a cast
Ira W. Snyder [Thu, 30 Sep 2010 22:15:27 +0000 (15:15 -0700)]
kfifo: fix scatterlist usage
The kfifo_dma family of functions use sg_mark_end() on the last element in
their scatterlist. This forces use of a fresh scatterlist for each DMA
operation, which makes recycling a single scatterlist impossible.
Change the behavior of the kfifo_dma functions to match the usage of the
dma_map_sg function. This means that users must respect the returned
nents value. The sample code is updated to reflect the change.
This bug is trivial to cause: call kfifo_dma_in_prepare() such that it
prepares a scatterlist with a single entry comprising the whole fifo.
This is the case when you map the entirety of a newly created empty fifo.
This causes the setup_sgl() function to mark the first scatterlist entry
as the end of the chain, no matter what comes after it.
Afterwards, add and remove some data from the fifo such that another call
to kfifo_dma_in_prepare() will create two scatterlist entries. It returns
nents=2. However, due to the previous sg_mark_end() call, sg_is_last()
will now return true for the first scatterlist element. This causes the
sample code to print a single scatterlist element when it should print
two.
By removing the call to sg_mark_end(), we make the API as similar as
possible to the DMA mapping API. All users are required to respect the
returned nents.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu> Cc: Stefani Seibold <stefani@seibold.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jeff Layton [Wed, 29 Sep 2010 19:27:08 +0000 (15:27 -0400)]
cifs: prevent infinite recursion in cifs_reconnect_tcon
cifs_reconnect_tcon is called from smb_init. After a successful
reconnect, cifs_reconnect_tcon will call reset_cifs_unix_caps. That
function will, in turn call CIFSSMBQFSUnixInfo and CIFSSMBSetFSUnixInfo.
Those functions also call smb_init.
It's possible for the session and tcon reconnect to succeed, and then
for another cifs_reconnect to occur before CIFSSMBQFSUnixInfo or
CIFSSMBSetFSUnixInfo to be called. That'll cause those functions to call
smb_init and cifs_reconnect_tcon again, ad infinitum...
Break the infinite recursion by having those functions use a new
smb_init variant that doesn't attempt to perform a reconnect.
Reported-and-Tested-by: Michal Suchanek <hramrach@centrum.cz> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
vmwgfx: Fix fb VRAM pinning failure due to fragmentation
If the soon-to-be scanout buffer is partly covering the intended
VRAM region, move and pin will fail. In that case, just move it out
to system before attempting to move it in again.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
This is to avoid accessing uninitialized data during
drm_irq_uninstall and vblank ioctls. At the same time, enable error check from
drm_kms_init which previously appeared to ignore all errors.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
We add an option not to enable fbdev, this option is off (0) by default.
Not enabling fbdev at load time makes it possible to co-operate with
vga16fb and vga text mode when VT switching.
However, if 3D resources are active when VT switching, we're currently
not able to switch over to vga, due to device limitations.
This fixes a bug where we previously lost 3D state during VT switch.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Chris Wilson [Thu, 30 Sep 2010 08:10:26 +0000 (09:10 +0100)]
drm: Hold the mutex when dropping the last GEM reference (v2)
In order to be fully threadsafe we need to check that the drm_gem_object
refcount is still 0 after acquiring the mutex in order to call the free
function. Otherwise, we may encounter scenarios like:
Note that no driver is currently using the free_unlocked vfunc and it is
scheduled for removal, hasten that process.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30454 Reported-and-Tested-by: Magnus Kessler <Magnus.Kessler@gmx.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
Suresh Siddha [Fri, 1 Oct 2010 01:19:07 +0000 (21:19 -0400)]
intel_idle: Voluntary leave_mm before entering deeper
Avoid TLB flush IPIs for the cores in deeper c-states by voluntary leave_mm()
before entering into that state. CPUs tend to flush TLB in those c-states
anyways.
acpi_idle does this with C3-type states, but it was not caried over
when intel_idle was introduced. intel_idle can apply it
to C-states in addition to those that ACPI might export as C3...
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Eric Dumazet [Thu, 30 Sep 2010 02:16:44 +0000 (02:16 +0000)]
vlan: dont drop packets from unknown vlans in promiscuous mode
Roger Luethi noticed packets for unknown VLANs getting silently dropped
even in promiscuous mode.
Check for promiscuous mode in __vlan_hwaccel_rx() and vlan_gro_common()
before drops.
As suggested by Patrick, mark such packets to have skb->pkt_type set to
PACKET_OTHERHOST to make sure they are dropped by IP stack.
Reported-by: Roger Luethi <rl@hellgate.ch> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> CC: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Dave Airlie [Mon, 27 Sep 2010 06:17:17 +0000 (16:17 +1000)]
drm/gem: handlecount isn't really a kref so don't make it one.
There were lots of places being inconsistent since handle count
looked like a kref but it really wasn't.
Fix this my just making handle count an atomic on the object,
and have it increase the normal object kref.
Now i915/radeon/nouveau drivers can drop the normal reference on
userspace object creation, and have the handle hold it.
This patch fixes a memory leak or corruption on unload, because
the driver had no way of knowing if a handle had been actually
added for this object, and the fbcon object needed to know this
to clean itself up properly.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
MyungJoo Ham [Thu, 30 Sep 2010 13:54:46 +0000 (15:54 +0200)]
i2c-s3c2410: fix calculation of SDA line delay
S3C2440 style I2C controller uses PCLK to calculate the SDA line delay.
The driver wrongly assumed that this delay is calculated from the
frequency that the controller is operating on. This patch fixes this
issue.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Thomas Gleixner [Tue, 28 Sep 2010 18:57:19 +0000 (20:57 +0200)]
x86, irq: Plug memory leak in sparse irq
free_irq_cfg() is not freeing the cpumask_vars in irq_cfg. Fixing this
triggers a use after free caused by the fact that copying struct
irq_cfg is done with memcpy, which copies the pointer not the cpumask.
Fix both places.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Yinghai Lu <yhlu.kernel@gmail.com>
LKML-Reference: <alpine.LFD.2.00.1009282052570.2416@localhost6.localdomain6> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Commit c52c2ddc1dfa ("alpha: switch osf_sigprocmask() to use of
sigprocmask()") had several problems. The more obvious compile issues
got fixed in commit 0f44fbd297e1 ("alpha: fix compile problem in
arch/alpha/kernel/signal.c"), but it also caused a regression.
Since _BLOCKABLE is already the set of signals that can be blocked, the
code should do "newmask & _BLOCKABLE" rather than inverting _BLOCKABLE
before masking.
Reported-by: Michael Cree <mcree@orcon.net.nz> Patch-by: Al Viro <viro@zeniv.linux.org.uk> Patch-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Enhanced Retransmission Mode(ERTM) is a realiable mode of operation
of the Bluetooth L2CAP layer. Think on it like a simplified version of
TCP.
The problem we were facing here was a deadlock. ERTM uses a backlog
queue to queue incomimg packets while the user is helding the lock. At
some moment the sk_sndbuf can be exceeded and we can't alloc new skbs
then the code sleep with the lock to wait for memory, that stalls the
ERTM connection once we can't read the acknowledgements packets in the
backlog queue to free memory and make the allocation of outcoming skb
successful.
This patch actually affect all users of bt_skb_send_alloc(), i.e., all
L2CAP modes and SCO.
We are safe against socket states changes or channels deletion while the
we are sleeping wait memory. Checking for the sk->sk_err and
sk->sk_shutdown make the code safe, since any action that can leave the
socket or the channel in a not usable state set one of the struct
members at least. Then we can check both of them when getting the lock
again and return with the proper error if something unexpected happens.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
Bluetooth: Fix inconsistent lock state with RFCOMM
When receiving a rfcomm connection with the old dund deamon a
inconsistent lock state happens. That's because interrupts were already
disabled by l2cap_conn_start() when rfcomm_sk_state_change() try to lock
the spin_lock.
As result we may have a inconsistent lock state for l2cap_conn_start()
after rfcomm_sk_state_change() calls bh_lock_sock() and disable interrupts
as well.
As we don't have any error control on the Streaming mode, i.e., we don't
need to keep a copy of the skb for later resending we don't need to
call skb_clone() on it.
Then we can go one further here, and dequeue the skb before sending it,
that also means we don't need to look to sk->sk_send_head anymore.
The patch saves memory and time when sending Streaming mode data, so
it is good to mainline.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
When receiving L2CAP negative configuration response with respect
to MTU parameter we modify wrong field. MTU here means proposed
value of MTU that the remote device intends to transmit. So for local
L2CAP socket it is pi->imtu.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Acked-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Mat Martineau [Tue, 24 Aug 2010 22:35:42 +0000 (15:35 -0700)]
Bluetooth: Only enable L2CAP FCS for ERTM or streaming
This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16
with L2CAP modes other than ERTM or streaming. At present, this only
affects the FCS value shown with getsockopt() for basic mode.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
The i810 and i830 device drivers may replace their file operations
on an open file descriptor. My previous patch to move the BKL
out of the common DRM code into these drivers only caught the
default file operations, not the ones that actually end up being
used.
Found while trying to come up with a way to kill the BKL for
good in these drivers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
um: Proper Fix for f25c80a4: remove duplicate structure field initialization
uml_net_set_mac() was broken and luckily it was never used, before.
What it was trying to do is spin_lock before memcopy the mac address.
Linus attempted to fix it in assumption that someone decided the
lock was needed. But since it was never ever used at all, and was
just dead code, I think we can assume that it is not needed, after
all.
On the other hand patch [f25c80a4] was trying to use eth_mac_addr()
in eth_configure(), *which was the real fallout*. Because of state
checks done inside eth_mac_addr() the address was never set. I have
not reintroduced the memcpy wrapper, but I've put a comment for future
cats.
The code now is back to exactly as it was before [f25c80a4]. With
the cleanup applied. If the spin_lock is indeed needed then a contender
should supply a test case that fails, then fix it with the proper
locking, as a separate unrelated patch.
CC: Julia Lawall <julia@diku.dk> CC: David S. Miller <davem@davemloft.net> CC: Andrew Morton <akpm@linux-foundation.org> CC: Al Viro <viro@ZenIV.linux.org.uk> Tested-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx:
dmaengine: fix interrupt clearing for mv_xor
missing inline keyword for static function in linux/dmaengine.h
dma/shdma: move dereference below the NULL check
Joel Becker [Thu, 30 Sep 2010 00:33:05 +0000 (17:33 -0700)]
ocfs2: Don't walk off the end of fast symlinks.
ocfs2 fast symlinks are NUL terminated strings stored inline in the
inode data area. However, disk corruption or a local attacker could, in
theory, remove that NUL. Because we're using strlen() (my fault,
introduced in a731d1 when removing vfs_follow_link()), we could walk off
the end of that string.
Signed-off-by: Joel Becker <joel.becker@oracle.com> Cc: stable@kernel.org
...the following patch fixes it and seems to be the obviously correct
thing to do for cifs.
Cc: stable@kernel.org Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
ACPI, APEI, Fix ERST MOVE_DATA instruction implementation
The src_base and dst_base fields in apei_exec_context are physical
address, so they should be ioremaped before being used in ERST
MOVE_DATA instruction.
Reported-by: Javier Martinez Canillas <martinez.javier@gmail.com> Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Luis Henriques [Wed, 7 Jul 2010 18:30:15 +0000 (19:30 +0100)]
ACPI: fan: Fix more unbalanced code block
commit 934231de706d2579fae14f5857fcd8de991009ff fixes an unbalanced
CONFIG_ACPI_PROCFS code block during module initialisation. This
patch fixes similar issue but for the module exit.
Signed-off-by: Luis Henriques <luis.henrix@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
In ERST debug/test support patch, a dynamic allocated buffer is
used. The may-failed memory allocation should be tried firstly before
free the previous buffer.
APEI resource management memory allocation related error path is fixed
too.
v2:
- Fix error messages for APEI resources management
Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Jin Dongming [Wed, 29 Sep 2010 11:53:53 +0000 (19:53 +0800)]
ACPI, APEI, HEST Fix the unsuitable usage of platform_data
platform_data in hest_parse_ghes() is used for saving the address of entry
information of erst_tab. When the device is failed to be added, platform_data
will be freed by platform_device_put(). But the value saved in platform_data
should not be freed here. If it is done, it will make system panic.
So I think platform_data should save the address of allocated memory
which saves entry information of erst_tab.
This patch fixed it and I confirmed it on x86_64 next-tree.
v2:
Transport the pointer of hest_hdr to platform_data using
platform_device_add_data()
Signed-off-by: Jin Dongming <jin.dongming@np.css.fujitsu.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Jin Dongming [Wed, 29 Sep 2010 11:53:52 +0000 (19:53 +0800)]
ACPI, APEI, Fix acpi_pre_map() return value
After we ioremap() a new region, we call __acpi_try_ioremap() to
see whether another thread has already mapped the same region.
This check clobbers "vaddr", so compute the return value of
acpi_pre_map() using the ioremap() result "map->vaddr" instead.
v2:
Modified the unsuitable description of patch.
v3:
Removed unlikely() check and made description simpler.
Signed-off-by: Jin Dongming <jin.dongming@np.css.fujitsu.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Dave Chinner [Fri, 24 Sep 2010 08:13:44 +0000 (18:13 +1000)]
xfs: force background CIL push under sustained load
I have been seeing occasional pauses in transaction throughput up to
30s long under heavy parallel workloads. The only notable thing was
that the xfsaild was trying to be active during the pauses, but
making no progress. It was running exactly 20 times a second (on the
50ms no-progress backoff), and the number of pushbuf events was
constant across this time as well. IOWs, the xfsaild appeared to be
stuck on buffers that it could not push out.
Further investigation indicated that it was trying to push out inode
buffers that were pinned and/or locked. The xfsbufd was also getting
woken at the same frequency (by the xfsaild, no doubt) to push out
delayed write buffers. The xfsbufd was not making any progress
because all the buffers in the delwri queue were pinned. This scan-
and-make-no-progress dance went one in the trace for some seconds,
before the xfssyncd came along an issued a log force, and then
things started going again.
However, I noticed something strange about the log force - there
were way too many IO's issued. 516 log buffers were written, to be
exact. That added up to 129MB of log IO, which got me very
interested because it's almost exactly 25% of the size of the log.
He delayed logging code is suppose to aggregate the minimum of 25%
of the log or 8MB worth of changes before flushing. That's what
really puzzled me - why did a log force write 129MB instead of only
8MB?
Essentially what has happened is that no CIL pushes had occurred
since the previous tail push which cleared out 25% of the log space.
That caused all the new transactions to block because there wasn't
log space for them, but they kick the xfsaild to push the tail.
However, the xfsaild was not making progress because there were
buffers it could not lock and flush, and the xfsbufd could not flush
them because they were pinned. As a result, both the xfsaild and the
xfsbufd could not move the tail of the log forward without the CIL
first committing.
The cause of the problem was that the background CIL push, which
should happen when 8MB of aggregated changes have been committed, is
being held off by the concurrent transaction commit load. The
background push does a down_write_trylock() which will fail if there
is a concurrent transaction commit holding the push lock in read
mode. With 8 CPUs all doing transactions as fast as they can, there
was enough concurrent transaction commits to hold off the background
push until tail-pushing could no longer free log space, and the halt
would occur.
It should be noted that there is no reason why it would halt at 25%
of log space used by a single CIL checkpoint. This bug could
definitely violate the "no transaction should be larger than half
the log" requirement and hence result in corruption if the system
crashed under heavy load. This sort of bug is exactly the reason why
delayed logging was tagged as experimental....
The fix is to start blocking background pushes once the threshold
has been exceeded. Rework the threshold calculations to keep the
amount of log space a CIL checkpoint can use to below that of the
AIL push threshold to avoid the problem completely.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Alex Elder <aelder@sgi.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Kevin Liu [Wed, 8 Sep 2010 13:44:36 +0000 (09:44 -0400)]
mfd: Fix max8925 irq control bit incorrect setting
In max8925_irq_sync_unlock(), irq control bit is set at the same time.
Zero means enabling irq, and one means disabling irq.
The original code is:
irq_chg[0] &= irq_data->enable;
It should be changed to:
irq_chg[0] &= ~irq_data->enable;
Otherwise, irq control bit is mess.
Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Mark Brown [Mon, 16 Aug 2010 19:26:51 +0000 (20:26 +0100)]
mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types
The driver was originally tested with an additional patch which
made this unneeded but that patch had issuges and got lost on the
way to mainline, causing problems when the errors are reported.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Cc: stable@kernel.org
David S. Miller [Wed, 29 Sep 2010 05:37:56 +0000 (22:37 -0700)]
ip_gre: Fix dependencies wrt. ipv6.
The GRE tunnel driver needs to invoke icmpv6 helpers in the
ipv6 stack when ipv6 support is enabled.
Therefore if IPV6 is enabled, we have to enforce that GRE's
enabling (modular or static) matches that of ipv6.
Reported-by: Patrick McHardy <kaber@trash.net> Reported-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhang Rui [Mon, 30 Aug 2010 06:08:02 +0000 (14:08 +0800)]
ACPI: fix build warnings resulting from merge window conflict
drivers/acpi/sysfs.c:154: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
David Howells [Wed, 29 Sep 2010 00:57:02 +0000 (01:57 +0100)]
MN10300: Handle missing sys_cacheflush() when caching disabled
When caching is disabled on the MN10300 arch, the sys_cacheflush()
function is removed by conditional stuff in the makefiles, but is still
referred to by the syscall table.
Provide a null version that just returns 0 when caching is disabled (or
-EINVAL if the arguments are silly).
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
net-2.6: SYN retransmits: Add new parameter to retransmits_timed_out()
Fixes kernel Bugzilla Bug 18952
This patch adds a syn_set parameter to the retransmits_timed_out()
routine and updates its callers. If not set, TCP_RTO_MIN is taken
as the calculation basis as before. If set, TCP_TIMEOUT_INIT is
used instead, so that sysctl_syn_retries represents the actual
amount of SYN retransmissions in case no SYNACKs are received when
establishing a new connection.
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Colin Ian King [Mon, 2 Aug 2010 15:14:43 +0000 (15:14 +0000)]
ACPI: enable repeated PCIEXP wakeup by clearing PCIEXP_WAKE_STS on resume
Section 4.7.3.1.1 (PM1 Status Registers) of version 4.0 of
the ACPI spec concerning PCIEXP_WAKE_STS points out in
in the final note field in table 4-11 that if this bit is
set to 1 and the system is put into a sleeping state then
the system will not automatically wake.
This bit gets set by hardware to indicate that the system
woke up due to a PCI Express wakeup event, so clear it during
acpi_hw_clear_acpi_status() calls to enable subsequent
resumes to work.
BugLink: http://bugs.launchpad.net/bugs/613381 Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Len Brown <len.brown@intel.com>
Dan Rosenberg [Tue, 28 Sep 2010 18:18:20 +0000 (14:18 -0400)]
ALSA: prevent heap corruption in snd_ctl_new()
The snd_ctl_new() function in sound/core/control.c allocates space for a
snd_kcontrol struct by performing arithmetic operations on a
user-provided size without checking for integer overflow. If a user
provides a large enough size, an overflow will occur, the allocated
chunk will be too small, and a second user-influenced value will be
written repeatedly past the bounds of this chunk. This code is
reachable by unprivileged users who have permission to open
a /dev/snd/controlC* device (on many distros, this is group "audio") via
the SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE ioctls.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
iwl3945: queue the right work if the scan needs to be aborted
iwl3945's scan_completed calls into the mac80211 stack which triggers a
warn on if there is no scan outstanding.
This can be avoided by not calling scan_completed but abort_scan in
iwl3945_request_scan in the done: branch of the function which is used
as an error out.
The done: branch seems to be an error-out branch, as, for example, if
iwl_is_ready(priv) returns false the done: branch is executed.
NOTE:
I'm not familiar with the driver at all.
I just quickly scanned as a reaction to
https://bugzilla.kernel.org/show_bug.cgi?id=17722
the users of scan_completed in the iwl3945 driver and noted the odd
discrepancy between the comment above this instance and the comment in
mac80211 scan_completed function.
Signed-off-by: Florian Mickler <florian@mickler.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ahci: fix module refcount breakage introduced by libahci split
libata depends on scsi_host_template for module reference counting and
sht's should be owned by each low level driver. During libahci split,
the sht was left with libahci.ko leaving the actual low level drivers
not reference counted. This made ahci and ahci_platform always
unloadable even while they're being actively used.
Fix it by defining AHCI_SHT() macro in ahci.h and defining a sht for
each low level ahci driver.
stable: only applicable to 2.6.35.
Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Pedro Francisco <pedrogfrancisco@gmail.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Cc: stable@kernel.org Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (47 commits)
tcp: Fix >4GB writes on 64-bit.
net/9p: Mount only matching virtio channels
de2104x: fix ethtool
tproxy: check for transparent flag in ip_route_newports
ipv6: add IPv6 to neighbour table overflow warning
tcp: fix TSO FACK loss marking in tcp_mark_head_lost
3c59x: fix regression from patch "Add ethtool WOL support"
ipv6: add a missing unregister_pernet_subsys call
s390: use free_netdev(netdev) instead of kfree()
sgiseeq: use free_netdev(netdev) instead of kfree()
rionet: use free_netdev(netdev) instead of kfree()
ibm_newemac: use free_netdev(netdev) instead of kfree()
smsc911x: Add MODULE_ALIAS()
net: reset skb queue mapping when rx'ing over tunnel
br2684: fix scheduling while atomic
de2104x: fix TP link detection
de2104x: fix power management
de2104x: disable autonegotiation on broken hardware
net: fix a lockdep splat
e1000e: 82579 do not gate auto config of PHY by hardware during nominal use
...
This fix is only a workaround. For a real fix, cpu_sibling_mask() should
be defined in UP include code, eg in linux/smp.h, and asm/smp.h should not be
included directly. This fix is currently not possible because asm/smp.h defines
cpu_sibling_mask() unconditionally and is included directly from many source
files.
Merge branch 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: Avoid 'constant_test_bit()' misoptimization due to cast to non-volatile
David S. Miller [Tue, 28 Sep 2010 03:24:54 +0000 (20:24 -0700)]
tcp: Fix >4GB writes on 64-bit.
Fixes kernel bugzilla #16603
tcp_sendmsg() truncates iov_len to an 'int' which a 4GB write to write
zero bytes, for example.
There is also the problem higher up of how verify_iovec() works. It
wants to prevent the total length from looking like an error return
value.
However it does this using 'int', but syscalls return 'long' (and
thus signed 64-bit on 64-bit machines). So it could trigger
false-positives on 64-bit as written. So fix it to use 'long'.
Reported-by: Olaf Bonorden <bono@onlinehome.de> Reported-by: Daniel Büse <dbuese@gmx.de> Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Rosenberg [Mon, 27 Sep 2010 16:30:28 +0000 (12:30 -0400)]
Fix pktcdvd ioctl dev_minor range check
The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a
pktcdvd_device from the global pkt_devs array. The index into this
array is provided directly by the user and is a signed integer, so the
comparison to ensure that it falls within the bounds of this array will
fail when provided with a negative index.
This can be used to read arbitrary kernel memory or cause a crash due to
an invalid pointer dereference. This can be exploited by users with
permission to open /dev/pktcdvd/control (on many distributions, this is
readable by group "cdrom").
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
[ Rather than add a cast, just make the function take the right type -Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David Howells [Mon, 27 Sep 2010 12:12:33 +0000 (13:12 +0100)]
MN10300: Default config choice GDBSTUB_TTYSM0 should be GDBSTUB_ON_TTYSM0
The configuration choice for the port on which the GDB stub listens has
a default of GDBSTUB_TTYSM0, but this should be GDBSTUB_ON_TTYSM0 to
match the option.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alex Deucher [Mon, 27 Sep 2010 15:33:00 +0000 (11:33 -0400)]
drm/radeon/kms: add quirk for MSI K9A2GM motherboard
Board has no digital connectors
Reported-by: Andy Walls <awalls@md.metrocast.net> Tested-by: Andy Walls <awalls@md.metrocast.net> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Mon, 27 Sep 2010 14:57:10 +0000 (10:57 -0400)]
drm/radeon/kms: fix potential segfault in r600_ioctl_wait_idle
radeon_gem_wait_idle_ioctl can apparently get called prior to
the vram page being set up or even if accel if false, so make
sure it's valid before using it.
Should fix:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597636
https://bugs.freedesktop.org/show_bug.cgi?id=29834
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
Chris Wilson [Mon, 27 Sep 2010 20:28:30 +0000 (21:28 +0100)]
drm: Prune GEM vma entries
Hook the GEM vm open/close ops into the generic drm vm open/close so
that the private vma entries are created and destroy appropriately.
Fixes the leak of the drm_vma_entries during the lifetime of the filp.
Reported-by: Matt Mackall <mpm@selenic.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
Jon Povey [Fri, 17 Sep 2010 03:02:11 +0000 (12:02 +0900)]
i2c-davinci: Fix race when setting up for TX
When setting up to transmit, a race exists between the ISR and
i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
This is mostly visible for transmits > 1 byte long.
The hardware starts sending immediately that MDR is loaded. IMR trickery
doesn't work because if we start sending, finish the first byte and an
XRDY event occurs before we load IMR to unmask it, we never get an
interrupt, and we timeout.
Move the MDR load after DXR,IMR loads to avoid this race without locking.
Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Sven Eckelmann [Mon, 27 Sep 2010 22:54:44 +0000 (15:54 -0700)]
net/9p: Mount only matching virtio channels
p9_virtio_create will only compare the the channel's tag characters
against the device name till the end of the channel's tag but not till
the end of the device name. This means that if a user defines channels
with the tags foo and foobar then he would mount foo when he requested
foonot and may mount foo when he requested foobar.
Thus it is necessary to check both string lengths against each other in
case of a successful partial string match.
Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Ondrej Zary [Mon, 27 Sep 2010 11:41:45 +0000 (11:41 +0000)]
de2104x: fix ethtool
When the interface is up, using ethtool breaks it because:
a) link is put down but media_timer interval is not shortened to NO_LINK
b) rxtx is stopped but not restarted
Also manual 10baseT-HD (and probably FD too - untested) mode does not work -
the link is forced up, packets are transmitted but nothing is received.
Changing CSR14 value to match documentation (not disabling link check) fixes this.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bernhard Walle [Mon, 27 Sep 2010 10:55:16 +0000 (12:55 +0200)]
i2c-octeon: Return -ETIMEDOUT in octeon_i2c_wait() on timeout
It doesn't make sense to set result to -ETIMEDOUT but return 0 (success)
afterwards. Since there's code in octeon_i2c_start() to handle the
error, it should be called.
Signed-off-by: Bernhard Walle <walle@corscience.de> Acked-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
tcp: fix TSO FACK loss marking in tcp_mark_head_lost
When TCP uses FACK algorithm to mark lost packets in
tcp_mark_head_lost(), if the number of packets in the (TSO) skb is
greater than the number of packets that should be marked lost, TCP
incorrectly exits the loop and marks no packets lost in the skb. This
underestimates tp->lost_out and affects the recovery/retransmission.
This patch fargments the skb and marks the correct amount of packets
lost.
Signed-off-by: Yuchung Cheng <ycheng@google.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
* master.kernel.org:/home/rmk/linux-2.6-arm: (28 commits)
ARM: 6411/1: vexpress: set RAM latencies to 1 cycle for PL310 on ct-ca9x4 tile
ARM: 6409/1: davinci: map sram using MT_MEMORY_NONCACHED instead of MT_DEVICE
ARM: 6408/1: omap: Map only available sram memory
ARM: 6407/1: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries
ARM: pxa: remove pr_<level> uses of KERN_<level>
ARM: pxa168fb: clear enable bit when not active
ARM: pxa: fix cpu_is_pxa*() not expanding to zero when not configured
ARM: pxa168: fix corrected reset vector
ARM: pxa: Use PIO for PI2C communication on Palm27x
ARM: pxa: Fix Vpac270 gpio_power for MMC
ARM: 6401/1: plug a race in the alignment trap handler
ARM: 6406/1: at91sam9g45: fix i2c bus speed
leds: leds-ns2: fix locking
ARM: dove: fix __io() definition to use bus based offset
dmaengine: fix interrupt clearing for mv_xor
ARM: kirkwood: Unbreak PCIe I/O port
ARM: Fix build error when using KCONFIG_CONFIG
ARM: 6383/1: Implement phys_mem_access_prot() to avoid attributes aliasing
ARM: 6400/1: at91: fix arch_gettimeoffset fallout
ARM: 6398/1: add proc info for ARM11MPCore/Cortex-A9 from ARM
...