Notifier functions are expected to return NOTIFY_* codes, not -E...
ones. In particular, since the respective hypercalls failing is not
fatal to the operation of the Dom0 kernel, it must be avoided to
return negative values here as those would make it appear as if
NOTIFY_STOP_MASK wa set, suppressing further notification calls to
other interested parties (which is also why we don't want to use
notifier_from_errno() here).
While at it, also notify the user of a failed hypercall.
Signed-off-by: Jan Beulich <[email protected]>
[v1: Added dev_err and the disable MSI/MSI-X call]
[v2: Removed the disable MSI/MSI-X call]
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
The order-based approach is not only less efficient (requiring a shift
and a compare, typical generated code looking like this
mov eax, [machine_to_phys_order]
mov ecx, eax
shr ebx, cl
test ebx, ebx
jnz ...
whereas a direct check requires just a compare, like in
cmp ebx, [machine_to_phys_nr]
jae ...
), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).
Additionally, the elimination of the mistaken use of fls() here (should
have been __fls()) fixes a latent issue on x86-64 that would trigger
if the code was run on a system with memory extending beyond the 44-bit
boundary.
CC: [email protected]
Signed-off-by: Jan Beulich <[email protected]>
[v1: Based on Jeremy's feedback]
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Without this change, the majority of the raw PCI config space access
functions silently ignore a non-zero segment argument, which is
certainly wrong.
Apart from pci_direct_conf1, all other non-MMCFG access methods get
used only for non-extended accesses (i.e. assigned to raw_pci_ops
only). Consequently, with the way raw_pci_{read,write}() work, it would
be a coding error to call these functions with a non-zero segment (with
the current call flow this cannot happen afaict).
The access method 1 accessor, as it can be used for extended accesses
(on AMD systems) instead gets checks added for the passed in segment to
be zero. This would be the case when on such a system having multiple
PCI segments (don't know whether any exist in practice) MMCFG for some
reason is not usable, and method 1 gets selected for doing extended
accesses. Rather than accessing the wrong device's config space, the
function will now error out.
v2: Convert BUG_ON() to WARN_ON(), and extend description as per Ingo's
request.
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
The compiler, at least for ix86 and m68k, validly warns that the
comparison:
next <= (loff_t)-1
is always true (and it's always true also for x86-64 and probably all
other arches - as long as pgoff_t isn't wider than loff_t). The
intention appears to be to avoid wrapping of "next", so rather than
eliminating the pointless comparison, fix the loop to indeed get exited
when "next" would otherwise wrap.
On m68k the following warning is observed:
fs/fscache/page.c: In function '__fscache_uncache_all_inode_pages':
fs/fscache/page.c:979: warning: comparison is always false due to limited range of data type
Reported-by: Geert Uytterhoeven <[email protected]>
Reported-by: Jan Beulich <[email protected]>
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: David Howells <[email protected]>
Cc: Suresh Jayaraman <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: [email protected]
Signed-off-by: Linus Torvalds <[email protected]>
The EFI specification requires that callers of the time related
runtime functions serialize with other CMOS accesses in the
kernel, as the EFI time functions may choose to also use the
legacy CMOS RTC.
Besides fixing a latent bug, this is a prerequisite to safely
enable the rtc-efi driver for x86, which ought to be preferred
over rtc-cmos on all EFI platforms.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Matthew Garrett <[email protected]>
Cc: <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Cc: Matthew Garrett <[email protected]>
With CPU hotplug, there is a theoretical race between other CMOS
(namely RTC) accesses and those done in the SMP secondary
processor bringup path.
I am unware of the problem having been noticed by anyone in practice,
but it would very likely be rather spurious and very hard to reproduce.
So to be on the safe side, acquire rtc_lock around those accesses.
Signed-off-by: Jan Beulich <[email protected]>
Cc: John Stultz <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
With the write lock path simply subtracting RW_LOCK_BIAS there
is, on large systems, the theoretical possibility of overflowing
the 32-bit value that was used so far (namely if 128 or more
CPUs manage to do the subtraction, but don't get to do the
inverse addition in the failure path quickly enough).
A first measure is to modify RW_LOCK_BIAS itself - with the new
value chosen, it is good for up to 2048 CPUs each allowed to
nest over 2048 times on the read path without causing an issue.
Quite possibly it would even be sufficient to adjust the bias a
little further, assuming that allowing for significantly less
nesting would suffice.
However, as the original value chosen allowed for even more
nesting levels, to support more than 2048 CPUs (possible
currently only for 64-bit kernels) the lock itself gets widened
to 64 bits.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Consumers of the table pointers in struct efi check for
EFI_INVALID_TABLE_ADDR to determine validity, hence these
pointers should all be pre-initialized to this value (rather
than zero).
Noticed by the discrepancy between efivars' systab sysfs entry
showing all tables (and their pointers) despite the code
intending to only display the valid ones. No other bad effects
known, but having the various table parsing routines bogusly
access physical address zero is certainly not very desirable
(even though they're unlikely to find anything useful there).
Signed-off-by: Jan Beulich <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Otherwise, the warning at the top of vsnprintf() gets triggered by
kvasprintf()'s first invocation (with NULL buffer and zero size) of
vsnprintf().
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
On various newer Intel systems the PCI bus(ses) the non-core devices
live on aren't getting announced by ACPI except through the bus range
covered by mmconfig. At least the i7core-edac driver depends on these
devices getting detected.
Mauro, could you check whether with this change the Xeon 55xx hack in
that driver can go away altogether, and with it the bogus exporting of
pcibios_scan_specific_bus()?
Signed-off-by: Jan Beulich <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Aristeu Sergio <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
The sector number on empty barrier requests may (will?) be -1, which,
given that it's being treated as unsigned 64-bit quantity, will almost
always exceed the actual (virtual) disk's size.
Inspired by Konrad's "When writting barriers set the sector number to
zero...".
While at it also add overflow checking to the math in vbd_translate().
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Cherry-pick and modified from 69d64727c42eecd47fdf82c15a54474d21a4012a
("blkback/blktap2: simplify address translations"):
"There are quite a number of places where e.g. page->va->page
translations happen.
Besides yielding smaller code (source and binary), a second goal is to
make it easier to determine where virtual addresses of pages allocated
through alloc_empty_pages_and_pagevec() are really used (in turn in
order to determine whether using highmem pages would be possible
there)."
The second goal is not the purpose of this patch - it is just to
make it easier to read the code.
linux-2.6-pvops:
* Stripped drivers/xen/gntdev/*
* Stripped drivers/xen/netback/*
[v2: Stripped blktap off]
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Daniel Stodden <[email protected]>
Signed-off-by: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
'struct dmi_system_id' arrays must always have a terminator to keep
dmi_check_system() from looking at data (and possibly crashing) it
isn't supposed to look at.
The issue went unnoticed until ef8313bb1a,
but was introduced about a year earlier with
7705d548cb (which also similarly changed
lifebook.c, but the problem there got eliminated shortly afterwards).
The first hunk therefore is a stable candidate back to 2.6.33, while
the full change is needed only on 2.6.38.
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
While the hypervisor change adding SCHEDOP_watchdog support included a
daemon to make use of the new functionality, having a kernel driver
for /dev/watchdog so that user space code doesn't need to distinguish
non-Xen and Xen seems to be preferable.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
'n' defaults are pretty pointless and actually bogus when used with
prompt-less config options.
The "bool"/"default y" pair with no prompt can be expressed more
compactly using def_bool.
[rjw: Rebased on top of earlier patches modifying this file.]
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
This isn't being referenced anywhere, and the selects done from
it can be easily done together with all the other X86 ones.
v2: Also adjust UML's Kconfig.x86.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Add extra parentheses around a couple of definitions introduced
by "x86: Cleanup vector usage" and used in assembly macro
arguments, and remove spaces. Without that old (2.16.1) gas
would see more macro arguments than were actually specified.
Reported-and-tested-by: Andrew Morton <[email protected]>
Signed-off-by: Jan Beulich <[email protected]>
Cc: Shaohua Li <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Once acpi_map_lsapic() in ia64 follows how x86 treats it wrt section
placement, the whole tree from acpi_processor_set_pdc() can become
__cpuinit.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Tony Luck <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Use __init for several functions, remove an unnecessary export and a
stray use of __ref.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Len Brown <[email protected]>
'simple' would have required specifying current frame address
and return address location manually, but that's obviously not
the case (and not necessary) here.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
arch/um/Kconfig.x86 has X86_32 but not X86_64 - that's resulting in
asm/dwarf2.h producing the 32-bit (pushl_cfi & Co) macros instead of
the 64-bit ones.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Jeff Dike <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Some of the items removed were apparently never used, others
simply didn't get removed with their last user.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
"def_bool n" without prompt is pointless, these should be just "bool".
[ tglx: Adapted to latest changes ]
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
The interface is identical EMC6D102, so all that needs to be added are
some definitions and their uses.
Registers apparently missing in EMC6D103S/EMC6D103:A2 compared to EMC6D103:A0,
EMC6D103:A1, and EMC6D102 (according to the data sheets), but used
unconditionally in the driver: 62[5:7], 6D[0:7], and 6E[0:7]. For that
reason, EMC6D103S chips don't get enabled for the time being.
Signed-off-by: Jan Beulich <[email protected]>
(Guenter Roeck: Replaced EMC6D103_A2 with EMC6D103S per EMC6D103S datasheet)
Signed-off-by: Guenter Roeck <[email protected]>
Cc: [email protected]
"def_bool n" without prompt is pointless, this should be just "bool".
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Not only when an IRQ's affinity equals cpu_online_mask is there
no need to actually try to adjust the affinity, but also when
it's a subset thereof. This particularly avoids adjustment
attempts during system shutdown to any IRQs bound to CPU#0.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Gary Hade <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Printing a single character alone when there's an immediately
following printk() is pretty pointless (and wasteful).
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Just consolidating the common parts. Full unification would seem
straight forward, but it's not clear the necessary #ifdef-s would
be acceptable.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Additionally doing things conditionally upon smp_processor_id()
being zero is generally a bad idea, as this means CPU 0 cannot
be offlined and brought back online later again.
While there may be other places where this is done, I think adding
more of those should be avoided so that some day SMP can really
become "symmetrical".
Signed-off-by: Jan Beulich <[email protected]>
Cc: Cyrill Gorcunov <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
In order to be able to suppress the use of SRAT tables that
32-bit Linux can't deal with (in one case known to lead to a
non-bootable system, unless disabling ACPI altogether), move the
"numa=" option handling to common code.
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Thomas Renninger <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Thomas Renninger <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
While both methods should work equivalently well for the native
case, the Xen Dom0 case can't reliably work with the MSR one,
since there's no guarantee that the virtual CPUs it has
available fully cover all necessary physical ones.
As per the suggestion of Robert Richter the patch only adds the
PCI method, but leaves the MSR one as a fallback to cover new
systems the PCI IDs of which may not have got added to the code
base yet.
The only change in v2 is the breaking out of the new CPI
initialization method into a separate function, as requested by
Ingo.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Robert Richter <[email protected]>
Cc: Andreas Herrmann3 <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
The function can't be __init itself (being called from some sysfs
handler), and hence none of the functions it calls can be either.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
This lead to non-selected, non-user-selectable options to be written
out to .config. This is not only pointless, but also preventing the
user to be prompted should any of those options eventually become
visible (e.g. by de-selecting the *_AUTO options the "visible"
attribute was added for.
Furthermore it is quite logical for the "visible" attribute of a menu
to control the visibility of all contained prompts, which is what the
patch does.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
Properly const-, __init-, and __read_mostly-annotate this code.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Len Brown <[email protected]>
... regarding an unused function when !MIGRATION, and regarding a
printk() format string vs argument mismatch.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Candidate memory ranges were not calculated properly (start
addresses got needlessly rounded down, and end addresses didn't
get rounded up at all), address comparison for secondary CPUs
was done on only part of the address, and disabled status wasn't
tracked properly.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Yinghai Lu <[email protected]>
Acked-by: Andreas Herrmann <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
To bind all event channels to CPU#0, it is not sufficient to set all
of its cpu_evtchn_mask[] bits; all other CPUs also need to get their
bits cleared. Otherwise, evtchn_do_upcall() will start handling
interrupts on CPUs they're not intended to run on, which can be
particularly bad for per-CPU ones.
[ linux-2.6.18-xen.hg 7de7453dee36 ]
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Jeremy Fitzhardinge <[email protected]>
check_enable_amd_mmconf_dmi() gets called only for the BSP,
hence everything hanging off of it can be __init*.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Yinghai Lu <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
gcc aligns strings as a performance consideration for those cases where
strings are being used a lot.
Their use is not performance critical, and hence it seems better to save
some space.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Rusty Russell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
According to the documentation, simply reading the respective MSR
isn't sufficient: It should be written with zeros, cpuid(1) be
executed, and then read (see arch/x86/kernel/cpu/intel.c for an
example).
v2: Fail probe when microcode revision cannot be determined, but is
needed to check for proper operation.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: Chen Gong <[email protected]>
Cc: Jean Delvare <[email protected]>
Acked-by: Fenghua Yu <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
These likely originate from these drivers being clones of one another
and/or other drivers which actually needed these includes.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
"break" after "return" is at best bogus (good compilers even warn about
the "break" being unreachable).
Signed-off-by: Jan Beulich <[email protected]>
Cc: Rudolf Marek <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
... as they're being called only from a __cpuinit function.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
These were (intentionally) stripped by "fix CFI macro
invocations to deal with shortcomings in gas" to expose problems
with unexpected splitting of arguments by older gas also on
newer versions, but as it turns out there is at least one distro
(Ubuntu 6.06) where even not having *any* spaces in a macro
argument doesn't reliably prevent splitting into multiple
arguments.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Alexander van Heukelum <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
gas prior to (perhaps) 2.16.90 has problems with passing non-
parenthesized expressions containing spaces to macros. Spaces, however,
get inserted by cpp between any macro expanding to a number and a
subsequent + or -. For the +, current x86 gas then removes the space
again (future gas may not do so), but for the - the space gets retained
and is then considered a separator between macro arguments.
Fix the respective definitions for both the - and + cases, so that they
neither contain spaces nor make cpp insert any (the latter by adding
seemingly redundant parentheses).
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Cc: Alexander van Heukelum <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
This patch (commit 690a1f2002) added a
new call site for acpi_set_WOL() without checking that the function is
actually suitable to be called via
vortex_set_wol+0xcd/0xe0 [3c59x]
dev_ethtool+0xa5a/0xb70
dev_ioctl+0x2e0/0x4b0
T.961+0x49/0x50
sock_ioctl+0x47/0x290
do_vfs_ioctl+0x7f/0x340
sys_ioctl+0x80/0xa0
system_call_fastpath+0x16/0x1b
i.e. outside of code paths run when the device is not yet enabled or
already disabled. In particular, putting the device into D3hot is a
pretty bad idea when it was already brought up.
Furthermore, all prior callers of the function made sure they're
actually dealing with a PCI device, while the newly added one didn't.
In the same spirit, the .get_wol handler shouldn't indicate support
for WOL for non-PCI devices.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Other than coretemp, from which this code was apparently derived, there
is no PCI specific code in this driver.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Fenghua Yu <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Just like pkgtemp registers another core of the same package when one
gets removed, coretemp should register another hyperthread (if
available) in that situation.
As pointed out in the patch fixing the respective code in pkgtemp, the
list protectng mutex must be dropped before calling
coretemp_device_add(), and due to the restructured loop (including an
explicit return) the "safe" variant of the list iterator isn't needed
anymore.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Rudolf Marek <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Using cpuid_eax() to determine feature availability on other than
the current CPU is invalid. And feature availability should also be
checked in the hotplug code path.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Rudolf Marek <[email protected]>
Cc: Fenghua Yu <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
pkgtemp_device_remove(), holding the list protecting mutex, calls
pkgtemp_device_add(), which itself wants to acquire the same mutex.
Holding the mutex over the entire loop body in pkgtemp_device_remove()
isn't really necessary, as long as the loop gets exited after
processing the matched CPU.
Once exiting the loop after removing an eventual match, there's no
need for using the "safe" list iterator anymore.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Fenghua Yu <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
In commit 0dca94baea the call to
platform_driver_unregister() was made conditional upon !HOTPLUG_CPU,
but the return value from coretemp_init() was left to indicate an
error. This isn't correct, as the negative return value indicates to
the module loader that initialization failed, which isn't intended
here and results in dangling pointers.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Chen Gong <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
In commit e517a5e970 the call to
map_page_into_agp() got removed from intel_i830_setup_flush(), but the
counterpart call from intel_i830_fini_flush() to unmap_page_from_agp()
was left in place.
Additionally, the page allocated here never gets its physical address
used for sending to hardware, so there's no need to allocate it with
GFP_DMA32. Nor is __GFP_ZERO really necessary, as the page is used
only to store data to force flushing of some internal processor state.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Eric Anholt <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
When operating on whole pages, use clear_page() and copy_page() in
favor of memset() and memcpy(); after all that's what they are
intended for.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
The explicit saving and restoring of %ebx was confusing stack
unwind data consumers, and it is plain unnecessary to do this
within the asm(), since that was only introduced for PIC user
mode consumers of the original _syscall3() macro this was
derived from.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Arnd Bergmann <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
... plus additionally introduce {push,pop}f{l,q}_cfi. All in the
hope that the code becomes better readable this way (it gets
quite a bit smaller in any case).
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Alexander van Heukelum <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
When these stubs are actual functions (i.e. having a return
instruction) and have stack manipulation instructions in them,
they should also be annotated to allow unwinding through them.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Alexander van Heukelum <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
... making the code a little less fragile.
Also use pushq_cfi instead of raw CFI annotations in two more
places, and add two missing annotations after stack pointer
adjustments which got modified here anyway.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Alexander van Heukelum <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
As this isn't an exception or interrupt entry point, it doesn't
have any of the hardware provide frame layouts active.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Alexander van Heukelum <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
With the return address removed from the stack, these should
really refer to their caller's register state.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Alexander van Heukelum <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
It doesn't like pattern and explicit rules to be on the same line,
and it seems to be more picky when matching file (or really directory)
names with different numbers of trailing slashes.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Andrew Benton <[email protected]>
Cc: <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
Unfortunately commit "blkfront: fixes for 'xm block-detach ... --force'"
still wasn't quite right - there was a reference to freed memory left
from blkfront_closing().
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Prevent prematurely freeing 'struct blkfront_info' instances (when the
xenbus data structures are gone, but the Linux ones are still needed).
Prevent adding a disk with the same (major, minor) [and hence the same
name and sysfs entries, which leads to oopses] when the previous
instance wasn't fully de-allocated yet.
This still doesn't address all issues resulting from forced detach:
I/O submitted after the detach still blocks forever, likely preventing
subsequent un-mounting from completing. It's not clear to me (not
knowing much about the block layer) how this can be avoided.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
This makes it so "make oldconfig" really prompts for any choice where
options that previously weren't visible just became so. Previously one
would have to remember to go over all choice values and check whether
some that previously couldn't be selected now can be.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
Bits set in cpu_possible_mask prior to the execution of
prefill_possible_map() (i.e. when parsing ACPI or MPS tables) would
prevent the SMP alternatives logic from switching to UP mode, plus
unnecessary setup of per-CPU data for CPUs that can never come online.
Additionally, without CONFIG_HOTPLUG_CPU disabled CPUs can never come
online, and hence setting cpu_possible_mask bits for them is again a
simple waste of resources.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Without CONFIG_CPUMASK_OFFSTACK, simply inverting cpu_online_mask leads
to CPUs beyond nr_cpu_ids to be displayed twice and CPUs not even
possible to be displayed as offline.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
It's not used by any module, and i386 (as well as some other arches)
also doesn't export its equivalent (swapper_pg_dir).
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Reduce the SMP locks table size by using relative pointers instead of
absolute ones, thus cutting the table size by half.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
... i.e. when the hole between two regions isn't occupied by memory on
another node. This reduces the memory->node table size, thus reducing
cache footprint of lookups, which got increased significantly some
time ago, and things go back to how they were before that change on
the systems I looked at.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Commit c2e13037e6 ("platform-drivers: move
probe to .devinit.text in drivers/video") introduced a huge amount of
section mismatch warnings in vesafb code. Rather than converting all of
the annotations, do the obvious and revert the __init -> __devinit change,
and use the recommended (in that patch) alternative to calling
platform_driver_register(): vesafb depends on information obtained from by
kernel at boot time, cannot be a module, and no post-boot devices can ever
show up.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Greg KH <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Ever for 32-bit with sufficiently high NR_CPUS, and starting
with commit 789d03f584 also for
64-bit, the statically allocated early fixmap page tables were
not covering FIX_OHCI1394_BASE, leading to a boot time crash
when "ohci1394_dma=early" was used. Despite this entry not being
a permanently used one, it needs to be moved into the permanent
range since it has to be close to FIX_DBGP_BASE and
FIX_EARLYCON_MEM_BASE.
Reported-bisected-and-tested-by: Justin P. Mattock <[email protected]>
Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=14487
Signed-off-by: Jan Beulich <[email protected]>
Cc: <[email protected]> # [as far back as long as it still applies]
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
In order to avoid unnecessary chains of branches, rather than
implementing memcpy()/memset()'s access to their alternative
implementations via a jump, patch the (larger) original function
directly.
The memcpy() part of this is slightly subtle: while alternative
instruction patching does itself use memcpy(), with the
replacement block being less than 64-bytes in size the main loop
of the original function doesn't get used for copying memcpy_c()
over memcpy(), and hence we can safely write over its beginning.
Also note that the CFI annotations are fine for both variants of
each of the functions.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Nick Piggin <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
In order to avoid unnecessary chains of branches, rather than
implementing copy_user_generic() as a function consisting of
just a single (possibly patched) branch, instead properly deal
with patching call instructions in the alternative instructions
framework, and move the patching into the callers.
As a follow-on, one could also introduce something like
__EXPORT_SYMBOL_ALT() to avoid patching call sites in modules.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Nick Piggin <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
The early ioremap fixmap entries cover half (or for 32-bit
non-PAE, a quarter) of a page table, yet they got
uncondtitionally aligned so far to a 256-entry boundary. This is
not necessary if the range of page table entries anyway falls
into a single page table.
This buys back, for (theoretically) 50% of all configurations
(25% of all non-PAE ones), at least some of the lowmem
necessarily lost with commit e621bd1895.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Commit 917778267f removed __init from
ehci_wait_for_port(), but left it in place on ehci_reset_port(), which
is being called from the former function.
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Jason Wessel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
- avoid wasting more precious resources (DMA or DMA32 pools), when
being called through vmalloc_32{,_user}()
- explicitly allow using high memory here even if the outer allocation
request doesn't allow it
Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Cc: Nick Piggin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Despite being unused these should also get a CRC calculated.
Primarily I view this as a consistency thing. But I also think this is
one of the reasons why __crc_* need to be weak (which I think should be
avoided, and hence we should have the goal to eliminate this so that
failure to calculate a proper CRC for a symbol causes the build to fail).
Signed-off-by: Jan Beulich <[email protected]>
Cc: Anibal Monsalve Salazar <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
mce_timer must be passed to setup_timer() in all cases, no
matter whether it is going to be actually used. Otherwise, when
the CPU gets brought down, its call to del_timer_sync() will
never return, as the timer won't have a base associated, and
hence lock_timer_base() will loop infinitely.
Signed-off-by: Jan Beulich <[email protected]>
Signed-off-by: Hidetoshi Seto <[email protected]>
Cc: <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Having run into the run-(boot-)time check a couple of times lately,
I finally took time to find a build-time check so that one doesn't
need to analyze the register/stack dump and resolve this (through
manual lookup in vmlinux) to the offending construct.
The assembler will emit a message like "Error: value of <num> too
large for field of 1 bytes at <offset>", which while not pointing
out the source location still makes analysis quite a bit easier.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
init_task doesn't get its stack end location set to
STACK_END_MAGIC, and hence the message is confusing
rather than helpful in this case.
Signed-off-by: Jan Beulich <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Jan Beulich