The gcov-kernel infrastructure expects that each object file is loaded
only once. This may not be true, e.g. when loading multiple kernel
modules which are linked to the same object file. As a result, loading
such kernel modules will result in incorrect gcov results while unloading
will cause a null-pointer dereference.
This patch fixes these problems by changing the gcov-kernel infrastructure
so that multiple profiling data sets can be associated with one debugfs
entry. It applies to 2.6.36-rc1.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Reported-by: Werner Spies <werner.spies@thalesgroup.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
commit c2c6ca4 (direct-io: do not merge logically non-contiguous requests)
introduced a bug whereby all O_DIRECT I/Os were submitted a page at a time
to the block layer. The problem is that the code expected
dio->block_in_file to correspond to the current page in the dio. In fact,
it corresponds to the previous page submitted via submit_page_section.
This was purely an oversight, as the dio->cur_page_fs_offset field was
introduced for just this purpose. This patch simply uses the correct
variable when calculating whether there is a mismatch between contiguous
logical blocks and contiguous physical blocks (as described in the
comments).
I also switched the if conditional following this check to an else if, to
ensure that we never call dio_bio_submit twice for the same dio (in
theory, this should not happen, anyway).
I've tested this by running blktrace and verifying that a 64KB I/O was
submitted as a single I/O. I also ran the patched kernel through
xfstests' aio tests using xfs, ext4 (with 1k and 4k block sizes) and btrfs
and verified that there were no regressions as compared to an unpatched
kernel.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Acked-by: Josef Bacik <jbacik@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: <stable@kernel.org> [2.6.35.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Much (but not all) of the RTC state is kept in the RTC peripheral which
has its own power domain. Periodically (1 HZ), that state is synced from
one power domain to the other (peripheral->core). When we are resuming,
we need to wait for the sync to occur so that we don't get a mismatch of
reading undefined state in the rest of the driver.
Further, once the externally maintained bits have been synced back into
the core, we then need to restore the bits maintained in the core. In our
particular case, that is just the write completion interrupt bit.
If we don't do any of this, working with the RTC causes ~5 second delays
from time to time after waking up due to the write completion interrupt
never firing.
Reported-by: Michael Dean <mdean@aeronix.com>
Reported-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The int_clear helper takes a bitmask of interrupts to keep, not to
disable. When suspending without wakeup enabled, we want to disable
all interrupts, so use 0 (keep none) instead of -1 (keep all).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The introduction of support for SD combo cards breaks the initialization
of all CSR SDIO chips. The GO_IDLE (CMD0) in mmc_sd_get_cid() causes CSR
chips to be reset (this is non-standard behavior).
When initializing an SDIO card check for a combo card by using the memory
present bit in the R4 response to IO_SEND_OP_COND (CMD5). This avoids the
call to mmc_sd_get_cid() on an SDIO-only card.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Acked-by: Michal Mirolaw <mirq-linux@rere.qmqm.pl>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* master.kernel.org:/home/rmk/linux-2.6-arm: (30 commits)
ARM: Update mach-types
ARM: Partially revert "Auto calculate ZRELADDR and provide option for exceptions"
ARM: Ensure PTE modifications via dma_alloc_coherent are visible
ARM: 6359/1: ep93xx: move clock initialization earlier
Revert "[ARM] pxa: remove now unnecessary dma_needs_bounce()"
ARM: 6352/1: perf: fix event validation
ARM: 6344/1: Mark CPU_32v6K as depended on CPU_V7
ARM: 6343/1: wire up fanotify and prlimit64 syscalls on ARM
ARM: 6330/1: perf: reword comments relating to perf_event_do_pending
ARM: pxa168fb: fix section mismatch
ARM: pxa: Make id const in pwm_probe()
ARM: pxa: fix CI_HSYNC and CI_VSYNC MFP defines for pxa300
ARM: pxa: remove __init from cpufreq_driver->init()
ARM: imx: set cache line size to 64 bytes for i.MX5
mx5/clock: fix clear bit fields issue in _clk_ccgr_disable function
mxc/tzic: add base address when accessing TZIC registers
ARM: mach-shmobile: ap4evb: fix write protect for SDHI1
ARM: mach-shmobile: ap4evb: modify FSI2 ID
ARM: mach-shmobile: do not enable the PLLC2 clock on init
ARM: mach-shmobile: Clock framework comment fix
...
Partially revert e69edc7, which introduced automatic zreladdr
support. The change in the way the manual definition is defined
seems to be error and conflict prone. Go back to the original way
we were handling this for the time being, while keeping the automatic
zreladdr facility.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
lg_lock_global() currently only acquires spinlocks for online CPUs, but
it's meant to lock all possible CPUs. Lglock-protected resources may be
associated with removed CPUs - and, indeed, that could happen with the
per-superblock open files lists.
At Nick's suggestion, change for_each_online_cpu() to
for_each_possible_cpu() to protect accesses to those resources.
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Acked-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
RDMA/nes: Fix hang with modified FIN handling on A0 cards
RDMA/nes: Change state to closing after FIN
RDMA/nes: Fix double CLOSE event indication crash
RDMA/nes: Write correct register write to set TX pause param
RDMA/cxgb3: Don't exceed the max HW CQ depth
* 'fixes' of git://oss.oracle.com/git/tma/linux-2.6:
ocfs2: Fix orphan add in ocfs2_create_inode_in_orphan
ocfs2: split out ocfs2_prepare_orphan_dir() into locking and prep functions
ocfs2: allow return of new inode block location before allocation of the inode
ocfs2: use ocfs2_alloc_dinode_update_counts() instead of open coding
ocfs2: split out inode alloc code from ocfs2_mknod_locked
Ocfs2: Fix a regression bug from mainline commit(6b933c8e6f).
ocfs2: Fix deadlock when allocating page
ocfs2: properly set and use inode group alloc hint
ocfs2: Use the right group in nfs sync check.
ocfs2: Flush drive's caches on fdatasync
ocfs2: make __ocfs2_page_mkwrite handle file end properly.
ocfs2: Fix incorrect checksum validation error
ocfs2: Fix metaecc error messages
Changing state to CLOSING when FIN is received causes A0 cards to
hang. Fix this by checking for A0 cards in FIN handling.
Signed-off-by: Faisal Latif <faisal.latif@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
When the driver receives an AE for FIN received, it closes the
connection without changing the state of the connection in the
hardware to closing. By changing the state to closing, hardware will
do a normal close sequence.
Signed-off-by: Faisal Latif <faisal.latif@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
During a stress testing in a large cluster, multiple close event are
detected and BUG() is hit in the iWARP core. The cause is that the
active node gave up while waiting for an MPA response from the peer
and tried to close the connection by sending RST. The passive node
driver receives the RST but is waiting for MPA response from the user.
When the MPA accept is received, the driver offloads the connection
and sends a CLOSE event. The driver gets an AE indicating RESET
received and also sends a CLOSE event, hitting a BUG().
Fix this by correcting RESET handling and sending CLOSE events.
Signed-off-by: Faisal Latif <faisal.latif@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>