Commit 19d36ccdc3 "x86: Fix alternatives
and kprobes to remap write-protected kernel text" uses code which is
being patched for patching.
In particular, paravirt_ops does patching in two stages: first it
calls paravirt_ops.patch, then it fills any remaining instructions
with nop_out(). nop_out calls text_poke() which calls
lookup_address() which calls pgd_val() (aka paravirt_ops.pgd_val):
that call site is one of the places we patch.
If we always do patching as one single call to text_poke(), we only
need make sure we're not patching the memcpy in text_poke itself.
This means the prototype to paravirt_ops.patch needs to change, to
marshal the new code into a buffer rather than patching in place as it
does now. It also means all patching goes through text_poke(), which
is known to be safe (apply_alternatives is also changed to make a
single patch).
AK: fix compilation on x86-64 (bad rusty!)
AK: fix boot on x86-64 (sigh)
AK: merged with other patches
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Files using bits from paravirt.h should explicitly include it rather than
relying on it being pulled in by something else.
Signed-off-by: Jes Sorensen <jes@sgi.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gcc-4.2 is a lot more picky about its symbol handling. EXPORT_SYMBOL no
longer works on symbols that are undefined or defined with static scope.
For example, with CONFIG_PROFILE off, I see:
kernel/profile.c:206: error: __ksymtab_profile_event_unregister causes a section type conflict
kernel/profile.c:205: error: __ksymtab_profile_event_register causes a section type conflict
This patch moves the EXPORTs inside the #ifdef CONFIG_PROFILE, so we
only try to export symbols that are defined.
Also, in kernel/kprobes.c there's an EXPORT_SYMBOL_GPL() for
jprobes_return, which if CONFIG_JPROBES is undefined is a static
inline and gives the same error.
And in drivers/acpi/resources/rsxface.c, there's an
ACPI_EXPORT_SYMBOPL() for a static symbol. If it's static, it's not
accessible from outside the compilation unit, so should bot be exported.
These three changes allow building a zx1_defconfig kernel with gcc 4.2
on IA64.
[akpm@linux-foundation.org: export jpobe_return properly]
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git rid of "warning: passing arg 2 of `access_ok' makes pointer from integer
without a cast" reported on SH ... most architectures use macros in that
test, SH uses inlined functions.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sh:
drivers/mtd/mtdchar.c: In function `mtd_mmap':
drivers/mtd/mtdchar.c:817: error: dereferencing pointer to incomplete type
drivers/mtd/mtdchar.c:817: error: `VM_SHARED' undeclared (first use in this function)
drivers/mtd/mtdchar.c:817: error: (Each undeclared identifier is reported only once
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Patch c5c34d4862 (tty: flush flip buffer on
ldisc input queue flush) introduces a race condition which can lead to memory
leaks.
The problem can be triggered when tcflush() is called when data are being
pushed to the line discipline driver by flush_to_ldisc().
flush_to_ldisc() releases tty->buf.lock when calling the line discipline
receive_buf function. At that poing tty_buffer_flush() kicks in and sets both
tty->buf.head and tty->buf.tail to NULL. When flush_to_ldisc() finishes, it
restores tty->buf.head but doesn't touch tty->buf.tail. This corrups the
buffer queue, and the next call to tty_buffer_request_room() will allocate a
new buffer and overwrite tty->buf.head. The previous buffer is then lost
forever without being released.
(Thanks to Laurent for the above text, for finding, disgnosing and reporting
the bug)
- Use tty->flags bits for the flush status.
- Wait for the flag to clear again before returning
- Fix the doc error noted
- Fix flush of empty queue leaving stale flushpending
[akpm@linux-foundation.org: cleanup]
Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Paul Fulghum <paulkf@microgate.com>
Cc: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Long ago I've noticed (but didn't pay much attention) that
spi_mpc83xx using PM calculations that differs from what
specs describe. I.e.
u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
While specs says: "The SPI baud rate generator clock source (either
system clock or system clock divided by 16, depending on DIV16 bit) is
divided by 4 * ([PM] + 1), a range from 4 to 64.".
Thus " - 1" is missing in the spi_mpc83xx's formula.
Why nobody noticed that bug? Probably because sysclk usually less then
user expects, e.g. you expect 200 MHz, but real clock is 198 MHz,
and integer rounding helps when this formula is used.
Suppose it's SPI in QE, SYSCLK at 198 MHz, thus SPIBRG at 99MHz, 25 MHz
requested.
PM = (99MHz / ( 25 MHz * 4 )), PM == 0, output SPICLK will be 24.75 MHz
At lower frequencies this bug is more noticeable, though.
And this bug shows itself in all its beauty if SYSCLK is equal or a bit
more than you expect (200 MHz SYSCLK, 100 MHz SPIBRG):
PM = (100MHz / ( 25 MHz * 4 )), PM == 1, output SPICLK will be 12.625 MHz!
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
For MPC8349E input to the SPI Baud Rate Generator is SYSCLK, but it's
SYSCLK/2 for MPC8323E (SPI in QE). Fix this, and remove confusion by
renaming the mpc83xx_spi->sysclk member as mpc83xx_spi->spibrg.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cm4000_cs.c and cm4040_cs.c call the internal release function with
an argument of wrong type. this fixes bug #8485
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Bill McConnaughey <mcconnau@biochem.wustl.edu>
Cc: Natalie Protasevich <protasnb@gmail.com>
Cc: Harald Welte <laforge@gnumonks.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This builds upon my previous attempts to resolve some jitter problems seen
with the Matrox G450 and G550 -based cards, including odd disparities observed
between x86 and Power -based machines in a somewhat less hackish way (removing
the hacked ifdefs).
Apparently, preference should be given to use the DVI PLL when frequencies
permit, the Standard PLL otherwise. The max pixel clock for the panellink
interface is extracted from the PInS information on the card and used as a
limit to determine which PLL to use.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Acked-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- better handling of the pvr2 registers based on more up to date information.
Testing shows that it seems to work pretty well at 16bpp, 24bpp and 32bpp -
including proper rendering of the boot logo at all levels (previously this was
a bit broken even at 16bpp) and giving white against black text. Really
detailed testing (eg with X11) requires support for the maple bus - which
isn't (currently - next project assuming this is okay) available, but I have
no reason to think this is broken.
Signed-off by: Adrian McMenamin <adrian@mcmen.demon.co.uk>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported by: Adrian McMenamin <adrianmcmenamin@gmail.com>
This driver will oops when the pseudo_palette[] is written as u32 but not when
written as u16. When written as u32, it corrupts the adjacent 'mmio_base'
field of struct pvr2fb_par. Fix by using framebuffer_alloc()/release() to
allocate struct fb_info and struct pvr2fb_par, and create the pseudo_palette[]
as part of struct pvr2fb_par.
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix compile warning ('map_override unused') if fbcon is compiled as a module
and CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=n.
[akpm@linux-foundation.org: cleanup]
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Visualize-EG, Graffiti and A4450A graphics cards on PARISC can
be configured in double-buffer and standard mode, but the stifb
driver supports standard mode only.
This patch detects double-buffered cards more reliable.
It is a real bugfix for a very nasty problem for all parisc users which have
wrongly configured their graphic card. The problem: The stifb graphics driver
will not detect that the card is wrongly configured and then nevertheless just
enables the graphics mode, which it shouldn't. In the end, the user will see
no further updates / boot messages on the screen.
We had documented this problem already on our FAQ
(http://parisc-linux.org/faq/index.html#viseg "Why do I get corrupted graphics
with my Vis-EG/Graffiti/A4450A card?") but people still run into this problem.
So having this fix in as early as possible can help us.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Cc: <stable@kernel.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
mmc: at91_mci: remove whitespace at the end of lines
mmc: reorganize bounce buffer init
wbsd: fix section mismatch warnings
If a Guest makes hypercall which sets a GDT entry to not present, we
currently set any segment registers using that GDT entry to 0.
Unfortunately, this is not sufficient: there are other ways of
altering GDT entries which will cause a fault.
The correct solution to do what Linux does: let them set any GDT value
they want and handle the #GP when popping causes a fault. This has
the added benefit of making our Switcher slightly more robust in the
case of any other bugs which cause it to fault.
We kill the Guest if it causes a fault in the Switcher: it's the
Guest's responsibility to make sure it's not using segments when it
changes them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
lguest uses a host-supplied wallclock-based clocksource when the TSC
is not reliable. As this is already in nanoseconds, I naively used a
multiplier of 1 and a shift of 0.
But update_wall_time() in its infinite wisdom decides to adjust the
clock a little (where does it think it's getting a more accurate time
from?)
It will happily tweak the multiplier... to 0, then -1.
So the "fix" is to use a shift of 22 like everyone else, and a
multiplier of 1 << 22.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some cleanup with whitespace/tab at the end of lines.
Signed-off-by: Nicolas Ferre <nicolas.ferre@rfo.atmel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Reorganize the code that initializes mmc_block's bounce buffer in
order to avoid warnings when MMC_BLOCK_BOUNCE isn't used.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
This patch fixes the following section mismatch warnings
...
WARNING: vmlinux.o(.init.text+0x29d40): Section mismatch: reference to .exit.text:wbsd_release_resources (between 'wbsd_init' and 'wbsd_probe')
WARNING: vmlinux.o(.init.text+0x29d49): Section mismatch: reference to .exit.text:wbsd_free_mmc (between 'wbsd_init' and 'wbsd_probe')
WARNING: vmlinux.o(.init.text+0x29f28): Section mismatch: reference to .exit.text:wbsd_free_mmc (between 'wbsd_init' and 'wbsd_probe')
...
Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
> >> Looks like memset() is zeroing wrong nr of bytes.
> >
> > Good catch, however, I think we can just remove this memset altogether
> > since the memory gets allocated via kzalloc.
>
> Correct, that memset() is superfluous.
Ok. Then this should do it.
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
drivers/net/ibmveth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Use shorter method to determine whether adapter has configured ports
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
sis190 driver assumes to find ISA only on SiS965.
similar fix is in sis900 driver, see bug report
http://bugs.debian.org/435547
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
use the simpler spin_trylock_irqsave() API to get the adapter lock.
[ this is also a fix for -rt where adapter->lock is a sleeping lock. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
SH boards in general only wire this up in 8 or 16-bit mode, and
as we never had the wrappers for 32-bit mode defined, SMC_CAN_USE_32BIT
caused build failure for the non-Solution Engine boards. This gets it
building again.
Also kill off the straggling set_irq_type() definition, this is left
over cruft that was missed when the rest of it switched to IRQ flags.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
--
drivers/net/smc91x.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Lguest drivers need to default to "Y" otherwise they're never selected
for new builds. (We don't bother prompting, because they're less than
4k combined, and implied by selecting lguest support).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
More fallout from the writeback fixes: debug register transfer
instructions do their own writeback and thus need to disable the general
writeback mechanism.
This fixes oopses and some guest failures on AMD machines (the Intel
variant decodes the instruction in hardware and thus does not need
emulation).
Cc: Alistair John Strachan <alistair@devzero.co.uk>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[NETFILTER]: Add xt_statistic.h to the header list for usermode programs
[BNX2]: Fix suspend/resume problem.
[TG3]: Fix suspend/resume problem.
This 965G and above chipsets moved the batch buffer non-secure bits to
another place. This means that previous drm's allowed in-secure batchbuffers
to be submitted to the hardware from non-privileged users who are logged
into X and and have access to direct rendering.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Theory : though needless, it should not have hurt.
Practice: it does not play nice with DEBUG_SHIRQ + LOCKDEP + UP
(see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242572).
The patch makes sense in itself but I should dig why it has an effect
on #242572 (assuming that NAPI do not change in a near future).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Fix extracted from Realtek's driver (8.002.00/20070713) for the PHY
attached to 8111/8168b chipsets.
The check against mac_version is just usual paranoia during the bugfix
period of the kernel cycle. -- FR
Tested on Asus M2A-VM motherboard by Roger So.
No regression on my Asrock 945G DVI either (built-in 8168 + 2x8169).
Signed-off-by: Roger So <roger.so@gmail.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
While filling the control set the driver tests for a PSPOLL frame.
But it tested only the subtype of the packet. The full type needs
to be tested to identify those packets reliably.
[dsd@gentoo.org: backport to mainline]
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
conf->mac_addr is not guaranteed to be set. This ensures priv->hwaddr is
always set to a valid mac address. Thanks to Johannes Berg
<johannes@sipsolutions.net> for finding this problem.
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit 77548f5807.
David Woodhouse wrote:
>This broke my shinybook. I seem to get absolutely _no_ outgoing packets,
>although I can receive OK.
Larry Finger wrote:
>Please revert this patch.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alan Cox suggested that the solution to the FIXMEs in pata_icside is
to use a private postreset method to detect the lack of devices on a
port, and in such a case, disable the interrupt for the port.
This patch implements such a method, and removes the hard coded
disable of port 0. Tested as working.
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If the driver fails to allocate the contiguous (DMAable) memory for
system reasons, we fail to load the instance, but then we try to free
the <nul> allocation in the cleanup code and we get a panic in
pci_free_consistent(). This is reported against an older kernel, hope
this is relevant for latest/greatest.
Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
And finally this is the regular !use_sg cleanup
and use of data accessors.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
check_condition code-path was similar but more
complicated to Reset. It went like this:
1. extra space was allocated at aha152x_scdata for mirroring
scsi_cmnd members.
2. At aha152x_internal_queue() every not check_condition
(REQUEST_SENSE) command was copied to above members in
case of error.
3. At busfree_run() in the DONE_CS phase if a Status of
SAM_STAT_CHECK_CONDITION was detected. The command was
re-queued Internally using aha152x_internal_queue(,,check_condition,)
The old command members are over written with the
REQUEST_SENSE info.
4. At busfree_run() in the DONE_CS phase again. If it is a
check_condition command, info was restored from mirror
made at first call to aha152x_internal_queue() (see 2)
and the command is completed.
What I did is:
1. Allocate less space in aha152x_scdata only for the 16-byte
original command. (which is actually not needed by scsi-ml
anymore at this stage. But this is to much knowledge of scsi-ml)
2. If Status == SAM_STAT_CHECK_CONDITION, then like before
re-queue a REQUEST_SENSE command. But only now save original
command members. (Less of them)
3. In aha152x_internal_queue(), just like for Reset, use the
check_condition hint to set differently the working members.
execute the command.
4. At busfree_run() in the DONE_CS phase again. restore needed
members.
While at it. This patch fixes a BUG. Old code when sending
a REQUEST_SENSE for a failed command. Would than return with
cmd->resid == 0 which was the status of the REQUEST_SENSE.
The failing command resid was lost. And when would resid
be interesting if not on a failing command?
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
What Reset code was doing: Save command's important/dangerous
Info on stack. NULL those members from scsi_cmnd.
Issue a Reset. wait for it to finish than restore members
and return.
What I do is save or NULL nothing. But use the "resetting"
hint in aha152x_internal_queue() to NULL out working members
and leave struct scsi_cmnd alone.
The indent here looks funny but it will change/drop in last
patch and it is clear this way what changed.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
hunk by hunk:
- CHECK_CONDITION is what happens to cmnd->status >> 1
or after status_byte() macro. But here it is used
directly on status which means 0x1 which is an undefined
bit in the standard. And is a status that will never
return from a target.
- in busfree_run at the DONE_SC phase we have 3 distinct
operation:
1-if(DONE_SC->SCp.phase & check_condition)
The REQUEST_SENSE command return.
- Restore original command
- Than continue to operation 3.
2-if(DONE_SC->SCp.Status==SAM_STAT_CHECK_CONDITION)
A regular command returned with a status.
- Internally re-Q a REQUEST_SENSE.
- Do not do operation 3.
3-
- Complete the command and return it to scsi-ml
So the 0x2 in both these operations (1,2) means the scsi
check-condition status, hence SAM_STAT_CHECK_CONDITION
- Here the code asks about !(DONE_SC->SCp.Status & not_issued)
but "not_issued" is an enum belonging to the "phase" member
and not to the Status returned from target. The reason this
works is because not_issued==1 and Also CHECK_CONDITION==1
(remember from hunk 1). So actually the code was asking
!(DONE_SC->SCp.Status & CHECK_CONDITION). Which means
"Has the status been read from target yet?"
Staus is read at status_run(). "not_issued" is
cleared in seldo_run() which is usually earlier than
status_run().
So this patch does nothing as far as assembly is concerned
but it does let the reader understand what is going on.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Cause highmem buffers to be bounced to low memory until this
driver supports highmem addresses. Otherwise it just oopses
on NULL buffer addresses.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
