Stephen Rothwell [Thu, 24 Nov 2011 23:44:55 +0000 (00:44 +0100)]
Freezer: fix more fallout from the thaw_process rename
Commit 944e192db53c "freezer: rename thaw_process() to __thaw_task()
and simplify the implementation" did not create a !CONFIG_FREEZER version
of __thaw_task().
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Jacek Galowicz [Thu, 24 Nov 2011 23:13:15 +0000 (10:13 +1100)]
lguest: switch segment-voodoo-numbers to readable symbols
When studying lguest's x86 segment descriptor code, it is not longer
necessary to have the Intel x86 architecture manual open on the page
with the segment descriptor illustration to understand the crazy
numbers assigned to both descriptor structure halves a/b.
Now the struct desc_struct's fields, like suggested by
Glauber de Oliveira Costa in 2008, are used.
Signed-off-by: Jacek Galowicz <jacek@galowicz.de> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Kevin Cernekee [Thu, 24 Nov 2011 23:13:15 +0000 (10:13 +1100)]
module: Fix performance regression on modules with large symbol tables
Looking at /proc/kallsyms, one starts to ponder whether all of the extra
strtab-related complexity in module.c is worth the memory savings.
Instead of making the add_kallsyms() loop even more complex, I tried the
other route of deleting the strmap logic and naively copying each string
into core_strtab with no consideration for consolidating duplicates.
Performance on an "already exists" insmod of nvidia.ko (runs
add_kallsyms() but does not actually initialize the module):
Original scheme: 1.230s
With naive copying: 0.058s
Extra space used: 35k (of a 408k module).
Signed-off-by: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
LKML-Reference: <73defb5e4bca04a6431392cc341112b1@localhost>
Rusty Russell [Thu, 24 Nov 2011 23:13:14 +0000 (10:13 +1100)]
virtio: add debugging if driver doesn't kick.
Under the existing #ifdef DEBUG, check that they don't have more than
1/10 of a second between an add_buf() and a
virtqueue_notify()/virtqueue_kick_prepare() call.
We could get false positives on a really busy system, but good for
development.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell [Thu, 24 Nov 2011 23:13:14 +0000 (10:13 +1100)]
virtio: expose added descriptors immediately.
A virtio driver does virtqueue_add_buf() multiple times before finally
calling virtqueue_kick(); previously we only exposed the added buffers
in the virtqueue_kick() call. This means we don't need a memory
barrier in virtqueue_add_buf(), but it reduces concurrency as the
device (ie. host) can't see the buffers until the kick.
In the unusual (but now possible) case where a driver does add_buf()
and get_buf() without doing a kick, we do need to insert one before
our counter wraps. Otherwise we could wrap num_added, and later on
not realize that we have passed the marker where we should have
kicked.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell [Thu, 24 Nov 2011 23:13:13 +0000 (10:13 +1100)]
virtio: support unlocked queue kick
Based on patch by Christoph for virtio_blk speedup:
Split virtqueue_kick to be able to do the actual notification
outside the lock protecting the virtqueue. This patch was
originally done by Stefan Hajnoczi, but I can't find the
original one anymore and had to recreated it from memory.
Pointers to the original or corrections for the commit message
are welcome.
Rusty Russell [Thu, 24 Nov 2011 23:13:12 +0000 (10:13 +1100)]
virtio: rename virtqueue_add_buf_gfp to virtqueue_add_buf
Remove wrapper functions. This makes the allocation type explicit in
all callers; I used GPF_KERNEL where it seemed obvious, left it at
GFP_ATOMIC otherwise.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Reviewed-by: Christoph Hellwig <hch@lst.de>
virtio pci device reset actually just does an I/O
write, which in PCI is really posted, that is it
can complete on CPU before the device has received it.
Further, interrupts might have been pending on
another CPU, so device callback might get invoked after reset.
This conflicts with how drivers use reset, which is typically:
reset
unregister
a callback running after reset completed can race with
unregister, potentially leading to use after free bugs.
Fix by flushing out the write, and flushing pending interrupts.
This assumes that device is never reset from
its vq/config callbacks, or in parallel with being
added/removed, document this assumption.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Heiko Carstens [Tue, 15 Nov 2011 09:13:24 +0000 (10:13 +0100)]
virtio: add HAS_IOMEM dependency to MMIO platform bus driver
Fix this compile error on s390:
CC [M] drivers/virtio/virtio_mmio.o
drivers/virtio/virtio_mmio.c: In function 'vm_get_features':
drivers/virtio/virtio_mmio.c:107:2: error: implicit declaration of function 'writel'
Cc: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Robert Jarzmik [Sat, 19 Nov 2011 15:02:58 +0000 (16:02 +0100)]
mtd/docg3: add protection areas sysfs access
As each docg3 chip has 2 protection areas (DPS0 and DPS1),
and because theses areas can prevent user access to the chip
data, add for each floor the sysfs entries which insert the
protection key into the right DPS.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Reviewed-by: Ivan Djelic <ivan.djelic@parrot.com> Reviewed-by: Mike Dunn <mikedunn@newsguy.com>
Robert Jarzmik [Sat, 19 Nov 2011 15:02:57 +0000 (16:02 +0100)]
mtd/docg3: add fast mode
Docg3 chips can work in 3 modes : normal MLC mode, fast
mode and reliable mode. Normally, as docg3 is a MLC chip, it
should be configured to work in normal mode.
In both normal mode, each page is distinct. This
means that writing to page 12 of blocks 14,15 writes only to
that page, and reading from page 12 of blocks 14,15 reads
only from that page.
In reliable and fast modes, pages are coupled by pairs, and
are clones one of each other. This means that the available
capacity of the chip is halved. Pages are coupled in each
block, and page of index 2*n contains the same data as page
2*n+1 of the same block.
In fast mode, the reads occur a bit faster, but are a bit
less reliable that in normal mode.
When reading from page 2*n, the chip reads bytes from both
page 2*n and page 2*n+1, makes a logical and for each byte,
and returns the result. As programming a page means
"clearing bits", even if a bit was not cleared on one page
because the flash is worn out, the other page has the bit
cleared, and the result of the "AND" gives a correct result.
When writing to page 2*n, the chip writes data to both page
2*n and page 2*n+1.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Reviewed-by: Ivan Djelic <ivan.djelic@parrot.com> Reviewed-by: Mike Dunn <mikedunn@newsguy.com>
Robert Jarzmik [Sat, 19 Nov 2011 15:02:55 +0000 (16:02 +0100)]
mtd/docg3: add ECC correction code
Credit for discovering the BCH algorith parameters, and bit
reversing algorithm is to be give to Mike Dunn and Ivan
Djelic.
The BCH correction code relied upon the BCH library, where
all data and ECC is bit-reversed. The BCH library works
correctly when each input byte is bit-reversed, and
accordingly ECC output is also bit-reversed.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Reviewed-by: Ivan Djelic <ivan.djelic@parrot.com> Reviewed-by: Mike Dunn <mikedunn@newsguy.com>
Robert Jarzmik [Sat, 19 Nov 2011 15:02:53 +0000 (16:02 +0100)]
mtd/docg3: add erase functions
Add erase capability to the docg3 driver. The erase block is
made of 2 physical blocks, as both share all 64 pages. That
makes an erase block of at least 64 kBytes.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Reviewed-by: Ivan Djelic <ivan.djelic@parrot.com> Reviewed-by: Mike Dunn <mikedunn@newsguy.com>