We should disable irqs when we take the tu->qlock because it is used in
the irq handler. The only place that doesn't is
snd_timer_user_ccallback(). Most of the time snd_timer_user_ccallback()
is called with interrupts disabled but the the first ti->ccallback()
call in snd_timer_notify1() has interrupts enabled.
This was caught by lockdep which generates the following message:
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.34-rc5 #5
> ---------------------------------
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> dolphin/4003 [HC1[1]:SC0[0]:HE0:SE1] takes:
> (&(&tu->qlock)->rlock){?.+...}, at: [<f84ec472>] snd_timer_user_tinterrupt+0x28/0x132 [snd_timer]
> {HARDIRQ-ON-W} state was registered at:
> [<c1048de9>] __lock_acquire+0x654/0x1482
> [<c1049c73>] lock_acquire+0x5c/0x73
> [<c125ac3e>] _raw_spin_lock+0x25/0x34
> [<f84ec370>] snd_timer_user_ccallback+0x55/0x95 [snd_timer]
> [<f84ecc4b>] snd_timer_notify1+0x53/0xca [snd_timer]
Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix memory corruption that sometimes result in kernel panic.
Signed-off-by: Mattias Walström <mattias@vmlinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
BugLink: https://launchpad.net/bugs/549267
The OR verified that using the olpc-xo-1_5 model quirk allows the
headphones to be audible when inserted into the jack. Capture was
also verified to work correctly.
Reported-by: Richard Gagne
Tested-by: Richard Gagne
Cc: <stable@kernel.org>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
BugLink: https://launchpad.net/bugs/573284
The OR verified that using the olpc-xo-1_5 model quirk allows the
headphones to be audible when inserted into the jack. Capture was
also verified to work correctly.
Reported-by: Andy Couldrake <acouldrake@googlemail.com>
Tested-by: Andy Couldrake <acouldrake@googlemail.com>
Cc: <stable@kernel.org>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This fixes a problem where cards show up as only having a single mixer
element, suppressing all sound output.
Signed-off-by: Brian J. Tarricone <brian@tarricone.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms/legacy: only enable load detection property on DVI-I
drm/radeon/kms: fix panel scaling adjusted mode setup
drivers/gpu/drm/drm_sysfs.c: sysfs files error handling
drivers/gpu/drm/radeon/radeon_atombios.c: range check issues
gpu: vga_switcheroo, fix lock imbalance
drivers/gpu/drm/drm_memory.c: fix check for end of loop
drivers/gpu/drm/via/via_video.c: fix off by one issue
drm/radeon/kms/agp The wrong AGP chipset can cause a NULL pointer dereference
drm/radeon/kms: r300 fix CS checker to allow zbuffer-only fastfill
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip:
powernow-k8: Fix frequency reporting
x86: Fix parse_reservetop() build failure on certain configs
x86: Fix NULL pointer access in irq_force_complete_move() for Xen guests
x86: Fix 'reservetop=' functionality
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
KEYS: Fix RCU handling in key_gc_keyring()
KEYS: Fix an RCU warning in the reading of user keys
key_gc_keyring() needs to either hold the RCU read lock or hold the keyring
semaphore if it's going to scan the keyring's list. Given that it only needs
to read the key list, and it's doing so under a spinlock, the RCU read lock is
the thing to use.
Furthermore, the RCU check added in e7b0a61b7929632d36cf052d9e2820ef0a9c1bfe is
incorrect as holding the spinlock on key_serial_lock is not grounds for
assuming a keyring's pointer list can be read safely. Instead, a simple
rcu_dereference() inside of the previously mentioned RCU read lock is what we
want.
Reported-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
DVI-D doesn't have analog. This matches the avivo behavior.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This should duplicate exactly what the ddx does for both
legacy and avivo.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2:
ocfs2: Avoid a gcc warning in ocfs2_wipe_inode().
ocfs2: Avoid direct write if we fall back to buffered I/O
ocfs2_dlmfs: Fix math error when reading LVB.
ocfs2: Update VFS inode's id info after reflink.
ocfs2: potential ERR_PTR dereference on error paths
ocfs2: Add directory entry later in ocfs2_symlink() and ocfs2_mknod()
ocfs2: use OCFS2_INODE_SKIP_ORPHAN_DIR in ocfs2_mknod error path
ocfs2: use OCFS2_INODE_SKIP_ORPHAN_DIR in ocfs2_symlink error path
ocfs2: add OCFS2_INODE_SKIP_ORPHAN_DIR flag and honor it in the inode wipe code
ocfs2: Reset status if we want to restart file extension.
ocfs2: Compute metaecc for superblocks during online resize.
ocfs2: Check the owner of a lockres inside the spinlock
ocfs2: one more warning fix in ocfs2_file_aio_write(), v2
ocfs2_dlmfs: User DLM_* when decoding file open flags.
The x86_64 call_rwsem_wait() treats the active state counter part of the
R/W semaphore state as being 16-bit when it's actually 32-bit (it's half
of the 64-bit state). It should do "decl %edx" not "decw %dx".
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
i2c-core: Use per-adapter userspace device lists
i2c: Fix probing of FSC hardware monitoring chips
i2c-core: Erase pointer to clientdata on removal
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
perf: Fix resource leak in failure path of perf_event_open()
* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
rcu: Fix RCU lockdep splat on freezer_fork path
rcu: Fix RCU lockdep splat in set_task_cpu on fork path
mutex: Don't spin when the owner CPU is offline or other weird cases
These are needed for mounting root on MMC on many boards.
Also disable CONFIG_WATCHDOG_NOWAYOUT, that can keep the
system from running with external watchdogs.
Signed-off-by: Tony Lindgren <tony@atomide.com>
The bootloader on Nokia boards does not support updating
the kernel cmdline. For the other boards, the bootloader
provided cmdline will be used instead.
To mount root on n8x0, compile in also the MMC_OMAP.
It seems that the best way to mount root with the
new kernels on Nokia boards is to mount root on mmcblk0p2.
Note that n8x0 current has several issues booting with
omap3_defconfig: The bootloader has a 2MB limit for loading
kernels, so you may want to use kexec. Also ARMv6 does
not currently work with ARMv7 for VFP and TLS.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We cannot use the omap34xx_sram_init(). It needs to be implemented
for omap4. Otherwise we get an error and the system won't boot:
Unhandled fault: imprecise external abort (0x1406) at 0xea963e94
...
Fix this by adding a dummy omap44xx_sram_init().
Signed-off-by: Tony Lindgren <tony@atomide.com>
These are currently non-muxable, so let's save some memory
and remove them. Otherwise we get the following warnings:
mux: Unknown ball offset 0x5e
mux: Unknown ball offset 0x60
mux: Unknown ball offset 0x62
...
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise we can get the following error:
error: variable 'tdo24m_mcspi_config' has initializer but incomplete type
...
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit 04de0816 (pcmcia: pcmcia_dev_present bugfix) broke the
deprecated ioctl layer. Fix it by getting rid of references to
unexisting fields.
Signed-off-by: Marc Zyngier <maz@misterjones.org>
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Assert that userspace suspend and resume requests appearing
(almost) immediately are executed in the following order:
suspend, resume. This should result in "pccardctl reset"
behaving the same as before.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
The show_mem() and mem_init() function are assuming that the page map is
contiguous and calculates the start and end page of a bank using (map +
pfn). This fails with SPARSEMEM where pfn_to_page() must be used.
Tested-by: Will Deacon <Will.Deacon@arm.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch fixes task_in_mem_cgroup(), mem_cgroup_uncharge_swapcache(),
mem_cgroup_move_swap_account(), and is_target_pte_for_mc() to protect
calls to css_id(). An additional RCU lockdep splat was reported for
memcg_oom_wake_function(), however, this function is not yet in
mainline as of 2.6.34-rc5.
Reported-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Tested-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Expand task_subsys_state()'s rcu_dereference_check() to include the full
locking rule as documented in Documentation/cgroups/cgroups.txt by adding
a check for task->alloc_lock being held.
This fixes an RCU false positive when resuming from suspend. The warning
comes from freezer cgroup in cgroup_freezing_or_frozen().
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Matt Helsley <matthltc@us.ibm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
With CONFIG_PROVE_RCU=y, a warning can be triggered:
$ cat /proc/sched_debug
...
kernel/cgroup.c:1649 invoked rcu_dereference_check() without protection!
...
Both cgroup_path() and task_group() should be called with either
rcu_read_lock or cgroup_mutex held.
The rcu_dereference_check() does include cgroup_lock_is_held(), so we
know that this lock is not held. Therefore, in a CONFIG_PREEMPT kernel,
to say nothing of a CONFIG_PREEMPT_RT kernel, the original code could
have ended up copying a string out of the freelist.
This patch inserts RCU read-side primitives needed to prevent this
scenario.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
With CONFIG_PROVE_RCU=y, a warning can be triggered:
# mount -t cgroup -o memory xxx /mnt
# mkdir /mnt/0
...
kernel/cgroup.c:4442 invoked rcu_dereference_check() without protection!
...
This is a false-positive. It's safe to directly access parent_css->id.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
with CONFIG_PROVE_RCU=y, a warning can be triggered:
# mount -t cgroup -o debug xxx /mnt
# cat /proc/$$/cgroup
...
kernel/cgroup.c:1649 invoked rcu_dereference_check() without protection!
...
This is a false-positive, because cgroup_path() can be called
with either rcu_read_lock() held or cgroup_mutex held.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Fix an RCU warning in the reading of user keys:
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
security/keys/user_defined.c:202 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by keyctl/3637:
#0: (&key->sem){+++++.}, at: [<ffffffff811a80ae>] keyctl_read_key+0x9c/0xcf
stack backtrace:
Pid: 3637, comm: keyctl Not tainted 2.6.34-rc5-cachefs #18
Call Trace:
[<ffffffff81051f6c>] lockdep_rcu_dereference+0xaa/0xb2
[<ffffffff811aa55f>] user_read+0x47/0x91
[<ffffffff811a80be>] keyctl_read_key+0xac/0xcf
[<ffffffff811a8a06>] sys_keyctl+0x75/0xb7
[<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Using a single list for all userspace devices leads to a dead lock
on multiplexed buses in some circumstances (mux chip instantiated
from userspace). This is solved by using a separate list for each
bus segment.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Michael Lawnick <ml.lawnick@gmx.de>
Some FSC hardware monitoring chips (Syleus at least) doesn't like
quick writes we typically use to probe for I2C chips. Use a regular
byte read instead for the address they live at (0x73). These are the
only known chips living at this address on PC systems.
For clarity, this fix should not be needed for kernels 2.6.30 and
later, as we started instantiating the hwmon devices explicitly based
on DMI data. Still, this fix is valuable in the following two cases:
* Support for recent FSC chips on older kernels. The DMI-based device
instantiation is more difficult to backport than the device support
itself.
* Case where the DMI-based device instantiation fails, whatever the
reason. We fall back to probing in that case, so it should work.
This fixes kernel bug #15634:
https://bugzilla.kernel.org/show_bug.cgi?id=15634
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@kernel.org
After discovering that a lot of i2c-drivers leave the pointer to their
clientdata dangling, it was decided to let the core handle this issue.
It is assumed that the core may access the private data after remove()
as there are no guarantees for the lifetime of such pointers anyhow (see
thread starting at http://lkml.org/lkml/2010/3/21/68)
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Dance pads don't have an axis, so allow this kind of controllers
to be used via legacy joystick interface.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
As per RFC 3493 the default multicast hops setting
for a socket should be "1" just like ipv4.
Ironically we have a IPV6_DEFAULT_MCASTHOPS macro
it just wasn't being used.
Reported-by: Elliot Hughes <enh@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In older versions of the elantech hardware/firmware those bits always
were unset, so it didn't actually matter, but newer versions seem to
use those high bits for something else, screwing up the coordinates
we report to the input layer for those devices.
Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Apparently hardware vendors now ship elantech touchpads with different version
magic. This options allows for them to be tested easier with the current driver
in order to add their magic to the whitelist later.
Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The check determining whether device should use 4- or 6-byte packets
was trying to compare firmware with 2.48, but was failing on majors
greater than 2. The new check ensures that versions like 4.1 are
checked properly.
Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The (out-of-tree) lirc_atiusb driver has a much longer list of devices
it supports. Some of them look like they may just be guesses at possible
device IDs, but a few are definitely confirmed devices. This adds the
nVidia-branded RF receiver and the X10 Lola Wireless Video Sender device
(which contains an RF receiver) to the list of devices in ati_remote.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Receiving small packet(s) in a fast pace leads to not receiving any
packets at all after some time.
After ethernet packet(s) arrived the receive descriptor is incremented
by the number of frames processed. If another packet arrives while
processing, this is processed in another call of ep93xx_rx. This
second call leads that too many receive descriptors getting released.
This fix increments, even in these case, the right number of processed
receive descriptors.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
gcc warns that a variable is uninitialized. It's actually handled, but
an early return fools gcc. Let's just initialize the variable to a
garbage value that will crash if the usage is ever broken.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Zoom2 and 3 have UARTs only on the external debug board.
GPMC needs to be mapped early to use it for DEBUG_LL.
Additionally, 0xfb000000 overlaps with other areas, so
use 0xfa400000 for the virtual address instead.
Note that with the pending serial.c patches you need to
set console=ttyS0,115200n8 as it will be the only UART
mapped. To use DEBUG_LL, you need to pass also earlyprintk
in cmdline.
Cc: Allen Pais <allen.pais@ti.com>
Acked-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This removes the dependency to the UART1 being available for storing
the debug configuration in uncompress.h. This will simplify the
DEBUG_LL UART configuration for boards that may not have UART1, or
have an external UART as it requires only one mapping for DEBUG_LL.
The patch has a few limitations. Basically now we're assuming that
the kernel uncompress code won't overlap with OMAP_UART_INFO. We also
assume the printascii is called at least once before paging_init in
order for addruart to have a chance to read the UART setup from
OMAP_UART_INFO.
As suggested by Cyril Chemparathy <cyril@ti.com>,
Vikram Pandita <vikram.pandita@ti.com> and
Kevin Hilman <khilman@deeprootsystems.com>. Based on an earlier
patch posted for Davinci by Cyril Chemparathy <cyril@ti.com>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise we'll get an error about get_irqnr_and_base being defined
twice. Add an entry for omap4, and use ARCH_OMAP3 for omap3 instead of
ARCH_OMAP3430.
Also fix the check for omap1 to use ARCH_OMAP2PLUS to avoid having to
add ARCH_OMAP4 separately there.
Signed-off-by: Tony Lindgren <tony@atomide.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
ceph: remove bad auth_x kmem_cache
ceph: fix lockless caps check
ceph: clear dir complete, invalidate dentry on replayed rename
ceph: fix direct io truncate offset
ceph: discard incoming messages with bad seq #
ceph: fix seq counting for skipped messages
ceph: add missing #includes
ceph: fix leaked spinlock during mds reconnect
ceph: print more useful version info on module load
ceph: fix snap realm splits
ceph: clear dir complete on d_move
