Instead of re-creating the array on the stack each time
is_cmos_rtc_device() gets called, make the array 'static const'.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Commit 1266963170 ("PCI: Prevent out of bounds access in numa_node
override") missed that the user-provided node could also be negative.
Handle this case as well to avoid out-of-bounds accesses to the
node_states[] array. However, allow the special value -1, i.e.
NUMA_NO_NODE, to be able to set the 'no specific node' configuration.
Fixes: 1266963170 ("PCI: Prevent out of bounds access in numa_node override")
Fixes: 63692df103 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Sasha Levin <[email protected]>
CC: Prarit Bhargava <[email protected]>
CC: [email protected] # v3.19+
The following statement of ABI/testing/dev-kmsg is not quite right:
It is not possible to inject messages from userspace with the
facility number LOG_KERN (0), to make sure that the origin of the
messages can always be reliably determined.
Userland actually can inject messages with a facility of 0 by abusing the
fact that the facility is stored in a u8 data type. By using a facility
which is a multiple of 256 the assignment of msg->facility in log_store()
implicitly truncates it to 0, i.e. LOG_KERN, allowing users of /dev/kmsg
to spoof kernel messages as shown below:
The following call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
...leads to the following log entry (dmesg -x | tail -n 1):
user :emerg : [ 66.137758] Kernel panic - not syncing: beer empty
However, this call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
...leads to the slightly different log entry (note the kernel facility):
kern :emerg : [ 74.177343] Kernel panic - not syncing: beer empty
Fix that by limiting the user provided facility to 8 bit right from the
beginning and catch the truncation early.
Fixes: 7ff9554bb5 ("printk: convert byte-buffer to variable-length...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Alex Elder <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Kay Sievers <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
cpu_chain lost its __cpuinitdata annotation long ago in commit
5c113fbeed ("fix cpu_chain section mismatch..."). This and the global
__cpuinit annotation drop in v3.11 vanished the need to mark all users,
including transitive ones, with the __ref annotation. Just get rid of it
to not wrongly hide section mismatches.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
In commit 0db0628d90 ("kernel: delete __cpuinit usage from all core
kernel files") cpu_up() lost its __cpuinit annotation, vanishing the
need for cpu_subsys_online() to have a __ref annotation. Just drop it
to be able to catch real section mismatches in the future.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The sk_classid member is only required when CONFIG_CGROUP_NET_CLASSID is
enabled. #ifdefify it to reduce the size of struct sock on 32 bit
systems, at least.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The processor_handler structure does not reference any __init / __exit
code or data. Therefore the __refdata annotation is not needed. It used
to be prior to commit fe7bf106eb ("acpi: delete __cpuinit usage from
all acpi files") due to the __cpuinit annotation of acpi_processor_add().
But with that commit in place that requirement has gone.
The same is true for the acpi_cpu_notifier notifier block.
acpi_cpu_soft_notify() used to be marked __cpuinit but lost its
annotation in the above mentioned commit as well. Therefore the __refdata
annotation isn't needed there either.
Just drop the unneded __refdata annotations to be able to catch future
section mismatches.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The __ref / __refdata annotations used to be needed because of
referencing functions / variables annotated __cpuinit /
__cpuinitdata.
But those annotations vanished during the development of v3.11.
Therefore most of the __ref / __refdata annotations are not needed
anymore. As they may hide legitimate sections mismatches, we
better get rid of them.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
ACPI device ID arrays normally don't need to be written to as they're
only ever read. The common usage -- embedding pointers to acpi_device_id
arrays in other data structures -- reference them as 'const', e.g. as in
struct acpi_driver / acpi_scan_handler / device_driver. The matchers are
taking const pointers, too. So it's only natural, to propose using const
arrays. Change the documentation accordingly.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Make the button ACPI device ID array static const. Safes us a little bit
of code.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
There is no need to have processor_power_dmi_table[] writeable, constify
it.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Constify the acpi_hed_ids[] ACPI device IDs array -- no need to have it
writeable.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The device descriptors are never written to -- even pointed to as
'const' from struct lpss_private_data. Make them r/o for real.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The bat_dmi_table[] DMI table is referenced from the __init function
acpi_battery_init_async() only. It and its referenced functions can
therefore be marked __initconst to free up ~1kB of runtime memory after
initialization is done.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Make the acpi_battery_units() function take a const argument and return
a const char*, too. Also make it static. It probably doesn't matter, as
gcc will be clever enough to optimize and inline the code even without
these hints. However, we also get rid of a #ifdef block by moving the
function closer to its usage location, so it's at least a small gain in
code readability.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The offset tables are only read, not modified. Make them const.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
There is no need to have ac_dmi_table[] writeable, constify it.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Make the video ACPI device ID array static and constify the DMI system
IDs array. Saves us a little bit of code.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array and the register map, no need to have
them writable at runtime. Also drop the unneeded RT5670_INIT_REG_LEN
define.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array and the register map, no need to have
them writable at runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array and the register map, no need to have
them writable at runtime. Also drop the unneeded RT5640_INIT_REG_LEN
define.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Mark the module init / exit functions with __init / __exit accodingly.
This allows making the intel_powerclamp_ids[] array __initconst, too, as
it only gets referenced from powerclamp_probe(). This is safe as
file2alias doesn't care about the section, but the symbol name for the
MODULE_DEVICE_TABLE alias.
Cc: Arjan van de Ven <[email protected]>
Cc: Jacob Pan <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Jacob Pan <[email protected]>
Acked-by: Jacob Pan <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
The CPU ids are only tested in intel_idle_probe() which is itself an
__init function. For the MODULE_DEVICE_TABLE() file2alias doesn't care
about the section, just about the symbol name. So it's safe to mark
the cpu id array as __initconst so its memory can be released after
initialization is done.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The RAPL ids are only tested in rapl_init() which is itself an __init
function. For the MODULE_DEVICE_TABLE() file2alias doesn't care about
the section, just about the symbol name. Therefore it's safe to mark the
rapl_ids[] array as __initconst so its memory can be released after
initialization is done.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Jacob Pan <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
This module implements variations of "des3_ede" only. Drop the bogus
module aliases for "des".
Cc: Jussi Kivilinna <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
This module provides implementations for "des3_ede", too. Announce those
via an appropriate crypto module alias so it can be used in favour to
the generic C implementation.
Cc: David S. Miller <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: David S. Miller <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Commit 5d26a105b5 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.
Even though commit 5d26a105b5 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.
Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.
Fixes: 5d26a105b5 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
We can mark the DMI system id table as __initconst by using a helper
variable that'll tell us if we need to unregister the reboot notifier in
atyfb_exit() instead of matching the DMI system id again.
This frees up ~680 bytes of runtime memory, the DMI table occupies.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
The "by8" counter mode optimization is broken for 128 bit keys with
input data longer than 128 bytes. It uses the wrong key material for
en- and decryption.
The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved
in case we're handling more than 128 bytes of input data -- they won't
get reloaded after the initial load. They must therefore be (a) loaded
on the first iteration and (b) be preserved for the latter ones. The
implementation for 128 bit keys does not comply with (a) nor (b).
Fix this by bringing the implementation back to its original source
and correctly load the key registers and preserve their values by
*not* re-using the registers for other purposes.
Kudos to James for reporting the issue and providing a test case
showing the discrepancies.
Reported-by: James Yonan <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Cc: <[email protected]> # v3.18
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
pptp_getname() only partially initializes the stack variable sa,
particularly only fills the pptp part of the sa_addr union. The code
thereby discloses 16 bytes of kernel stack memory via getsockname().
Fix this by memset(0)'ing the union before.
Cc: Dmitry Kozlov <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
In commit 3891a04aaf ("x86-64, espfix: Don't leak bits 31:16 of %esp
returning..") the "ESPFix Area" was added to the page table dump special
sections. That area, though, has a limited amount of entries printed.
The EFI runtime services are, unfortunately, located in-between the
espfix area and the high kernel memory mapping. Due to the enforced
limitation for the espfix area, the EFI mappings won't be printed in the
page table dump.
To make the ESP runtime service mappings visible again, provide them a
dedicated entry.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
There is no need to keep the module loaded when it serves no function in
case the EFI runtime services are disabled. Return an error in this case
so loading the module will fail.
Also supply a module_exit function to allow unloading the module.
Last, but not least, set the owner of the file_system_type struct.
Cc: Jeremy Kerr <[email protected]>
Cc: Matthew Garrett <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
If userland creates a timer without specifying a sigevent info, we'll
create one ourself, using a stack local variable. Particularly will we
use the timer ID as sival_int. But as sigev_value is a union containing
a pointer and an int, that assignment will only partially initialize
sigev_value on systems where the size of a pointer is bigger than the
size of an int. On such systems we'll copy the uninitialized stack bytes
from the timer_create() call to userland when the timer actually fires
and we're going to deliver the signal.
Initialize sigev_value with 0 to plug the stack info leak.
Found in the PaX patch, written by the PaX Team.
Fixes: 5a9fa73072 ("posix-timers: kill ->it_sigev_signo and...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: PaX Team <[email protected]>
Cc: <[email protected]> # v2.6.28+
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
The 32 bit and 64 bit implementations differ in their __init annotations
for some functions referenced from the common EFI code. Namely, the 32
bit variant is missing some of the __init annotations the 64 bit variant
has.
To solve the colliding annotations, mark the corresponding functions in
efi_32.c as initialization code, too -- as it is such.
Actually, quite a few more functions are only used during initialization
and therefore can be marked __init. They are therefore annotated, too.
Also add the __init annotation to the prototypes in the efi.h header so
users of those functions will see it's meant as initialization code
only.
This patch also fixes the "prelog" typo. ("prologue" / "epilogue" might
be more appropriate but this is C code after all, not an opera! :D)
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
Commit 3f4a7836e3 ("x86/efi: Rip out phys_efi_get_time()") left
set_virtual_address_map as the only runtime service needed with a
phys mapping but missed to update the preceding comment. Fix that.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
This variable was accidentally exported, even though it's only used in
this compilation unit and only during initialization.
Remove the bogus export, make the variable static instead and mark it
as __initdata.
Fixes: 200001eb14 ("x86 boot: only pick up additional EFI memmap...")
Cc: Paul Jackson <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
Complement commit 62fa6e69a4 ("x86/efi: Delete most of the efi_call*
macros") and delete the stub macros for the !CONFIG_EFI case, too. In
fact, there are no EFI calls in this case so we don't need a dummy for
efi_call() even.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
The defines for xkey3, xkey6 and xkey9 are not used in the code. They're
probably left overs from merging the three source files for 128, 192 and
256 bit AES. They can safely be removed.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The "by8" CTR AVX implementation fails to propperly handle counter
overflows. That was the reason it got disabled in commit 7da4b29d49
("crypto: aesni - disable "by8" AVX CTR optimization").
Fix the overflow handling by incrementing the counter block as a double
quad word, i.e. a 128 bit, and testing for overflows afterwards. We need
to use VPTEST to do so as VPADD* does not set the flags itself and
silently drops the carry bit.
As this change adds branches to the hot path, minor performance
regressions might be a side effect. But, OTOH, we now have a conforming
implementation -- the preferable goal.
A tcrypt test on a SandyBridge system (i7-2620M) showed almost identical
numbers for the old and this version with differences within the noise
range. A dm-crypt test with the fixed version gave even slightly better
results for this version. So the performance impact might not be as big
as expected.
Tested-by: Romain Francoise <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The "by8" implementation introduced in commit 22cddcc7df ("crypto: aes
- AES CTR x86_64 "by8" AVX optimization") is failing crypto tests as it
handles counter block overflows differently. It only accounts the right
most 32 bit as a counter -- not the whole block as all other
implementations do. This makes it fail the cryptomgr test #4 that
specifically tests this corner case.
As we're quite late in the release cycle, just disable the "by8" variant
for now.
Reported-by: Romain Francoise <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The pci_find_bios() function is only ever called from initialization code,
therefore can be marked as such, too. This, in turn, allows marking other
functions called only in this context as well.
The bios32_indirect variable can be marked as __initdata as it is only
referenced from __init functions now.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
The constants in pci_mmcfg_nvidia_mcp55() need to be marked as __initconst
or they will remain in memory after init memory was released.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
According to include/linux/init.h, the __init annotation should be added
immediately before the function name. However, for quite a few functions
in mmconfig-shared.c this is not the case. It's either before the return
type or even in the middle of it. Beside gcc still getting it right, we
should change them to comply to the rules of include/linux/init.h.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
The DMI tables are only used in __init code, thereby can be marked as
initialization data, too. The same is true for the callback functions
referenced from the DMI tables.
This moves ~9.6 kB of code and r/o data to the init sections, marking the
memory for release after initialization.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
This is a follow-up patch to commit 49458e8308 ("ideapad-laptop:
Constify DMI table and other r/o variables") to do what its commit
message says. The actual commit differs from the patch posted at
https://www.mail-archive.com/[email protected]/msg05340.html
significantly, probably due to a bad merge conflict resolution. Fix up
the mess and constify the DMI table for real and fix the bogus
double-const of ideapad_rfk_data[].
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: Ike Panhc <[email protected]>
Signed-off-by: Darren Hart <[email protected]>
The DMI table does not need to be written to, make it r/o.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
The __init annotations for the DMI callback functions are wrong as this
code can be called even after the module has been initialized, e.g. like
this:
# echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove
# modprobe i915
# echo 1 > /sys/bus/pci/rescan
The first command will remove the PCI device from the kernel's device
list so the second command won't see it right away. But as it registers
a PCI driver it'll see it on the third command. If the system happens to
match one of the DMI table entries we'll try to call a function in long
released memory and generate an Oops, at best.
Fix this by removing the bogus annotation.
Modpost should have caught that one but it ignores section reference
mismatches from the .rodata section. :/
Fixes: 25e341cfc3 ("drm/i915: quirk away broken OpRegion VBT")
Fixes: 8ca4013d70 ("CHROMIUM: i915: Add DMI override to skip CRT...")
Fixes: 425d244c86 ("drm/i915: ignore LVDS on intel graphics systems...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Duncan Laurie <[email protected]>
Cc: Jarod Wilson <[email protected]>
Cc: Rusty Russell <[email protected]> # Can modpost be fixed?
Cc: [email protected]
Signed-off-by: Jani Nikula <[email protected]>
Avoid the variable length array (vla), just use PATH_MAX instead.
This not only makes this code clang friedly, it also leads to a
code size reduction:
text data bss dec hex filename
51765 2224 12416 66405 10365 scripts/mod/modpost.old
51677 2224 12416 66317 1030d scripts/mod/modpost.new
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Internally used symbols of modpost don't need to be externally visible;
make them static. Also constify the string arrays so they resist in the
r/o section instead of being runtime writable.
Those changes lead to a small size reduction as can be seen below:
text data bss dec hex filename
51381 2640 12416 66437 10385 scripts/mod/modpost.old
51765 2224 12416 66405 10365 scripts/mod/modpost.new
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Constify the rfkill_blacklist[] DMI table, the ideapad_rfk_data[] table
and the ideapad_attribute_group attribute group. There's no need to have
them writeable during runtime.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Ike Panhc <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
These variables don't need to be visible outside of this compilation
unit, make them static.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Mark volume_alsa_control_vol and volume_alsa_control_mute as __initdata,
as snd_ctl_new1() will copy the relevant parts, so there is no need to
keep the master copies around after initialization.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Henrique de Moraes Holschuh <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The DMI table is only ever used during initialization. Mark it as
__initconst so its memory can be released afterwards -- roughly 1.5 kB.
In turn, the callback functions can be marked with __init, too.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Jonathan Woithe <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
These functions are only called from other initialization routines, so
can be marked __init, too.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Constify the lis3lv02d_device_ids[] ACPI and the lis3lv02d_dmi_ids[] DMI
tables. There's no need to have them writeable during runtime.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Eric Piel <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The DMI table is already marked as __initconst, so can be the callback
functions as they're only used in that context.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Robert Gerlach <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The dell_quirks[] DMI table is only ever used during initialization.
Mark it as __initconst so its memory can be released afterwards --
roughly 5.7 kB. In turn, the callback function can be marked with
__init, too.
Also the touchpad_led_init() function can be marked __init as it's only
referenced from dell_init() -- an __init function.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Constify the asus_quirks[] DMI table. There's no need to have it
writeable during runtime.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Corentin Chary <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Quite a lot of code and data of acer-wmi.c is only ever used during
initialization. Mark those accordingly -- and constify, where
appropriate -- so the memory can be released afterwards.
All in all those changes move ~10 kB of code and data to the .init
sections, marking them for release after initialization has finished.
Signed-off-by: Mathias Krause <[email protected]>
Cc: "Lee, Chun-Yi" <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Constify the asus_quirks[] DMI table. There's no need to have it
writeable during runtime.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Corentin Chary <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The DMI table is only ever used during initialization. Mark it as
__initconst so its memory can be released appropriately. In turn, the
callback function can be marked with __init, too.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Encapsulate acer_suspend() and acer_resume with #ifdef CONFIG_PM_SLEEP
to get rid of the following warnings:
../acer-wmi.c:2046:12: warning: ‘acer_suspend’ defined but not used [-Wunused-function]
../acer-wmi.c:2068:12: warning: ‘acer_resume’ defined but not used [-Wunused-function]
Signed-off-by: Mathias Krause <[email protected]>
Cc: "Lee, Chun-Yi" <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
sparse_keymap_setup() will make a copy of the keymap, so we can release
the master copy after initialization.
Signed-off-by: Mathias Krause <[email protected]>
Cc: "Lee, Chun-Yi" <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The repo on kernel.org is no longer available but has a replacement at
cavan.codon.org.uk.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Complement commit 68aecfb979 ("lib/string_helpers.c: make arrays
static") by making the arrays const -- not only pointing to const
strings. This moves them out of the data section to the r/o data
section:
text data bss dec hex filename
1150 176 0 1326 52e lib/string_helpers.old.o
1326 0 0 1326 52e lib/string_helpers.new.o
Signed-off-by: Mathias Krause <[email protected]>
Cc: James Bottomley <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The VFS layer handles those in the very same way, if unset. No need for
additional stubs.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Alexander Viro <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
The code in neigh_sysctl_register() relies on a specific layout of
struct neigh_table, namely that the 'gc_*' variables are directly
following the 'parms' member in a specific order. The code, though,
expresses this in the most ugly way.
Get rid of the ugly casts and use the 'tbl' pointer to get a handle to
the table. This way we can refer to the 'gc_*' variables directly.
Similarly seen in the grsecurity patch, written by Brad Spengler.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Brad Spengler <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The error handling in the module init and exit functions can be
shortened to safe us some code.
1/ Remove the code duplications in the init function, jump straight to
the existing cleanup code by adding some labels. Also give the error
message some more value by telling the reason why loading the module has
failed. Furthermore fix the "IPSec" typo -- it should be "IPsec" instead.
2/ Remove the error handling in the exit function as the only legitimate
reason xfrm4_protocol_deregister() might fail is inet_del_protocol()
returning -1. That, in turn, means some other protocol handler had been
registered for this very protocol in the meantime. But that essentially
means we haven't been handling that protocol any more, anyway. What it
definitely means not is that we "can't deregister tunnel". Therefore
just get rid of that bogus warning. It's plain wrong.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
The error handling in the module init and exit functions can be
shortened to safe us some code.
1/ Remove the code duplications in the init function, jump straight to
the existing cleanup code by adding some labels. Also give the error
message some more value by telling the reason why loading the module has
failed.
2/ Remove the error handling in the exit function as the only legitimate
reason xfrm6_protocol_deregister() might fail is inet6_del_protocol()
returning -1. That, in turn, means some other protocol handler had been
registered for this very protocol in the meantime. But that essentially
means we haven't been handling that protocol any more, anyway. What it
definitely means not is that we "can't deregister protocol". Therefore
just get rid of that bogus warning. It's plain wrong.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
The quirks_param array is located in the BSS, no need to explicitly
initialize it with NULL.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
There is no need to recreate the very same ipc_ops structure on every
kernel entry for msgget/semget/shmget. Just declare it static and be
done with it. While at it, constify it as we don't modify the structure
at runtime.
Found in the PaX patch, written by the PaX Team.
Signed-off-by: Mathias Krause <[email protected]>
Cc: PaX Team <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: Manfred Spraul <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The format strings for various printk()s make use of a temporary
variable that is declared 'static'. This is probably not intended,
so fix those.
Found in the PaX patch, written by the PaX Team.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Hannes Reinecke <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: PaX Team <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
sk_unattached_filter_create() will copy the filter's instructions so we
don't need to have the master copy hanging around after initialization.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
If we fail to register one of the xfrm protocol handlers we will
unregister the pernet ops twice on the error exit path. This will
probably lead to a kernel panic as the double deregistration
leads to a double kfree().
Fix this by removing one of the calls to do it only once.
Fixes: fa9ad96d49 ("vti6: Update the ipv6 side to use its own...")
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
arch/x86/tests/regs_load.S is missing the linker note about the stack
requirements, therefore making the linker fall back to an executable
stack. As this object gets linked against the final perf binary, it'll
needlessly end up with an executable stack. Fix this by adding the
appropriate linker note.
Also add a global linker flag to prevent future regressions, as
suggested by Jiri. This way perf won't get an executable stack even if
we fail to add the .GNU-stack linker note to future assembler files.
Though, doing so might create regressions the other way around, when
(statically) linking against libraries needing an executable stack.
But, apparently, regressing in that direction is wanted as it is an
indicator of poor code quality -- or just missing linker notes.
Fixes: 3c8b06f981 ("perf tests x86: Introduce perf_regs_load function")
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Jiri Olsa <[email protected]>
In case we found a matching USB PHY in usb_get_phy() but the call to
try_module_get() fails, we shouldn't return a (probably soon dangling)
pointer but an ERR_PTR instead.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
The BPF_S_ANC_NLATTR and BPF_S_ANC_NLATTR_NEST extensions fail to check
for a minimal message length before testing the supplied offset to be
within the bounds of the message. This allows the subtraction of the nla
header to underflow and therefore -- as the data type is unsigned --
allowing far to big offset and length values for the search of the
netlink attribute.
The remainder calculation for the BPF_S_ANC_NLATTR_NEST extension is
also wrong. It has the minuend and subtrahend mixed up, therefore
calculates a huge length value, allowing to overrun the end of the
message while looking for the netlink attribute.
The following three BPF snippets will trigger the bugs when attached to
a UNIX datagram socket and parsing a message with length 1, 2 or 3.
,-[ PoC for missing size check in BPF_S_ANC_NLATTR ]--
| ld #0x87654321
| ldx #42
| ld #nla
| ret a
`---
,-[ PoC for the same bug in BPF_S_ANC_NLATTR_NEST ]--
| ld #0x87654321
| ldx #42
| ld #nlan
| ret a
`---
,-[ PoC for wrong remainder calculation in BPF_S_ANC_NLATTR_NEST ]--
| ; (needs a fake netlink header at offset 0)
| ld #0
| ldx #42
| ld #nlan
| ret a
`---
Fix the first issue by ensuring the message length fulfills the minimal
size constrains of a nla header. Fix the second bug by getting the math
for the remainder calculation right.
Fixes: 4738c1db15 ("[SKFILTER]: Add SKF_ADF_NLATTR instruction")
Fixes: d214c7537b ("filter: add SKF_AD_NLATTR_NEST to look for nested..")
Cc: Patrick McHardy <[email protected]>
Cc: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
There is really no need to page align sha1_transform_avx2. The default
alignment is just fine. This is not the hot code but only the entry
point, after all.
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Reviewed-by: H. Peter Anvin <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The AVX2 implementation might waste up to a page of stack memory because
of a wrong alignment calculation. This will, in the worst case, increase
the stack usage of sha1_transform_avx2() alone to 5.4 kB -- way to big
for a kernel function. Even worse, it might also allocate *less* bytes
than needed if the stack pointer is already aligned bacause in that case
the 'sub %rbx, %rsp' is effectively moving the stack pointer upwards,
not downwards.
Fix those issues by changing and simplifying the alignment calculation
to use a 32 byte alignment, the alignment really needed.
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Reviewed-by: H. Peter Anvin <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Commit 7c1da8d0d0 "crypto: sha - SHA1 transform x86_64 AVX2"
accidentally disabled the AVX variant by making the avx_usable() test
not only fail in case the CPU doesn't support AVX or OSXSAVE but also
if it doesn't support AVX2.
Fix that regression by splitting up the AVX/AVX2 test into two
functions. Also test for the BMI1 extension in the avx2_usable() test
as the AVX2 implementation not only makes use of BMI2 but also BMI1
instructions.
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Reviewed-by: H. Peter Anvin <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
This patch restores the changes of commit dff38e3e93 "x86: Use inline
assembler instead of global register variable to get sp". They got lost
in commit 198d208df4 "x86: Keep thread_info on thread stack in x86_32"
while moving the code to arch/x86/kernel/irq_32.c.
Quoting Andi from commit dff38e3e93:
"""
LTO in gcc 4.6/47. has trouble with global register variables. They were
used to read the stack pointer. Use a simple inline assembler statement
with a mov instead.
This also helps LLVM/clang, which does not support global register
variables.
"""
Cc: Steven Rostedt <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Andi Kleen <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
The documentation misses a few of the supported flags. Fix this. Also
respect the dependency to CONFIG_XFRM for the IPSEC flag.
Cc: Fan Du <[email protected]>
Cc: "David S. Miller" <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The 'out' label is just a relict from previous times as pgctrl_write()
had multiple error paths. Get rid of it and simply return right away
on errors.
Cc: "David S. Miller" <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
If a privileged user writes an empty string to /proc/net/pktgen/pgctrl
the code for stripping the (then non-existent) '\n' actually writes the
zero byte at index -1 of data[]. The then still uninitialized array will
very likely fail the command matching tests and the pr_warning() at the
end will therefore leak stack bytes to the kernel log.
Fix those issues by simply ensuring we're passed a non-empty string as
the user API apparently expects a trailing '\n' for all commands.
Cc: "David S. Miller" <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
A kernel with enabled lockdep complains about the wrong usage of
rcu_dereference() under a rcu_read_lock_bh() protected region.
===============================
[ INFO: suspicious RCU usage. ]
3.13.0-rc1+ #126 Not tainted
-------------------------------
linux/kernel/padata.c:115 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
1 lock held by cryptomgr_test/153:
#0: (rcu_read_lock_bh){.+....}, at: [<ffffffff8115c235>] padata_do_parallel+0x5/0x270
Fix that by using rcu_dereference_bh() instead.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Steffen Klassert <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
A kernel with enabled lockdep complains about the wrong usage of
rcu_dereference() under a rcu_read_lock_bh() protected region.
===============================
[ INFO: suspicious RCU usage. ]
3.13.0-rc1+ #126 Not tainted
-------------------------------
linux/crypto/pcrypt.c:81 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
1 lock held by cryptomgr_test/153:
#0: (rcu_read_lock_bh){.+....}, at: [<ffffffff812c8075>] pcrypt_do_parallel.isra.2+0x5/0x200
Fix that by using rcu_dereference_bh() instead.
Signed-off-by: Mathias Krause <[email protected]>
Cc: "David S. Miller" <[email protected]>
Acked-by: Steffen Klassert <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Mathias Krause